Re: [go-nuts] Why is the error sent to original channel can still be received after recreating the channel?

[Justin Israel]

On Friday, September 20, 2024 at 8:52:46 AM UTC+12 robert engels wrote:

Because the channel is captured by reference, so when the Go routine runs 
it already has the later value.


Maybe this modified version better illustrates the problem:
https://go.dev/play/p/XLekzv9wsVO

The original code has no synchronization, so you cannot be sure when the 
goroutine will run and reference the channel from the outer scope. This 
updated example shows the difference between synchronizing before and after 
the goroutine.
 


Your code has a race condition - run it under the race detector.

On Sep 19, 2024, at 11:30 AM, Feng Liyuan (SunRunAway)  
wrote:

I have a piece of Go code where I create a buffered error channel and send 
an error to it from a goroutine. Then, in the main, I recreate this 
channel. To my confusion, even after recreating the channel, I still 
receive the error sent by the original goroutine. Here is the code:

https://go.dev/play/p/y3roOPKO0iy

Can someone help explain why this happens?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3a49b432-a8fa-4bb3-bcd2-a8fcd679a0c3n%40googlegroups.com
 

.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/63fc3ce1-e016-480d-9df7-aa59c240b09bn%40googlegroups.com.

Re: [go-nuts] Re: couldn't print numbers ordered with goroutine

[Justin Israel]

On Sun, Apr 21, 2024, 2:07 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Sat, 2024-04-20 at 18:55 -0700, Robert Solomon wrote:
> > channels are not queues, as Justin said
>
> They can be; buffered channels are queues.
>
> From https://go.dev/ref/spec#Channel_types
>
> > Channels act as first-in-first-out queues. For example, if one
> > goroutine sends values on a channel and a second goroutine receives
> > them, the values are received in the order sent.



And really I wasn't even commenting on the nature of the channel. Only the
scheduling of the goroutines. Buffered or not, they would still be random
order right?


>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/oMFIFDi_Irg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/05501e4c795fdcb4b91ffa3c35f95984772c9cde.camel%40kortschak.io
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA2xbShBJNd1Sg2BOOsN%2BtU0050PcbDiGtOCNULsQG%3Dwig%40mail.gmail.com.

[go-nuts] Re: couldn't print numbers ordered with goroutine

[Justin Israel]

On Sunday, April 21, 2024 at 11:18:24 AM UTC+12 Taňryberdi Şyhmyradow wrote:

Hello guys,
For the following lines, I wanted to print numbers in ordered, but 
couldn't. Could you please help me and explain the reason
Thanks in advance

```
numbers := []int{1, 2, 3, 4, 5}

// Create a buffered channel to handle multiple values
printed := make(chan int, len(numbers))

for _, n := range numbers {
fmt.Println("Sending", n, "to the channel")
go func() {
printed <- n
}() // Pass the value of n by copying it
}

// Receive all values from the channel in a loop
for i := 0; i < len(numbers); i++ {
fmt.Println(<-printed)
}
```


When you start a bunch of goroutines in a loop, there is no guarantee as to 
what order the scheduler will start each one. 
Thus you will see them delivered in different orders on each run. You have 
to decide on some form of synchronization. Maybe you choose to run a single 
goroutine worker that will loop over the source slice, and push the values 
into the channel in order. Or maybe you will keep using many goroutines but 
collect them all in the receiver, sort them after the last value is 
received, and then print them out. Or, maybe your receiver will have some 
kind of buffering where it collects values and only prints them when it has 
the next one in sequence. 



-- 
Tanryberdi Shyhmyradov

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ae085bdf-544f-4958-b85f-e36dcaea8ca7n%40googlegroups.com.

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Justin Israel]

On Wednesday, October 18, 2023 at 3:12:29 AM UTC+13 Marc-Antoine Ruel wrote:

Sorry I wasn't clear. The static libraries are in a subdirectory because 
the user should not care and these libraries are effectively third party 
code.


Actually, you were totally clear. Sorry if my comment didn't make sense. I 
get that the user doesn't need to worry about the third_party directory 
with the header and pre-built static libraries. And I saw how you arrange 
to pick up the right ones in the code. My point was that from previous 
experience, "go get" would prune away directories that do not contain go 
source code, after it performs the clone from the remote, into the module 
cache. So I would have expected that when someone uses your library as a 
dependency, it would have omitted the needed third_party directory, for not 
having any Go source files in it. But when I tested it just now, it does 
seem to retain the subdirectory and link correctly. Maybe this was improved 
as of recent Go releases. 
In earlier versions of the Go tool, I would have either included a dummy Go 
source file in the subdirectory, or just kept the non-go files in the root 
with the rest of the Go source.
Maybe someone else can clarify if this workflow has been improved?


This declares the generic code available everywhere:
https://github.com/periph/d2xx/blob/main/d2xx.go

One set of files declare the import that is OS and CPU arch appropriate, 
e.g. 
https://github.com/periph/d2xx/blob/main/d2xx_linux_amd64.go

Then another set of two files defines the OS specific code. In practice, 
POSIX and windows;
https://github.com/periph/d2xx/blob/main/d2xx_posix.go
https://github.com/periph/d2xx/blob/main/d2xx_windows.go

A CGO_ENABLED=0 build gets instead redirected to
https://github.com/periph/d2xx/blob/main/d2xx_posix_no_cgo.go
but not on windows because this package uses dynamic linking on windows. 
Adapt as appropriate in your use case.

I hope this helps.

M-A


Le lun. 16 oct. 2023, 21 h 13, Justin Israel  a écrit :



On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:

I second Richard's suggestion. I used the same trick for 
https://github.com/periph/d2xx. This git repository contains a minimalist 
shim for the .a libraries and nothing else. It's designed to compile on any 
platform. It falls back to a scaffolding if the corresponding .a library is 
not present for the OS-arch combination or if CGO is disabled. It makes 
testing easier.

Then a proper package under https://github.com/periph/host/tree/main/ftdi 
exposes a higher level abstraction for the user.


With only headers and static libs in the thirdparty directory, is this 
package "go-gettable"? 
Will go make the subdirectory available in that case? It usually ignores if 
there is no Go source files. 
 

M-A

Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a 
écrit :

Hi Jan,

I'm going to go out on a limb here and suggest looking at using Go's 
`embed` feature?

https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/

I have not tried it with C libraries so there may be numerous reasons why 
it may not work for your needs. For example, I do not know what is required 
to *"install"* the libraries so that might be your sticking point that 
embed would not address. But if building on the user's machine is the real 
problem and you can distribute pre-build binaries then this might work for 
you.  

Basically Go reads a `//go:embed` comment, converts your files into Go 
source code, compiles that code, and then provides a package that allows 
you to write those files to disk from an your Go app before you need to 
load the libraries.

Maybe this will work for you?  If yes, would love to hear back how it 
worked out.

-Mike
On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:

I guess you switched things here. Shared libraries (.so) need to be 
available at engine. Static libraries (.a) are bagged into the binary.

-Bruno


On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:

Thanks Tamas, this is useful information. 

One of my libraries is using a `.a` library -- as opposed to `.so`, which 
is another level of complexity, since the library has to be available in 
runtime, not only in compile time -- and I'm going to follow your 
"incantation" suggestion.


On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:

Neither I see a convenient way.
BUT if you add a .go file into the directories where your precompiled 
libraries live,
then "go get" will download them too (and only those dirs that have .go 
files in it).

So your next mission is to prepare the right #cgo CFLAGS LDFLAGS 
incantations to use those libraries.

Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):

Thanks Tamás, I may not be understanding correctly, but after taking a look 
at github.com/godror/godror, and the odpi subdirectory,
I

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Justin Israel]

On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:

I second Richard's suggestion. I used the same trick for 
https://github.com/periph/d2xx. This git repository contains a minimalist 
shim for the .a libraries and nothing else. It's designed to compile on any 
platform. It falls back to a scaffolding if the corresponding .a library is 
not present for the OS-arch combination or if CGO is disabled. It makes 
testing easier.

Then a proper package under https://github.com/periph/host/tree/main/ftdi 
exposes a higher level abstraction for the user.


With only headers and static libs in the thirdparty directory, is this 
package "go-gettable"? 
Will go make the subdirectory available in that case? It usually ignores if 
there is no Go source files. 
 

M-A

Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a 
écrit :

Hi Jan,

I'm going to go out on a limb here and suggest looking at using Go's 
`embed` feature?

https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/

I have not tried it with C libraries so there may be numerous reasons why 
it may not work for your needs. For example, I do not know what is required 
to *"install"* the libraries so that might be your sticking point that 
embed would not address. But if building on the user's machine is the real 
problem and you can distribute pre-build binaries then this might work for 
you.  

Basically Go reads a `//go:embed` comment, converts your files into Go 
source code, compiles that code, and then provides a package that allows 
you to write those files to disk from an your Go app before you need to 
load the libraries.

Maybe this will work for you?  If yes, would love to hear back how it 
worked out.

-Mike
On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:

I guess you switched things here. Shared libraries (.so) need to be 
available at engine. Static libraries (.a) are bagged into the binary.

-Bruno


On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:

Thanks Tamas, this is useful information. 

One of my libraries is using a `.a` library -- as opposed to `.so`, which 
is another level of complexity, since the library has to be available in 
runtime, not only in compile time -- and I'm going to follow your 
"incantation" suggestion.


On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:

Neither I see a convenient way.
BUT if you add a .go file into the directories where your precompiled 
libraries live,
then "go get" will download them too (and only those dirs that have .go 
files in it).

So your next mission is to prepare the right #cgo CFLAGS LDFLAGS 
incantations to use those libraries.

Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):

Thanks Tamás, I may not be understanding correctly, but after taking a look 
at github.com/godror/godror, and the odpi subdirectory,
I see it is including all the `.c` files on the fly 
.

A couple of reasons immediately come to mind, that make this not a 
generically valid option:

* ODPI library is all C code (see src 
) so it works 
including in Go: my dependencies are C++/Rust code, for which I write a 
small C wrapper (or for Rust just `extern "C"`). Also architecture 
dependent compilation is different in C++/C/Rust code ...
* The C++ libraries I'm including have sub-dependencies of themselves (one 
of which is llvm). It uses Bazel to organize it, and to manually move all 
the required C++ files to a directory would be years of work :) Plus would 
require me to slave to maintain things in sync. 
* The C++ libraries take hours to compile ... I don't want to impose this 
to users of my libraries.

I think the only way to work this out is distributing the pre-compiled 
C++/Rust libraries, so the Go simply refer to them (and we get the fast 
compilation times from Go). But then, how to best distribute them in an 
automatic fashion, so that users don't need to one by one figure out how to 
install them (and clean up them later if they are no longer using...) ?

Or maybe there is another convenient way I'm not seeing ?


On Thursday, October 12, 2023 at 6:39:34 PM UTC+2 Tamás Gulácsi wrote:

Can't you build (make go build for you) those libraries?
For example, see github.com/godror/godror just includes the sources of that 
third party library in an "odpi" subdir, and with
```
/*
#cgo CFLAGS: -I./odpi/include -I./odpi/src -I./odpi/embed

#include "dpi.c"

*/
import "C"
```
it is compiled automatically.


Caveat: for "go get" to download a directory, it must include a sth.go file 
("require.go" in the odpi/* subdirs).
But it may work that your precompiled libs in a subdir, with a mock .go 
file gets downloaded.
But how will it found by your lib/app ?

Tamás


Jan a következőt írta (2023. október 12., csütörtök, 8:14:41 UTC+2):

Thanks Richard. Indeed, as you pointed out the downside is the bloating of 
the g

Re: [go-nuts] Re: Best IDE for GO ?

[Justin Israel]

On Sun, Aug 27, 2023 at 12:47 AM Mike Schinkel 
wrote:

> If I understand what you are asking then JetBrains GoLand does.
>
> I do not know if there is a way to use the keyboard, but it does provides
> links you can click when it displays the call stack on panic.
>

If your keymap configuration derives from one of the system configs
(Windows, Macos, ...) then "Next Frame" and "Previous Frame" have default
mapped hotkeys. So you can do the same workflow Jason mentioned, starting a
debugger execution, which panics, and then navigating the stack all via
keyboard (if that really is your thing).


>
> -Mike
>
> On Saturday, August 26, 2023 at 8:33:08 AM UTC-4 Jason E. Aten wrote:
>
>> Is there any IDE that allows you to jump through a stack trace like emacs
>> does?
>>
>> e.g. If I have a panic on a run, with two keystrokes I can jump to the
>> origin
>> of the panic, and then their caller, and then the parent caller, and then
>> up to
>> the grandparent on the call stack... instantly. I've never found this
>> essential
>> functionality elsewhere, but maybe I'm just not familiar... A friend of
>> mine tried
>> to add it to Visual Studio and gave up... it was just too hard for VS.
>> But maybe JetBrains has it??
>>
>> I'd love to try an IDE other than emacs, but this is a fundament thing,
>> that I cannot give up.
>>
>> On Friday, August 25, 2023 at 6:21:35 PM UTC+1 Mike Schinkel wrote:
>>
>>> Yes, as Luke Crook mentioned I think those requirements are more ALM
>>> functionality than IDE functionality.
>>>
>>> Generally, ALM addresses concerns broader than individual concerns
>>> whereas IDEs are more focused on individual productivity.
>>>
>>> Just my opinion, but I would expect you'd be better off finding an ALM
>>> solution and then an IDE that integrates with that ALM, or vice versa, i.e.
>>> find an IDE that integrates with an ALM and then use that ALM.
>>>
>>> #fwiw
>>>
>>> -Mike
>>> On Wednesday, August 23, 2023 at 7:21:46 AM UTC-4 alex-coder wrote:
>>>
 Hi All !

 Considering that IBM's punch cards were bearing at least twice, I would
 vote for them. :-)

 Of cource I do agree with them who wrote that to feel comfortable
 "under fingers" is great !

 So, the tasks to code - they are different.
 Sometimes it is possible to keep all the details regards to the task in
 a head or several.
 Sometimes it is nesessary to write say a hard copy of them(details) on
 a paper with a different size.

 But in case the task from the area of the "poorly formalized". You
 spend paper quickly. :-)

 The Luke Crook points to:
 https://en.wikipedia.org/wiki/Application_lifecycle_management

 I will simplify the task somewhat and take from ALM for example even
 less than SDLC, namely:
 requirements, design, implementation, testing, deployment.

 1. Requirements must be described somewhere.
 2. Design artifacts should reflect requirements.
 3. Design decisions refer to objects and messages that
 implemented in the form of classes and operations.
 4. Each operation must pass at least one test.
 All tests must be passed successfully.
 5. The application is assembled and installed there and
 the tests are successfully passed again.

 Question: is there any IDE or plugin which one support that kind of
 dependencies in a graphical mode ?

 Thank you.

 вторник, 22 августа 2023 г. в 18:22:52 UTC+3, Mike Schinkel:

> On Saturday, August 19, 2023 at 5:27:34 AM UTC-4 alex-coder wrote:
>
> What I'm looking for is the ability to manage dependencies not only in
> code,
> but entirely in a project from requirements to deployment.
>
>
> I assume you mean a lot more than just Go package dependencies, as `go
> mod` handles those nicely.
>
> Can you elaborate on the specific dependencies you are trying to
> manage?  In specific, vs generalities.
>
> -Mike
>
 --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/4yVXlyZZatM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c8b2e710-240b-4f4a-ae80-3142578673d3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA3S9n3C8nUp-X5

Re: [go-nuts] Best IDE for GO ?

[Justin Israel]

I usually hate this question and threads, because it's a bunch of people 
arguing that their solution is superior. 
There are always individuals stating how all they need is VIM or a plain 
text editor with no syntax highlighting. 
And then those like myself that feel very productive from the Jetbrains 
ecosystem because of its superior performance in large codebases and 
exceptional refactoring tools. No one is going to convince me that I would 
be more productive learning all the vim hot keys and doing it in a terminal 
without touching the mouse. It's just not my jam. And I wouldn't try to 
convince those developers to switch away from vim if they are happy. I 
prefer the visual feedback that I get from Intellij when refactoring and 
making really complicated changes. Typing is typing and everything can do 
that well to some degree with a language plugin. But things like the way my 
personal choice lays out unit testing and making it easy to retry subsets 
and see everything I need to see at once works for me. 
I just don't get the point of these threads that try to narrow in on the 
"best" ide. 


On Sunday, August 20, 2023 at 9:17:35 AM UTC+12 Robert Engels wrote:

> Reread what I wrote. Vim with autocomplete, etc is not a simple text 
> editor with syntax coloring. 
>
> Still every major software engineering org in the world uses an ide (or 
> multiple). I guess they don’t know what they are doing. 
>
> Btw, Googles current IDE is based on VSCode. 
>
> > On Aug 19, 2023, at 3:24 PM, Jan Mercl <0xj...@gmail.com> wrote:
> > 
> > On Sat, Aug 19, 2023 at 10:06 PM Christian Stewart
> >  wrote:
> > 
> >> Autocomplete and a go language server (gopls) add a ton of speed 
> because you don't need to look up the docs for function and variable names. 
> And go to definition improves speed navigating code significantly.
> > 
> > - Using autocomplete and go-to-definiton does not require VSCode or
> > any other IDE.
> > - I do use autocomplete and go-to-definition. When I said I use no
> > IDE, that does not mean I don't use those features.
> > - The speed of typing/inputting code is overally a rather negligible
> > factor of the total time cost of developing/debugging and maintaining
> > any non-toy project. IOW, it's not a significant metric of
> > productivity.
> > 
> >> But vim-go can do both, so why not just use it?
> > 
> > Because I use govim? ;-)
> > 
> > (But not for my large projects, gopls chokes on them still too often
> > to tolerate it.)
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-XusymW6gb5OnDa_7QWAWPFSkwKYQMYUm-d7419EZ%2BGkQ%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1e0ef783-83d2-4dbb-a7fb-02cf8786fa15n%40googlegroups.com.

[go-nuts] Re: [RFC] Yet another proposal for Go2 error handling

[Justin Israel]

On Monday, June 5, 2023 at 4:17:17 AM UTC+12 Shulhan wrote:

Dear gophers, 

I have been reading several proposals about error handling couple of 
months ago and today a light bulb come upon me, and then I write as much 
as I can think. I am not sure if its good or bad idea or even possible 
to implement. 

In this post, I will try as concise as possible. 
The full and up to date proposal is available at 
https://kilabit.info/journal/2023/go2_error_handling/ . 

Any feedback are welcome so I can see if this can move forward. 
Thanks in advance. 

== Background 

This proposal is based on "go2draft Error Handling". 

My critics to "go2draft Error Handling" is the missing correlation 
between handle and check. 
If we see one of the first code in the design, 

 
... 
handle err { 
return fmt.Errorf("copy %s %s: %v", src, dst, err) 
} 

r := check os.Open(src) 
... 
 

There is no explicit link between check keyword and how it will trigger 
handle err later. 
It is also break the contract between the signature of os.Open, that 
return an error in the second parameter, and the code that call it. 

This proposal try to make the link between them clear and keep the code 
flow explicit and readable. 

The goals is not to reduce number of lines but to minimize repetitive 
error handling. 


== Proposal 

This proposal introduces two new keywords and one new syntax for 
statement. 

The two new keywords are “WHEN” and “HANDLE”. 

 
When = "when" NonZeroValueStmt HandleCallStmt . 
NonZeroValueStmt = ExpressionStmt 
; I am not quite sure how to express non-zero value 
; expression here, so I will describe it below. 

HandleCallStmt = "handle" ( HandleName | "{" SimpleStmt "}" ) . 
HandleName = identifier . 
 

The HandleCallStmt will be executed if only if the statement in 
NonZeroValueStmt returned non-zero value of its type. 
For example, given the following variable declarations, 

 
var ( 
err = errors.New(`error`) 
slice = make([]byte, 1) 
no1 = 1 

no2 int 
ok bool 
) 
 

The result of when evaluation are below, 

 
when err // true, non-zero value of type error. 
when len(slice) == 0 // true, non-zero value of type bool. 
when no1 // true, non-zero value of type int. 
when no2 // false, zero value of int. 
when ok // false, zero value of bool. 
 

The HandleCallStmt can jump to handle by passing handle name or provide 
simple statement directly. 
If its simple statement, there should be no variable shadowing happen 
inside them. 

Example of calling handle by name, 

 
... 
when err handle myErrorHandle 

:myErrorHandle: 
return err 
 

Example of calling handle using simple statement, 

 
... 
when err handle { return err } 
 

The new syntax for statement is to declare label for handle and its body, 

 
HandleStmt = ":" HandleName ":" [SimpleStmt] [ReturnStmt | HandleCallStmt] 
. 
 

Each of `HandleStmt` MUST be declared at the bottom of function block. 
An `HandleStmt` can call other `HandleStmt` as long as the handle is above 
the 
current handle and it is not itself. 
Any statements below `HandleCallStmt` MUST not be executed. 

Unlike goto, each `HandleStmt` is independent on each other, one 
`HandleStmt` 
end on itself, either by calling `return` or `handle`, or by other 
`HandleStmt` and does not fallthrough below it. 

Given the list of handle below, 

 
:handle1: 
S0 
S1 
:handle2: 
handle handle1 
S3 
 

A `handle1` cannot call `handle2` because its below it. 
A `handle2` cannot call `handle2`, because its the same handle. 
A `handle2` can call `handle1`. 
The `handle1` execution stop at statement `S1`, not fallthrough below it. 
The `handle2` execution stop at statement "`handle handle1`", any 
statements 
below it will not be executed. 


The following function show an example of using this proposed error 
handling. 
Note that the handlers are defined several times here for showing the 
possible cases on how it can be used, the actual handlers probably only two 
or 
three. 

 
func ImportToDatabase(db *sql.DB, file string) (error) { 
when len(file) == 0 handle invalidInput 

f, err := os.Open(file) 
when err handle fileOpen 
// Adding `== nil` is OPTIONAL, the WHEN operation check for NON zero 
// value of returned function or instance. 

data, err := parse(f) 
when err handle parseError 

err = f.Close() 
// Inline error handle. 
when err handle { return fmt.Errorf(`%s: %w`, file, err) } 

tx, err := db.Begin() 
when err handle databaseError 

// One can join the statement with when using ';'. 
err = doSomething(tx, data); when err handle databaseError 

err = tx.Commit() 
when err handle databaseCommitError 

var outofscope string 
_ = outofscope 

// The function body stop here if its not expecting RETURN, otherwise 
// explicit RETURN must be declared. 

return nil 

:invalidInput: 
// If the function expect RETURN, the compiler will reject and return 
// an error indicating missing return. 

:fileOpen: 
// All the instances 

Re: [go-nuts] Experience with building JS and Python bindings for a Go library

[Justin Israel]

For automatic python bindings I have used github.com/go-python/gopy
https://github.com/justinfx/pygo-plugin/blob/main/go_plugin/client.go

And for pure cpython bindings I have used:

   - py2: github.com/sbinet/go-python
   - py3: github.com/DataDog/go-python3

- Justin

On Tuesday, May 23, 2023 at 5:56:34 PM UTC+12 Sebastien Binet wrote:

> For CPython, there's github.com/go-python/gopy that tries to 
> automatically wrap a Go package into a CPython module. 
>
> There's also go-python/gpython, a pure-Go Python3 interpreter (without all 
> the batteries, though). 
>
> For JS, I guess there's GopherJS. 
>
> hth, 
> -s 
>
> May 23, 2023 02:35:15 Taco de Wolff :
>
> I would like to know if anyone has experience with building bindings for 
> JavaScript (NodeJS) and Python for a Go library. Who has worked on this, or 
> does anybody know of libraries that have succeeded? In particular, I have 
> successfully built working JS and Python bindings (see 
> https://github.com/tdewolff/minify/tree/master/bindings), but I have two 
> problems:
>
> - How does the Go standard library (CGO) work in conjunction with 
> forked/worker threads of JS/Python? See 
> https://github.com/tdewolff/minify/issues/518#issuecomment-1256812343 
> - How can I prebuild binaries for Windows for a JS binding? In particular, 
> node-gyp allows you to build addons which is working fine for Linux/MacOS, 
> however they only permit using MSVC on WIndows and Go/CGO only can use GCC. 
> I'm suspecting this is behind an error we have (Error: Module did not 
> self-register) 
>
> I would love to hear about example or people with experience! Thanks in 
> advance!
>
> -- 
>
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7c18fb1e-1737-447c-9a86-04d52cf0b2f9n%40googlegroups.com
>  
> 
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e4421a6c-05aa-4fbd-9923-7b0118bacfdcn%40googlegroups.com.

Re: [go-nuts] Go + Imagemagick 7 + tight loop = CRASH!

[Justin Israel]

On Saturday, June 12, 2021 at 8:37:34 AM UTC+12 Ian Lance Taylor wrote:

> On Fri, Jun 11, 2021 at 1:32 PM Robert Schaaf  wrote: 
> > 
> > Please help, I humbly beg! 
> > 
> > First, the environment: 
> > 
> > go version go1.16.5 darwin/arm64 
> > ImageMagick 7.0.11-8 Q16 arm 2021-04-17 
> > macOS Big Sur, version 11.4 on Mac Mini M1, 16 GB 
> > 
> > I've run into a brick wall with Go driving the Imagemagick 7 API on a 16 
> > GB M1 Mac Mini. The problem occurs when combining an image read and 
> > pixel extraction in a tight loop. The first two lines, which cure the 
> problem, 
> > were suggested by Justin Israel. Note: it doesn't always crash, but the 
> attached 
> > PNG fails 100% of the time. 
>
> My understanding of what you are saying is that you have a way to 
> avoid the crash, which is to call runtime.LockOSThread. Is there 
> something wrong with that approach? What kind of answer are you 
> looking for? Thanks. 
>
> Ian


Some important context seems to have been omitted in this thread from the 
original question as it was posted in the imagick issue:
https://github.com/gographics/imagick/pull/256#issuecomment-858047483

Robert said it only crashes on a Mac M1 with ImageMagick7, whereas it 
worked fine on a Mac amd64. And I had also tested it and found it to be 
working fine on Ubuntu 18.04 amd64. My suggestion of trying LockOSThread 
apparently fixed the crash on the M1 target. And then I suggested Robert 
pose the situation to golang-nuts to see if anything popped up as being 
specific to this newer Mac target and why it might behave differently than 
other targets.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/75d22cb0-124a-47fe-8dd3-89febdb94651n%40googlegroups.com.

Re: [go-nuts] Re: Modules... why it has to be so painfull?

[Justin Israel]

On Sat, Apr 10, 2021 at 3:38 AM 'gonutz' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Justin Isreael said
>
> "Changes to ProjectB should be immediately available when compiling
> ProjectA."
>
> which is not true when you simply insert a replace in your go.mod file.
>
> My current problem is that I have a main module that uses a library
> module. I want to debug an issue so I insert a print statement in my main
> module. That works. But now I want to insert a print statement in the
> library. How do I do that?
>
> A replace in the go.mod file is of no help here because I still have to
> specify a require with a concrete version or commit hash for the library.
> This means I cannot just change the code in the library module, I also have
> to create a commit and check it in, then go back to my main module and
> udpate not only the replace but also the require in go.mod, every time I
> want to simply place a simple, temporary print statement for debugging
> purposes into the library.
>

Yes I omitted the fact that the "replace" directive implies that there was
already a "require" directive that needs replacing. But I still maintain
that my original suggestion works. I don't see any requirement that your
library be committed or pushed anywhere, or have a real github hosting, for
the case of pure local development between a number of separate modules.

Here is a structure of two module projects, neither of which have any git
configuration:

.
├── projectA
│   ├── go.mod
│   └── main.go
└── projectB
├── go.mod
└── lib.go

// projectB/lib.gopackage projectB
import "fmt"
func Foo() {
fmt.Println("ProjectB")
}

// projectB/go.mod
module mydomain.com/projects/projectB

// projectA/main.gopackage main
import  "mydomain.com/projects/projectB"
func main() {
projectB.Foo()
}

// projectA/go.mod
module mydomain.com/projects/projectA

require mydomain.com/projects/projectB v0.0.0
replace mydomain.com/projects/projectB => /tmp/gotesting/projectB


So I didn't have to commit and push my code anywhere and could just use an
arbitrary version for the "require", and then replace. Now I can do local
development across modules. I guess I am missing the pain point here.


> Does anybody have an easy workflow for the common use case?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/_BqV6Rk15UA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/421ae2eb-fd97-46b4-ab83-979c5e63cf88n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA1smZ1yAiBLdzYag5cN4_8rL0A3HjTBRwFgJhq_6_UsJg%40mail.gmail.com.

Re: [go-nuts] Modules... why it has to be so painfull?

[Justin Israel]

On Thursday, April 8, 2021 at 12:14:40 PM UTC+12 Slawomir Pryczek wrote:

> Thanks for all replies. Actually the docs are good (imo) just these  
> solutions proposed in docs are a horror.
>
> Inside root folder of the module... so im unable to share packages between 
> projects and code structure gets horrible, because now instead of nicely 
> organized 2 levels of nesting i have 3 levels and i need to repeat name of 
> the project 5 times inside every of 25 different root packages. Maybe for 
> small  apps. If i'm having eg. slab allocator used by both webserver and 
> k-v storage it'd be good to put it outside and not having half of the 
> modules in other apps imported from webserver and other half from k-v 
> storage. It introduces unneeded complexity if package pretends to have 
> something in common with something which is totally unrelated just because 
> it's easier to put it in there. Next i'll have to do v2 of webserver when 
> API of some of packages will change, so the version number won't reflect 
> version number of my app... but changes to some single package in it.
>
> Putting main app dir/files as a parent of general purpose packages is a 
> bad idea. Having tax app to be a parent of decimals package is like having 
> a 3d graph library to be a parent of network I/O package. There is no 
> relation so it should be separated for readability.
>
> >Have you tried go mod edit -replace github.com/foo/bar=/path/to/local/bar 
> ?
> I'll have to do hundreds of such edits and then re-edit it each time 
> anything changes (package rename, moving files, etc.)
>
> My point is why this module approach broken the ability to organize code 
> conviniently and logically... If we're in /src/foo and there is /src/bar 
> and we do import "bar" in foo... it should just (what a surprise) import 
> the local bar :D And another issue with this approach is that... should we 
> put this abomination inside git? So really, everyone who downloads my code 
> will have to waste 4 hours of his life replacing imports or he'll be forced 
> to do edits inside C:\Users\slawomir\go or maybe he'll edit in 
> F:\users\michael\my\nice\go\path and put it in repo so i'll have to change 
> it back :D
>
> I know it's easier said than done but we have all this nice things like 
> goroutines, GC, channels, peemption... and everything is so simple. Just to 
> manually babysit package manager when previous model was working? Even 
> having the user go to command line and issue module init for something 
> without remote imports is a step backwards, because it's a waste of time, 
> added complexity and totally unneeded.
>
> Having like tens of pages of "instructions" and blog posts telling users 
> how to configure package manager just to run 10 lines of code if we want to 
> organize it well is a step forward? With GOPATH you did one simple thing 
> and it was working. Just once not 1000 times over and over, for each 
> package or after anything in your dev enviroment changed. So not sure why 
> everyone should be forced to migrate to this cumbersome model when we have 
> nicely organized, self containted projects and the only issue is versioning 
> for the PART of projects which are actually ... libraries, not applications.
>
> >One solution is apparently to use a module like a giant mono repo, aka 
> gopath
> Still it requires for this replace and keeping absolute paths everywhere. 
> It's not even possible to put your project on github this way because it 
> won't compile without configuring everything. That's a huge regression 
> because you'll have to copy-paste all shared code inside each individual 
> app folder if you don't want to publish 30 packages as separate modules or 
> put unrelated things together. Each solution is sub-optimal because 
> separation can't just be done right in sane amount of time in this model 
> because PM isn't able to conviniently handle local packages nor 
> initialization nor changes in the packages...
>
> My point is, that it's so inconvinient that you'll organize your code 
> badly just to save time... GOPATH is much better approach for bigger apps 
> and it shouldn't be made obsolete. At least not if the only solution is 
> putting things where they don't belong or setting up proxies to pretend 
> local files are remote and then re-running some command line tools each 
> time you add a line in one of these...
>

My take on this is that you appear to be aggressively ranting about modules 
with assertions about how it does or does not function, before actually 
discovering what modules truly do or do not do. People are more likely 
inclined to be helpful if you just present your situation, what you tried, 
and what you expect. But leave out the bits where it is assumed to be a 
broken implementation that can not do what you want, that it is poorly 
conceived, and how frustrated and angry those assumptions makes you feel. 
Your frustrations are valid, but they are likely based on incomplete or 
w

[go-nuts] Re: Calling Go from Python

[Justin Israel]

On Wednesday, April 7, 2021 at 6:10:49 AM UTC+12 amitl...@gmail.com wrote:

>
> Hi,
> A cheat-sheet I wrote for myself evolved into a full tutorial 
>  on calling Go directly from Python 
> using ctypes and dll's, so I am happy to share it with the community. It 
> starts from the very basics and covers how to handle arrays, strings and 
> objects in both directions, memory management, performance, and even how to 
> interact directly with numpy and pandas objects. I hope it's useful for the 
> pythonistas among you.
>
> Any feedback, ideas and questions are welcome.
>

Nice write up! I've use the ctypes approach for a few situations and its 
great to have a detailed reference guide like this. 

Also recently I started using https://github.com/go-python/gopy and have 
been contributing a bunch of fixes and features. For simple situations 
though it is much easier to just use the ctypes approach since you have 
fine grained control over the access. As long has you don't have too much 
to expose to python, and too much memory management and type shimming to do.
 

>
> Amit
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/58381400-d80a-4f31-a5e9-7e12cd8b7a83n%40googlegroups.com.

Re: [go-nuts] Contrary to popular opinion...

[Justin Israel]

On Monday, March 1, 2021 at 9:36:57 AM UTC+13 ren...@ix.netcom.com wrote:

> I think the only time the indentation is a problem is when refactoring 
> code - copying pasting code blocks seems to be a guessing game with my IDEs 
> and often require manual fixes - the issue seems far less common (and more 
> easily corrected) when using brackets.  
>
> On Feb 28, 2021, at 12:12 PM, Bob Alexander  wrote:
>
> 
>
> I never have understood the *serious* hatred of Python's "indentation as 
> syntax" approach. I've used lots of bracketed and begin/end languages 
> (C/C++, Algol & relatives, Ruby, and most other programming languages), and 
> when I write code in those languages I usually indent as I write. 
> Obviously, indenting makes it much easier for a human to understand the 
> program structure. It never occurred to me to code C, for example, without 
> indenting. Of course, the compiler doesn't mind -- for the computer the 
> brackets are easier to understand, but not for humans.
>
> When I pseudo-code with pencil and paper or text editor, my natural 
> tendency is to use indentation for structure, not brackets. I'd imagine 
> this is true for almost everyone. When Python came along the Python team 
> adopted the motto "programmable pseudo-code" (or something like that) and, 
> for me, it was true. I personally think Python is very readable. 
> Another minor benefit of the indentation-only approach is the reduced 
> vertical size of a program -- all those trailing brackets on a line of 
> their own add up :)
>
> So it never occurred to me to object to Python's indentation approach. I 
> always did it anyway. And, even without code formatters, if a program could 
> compile and run, I could rely on the indentation to be representative of 
> the program's actual structure.
>
> Aside from indentation Python's keyword function arguments and optional 
> arguments often make for more readable code. Go could really benefit from 
> those features, and since they are already available in struct literals, it 
> might not be too hard to fit into the Go language...
>
> On Sun, Feb 28, 2021 at 12:35 AM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
>> > I meant, for example, in regexp notation, ` *` vs `\n *` between a
>> > function signature and the opening brace of the function body.
>>
>> Ah, yes.
>>
>> > This assumes newline is a whitespace. Most programming languages
>> > agree, but humans may not.
>>
>> With semicolon insertion, they're not. While they are white, they're
>> qualitatively difference to horizontal white.
>>
>> Dan
>>
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/uy17JJe8KB4/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/070aa073f9c5c9d78a7d68bf9534fa37d701d384.camel%40kortschak.io
>> .
>>
> -- 
>
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAKyHfRMkgqZ0MyQFcyszX3m1DLcrK%3D1Zfiw2ugFx3VsX2QSeAQ%40mail.gmail.com
>  
> 
> .
>
> I have been a Python developer for 14 years, and whitespace has never 
really presented itself as any significant issue. The occasional copy-paste 
resulting in mixed spaces vs tabs gets flagged by modern code editors. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/713d2178-87a2-480a-9ba1-d113175bdd72n%40googlegroups.com.

Re: [go-nuts] What are debian:buster-slim advantages vs alpine ones?

[Justin Israel]

On Friday, December 18, 2020 at 10:31:46 AM UTC+13 za...@zrhoffman.net 
wrote:

> In our project we'd chosen debian-slim images vs alpine few years ago due 
>> to a number of reasons, if I recall arguments were like:
>>
>> 1. presence of libc
>>
>  
> There are reasons to choose other images over Alpine, but IMO avoiding 
> musl libc is not one of them. In the case of x86_64 architecture, if you 
> symlink ld-musl-x86_64.so.1 to ld-linux-x86-64.so.2, you can use musl libc 
> in place of glibc, which is functional for most use cases.
>

My experience in maintaining  github.com/gographics/imagick  is that the 
use of an alpine image led to a lot of support tickets. As it turns out, 
libmusl doesn't work well with ImageMagick. So I just avoid it, as you 
would need to be sure your C dependencies are happy with it first. 

>
> See this example Dockerfile to use a linux/arm64 Go release with an Alpine 
> base image:
>
> FROM alpine:3.12 
> RUN ln -s lib lib64 && \ 
> ln -s ld-musl-x86_64.so.1 lib/ld-linux-x86-64.so.2 
> RUN set -o pipefail && \ 
> wget -O- https://golang.org/dl/go1.15.6.linux-amd64.tar.gz | \ 
> tar xzC usr/local && \ 
> rm -r usr/local/go/pkg/linux_amd64_race 
> ENV PATH=${PATH}:/usr/local/go/bin \ 
> GOPATH=/go
>
> Binaries built using this approach can run on other linux/amd64 platforms, 
> even though CGO was not disabled.
>
> As a side note, the resultant image for the above Dockerfile is 369MB, 
> whereas golang:alpine is only 299MB. The size difference is 
> /usr/local/go/pkg/linux_amd64_race, which golang:alpine does not include 
> (but golang:buster, for example, does).
>
> -Zach
>
> On Thu, Dec 17, 2020 at 5:44 AM Space A.  wrote:
>
>> Hi Constantine,
>>
>> In our project we'd chosen debian-slim images vs alpine few years ago due 
>> to a number of reasons, if I recall arguments were like:
>>
>> 1. presence of libc
>> 2. bugs and performance issues of alpine
>> 3. security issues of alpine 
>> 4. debian is more suitable for testing with huge amount of tools 
>> available out of the box, if needed
>>
>>
>> After all, talking about saving few tens of megs of hdd space per image 
>> (it's the main reason for ppl selecting alpine) is ridiculous nowadays IMO.
>>
>>
>>
>> среда, 16 декабря 2020 г. в 20:10:49 UTC+3, Constantine Vassilev: 
>>
>>> What about the size of images? For pure Golang project what are the 
>>> advantages of glibc?
>>>
>>> For a project I have to present pro and cons before the team to decide.
>>>
>>> On Tuesday, December 15, 2020 at 6:03:29 PM UTC-8 amits...@gmail.com 
>>> wrote:
>>>


 On Wed, 16 Dec 2020, 12:38 pm Constantine Vassilev,  
 wrote:

> All examples in Google Cloud Run for building
> Golang Docker images are based on Debian.
>
> FROM golang:alpine AS builder
> ...
> FROM debian:buster-slim
> ...
>
> What are debian:buster-slim  advantages vs alpine ones?
>

 Besides the size of the images, one key difference would be the 
 underlying C library - Debian would be glibc and Alpine would be libmusl

 So advantages would be if knowing that libc is available.

> -- 
> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2433a1dd-c3ea-4c5c-9f6e-d1595cef99f9n%40googlegroups.com
>  
> 
> .
>
 -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9f0bd697-286f-455a-afef-4a49e98fea80n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a3c9d89-a95e-43fd-acfb-4693bb275349n%40googlegroups.com.

Re: [go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

[Justin Israel]

On Friday, July 17, 2020 at 11:21:32 AM UTC+12 va...@selfip.ru wrote:

> вт, 14 июл. 2020 г. в 18:39, Jake Montgomery : 
> > 
> > I agree, it seems like an unfortunate oversight. You can do it without 
> the slice tricks: https://play.golang.org/p/tNAPOcQqApN 
> > It does take an additional Sprintf() though. 
> > 
>
> Thanks, looks good. But i think for go devs adding additional format 
> that can be used to specify milli/micro/nano seconds will be easy. 
>
> -- 
> Vasiliy Tolstov, 
> e-mail: v.to...@selfip.ru 
>

I asked the same question on reddit about a month ago, where I needed to 
match an existing timestamp format:
https://www.reddit.com/r/golang/comments/gr7hz9/string_formatting_a_timetime_with_custom/

Seems string formatting was the best option available to me.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5b132613-5be4-4062-8092-5e0cfa92a7d6n%40googlegroups.com.

Re: [go-nuts] Re: Tracking down RSS growth in cgo library

[Justin Israel]

On Mon, May 25, 2020, 7:12 AM Ian Lance Taylor  wrote:

> On Sat, May 23, 2020 at 8:39 PM Justin Israel 
> wrote:
> >
> > On Sat, May 23, 2020 at 5:19 PM Justin Israel 
> wrote:
> >>
> >> I've been working to track this down for 2 days now and I'm just taking
> a long shot to see if anyone might have a new idea for me.
> >> My cgo-based bindings library seems to have unbounded RSS memory
> growth, which I have been able to reduce to the smallest benchmark test and
> even pinpoint the exact call, but the reason behind it still eludes me.
> >> The context is that I have a struct in C++ that will store a const
> char* for the last exception that was thrown, as a strdup() copy which gets
> cleaned up properly each time.
> >>
> >> typedef struct _HandleContext {
> >> HandleId handle;
> >> const char* last_error;
> >> } _HandleContext;
> >>
> >> const char* getLastError(_HandleContext* ctx);
> >>
> >> On the Go side, I have a function for lastError() to return the last
> error value
> >>
> >> func (c *Config) lastError() error {
> >> err := C.getLastError(c.ptr)
> >> if err == nil {
> >> return nil
> >> }
> >> e := C.GoString(err)
> >> if e == "" {
> >> return nil
> >> }
> >> runtime.KeepAlive(c)
> >> // return nil  // <- would result in no memory growth
> >> return errors.New(e)  // <- results in memory growth
> >> }
> >>
> >> What I am seeing in my benchmark test is that the RSS grows something
> like 20MB a second, yet the GODEBUG=gctrace=1 and the pprof memory profile
> don't reflect this memory usage at all, aside from showing a hotspot (in
> pprof) being the GoString() call:
> >>
> >> gc 4 @4.039s 0%: 0.006+0.14+0.003 ms clock,
> 0.024+0.10/0.039/0.070+0.014 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
> >> gc 5 @6.857s 0%: 0.003+0.20+0.004 ms clock,
> 0.015+0.069/0.025/0.15+0.016 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
> >> ...
> >> gc 26 @69.498s 0%: 0.005+0.12+0.003 ms clock,
> 0.021+0.10/0.044/0.093+0.014 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
> >> // 800MB RSS usage
> >> gc 27 @71.824s 0%: 0.006+2.2+0.003 ms clock,
> 0.025+0.063/0.058/0.11+0.014 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
> >>
> >> (pprof) top10
> >> Showing nodes accounting for 46083.69kB, 100% of 46083.69kB total
> >> Showing top 10 nodes out of 19
> >>   flat  flat%   sum%cum   cum%
> >> 30722.34kB 66.67% 66.67% 30722.34kB 66.67%  <...>._Cfunc_GoStringN
> (inline)
> >>  7168.11kB 15.55% 82.22%  7168.11kB 15.55%  errors.New (inline)
> >>  3073.16kB  6.67% 88.89% 46083.69kB   100%  <...>.testLeak
> >>  1536.02kB  3.33% 92.22%  1536.02kB  3.33%
> <...>.(*DisplayTransform).SetInputColorSpace.func1
> >>  1024.02kB  2.22% 94.44%  1024.02kB  2.22%
> <...>.(*Config).NumViews.func1
> >>  1024.02kB  2.22% 96.67%  1024.02kB  2.22%  <...>.(*Config).View.func1
> >>   512.01kB  1.11% 97.78%   512.01kB  1.11%
> <...>.(*DisplayTransform).SetView.func1
> >>   512.01kB  1.11% 98.89%   512.01kB  1.11%  <...>._Cfunc_GoString
> (inline)
> >>   512.01kB  1.11%   100%   512.01kB  1.11%  <...>.newProcessor (inline)
> >>  0 0%   100%   512.01kB  1.11%
> <...>.(*Config).ColorSpaceNameByIndex
> >>
> >> Regardless of whether I ignore the error return value in my test, it
> grows. If I return nil instead of errors.New(e), it will stay around 20MB
> RSS.
> >>
> >> I MUST be doing something stupid, but I can't see any reason for the
> memory growth based on returning this string wrapped in an error. At first
> I thought I was leaking in C/C++ but it a led to this one factor on the Go
> side. Any tips would help greatly, since I have tried debug GC output,
> pprof reports, valgrind, address sanitizer, and refactoring the entire
> memory management of my C bindings layer.
> >>
> >> Justin
> >>
> >
> > Well I seem to have resolved the leak, which was due to a poor
> assumption on my part about the frequency of finalizer execution and being
> tied to a GC cycle. Are finalizers executed on every GC cycle, or are they
> maybe executed on a GC cycle but not sooner than?
> > My library creates finalizers to ensure C memory is freed at some point,
> but I also have Destroy() methods to immediately free them (and clear
> finalizers). So I think it was a combin

[go-nuts] Re: Tracking down RSS growth in cgo library

[Justin Israel]

On Sat, May 23, 2020 at 5:19 PM Justin Israel 
wrote:

> I've been working to track this down for 2 days now and I'm just taking a
> long shot to see if anyone might have a new idea for me.
> My cgo-based bindings library seems to have unbounded RSS memory growth,
> which I have been able to reduce to the smallest benchmark test and even
> pinpoint the exact call, but the reason behind it still eludes me.
> The context is that I have a struct in C++ that will store a const char*
> for the last exception that was thrown, as a strdup() copy which gets
> cleaned up properly each time.
>
> typedef struct _HandleContext {
> HandleId handle;
> const char* last_error;
> } _HandleContext;
> const char* getLastError(_HandleContext* ctx);
>
> On the Go side, I have a function for lastError() to return the last error
> value
>
> func (c *Config) lastError() error {
> err := C.getLastError(c.ptr)
> if err == nil {
> return nil
> }
> e := C.GoString(err)
> if e == "" {
> return nil
> }
> runtime.KeepAlive(c)
> // return nil  // <- would result in no memory growth
> return errors.New(e)  // <- results in memory growth
> }
>
> What I am seeing in my benchmark test is that the RSS grows something like
> 20MB a second, yet the GODEBUG=gctrace=1 and the pprof memory profile don't
> reflect this memory usage at all, aside from showing a hotspot (in pprof)
> being the GoString() call:
>
> gc 4 @4.039s 0%: 0.006+0.14+0.003 ms clock, 0.024+0.10/0.039/0.070+0.014 ms 
> cpu, 4->4->0 MB, 5 MB goal, 4 P
> gc 5 @6.857s 0%: 0.003+0.20+0.004 ms clock, 0.015+0.069/0.025/0.15+0.016 ms 
> cpu, 4->4->0 MB, 5 MB goal, 4 P
> ...
> gc 26 @69.498s 0%: 0.005+0.12+0.003 ms clock, 0.021+0.10/0.044/0.093+0.014 ms 
> cpu, 4->4->0 MB, 5 MB goal, 4 P
> // 800MB RSS usage
> gc 27 @71.824s 0%: 0.006+2.2+0.003 ms clock, 0.025+0.063/0.058/0.11+0.014 ms 
> cpu, 4->4->0 MB, 5 MB goal, 4 P
>
> (pprof) top10
> Showing nodes accounting for 46083.69kB, 100% of 46083.69kB total
> Showing top 10 nodes out of 19
>   flat  flat%   sum%cum   cum%
> 30722.34kB 66.67% 66.67% 30722.34kB 66.67%  <...>._Cfunc_GoStringN (inline)
>  7168.11kB 15.55% 82.22%  7168.11kB 15.55%  errors.New (inline)
>  3073.16kB  6.67% 88.89% 46083.69kB   100%  <...>.testLeak
>  1536.02kB  3.33% 92.22%  1536.02kB  3.33%  
> <...>.(*DisplayTransform).SetInputColorSpace.func1
>  1024.02kB  2.22% 94.44%  1024.02kB  2.22%  <...>.(*Config).NumViews.func1
>  1024.02kB  2.22% 96.67%  1024.02kB  2.22%  <...>.(*Config).View.func1
>   512.01kB  1.11% 97.78%   512.01kB  1.11%  
> <...>.(*DisplayTransform).SetView.func1
>   512.01kB  1.11% 98.89%   512.01kB  1.11%  <...>._Cfunc_GoString (inline)
>   512.01kB  1.11%   100%   512.01kB  1.11%  <...>.newProcessor (inline)
>  0 0%   100%   512.01kB  1.11%  
> <...>.(*Config).ColorSpaceNameByIndex
>
> Regardless of whether I ignore the error return value in my test, it
> grows. If I return nil instead of errors.New(e), it will stay around 20MB
> RSS.
>
> I MUST be doing something stupid, but I can't see any reason for the
> memory growth based on returning this string wrapped in an error. At first
> I thought I was leaking in C/C++ but it a led to this one factor on the Go
> side. Any tips would help greatly, since I have tried debug GC output,
> pprof reports, valgrind, address sanitizer, and refactoring the entire
> memory management of my C bindings layer.
>
> Justin
>
>
Well I seem to have resolved the leak, which was due to a poor assumption
on my part about the frequency of finalizer execution and being tied to a
GC cycle. Are finalizers executed on every GC cycle, or are they maybe
executed on a GC cycle but not sooner than?
My library creates finalizers to ensure C memory is freed at some point,
but I also have Destroy() methods to immediately free them (and clear
finalizers). So I think it was a combination of the test not generating
enough Go garbage to clean up the more significant C memory, and not being
explicit enough with Destroy calls. I look to have also had a situation
where I wasn't cleaning up C strings as fast as I could have been, so that
also helps to clear them more quickly before a Destroy or a finalizer runs.

As much as I thought I knew about the caveats of finalizers and using them
to release C resources, I still likely made faulty assumptions.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA0Q6jFovOhjHxo0vNFSvqUaBPC_uU3sJhL5LnDbmQM1%2BA%40mail.gmail.com.

[go-nuts] Tracking down RSS growth in cgo library

[Justin Israel]

I've been working to track this down for 2 days now and I'm just taking a
long shot to see if anyone might have a new idea for me.
My cgo-based bindings library seems to have unbounded RSS memory growth,
which I have been able to reduce to the smallest benchmark test and even
pinpoint the exact call, but the reason behind it still eludes me.
The context is that I have a struct in C++ that will store a const char*
for the last exception that was thrown, as a strdup() copy which gets
cleaned up properly each time.

typedef struct _HandleContext {
HandleId handle;
const char* last_error;
} _HandleContext;
const char* getLastError(_HandleContext* ctx);

On the Go side, I have a function for lastError() to return the last error
value

func (c *Config) lastError() error {
err := C.getLastError(c.ptr)
if err == nil {
return nil
}
e := C.GoString(err)
if e == "" {
return nil
}
runtime.KeepAlive(c)
// return nil  // <- would result in no memory growth
return errors.New(e)  // <- results in memory growth
}

What I am seeing in my benchmark test is that the RSS grows something like
20MB a second, yet the GODEBUG=gctrace=1 and the pprof memory profile don't
reflect this memory usage at all, aside from showing a hotspot (in pprof)
being the GoString() call:

gc 4 @4.039s 0%: 0.006+0.14+0.003 ms clock,
0.024+0.10/0.039/0.070+0.014 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 5 @6.857s 0%: 0.003+0.20+0.004 ms clock,
0.015+0.069/0.025/0.15+0.016 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
...
gc 26 @69.498s 0%: 0.005+0.12+0.003 ms clock,
0.021+0.10/0.044/0.093+0.014 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
// 800MB RSS usage
gc 27 @71.824s 0%: 0.006+2.2+0.003 ms clock,
0.025+0.063/0.058/0.11+0.014 ms cpu, 4->4->0 MB, 5 MB goal, 4 P

(pprof) top10
Showing nodes accounting for 46083.69kB, 100% of 46083.69kB total
Showing top 10 nodes out of 19
  flat  flat%   sum%cum   cum%
30722.34kB 66.67% 66.67% 30722.34kB 66.67%  <...>._Cfunc_GoStringN (inline)
 7168.11kB 15.55% 82.22%  7168.11kB 15.55%  errors.New (inline)
 3073.16kB  6.67% 88.89% 46083.69kB   100%  <...>.testLeak
 1536.02kB  3.33% 92.22%  1536.02kB  3.33%
<...>.(*DisplayTransform).SetInputColorSpace.func1
 1024.02kB  2.22% 94.44%  1024.02kB  2.22%  <...>.(*Config).NumViews.func1
 1024.02kB  2.22% 96.67%  1024.02kB  2.22%  <...>.(*Config).View.func1
  512.01kB  1.11% 97.78%   512.01kB  1.11%
<...>.(*DisplayTransform).SetView.func1
  512.01kB  1.11% 98.89%   512.01kB  1.11%  <...>._Cfunc_GoString (inline)
  512.01kB  1.11%   100%   512.01kB  1.11%  <...>.newProcessor (inline)
 0 0%   100%   512.01kB  1.11%
<...>.(*Config).ColorSpaceNameByIndex

Regardless of whether I ignore the error return value in my test, it grows.
If I return nil instead of errors.New(e), it will stay around 20MB RSS.

I MUST be doing something stupid, but I can't see any reason for the memory
growth based on returning this string wrapped in an error. At first I
thought I was leaking in C/C++ but it a led to this one factor on the Go
side. Any tips would help greatly, since I have tried debug GC output,
pprof reports, valgrind, address sanitizer, and refactoring the entire
memory management of my C bindings layer.

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA20ai9u9Gy8Zk_XTq5ZK9bz_oo0ZrZs5ruvEwfwK3ukqA%40mail.gmail.com.

Re: [go-nuts] help w/ therecipe/qt

[Justin Israel]

On Mon, Mar 2, 2020 at 6:48 AM rob  wrote:

> The exact problem is one of the first in chapter 4
>
> MainWindow::MainWindow()
> {
> setWindowTitle("SRM System");
> setFixedSize(500, 500);
> QPixmap newIcon("new.png");
> QPixmap openIcon("open.png");
> QPixmap closeIcon("close.png");
>
> // Setup File Menu
> fileMenu = menuBar()->addMenu("&File");
> quitAction = new QAction(closeIcon, "Quit", this);
> quitAction->setShortcuts(QKeySequence::Quit);
> newAction = new QAction(newIcon, "&New", this);
> newAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_C));
> openAction = new QAction(openIcon, "&New", this);
> openAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_O));
> fileMenu->addAction(newAction);
> fileMenu->addAction(openAction);
> fileMenu->addSeparator();
> fileMenu->addAction(quitAction);
> helpMenu = menuBar()->addMenu("Help");
> aboutAction = new QAction("About", this);
> aboutAction->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_H));
> helpMenu->addAction(aboutAction);
>
> // Setup Signals and Slots
> connect(quitAction, &QAction::triggered, this, &QApplication::quit);
> }
>

How about checking out the examples?
https://github.com/therecipe/qt/blob/master/internal/examples/widgets/textedit/textedit.go#L131


That one shows how to use QKeySequence constants and custom keys.


> Thanks
>
> --rob solomon
>
>
> On 2/29/20 2:55 PM, Rob Muhlestein wrote:
> > Hi there Rob, would you mind sharing that book so I can share it with
> people on my rwxrob.live stream. I like the idea of doing what you are
> doing.
> >
> > I might be able to help you past that if I had the exact problem.
> >
> >
> > ---
> > “Mr. Rob” Muhlestein
> > /^((Found|Teach|Hack)er|(Men|Jani)tor|C[A-Z]*O)$/
> > r...@robs.io • skilstak.io • twitch.tv/rwxrob
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Saturday, February 29, 2020 11:48 AM, rob 
> wrote:
> >
> >> Hi.  I'm trying to learn therecipe/qt by working my way thru a book
> >> using C++ examples and translating them into Go.  I'm stuck at
> >> QKeySequence stuff.
> >>
> >> My computer runs ubuntu 18.04, and I installed Go 1.13.8 on it, along w/
> >> all the Qt development stuff from qt.io, and therecipe/qt.
> >>
> >> Where are there resources for me to go thru on doing what I'm trying?
> >>
> >> Thanks
> >>
> >>
> >>
> 
> >>
> >> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7b6da064-cf87-513c-783f-379f2bfd0eed%40fastmail.com
> .
> >
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/qvswkktCbYg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3d8b80e0-009b-7360-2d69-53e9c489d483%40fastmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA0-YiaKzQ1xjHO88PmmP32Lhnmv_uDEfg9PAXcQYocdZw%40mail.gmail.com.

[go-nuts] help w/ therecipe/qt

[Justin Israel]

You are likely to get the most focused support by checking with the project:
https://github.com/therecipe/qt/blob/master/README.md

Maybe asking on their slack channel if you can't figure it out from the Qt docs 
+ therecipe/qt api? 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b68aeb55-25dd-4b8f-a07a-2a0dd5e6f44e%40googlegroups.com.

[go-nuts] Re: A question !

[Justin Israel]

On Sunday, January 5, 2020 at 7:28:24 AM UTC+13, Motaz Hejaze wrote:
>
>
> 1 - Is there really a big performance ( speed ) difference between using 
> Python OR Golang in backend web development ? 
>

There are a number of reasons why Go *could* out-perform Python when 
comparing django to a Go web backend. 
Firstly, in order to scale django across multiple cores on the same host, 
one generally deploys a python web framework under uwsgi which handles 
spawning multiple instances of the application and load balancing th 
request. Python is effectively single threaded because of the GIL so this 
is the solution for production python web servers. 
Go on the other hand can use all of the cores with just a single process 
and can be deployed directly. 

Aside from that, there could be other areas where Go performs better, 
depending on what your application is doing, because it is compiled and 
uses static types as opposed to python being interpreted and constantly 
using reflection. One can mitigate some of these performance issues with 
compiled python extensions. But again, *it depends*. 
 

> 4 - I know that go comes with builtin web server , is it reliable for 
> production ? or shall we connect go with classic web servers aka ( nginx , 
> apache ) ?
>

The stdlib web server is production grade and can be used to deploy the 
binary directly without the need for a proxy.
But the use of a proxy can still be valid for situations where you want 
load balancing, static file caching, or TLS terminatation, as a few 
examples. 
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f9e386d9-007a-4b1e-8841-474e098fbfeb%40googlegroups.com.

[go-nuts] distributed runtime

[Justin Israel]

Seems like it would just be easier to explicitly schedule work over something 
like nats.io
At least you would have 100% control over what is distributed over the network. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6bfa45c1-082f-42ad-84c2-cfa7d000d84d%40googlegroups.com.

[go-nuts] Re: Appending static libraries to cgo LDFLAGS.

[Justin Israel]

On Thursday, December 19, 2019 at 11:23:41 AM UTC+13, Bruno Albuquerque 
wrote:
>
> I am trying to get a version of GoCV that works with OpenCV static 
> libraries. The final issue I have is that pkg-config is not really listing 
> all required libraries so i need to append some extra ones. Here is how my 
> cgo configuration looks like without the extra libraries:
>
> #cgo !windows pkg-config: --static opencv4
> #cgo CXXFLAGS:   --std=c++11
>
> This mostly works but, as I mentioned, pkg-config -static is somehow 
> missing some libraries and I have to add then.
>
> because I am dealing with static libraries, it is important that they are 
> all added after all the other -llibrary entries.
>
> I tried adding the libraries after the last #cgo statement, like this:
>
> #cgo !windows pkg-config: --static opencv4
> #cgo CXXFLAGS:   --std=c++11
> #cgo !windows LDFLAGS: -ldc1394 -lavcodec -lavformat -lavutil -lswscale
>

Are their pc file definitions for the avcodec and other dependencies? If 
so, can you pass them all to pkg-config?

 #cgo !windows pkg-config: --static opencv4 avcodec ...

Other than that, I am not sure how you can get fine grained control of 
order when mixing pkg-config and LDFLAGS. Usually when I am static linking 
cgo I am 100% using CXXFLAGS/LDFLAGS and not pkg-config. 
Maybe they could introduce something like LINKFLAGS which is the same as 
LDFLAGS but appends to the end? (I got that concept from using the waf 
build system, which provides that setting as well).
 

>
> This correctly adds the libraries to the linker command but the libraries 
> are added before any other entries. i.e, here is what I get:
>
> TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK/b031=/tmp/go-build -gno-record-gcc-switches -o 
> $WORK/b031/_cgo_.o $WORK/b031/_cgo_main.o $WORK/b031/_x001.o 
> $WORK/b031/_x002.o $WORK/b031/_x003.o $WORK/b031/_x004.o $WORK/b031/_x005.o 
> $WORK/b031/_x006.o $WORK/b031/_x007.o $WORK/b031/_x008.o $WORK/b031/_x009.o 
> $WORK/b031/_x010.o $WORK/b031/_x011.o $WORK/b031/_x012.o $WORK/b031/_x013.o 
> $WORK/b031/_x014.o $WORK/b031/_x015.o $WORK/b031/_x016.o $WORK/b031/_x017.o 
> $WORK/b031/_x018.o $WORK/b031/_x019.o $WORK/b031/_x020.o $WORK/b031/_x021.o 
> $WORK/b031/_x022.o $WORK/b031/_x023.o $WORK/b031/_x024.o $WORK/b031/_x025.o 
> -g -O2 -ldc1394 -lavcodec -lavformat -lavutil -lswscale -ldc1394 -lavcodec 
> -L/usr/local/lib -L/usr/local/lib/opencv4/3rdparty 
> -L/tmp/opencv/opencv-4.1.2/build/lib -lopencv_gapi -lopencv_stitching 
> -lopencv_aruco -lopencv_bgsegm -lopencv_bioinspired -lopencv_ccalib 
> -lopencv_dnn_objdetect -lopencv_dnn_superres -lopencv_dpm -lopencv_highgui 
> -lopencv_face -lopencv_freetype -lopencv_fuzzy -lopencv_hfs 
> -lopencv_img_hash -lopencv_line_descriptor -lopencv_quality -lopencv_reg 
> -lopencv_rgbd -lopencv_saliency -lopencv_stereo -lopencv_structured_light 
> -lopencv_phase_unwrapping -lopencv_superres -lopencv_optflow 
> -lopencv_surface_matching -lopencv_tracking -lopencv_datasets -lopencv_text 
> -lopencv_dnn -lopencv_plot -lopencv_videostab -lopencv_video 
> -lopencv_videoio -lopencv_xfeatures2d -lopencv_shape -lopencv_ml 
> -lopencv_ximgproc -lopencv_xobjdetect -lopencv_objdetect -lopencv_calib3d 
> -lopencv_imgcodecs -lopencv_features2d -lopencv_flann -lopencv_xphoto 
> -lopencv_photo -lopencv_imgproc -lopencv_core -littnotify -llibprotobuf 
> -llibwebp -lIlmImf -lquirc -lippiw -lippicv -lade -lgtk-x11-2.0 
> -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 
> -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig 
> -lgthread-2.0 -ljpeg -lpng -lz -ltiff -lfreetype -lharfbuzz -ldl -lm 
> -lpthread -lrt
>
> This fails. If I simply move the libraries to the end, then it works:
>
> TERM='dumb' g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=$WORK/b031=/tmp/go-build -gno-record-gcc-switches -o 
> $WORK/b031/_cgo_.o $WORK/b031/_cgo_main.o $WORK/b031/_x001.o 
> $WORK/b031/_x002.o $WORK/b031/_x003.o $WORK/b031/_x004.o $WORK/b031/_x005.o 
> $WORK/b031/_x006.o $WORK/b031/_x007.o $WORK/b031/_x008.o $WORK/b031/_x009.o 
> $WORK/b031/_x010.o $WORK/b031/_x011.o $WORK/b031/_x012.o $WORK/b031/_x013.o 
> $WORK/b031/_x014.o $WORK/b031/_x015.o $WORK/b031/_x016.o $WORK/b031/_x017.o 
> $WORK/b031/_x018.o $WORK/b031/_x019.o $WORK/b031/_x020.o $WORK/b031/_x021.o 
> $WORK/b031/_x022.o $WORK/b031/_x023.o $WORK/b031/_x024.o $WORK/b031/_x025.o 
> -g -O2 -L/usr/local/lib -L/usr/local/lib/opencv4/3rdparty 
> -L/tmp/opencv/opencv-4.1.2/build/lib -lopencv_gapi -lopencv_stitching 
> -lopencv_aruco -lopencv_bgsegm -lopencv_bioinspired -lopencv_ccalib 
> -lopencv_dnn_objdetect -lopencv_dnn_superres -lopencv_dpm -lopencv_highgui 
> -lopencv_face -lopencv_freetype -lopencv_fuzzy -lopencv_hfs 
> -lopencv_img_hash -lopencv_line_descriptor -lopencv_quality -lopencv_reg 
> -lopencv_rgbd -lopencv_saliency -lopencv_stereo -lopencv_structured_light 
> -lopencv_phase_unwrapping -lopencv_superre

Re: [go-nuts] Re: buildmode=c-archive and statically linking into another lib

[Justin Israel]

On Wed, Aug 28, 2019, 3:47 PM  wrote:

> I find the package you build with 'go build buildmode=c-archive/c-shared',
> when you build you code with the lib, the outer need to have main func, I
> don't know why.
>

That requirement is documented here:
https://golang.org/cmd/go/#hdr-Build_modes


> 在 2016年5月18日星期三 UTC+8上午11:11:57，Justin Israel写道：
>>
>> I'm wondering if someone can tell me if this is either a limitation of
>> buildmode=c-archive static libs, or if I am really just doing something
>> wrong.
>>
>> Problematic steps:
>>
>>1. export functions to  libgofoo.a using buildmode=c-archive
>>2. statically link libgofoo.a into another library to produce libfoo.a
>>3. Someone else consumes libfoo.a and libgofoo.a in their library,
>>and get linker errors about:
>>ld: libgofoo.a(go.o): relocation R_X86_64_TPOFF32 against
>>`runtime.tlsg` can not be used when making a shared object; recompile with
>>-fPIC
>>libgofoo.a: could not read symbols: Bad value
>>
>> But library that wants to consume these libs can do so if they
>> dynamically link with shared libs from c-shared. Also, if the consumer
>> of the libs is a main binary, then the static linking works and does not
>> complain. It is only when the target is a library.
>>
>> I could swear I went through and ensured -fPIC was being used, but it
>> didn't seem to make a difference. Am I infact just messing up my
>> compilation settings and failing to add this flag as it suggests, or is
>> there a known limitation related to the steps I have outlined?
>>
>> Thanks!
>> Justin
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/EhndTzcPJxQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2032198a-00dd-40a8-a8aa-489e9ae406bf%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/2032198a-00dd-40a8-a8aa-489e9ae406bf%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA3jXOrEVf8pFrC5GxF%2B%3Dmg_DUZOPj-LDS1e-scj_%3D_LLA%40mail.gmail.com.

[go-nuts] Re: buildmode=c-archive and statically linking into another lib

[Justin Israel]

On Friday, April 12, 2019 at 1:21:25 PM UTC+12, Chao Chen wrote:
> Do you any progress to solve the problem? I meet the same problem.
> 
> 
> when I call golang build shared library on python from alpine 3.9 
> container.failed with OSError: Error relocating ./cc.so: : initial-exec TLS 
> resolves to dynamic definition in ./cc.so
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> /usr/src/app # go build -o cc.so -buildmode=c-shared main.go
> 
> 
> 
> 
> /usr/src/app # readelf -d cc.so
> 
> 
> 
> 
> Dynamic section at offset 0x10cd10 contains 22 entries:
> 
> Tag Type Name/Value
> 
> 0x0001 (NEEDED) Shared library: [libc.musl-x86_64.so.1]
> 
> 0x0010 (SYMBOLIC) 0x0
> 
> 0x000c (INIT) 0x42000
> 
> 0x000d (FINI) 0x92ed9
> 
> 0x0019 (INIT_ARRAY) 0xa2078
> 
> 0x001b (INIT_ARRAYSZ) 8 (bytes)
> 
> 0x6ef5 (GNU_HASH) 0x270
> 
> 0x0005 (STRTAB) 0xa50
> 
> 0x0006 (SYMTAB) 0x378
> 
> 0x000a (STRSZ) 1026 (bytes)
> 
> 0x000b (SYMENT) 24 (bytes)
> 
> 0x0003 (PLTGOT) 0x10deb0
> 
> 0x0002 (PLTRELSZ) 720 (bytes)
> 
> 0x0014 (PLTREL) RELA
> 
> 0x0017 (JMPREL) 0x41a00
> 
> 0x0007 (RELA) 0xe58
> 
> 0x0008 (RELASZ) 265128 (bytes)
> 
> 0x0009 (RELAENT) 24 (bytes)
> 
> 0x001e (FLAGS) SYMBOLIC BIND_NOW STATIC_TLS
> 
> 0x6ffb (FLAGS_1) Flags: NOW NODELETE
> 
> 0x6ff9 (RELACOUNT) 11040
> 
> 0x (NULL) 0x0
> 
> 
> 
> 
> /usr/src/app # python test.py
> 
> Traceback (most recent call last):
> 
> File "test.py", line 2, in 
> 
> lib = ctypes.cdll.LoadLibrary('./cc.so')
> 
> File "/usr/lib/python2.7/ctypes/init.py", line 444, in LoadLibrary
> 
> return self._dlltype(name)
> 
> File "/usr/lib/python2.7/ctypes/init.py", line 366, in init
> 
> self._handle = _dlopen(self._name, mode)
> 
> OSError: Error relocating ./cc.so: : initial-exec TLS resolves to dynamic 
> definition in ./cc.so
It looks like there was some recent activity that relates to both your musl 
compiler issue and my original issue:
https://github.com/golang/go/issues/29674

This is specifically targeting Android issues it seems. 

I stopped trying to use Go C shared libraries in C++ libs/plugins after this 
post, since it couldn't cope with large shared plugin environment platforms 
where there was a race to a limited amount of static TLS slots. But now this is 
becoming relevant for me again with the new work being done in gopy to generate 
python extensions:
https://github.com/go-python/gopy/pull/180



> On Wednesday, May 25, 2016 at 7:14:02 AM UTC+8, Justin Israel wrote:
> I've got one more question, related to this process, now that this library is 
> seeing some production use...
> 
> 
> The C++ Go binding shared library is being used as a dependency in another 
> library. This other library is a plugin that gets loaded via dlopen. I am 
> seeing the following:
> 
> 
> dlopen: cannot load any more object with static TLS
> 
> 
> In doing some research, I found that this happens when shared libs default or 
> use "-ftls-model=initial-exec" and/or don't use "-fpic". So it a situation of 
> the big pool of plugins that get dlopen'd into this particular application, 
> and the static TLS slots running out when enough of them use initial-exec. 
> 
> 
> I was looking at my shared lib that is created via "go build 
> -buildmode=c-shared -gcflags=-shared -asmflags=-shared -installsuffix=_shared 
> -a" and I do see it using "-fPIC". After doing some SO research, someone 
> suggested doing the following to determine the TLS mode that is being used:
> 
> 
> http://stackoverflow.com/questions/22983986/is-there-a-way-to-determine-thread-local-storage-model-used-by-a-library-on-linu
> 
> 
> 
> $ readelf -d libgofileseq.so | grep FLAGS
> ... (FLAGS)    SYMBOLIC STATIC_TLS
> 
> 
> 
> It seems no combination of trying to add "-ftls-model=global-dynamic" to my 
> compile process can resolve the problem. Are there any suggestions of where 
> this change can be applied, to correct the situation where dlopen fails? We 
> have found that if this plugin using this shared library gets loaded first, 
> then we don't encounter the static TLS failure. 
> 
> 
> Justin
> 
> 
> 
> 
> 
> On Wednesday, May 18, 2016 at 3:11:57 PM UTC+12, Justin Israel wrote:
> I'm wondering if someone can tell me if t

Re: [go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Justin Israel]

On Thu, Jun 13, 2019 at 4:05 PM Tong Sun  wrote:

> Yep, thanks Justin, both your points really made the difference,
> because I do believe that the buffered socket write is the key
> component for the 3-time improvement that I'm getting (from using
> FastHTTP), IMHO. And FastHTTP recommends GOMAXPROCS=1 too, which I
> used this time as well.
>
> So thanks again, Justin & Ronny!
>

Cool. Glad that actually helped. I do feel with your results, and in
agreement with others,  that you really are comparing Go to the underlying
C implementation of php, with everything stripped back so far. But at least
you are happy with your results!


> On Sat, Jun 8, 2019 at 10:54 PM Justin Israel 
> wrote:
> >
> > I'm wondering about a couple factors in this comparison that seem to
> make a difference in my local test:
> >
> > I think perl sockets are write buffered. So would the equivalent be to
> wrap the net.Conn in bufio.NewWriter(c) and flush before the Close?
> > Since this is a straigh-line test where both servers are not using
> concurrent handling of connections (uncommon for a Go server even on 1
> core), would it not make sense to run the Go server with GOMAXPROCS=1?
> >
> > - Justin
> >
> > On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote:
> >>
> >> I had always believed that the web projects build with Go should be
> much faster than Perl, since Go is a compiled language.
> >>
> >> However that belief was crushed brutally last night, when I did a
> comparison -- the Go implementation is 8 times worse than the Perl! -- the
> mean response time jumped from 6ms to 48ms.
> >>
> >> I know this is the simplest possible web server, but still, when it
> comes to simple web servers like this, I have to say that Perl performs
> much better than Go.
> >>
> >> I don't think there is much I can twist on the Go side, since it can't
> be more simpler than that. However, I also believe it won't hurt to ask and
> confirm. So,
> >>
> >> Have I missed anything? Is it possible for me to make my Go
> implementation anywhere near the Perl's performance?
> >>
> >> Thanks
> >>
> >>
> > --
> > You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> > To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/iH2Ck_hpCpI/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGFgA2_oz-Frmw13oraLoeyzidwy_r4yWUfPNuqFFKefgG6DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go will shine on huge web projects, but how about simple ones?

[Justin Israel]

I'm wondering about a couple factors in this comparison that seem to make a 
difference in my local test:

   1. I think perl sockets are write buffered. So would the equivalent be 
   to wrap the net.Conn in bufio.NewWriter(c) and flush before the Close?
   2. Since this is a straigh-line test where both servers are not using 
   concurrent handling of connections (uncommon for a Go server even on 1 
   core), would it not make sense to run the Go server with GOMAXPROCS=1? 

- Justin

On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote:
>
> I had always believed that the web projects build with Go should be much 
> faster than Perl, since Go is a compiled language. 
>
> However that belief was crushed brutally last night, when I did a 
> comparison -- the Go implementation is *8 times worse 
> * 
> than the *Perl*! -- the *mean *response time jumped from 6ms to 48ms. 
>
> I know this is the simplest possible web server, but still, when it comes 
> to simple web servers like this, I have to say that Perl performs much 
> better than Go.
>
> I don't think there is much I can twist on the Go side, since it can't be 
> more simpler than that. However, I also believe it won't hurt to ask and 
> confirm. So,
>
> Have I missed anything? Is it possible for me to make my Go implementation 
> anywhere near the Perl's performance?
>
> Thanks
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go package manager

[Justin Israel]

On Saturday, June 1, 2019 at 12:43:50 AM UTC+12, yashi...@gmail.com wrote:
> Hi everyone!
> 
> I recently build an interesting Go tool - GPM (Go Project Manager). It allows 
> you to build and manage go projects. Ont op, it also allows to update version 
> of Go from cli.
> Check it out: https://github.com/YashishDua/gpm
> 
> Feedback is appreciated!

Your README doesn't indicate that it only supports OSX. The "update" command 
downloads the osx build and replaces a hard-coded system install location.

Aside from the "create" command setting up an opinionated project structure, to 
me is seems like the build, mod, vendor logic just thinly wraps calls to the Go 
tool equivalent commands. What is it really doing that the current go tool 
doesn't handle? I thought go module support works in any location already. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4ce39173-697a-408a-9a2d-92d84f7b7468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Convert *C.char to array of strings in Go

[Justin Israel]

On Wed, May 1, 2019, 11:44 PM Nitish Saboo  wrote:

> Hi Jusitn,
>
> I realised I have value_len field in my arguments.I did this :
>
> func Nitish(key *C.char, value *C.char, value_len C.size_t){
>
> f.WriteString(C.GoString(key)+ ":")
> s := C.GoStringN(value, C.int(value_len))
> //fmt.Println(s)
>
> f.WriteString(s)
> f.WriteString("\n")
>
> }
> Am I doing it correctly?
>

Yea the intent was that you already had the value and value_len being
passed into your callback. So you can split the value as needed by
converting it with GoStringN()


> Thanks
>
> On Wed, May 1, 2019 at 4:40 PM Nitish Saboo 
> wrote:
>
>> Hi Justin,
>>
>> As you had suggested:
>> 
>> You could use something like this:
>> https://play.golang.org/p/fcE2UJEUFPy
>>
>> That example has the option of only converting a fixed number of bytes
>> from the C string to the Go string, if you know how big the prefix is.
>> *
>>
>>
>> I made the following changes to my function:
>>
>> func Nitish(key *C.char, value *C.char, value_len C.size_t){
>>
>> f.WriteString(C.GoString(key)+ ":")
>> value1 := C.CString(C.GoString(value))
>> value_len1 := C.size_t(value1)
>> // If we know the max size of characters
>> // that we are looking for, then we can
>> // limit how many we need to convert from
>> // the C string
>> const maxLen = 40
>> if value_len1 > maxLen {
>> value_len1 = C.size_t(maxLen)
>> }
>>
>> s := C.GoStringN(value, C.int(value_len1))
>> //fmt.Println(s)
>>
>> parts := strings.SplitN(s, " ", 2)
>> //fmt.Println(parts[0])
>> f.WriteString(parts[0])
>> f.WriteString("\n")
>>
>> }
>>
>> *value *field is pointer to strings in C.I am getting the following
>> error:
>>
>> # command-line-arguments
>> ./main.go:109:24: cannot convert value1 (type *_Ctype_char) to type
>> _Ctype_ulong
>> makefile:6: recipe for target 'main' failed
>> make: *** [main] Error 2
>>
>> I am new to cgo.I know I am making a silly mistake to fetch the value of
>> value1.Can you please point it out ?
>>
>> Thanks,
>> Nitish
>>
>> On Wed, May 1, 2019 at 3:10 PM Nitish Saboo 
>> wrote:
>>
>>> Actually, this is what is happening:
>>>
>>> func Nitish(key *C.char, value *C.char, value_len C.size_t){
>>>
>>>f.WriteString(C.GoString(key)+ ":")
>>>f.WriteString(C.GoString(value))
>>>f.WriteString("\n")
>>>
>>> }
>>>
>>> This callback method is getting called from C code multiple times.
>>>
>>> I am planning to write  the key, value pairs in a file.But the 'value' 
>>> field is getting appended with the previous value in the buffer.
>>>
>>> These are the contents that are getting written to the file.Please see the 
>>> following from bottom to top.If you see for every key field (bottom to 
>>> top), image/gif and then 'Fp5PpR2roT6uPnte47' is getting appended as I 
>>> continue writing key-values to the file.
>>>
>>> But I need only the first word from the value field.
>>>
>>> Actual:
>>>
>>> sentfileid: -   Fp5PpR2roT6uPnte47  image/gif
>>> sentmimetype: Fp5PpR2roT6uPnte47  image/gif
>>> rcvdfileid: image/gif
>>>
>>> Expected:
>>>
>>> sentfileid: -
>>> sentmimetype: Fp5PpR2roT6uPnte47
>>> rcvdfileid: image/gif
>>>
>>> Please let me know how can I achieve this ?
>>>
>>> Thanks
>>>
>>>
>>>
>>> On Wed, May 1, 2019 at 11:25 AM Nitish Saboo 
>>> wrote:
>>>
>>>> Hi,
>>>> I have this method:
>>>>
>>>> func CallBack(key *C.char, value *C.char, value_len C.size_t){
>>>>
>>>> }
>>>>
>>>> and the *value* parameter in the arguments is containing the given
>>>> string  'Fp5PpR2roT6uPnte47  image/gif'.
>>>> I want to extract only first word from the string.Let me know how can I
>>>> do this.
>>>>
>>>> I don't want  to split the string into a slice of individual characters.
>>>>
>>>> Thanks
>>>>
>>>> On Wed, May 1, 2019 at 6:27 AM Justin Israel 
>>>> wrote:
>&

Re: [go-nuts] Convert *C.char to array of strings in Go

[Justin Israel]

On Wed, May 1, 2019 at 9:40 PM Nitish Saboo 
wrote:

> Actually, this is what is happening:
>
> func Nitish(key *C.char, value *C.char, value_len C.size_t){
>
>f.WriteString(C.GoString(key)+ ":")
>f.WriteString(C.GoString(value))
>f.WriteString("\n")
>
> }
>
> This callback method is getting called from C code multiple times.
>
> I am planning to write  the key, value pairs in a file.But the 'value' field 
> is getting appended with the previous value in the buffer.
>
> These are the contents that are getting written to the file.Please see the 
> following from bottom to top.If you see for every key field (bottom to top), 
> image/gif and then 'Fp5PpR2roT6uPnte47' is getting appended as I continue 
> writing key-values to the file.
>
> But I need only the first word from the value field.
>
> Actual:
>
> sentfileid: -   Fp5PpR2roT6uPnte47  image/gif
> sentmimetype: Fp5PpR2roT6uPnte47  image/gif
> rcvdfileid: image/gif
>
> Expected:
>
> sentfileid: -
> sentmimetype: Fp5PpR2roT6uPnte47
> rcvdfileid: image/gif
>
> Please let me know how can I achieve this ?
>
> Thanks
>
>
>
> On Wed, May 1, 2019 at 11:25 AM Nitish Saboo 
> wrote:
>
>> Hi,
>> I have this method:
>>
>> func CallBack(key *C.char, value *C.char, value_len C.size_t){
>>
>> }
>>
>> and the *value* parameter in the arguments is containing the given
>> string  'Fp5PpR2roT6uPnte47  image/gif'.
>> I want to extract only first word from the string.Let me know how can I
>> do this.
>>
>> I don't want  to split the string into a slice of individual characters.
>>
>
You could use something like this:
https://play.golang.org/p/fcE2UJEUFPy

That example has the option of only converting a fixed number of bytes from
the C string to the Go string, if you know how big the prefix is.


>
>> Thanks
>>
>> On Wed, May 1, 2019 at 6:27 AM Justin Israel 
>> wrote:
>>
>>>
>>>
>>> On Wednesday, May 1, 2019 at 7:06:47 AM UTC+12, Nitish Saboo wrote:
>>>>
>>>> Apologies.I did this 'strings.Split(C.GoString(*C.char),"").
>>>> I am getting 'Incompatible types' compilation error.
>>>>
>>>
>>> Are you literally doing this?
>>> strings.Split(C.GoString(*C.char),"")
>>>
>>> Something like this should be working correctly:
>>>
>>> someCArr := getSomeCArr()
>>> chars := strings.Split(C.GoString(someCArr),"")
>>>
>>> Is your goal to split the string into a slice of individual characters?
>>> Because that is what your delim suggests.
>>>
>>>
>>>> Thanks
>>>>
>>>>
>>>> On Wed, May 1, 2019 at 12:30 AM Nitish Saboo 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to convert *C.char to array of strings in Go.
>>>>> I want to do this because I want the first word from the
>>>>> string.Strings are getting appended to *C.char and I want the first word 
>>>>> of
>>>>> the string.
>>>>> I am doing it using 'strings.Split(C.GoString(*C.char))[0]', but it is
>>>>> giving error.
>>>>> Can someone correct me here ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "golang-nuts" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to golan...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Convert *C.char to array of strings in Go

[Justin Israel]

On Wednesday, May 1, 2019 at 7:06:47 AM UTC+12, Nitish Saboo wrote:
>
> Apologies.I did this 'strings.Split(C.GoString(*C.char),"").
> I am getting 'Incompatible types' compilation error.
>

Are you literally doing this?
strings.Split(C.GoString(*C.char),"")

Something like this should be working correctly:

someCArr := getSomeCArr()
chars := strings.Split(C.GoString(someCArr),"")

Is your goal to split the string into a slice of individual characters? 
Because that is what your delim suggests.


> Thanks
>
>
> On Wed, May 1, 2019 at 12:30 AM Nitish Saboo  > wrote:
>
>> Hi,
>>
>> I want to convert *C.char to array of strings in Go.
>> I want to do this because I want the first word from the string.Strings 
>> are getting appended to *C.char and I want the first word of the string.
>> I am doing it using 'strings.Split(C.GoString(*C.char))[0]', but it is 
>> giving error.
>> Can someone correct me here ?
>>
>> Thanks
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

On Tue, Apr 30, 2019 at 6:33 PM vaastav anand 
wrote:

> I have encountered a SIGBUS with go before but I was hacking inside the
> runtime and using shared mem with mmap.
>
> goroutines are assigned IDs incrementally and each goroutine at bare
> minimum has 2.1KB stack space in go1.11 down from 2.7KB in go1.10 if I
> recall correctly. So, at the very least at that point you could have easily
> burnt through at least 7.5GB of memory. I am not sure what could happen if
> you somehow exceed the amount of memory available. Seems like that is a
> test you could write and see if launching more goroutines than that could
> fit in the size of memory could actually cause a SIGBUS.
>

The stack trace only listed 282 goroutines, which seems about right
considering the number of clients that are connected. Its about 3
goroutines per client connection, plus the other stuff in the server. I
think it just indicates that I have turned over a lot of client connections
over time.


>
> On Monday, 29 April 2019 23:25:52 UTC-7, Justin Israel wrote:
>>
>>
>>
>> On Tue, Apr 30, 2019 at 6:09 PM vaastav anand 
>> wrote:
>>
>>> Ok, so in the 2nd piece of code you posted, is some request being pushed
>>> onto some OS queue? If so, is it possible that you may be maxing the queue
>>> out and then pushing something else into it and that could cause a SIGBUS
>>> as well This seems super farfetched tho but it is hard to debug without
>>> really knowing what the application might really be doing.
>>>
>>
>> I want to say that I really appreciate you taking the time to try and
>> give me some possible ideas, even though this is a really vague problem. I
>> had only hoped someone had encountered something similar.
>>
>> So that line in the SIGBUS crash is just trying to add a subscription to
>> a message topic callback in the nats client connection:
>> https://godoc.org/github.com/nats-io/go-nats#Conn.Subscribe
>> It's pretty high level logic at my application level.
>>
>> One thing that stood out to me was that in the crash, the goroutine id
>> number was 3538668. I had to double check to confirm that the go runtime
>> just uses an insignificant increasing number. I guess it does indicate that
>> the application turned over > 3 mil goroutines by that point. I'm wondering
>> if this is caused by something in the gnatsd embedded server (
>> https://github.com/nats-io/gnatsd/tree/master/server) since most the
>> goroutines do come from that, with all the client handling going on. If we
>> are talking about something that is managing very large queues, that would
>> be the one doing so in this application.
>>
>>
>>>
>>> On Monday, 29 April 2019 22:57:40 UTC-7, Justin Israel wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Apr 30, 2019 at 5:43 PM vaastav anand 
>>>> wrote:
>>>>
>>>>> I'd be very surprised if the anonymous goroutine is the reason behind
>>>>> a SIGBUS violation.
>>>>> So, if I remember SIGBUS correctly, it means that you are issuing a
>>>>> read/write to a memory address which is not really addressable or it is
>>>>> misaligned. I think the chances of the address being misaligned are very
>>>>> low.so it really has to be a non-existent address.
>>>>> It can happen if you have try to access memory outside the region
>>>>> mmaped into your application.
>>>>> If your application has any kind of mmap or shared memory access, I
>>>>> would start there.
>>>>> In any case your best bet is to somehow reproduce the bug consistently
>>>>> and then figure out which memory access is causing the fault.
>>>>>
>>>>
>>>> My application isn't doing anything with mmap or shared memory, and my
>>>> direct and indirect dependencies don't seem to be anything like that
>>>> either. Its limited to pretty much nats.io client, gnatds embedded
>>>> server, and a thrift rpc.
>>>>
>>>> It seems so random that I doubt I could get a reproducible crash. So I
>>>> can really only try testing this on go 1.11 instead to see if any of the GC
>>>> work in 1.12 causes this.
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Monday, 29 April 2019 21:59:34 UTC-7, Justin Israel wrote:
>>>>>>
>>>>>>
>>>>>> On Thursday, November 29, 2018 at 6:22:56 PM UTC+13, Justin Israel
>>>>>>

Re: [go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

On Tue, Apr 30, 2019 at 6:09 PM vaastav anand 
wrote:

> Ok, so in the 2nd piece of code you posted, is some request being pushed
> onto some OS queue? If so, is it possible that you may be maxing the queue
> out and then pushing something else into it and that could cause a SIGBUS
> as well This seems super farfetched tho but it is hard to debug without
> really knowing what the application might really be doing.
>

I want to say that I really appreciate you taking the time to try and give
me some possible ideas, even though this is a really vague problem. I had
only hoped someone had encountered something similar.

So that line in the SIGBUS crash is just trying to add a subscription to a
message topic callback in the nats client connection:
https://godoc.org/github.com/nats-io/go-nats#Conn.Subscribe
It's pretty high level logic at my application level.

One thing that stood out to me was that in the crash, the goroutine id
number was 3538668. I had to double check to confirm that the go runtime
just uses an insignificant increasing number. I guess it does indicate that
the application turned over > 3 mil goroutines by that point. I'm wondering
if this is caused by something in the gnatsd embedded server (
https://github.com/nats-io/gnatsd/tree/master/server) since most the
goroutines do come from that, with all the client handling going on. If we
are talking about something that is managing very large queues, that would
be the one doing so in this application.


>
> On Monday, 29 April 2019 22:57:40 UTC-7, Justin Israel wrote:
>>
>>
>>
>> On Tue, Apr 30, 2019 at 5:43 PM vaastav anand 
>> wrote:
>>
>>> I'd be very surprised if the anonymous goroutine is the reason behind a
>>> SIGBUS violation.
>>> So, if I remember SIGBUS correctly, it means that you are issuing a
>>> read/write to a memory address which is not really addressable or it is
>>> misaligned. I think the chances of the address being misaligned are very
>>> low.so it really has to be a non-existent address.
>>> It can happen if you have try to access memory outside the region mmaped
>>> into your application.
>>> If your application has any kind of mmap or shared memory access, I
>>> would start there.
>>> In any case your best bet is to somehow reproduce the bug consistently
>>> and then figure out which memory access is causing the fault.
>>>
>>
>> My application isn't doing anything with mmap or shared memory, and my
>> direct and indirect dependencies don't seem to be anything like that
>> either. Its limited to pretty much nats.io client, gnatds embedded
>> server, and a thrift rpc.
>>
>> It seems so random that I doubt I could get a reproducible crash. So I
>> can really only try testing this on go 1.11 instead to see if any of the GC
>> work in 1.12 causes this.
>>
>>
>>>
>>>
>>> On Monday, 29 April 2019 21:59:34 UTC-7, Justin Israel wrote:
>>>>
>>>>
>>>> On Thursday, November 29, 2018 at 6:22:56 PM UTC+13, Justin Israel
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 29, 2018 at 6:20 PM Justin Israel 
>>>>> wrote:
>>>>>
>>>>>> On Thu, Nov 29, 2018 at 5:32 PM Ian Lance Taylor 
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Nov 28, 2018 at 7:18 PM Justin Israel 
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > I've got a service that I have been testing quite a lot over the
>>>>>>> last few days. Only after I handed it off for some testing to a 
>>>>>>> colleague,
>>>>>>> was he able to produce a SIGBUS panic that I had not seen before:
>>>>>>> >
>>>>>>> > go 1.11.2 linux/amd64
>>>>>>> >
>>>>>>> > The service does set up its own SIGINT/SIGTERM handling via the
>>>>>>> typical siginal.Notify approach. The nature of the program is that it
>>>>>>> listens on nats.io message queues, and receives requests to run
>>>>>>> tasks as sub-processes. My tests have been running between 40-200 of 
>>>>>>> these
>>>>>>> instances over the course of a few days. But this panic occurred on a
>>>>>>> completely different machine that those I had been testing...
>>>>>>> >
>>>>>>> > goroutine 1121 [runnable (scan)]:
>>>>>>> > fatal error: 

Re: [go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

On Tue, Apr 30, 2019 at 5:43 PM vaastav anand 
wrote:

> I'd be very surprised if the anonymous goroutine is the reason behind a
> SIGBUS violation.
> So, if I remember SIGBUS correctly, it means that you are issuing a
> read/write to a memory address which is not really addressable or it is
> misaligned. I think the chances of the address being misaligned are very
> low.so it really has to be a non-existent address.
> It can happen if you have try to access memory outside the region mmaped
> into your application.
> If your application has any kind of mmap or shared memory access, I would
> start there.
> In any case your best bet is to somehow reproduce the bug consistently and
> then figure out which memory access is causing the fault.
>

My application isn't doing anything with mmap or shared memory, and my
direct and indirect dependencies don't seem to be anything like that
either. Its limited to pretty much nats.io client, gnatds embedded server,
and a thrift rpc.

It seems so random that I doubt I could get a reproducible crash. So I can
really only try testing this on go 1.11 instead to see if any of the GC
work in 1.12 causes this.


>
>
> On Monday, 29 April 2019 21:59:34 UTC-7, Justin Israel wrote:
>>
>>
>> On Thursday, November 29, 2018 at 6:22:56 PM UTC+13, Justin Israel wrote:
>>>
>>>
>>>
>>> On Thu, Nov 29, 2018 at 6:20 PM Justin Israel 
>>> wrote:
>>>
>>>> On Thu, Nov 29, 2018 at 5:32 PM Ian Lance Taylor 
>>>> wrote:
>>>>
>>>>> On Wed, Nov 28, 2018 at 7:18 PM Justin Israel 
>>>>> wrote:
>>>>> >
>>>>> > I've got a service that I have been testing quite a lot over the
>>>>> last few days. Only after I handed it off for some testing to a colleague,
>>>>> was he able to produce a SIGBUS panic that I had not seen before:
>>>>> >
>>>>> > go 1.11.2 linux/amd64
>>>>> >
>>>>> > The service does set up its own SIGINT/SIGTERM handling via the
>>>>> typical siginal.Notify approach. The nature of the program is that it
>>>>> listens on nats.io message queues, and receives requests to run tasks
>>>>> as sub-processes. My tests have been running between 40-200 of these
>>>>> instances over the course of a few days. But this panic occurred on a
>>>>> completely different machine that those I had been testing...
>>>>> >
>>>>> > goroutine 1121 [runnable (scan)]:
>>>>> > fatal error: unexpected signal during runtime execution
>>>>> > panic during panic
>>>>> > [signal SIGBUS: bus error code=0x2 addr=0xfa2adc pc=0x451637]
>>>>> >
>>>>> > runtime stack:
>>>>> > runtime.throw(0xcf7fe3, 0x2a)
>>>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
>>>>> > runtime.sigpanic()
>>>>> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
>>>>> > runtime.gentraceback(0x, 0x, 0x0,
>>>>> 0xc0004baa80, 0x0, 0x0, 0x64, 0x0, 0x0, 0x0, ...)
>>>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
>>>>> > runtime.traceback1(0x, 0x, 0x0,
>>>>> 0xc0004baa80, 0x0)
>>>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:728 +0xf3
>>>>> > runtime.traceback(0x, 0x, 0x0,
>>>>> 0xc0004baa80)
>>>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:682 +0x52
>>>>> > runtime.tracebackothers(0xc00012e780)
>>>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:947 +0x187
>>>>> > runtime.dopanic_m(0xc00012e780, 0x42dcc2, 0x7f83f6ffc808, 0x1)
>>>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:805 +0x2aa
>>>>> > runtime.fatalthrow.func1()
>>>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:663 +0x5f
>>>>> > runtime.fatalthrow()
>>>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:660 +0x57
>>>>> > runtime.throw(0xcf7fe3, 0x2a)
>>>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
>>>>> > runtime.sigpanic()
>>>>> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
>>>>> > runtime.gentraceback(0x, 0x, 0x0,
>>>>>

Re: [go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

On Thursday, November 29, 2018 at 6:22:56 PM UTC+13, Justin Israel wrote:
>
>
>
> On Thu, Nov 29, 2018 at 6:20 PM Justin Israel  
> wrote:
>
>> On Thu, Nov 29, 2018 at 5:32 PM Ian Lance Taylor  wrote:
>>
>>> On Wed, Nov 28, 2018 at 7:18 PM Justin Israel  
>>> wrote:
>>> >
>>> > I've got a service that I have been testing quite a lot over the last 
>>> few days. Only after I handed it off for some testing to a colleague, was 
>>> he able to produce a SIGBUS panic that I had not seen before:
>>> >
>>> > go 1.11.2 linux/amd64
>>> >
>>> > The service does set up its own SIGINT/SIGTERM handling via the 
>>> typical siginal.Notify approach. The nature of the program is that it 
>>> listens on nats.io message queues, and receives requests to run tasks 
>>> as sub-processes. My tests have been running between 40-200 of these 
>>> instances over the course of a few days. But this panic occurred on a 
>>> completely different machine that those I had been testing...
>>> >
>>> > goroutine 1121 [runnable (scan)]:
>>> > fatal error: unexpected signal during runtime execution
>>> > panic during panic
>>> > [signal SIGBUS: bus error code=0x2 addr=0xfa2adc pc=0x451637]
>>> >
>>> > runtime stack:
>>> > runtime.throw(0xcf7fe3, 0x2a)
>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
>>> > runtime.sigpanic()
>>> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
>>> > runtime.gentraceback(0x, 0x, 0x0, 
>>> 0xc0004baa80, 0x0, 0x0, 0x64, 0x0, 0x0, 0x0, ...)
>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
>>> > runtime.traceback1(0x, 0x, 0x0, 
>>> 0xc0004baa80, 0x0)
>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:728 +0xf3
>>> > runtime.traceback(0x, 0x, 0x0, 
>>> 0xc0004baa80)
>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:682 +0x52
>>> > runtime.tracebackothers(0xc00012e780)
>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:947 +0x187
>>> > runtime.dopanic_m(0xc00012e780, 0x42dcc2, 0x7f83f6ffc808, 0x1)
>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:805 +0x2aa
>>> > runtime.fatalthrow.func1()
>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:663 +0x5f
>>> > runtime.fatalthrow()
>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:660 +0x57
>>> > runtime.throw(0xcf7fe3, 0x2a)
>>> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
>>> > runtime.sigpanic()
>>> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
>>> > runtime.gentraceback(0x, 0x, 0x0, 
>>> 0xc0004baa80, 0x0, 0x0, 0x7fff, 0x7f83f6ffcd00, 0x0, 0x0, ...)
>>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
>>> > runtime.scanstack(0xc0004baa80, 0xc31270)
>>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:786 +0x15a
>>> > runtime.scang(0xc0004baa80, 0xc31270)
>>> > /vol/apps/go/1.11.2/src/runtime/proc.go:947 +0x218
>>> > runtime.markroot.func1()
>>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:264 +0x6d
>>> > runtime.markroot(0xc31270, 0xc00047)
>>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:245 +0x309
>>> > runtime.gcDrain(0xc31270, 0x6)
>>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:882 +0x117
>>> > runtime.gcBgMarkWorker.func2()
>>> > /vol/apps/go/1.11.2/src/runtime/mgc.go:1858 +0x13f
>>> > runtime.systemstack(0x7f83f7ffeb90)
>>> > /vol/apps/go/1.11.2/src/runtime/asm_amd64.s:351 +0x66
>>> > runtime.mstart()
>>> > /vol/apps/go/1.11.2/src/runtime/proc.go:1229
>>> >
>>> > Much appreciated for any insight.
>>>
>>> Is the problem repeatable?
>>>
>>> It looks like it crashed while tracing back the stack during garbage
>>> collection, but I don't know why since the panic was evidently able to
>>> trace back the stack just fine.
>>>
>>
>>
>> Thanks for the reply. Unfortunately it was rare and never happened in my 
>> own testing of thousands of runs of this service. The colleague that saw 
>> this crash on one of his 

[go-nuts] Re: which is best thrift client pooling driver supported in golang.

[Justin Israel]

On Sunday, April 14, 2019 at 10:18:00 PM UTC+12, shrin...@gmail.com wrote:
>
> which is best thrift client pooling driver supported in golang (means 
> which is optimized according to performance )
>

Do any of them even do client pooling? I would be interested to know. I've 
had to handle my own connection pools. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [URGENT] Pass array of string between Go and C library

[Justin Israel]

On Friday, March 29, 2019 at 11:08:06 AM UTC+13, Ashutosh Baghel wrote:
>
> Hi folks,
>
> I am new to Go-Programming and  having the following requirement, I need 
> to have Array of Strings,(for example names) at my 'Go Side' .
>
> But i would get this names from my C library API which i have included in 
> my Go program.
>
> Note: I have liberty to modify the C library too, i could control the 
> return type.
>
> Please help with this.
>

Here is an example from one of my projects using cgo as a binding to a C++ 
library:

C string array to Go
https://github.com/justinfx/openimageigo/blob/master/imagespec.go#L387
 
Go string slice to C
https://github.com/justinfx/openimageigo/blob/master/imagespec.go#L402

There are other approaches besides this one. 


 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] This Makes No Sense

[Justin Israel]

On Tue, Jan 22, 2019 at 11:40 AM John  wrote:

> Dear Gophers,
>
> I have recently made a project of Connect Five. When the imput is wrong it
> will have a goroutine problem that says something about out of index, as my
> game win function depends on if the x = b and x+1 = b and so on. But if the
> imput is not 1,2 1,3 and so on, or it is over 15, 15 it will be wrong. I
> made a solution of creating a function like this:
>
> func fix() {
> if x == "1"|| x == "2"|| x == "3"|| x == "4"|| x == "5"|| x == "6"|| x ==
> "7"|| x == "8"|| x == "9"|| x == "10"|| x == "11"|| x == "12"|| x == "13"||
> x == "14"|| x == "15" {
> if y == "1"|| y == "2"|| y == "3"|| y == "4"|| y == "5"|| y == "6"|| y ==
> "7"|| y == "8"|| y == "9"|| y == "10"|| y == "11"|| y == "12"|| y == "13"||
> y == "14"|| y == "15" {
> blwi()
> }  else {
> showBoard()
> fmt.Println("Sorry you had entered wrong please enter again")
> fmt.Scanln(&x,&y)
> fix()
> }
> }
>
> It for some reason won't work. So I wonder if any of you can help me
> correct the function and simplify it. (it goes right between the imput and
> the win function.)
>

You don't have an "else" case if the x value is out of bounds; it only
handles the y value error condition.

Also, it would be a lot more simple if you were dealing with ints instead
of strings:

func fix(x, y int) {
if 1 > x || x > 15 {
handleError()
}
if 1 > y || y > 15 {
handleError()
}
proceed()
}

You could always scan them to ints and test them as ints, and then convert
to string if your app logic needs it.


>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Statically compile and link a go program with C dependencies

[Justin Israel]

On Tue, Jan 22, 2019, 8:27 AM snmed  wrote:

> Hi thanks,
>
> Ah yes, it seems that i forgot that with the static library. Now i've the
> static library under ./libs folder and i use this command:
> go build -ldflags '-L./libs -w -extldflags "-static"' -a
>
> but now i get this message:
> flag provided but not defined: -L./libs
>
> usage: link [options] main.o
>
>   -B note
>
> add an ELF NT_GNU_BUILD_ID note when using ELF
>
>   -D address
>
> set data segment address (default -1)
>
>   -E entry
>
> set entry symbol name
>
>   -H type
>
> set header type
>
>   -I linker
>
> ...rest omitted for brevity
>
> am i using the command wrong or is there a flag i'm missing?
>

That is the flag for the Go tool linker. Check out this page:
https://golang.org/cmd/cgo/

You can either define external linking options within your source or with
CGO_LDFLAGS env var



> Am Montag, 21. Januar 2019 17:40:54 UTC+1 schrieb Kurtis Rader:
>>
>> You say you "verified that all necessary libs are under /lib64." Do you
>> actually have static versions of those libraries or just dynamic versions?
>> For example, on macOS I only have dynamic (ending in .dylib) versions so it
>> isn't possible to statically link a binary that requires those libraries.
>> The "file" command should tell you whether the library is dynamic or
>> static. But in general a static lib will have a ".a" extension and dynamic
>> libs will have a ".so" or ".dylib" extension. "In general" because this is
>> platform dependent and you could be working on a platform with different
>> conventions.
>>
>> On Mon, Jan 21, 2019 at 7:50 AM snmed  wrote:
>>
>>> Hi all
>>>
>>> I try to compile and statically link the following example:
>>> https://github.com/rthornton128/goncurses/tree/master/examples/curs_menu
>>> I use this command:
>>> go build -ldflags '-w -extldflags "-static"' -a
>>>
>>> Unfortunately i get only this:
>>> /usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
>>>
>>> /usr/bin/ld: cannot find -lformw
>>>
>>> /usr/bin/ld: cannot find -lmenuw
>>>
>>> /usr/bin/ld: cannot find -lncursesw
>>>
>>> /usr/bin/ld: cannot find -lpanelw
>>>
>>> collect2: error: ld returned 1 exit status
>>>
>>>
>>>
>>> I have verified that all necessary libs are under /lib64, but the linker
>>> still complains. I'd appreciate any clues on this topic.
>>>
>>> Cheers,
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Dependency hell with Go modules

[Justin Israel]

On Fri, Jan 18, 2019, 12:36 AM Francis Chuang  wrote:

> Hey everyone,
>
> I was wondering if I can get some ideas on how to solve this dependency
> problem with Go modules. I am using Go 1.11.4 on Linux (Windows Subsystem
> for Linux to be exact).
>
> The first part of the problem is that for one of my libraries, I am
> importing github.com/hashicorp/vault/api, which is an api client to
> access Vault servers. This package is pretty thin and does not contain a
> lot of dependencies. However, the root project at
> github.com/hashicorp/vault has quite a few dependencies.
> If I delete the current go.mod and go.sum files in my library and start
> from scratch:
> - I run go mod init github.com/username/mylibrary
> - I then run go mod tidy to add missing packages to my go.mod and generate
> a go.sum
>
> Go mod imports the Vault repository at its root (
> github.com/hashicorp/vault) as expected. Unfortunately, this pulls in a
> lot of subdependencies and I have a ton of indirect dependencies in my
> go.mod and go.sum. This is not unexpected of course as this is how go
> modules work. Unfortunately, this does slow down continuous integration
> builds and is probably not great for Github and VCS hosts as each build
> pulls in all of these unneeded dependencies.
>
> The second problem is that 2 of Vault's subdependencies (not sure how
> deep) is labix.org/v2/mgo and launchpad.net/gocheck. These are bazaar
> repos, so they necessitate the installation of the bzr tool. In my library,
> I added the following to my go.mod to force it to pull from the Github
> repos:
>
> replace labix.org/v2/mgo => github.com/go-mgo/mgo
> v0.0.0-20160801194620-b6121c6199b7
>
> replace launchpad.net/gocheck => github.com/go-check/check
> v0.0.0-20180628173108-788fd7840127
>
> This works great for running tests in the username/mylibrary repo as I no
> longer need to install bzr when running my CI builds. However, if I create
> another project such as github.com/username/some-project and import
> username/mylibrary, go mod will attempt to download launchpad.net/gocheck
> and labix.org/v2/mgo from the original bazaar repos when running go test
> and other commands.These causes errors such as `go:
> labix.org/v2/mgo@v0.0.0-20140701140051-0287: bzr branch
> --use-existing-dir https://launchpad.net/mgo/v2 . in
> /go/pkg/mod/cache/vcs/ca61c737a32b1e09a0919e15375f9c2b6aa09860cc097f1333b3c3d29e040ea8:
> exec: "bzr": executable file not found in $PATH `. This is quite annoying
> and I'd like to avoid having to add those `replace` statements in the
> go.mod of projects that consume the mylibrary package. In addition,
> consumers of my library would need to install bazaar (which most people
> probably won't have installed).
>
> The 2 options I have thought of are:
> 1. Ask the Vault team to extract the api package into a separate
> repository. I am not sure how likely they would be interested in doing
> this, but I am guessing it would be quite low.
> 2. Make a copy of the api package and copy it directly into my library.
> This is something I am hoping to avoid as much as possible, because I'd
> like to use go modules to manage my dependencies.
>
> Are there any other options I've missed?
>

I'm not yet well versed in modules since I use them in a very simple way
and I vendor. But is it also supported as an option to make /api a "sub
module" by adding another go.mod at that level?
If that is possible then it is way less intrusive of a change than
splitting it into another repo.

That aside, I don't know if that would help too much in this case because I
don't think Go modules differentiates between test and non test when
collecting dependencies. If the api tests have deps, they will get
collected I think. Even the non test files have some deps anyways. Might be
nice if there were a Go modules option to skip scanning tests.

Anyways just throwing that out there until someone more informed that me
responds.


> Cheers,
> Francis
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What is the main purpose of godoc?

[Justin Israel]

On Wed, Jan 16, 2019, 11:41 AM 伊藤和也  wrote:

> I added some commets to the source file which belongs to "main" package
> but the comments doesn't appear in godoc in html but it appears when it
> belongs to other package "hello".
>

godoc is meant to provide automatically generated documentation about
exported library symbols to developers, using only the source code.

There is a github issue talking about how only the main package
documentation can be shown in godoc for commands but there is a desire to
also see exported functions from that main command
https://github.com/golang/gddo/issues/397

>From that issue, this main command shows package docs
https://godoc.org/golang.org/x/tools/cmd/godoc

And is defined in this file
https://github.com/golang/tools/blob/master/cmd/godoc/doc.go

-- 
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] what is the use of context in golang RESTful apis?

[Justin Israel]

On Mon, Jan 14, 2019, 2:23 AM Mahendra Bhoir  wrote:

> APIs I have written are for mobile applications and request cancellation
> doesn’t happen much on mobile applications.


What if the mobile client closes the app in the middle of an expensive
request?

I think I am little confused with uses of context.
>
> I found this page on Internet about context. I this will clear my
> confusions..
>
>
> https://www.sohamkamani.com/blog/golang/2018-06-17-golang-using-context-cancellation/#listening-for-the-cancellation-event
>
> On Sun, 13 Jan 2019 at 6:24 PM, Tamás Gulácsi 
> wrote:
>
>> Timing out and cancellation are the main uses of Context.
>>
>> How do you cancel processing when the client clises the connection?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> *Mahendra Bhoir.*
> *+919545688916*
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how do I make my function always run at exit in `go test`?

[Justin Israel]

On Thu, Jan 10, 2019, 9:14 PM 김용빈  wrote:

> Hi, Justin. Thank you for the response.
>
> But it didn't work for me. that means when I terminate it with Ctrl+C, it
> doesn't print CLEANUP.
>
> I am using linux (manjaro) terminal now.
>

I am not sure why it wouldn't work. I confirmed it on an Ubuntu distro.


> 2019년 1월 10일 목요일 오후 2시 41분 24초 UTC+9, Justin Israel 님의 말:
>>
>> Oh, I see. Well also adding a signal handler for SIGINT/SIGTERM also
>> works for me:
>> https://play.golang.org/p/93VmTTgE4YB
>>
>> Justin
>>
>>
>> On Thu, Jan 10, 2019 at 6:29 PM 김용빈  wrote:
>>
>>> Sorry I didn't clarify but I mean when it is killed/terminated.
>>>
>>> 2019년 1월 10일 목요일 오후 2시 24분 35초 UTC+9, 김용빈 님의 말:
>>>
>>>> I tried signal.Notify but it seems it doesn't work.
>>>>
>>>> Then I find this:
>>>> https://github.com/golang/go/issues/15553#issuecomment-217162874
>>>>
>>>> So what should I do to make my function always run at exit in test?
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how do I make my function always run at exit in `go test`?

[Justin Israel]

Oh, I see. Well also adding a signal handler for SIGINT/SIGTERM also works
for me:
https://play.golang.org/p/93VmTTgE4YB

Justin


On Thu, Jan 10, 2019 at 6:29 PM 김용빈  wrote:

> Sorry I didn't clarify but I mean when it is killed/terminated.
>
> 2019년 1월 10일 목요일 오후 2시 24분 35초 UTC+9, 김용빈 님의 말:
>
>> I tried signal.Notify but it seems it doesn't work.
>>
>> Then I find this:
>> https://github.com/golang/go/issues/15553#issuecomment-217162874
>>
>> So what should I do to make my function always run at exit in test?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Temporarily allow unused variables

[Justin Israel]

On Thu, Jan 10, 2019 at 6:04 PM 김용빈  wrote:

> package main
>
> func unused(x interface{}) {}
>
> func main() {
> a := 1
> unused(a)
> }
>

The function isn't even required here. Assigning to underscore will prevent
the error:

func main() {
a := 1
_ = a
}


>
> 2012년 3월 7일 수요일 오후 8시 32분 19초 UTC+9, Elazar Leibovich 님의 말:
>
>> I sometimes have a very strange error, which I can't understand its
>> source.
>>
>> One of my techniques for finding it, is isolate the problem to a very
>> small case, by commenting out pieces of the code, and noticing which pieces
>> of codes cause the problem.
>>
>> Go really helps me with it due to the short compile run cycles, but it is
>> very difficult to use this technique without leaving unused variables.
>>
>> Is there a flag that enables you to temporarily compile without this
>> warning?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] how do I make my function always run at exit in `go test`?

[Justin Israel]

On Thu, Jan 10, 2019 at 6:24 PM 김용빈  wrote:

> I tried signal.Notify but it seems it doesn't work.
>
> Then I find this:
> https://github.com/golang/go/issues/15553#issuecomment-217162874
>
> So what should I do to make my function always run at exit in test?
>

A custom TestMain() is a good way to add setup and teardown functionality
around the entire test process:
https://golang.org/pkg/testing/#hdr-Main

It won't help you if you kill the "go test" process though. In that case
you would need a SIGTERM handler via signal.Notify()

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Can I say that a pointer is a memory address where a variable is?

[Justin Israel]

On Thu, Jan 10, 2019, 7:53 AM Justin Israel  wrote:

>
>
> On Thu, Jan 10, 2019, 7:43 AM 伊藤和也  wrote:
>
>> Can I say that a pointer is a memory address where a variable is?
>>
>
> A pointer is a memory address to a value (data in memory).
>
> A "variable" is just a name/label to *something*. That something could be
> a pointer or it could be a value. That is, you can have a pointer that
> points to the value of another pointer which points to the value of an int
> in memory (**x)
>

And I just now saw this was double posted. I don't want to fork two
conversations ;)


>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Can I say that a pointer is a memory address where a variable is?

[Justin Israel]

On Thu, Jan 10, 2019, 7:43 AM 伊藤和也  wrote:

> Can I say that a pointer is a memory address where a variable is?
>

A pointer is a memory address to a value (data in memory).

A "variable" is just a name/label to *something*. That something could be a
pointer or it could be a value. That is, you can have a pointer that points
to the value of another pointer which points to the value of an int in
memory (**x)


> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [Ann] create full github release from command line, not just a tag

[Justin Israel]

I've been using goreleaser  so far, to publish
github releases with cross-compiled assets. I am not familiar with the
wireframe project though. Do they share some overlap?

On Mon, Jan 7, 2019 at 5:50 PM Tong Sun  wrote:

> IIRC, github used to create full releases each time you push a git
> tag, but now it only creates tags, not releases. After pushing a git tag,
> people need to go to GitHub UI, find created tag, press "Edit tag", change
> nothing and press "Publish release", then they'll get full release and
> event.
>
> But I much prefer to be able to create full Release  with title,
> description, or assets from the command line.
> So I was wondering if there is any way to "Publish release" from a command
> line.
> and it turns out that now creating releases are via API:
> https://developer.github.com/v3/repos/releases/#create-a-release
>
>
> So I added the feature to easygen/wireframe, to "Publish release" from
> command line. The details can be found at
>
> https://github.com/go-easygen/wireframe#github-create-release---create-release-in-github
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] missing fmt.Error(...interface{})

[Justin Israel]

On Sun, Dec 30, 2018 at 9:26 PM Liam Breck  wrote:

> Justin, see docs for fmt.Print(...interface{})
>

Ah true. I forgot about the whitespace formatting versions. I stand
corrected that a fmt.Error would actually perform formatting and would be
consistent with Sprint and Print. My only guess now is that it *could* have
been in the errors package if the errors package had been created at the
same time as the fmt package, but it was added later after fmt.Errorf
already existed.


>
> On Sun, Dec 30, 2018, 12:15 AM Justin Israel  wrote:
>
>>
>>
>> On Sun, Dec 30, 2018, 7:24 PM Liam Breck  wrote:
>>
>>> What's the rationale for omission of:
>>>   fmt.Error(a ...interface{}) error
>>>
>>
>> What does it mean for this function to accept a variable number of
>> arguments when there is no formatting or printing implied by the name of
>> the function?
>>
>>
>>> Given that other fmt functions come in that variety?
>>>
>>
>> The other functions in the fmt package do some kind of formatting with
>> the arguments (newlines, format string)
>>
>>
>>> I realize it can be achieved like this, but so can fmt.Errorf
>>>   errors.New(fmt.Sprint(...))
>>>
>>> Would a proposal to add it be entertained?
>>>
>>
>> I have a feeling it wouldn't be accepted since it would just duplicate
>> the functionality of errors.New() and it doesn't provide any extra
>> formatting functionality.
>>
>>
>>> Happy New Year to all :-)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Using of packages

[Justin Israel]

On Sun, Dec 30, 2018, 5:02 PM  wrote:

> I'm a beginner in Golang and quite confusing about using packages in a
> program. For example, every non simple software has a bunch of classes and
> interfaces or utility classes which are usually lokated in different
> packages in the same program. So using them in Java fo example makes no
> diffculty at all, but it seems Golang makes this diffculty then it comes
> for using packages.
>

Can you clarify what you mean by "difficulty" here? The following examples
of accessing imported packages by their namespace doesn't seem to qualify
as difficult so maybe some details of your experience have been left out?
If the package namespace are what you meant as bering undesirable, would
you prefer a situation like C where you include a dependency and a Foo
struct is accessible in the global namespace as Foo? What happens then if
two dependencies provide Foo structs?

When classes(structures, methods) are placed in different packages we
> should import them and then using them with the package name like
> "utility.MyStructure" or "model.DemoStruct" - is not it an overhead using
> every time package names when referencing structures of methods from
> different packages of the same program?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] missing fmt.Error(...interface{})

[Justin Israel]

On Sun, Dec 30, 2018, 7:24 PM Liam Breck  wrote:

> What's the rationale for omission of:
>   fmt.Error(a ...interface{}) error
>

What does it mean for this function to accept a variable number of
arguments when there is no formatting or printing implied by the name of
the function?


> Given that other fmt functions come in that variety?
>

The other functions in the fmt package do some kind of formatting with the
arguments (newlines, format string)


> I realize it can be achieved like this, but so can fmt.Errorf
>   errors.New(fmt.Sprint(...))
>
> Would a proposal to add it be entertained?
>

I have a feeling it wouldn't be accepted since it would just duplicate the
functionality of errors.New() and it doesn't provide any extra formatting
functionality.


> Happy New Year to all :-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Closure, recursion and higher-order functions

[Justin Israel]

On Sun, Dec 30, 2018 at 5:07 AM 伊藤和也  wrote:

> How often do you use closure, recursion and higher-order functions?
>

I use closuresquite often, and recusion here and there as needed.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go modules go build fails - normal go build with $GOPATH set works

[Justin Israel]

On Wed, Dec 26, 2018, 3:07 PM Sam Whited  wrote:

> This sounds like the version is mismatched. Is the gopath version a newer
> commit (with api changes) than the tag being picked in the go.mod file? I
> have this quite frequently with golang.org/x/text which was last released
> some time ago and have to use a replace directive to get a more up to date
> version and fix the build
>

If I remember with Glide one could have it load the dependencies from the
local GOPATH to avoid download. It would be kind of neat if until GOPATH
were completely gone, that the go tool could have an option to init the
Go.mod from the GOPATH. It would be similar to how it knows how to convert
Glide and other dep management systems to module.
Just a thought.


> —Sam
>
>
> On December 25, 2018 8:10:08 PM UTC, robr...@gmail.com wrote:
> >I have been testing out the new go modules feature.  Our application
> >compiles/installs without problems using the normal $GOPATH way and
> >have
> >been using this for a while now.   trying go modules produces the same
> >error over and over
> >
> >Steps I followed
> >
> >unset $GOPATH just to be safe
> >
> >1) git clone github project
> >
> >2) go mod init
> >
> >3) go build
> >
> >
> >and after some output where I can see it getting all the dependencies I
> >
> >keep getting
> >
> >random.go:14:10: assignment mismatch: 2 variables but 1 values
> >random.go:29:10: assignment mismatch: 2 variables but 1 values
> >
> >Again reverting back to the normal $GOPATH way everything compiles fine
> >and
> >I can start the binary.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go get can not download git submodule

[Justin Israel]

On Tue, Dec 25, 2018, 4:17 PM xiang liu  wrote:

> Thanks a lot!
>
> It seems go 1.11  does not support git submodule.   go 1.10 works fine.
>

Oh, I wonder if they ended up getting rid of it as alluded to in that
issue. Or if it's hidden behind a mode controlled by an env var.


> Justin Israel  于2018年12月25日周二 上午2:47写道：
>
>>
>>
>> On Tue, Dec 25, 2018, 5:59 AM xiang liu  wrote:
>>
>>> Hi:
>>>
>>> Now i have go package  have another c++ submodule,
>>> https://github.com/notedit/media-server-go
>>>
>>> I wan to make it go gettable, but go get can not check the c++ submodule.
>>>
>>> Any way to fix this?
>>>
>>
>> I see this discussed here:
>> https://github.com/golang/go/issues/7764
>>
>> Although it appears the only support for submodules was added to the
>> vendor folder support. I am not sure what that really means in practice for
>> this problem.
>>
>>
>>> Thanks.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go get can not download git submodule

[Justin Israel]

On Tue, Dec 25, 2018, 5:59 AM xiang liu  wrote:

> Hi:
>
> Now i have go package  have another c++ submodule,
> https://github.com/notedit/media-server-go
>
> I wan to make it go gettable, but go get can not check the c++ submodule.
>
> Any way to fix this?
>

I see this discussed here:
https://github.com/golang/go/issues/7764

Although it appears the only support for submodules was added to the vendor
folder support. I am not sure what that really means in practice for this
problem.


> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Channels: selecting the last element

[Justin Israel]

On Wed, Dec 19, 2018, 5:31 AM Chris Burkert  wrote:

> Hello Ian, all,
> yes, the workers generate multiple results. I was able to use your
> proposal with the waiting goroutine which closes the channel. Unfortunately
> my initial minimal example was not so minimal. It is a little more
> complicated, as I have multiple "result" channels with different types and
> I don't know how many values I get. So I can't just range over one channel
> but instead use select with the ok from "val, ok := <-channel" to count the
> closed channels which finally ends the loop. Below is what I came up with
> (using Johns approach to run it multiple times) and it seems to be
> deterministic.
> Many thanks!
> PS: with buffered channels I have to disable closed channels with "channel
> = nil" to make it work.
>

You should need to disable the closed channel by setting it nil regardless
of it being buffered or not. Depending on how you actually end up sending
results back on multiple channels it could still be a bug if you end up
selecting on the closed channel multiple times and think you are done
instead of reading from another channel with results.


> package main
>
> import (
> "fmt"
> "sync"
> )
>
> func do(fc chan<- int, rc chan<- string) {
> fc <- 42
> fc <- 43
> rc <- "foo"
> }
>
> func main() {
> w := 4
> r := 10
> n := 0
> for i := 0; i < r; i++ {
> n = n + run(w)
> }
> fmt.Printf("Got %d, expected %d\n", n, 3*w*r)
> }
>
> func run(worker int) int {
> fc := make(chan int)
> rc := make(chan string)
> var wg sync.WaitGroup
> wg.Add(worker)
> for i := 0; i < worker; i++ {
> go func() {
> defer wg.Done()
> do(fc, rc)
> }()
> }
> go func() {
> wg.Wait()
> close(fc)
> close(rc)
> }()
> n := 0
> closed := 0
> for closed < 2 {
> select {
> case _, ok := <-fc:
> if ok {
> n++
> } else {
> closed++
> }
> case _, ok := <-rc:
> if ok {
> n++
> } else {
> closed++
> }
> }
> }
> return n
> }
>
> Am Di., 18. Dez. 2018 um 15:50 Uhr schrieb Ian Lance Taylor <
> i...@golang.org>:
>
>> On Tue, Dec 18, 2018 at 5:35 AM Chris Burkert 
>> wrote:
>> >
>> > I have a couple of goroutines sending multiple results over a channel -
>> a simple fan-in. They signal the completion on a done channel. Main selects
>> on the results and done channel in parallel. As the select is random main
>> sometimes misses to select the last result. What would be the idiomatic way
>> to prevent this and completely drain the result channel?
>> >
>> > Here is a minmal example which sometimes prints one 0 but should always
>> print two of them:
>> >
>> > package main
>> >
>> > import (
>> > "fmt"
>> > )
>> >
>> > func do(rc chan<- int, dc chan<- bool) {
>> > rc <- 0
>> > dc <- true
>> > }
>> >
>> > func main() {
>> > worker := 2
>> > rc := make(chan int, worker)
>> > done := 0
>> > dc := make(chan bool, worker)
>> > for i := 0; i < worker; i++ {
>> > go do(rc, dc)
>> > }
>> > for done < worker {
>> > select {
>> > case <-dc:
>> > done++
>> > case r := <-rc:
>> > fmt.Println(r)
>> > }
>> > }
>> > }
>>
>>
>> I assume the workers can generate multiple results, as otherwise the
>> done marker seems pointless.  In general the simplest way to signal
>> completion on a channel is to call close.  The simplest way to call
>> close on a fan-in is to have another goroutine that waits for the
>> other goroutines and closes the channel.  That might look like
>>
>> package main
>>
>> import (
>> "fmt"
>> "sync"
>> )
>>
>> func do(rc chan<- int) {
>> rc <- 0
>> }
>>
>> func main() {
>> worker := 2
>> rc := make(chan int, worker)
>> var wg sync.WaitGroup
>> wg.Add(worker)
>> for i := 0; i < worker; i++ {
>> go func() {
>> defer wg.Done()
>> do(rc)
>> }()
>> }
>> go func() {
>> wg.Wait()
>> close(rc)
>> }()
>> for r := range rc {
>> fmt.Println(r)
>> }
>> }
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsub

Re: [go-nuts] Is it possible to go test files priority

[Justin Israel]

On Tue, Dec 18, 2018, 8:01 AM  wrote:

> Hi all, Is it possible to set priority to go test files. As per my
> observation go tool runs test cases in alphabetical order of file name. Now
> I want to run files with custom priority. Is it possible?
>

I don't have a direct answer but I feel if it were possible at all it would
involve a custom TestMain:
https://golang.org/pkg/testing/#hdr-Main
Although it doesn't look like enough is exposed to allow you to define the
test order.

Out of curiosity, why is it important to control the order of tests? The
question implies that the tests are interdependant, which seems
undesirable.

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [ANN] pyg: python 3.7.1 bindings for Go

[Justin Israel]

Thanks for sharing this. I've been using github.com/sbinet/go-python on a
few tasks. Is this generally the same thing, but for py 3.x?

On Sun, Dec 16, 2018, 6:30 PM Jason E. Aten  wrote:

> `pyg` is a library for embedding python 3.7.1 in Go.
>
> Very little of `pyg` is mine. I consolidated a bunch of github
> repositories providing python 2/3 bindings, previously named gopy and
> originated by user qur and enhanced by users halturin and limetext.
>
> Unfornately there is another gopy repo at
> https://github.com/go-python/gopy with a slightly different purpose and a
> very different lineage. To distinguish the two, I've renamed my modern
> update to `pyg`.  The opposite of the lightweight approach in starlight (
> https://github.com/starlight-go/starlight), the name seems appropriate.
>
> https://github.com/glycerine/pyg
>
> Enjoy.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go offline development recommendations

[Justin Israel]

On Thu, Dec 13, 2018 at 11:19 AM snmed  wrote:

> Hi thepudds
>
> Thanks for you Reply. Indeed vendoring is an Option, but I'm not sure how
> long that will be supported. I think i've read about a blog post which says
> vendoring will be remove from the go tools, but i'm not sure if this still
> on the Roadmap of the go Team.
> I will have a look into the walkthrough you've posted and see if i get
> some new ideas out of it.
>

Even if vendoring somehow goes away, it seems like you could achieve the
same goal by manually populating the module cache location as you deem fit,
and pointing GOPROXY=file:///...   (instead of Athens)


>
> Cheers
>
> Am Mittwoch, 12. Dezember 2018 22:35:36 UTC+1 schrieb thepud...@gmail.com:
>>
>> Hi Sandro,
>>
>> Vendoring is another approach that can work here.
>>
>> In a pre-modules world, vendoring is fairly well known.
>>
>> In a modules world, vendoring is still an option. For example, you can
>> see this FAQ here that touches on using 'go mod vendor' with modules:
>>
>>
>> https://github.com/golang/go/wiki/Modules#how-do-i-use-vendoring-with-modules-is-vendoring-going-away
>>
>> An alternative approach in a modules world is to use the module cache. It
>> can end up with similar benefits as traditional vendoring (and in some ways
>> ends up with a higher fidelity copy), but uses a different technique. This
>> approach is explained as a "Go Modules by Example" walkthrough here:
>>
>>
>> https://github.com/go-modules-by-example/index/blob/master/012_modvendor/README.md
>>
>> Best,
>> thepudds
>>
>> On Wednesday, December 12, 2018 at 3:52:58 PM UTC-5, snmed wrote:
>>>
>>> Thank you for you reply,
>>>
>>> yes i have already read about that project, but as far as I see, there
>>> is no offline loading implemented.
>>> But I'm sure it would be doable with some customisation. I wondering if
>>> there is another approach for an offline scenario.
>>>
>>> Some other ideas or suggestions?
>>>
>>> Thanks in advance
>>> Sandro
>>>
>>> Am Mittwoch, 12. Dezember 2018 21:04:07 UTC+1 schrieb Burak Serdar:

 On Wed, Dec 12, 2018 at 1:00 PM snmed  wrote:
 >
 > Hi all
 >
 > Our customer demands an offline development environment with no
 internet connection, is there any best practices to handle package download
 and project setup for such an use case? And how would the new go modules
 fit in in such an environment?

 Somebody just mentioned this today. It looks like it is doing what
 you're asking for:

 https://github.com/gomods/athens


 >
 > Any advise will be most appreciated.
 >
 > Cheers Sandro
 >
 > --
 > You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 > To unsubscribe from this group and stop receiving emails from it,
 send an email to golang-nuts...@googlegroups.com.
 > For more options, visit https://groups.google.com/d/optout.

>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Starlight - run python inside Go to extend your applications - easily

[Justin Israel]

On Mon, Dec 10, 2018, 9:39 PM  wrote:

>
>
> On Friday, December 7, 2018 at 9:05:02 PM UTC+1, Nate Finch wrote:
>>
>> I’d like to announce starlight -
>> https://github.com/starlight-go/starlight.
>>
>>
>> Starlight wraps google’s Go implementation of the starlark python dialect
>>  (most notably found in the Bazel
>> build tool). Starlight makes it super easy for users to extend your
>> application by writing simple python scripts that interact seamlessly with
>> your current Go code… with no boilerplate on your part.
>>
>
> Do you think it is suitable for porting python applications?
> Usually you go through cgo like this
> https://www.datadoghq.com/blog/engineering/cgo-and-python/ it could be an
> interesting alternative.
>
>

The documentation for Starlark says it is a subset of python, originally
targeted at being a configuration language for Bazel. So it wouldn't be
complete enough to straight port full Python applications, unless you
really backed alot of it with Go code. The cgo approach gives you full
access to the CPython API and to embed an interpreter.

Starlight does sound interesting though for allowing specific extension
scripts for a Go application.


>> *Parser by google*
>>
>> The parser and runner are maintained by google’s bazel team, which write
>> starlark-go. Starlight is a wrapper on top of that, which makes it so much
>> easier to use starlark-go. The problem with the starlark-go API is that it
>> is more built to be a used as configuration, so it assumes you want to get
>> information out of starlark and into Go. It’s actually pretty difficult to
>> get Go information into a starlark script…. unless you use starlight.
>>
>> *Easy two-way interaction*
>>
>>
>> Starlight has adapters that use reflection to automatically make any Go
>> value usable in a starlark script. Passing an *http.Request into a
>> starlark script? Sure, you can do name = r.URL.Query()["name"][0] in the
>> python without any work on your part.
>>
>> Starlight is built to *just work* the way you hope it’ll work. You can
>> access any Go methods or fields, basic types get converted back and forth
>> seamlessly… and even though it uses reflection, it’s not as slow as you’d
>> think. A basic benchmark wrapping a couple values and running a starlark
>> script to work with them runs in a tiny fraction of a millisecond.
>>
>> The great thing is that the changes made by the python code are reflected
>> in your go objects, just as if it had been written in Go. So, set a field
>> on a pointer to a struct? Your go code will see the change, no additional
>> work needed.
>>
>> *100% Safe*
>>
>>
>> The great thing about starlark and starlight is that the scripts are 100%
>> safe to run. By default they have no access to other parts of your project
>> or system - they can’t write to disk or connect to the internet. The only
>> access they have to the outside is what you give them. Because of this,
>> it’s safe to run untrusted scripts (as long as you’re not giving them
>> dangerous functions to run, like os.RemoveAll). But at the same time, if
>> you’re only running trusted scripts, you can give them whatever you want (
>> http.Get? Sure, why not?)
>>
>> *Caching*
>>
>>
>> In a production environment, you probably want to only read a script once
>> and parse it once. You can do that with starlight’s Cache. This cache
>> takes a list of directories to look in for scripts, which it will read and
>> parse on-demand, and then store the parsed object in memory for later use.
>> It also uses a cache for any load() calls the scripts use to load
>> scripts they depend on.
>>
>> *Work Ongoing*
>>
>>
>> Starlight is still a work in progress, so don’t expect the API to be
>> perfectly stable quite yet. But it’s getting pretty close, and there
>> shouldn’t be any earth shattering changes, but definitely pin your imports.
>> Right now it’s more about finding corner cases where the starlight wrappers
>> don’t work quite like you’d expect, and supporting the last few things that
>> aren’t implemented yet (like channels).
>>
>>
>> *Example*
>>
>>
>> Here's a simple example of how easy it is to extend the behavior of your
>> application with a python script.  Just pass starlight whatever go values
>> you want your python script to act on, and any changes the python code
>> makes get reflected in your go code.
>>
>>
>> package main
>>
>> import (
>> "fmt"
>> "log"
>> "time"
>>
>> "github.com/starlight-go/starlight"
>> )
>>
>> // Starlight makes it easy to get values in and out of your starlark
>> scripts.
>> // Just pass in pointers to values that you want changed, or callback
>> functions
>> // that propagate data.
>>
>> // In theory, starlight also returns all global variables set by the
>> script, but
>> // in real programs, you need well-defined outputs for your calling code
>> to act on.
>> // If I write a script that creates a variable called nate_is_awesome =
>> 1337 ... your
>> // 

Re: [go-nuts] recursion plus goroutines

[Justin Israel]

On Sat, Dec 1, 2018, 10:43 AM Alex Dvoretskiy 
wrote:

> Here is recursion. I d'ont know when its end.
>

Do you mean that you want to wait for all 3 goroutines to complete?

var wg sync.WaitGroup
wg.Add(3)

go func() {
inOrderTr(root)
wg.Done()
}()

go func() {
preOrderTr(root)
wg.Done()
}()

go func() {
postOrderTr(root)
wg.Done()
}()

wg.Wait()


> On Friday, November 30, 2018 at 12:04:42 PM UTC-8, Burak Serdar wrote:
>>
>> On Fri, Nov 30, 2018 at 12:44 PM Alex Dvoretskiy
>>  wrote:
>> >
>> > Hi,
>> >
>> > How should I modify my code if I want to run three recursive functions
>> in parallel?
>> >
>> > go inOrderTr(root)
>> > go preOrderTr(root)
>> > go postOrderTr(root)
>>
>> Those three are mutually independent, and the tree is read-only, so
>> you don't need any synchronization between the three. You might use a
>> sync.WaitGroup to wait for all of them to end.
>> >
>> > https://play.golang.org/p/n-QLR7V0H49
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to golang-nuts...@googlegroups.com.
>>
> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

On Thu, Nov 29, 2018 at 6:20 PM Justin Israel 
wrote:

> On Thu, Nov 29, 2018 at 5:32 PM Ian Lance Taylor  wrote:
>
>> On Wed, Nov 28, 2018 at 7:18 PM Justin Israel 
>> wrote:
>> >
>> > I've got a service that I have been testing quite a lot over the last
>> few days. Only after I handed it off for some testing to a colleague, was
>> he able to produce a SIGBUS panic that I had not seen before:
>> >
>> > go 1.11.2 linux/amd64
>> >
>> > The service does set up its own SIGINT/SIGTERM handling via the typical
>> siginal.Notify approach. The nature of the program is that it listens on
>> nats.io message queues, and receives requests to run tasks as
>> sub-processes. My tests have been running between 40-200 of these instances
>> over the course of a few days. But this panic occurred on a completely
>> different machine that those I had been testing...
>> >
>> > goroutine 1121 [runnable (scan)]:
>> > fatal error: unexpected signal during runtime execution
>> > panic during panic
>> > [signal SIGBUS: bus error code=0x2 addr=0xfa2adc pc=0x451637]
>> >
>> > runtime stack:
>> > runtime.throw(0xcf7fe3, 0x2a)
>> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
>> > runtime.sigpanic()
>> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
>> > runtime.gentraceback(0x, 0x, 0x0,
>> 0xc0004baa80, 0x0, 0x0, 0x64, 0x0, 0x0, 0x0, ...)
>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
>> > runtime.traceback1(0x, 0x, 0x0,
>> 0xc0004baa80, 0x0)
>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:728 +0xf3
>> > runtime.traceback(0x, 0x, 0x0,
>> 0xc0004baa80)
>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:682 +0x52
>> > runtime.tracebackothers(0xc00012e780)
>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:947 +0x187
>> > runtime.dopanic_m(0xc00012e780, 0x42dcc2, 0x7f83f6ffc808, 0x1)
>> > /vol/apps/go/1.11.2/src/runtime/panic.go:805 +0x2aa
>> > runtime.fatalthrow.func1()
>> > /vol/apps/go/1.11.2/src/runtime/panic.go:663 +0x5f
>> > runtime.fatalthrow()
>> > /vol/apps/go/1.11.2/src/runtime/panic.go:660 +0x57
>> > runtime.throw(0xcf7fe3, 0x2a)
>> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
>> > runtime.sigpanic()
>> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
>> > runtime.gentraceback(0x, 0x, 0x0,
>> 0xc0004baa80, 0x0, 0x0, 0x7fff, 0x7f83f6ffcd00, 0x0, 0x0, ...)
>> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
>> > runtime.scanstack(0xc0004baa80, 0xc31270)
>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:786 +0x15a
>> > runtime.scang(0xc0004baa80, 0xc31270)
>> > /vol/apps/go/1.11.2/src/runtime/proc.go:947 +0x218
>> > runtime.markroot.func1()
>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:264 +0x6d
>> > runtime.markroot(0xc31270, 0xc00047)
>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:245 +0x309
>> > runtime.gcDrain(0xc31270, 0x6)
>> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:882 +0x117
>> > runtime.gcBgMarkWorker.func2()
>> > /vol/apps/go/1.11.2/src/runtime/mgc.go:1858 +0x13f
>> > runtime.systemstack(0x7f83f7ffeb90)
>> > /vol/apps/go/1.11.2/src/runtime/asm_amd64.s:351 +0x66
>> > runtime.mstart()
>> > /vol/apps/go/1.11.2/src/runtime/proc.go:1229
>> >
>> > Much appreciated for any insight.
>>
>> Is the problem repeatable?
>>
>> It looks like it crashed while tracing back the stack during garbage
>> collection, but I don't know why since the panic was evidently able to
>> trace back the stack just fine.
>>
>
>
> Thanks for the reply. Unfortunately it was rare and never happened in my
> own testing of thousands of runs of this service. The colleague that saw
> this crash on one of his workstations was not able to repro it after
> attempting another run of the workflow. I wasn't really sure how to debug
> this particular crash since it was in the gc and I have seen a "panic
> during panic" before. Thought it might jump out at someone.
>

Oops. I meant that I *haven't* seen a "panic during panic" before :-)


>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

On Thu, Nov 29, 2018 at 5:32 PM Ian Lance Taylor  wrote:

> On Wed, Nov 28, 2018 at 7:18 PM Justin Israel 
> wrote:
> >
> > I've got a service that I have been testing quite a lot over the last
> few days. Only after I handed it off for some testing to a colleague, was
> he able to produce a SIGBUS panic that I had not seen before:
> >
> > go 1.11.2 linux/amd64
> >
> > The service does set up its own SIGINT/SIGTERM handling via the typical
> siginal.Notify approach. The nature of the program is that it listens on
> nats.io message queues, and receives requests to run tasks as
> sub-processes. My tests have been running between 40-200 of these instances
> over the course of a few days. But this panic occurred on a completely
> different machine that those I had been testing...
> >
> > goroutine 1121 [runnable (scan)]:
> > fatal error: unexpected signal during runtime execution
> > panic during panic
> > [signal SIGBUS: bus error code=0x2 addr=0xfa2adc pc=0x451637]
> >
> > runtime stack:
> > runtime.throw(0xcf7fe3, 0x2a)
> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
> > runtime.sigpanic()
> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
> > runtime.gentraceback(0x, 0x, 0x0,
> 0xc0004baa80, 0x0, 0x0, 0x64, 0x0, 0x0, 0x0, ...)
> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
> > runtime.traceback1(0x, 0x, 0x0,
> 0xc0004baa80, 0x0)
> > /vol/apps/go/1.11.2/src/runtime/traceback.go:728 +0xf3
> > runtime.traceback(0x, 0x, 0x0,
> 0xc0004baa80)
> > /vol/apps/go/1.11.2/src/runtime/traceback.go:682 +0x52
> > runtime.tracebackothers(0xc00012e780)
> > /vol/apps/go/1.11.2/src/runtime/traceback.go:947 +0x187
> > runtime.dopanic_m(0xc00012e780, 0x42dcc2, 0x7f83f6ffc808, 0x1)
> > /vol/apps/go/1.11.2/src/runtime/panic.go:805 +0x2aa
> > runtime.fatalthrow.func1()
> > /vol/apps/go/1.11.2/src/runtime/panic.go:663 +0x5f
> > runtime.fatalthrow()
> > /vol/apps/go/1.11.2/src/runtime/panic.go:660 +0x57
> > runtime.throw(0xcf7fe3, 0x2a)
> > /vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
> > runtime.sigpanic()
> > /vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
> > runtime.gentraceback(0x, 0x, 0x0,
> 0xc0004baa80, 0x0, 0x0, 0x7fff, 0x7f83f6ffcd00, 0x0, 0x0, ...)
> > /vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
> > runtime.scanstack(0xc0004baa80, 0xc31270)
> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:786 +0x15a
> > runtime.scang(0xc0004baa80, 0xc31270)
> > /vol/apps/go/1.11.2/src/runtime/proc.go:947 +0x218
> > runtime.markroot.func1()
> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:264 +0x6d
> > runtime.markroot(0xc31270, 0xc00047)
> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:245 +0x309
> > runtime.gcDrain(0xc31270, 0x6)
> > /vol/apps/go/1.11.2/src/runtime/mgcmark.go:882 +0x117
> > runtime.gcBgMarkWorker.func2()
> > /vol/apps/go/1.11.2/src/runtime/mgc.go:1858 +0x13f
> > runtime.systemstack(0x7f83f7ffeb90)
> > /vol/apps/go/1.11.2/src/runtime/asm_amd64.s:351 +0x66
> > runtime.mstart()
> > /vol/apps/go/1.11.2/src/runtime/proc.go:1229
> >
> > Much appreciated for any insight.
>
> Is the problem repeatable?
>
> It looks like it crashed while tracing back the stack during garbage
> collection, but I don't know why since the panic was evidently able to
> trace back the stack just fine.
>


Thanks for the reply. Unfortunately it was rare and never happened in my
own testing of thousands of runs of this service. The colleague that saw
this crash on one of his workstations was not able to repro it after
attempting another run of the workflow. I wasn't really sure how to debug
this particular crash since it was in the gc and I have seen a "panic
during panic" before. Thought it might jump out at someone.


> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Cause of SIGBUS panic in gc?

[Justin Israel]

I've got a service that I have been testing quite a lot over the last few
days. Only after I handed it off for some testing to a colleague, was he
able to produce a SIGBUS panic that I had not seen before:

go 1.11.2 linux/amd64

The service does set up its own SIGINT/SIGTERM handling via the typical
siginal.Notify approach. The nature of the program is that it listens on
nats.io message queues, and receives requests to run tasks as
sub-processes. My tests have been running between 40-200 of these instances
over the course of a few days. But this panic occurred on a completely
different machine that those I had been testing...

goroutine 1121 [runnable (scan)]:
fatal error: unexpected signal during runtime execution
panic during panic
[signal SIGBUS: bus error code=0x2 addr=0xfa2adc pc=0x451637]

runtime stack:
runtime.throw(0xcf7fe3, 0x2a)
/vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
runtime.sigpanic()
/vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
runtime.gentraceback(0x, 0x, 0x0,
0xc0004baa80, 0x0, 0x0, 0x64, 0x0, 0x0, 0x0, ...)
/vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
runtime.traceback1(0x, 0x, 0x0,
0xc0004baa80, 0x0)
/vol/apps/go/1.11.2/src/runtime/traceback.go:728 +0xf3
runtime.traceback(0x, 0x, 0x0, 0xc0004baa80)
/vol/apps/go/1.11.2/src/runtime/traceback.go:682 +0x52
runtime.tracebackothers(0xc00012e780)
/vol/apps/go/1.11.2/src/runtime/traceback.go:947 +0x187
runtime.dopanic_m(0xc00012e780, 0x42dcc2, 0x7f83f6ffc808, 0x1)
/vol/apps/go/1.11.2/src/runtime/panic.go:805 +0x2aa
runtime.fatalthrow.func1()
/vol/apps/go/1.11.2/src/runtime/panic.go:663 +0x5f
runtime.fatalthrow()
/vol/apps/go/1.11.2/src/runtime/panic.go:660 +0x57
runtime.throw(0xcf7fe3, 0x2a)
/vol/apps/go/1.11.2/src/runtime/panic.go:608 +0x72
runtime.sigpanic()
/vol/apps/go/1.11.2/src/runtime/signal_unix.go:374 +0x2f2
runtime.gentraceback(0x, 0x, 0x0,
0xc0004baa80, 0x0, 0x0, 0x7fff, 0x7f83f6ffcd00, 0x0, 0x0, ...)
/vol/apps/go/1.11.2/src/runtime/traceback.go:190 +0x377
runtime.scanstack(0xc0004baa80, 0xc31270)
/vol/apps/go/1.11.2/src/runtime/mgcmark.go:786 +0x15a
runtime.scang(0xc0004baa80, 0xc31270)
/vol/apps/go/1.11.2/src/runtime/proc.go:947 +0x218
runtime.markroot.func1()
/vol/apps/go/1.11.2/src/runtime/mgcmark.go:264 +0x6d
runtime.markroot(0xc31270, 0xc00047)
/vol/apps/go/1.11.2/src/runtime/mgcmark.go:245 +0x309
runtime.gcDrain(0xc31270, 0x6)
/vol/apps/go/1.11.2/src/runtime/mgcmark.go:882 +0x117
runtime.gcBgMarkWorker.func2()
/vol/apps/go/1.11.2/src/runtime/mgc.go:1858 +0x13f
runtime.systemstack(0x7f83f7ffeb90)
/vol/apps/go/1.11.2/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
/vol/apps/go/1.11.2/src/runtime/proc.go:1229

Much appreciated for any insight.

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] gosnip: run small snippets of Go code from the command line

[Justin Israel]

On Sun, Nov 25, 2018, 11:06 AM Ben Hoyt  wrote:

> I just finished a little tool called "gosnip" that allows you to run
> little snippets of Go code from the command line:
>
> https://github.com/benhoyt/gosnip
>
> To use it, just type something like:
>
> $ gosnip 'fmt.Println("Hello world")'
> Hello world
>
> gosnip automatically adds (standard library) imports, rolls into into a
> complete program, and uses "go run" to run it.
>
> To quote the "Why?" section in the README: I made gosnip because when
> coding in Go I often want to try little snippets of code to see what they
> do, for example, "how does format string %6.3f work again?" I could use the
> Go playground, but it's nice to be able to use a one-line command. Also, I
> often develop while offline on my bus commute, so don't have access to the
> online Go playground (yes, I know it's possible to run the Go playground
> locally).
>
> It was very handy to have go/parser available in the standard library, and
> even nicer that it automatically provides the list of unresolved names --
> which I use to know what to import.
>
> "go run" isn't particularly fast for this use case, as it spawns the go
> compiler, linker, and then the program itself. Seems to take about 250ms on
> my macOS machine (and it's probably slower on Windows, as os/exec is
> somewhat slower on Windows).
>
> If anyone knows a better way to run Go source, let me know. As much as I
> like writing interpreters, it'd be a big job to write a Go compiler just
> for this. In the meantime, 250ms will have to do.
>

I've actually been using gomacro for this (testing a quick bit of syntax).
I have to import the std libs that I need (auto import would be nice if
it's not ambiguous), but it has nice output evaluation and state.

https://github.com/cosmos72/gomacro


> Feedback welcome!
>
> -Ben
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: go language sensitive editor?

[Justin Israel]

On Wed, Nov 21, 2018, 12:37 PM  wrote:

> I recommend Sublime Text with the GoSublime
>  addon package. There's a free
> trial for Sublime Text .
>

I started with this, and have also tried AnacondaGo for Sublime, but went
back to GoSublime. Now I use a combination of Goland for existing projects
(most the time) and Sublime when I need to quickly edit something
(infrequent) .


>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go modules and vendor: redundant features?

[Justin Israel]

On Sat, Nov 17, 2018 at 6:15 PM Justin Israel 
wrote:

>
>
> On Sat, Nov 17, 2018 at 6:06 PM Robert Engels 
> wrote:
>
>> I think that is incorrect. The vendoring was a way to ensure certain
>> dependencies remained constant. The modules should eliminate that, barring
>> deletion of the source repo.
>>
>
> Even with modules, vendoring is still useful for situations where external
> network access is limited and the internal network does not yet have an
> Athena proxy to serve dependencies. Also, before modules keeping
> dependencies constant was achievable with glide, godeps, dep, etc,
> regarless of whether you choose to vendor it or not. But yes, vendoring
> made it so that your build would prefer that location over your GOPATH, and
> the module system provides a versioned cache now. I still like the idea of
> being able to vendor if that makes the most sense.
>

s/Athena/Athens/


>
>>
>> On Nov 16, 2018, at 11:00 PM, Justin Israel 
>> wrote:
>>
>>
>>
>> On Sat, Nov 17, 2018 at 5:34 PM Henry  wrote:
>>
>>> Hi,
>>>
>>> It seems to me that go modules and vendor attempt to solve the same
>>> problem. I wonder whether we should just choose one and scrap the other, or
>>> find a way to consolidate them under a single unified feature.
>>>
>>
>> Comparing "modules" and "vendoring" have only the most minor overlap. The
>> module system is a built-in way to describe and track dependencies. This
>> ultimately bakes down into a go.sum 'lock' file describing exactly what you
>> are using at a moment in time. The lock file can then be consulted in the
>> future to download those exact dependencies and reproduce the same build as
>> when it was originally written. Vendoring is a way to store dependency code
>> within the repo to avoid relying on downloading it again. It may or may not
>> store any information about the versions and it may or may not have been
>> done manually. The vendoring feature in the go module command is just a way
>> to store the dependencies from the go.sum solution within the repo and
>> avoid the download step.
>>
>> Why do you feel they are mutually exclusive? What if someone wants the
>> dependency management of modules and being able to avoid GOPATH, while also
>> wanting to avoid relying on a download process?
>>
>>
>>> I am a bit concerned with the direction Go is going. People keep adding
>>> stuffs into Go and later find themselves unable to remove existing features
>>> due to the backward compatibility promise. Go 1.11 is a different beast
>>> than Go 1.0, and is significantly more complex.
>>>
>>> I think Go2 is an opportunity to learn from Go1, and to start from a
>>> clean slate by scraping and consolidating features. Go2 needs to be simpler
>>> than Go1.11
>>>
>>> Henry
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go modules and vendor: redundant features?

[Justin Israel]

On Sat, Nov 17, 2018 at 6:06 PM Robert Engels  wrote:

> I think that is incorrect. The vendoring was a way to ensure certain
> dependencies remained constant. The modules should eliminate that, barring
> deletion of the source repo.
>

Even with modules, vendoring is still useful for situations where external
network access is limited and the internal network does not yet have an
Athena proxy to serve dependencies. Also, before modules keeping
dependencies constant was achievable with glide, godeps, dep, etc,
regarless of whether you choose to vendor it or not. But yes, vendoring
made it so that your build would prefer that location over your GOPATH, and
the module system provides a versioned cache now. I still like the idea of
being able to vendor if that makes the most sense.


>
> On Nov 16, 2018, at 11:00 PM, Justin Israel 
> wrote:
>
>
>
> On Sat, Nov 17, 2018 at 5:34 PM Henry  wrote:
>
>> Hi,
>>
>> It seems to me that go modules and vendor attempt to solve the same
>> problem. I wonder whether we should just choose one and scrap the other, or
>> find a way to consolidate them under a single unified feature.
>>
>
> Comparing "modules" and "vendoring" have only the most minor overlap. The
> module system is a built-in way to describe and track dependencies. This
> ultimately bakes down into a go.sum 'lock' file describing exactly what you
> are using at a moment in time. The lock file can then be consulted in the
> future to download those exact dependencies and reproduce the same build as
> when it was originally written. Vendoring is a way to store dependency code
> within the repo to avoid relying on downloading it again. It may or may not
> store any information about the versions and it may or may not have been
> done manually. The vendoring feature in the go module command is just a way
> to store the dependencies from the go.sum solution within the repo and
> avoid the download step.
>
> Why do you feel they are mutually exclusive? What if someone wants the
> dependency management of modules and being able to avoid GOPATH, while also
> wanting to avoid relying on a download process?
>
>
>> I am a bit concerned with the direction Go is going. People keep adding
>> stuffs into Go and later find themselves unable to remove existing features
>> due to the backward compatibility promise. Go 1.11 is a different beast
>> than Go 1.0, and is significantly more complex.
>>
>> I think Go2 is an opportunity to learn from Go1, and to start from a
>> clean slate by scraping and consolidating features. Go2 needs to be simpler
>> than Go1.11
>>
>> Henry
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go modules and vendor: redundant features?

[Justin Israel]

On Sat, Nov 17, 2018 at 5:34 PM Henry  wrote:

> Hi,
>
> It seems to me that go modules and vendor attempt to solve the same
> problem. I wonder whether we should just choose one and scrap the other, or
> find a way to consolidate them under a single unified feature.
>

Comparing "modules" and "vendoring" have only the most minor overlap. The
module system is a built-in way to describe and track dependencies. This
ultimately bakes down into a go.sum 'lock' file describing exactly what you
are using at a moment in time. The lock file can then be consulted in the
future to download those exact dependencies and reproduce the same build as
when it was originally written. Vendoring is a way to store dependency code
within the repo to avoid relying on downloading it again. It may or may not
store any information about the versions and it may or may not have been
done manually. The vendoring feature in the go module command is just a way
to store the dependencies from the go.sum solution within the repo and
avoid the download step.

Why do you feel they are mutually exclusive? What if someone wants the
dependency management of modules and being able to avoid GOPATH, while also
wanting to avoid relying on a download process?


> I am a bit concerned with the direction Go is going. People keep adding
> stuffs into Go and later find themselves unable to remove existing features
> due to the backward compatibility promise. Go 1.11 is a different beast
> than Go 1.0, and is significantly more complex.
>
> I think Go2 is an opportunity to learn from Go1, and to start from a clean
> slate by scraping and consolidating features. Go2 needs to be simpler than
> Go1.11
>
> Henry
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] help(rest call failed)

[Justin Israel]

On Tue, Nov 13, 2018, 5:23 AM  wrote:

> I just want to send a rest call with golang, but it failed, the error
> message :  {"header":{"code":201,"desc":"param data not exist"}} .(but
> when I send rest request with postman ,it success)
> the code as follow
>
> 1 package main
>   2
>   3 import(
>   4 "net/http"
>   5 "fmt"
>   6 "strings"
>   7 "io/ioutil"
>   8 )
>   9 func check(err error){
>  10 if err !=nil{
>  11 panic(err)
>  12 }
>  13 }
>  14 func main(){
>  15 url:="http://ip:8080/api";
>  16 method:="POST"
>  17 da:="base64 encoded string"
>  18 data:=strings.NewReader(da)
>

This isn't an encoded form. And your server is complaining that it can't
find a "data" form field. Use url.Values to encode a form:
https://golang.org/pkg/net/url/#Values.Encode

var vals url.Values
vals.Add("data", "form data")
data:=strings.NewReader(vals.Encode())

 19 req,err:=http.NewRequest(method,url,data)
>  20 check(err)
>  21
>  req.Header.Set("Content_Type","application/x-www-form-urlencoded")
>


Should be "Content-Type"

 22 client:=&http.Client{}
>  23 resp,err:=client.Do(req)
>  24 check(err)
>  25 defer resp.Body.Close()
>  26 result,err:=ioutil.ReadAll(resp.Body)
>  27 check(err)
>  28 fmt.Println(string(result[:]))
>  29 }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re-building module with -buildmode=c-shared doesn't cache well

[Justin Israel]

(cross-posted from r/golang

)

I've noticed a great improvement with caching when I build modules that
haven't changed. The execution of "go build" is quite fast, and it is nice
in a larger build script when I can always call the go build and just rely
on the go tool to know when it needs to rebuild.


But I have a particular target in a project that is built as a c-shared
library so that it can be used in a python library. The build command looks
like:


go build -o module.so -buildmode-c-shared domain.com/project/dep


But in this form, the go tool always goes through a bunch of expensive cgo
compiling even if nothing has changed. Is there any way around this to get
back to the cached behaviour of calling this without the buildmode flag? My
build system could be told about the source inputs in order to hash them,
but this is an external dependency that is in the "go.mod" and pulled by
the go tool. The only idea that partially works right now is if I have the
build system hash the go.sum, go.mod, and the vendor/
domain.com/project/dep/**. That works for both normal and
"replaced"-with-dev-location go.mod situations. But it wouldn't know to
rebuild again if it were using a module "replace" with the dev location and
a dependency outside of the tareget module changed (which obviously the go
compiler would know about). Maybe that is an acceptable edge case. But it
would be nice to know if the current caching behaviour is expected in the
go tool when using buildmode=c-shared?


Much appreciated!

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Correct way to solve slice of interface type problem

[Justin Israel]

On Wed, Oct 31, 2018 at 1:32 PM robert engels  wrote:

> I have argued for a runtime/built-in to do this - it is so common…. (if
> doing “kind of OO” in Go)
>

I would love to have the ability to do it with built-in support, but I feel
like it would go against the goals of not wanting to hide complexity. It
wouldn't be "free" to do it (as far as I know) and I doubt the Go
maintainers want it to hide the copy into the new slice. My 2 cents.


>
>
> On Oct 30, 2018, at 7:30 PM, Justin Israel  wrote:
>
>
>
> On Wed, Oct 31, 2018 at 11:21 AM  wrote:
>
>> Hello, everyone.
>> Consider following code:
>>
>> package main
>> import "fmt"
>>
>> type implementation struct {
>> d []int}
>>
>> func (impl *implementation) getData() interface{} {
>> return impl.d}
>>
>> type phase struct{}
>>
>> type data interface {
>> getData() interface{}}
>>
>> func MakeIntDataPhase() *phase {
>> return &phase{}}
>>
>> func (p *phase) run(population []data) []data {
>> return nil}
>>
>> func main() {
>> var population []implementation
>> MyPhase := MakeIntDataPhase()
>> fmt.Println(MyPhase.run(population))
>> }
>>
>>
>> When running following code in playground I got following error: 
>> prog.go:30:25: cannot use population (type []implementation) as type []data 
>> in argument to MyPhase.run
>>
>> If I understand correctly it is because slice of interface type cannot be 
>> converted by the compiler to concrete type.
>>
>>
>> What is correct way in golang to implement functionality that is presented 
>> in the example?
>>
>> When method argument defined using a slice of some interface, how I can pass 
>> it a slice of a concrete type that implements the interface?
>>
>>
> You would end up needing to just do
>
> func (p *phase) run(population {}interface) []data
>
> and then type assert the {}interface into []implementation
> There isn't a way to directly pass a slice of concrete type to a function
> that accepts a slice of interface, unless you first do this:
>
> iface := make([]data, len(population))
> for i, p := range population {
> iface[i] = p
> }
> MyPhase.run(iface)
>
> Justin
>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Correct way to solve slice of interface type problem

[Justin Israel]

On Wed, Oct 31, 2018 at 11:21 AM  wrote:

> Hello, everyone.
> Consider following code:
>
> package main
> import "fmt"
>
> type implementation struct {
> d []int}
>
> func (impl *implementation) getData() interface{} {
> return impl.d}
>
> type phase struct{}
>
> type data interface {
> getData() interface{}}
>
> func MakeIntDataPhase() *phase {
> return &phase{}}
>
> func (p *phase) run(population []data) []data {
> return nil}
>
> func main() {
> var population []implementation
> MyPhase := MakeIntDataPhase()
> fmt.Println(MyPhase.run(population))
> }
>
>
> When running following code in playground I got following error: 
> prog.go:30:25: cannot use population (type []implementation) as type []data 
> in argument to MyPhase.run
>
> If I understand correctly it is because slice of interface type cannot be 
> converted by the compiler to concrete type.
>
>
> What is correct way in golang to implement functionality that is presented in 
> the example?
>
> When method argument defined using a slice of some interface, how I can pass 
> it a slice of a concrete type that implements the interface?
>
>
You would end up needing to just do

func (p *phase) run(population {}interface) []data

and then type assert the {}interface into []implementation
There isn't a way to directly pass a slice of concrete type to a function
that accepts a slice of interface, unless you first do this:

iface := make([]data, len(population))
for i, p := range population {
iface[i] = p
}
MyPhase.run(iface)

Justin

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Variadic functions using ...interface{}

[Justin Israel]

I was getting an error trying to pass a []string to this elasticsearch API
ctor:
https://github.com/olivere/elastic/blob/v6.2.11/search_queries_terms_set.go#L26

func NewTermsSetQuery(name string, values ...interface{}) *TermsSetQuery

And it was failing with "cannot use vals (type []string) as type
[]interface {}".
See: https://play.golang.org/p/l5pzqyugM29

When I figured out how to satisfy the signature, it reminded me of the
issue others have had with assigning slices of concrete values to slices of
interface values. I get that you can't directly do that because the memory
layout is different. But I was confused as to why this variadic example
can't work as had expected? I guess the variadic ... instead of seeing
[]interface{} in the signature threw off my expectations. I don't really
know whats going on under the hood when a variadic function handles
do(mySlice...).  Is it exactly the same issue as a direct argument mapping
between []string and []interface{} function parameters?

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go modules and replace

[Justin Israel]

On Sat, Oct 20, 2018, 11:34 AM Mark Volkmann 
wrote:

>
> On Oct 19, 2018, at 4:48 PM, Justin Israel  wrote:
>
>
>
> On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann 
> wrote:
>
>> I have a simple demo application that wants to use a package that is on
>> my local file system.
>> The code for the package is in /Users/Mark/foo/bar.
>> This directory contains the file bar.go which contains:
>>
>> package bar
>> import "fmt"
>> func Hello() {
>> fmt.Println("Hello from bar!")
>> }
>>
>> It also contains the file go.mod which just contains:
>>
>> module bar
>>
>> The demo application in another directory imports this as "foo/bar" in
>> the file main.go.
>> It has a go.mod file that contains the following:
>>
>> module demo
>> replace foo/bar => /Users/Mark/foo/bar
>>
>> When I enter "go run main.go" in the directory of the demo code I get
>> build demo: cannot find module for path foo/bar
>>
>> Is there something wrong with my use of the "replace" directive?
>>
>
> Base in this:
>
> https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive
>
> my understanding is that the path you are replacing has to first be
> identified as a locatable import path, as opposed to being able to define
> the location of a previously invalid path.
>
>
> What is a “locatable import path”?
>

What I mean is an import path that the Go tool could locate. If you are
outside a GOPATH then that would mean either a vcs pattern, something
relative to the module, or something in the module cache (assumptions so
far).


> If your top level module is called "demo" and it contains a nested packed
> "bar",
>
>
> bar is not a nested package. It’s in a completely different directory
> structure from the demo app.
>

So then it's even more to my point, where on its own the go tool would have
no idea where to find "foo/bar"


> then in the go.mod I would assume it to be called "demo/bar". If you
> forget about it actually currently existing under the "demo" location on
> disk, with the absence of GOPATH or a fully qualified vcs import path, how
> else would the module system find "bar" if not relative to "demo"?
>
>
> That’s what I thought the “replace” directive could do. I supplied the
> full path there.
>

And that's the part where I am under the impression that the Go tool first
wants to know where it would find "foo/bar" before it will replace it with
another location. It's not a vcs and it's not relative to the module you
are building.


> I'm still learning about Go modules so I could be totally wrong.
>
>>
>> None of this code is under the directory pointed to by GOPATH because I'm
>> trying to use Go modules for everything in this demo.
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go modules and replace

[Justin Israel]

On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann 
wrote:

> I have a simple demo application that wants to use a package that is on my
> local file system.
> The code for the package is in /Users/Mark/foo/bar.
> This directory contains the file bar.go which contains:
>
> package bar
> import "fmt"
> func Hello() {
> fmt.Println("Hello from bar!")
> }
>
> It also contains the file go.mod which just contains:
>
> module bar
>
> The demo application in another directory imports this as "foo/bar" in
> the file main.go.
> It has a go.mod file that contains the following:
>
> module demo
> replace foo/bar => /Users/Mark/foo/bar
>
> When I enter "go run main.go" in the directory of the demo code I get
> build demo: cannot find module for path foo/bar
>
> Is there something wrong with my use of the "replace" directive?
>

Base in this:
https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive

my understanding is that the path you are replacing has to first be
identified as a locatable import path, as opposed to being able to define
the location of a previously invalid path.

If your top level module is called "demo" and it contains a nested packed
"bar", then in the go.mod I would assume it to be called "demo/bar". If you
forget about it actually currently existing under the "demo" location on
disk, with the absence of GOPATH or a fully qualified vcs import path, how
else would the module system find "bar" if not relative to "demo"?

I'm still learning about Go modules so I could be totally wrong.



> None of this code is under the directory pointed to by GOPATH because I'm
> trying to use Go modules for everything in this demo.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Temporary files in go

[Justin Israel]

On Fri, Oct 12, 2018, 2:31 PM Ian Lance Taylor  wrote:

> On Thu, Oct 11, 2018 at 4:48 PM, Greg Saylor 
> wrote:
> >
> > In other programming languages (this is specific to Linux/Unix systems),
> in
> > the past to ensure security in the even of a program crash, we would do
> > something like:
> >
> > 1. Create a temporary file and squirrel away the file handle
> > 2. Unlink the temporary file by name
> > 3. Various functions would write stuff to the file
> > 4. If the programs completes to some successful state, create a hardlink
> to
> > the file handle with the final filename
> >
> > I'm finding this very difficult to do in Go, as there does not seem to
> be a
> > way to do #4.  And this is a very important consideration for this piece
> of
> > the system.
> >
> > For example, os.Rename takes filenames as the old/new filename.
> >
> > I figured looking in that code might reveal something lower level that
> could
> > be used, which lead me to syscal_linuxl.Rename()
> >
> > That lead me to syscall_linux.RenameAt()
> >
> > Which led me to zsyscall_linux_amd64.go.
> >
> > .. at this point I got pretty lost on how to do any of this.  _AT_FDCWD
> and
> > fishing around in what appears to be some pretty low-level internals of
> > Go...
> >
> > Is there some way to achieve this or a way that can ensure these files
> are
> > always removed if the program is kill -9'd, terminates from a panic, etc.
>
> Can you show us how you do this in C?
>

Probably linkat(2) ?

http://man7.org/linux/man-pages/man2/linkat.2.html


> I expect that will point toward how to do it in Go.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Importing local package

[Justin Israel]

On Wed, Oct 10, 2018, 5:49 AM D Whelp  wrote:

> Hello all,
>
> Super new to Golang, loving the hell out of it, but I am running into a
> small issue.  I have a small application that I am working through.  I can
> import my models using `import ("/dojo/pkg/models")` in main.go just fine.
> Now I am trying to build a `cli` package and I cannot import it.  Every
> time I do, I cannot use the function `QueryESXi()` that is in my esxi.go
> Attached is my layout.  I have tried "./cmd/cli" and "dojo/cmd/cli"... but
> none are working. What am I missing?  Thanks in advance.
>

There is a bit of missing info here. Assuming you are using a GOPATH like
$GOPATH/src/dojo or you have a go.mod properly configured and are outside
your GOPATH, then an import like "dojo/cmd/cli" could work. I would
recommend sticking to absolute import paths and not using relative dot
imports. What is the package name in your esxi.go file? The fact that it is
in a cmd location implies that it would be a "main" package and thus not
intended to be imported by another package.


>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: modules: Using vendored transitive dependencies of primary dependency

[Justin Israel]

Since I never found an answer to this, and I am still stumped, I have 
cross-posted 
here 
<https://stackoverflow.com/questions/52600915/go-modules-using-vendored-transitive-dependencies-of-primary-dependency>
.
Justin


On Thursday, September 6, 2018 at 9:34:36 AM UTC+12, Justin Israel wrote:
>
>
>
> On Wednesday, September 5, 2018 at 6:31:03 PM UTC+12, Justin Israel wrote:
>>
>> I've been having some great results converting some of my internal 
>> projects from glide to go modules, but I am looking at a specific workflow 
>> right now that is confusing me. Hoping to get some clarification...
>>
>> Project 'foo' has its dependencies vendored via "go mod vendor". This 
>> works great when building that project internally since a non-go developer 
>> can clone the project and build it, with no external proxy access needed to 
>> download dependencies. 
>>
>> Now I am trying to allow project 'bar' to build a tool provided by 'foo'. 
>> The go.mod file only contains:
>>
>> module internal.com/project/bar
>>
>> require internal.com/project/foo v0.0.0-...
>>
>> What I am seeing is that foo and all of its dependencies will be clones 
>> from their origins, and my go.sum file is updated with all of the transient 
>> dependencies. But what I really want is to only fetch 'foo' from my 
>> internal network and to have it use the vendored dependencies. 
>>
>> Is this even possible? The "-mod=vendor" flag was very useful when 
>> building project "foo" directly. But it doesn't seem to apply here because 
>> project "bar" doesn't want to vendor. It wants to get the one primary 
>> dependency and that is it.
>>
>> Justin
>>
>>
> I tried to solve this temporarily with a combination of using glide to 
> pull just the primary dependency, and then to use "go build -mod=vendor" to 
> pick up the vendored dependencies. But glide won't flatten the vendor 
> directory properly, to bring the nested vendor to the top level. So I have 
> had to resort to a hack where I manually clone the primary dependency, move 
> its nested vendor to the root, and the move that primary dependency into 
> vendor/ as well. 
>
> Would love to cleanly solve this through the module system.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] using 'go function_call()' inside Go program

[Justin Israel]

On Sun, Sep 30, 2018 at 3:47 PM Hemant Singh  wrote:

> I have a question.  I have changed the open goping.go code to return error
> from functions.
>
> The following function is implemented in a .goping.go file.
>
> func ping(config *Config, address, name string, pattern *regexp.Regexp)
> error {  }
>
> Another function shown below, in the same .go file, calls 'go ping()'.  As
> one can see above, the ping function returns an error.  How do I change the
> 'go ping()' code below to grab the error returned from calling ping()?  I
> could also use a URL to where a description exists for using 'go
> function_call' inside a Go program.
>
> func ping_main(address string) error {
> go ping(config, address, "DstIP", LATENCY_PATTERN)
> }
>

In this current form, it is not possible to grab the error because you are
not waiting on the ping() to finish when you call it asynchronously in a
goroutine. If you need the error, the most obvious thing to do is to call
it in a blocking fashion:

func ping_main(address string) error {
return ping(config, address, "DstIP", LATENCY_PATTERN)
}

​

But if you need to call it in a non-blocking way, then you have to arrange
a way to receive the error value later once the ping is complete. Wrapping
the existing ping() function might be a way to go:

func ping_main(address string) <-chan error {
err := make(chan error, 1)
go func() {
err <- ping(config, address, "DstIP", LATENCY_PATTERN)
}()
return err
}

​

This means the ping still runs in a non-blocking way, but will report the
return value when it is complete.


>
> Best,
>
> Hemant
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] having issues setting up favicon.ico on my site

[Justin Israel]

On Fri, Sep 28, 2018, 6:18 AM Grey White  wrote:

> Good day guys,
> I need help with attaching favicon.ico to my site
> that is my folder structure.
> i really can't tel what am doing wrong
>
> [image: Capture.PNG]
> func main() {
>http.HandleFunc("/favicon", faviconHandler)
>log.Fatal(http.ListenAndServe(":8080", nil))
> }
>
> func faviconHandler(w http.ResponseWriter, r *http.Request) {
> http.ServeFile(w, r, "/crm-app/favicon.ico")
> }
>

Are your deployed assets actually stored in /cram-app? Otherwise maybe you
want the path to be relative to where the binary is running:
crm-app/favicon.ico


> my links in index.html
> 
>
>
>
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Updating a struct from goroutines

[Justin Israel]

On Wed, Sep 26, 2018, 6:38 AM  wrote:

> Hi, new gopher here.
> I considered asking this on SO, but they (rightly, IMO) discourage "Is
> this a good way to do it?" questions.  Hope that's ok here.
>
> By way of background, I'm porting a largish industrial control application
> from Python to Go.  The Python version uses multiple processes (about a
> dozen in all) communicating over ZeroMQ.  One process, called the
> statehouse,  controls access to the application state.  The others obtain
> copies and send updates over REQ sockets.  The data are serialized as JSON
> objects that map nicely to Python dicts.
>
> Since there's no direct equivalent in Go to a Python dict that can hold a
> mixture of arbitrary types,  I need to use a struct to represent the state.
> No problem with that but I've been struggling with how to allow the
> goroutines that will replace the Python processes to read and write to the
> state struct with concurrency safety.
>
> This morning I came up with an idea to send functions over a channel to
> the main routine.  I put together a little test program and after some
> refinements it looks promising.  Some rough benchmarking shows I can get a
> million updates in under 1 second on a 2012 vintage Mac Mini.  That's more
> than good enough for this application where the time between events is
> usually more than 100 milliseconds.
>
> Here's the link to my test on the Go Playground:
> https://play.golang.org/p/8iWvwnqBNYl . It runs there except that the
> elapsed time comes back 0 and the prints from the second goroutine don't
> show up. I think that's got something to do with the artificial clock in
> the playground.  It works fine when I run it locally.  I've pasted the code
> at the bottom of this message.
>
> So my big questions are:
>
>- Is this actually concurrency safe as long as all goroutines only use
>the update mechanism to read and write?
>- Is there a more idiomatic way to do it that performs as well or
>better?
>- What are the potential problems if this is scaled to a couple dozen
>goroutines?
>- Does it sacrifice clarity for cleverness? (not that it's all that
>clever, mind you, but I need to think about handing this off to my client's
>staff.)
>
>
> Thanks very much,
> Mike Ellis
>
> code follows ...
>
> package main
>
> import (
>  "fmt"
>  "time"
> )
>
>
> // Big defines the application's state variables
> type Big struct {
>  A int
>  B string
>  /* and hundreds more */
> }
>
>
> // update is a struct that contains a function that updates a Big and
> // a signal channel to be closed when the update is complete. An update
> // may also be used to obtain a current copy of a Big by coding f to
> // do so.  (See gopher2 below.)
> type update struct {
>  done chan struct{}
>  ffunc(*Big)
> }
>
>
> // upch is a channel from which main receives updates.
> var upch = make(chan update)
>
>
> // gopher defines a function that updates a member of a Big and
> // sends updates via upch. After each send it waits for main to
> // close the update's done channel.
> func gopher() {
>  var newA int
>  f := func(b *Big) {
>  b.A = newA
>  }
>  for i := 0; i < n; i++ {
>  newA = i
>  u := update{make(chan struct{}), f}
>  upch <- u
>  <-u.done
>  }
> }
>
>
> // gopher2 uses an update struct to obtain a current copy of a Big
> // every 100 microseconds.
> func gopher2() {
>  var copied Big
>  f := func(b *Big) {
>  copied = *b
>  }
>  for {
>  time.Sleep(100 * time.Microsecond)
>  u := update{make(chan struct{}), f}
>  upch <- u
>  <-u.done
>  fmt.Println(copied)
>  }
> }
>
>
> // main creates a Big, launches gopher and waits on the update channel.
> When
> // an update, u, arrives it runs u.f and then closes u.done.
> func main() {
>  var state = Big{-1, "foo"}
>  fmt.Println(state) // --> {-1, "foo"}
>  go gopher()
>  go gopher2()
>  start := time.Now()
>  for i := 0; i < n; i++ {
>  u := <-upch
>  u.f(&state)
>  close(u.done)
>  }
>  perUpdate := time.Since(start).Nanoseconds() / int64(n) // Note: always
> 0 in playground
>  fmt.Printf("%d updates, %d ns per update.\n", n, perUpdate)
>  fmt.Println(state) // --> {n-1, "foo"}
> }
>
>
> var n = 1000 // number of updates to send and receive
>
>
One aspect that may not be safe is that you copy the struct to use in
another goroutine. This is a shallow copy. If you only have immutable basic
types like ints and strings then this would be safe. But if your struct has
slices, maps, or pointers then you run the risk of mutating shared
references between two copies of the main struct.


>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this g

[go-nuts] Re: When using 'go mod vendor' why are there lots of files missing?

[Justin Israel]

On Tuesday, September 18, 2018 at 8:58:01 AM UTC+12, Frits van Bommel wrote:
>
>  According to the help text that's the intended behavior:
>
> usage: go mod vendor [-v]
>>
>> Vendor resets the main module's vendor directory to include all packages
>> needed to build and test all the main module's packages.
>> It does not include test code for vendored packages.
>>
>> The -v flag causes vendor to print the names of vendored
>> modules and packages to standard error.
>>
>

This just bit me, because it isn't copying required cc source files from a 
parent directory of the package, leading to the cgo library not being able 
to build:

library
cpp/
source1.cpp
go/
lib.go
inc.cpp

For better or worse, inc.cpp has had '#include "../cpp/source1.cpp"' in it, 
and it has been working under glide as the whole project gets vendored. But 
now under "go mod vendor" it throws away the non-go files leading to 
missing cpp files. Is this intended behaviour, expecting that the Go source 
should have everything it needs as siblings or children in the directory 
structure?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Help tracking down module dependencies

[Justin Israel]

On Mon, Sep 24, 2018 at 4:31 PM  wrote:

> Hi Justin,
>
> I'm not sure where that gotest.tools is coming from in your particular
> build, and not sure of the root cause of the issue with your http proxy.
>
> However, one thing you could try is a 'replace' directive to try to get
> gotest.tools directly from github. I don't know if that will help your
> particular situation, but you could try adding something like the following
> to the end of your go.mod file:
>
>replace gotest.tools => github.com/gotestyourself/gotest.tools
> v2.1.0+incompatible
>

This fixed my problem. Thanks! My proxy is perfectly happy with the
github.com domain.
I still don't know where that original dependency was coming from, and it
would have been really cool if "go mod" could have told me some more
verbose output, since it obviously knows.


>
> There is some chance that might work around the issue with your http
> proxy.  (And if that starts to complain instead about a failed replace, you
> could also try adding an explicit 'require gotest.tools
> v2.1.0+incompatible' or maybe even 'require gotest.tools v0.0.0' in your
> go.mod file).
>
> --thepudds
>
> On Sunday, September 23, 2018 at 7:59:36 PM UTC-4, Justin Israel wrote:
>>
>> I'm converting one of my internal projects from glide to a module, after
>> having done two other conversions. But I am hitting a problem that I can't
>> yet solve.
>>
>> $ GO111MODULE=on go mod tidy -v
>>
>> Fetching https://gotest.tools?go-get=1
>> https fetch failed: Get https://gotest.tools?go-get=1: Forbidden
>> go: gotest.tools@v2.1.0+incompatible: unrecognized import path
>> "gotest.tools" (https fetch failed: Get https://gotest.tools?go-get=1:
>> Forbidden)
>> go: error loading module requirements
>>
>> My http proxy won't let me access this, and I can't find usage of it
>> anywhere in my own codebase or in the immediate dependencies (or even my
>> $GOPATH). The mod subcommand isn't being very specific about where this
>> dependency is coming from (even with the graph command). Any pointers would
>> be greatly appreciated. The dependency didn't show up in my glide.lock
>> originally.
>>
>> My module requirements are:
>>
>> require (
>>  github.com/boltdb/bolt v1.3.1
>>  github.com/elazarl/go-bindata-assetfs v1.0.0
>>  github.com/gorilla/context v1.1.1
>>  github.com/gorilla/mux v1.3.0
>>  github.com/pborman/uuid v1.2.0
>>  golang.org/x/sys v0.0.0-20170615053224-fb4cac33e319
>>  gopkg.in/yaml.v2 v2.2.0
>> )
>>
>>
>> Justin
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Help tracking down module dependencies

[Justin Israel]

I'm converting one of my internal projects from glide to a module, after
having done two other conversions. But I am hitting a problem that I can't
yet solve.

$ GO111MODULE=on go mod tidy -v

Fetching https://gotest.tools?go-get=1
https fetch failed: Get https://gotest.tools?go-get=1: Forbidden
go: gotest.tools@v2.1.0+incompatible: unrecognized import path
"gotest.tools" (https fetch failed: Get https://gotest.tools?go-get=1:
Forbidden)
go: error loading module requirements

My http proxy won't let me access this, and I can't find usage of it
anywhere in my own codebase or in the immediate dependencies (or even my
$GOPATH). The mod subcommand isn't being very specific about where this
dependency is coming from (even with the graph command). Any pointers would
be greatly appreciated. The dependency didn't show up in my glide.lock
originally.

My module requirements are:

require (
github.com/boltdb/bolt v1.3.1
github.com/elazarl/go-bindata-assetfs v1.0.0
github.com/gorilla/context v1.1.1
github.com/gorilla/mux v1.3.0
github.com/pborman/uuid v1.2.0
golang.org/x/sys v0.0.0-20170615053224-fb4cac33e319
gopkg.in/yaml.v2 v2.2.0
)


Justin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How can I run a method in a subprocess in golang?

[Justin Israel]

On Sat, Sep 22, 2018, 8:24 AM 'ggyft' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> My use case is that I am designing a scheduler that schedules various
> health checks (go method) periodically. Earlier I want to model run them in
> a new goroutine. But I ran into problems when I want to design timeout for
> each method. Basically go seems not able to kill goroutine and clean up
> resources like socket etc.
>

Rather than thinking about it as a lack of having a first class kill
command for goroutines, you need to run your goroutines in a way that the
work can be stopped. This can be accomplished with a Context that can be
closed or times out, or a channel that receives a stop signal, or even an
atomic that can be checked periodically. The work within the goroutine has
to be aware of stop conditions.

> I am wondering rather than run method in goroutine, can I run it in
> subprocess so I can kill it safely? My platform is windows hope that
> doesn't matter.
>

There is nothing stopping you from running health checks as separate
command as long as you have something to call.

-- 
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go modules and Dockerfile

[Justin Israel]

On Thu, Sep 20, 2018, 6:09 AM Sotirios Mantziaris 
wrote:

> hi,
>
> i am trying to build a container that supports modules and i get the
> following error:
>
> ↳ docker build . -t test
>
>  1 ↵ 
> 4.91G RAM  0.00K SWP  21:04:00
> Sending build context to Docker daemon  16.65MB
> Step 1/6 : FROM golang:latest as builder
>  ---> fb7a47d8605b
> Step 2/6 : COPY . ./
>  ---> Using cache
>  ---> 95a6b0284991
> Step 3/6 : RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o
> test ./cmd/test/main.go
>  ---> Running in f09b924aa3e9
> $GOPATH/go.mod exists but should not
> The command '/bin/sh -c CGO_ENABLED=0 GOOS=linux go build -a
> -installsuffix cgo -o test ./cmd/test/main.go' returned a non-zero code: 1
>
> The docker file looks like this.
>
> FROM golang:latest as builder
> COPY . ./
> RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o test
> ./cmd/test/main.go
>
> FROM scratch
> COPY --from=builder test .
> CMD ["./test"]
>
> any ideas how to solve this?
>

The golang image sets WORKDIR $GOPATH, and you don't modify it at all. So
you are copying your project files to $GOPATH

Try doing

WORKDIR $GOPATH/src/myapp

Or to some location outside $GOPATH

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing a Fyne GUI toolkit

[Justin Israel]

I've hit a couple issues with the bootstrap on ubuntu 16.04 and have been
logging them as I find them:
https://github.com/fyne-io/bootstrap/issues

On Tue, Sep 18, 2018 at 9:04 AM Tharaneedharan Vilwanathan <
vdhar...@gmail.com> wrote:

> Hi,
>
> Anyone having trouble installing on a Mac or am I alone?
>
> The bootstrapping part gives me trouble. Please let me know if I need to
> provide more details.
>
> Regards
> dharani
>
>
> On Mon, Sep 17, 2018 at 1:25 PM Andy Williams 
> wrote:
>
>> Hi,
>>
>> I don’t know if it helps but I wrote a short document about the driver in
>> Fyne.
>> https://github.com/fyne-io/fyne/wiki/Drivers
>>
>> Andrew
>>
>> On 14 September 2018 at 20:01:56, Andrew Williams (handya...@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> Thanks. There is an efl opengl driver which we could utilise instead of
>> the sofware driver with a small change - if your hardware supports it.
>> It would also be possible to provide an alternative driver that
>> communicates directly with opengl, but this is a lot more work.
>> I have designed the backend to be loosely coupled so that other options
>> could be provided (i.e. we could write a webgl/webasm driver or a native
>> mobile one). I am writing up documentation about the requirements for
>> drivers but it is basically a canvas that can draw
>> line/rect/text/images(including svg) and some basic window handling.
>>
>> Current drivers are "desktop" which uses EFL and "test" used for
>> in-memory unit testing of the widgets etc.
>>
>> I hope that helps,
>> Andrew
>>
>> On Friday, 14 September 2018 18:57:14 UTC+1, Ian Davis wrote:
>>>
>>>
>>> On Fri, 14 Sep 2018, at 6:02 PM, Andrew Williams wrote:
>>>
>>>
>>> It's now well into development and ready for people to get involved.
>>> There is a long way to go but it feels like a solid base.
>>> Instructions for getting started, if you need them, are at
>>> https://github.com/fyne-io/bootstrap/blob/master/README.md .
>>> If you want to know more we're also in the #fyne channel on the gopher
>>> Slack server.
>>>
>>>
>>> This looks very impressive.
>>>
>>> Is it possible to interface it with opengl or vulcan?
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Run time error

[Justin Israel]

Your stack trace isn't long enough to see the usage of ipfs leading up to
the crash. And your example code doesn't show usage of that library.
Somewhere in there you must have a nil pointer to a RequestBuilder, on
which Send() is being called.

On Tue, Sep 18, 2018, 3:42 AM akshita babel 
wrote:

> When I am running a program which is for a web response I am getting a run
> time error as follows:
> http: panic serving 127.0.0.1:43802: runtime error: invalid memory
> address or nil pointer dereference
> goroutine 6 [running]:
> net/http.(*conn).serve.func1(0xc4200a4a00)
> /usr/lib/go-1.10/src/net/http/server.go:1726 +0x11b
> panic(0x9b5360, 0xd99230)
> /usr/lib/go-1.10/src/runtime/panic.go:502 +0x24a
> github.com/ipfs/go-ipfs-api.(*RequestBuilder).Send(0xc4201740a0,
> 0xb95c60, 0xc420022100, 0x0, 0x0, 0x0)
> The code of main file is as follows:
> func main() {
>
> router := httprouter.New()
> router.RedirectTrailingSlash = true
> c := cors.New(cors.Options{
>   AllowedOrigins:   []string{"*"},
>   AllowedMethods:   []string{"GET", "POST", "OPTIONS", "Authorization"},
>   AllowedHeaders:   []string{"*"},
>   AllowCredentials: true,
> })
> router.GET("/create", StoreAndGetHash)
> router.GET("/read/:hashvalue", GetFile)
> router.GET("/appdata/:appID", ReadPeer)
> router.GET("/update", UpdateAndGetHash)
> router.GET("/createdir", GetDir)
> router.GET("/newkey", GetNewKey)
>
> log.Fatal(http.ListenAndServe(":3000", c.Handler(router)))
>
> }
>
> I am working on ubuntu
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Golang equivalent of Python's context manager

[Justin Israel]

On Thu, Sep 13, 2018, 10:13 AM Mirko Friedenhagen 
wrote:

> Thanks again. I think some of the use cases, especially those which
> implement some kind of finally (which includes locking use case) may just
> be implemented with simple functions. At least throwing exceptions is a
> rare event in Golang (panicking is what I meant with rare).
>
> Are closures, like the one in the main method idiomatic?
>

I don't see why not.
Also when I was using the boltdb api, I found it relies heavily on passing
function closures to the view and batch functions. The signature of the
function can be minimal like just returning and error, and you can capture
arbitrary return values just by declaring them in the outer scope and
setting them in the closure.


> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Golang equivalent of Python's context manager

[Justin Israel]

For about the same amount of typing that you have to do to create a closure
for using with a predefined WithContext handler, I tend to do this inline:

func start() { fmt.Println("start") }
func stop() { fmt.Println("stop") }

func main() {
func() (string, error) {
start()
defer stop()
fmt.Println("run")
return "hi", nil
}()
}

https://play.golang.org/p/3B63iTY4pla

It means I can return any signature, as long as I have the enter/exit
functions defined already.

Justin

On Thu, Sep 13, 2018, 7:35 AM Sam Whited  wrote:

> On Wed, Sep 12, 2018, at 14:12, Mirko Friedenhagen wrote:
> > However, coming from Java lately, retrieving a DB-connection from a
> pool,
> > opening a transaction and committing/aborting and returningafterwards
> seems
> > something which could be handled with such a construct. How would you do
> > this in Golang?
>
> I frequently do something similar to this:
>
> https://gist.github.com/SamWhited/d81d081aed0351a1c1d128acf3a16b5c
>
> (there may be some extra parameters, I cut out some row-level-security
> stuff from something being used in prod and pasted everything into the gist
> without really checking it)
>
> —Sam
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: modules: Using vendored transitive dependencies of primary dependency

[Justin Israel]

On Wednesday, September 5, 2018 at 6:31:03 PM UTC+12, Justin Israel wrote:
>
> I've been having some great results converting some of my internal 
> projects from glide to go modules, but I am looking at a specific workflow 
> right now that is confusing me. Hoping to get some clarification...
>
> Project 'foo' has its dependencies vendored via "go mod vendor". This 
> works great when building that project internally since a non-go developer 
> can clone the project and build it, with no external proxy access needed to 
> download dependencies. 
>
> Now I am trying to allow project 'bar' to build a tool provided by 'foo'. 
> The go.mod file only contains:
>
> module internal.com/project/bar
>
> require internal.com/project/foo v0.0.0-...
>
> What I am seeing is that foo and all of its dependencies will be clones 
> from their origins, and my go.sum file is updated with all of the transient 
> dependencies. But what I really want is to only fetch 'foo' from my 
> internal network and to have it use the vendored dependencies. 
>
> Is this even possible? The "-mod=vendor" flag was very useful when 
> building project "foo" directly. But it doesn't seem to apply here because 
> project "bar" doesn't want to vendor. It wants to get the one primary 
> dependency and that is it.
>
> Justin
>
>
I tried to solve this temporarily with a combination of using glide to pull 
just the primary dependency, and then to use "go build -mod=vendor" to pick 
up the vendored dependencies. But glide won't flatten the vendor directory 
properly, to bring the nested vendor to the top level. So I have had to 
resort to a hack where I manually clone the primary dependency, move its 
nested vendor to the root, and the move that primary dependency into 
vendor/ as well. 

Would love to cleanly solve this through the module system.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] modules: Using vendored transitive dependencies of primary dependency

[Justin Israel]

I've been having some great results converting some of my internal projects
from glide to go modules, but I am looking at a specific workflow right now
that is confusing me. Hoping to get some clarification...

Project 'foo' has its dependencies vendored via "go mod vendor". This works
great when building that project internally since a non-go developer can
clone the project and build it, with no external proxy access needed to
download dependencies.

Now I am trying to allow project 'bar' to build a tool provided by 'foo'.
The go.mod file only contains:

module internal.com/project/bar

require internal.com/project/foo v0.0.0-...

What I am seeing is that foo and all of its dependencies will be clones
from their origins, and my go.sum file is updated with all of the transient
dependencies. But what I really want is to only fetch 'foo' from my
internal network and to have it use the vendored dependencies.

Is this even possible? The "-mod=vendor" flag was very useful when building
project "foo" directly. But it doesn't seem to apply here because project
"bar" doesn't want to vendor. It wants to get the one primary dependency
and that is it.

Justin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go mod impressions

[Justin Israel]

On Sat, Sep 1, 2018, 11:43 AM Vasily Korytov  wrote:

> Hi,
>
> I've experimented with GO111MODULE preview in Go 1.11 release, two things
> to note so far:
> 1. go mod vendor pulled in vendor folder the .travis.yml file which
> apparently I don't want there (govendor filters it by default)
>
> 2. I've decided to clean up my GOPATH and start from scratch. I moved
> GOPATH and ran: go get something, but wasn't able to do it:
> it complained with 'cannot find main module' and did nothing (despite the
> target package had go.mod). Same procedure without GO111MODULE=on works
> like a charm.
>

This point has been discussed before. The conclusion is that if you
set GO111MODULE=on and run "go get", then it is expected that you are
within a module location. Otherwise the Go tool has no idea where to cache
the package you are getting. I may be summarising that incorrectly though,
because it only makes partial sense to me. I get that it wouldn't know what
you want to do with a library that is meant to be a dependency of a current
module project. But I don't get why it shouldn't work for getting a main
program. i.e. would expect it to work for getting something like goimports,
where is it meant to just get and install a binary to $GOBIN

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Is the go 1.11 godoc tool 'module-aware'?

[Justin Israel]

On Thu, Aug 30, 2018, 9:54 PM Agniva De Sarker 
wrote:

> I had filed https://github.com/golang/go/issues/26827 to list the changes
> that godoc needs to make. Please feel free to add your comments there.
>
> Also - note that godoc cli mode is going to go away. So "godoc -links=0
> -html domain.com/group/project/v3/lib/foo" is not going to work after
> 1.12. You should be using the http server. If you want command line help,
> use "go doc".
>

Fair enough. I should just discontinue the feature we have in our build
systems Go tool. It was neat to generate html docs with our deploys.


> - Agniva
>
>
> On Thursday, 30 August 2018 01:02:48 UTC+5:30, Justin Israel wrote:
>>
>> Thanks for that update, Paul!
>>
>> On Thu, Aug 30, 2018, 2:07 AM Paul Jolly  wrote:
>>
>>> Perhaps better (because of the automatic linking, status updates etc)
>>> is to create issues in respective tools under the umbrella of
>>> https://github.com/golang/go/issues/24661
>>>
>>> Indeed I know there are a number of such issues, so it's just a case
>>> of linking those from #24661.
>>> On Wed, 29 Aug 2018 at 07:46, wilk  wrote:
>>> >
>>> >
>>> > It could be fine to start a wiki page to list the tools and ide
>>> > (not)ready for modules with the linked issues.
>>> >
>>> > In https://github.com/golang/go/wiki/Modules or a new page ?
>>> >
>>> > On 29-08-2018, Paul Jolly wrote:
>>> > > --50127c057491b176
>>> > > Content-Type: text/plain; charset="UTF-8"
>>> > >
>>> > > Please see https://github.com/golang/gddo/issues/567
>>> > >
>>> > > On Tue, 28 Aug 2018, 18:59 Justin Israel, 
>>> wrote:
>>> > >
>>> > >> I've been trying out converting some of our internal projects to go
>>> 1.11
>>> > >> using modules instead of glide. We have a build system that
>>> provides the
>>> > >> ability to generate html docs via "godoc" and I am wondering if
>>> godoc has
>>> > >> been made "module-aware" in go 1.11?
>>> > >>
>>> > >> My particular project is using the migration approach of setting
>>> "v3" at
>>> > >> in the go.mod, and in all import paths within the project. But it
>>> seems
>>> > >> godoc is not happy about this:
>>> > >>
>>> > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
>>> > >>
>>> > >> 2018/08/29 11:52:12 error while importing build package: cannot
>>> find package "domain.com/group/project/v3/lib/foo" in any of:
>>> > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo
>>> (from $GOROOT)
>>> > >> /usr/home/justin/src/go/src/
>>> domain.com/group/project/v3/lib/foo (from $GOPATH)
>>> > >> 2018/08/29 11:52:12 cannot find package "." in:
>>> > >> /src/domain.com/group/project/v3/lib/foo
>>> > >>
>>> > >>
>>> > >> It seems to only care about the filesystem structure and not the
>>> module import path naming?
>>> > >>
>>> > >>
>>> > >> Justin
>>> > >>
>>> > >>
>>> > >> --
>>> > >> You received this message because you are subscribed to the Google
>>> Groups
>>> > >> "golang-nuts" group.
>>> > >> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> > >> email to golang-nuts...@googlegroups.com.
>>> > >> For more options, visit https://groups.google.com/d/optout.
>>> > >>
>>> > >
>>> >
>>> >
>>> > --
>>> > William
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Is the go 1.11 godoc tool 'module-aware'?

[Justin Israel]

Thanks for that update, Paul!

On Thu, Aug 30, 2018, 2:07 AM Paul Jolly  wrote:

> Perhaps better (because of the automatic linking, status updates etc)
> is to create issues in respective tools under the umbrella of
> https://github.com/golang/go/issues/24661
>
> Indeed I know there are a number of such issues, so it's just a case
> of linking those from #24661.
> On Wed, 29 Aug 2018 at 07:46, wilk  wrote:
> >
> >
> > It could be fine to start a wiki page to list the tools and ide
> > (not)ready for modules with the linked issues.
> >
> > In https://github.com/golang/go/wiki/Modules or a new page ?
> >
> > On 29-08-2018, Paul Jolly wrote:
> > > --50127c057491b176
> > > Content-Type: text/plain; charset="UTF-8"
> > >
> > > Please see https://github.com/golang/gddo/issues/567
> > >
> > > On Tue, 28 Aug 2018, 18:59 Justin Israel, 
> wrote:
> > >
> > >> I've been trying out converting some of our internal projects to go
> 1.11
> > >> using modules instead of glide. We have a build system that provides
> the
> > >> ability to generate html docs via "godoc" and I am wondering if godoc
> has
> > >> been made "module-aware" in go 1.11?
> > >>
> > >> My particular project is using the migration approach of setting "v3"
> at
> > >> in the go.mod, and in all import paths within the project. But it
> seems
> > >> godoc is not happy about this:
> > >>
> > >> godoc -links=0 -html domain.com/group/project/v3/lib/foo
> > >>
> > >> 2018/08/29 11:52:12 error while importing build package: cannot find
> package "domain.com/group/project/v3/lib/foo" in any of:
> > >> /path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo
> (from $GOROOT)
> > >> /usr/home/justin/src/go/src/
> domain.com/group/project/v3/lib/foo (from $GOPATH)
> > >> 2018/08/29 11:52:12 cannot find package "." in:
> > >> /src/domain.com/group/project/v3/lib/foo
> > >>
> > >>
> > >> It seems to only care about the filesystem structure and not the
> module import path naming?
> > >>
> > >>
> > >> Justin
> > >>
> > >>
> > >> --
> > >> You received this message because you are subscribed to the Google
> Groups
> > >> "golang-nuts" group.
> > >> To unsubscribe from this group and stop receiving emails from it,
> send an
> > >> email to golang-nuts+unsubscr...@googlegroups.com.
> > >> For more options, visit https://groups.google.com/d/optout.
> > >>
> > >
> >
> >
> > --
> > William
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is the go 1.11 godoc tool 'module-aware'?

[Justin Israel]

I've been trying out converting some of our internal projects to go 1.11 
using modules instead of glide. We have a build system that provides the 
ability to generate html docs via "godoc" and I am wondering if godoc has 
been made "module-aware" in go 1.11?

My particular project is using the migration approach of setting "v3" at in 
the go.mod, and in all import paths within the project. But it seems godoc 
is not happy about this:

godoc -links=0 -html domain.com/group/project/v3/lib/foo

2018/08/29 11:52:12 error while importing build package: cannot find package 
"domain.com/group/project/v3/lib/foo" in any of:
/path/to/go/1.11.0/src/domain.com/group/project/v3/lib/foo (from 
$GOROOT)
/usr/home/justin/src/go/src/domain.com/group/project/v3/lib/foo (from 
$GOPATH)
2018/08/29 11:52:12 cannot find package "." in:
/src/domain.com/group/project/v3/lib/foo


It seems to only care about the filesystem structure and not the module import 
path naming?


Justin


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] streadway/amqp (RabbitMQ) manual Ack does not work after first message

[Justin Israel]

On Wed, Aug 15, 2018 at 9:33 AM Sotirios Mantziaris 
wrote:

> I can see over the wire that i get messages from the server with
> Basic.Delivery.
> The messages do not pop up out of the channel that channel.Consume returns
> when creating the connection.
> I might read some where that channels do not play well with threads. I
> wonder if it is the same with goroutines, because i get the messages one
> one goroutine, send it to another via a channel where the messages get Ack
> or Nack.
>
> You said that your application has a similar pattern. Is the channel and
> Ack, Nack on the same goroutine? do you have code that i can look into?
>

My application is internal at work, so I can't share it. But I took a look
at your code and I think this might be your problem:

https://github.com/mantzas/patron/blob/amqp-lock/async/amqp/amqp.go#L119

You are only selecting once on the delivery channel, without a for loop. So
you pull one message and your goroutine exits and never delivers another
message.

You should be fine sharing the messages between goroutines. All that
matters is that the message acks itself back with the tag you set.


>
> On Wednesday, August 15, 2018 at 12:24:18 AM UTC+3, Justin Israel wrote:
>
>>
>>
>> On Wed, Aug 15, 2018 at 8:05 AM Sotirios Mantziaris 
>> wrote:
>>
>>> I have actually opened a thread in the rabbitmq-users list where i
>>> checked through wireshark what goes over the wire. It is actually pretty
>>> nice to see the flow.
>>> I have cross posted since i did not know if it is rabbitmq or my go
>>> code...
>>> it seems that i get the next message from the wire but the code does not
>>> get it at all...
>>>
>>
>> If I am reading that properly, you are saying that your message handler
>> is not actually getting triggered at all for subsequent messages? That
>> would mean you have some kind of blocking problem in your goroutines and
>> channels. I thought initially you were saying that you verified the handler
>> was constantly receiving messages and calling ack() but the ack never makes
>> it back to Rabbitmq
>>
>>
>>> On Tuesday, August 14, 2018 at 10:59:15 PM UTC+3, Justin Israel wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Aug 15, 2018, 2:14 AM Sotirios Mantziaris 
>>>> wrote:
>>>>
>>>>> hi,
>>>>>
>>>>> i have setup a "consumer" for a rabbitmq queue. Every delivery is put
>>>>> in a channel which is picked up by a goroutine.
>>>>> After processing the delivery is then Ack or Nack based on the success
>>>>> of the processing.
>>>>> It seems that the first one is processed ok but the rest cannot be
>>>>> Ack/Nack.
>>>>> The ui of rabbitmq shows every message in a unacked state, which
>>>>> probably means that the consumer gets the message from the queue but
>>>>> something prevents it for being put in the above mentioned channel.
>>>>>
>>>>> The consume part of the queue can be found here :
>>>>> https://github.com/mantzas/patron/blob/amqp-lock/async/amqp/amqp.go
>>>>> The processing goroutine can be found here:
>>>>> https://github.com/mantzas/patron/blob/amqp-lock/async/component.go
>>>>>
>>>>> Does anybody have a idea?
>>>>>
>>>>
>>>> I have an application with a similar pattern where is manually acks
>>>> each message after the processing succeeds. So I can check your logic
>>>> against mine. In the meantime, can you clarify if you confirmed that
>>>> processing always happens locally and the ack does get called every time,
>>>> but you are just not seeing it deliver the ack to Rabbitmq?
>>>>
>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "golang-nuts" group.
>>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to golang-nuts...@googlegroups.com.
>>>>
>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.