[go-nuts] Windows syscall.Open() change to fix os.Rename() & .Remove()

[Liam]

Microsoft recommends changing syscall.Open() for GOOS=windows to fix this. 
Pls reply if you know of existing apps that rely on it.

This code fails with a "sharing violation" on Windows. That behavior is 
undocumented in package "os".

path := "rename-after-open"
fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
if err != nil { ... }
err = os.Rename(path_a, path_b)// or os.Remove(path)
if err != nil { ... }  // sharing violation
fd.Close()


In this issue, Microsoft suggested that Go on Windows switch to Unix-like 
behavior:
https://github.com/golang/go/issues/32088

I believe this will happen in pre-release 1.14.

-- 
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/a6702e0b-93e1-40b6-95e7-40b73701b3a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Not receiving email digests

[Ian Lance Taylor]

On Wed, Jul 10, 2019 at 4:33 PM amr  wrote:
>
> I appear to be no longer receiving the email digests daily. I last received a 
> daily on 26th June, and then a single daily on 2nd July. I tried leaving the 
> group and rejoining yesterday, to no avail!
> Any ideas, please, moderator?

Sorry, no ideas.  I see that you are on the list and signed up to
receive one message per day.  Everything I can see looks fine.  I have
no way to verifying that the messages are actually being sent or
anything, but likely they are.  Check your spam filters and logs.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV8%3DBXt%3Dj7Ut5ojz1bvspX5Vd7%3Dc8uzfSDjSUSLsZ5i7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Not receiving email digests

[amr]

I appear to be no longer receiving the email digests daily. I last received 
a daily on 26th June, and then a single daily on 2nd July. I tried leaving 
the group and rejoining yesterday, to no avail!
Any ideas, please, moderator?

-- 
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/bfe5e4b1-ee6c-40e1-91f8-8d06d826ca10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Burak Serdar]

On Wed, Jul 10, 2019 at 3:24 PM Roman Kuprov  wrote:
>
> Would the Context package not work for this issue?
> (kinda new gopher here)

It is similar to using a cancel channel. Context communicates the
cancellation by closing a channel returned by Done().

>
> On Wednesday, July 10, 2019 at 1:08:38 PM UTC-6, Dan Eloff wrote:
>>
>> Yeah, agreed. I've been deep into concurrent programming for a long time 
>> now, and into lock-free programming as well which is the most fraught kind 
>> of programming I've ever done. Parallel is the future, it has been that way 
>> for a long time, but it's only getting more and more obvious.
>>
>> I think in this specific case, the timeout should have been handled on the 
>> sending side in a select,  almost identically to the receiver code I posted. 
>> If the timer channel triggers, then close the channel to indicate to the 
>> receiver that it can wake up and it has timed out. Then the sender can go 
>> ahead and clean up the resource which it still owns. Doing it on the 
>> receiver side is fraught with problems.
>>
>> I solved it with a dedicated go routine that scans for timed out waiters and 
>> expires them by closing the channel, but that meant the sender now needs to 
>> handle the rare panic if it sends on a closed channel - not the end of the 
>> world, but not as clean.
>>
>> On Wed, Jul 10, 2019 at 10:14 AM Jesper Louis Andersen 
>>  wrote:
>>>
>>> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff  wrote:

 On Wed, Jul 10, 2019 at 7:54 AM Michael Jones  wrote:
>
> unbuffered means nothing is sent until is is simultaneously received, so 
> there is no limbo or race or uncertainty. one sender "wins" the select 
> and the others remain blocked waiting.


 So I'm correct then: "Now one of two things must happen, either the sender 
 blocks forever because nobody read the sent value"

>>>
>>> If the sender is written as
>>>
>>> channel <- fd
>>>
>>> as you propose, then indeed, the sender will block forever. However, this 
>>> is easily fixed via a select on the sender side as well with a timeout, or 
>>> a context.Context that can cancel. If the send on the channel is _not_ 
>>> selected, you still own the resource and have to clean up.
>>>
>>> More advanced event systems, such as Concurrent ML, has a withNACK guard 
>>> for this case. If a given event is not selected, its withNACK thunk is run, 
>>> allowing for cleanup. But in your case and Go, you can just have a variable 
>>> or such to handle the case and clean up properly.
>>>
>>> You are right that a lot of concurrent programming is hard, especially in 
>>> the presence of errors and faults. Hence, simple strategies first. And then 
>>> you need to have a sketch of a proof present for more complicated 
>>> interactions, or a model in TLA+ if you want it to be water-tight. However, 
>>> given what AMD just launched, there is little hope for MIMD style operation 
>>> now. SIMD style can still be done with a sequential but parallel program.
>>>
>>>
>>> --
>>> J.
>
> --
> 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/7a3021d7-3637-46f2-84a2-58b4b338ffa2%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/CAMV2RqohgH%3DXv4VQYaxe09LRzMhkm%3DiXAOe5OS23dJR_ii_UNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] get interface and method name

[Ian Lance Taylor]

On Wed, Jul 10, 2019 at 1:40 PM Vasiliy Tolstov  wrote:
>
> Hi! i have interface like
>
> type AccountService interface {
>   Create(context.Context) error
> }
>
> if i need to get string representation of this interface from passed
> AccountService.Create how can i do that?
>
> Now i create POC like this:
> parts := 
> strings.Split(runtime.FuncForPC(reflect.ValueOf(iface).Pointer()).Name(),
> ".")
> return parts[len(parts)-2] + "." + parts[len(parts)-1]
>
> it returns string "AccountService.Create"
> Does it possible to get this not using runtime? only via reflect and
> may be without strings ?

Can you show us a working example in the Go playground to demonstrated
what you are looking for?

If your interface is named AccountService, I would not expect any
method to be named AccountService.Create.  The Create method will be
defined on other types converted to the interface type, not on the
interface type itself.  So I'm not sure what you are actually looking
for.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVZrcCMDpUgBZ2uEAnhFmKtE9_Zau5H1w_6CfzOBqnu3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Roman Kuprov]

Would the Context package not work for this issue?
(kinda new gopher here)

On Wednesday, July 10, 2019 at 1:08:38 PM UTC-6, Dan Eloff wrote:
>
> Yeah, agreed. I've been deep into concurrent programming for a long time 
> now, and into lock-free programming as well which is the most fraught kind 
> of programming I've ever done. Parallel is the future, it has been that way 
> for a long time, but it's only getting more and more obvious.
>
> I think in this specific case, the timeout should have been handled on the 
> sending side in a select,  almost identically to the receiver code I 
> posted. If the timer channel triggers, then close the channel to indicate 
> to the receiver that it can wake up and it has timed out. Then the sender 
> can go ahead and clean up the resource which it still owns. Doing it on the 
> receiver side is fraught with problems.
>
> I solved it with a dedicated go routine that scans for timed out waiters 
> and expires them by closing the channel, but that meant the sender now 
> needs to handle the rare panic if it sends on a closed channel - not the 
> end of the world, but not as clean.
>
> On Wed, Jul 10, 2019 at 10:14 AM Jesper Louis Andersen <
> jesper.lo...@gmail.com > wrote:
>
>> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff > > wrote:
>>
>>> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones >> > wrote:
>>>
 unbuffered means nothing is sent until is is simultaneously received, 
 so there is no limbo or race or uncertainty. one sender "wins" the select 
 and the others remain blocked waiting.

>>>
>>> So I'm correct then: "Now one of two things must happen, either the 
>>> sender blocks forever because nobody read the sent value"
>>>
>>>
>> If the sender is written as
>>
>> channel <- fd
>>
>> as you propose, then indeed, the sender will block forever. However, this 
>> is easily fixed via a select on the sender side as well with a timeout, or 
>> a context.Context that can cancel. If the send on the channel is _not_ 
>> selected, you still own the resource and have to clean up.
>>
>> More advanced event systems, such as Concurrent ML, has a withNACK guard 
>> for this case. If a given event is not selected, its withNACK thunk is run, 
>> allowing for cleanup. But in your case and Go, you can just have a variable 
>> or such to handle the case and clean up properly.
>>
>> You are right that a lot of concurrent programming is hard, especially in 
>> the presence of errors and faults. Hence, simple strategies first. And then 
>> you need to have a sketch of a proof present for more complicated 
>> interactions, or a model in TLA+ if you want it to be water-tight. However, 
>> given what AMD just launched, there is little hope for MIMD style operation 
>> now. SIMD style can still be done with a sequential but parallel program.
>>
>>
>> -- 
>> J.
>>
>

-- 
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/7a3021d7-3637-46f2-84a2-58b4b338ffa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] get interface and method name

[Vasiliy Tolstov]

Hi! i have interface like

type AccountService interface {
  Create(context.Context) error
}

if i need to get string representation of this interface from passed
AccountService.Create how can i do that?

Now i create POC like this:
parts := 
strings.Split(runtime.FuncForPC(reflect.ValueOf(iface).Pointer()).Name(),
".")
return parts[len(parts)-2] + "." + parts[len(parts)-1]

it returns string "AccountService.Create"
Does it possible to get this not using runtime? only via reflect and
may be without strings ?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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/CACaajQt7QsQQSZ-tn2p8nyGL3XWdZm0ruTHu_-3-iL5P0gQOww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Dan Eloff]

Yeah, agreed. I've been deep into concurrent programming for a long time
now, and into lock-free programming as well which is the most fraught kind
of programming I've ever done. Parallel is the future, it has been that way
for a long time, but it's only getting more and more obvious.

I think in this specific case, the timeout should have been handled on the
sending side in a select,  almost identically to the receiver code I
posted. If the timer channel triggers, then close the channel to indicate
to the receiver that it can wake up and it has timed out. Then the sender
can go ahead and clean up the resource which it still owns. Doing it on the
receiver side is fraught with problems.

I solved it with a dedicated go routine that scans for timed out waiters
and expires them by closing the channel, but that meant the sender now
needs to handle the rare panic if it sends on a closed channel - not the
end of the world, but not as clean.

On Wed, Jul 10, 2019 at 10:14 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff  wrote:
>
>> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones 
>> wrote:
>>
>>> unbuffered means nothing is sent until is is simultaneously received, so
>>> there is no limbo or race or uncertainty. one sender "wins" the select and
>>> the others remain blocked waiting.
>>>
>>
>> So I'm correct then: "Now one of two things must happen, either the
>> sender blocks forever because nobody read the sent value"
>>
>>
> If the sender is written as
>
> channel <- fd
>
> as you propose, then indeed, the sender will block forever. However, this
> is easily fixed via a select on the sender side as well with a timeout, or
> a context.Context that can cancel. If the send on the channel is _not_
> selected, you still own the resource and have to clean up.
>
> More advanced event systems, such as Concurrent ML, has a withNACK guard
> for this case. If a given event is not selected, its withNACK thunk is run,
> allowing for cleanup. But in your case and Go, you can just have a variable
> or such to handle the case and clean up properly.
>
> You are right that a lot of concurrent programming is hard, especially in
> the presence of errors and faults. Hence, simple strategies first. And then
> you need to have a sketch of a proof present for more complicated
> interactions, or a model in TLA+ if you want it to be water-tight. However,
> given what AMD just launched, there is little hope for MIMD style operation
> now. SIMD style can still be done with a sequential but parallel program.
>
>
> --
> J.
>

-- 
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/CADz32d%3Dm5fc40-1kBPdynqg6_RgmoZnMGyhccDam6FF0u8tOEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Jesper Louis Andersen]

On Wed, Jul 10, 2019 at 6:30 PM  wrote:

>
> The best thing to do is to not use unmanaged resources.
>

Would be the Erlang solution. You cannot change the owner of an open file,
and if the process owning it terminates, the file is closed. You can change
ownership of a TCP socket, and then messages from the socket in the mailbox
which has not yet been received are also transferred to the new owner in
the same order, preserving linearizability guarantees.

-- 
J.

-- 
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/CAGrdgiXpPpr5%3Dwb8N7s5bSZZjg49iph%3DsozM5P1g%3DF-5-1prqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[Nitish Saboo]

Hi Andrey,

I made the following changes as suggested by you:

 InitStruct := C.calloc(1, C.sizeof_struct_Foo)
InitStruct.key_value_cb = C.callOnMeGo_cgo
InitStruct.data = C.int(1)
C.initialize_engine(pattern_db, module_path,
(*C.Foo)(unsafe.Pointer(InitStruct)))

Still Getting following error:

Am i missing something?

go build -v -x main.go cfuncs.go
WORK=/tmp/go-build822337807
command-line-arguments
mkdir -p $WORK/b001/
cd /home/nsaboo/Documents/goworkspace/src/poc
pkg-config --cflags -- syslog-ng eventlog
pkg-config --libs -- syslog-ng eventlog
CGO_LDFLAGS='"-g" "-O2" "syslog-node.so" "-L/usr/local/lib/" "-lsyslog-ng"
"-L/usr/local/lib/syslog-ng" "-ldbparser" "-L/usr/local/lib"
"-Wl,--export-dynamic" "-lgmodule-2.0" "-pthread" "-lgthread-2.0"
"-pthread" "-lglib-2.0" "-lsyslog-ng" "-lglib-2.0" "-levtlog"'
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/b001/ -importpath
command-line-arguments -- -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I
$WORK/b001/ -g -O2 -I/usr/local/include/ ./main.go ./cfuncs.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x001.o -c _cgo_export.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x002.o -c main.cgo2.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x003.o -c cfuncs.cgo2.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_cgo_main.o -c _cgo_main.c
cd /home/nsaboo/Documents/goworkspace/src/poc
TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o
$WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o
$WORK/b001/_x002.o $WORK/b001/_x003.o -g -O2 syslog-node.so
-L/usr/local/lib/ -lsyslog-ng -L/usr/local/lib/syslog-ng -ldbparser
-L/usr/local/lib -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgthread-2.0
-pthread -lglib-2.0 -lsyslog-ng -lglib-2.0 -levtlog
TERM='dumb' /usr/local/go/pkg/tool/linux_amd64/cgo -dynpackage main
-dynimport $WORK/b001/_cgo_.o -dynout $WORK/b001/_cgo_import.go
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile bufio=/usr/local/go/pkg/linux_amd64/bufio.a
packagefile encoding/json=/usr/local/go/pkg/linux_amd64/encoding/json.a
packagefile fmt=/usr/local/go/pkg/linux_amd64/fmt.a
packagefile os=/usr/local/go/pkg/linux_amd64/os.a
packagefile path=/usr/local/go/pkg/linux_amd64/path.a
packagefile runtime=/usr/local/go/pkg/linux_amd64/runtime.a
packagefile time=/usr/local/go/pkg/linux_amd64/time.a
packagefile runtime/cgo=/usr/local/go/pkg/linux_amd64/runtime/cgo.a
packagefile syscall=/usr/local/go/pkg/linux_amd64/syscall.a
EOF
/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath
$WORK/b001 -p main -buildid 6VU9NC3t5EyTg_0nt_wU/6VU9NC3t5EyTg_0nt_wU
-goversion go1.12.4 -D _/home/nsaboo/Documents/goworkspace/src/poc
-importcfg $WORK/b001/importcfg -pack -c=2 $WORK/b001/_cgo_gotypes.go
$WORK/b001/main.cgo1.go $WORK/b001/cfuncs.cgo1.go $WORK/b001/_cgo_import.go
# command-line-arguments
./main.go:92:12: InitStruct.key_value_cb undefined (type unsafe.Pointer has
no field or method key_value_cb)
./main.go:93:12: InitStruct.data undefined (type unsafe.Pointer has no
field or method data)
./main.go:170:12: InitStruct.key_value_cb undefined (type unsafe.Pointer
has no field or method key_value_cb)
./main.go:171:12: InitStruct.data undefined (type unsafe.Pointer has no
field or method data)
makefile:6: recipe for 

Re: [go-nuts] Avoiding resource leaks with racing channels

[Jesper Louis Andersen]

On Wed, Jul 10, 2019 at 6:45 PM Dan Eloff  wrote:

> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones 
> wrote:
>
>> unbuffered means nothing is sent until is is simultaneously received, so
>> there is no limbo or race or uncertainty. one sender "wins" the select and
>> the others remain blocked waiting.
>>
>
> So I'm correct then: "Now one of two things must happen, either the sender
> blocks forever because nobody read the sent value"
>
>
If the sender is written as

channel <- fd

as you propose, then indeed, the sender will block forever. However, this
is easily fixed via a select on the sender side as well with a timeout, or
a context.Context that can cancel. If the send on the channel is _not_
selected, you still own the resource and have to clean up.

More advanced event systems, such as Concurrent ML, has a withNACK guard
for this case. If a given event is not selected, its withNACK thunk is run,
allowing for cleanup. But in your case and Go, you can just have a variable
or such to handle the case and clean up properly.

You are right that a lot of concurrent programming is hard, especially in
the presence of errors and faults. Hence, simple strategies first. And then
you need to have a sketch of a proof present for more complicated
interactions, or a model in TLA+ if you want it to be water-tight. However,
given what AMD just launched, there is little hope for MIMD style operation
now. SIMD style can still be done with a sequential but parallel program.


-- 
J.

-- 
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/CAGrdgiVxOHWiz%2Bk5ga09qqnS6ndcK1dDe%2BDgnP93wHizTtquBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Burak Serdar]

On Wed, Jul 10, 2019 at 10:45 AM Dan Eloff  wrote:
>
> On Wed, Jul 10, 2019 at 7:54 AM Michael Jones  wrote:
>>
>> unbuffered means nothing is sent until is is simultaneously received, so 
>> there is no limbo or race or uncertainty. one sender "wins" the select and 
>> the others remain blocked waiting.
>
>
> So I'm correct then: "Now one of two things must happen, either the sender 
> blocks forever because nobody read the sent value"
>
> The implications of that are that the sending and receiving code are tightly 
> coupled. It is not generally safe to send on a channel without knowing how 
> the receiver receives it, otherwise you can block forever like in this case 
> where the receiver is using a select and the timeout wins. It's very easy to 
> make your Go program leak goroutines that way - and I bet a lot of serious 
> software makes that mistake in practice. In this case the sender would need 
> to loop doing a non-blocking send because the receiver is using a select, and 
> then handle the case where the fd didn't get sent within a reasonable time 
> period (which makes no sense because no both sender and receiver have a 
> timeout baked in.)

Sender would not need a loop if you use  a cancel channel:

select {
  case channel<-fd:
  case <-cancel:
close(fd)
}

I think the problem is, as someone else already mentioned, resource
ownership. If fd cannot be sent, it still belongs to the sender, and
it has to have a way of cleaning it up. So the receiver has to let the
sender know that it is no longer interested in the resource.

>
> Basically a simple send and receive are not too bad, but once you move beyond 
> that the world gets complex and fraught very quickly. Multi-threaded 
> programming is hard, and Go doesn't wave that burden away. No tools that I've 
> seen wave that away, so it's not really a failing of Go, it speaks more to 
> the inherit complexity of the domain.
>
> --
> 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/CADz32dnDZt_npnZvCyfcGKOZ-sXHz-0V59hbhu%3DQbz5WTV3B0w%40mail.gmail.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/CAMV2Rqo2Rvu201bbr9d-9ZQxqk7-UojjHxSgzfB2yyKkabk5CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Dan Eloff]

On Wed, Jul 10, 2019 at 7:54 AM Michael Jones 
wrote:

> unbuffered means nothing is sent until is is simultaneously received, so
> there is no limbo or race or uncertainty. one sender "wins" the select and
> the others remain blocked waiting.
>

So I'm correct then: "Now one of two things must happen, either the sender
blocks forever because nobody read the sent value"

The implications of that are that the sending and receiving code are
tightly coupled. It is not generally safe to send on a channel without
knowing how the receiver receives it, otherwise you can block forever like
in this case where the receiver is using a select and the timeout wins.
It's very easy to make your Go program leak goroutines that way - and I bet
a lot of serious software makes that mistake in practice. In this case the
sender would need to loop doing a non-blocking send because the receiver is
using a select, and then handle the case where the fd didn't get sent
within a reasonable time period (which makes no sense because no both
sender and receiver have a timeout baked in.)

Basically a simple send and receive are not too bad, but once you move
beyond that the world gets complex and fraught very quickly. Multi-threaded
programming is hard, and Go doesn't wave that burden away. No tools that
I've seen wave that away, so it's not really a failing of Go, it speaks
more to the inherit complexity of the domain.

-- 
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/CADz32dnDZt_npnZvCyfcGKOZ-sXHz-0V59hbhu%3DQbz5WTV3B0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[jake6502]

On Tuesday, July 9, 2019 at 12:27:32 PM UTC-4, Dan Eloff wrote:
>
> I couldn't use <-channel.Close since in my case the goroutine isn't 
> guaranteed to have something sent, so that would leak goroutines. I added a 
> cleanup goroutine to scan timed-out channels and close them, which solves 
> this problem. But now I can use that close as a signal to the receiver than 
> the a timeout happened, and eliminate the select and the race entirely. The 
> close can in rare cases race with the sender, but that's easily enough 
> fixed:
>
> // TrySend tries to send on a possibly closed channel and handles the 
> panic if necessary.
> // Returns true if conn was successfully sent over the channel.
> func (waiter *Waiter) TrySend(conn Connection) (sent bool) {
> defer func() {
> r := recover()
> sent = r != nil
> }()
> waiter.channel <- conn
> return
> }
>
>
So I guess the best thing to do in these cases is don't combine select with 
> sending unmanaged resources over a channel. It's probably worth warning 
> about this problem in the docs for select? It's not an obvious gotcha.
>

The best thing to do is to not use unmanaged resources. This is obviously 
not always possible, but when you *have* to use unmanaged resources, and 
you care about cleaning them up, you must use a lot of care. This is not a 
problem specific to select. It is possible to correctly use select with 
unmanaged resources. It just takes more thought, and a really solid 
understanding of the language and the principals of concurrency and 
ownership to get it right. 

-- 
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/683f05e8-00d3-4480-90f9-e8c114cb5ca1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[andrey mirtchovski]

the Go "Callback" struct may have completely different size and
alignment than the C.Foo one expected by C.initialize_engine.
therefore you want to construct the C version when calling
C.initialize_engine, and the Go version for everything else. Your call
may look something like this:

initStruct := C.calloc(1, sizeof(C.Foo))
initStruct.key_value_cb = C.callOnMeGo_cgo
initStrudct.data: C.int(1)

C.initialize_engine(pattern_db, module_path,
(*C.Foo)(unsafe.Pointer(initStruct)))

the Go Callback struct is not required unless you expect the callbacks
to change or be settable by library clients, in which case you'll need
to construct a more elaborate struct that implements locking and (at
least what I do) a map between callback names and interface{} pointing
to the callbacks sent by the library clients.

On Wed, Jul 10, 2019 at 8:14 AM Nitish Saboo  wrote:
>
> Hi Andrey,
>
> I am new to Go and cgo therefore did not exactly understand your point.
> Can you explain me in the context of the code that I had posted.It will 
> really help me to get hold of the things much better.
>
> Thanks,
> Nitish
>
> On Wed, Jul 10, 2019 at 5:19 PM andrey mirtchovski  
> wrote:
>>
>> what i do is have a similar struct in Go, and the original C one. here
>> 'callbacks' is the go one, and
>> "type Engine C.struct_cl_engine" is the opaque C one:
>>
>> https://github.com/mirtchovski/clamav/blob/master/callback.go#L63
>>
>> On Wed, Jul 10, 2019 at 5:25 AM Nitish Saboo  
>> wrote:
>> >
>> > Hi Andrey,
>> >
>> > I understand the issue here but how can I pass a callback function in a 
>> > struct to C code.I need a struct because I want to pass and an extra 
>> > parameter 'userdata' as well that I would require back as part of callback.
>> >
>> > Thanks,
>> > Nitish
>> >
>> > On Wed, Jul 10, 2019 at 4:39 PM andrey mirtchovski  
>> > wrote:
>> >>
>> >> i don't think you can use a go function directly in the callback. you
>> >> need a correctly-typed C helper to do it. at least that used to be the
>> >> case. see examples:
>> >>
>> >> https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
>> >> https://github.com/mirtchovski/clamav/blob/master/callback.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykXPuOuEo-TCXrJDPhRymX_xQC-B_Yrywz1QcvkoYYA9PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Include tests in binary and run them

[Tamás Gulácsi]

2019. július 10., szerda 6:43:39 UTC+2 időpontban Farid Zakaria a 
következőt írta:
>
> That's not bad and good to know. 
> Thanks for sharing !
>
> Fundamentally I want to include the tests in the main though executable 
> and then run testing.T myself in the normal main
> (Through a CLI command)
>
> I'm willing to accept it can't be done because ts not idiomatic but 
> thought I'd inquire. 
>
> On Tue, Jul 9, 2019, 9:40 PM Dan Kortschak  > wrote:
>
>> You can ask go test to leave the test executable for you to use later.
>> This is done with the -c flag. It will leave a -test binary
>> that takes all the flags that go test takes. This is at least similar
>> to what you are asking for.
>>
>> On Tue, 2019-07-09 at 18:35 -0700, farid@gmail.com  
>> wrote:
>> > We've written some diagnostic tests that we execute during the test
>> > phase 
>> > (go test) however I was wondering if there's an established
>> > pattern for how to include tests in the final binary and execute
>> > them 
>> > afterwards.
>> > 
>> > The analogous version in Java would be that you could create a "test
>> > JAR" 
>> > which contains the test classes and execute an XUnit framework
>> > (JUnit) 
>> > programmatically yourself run the tests.
>> > 
>>
>>
go test -c
and append yourpacakge.test onto yourpackage binary as a zip file with 
github.com/GeertJohan/go.rice/rice .

-- 
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/61ca5f8c-bef1-4db6-b929-5b904ad0a8ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: With Go modules, is that possible to reference a package which hasn't gotten a module support

[Tamás Gulácsi]

2019. július 10., szerda 11:00:48 UTC+2 időpontban Roman Gomoliako a 
következőt írta:
>
> thepudds,
>
> Thank you for the reply, thanks for the link!
>
> The follow-up question, what if the project isn't hosted anywhere yet? 
> Like, I have a module-opted package and it tries to use a local 
> module-unaware package. For a local module-aware package usage one would 
> use `replace` declaration. But I found it doesn't work for module-unaware 
> packages. Having the module-unaware anEnterpriseCompany.com/anotherProject 
> only 
> locally I can't ahieve a successfull compilation using `replace`:
>
> module anEnterpriseCompany.com/aProject
>
> require anEnterpriseCompany.com/anotherProject v0.0.0
>
> replace anEnterpriseCompany.com/anotherProject => 
> ../some/where/up/on/a/filesystem/anotherProject
>
> go 1.12
>
>
>
> On Tuesday, 9 July 2019 22:08:52 UTC+3, t hepudds wrote:
>>
>>
>> Hi Roman,
>>
>> > For a project considering switching to Go modules, is that possible to 
>> > reference a package without support of modules (doesn't have a 
>> go.mod/go.sum files)?
>>
>> Yes, as far I understand, that should usually work.
>>
>> Using your example of wanting to consume a non-module dependency 
>> anEnterpriseCompany.com/anotherProject, a module-based consumer should be 
>> able to do things like:
>>
>>   $ go get anEnterpriseCompany.com/anotherProject@
>>   $ go get anEnterpriseCompany.com/anotherProject@
>>   $ go get anEnterpriseCompany.com/anotherProject@latest
>>
>> There is a longer discussion in this FAQ on the Modules wiki:
>>
>>
>> https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-package-that-has-not-opted-in-to-modules
>>
>> Hope that helps,
>> thepudds
>>
>>
>> On Tuesday, July 9, 2019 at 9:21:48 AM UTC-4, Roman Gomoliako wrote:
>>>
>>> For a project considering switching to Go modules, is that possible to 
>>> reference a package without support of modules (doesn't have a 
>>> go.mod/go.sum files)?
>>>
>>> module anEnterpriseCompany.com/aProject
>>>
>>> require anEnterpriseCompany.com/anotherProject v0.0.0
>>>
>>> go 1.12
>>>
>>> "anEnterpriseCompany.com/anotherProject" can't be modified to support 
>>> Go modules for some internal reasons. Is there some ways to resolve this?
>>>
>>> Thanks,
>>>
>>> Roman
>>>
>>
If it's on your local filesystem, you can easily add a go.mod file to 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e791d0ce-dce0-491b-aebe-76019865bb66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Michael Jones]

unbuffered means nothing is sent until is is simultaneously received, so
there is no limbo or race or uncertainty. one sender "wins" the select and
the others remain blocked waiting.

On Wed, Jul 10, 2019 at 6:24 AM Dan Eloff  wrote:

> Maybe I'm wrong here in my understanding of unbuffered channels, but I
> don't think so:
>
> Matt says earlier: "Only a buffered channel can "hold" anything. If the
> channel is unbuffered, then you are guaranteed that another goroutine has
> at least received the item you sent when the send statement returns."
>
> I think at least in the simple case of `channel <- fd` this cannot be
> true, since that operation can only fail by panicking, and I beleive it
> will only panic if the channel is nil or closed. Now if you used a
> non-blocking send with a select, that would be a different story.
>
> So if you send over that channel it blocks
> the receiver wakes and runs the select
> but sees both channels ready
> picks the timeout channel at random
>
> Now one of two things must happen, either the sender blocks forever
> because nobody read the sent value, or the value gets lost to space and
> both receiver and sender continue on their merry ways.
>
> Am I wrong?
>
> -Dan
>
> --
> 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/CADz32d%3DOm96%2B7iZet%3DDL0AaNxYVYWO6Q%3DOgvzoYiWKdZpSipHg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.jo...@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/CALoEmQzqDs9XnDm-WHuUw7pr7j%2BB%3Df8PsozhoKsgXDQ7o%3DwjuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Include tests in binary and run them

[Sean Liao]

actually looking into it more since *_test,go files aren't included in a 
normal build you are probably better off just writing your tests as normal 
functions if you want them included in the final build

-- 
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/8c964535-e822-423f-b9b5-14032beff5f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Dan Eloff]

Maybe I'm wrong here in my understanding of unbuffered channels, but I
don't think so:

Matt says earlier: "Only a buffered channel can "hold" anything. If the
channel is unbuffered, then you are guaranteed that another goroutine has
at least received the item you sent when the send statement returns."

I think at least in the simple case of `channel <- fd` this cannot be true,
since that operation can only fail by panicking, and I beleive it will only
panic if the channel is nil or closed. Now if you used a non-blocking send
with a select, that would be a different story.

So if you send over that channel it blocks
the receiver wakes and runs the select
but sees both channels ready
picks the timeout channel at random

Now one of two things must happen, either the sender blocks forever because
nobody read the sent value, or the value gets lost to space and both
receiver and sender continue on their merry ways.

Am I wrong?

-Dan

-- 
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/CADz32d%3DOm96%2B7iZet%3DDL0AaNxYVYWO6Q%3DOgvzoYiWKdZpSipHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Dan Eloff]

>
> If the channel is unbuffered, there are two parties, S and R (Sender and
> Receiver). If the channel is buffered, it is another party, C (channel).
> The delivery chain is really S -> C -> R. Whereas in the unbuffered case,
> rendezvous means an atomic exchange of the resource (S -> R). Clearly,
> cleanup is the responsibility of the owner at any point in time. But the
> extra owner, C, means that you will have to handle the case where the
> resource is in limbo between the two systems. Since a channel cannot run
> code, you will have to either let S or R handle it, or introduce a proxy,
> P, who handles eventual cleanup on behalf of C.
>

Note in this case the channel is unbuffered, but there is no atomic
exchange because of the select statement which is inherently a race between
channels. If there are sends on multiple channels at close to the same
time, one will randomly be chosen and the other will eventually get garbage
collected with whatever was sent on it, unless you jump through hoops to
avoid that situation.

-- 
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/CADz32d%3Dd23C6G%3D3W8k1-u29kHzHcorZJsYSVA%2BTx5UVcJ-J_LQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Include tests in binary and run them

[Sean Liao]

I think testing.MainStart() does what you want though do nore the caveats

https://golang.org/pkg/testing/#MainStart

-- 
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/db5e1fec-8210-4000-bcc8-73576f586716%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Announcing a Go API for YottaDB

[tptan12345]

Hi Bhaskar,

>
I have a problem when I *go get lang.yottadb.com/go/yottadb*

There is an error:
"*could not determine kind of name for C.ydb_call_variadic_plist_func_st*"


Did I miss any step?


I am looking forward to your answer.


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/cd4c15d6-4593-4690-b780-0ca2206f2294%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Build kubernetes with gollvm

[Yuan Ting]

Thank you, I will continue to pay attention to it. Hope those bugs can be 
solved :)

Thank you again for your patience.

On Wednesday, July 10, 2019 at 7:56:03 PM UTC+8, Than McIntosh wrote:
>
> OK, thanks for checking on that.  
>
> Sounds like this is a new problem (not too surprising, since this is an 
> area of the compiler that is undergoing a lot of changes in recent weeks; 
> tip is a bit unstable).
>
> I have my hands full with a couple of other bugs that I am juggling right 
> now; filed issue https://github.com/golang/go/issues/33020 to track.
>
> Cheers, Than 
>
> On Tue, Jul 9, 2019 at 8:04 PM Yuan Ting > 
> wrote:
>
>> My gollvm version is
>> commit 29005f52b3501c489cb1653506cd479d5a178e98 (HEAD -> master, 
>> origin/master, origin/HEAD)
>> Author: Cherry Zhang <...>
>> Date:   Sat Jun 29 00:25:46 2019 -0400
>>
>> bridge: support builtin memset
>> 
>> Change-Id: I7321f57e0d58c0ff5c3a19f7cbf5721fabbf1263
>> Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/184439
>> Reviewed-by: Than McIntosh <...>
>>
>>
>> gofrontend version is 
>>
>> commit 7a8e10be0ddb8909ce25a264d03b24cee4df60cc (HEAD -> master, 
>> origin/master, origin/HEAD)
>> Author: Cherry Zhang <...>
>> Date:   Wed Jul 3 15:55:19 2019 -0400
>>
>> compiler: optimize 0,1,2-case select statement
>> 
>> For a select statement with zero-, one-, or two-case with a
>> default case, we can generate simpler code instead of calling the
>> generic selectgo. A zero-case select is just blocking the
>> execution. A one-case select is mostly just executing the case. A
>> two-case select with a default case is a non-blocking send or
>> receive. We add these special cases for lowering a select
>> statement.
>> 
>> Change-Id: I519d246a4a5ba6871bb303160bba1ec1e3074bd0
>> Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/184998
>> Reviewed-by: Ian Lance Taylor <...>
>>
>>
>> I retry to pull gollvm from https://go.googlesource.com/gollvm but it 
>> tells me I'm already up to date.
>>
>> Thanks.
>>
>> On Tuesday, July 9, 2019 at 10:03:11 PM UTC+8, Than McIntosh wrote:
>>>
>>> That stack trace looks a lot like
>>>
>>> https://github.com/golang/go/issues/32778
>>>
>>> which was fixed last week. What vintage is your gollvm?
>>>
>>> Thanks, Than
>>>
>>>
>>> On Tue, Jul 9, 2019 at 9:54 AM Yuan Ting  wrote:
>>>
 In addition, I also failed to build etcd. 

 $ git clone https://github.com/etcd-io/etcd.git
 $ cd etcd/ && ./build
 go build: when using gccgo toolchain, please pass linker flags using 
 -gccgoflags, not -ldflags
 # go.etcd.io/etcd/etcdserver/api/rafthttp
  #0 0x55ecc4cfa34a llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0xa6c34a)
  #1 0x55ecc4cf8124 llvm::sys::RunSignalHandlers() 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0xa6a124)
  #2 0x55ecc4cf8262 SignalHandler(int) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0xa6a262)
  #3 0x7fbbd49d5890 __restore_rt 
 (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
  #4 0x55ecc44f0940 Export::type_index(Type const*) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x262940)
  #5 0x55ecc44f0c31 Export::write_type(Type const*) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x262c31)
  #6 0x55ecc449f2e1 Named_type::do_export(Export*) const 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x2112e1)
  #7 0x55ecc44f10ce Export::write_type_definition(Type const*, int) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x2630ce)
  #8 0x55ecc44f1390 Export::write_types(int) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x263390)
  #9 0x55ecc44fcea0 
 Export::export_globals(std::__cxx11::basic_string>>> std::char_traits, std::allocator > const&, 
 std::__cxx11::basic_string, 
 std::allocator > const&, std::__cxx11::basic_string>>> std::char_traits, std::allocator > const&, 
 std::map, 
 std::allocator >, Package*, 
 std::less, 
 std::allocator > >, 
 std::allocator>>> std::char_traits, std::allocator > const, Package*> > > 
 const&, 
 std::map, 
 std::allocator >, Package*, 
 std::less, 
 std::allocator > >, 
 std::allocator>>> std::char_traits, std::allocator > const, Package*> > > 
 const&, 
 std::__cxx11::basic_string, 
 std::allocator > const&, Import_init_set const&, Bindings const*) 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x26eea0)
 #10 0x55ecc4457047 Gogo::do_exports() 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1c9047)
 #11 0x55ecc4441a90 go_parse_input_files(char const**, unsigned int, 
 bool, bool) (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1b3a90)
 #12 0x55ecc442ee69 gollvm::driver::CompileGoImpl::invokeFrontEnd() 
 (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1a0e69)
 #13 0x55ecc4436ee5 
 gollvm::driver::CompileGoImpl::performAction(gollvm::driver::Compilation&, 

Re: [go-nuts] Include tests in binary and run them

[Marko Ristin-Kaufmann]

Hi Farid,
If I understood your question correctly, you can play with build flags.
Alternatively, you can add a "-diagnostics" flag.


Consider also design-by-contract with contracts tested at run time (e.g.,
we use our own implementation https://github.com/Parquery/gocontracts; see
also other implementations in the readme).

Le mer. 10 juil. 2019 à 03:35,  a écrit :

> We've written some diagnostic tests that we execute during the test phase
> (go test) however I was wondering if there's an established
> pattern for how to include tests in the final binary and execute them
> afterwards.
>
> The analogous version in Java would be that you could create a "test JAR"
> which contains the test classes and execute an XUnit framework (JUnit)
> programmatically yourself run the tests.
>
> --
> 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/1441787d-eb2b-479e-821c-934694fbe6b7%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/CAGu4bVCbqzAuSCDeDQazgPOB52XcOYuDww7%3DkzQxQ1HtnHKBWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Build kubernetes with gollvm

['Than McIntosh' via golang-nuts]

OK, thanks for checking on that.

Sounds like this is a new problem (not too surprising, since this is an
area of the compiler that is undergoing a lot of changes in recent weeks;
tip is a bit unstable).

I have my hands full with a couple of other bugs that I am juggling right
now; filed issue https://github.com/golang/go/issues/33020 to track.

Cheers, Than

On Tue, Jul 9, 2019 at 8:04 PM Yuan Ting  wrote:

> My gollvm version is
> commit 29005f52b3501c489cb1653506cd479d5a178e98 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Cherry Zhang <...>
> Date:   Sat Jun 29 00:25:46 2019 -0400
>
> bridge: support builtin memset
>
> Change-Id: I7321f57e0d58c0ff5c3a19f7cbf5721fabbf1263
> Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/184439
> Reviewed-by: Than McIntosh <...>
>
>
> gofrontend version is
>
> commit 7a8e10be0ddb8909ce25a264d03b24cee4df60cc (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Cherry Zhang <...>
> Date:   Wed Jul 3 15:55:19 2019 -0400
>
> compiler: optimize 0,1,2-case select statement
>
> For a select statement with zero-, one-, or two-case with a
> default case, we can generate simpler code instead of calling the
> generic selectgo. A zero-case select is just blocking the
> execution. A one-case select is mostly just executing the case. A
> two-case select with a default case is a non-blocking send or
> receive. We add these special cases for lowering a select
> statement.
>
> Change-Id: I519d246a4a5ba6871bb303160bba1ec1e3074bd0
> Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/184998
> Reviewed-by: Ian Lance Taylor <...>
>
>
> I retry to pull gollvm from https://go.googlesource.com/gollvm but it
> tells me I'm already up to date.
>
> Thanks.
>
> On Tuesday, July 9, 2019 at 10:03:11 PM UTC+8, Than McIntosh wrote:
>>
>> That stack trace looks a lot like
>>
>> https://github.com/golang/go/issues/32778
>>
>> which was fixed last week. What vintage is your gollvm?
>>
>> Thanks, Than
>>
>>
>> On Tue, Jul 9, 2019 at 9:54 AM Yuan Ting  wrote:
>>
>>> In addition, I also failed to build etcd.
>>>
>>> $ git clone https://github.com/etcd-io/etcd.git
>>> $ cd etcd/ && ./build
>>> go build: when using gccgo toolchain, please pass linker flags using
>>> -gccgoflags, not -ldflags
>>> # go.etcd.io/etcd/etcdserver/api/rafthttp
>>>  #0 0x55ecc4cfa34a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0xa6c34a)
>>>  #1 0x55ecc4cf8124 llvm::sys::RunSignalHandlers()
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0xa6a124)
>>>  #2 0x55ecc4cf8262 SignalHandler(int)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0xa6a262)
>>>  #3 0x7fbbd49d5890 __restore_rt
>>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
>>>  #4 0x55ecc44f0940 Export::type_index(Type const*)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x262940)
>>>  #5 0x55ecc44f0c31 Export::write_type(Type const*)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x262c31)
>>>  #6 0x55ecc449f2e1 Named_type::do_export(Export*) const
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x2112e1)
>>>  #7 0x55ecc44f10ce Export::write_type_definition(Type const*, int)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x2630ce)
>>>  #8 0x55ecc44f1390 Export::write_types(int)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x263390)
>>>  #9 0x55ecc44fcea0
>>> Export::export_globals(std::__cxx11::basic_string>> std::char_traits, std::allocator > const&,
>>> std::__cxx11::basic_string,
>>> std::allocator > const&, std::__cxx11::basic_string>> std::char_traits, std::allocator > const&,
>>> std::map,
>>> std::allocator >, Package*,
>>> std::less,
>>> std::allocator > >,
>>> std::allocator>> std::char_traits, std::allocator > const, Package*> > > const&,
>>> std::map,
>>> std::allocator >, Package*,
>>> std::less,
>>> std::allocator > >,
>>> std::allocator>> std::char_traits, std::allocator > const, Package*> > > const&,
>>> std::__cxx11::basic_string,
>>> std::allocator > const&, Import_init_set const&, Bindings const*)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x26eea0)
>>> #10 0x55ecc4457047 Gogo::do_exports()
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1c9047)
>>> #11 0x55ecc4441a90 go_parse_input_files(char const**, unsigned int,
>>> bool, bool) (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1b3a90)
>>> #12 0x55ecc442ee69 gollvm::driver::CompileGoImpl::invokeFrontEnd()
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1a0e69)
>>> #13 0x55ecc4436ee5
>>> gollvm::driver::CompileGoImpl::performAction(gollvm::driver::Compilation&,
>>> gollvm::driver::Action const&, llvm::SmallVector>> 3u> const&, gollvm::driver::Artifact const&)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x1a8ee5)
>>> #14 0x55ecc442950f
>>> gollvm::driver::Driver::processAction(gollvm::driver::Action*,
>>> gollvm::driver::Compilation&, bool)
>>> (/home/yt/LLVMsvn/install/bin/llvm-goc+0x19b50f)
>>> #15 0x55ecc44296af
>>> 

Re: [go-nuts] Passing Struct from Go to C

[andrey mirtchovski]

what i do is have a similar struct in Go, and the original C one. here
'callbacks' is the go one, and
"type Engine C.struct_cl_engine" is the opaque C one:

https://github.com/mirtchovski/clamav/blob/master/callback.go#L63

On Wed, Jul 10, 2019 at 5:25 AM Nitish Saboo  wrote:
>
> Hi Andrey,
>
> I understand the issue here but how can I pass a callback function in a 
> struct to C code.I need a struct because I want to pass and an extra 
> parameter 'userdata' as well that I would require back as part of callback.
>
> Thanks,
> Nitish
>
> On Wed, Jul 10, 2019 at 4:39 PM andrey mirtchovski  
> wrote:
>>
>> i don't think you can use a go function directly in the callback. you
>> need a correctly-typed C helper to do it. at least that used to be the
>> case. see examples:
>>
>> https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
>> https://github.com/mirtchovski/clamav/blob/master/callback.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykVRS61Z5d-60QKTtNm%2BGO2TNbWeteb6KGNQq0490f8BVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Avoiding resource leaks with racing channels

[Jesper Louis Andersen]

On Tue, Jul 9, 2019 at 6:14 AM Daniel Eloff  wrote:

> If a select statement has multiple channels ready when it runs, then it
> will choose one at a random. So if you fire something across a channel that
> holds a resource, like an open file descriptor - you have no guarantees
> that the other end of the channel receives it. The (possibly full) channel
> will get garbage collected later and the resource will leak in that case.
>
>
To me, the real question is about "who owns the resource?"

If the channel is unbuffered, there are two parties, S and R (Sender and
Receiver). If the channel is buffered, it is another party, C (channel).
The delivery chain is really S -> C -> R. Whereas in the unbuffered case,
rendezvous means an atomic exchange of the resource (S -> R). Clearly,
cleanup is the responsibility of the owner at any point in time. But the
extra owner, C, means that you will have to handle the case where the
resource is in limbo between the two systems. Since a channel cannot run
code, you will have to either let S or R handle it, or introduce a proxy,
P, who handles eventual cleanup on behalf of C.

I think not introducing C in the first place is the best way to go if
possible. Resource handling is a place where things need to be correct
before being asynchronous.

-- 
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/CAGrdgiVENqoANOj6xLrPYwfi_0kRXXk3zp%2B3DQO5Std6ZzKiqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[Nitish Saboo]

Hi Andrey,

I understand the issue here but how can I pass a callback function in a
struct to C code.I need a struct because I want to pass and an extra
parameter 'userdata' as well that I would require back as part of callback.

Thanks,
Nitish

On Wed, Jul 10, 2019 at 4:39 PM andrey mirtchovski 
wrote:

> i don't think you can use a go function directly in the callback. you
> need a correctly-typed C helper to do it. at least that used to be the
> case. see examples:
>
> https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
> https://github.com/mirtchovski/clamav/blob/master/callback.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALjMrq7Xsz7PB3T3SpZD%3Dg%3DtXahAPMjo7k77HGmDkDKf2_p_bQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[andrey mirtchovski]

i don't think you can use a go function directly in the callback. you
need a correctly-typed C helper to do it. at least that used to be the
case. see examples:

https://github.com/mirtchovski/clamav/blob/master/cfuncs.go
https://github.com/mirtchovski/clamav/blob/master/callback.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAK4xykXyfti3P-49W-jbM9s_Jssb6m0w_FvN7JM6%3DR1s8mdGcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[Nitish Saboo]

Hi Tamas,

I made it *C.Foo but still getting the error.

main.go
===

type Callback struct {
Func func(*C.char , *C.char , C.size_t, C.int)
UserData int32
}

Calling C code in the following manner
=

C.initialize_engine(pattern_db, module_path,
(*C.Foo)(unsafe.Pointer({
Func: C.callOnMeGo_cgo
UserData: C.int(1),
})))

//export ParsedData
func ParsedData(key *C.char, value *C.char, value_len C.size_t, work C.int)
{
fmt.Println("WORK:")
fmt.Print()
//performing some operation here
}

cfunc.go
=

package main

/*

#include 

// The gateway function
void callOnMeGo_cgo(char *key, char *value, size_t value_len, int work)
{
//printf("C.callOnMeGo_cgo(): called");
void ParsedData(const char *key, const char *value, size_t value_len, int
work);
ParsedData(key, value, value_len, work);
}
*/
import "C"



syslog-node.h
===
#ifndef _TEST_H_
#define _TEST_H_

#include 

typedef void (*key_value_cb)(const char* key, const char* value, size_t
value_len, int work);
typedef struct Foo{
key_value_cb cbnitish;
int data;
}Foo;
int initialize_engine(const char* filename, const char* module_path, Foo
*cb);
int reload_pattern_db(const char* filename, Foo *cb);

#endif

syslog-node.c
===

gboolean pdbtool_accumulate_fields(NVHandle handle, const gchar *name,
const gchar *value, gssize length, gpointer user_data)
{
  user_data->cbnitish(name, value, length, user_data->data);// Callback
happening here
  return FALSE;
}

Eventually user_data will get the instance of the struct.

Looks like there is some issue with my  struct declaration in Go.Can some
please guide me  as in what is the issue ?


Error:

go build -v -x main.go cfuncs.go
WORK=/tmp/go-build037176041
command-line-arguments
mkdir -p $WORK/b001/
cd /home/nsaboo/Documents/goworkspace/src/poc
pkg-config --cflags -- syslog-ng eventlog
pkg-config --libs -- syslog-ng eventlog
CGO_LDFLAGS='"-g" "-O2" "syslog-node.so" "-L/usr/local/lib/" "-lsyslog-ng"
"-L/usr/local/lib/syslog-ng" "-ldbparser" "-L/usr/local/lib"
"-Wl,--export-dynamic" "-lgmodule-2.0" "-pthread" "-lgthread-2.0"
"-pthread" "-lglib-2.0" "-lsyslog-ng" "-lglib-2.0" "-levtlog"'
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/b001/ -importpath
command-line-arguments -- -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I
$WORK/b001/ -g -O2 -I/usr/local/include/ ./main.go ./cfuncs.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x001.o -c _cgo_export.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x002.o -c main.cgo2.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x003.o -c cfuncs.cgo2.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_cgo_main.o -c _cgo_main.c
cd /home/nsaboo/Documents/goworkspace/src/poc
TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o
$WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o
$WORK/b001/_x002.o $WORK/b001/_x003.o -g -O2 syslog-node.so
-L/usr/local/lib/ -lsyslog-ng -L/usr/local/lib/syslog-ng -ldbparser
-L/usr/local/lib -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgthread-2.0
-pthread -lglib-2.0 -lsyslog-ng -lglib-2.0 -levtlog
TERM='dumb' /usr/local/go/pkg/tool/linux_amd64/cgo -dynpackage main
-dynimport $WORK/b001/_cgo_.o -dynout $WORK/b001/_cgo_import.go
cat >$WORK/b001/importcfg << 

[go-nuts] Re: With Go modules, is that possible to reference a package which hasn't gotten a module support

[Roman Gomoliako]

thepudds,

Thank you for the reply, thanks for the link!

The follow-up question, what if the project isn't hosted anywhere yet? 
Like, I have a module-opted package and it tries to use a local 
module-unaware package. For a local module-aware package usage one would 
use `replace` declaration. But I found it doesn't work for module-unaware 
packages. Having the module-unaware anEnterpriseCompany.com/anotherProject only 
locally I can't ahieve a successfull compilation using `replace`:

module anEnterpriseCompany.com/aProject

require anEnterpriseCompany.com/anotherProject v0.0.0

replace anEnterpriseCompany.com/anotherProject => 
../some/where/up/on/a/filesystem/anotherProject

go 1.12



On Tuesday, 9 July 2019 22:08:52 UTC+3, t hepudds wrote:
>
>
> Hi Roman,
>
> > For a project considering switching to Go modules, is that possible to 
> > reference a package without support of modules (doesn't have a 
> go.mod/go.sum files)?
>
> Yes, as far I understand, that should usually work.
>
> Using your example of wanting to consume a non-module dependency 
> anEnterpriseCompany.com/anotherProject, a module-based consumer should be 
> able to do things like:
>
>   $ go get anEnterpriseCompany.com/anotherProject@
>   $ go get anEnterpriseCompany.com/anotherProject@
>   $ go get anEnterpriseCompany.com/anotherProject@latest
>
> There is a longer discussion in this FAQ on the Modules wiki:
>
>
> https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-package-that-has-not-opted-in-to-modules
>
> Hope that helps,
> thepudds
>
>
> On Tuesday, July 9, 2019 at 9:21:48 AM UTC-4, Roman Gomoliako wrote:
>>
>> For a project considering switching to Go modules, is that possible to 
>> reference a package without support of modules (doesn't have a 
>> go.mod/go.sum files)?
>>
>> module anEnterpriseCompany.com/aProject
>>
>> require anEnterpriseCompany.com/anotherProject v0.0.0
>>
>> go 1.12
>>
>> "anEnterpriseCompany.com/anotherProject" can't be modified to support Go 
>> modules for some internal reasons. Is there some ways to resolve this?
>>
>> Thanks,
>>
>> Roman
>>
>

-- 
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/fc3af77b-2dee-420b-acd4-fcd3d4bbdf03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Passing Struct from Go to C

[Tamás Gulácsi]

*C.foo

-- 
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/32a3a3c6-78e2-492d-9542-8a1c29deb600%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: On the topic of try() and errors

[pierre . curto]

Interesting reasoning Michael...

Le mercredi 10 juillet 2019 01:46:03 UTC+2, Michael Jones a écrit :
>
> In the hope of elevating the discussion of late, I've made a little speech 
> as one might do at a lunchtime discussion with students or colleagues. 
> Maybe this will make sense to some kindred spirits here...
>
> Thoughts about facilitating error handling in Go(), and the try() proposal 
> in particular, have inspired a great deal of thought and sharing, with 
> heated disapproval by some and, it seems, general approval by many. In a 
> sense this is all premature--the proposal is a test and the good/bad 
> judgement will come over time.
>
> One aspect of the topic that seems to cause alarms is the fact it looks 
> like and in some ways acts like error-related try() features in C, C++, C#, 
> Java, JavaScript, and SQL. This invites presumption of harm through 
> similarity. The goal here is to offer *an entirely different way to think 
> about the issue*. In this alternate view, some aspects are more readily 
> understood and extensions and refinements more inviting. So, from here out, 
> it is not about errors.
>
> In 1969, C. A. R. Hoare, Mr. Quicksort and the father of the ideas in Go's 
> channels, was inspired to seek a logical, mathematical basis for computer 
> programming. He, Nicholas Wirth, Ole-Johan Dahl, and Edsger Dijkstra were 
> marching down this path and they all realized that *guarded computation* 
> was important; that statements of provable truth are the basis of rigor.
>
> [image: assert.002.jpeg]
> In my Fig. 1 here, you can see the problem, the result of math.Sqrt() is 
> valid or invalid depending on the status of x; x in the domain of 
> non-negative real numbers means Sqrt is good and x out of that domain means 
> the opposite. 
>
> As a starting point, Hoare and the others embraced AJT's call for 
> *assertions*, such as is shown in Fig 2. as is typical now and then. 
> Let's call it an *assertion statement*. (Hoare actually proposed a 
> keyword version, "assert ;" that would return with 
> prejudice if the bool was false.)
>
> We all know this. But, are other kinds of assertions interesting, beyond 
> statements? Here are two others, the *assertion expression* and the 
> *assertion 
> assignment,* along with Alan Turing's original 1949 appeal for 
> assertions: 
>
> [image: assert.003.jpeg]
> What I've shown here is not something I'm aware of being implemented 
> before, but both Fig. 3 and 4 show consistent specializations of assertion 
> statement to substatements; in the one case, to a function's arguments and 
> in the other, to the values being assigned. If we had these inline 
> assertions, we could call functions with range checking clear, local, and 
> concise, and assign return values with stated conditions known to have been 
> proven. To quote Turing, "...from which the correctness of the whole 
> program easily follows."
>
> There is a subtle shift here, from asserting that x>=0 which is specific, 
> to insisting that Sqrt() has not complained about a domain error, which is 
> specific in meaning but omits specifying what that range might be. 
> (AssertDomain(math.Log(x)) would have the same meaning but a different 
> domain.)
>
> Perhaps Figure 4 looks familiar to you. Compare to Fig. 5...
>
> [image: assert.004.jpeg]
> ...as you can see, we've come to the great debate, but along a different 
> path. If you can pretend that "try" did not have a decade of bitter 
> meanings from other languages and common misuse, then you can see try as 
> nothing more than an assertion assignment. In this view, disjoint from the 
> error type, we can also see that other "same meaning different detail" uses 
> could make sense, just like the Domain assertion of Fig 4. If I have test 
> for error value != nil, then why not test for non-error pointer value == 
> nil as in Fig. 6. Not only does this seem useful and thematically 
> consistent, it happens to already be in Go!
>
> Where you ask? Where has this nil-pointer-try been hiding? Right here:
> [image: assert.005.jpeg]
> So now we reach my destination: Go's "must" is an assertion at its heart. 
> That your program is executing means "it must have or else we'd not be 
> here." It is an extreme, fatal must. Assertions considered previously range 
> from the fatal-must of the assertion statement to the return-with-error of 
> the assertion assignment.
>
> Should "try" be "must"? Should musts take an optional error argument that 
> defines what is returned? Is there a beautiful way to unify compile-time 
> must, init-time must, and runtime must? I'll not comment as my goal here is 
> not to propose, rather to encourage each of us to offer insights that 
> convey the wisdom of those who came before us as well as learnings from our 
> own experience.
>
> Michael
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

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

Re: [go-nuts] Passing Struct from Go to C

[Nitish Saboo]

Hi,

Looks like I was able to resolve the C error.I am getting the following Go
error while running 'make' command:

gcc -L/usr/local/lib -lsyslog-ng -o syslog-node.so
-L/usr/local/lib/syslog-ng -ldbparser -c `pkg-config --libs --cflags
glib-2.0` -I/usr/local/include/syslog-ng/ -I./syslog-ng-3.6.2/
-I/usr/local/include/eventlog/ syslog-node.c
go build -v -x main.go cfuncs.go
WORK=/tmp/go-build873967443
command-line-arguments
mkdir -p $WORK/b001/
cd /home/nsaboo/Documents/goworkspace/src/poc
pkg-config --cflags -- syslog-ng eventlog
pkg-config --libs -- syslog-ng eventlog
CGO_LDFLAGS='"-g" "-O2" "syslog-node.so" "-L/usr/local/lib/" "-lsyslog-ng"
"-L/usr/local/lib/syslog-ng" "-ldbparser" "-L/usr/local/lib"
"-Wl,--export-dynamic" "-lgmodule-2.0" "-pthread" "-lgthread-2.0"
"-pthread" "-lglib-2.0" "-lsyslog-ng" "-lglib-2.0" "-levtlog"'
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/b001/ -importpath
command-line-arguments -- -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I
$WORK/b001/ -g -O2 -I/usr/local/include/ ./main.go ./cfuncs.go
cd $WORK
gcc -fno-caret-diagnostics -c -x c - || true
gcc -Qunused-arguments -c -x c - || true
gcc -fdebug-prefix-map=a=b -c -x c - || true
gcc -gno-record-gcc-switches -c -x c - || true
cd $WORK/b001
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x001.o -c _cgo_export.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x002.o -c main.cgo2.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_x003.o -c cfuncs.cgo2.c
TERM='dumb' gcc -I /home/nsaboo/Documents/goworkspace/src/poc -fPIC -m64
-pthread -fmessage-length=0 -fdebug-prefix-map=$WORK/b001=/tmp/go-build
-gno-record-gcc-switches -I/usr/local/include/syslog-ng
-I/usr/local/include/syslog-ng/ivykis -I/usr/local/include/eventlog
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I ./
-g -O2 -I/usr/local/include/ -o ./_cgo_main.o -c _cgo_main.c
cd /home/nsaboo/Documents/goworkspace/src/poc
TERM='dumb' gcc -I . -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=$WORK/b001=/tmp/go-build -gno-record-gcc-switches -o
$WORK/b001/_cgo_.o $WORK/b001/_cgo_main.o $WORK/b001/_x001.o
$WORK/b001/_x002.o $WORK/b001/_x003.o -g -O2 syslog-node.so
-L/usr/local/lib/ -lsyslog-ng -L/usr/local/lib/syslog-ng -ldbparser
-L/usr/local/lib -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgthread-2.0
-pthread -lglib-2.0 -lsyslog-ng -lglib-2.0 -levtlog
TERM='dumb' /usr/local/go/pkg/tool/linux_amd64/cgo -dynpackage main
-dynimport $WORK/b001/_cgo_.o -dynout $WORK/b001/_cgo_import.go
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile bufio=/usr/local/go/pkg/linux_amd64/bufio.a
packagefile encoding/json=/usr/local/go/pkg/linux_amd64/encoding/json.a
packagefile fmt=/usr/local/go/pkg/linux_amd64/fmt.a
packagefile os=/usr/local/go/pkg/linux_amd64/os.a
packagefile path=/usr/local/go/pkg/linux_amd64/path.a
packagefile runtime=/usr/local/go/pkg/linux_amd64/runtime.a
packagefile time=/usr/local/go/pkg/linux_amd64/time.a
packagefile runtime/cgo=/usr/local/go/pkg/linux_amd64/runtime/cgo.a
packagefile syscall=/usr/local/go/pkg/linux_amd64/syscall.a
EOF
/usr/local/go/pkg/tool/linux_amd64/compile -o $WORK/b001/_pkg_.a -trimpath
$WORK/b001 -p main -buildid hIEYVdT7igzjOGrFONpW/hIEYVdT7igzjOGrFONpW
-goversion go1.12.4 -D _/home/nsaboo/Documents/goworkspace/src/poc
-importcfg $WORK/b001/importcfg -pack -c=2 $WORK/b001/_cgo_gotypes.go
$WORK/b001/main.cgo1.go $WORK/b001/cfuncs.cgo1.go $WORK/b001/_cgo_import.go
# command-line-arguments
./main.go:91:57: cannot convert unsafe.Pointer(*Callback literal) (type
unsafe.Pointer) to type _Ctype_struct_Foo
./main.go:91:84: cannot use _Cgo_ptr(_Cfpvar_fp_callOnMeGo_cgo) (type
unsafe.Pointer) as type func(*_Ctype_char, *_Ctype_char, _Ctype_ulong,
_Ctype_int) in field value
./main.go:91:128: cannot use _Ctype_int(1) (type _Ctype_int) as type int32
in field value
./main.go:166:66: cannot convert 

[go-nuts] Passing Struct from Go to C

[Nitish Saboo]

Hi,

I am trying to pass a Struct from Go to C (this is cgo).I m passing a 
callback function in that struct that will be called from C code to Go.


main.go
===

type Callback struct {
Func func(*C.char , *C.char , C.size_t, C.int)
UserData int32
}

Calling C code in the following manner
=

C.initialize_engine(pattern_db, module_path, 
(C.Foo)(unsafe.Pointer({
Func: C.callOnMeGo_cgo,
UserData: C.int(1),
})))

//export ParsedData
func ParsedData(key *C.char, value *C.char, value_len C.size_t, work C.int) 
{
fmt.Println("WORK:")
fmt.Print()
//performing some operation here
}

cfunc.go
=

package main

/*

#include 

// The gateway function
void callOnMeGo_cgo(char *key, char *value, size_t value_len, int work)
{
//printf("C.callOnMeGo_cgo(): called");
void ParsedData(const char *key, const char *value, size_t value_len, int 
work);
ParsedData(key, value, value_len, work);
}
*/
import "C"



syslog-node.h
===
#ifndef _TEST_H_
#define _TEST_H_

#include 

typedef void (*key_value_cb)(const char* key, const char* value, size_t 
value_len, int work);
typedef struct Foo{
key_value_cb cbnitish;
int data;
}Foo;
int initialize_engine(const char* filename, const char* module_path, Foo 
*cb);
int reload_pattern_db(const char* filename, Foo *cb);

#endif

syslog-node.c
===

gboolean pdbtool_accumulate_fields(NVHandle handle, const gchar *name, 
const gchar *value, gssize length, gpointer user_data)
{
  user_data->cbnitish(name, value, length, user_data->data);// Callback 
happening here
  return FALSE;
}

Eventually user_data will get the instance of the struct.


Getting following error during make command:
==

nsaboo@ubuntu:~/Documents/goworkspace/src/poc$ make
gcc -L/usr/local/lib -lsyslog-ng -o syslog-node.so 
-L/usr/local/lib/syslog-ng -ldbparser -c `pkg-config --libs --cflags 
glib-2.0` -I/usr/local/include/syslog-ng/ -I./syslog-ng-3.6.2/ 
-I/usr/local/include/eventlog/ syslog-node.c
syslog-node.c: In function ‘pdbtool_accumulate_fields’:
syslog-node.c:33:12: warning: dereferencing ‘void *’ pointer
   user_data->cbnitish(name, value, length, user_data->data);
^~
syslog-node.c:33:12: error: request for member ‘cbnitish’ in something not 
a structure or union
syslog-node.c:33:53: warning: dereferencing ‘void *’ pointer
   user_data->cbnitish(name, value, length, user_data->data);
 ^~
syslog-node.c:33:53: error: request for member ‘data’ in something not a 
structure or union
makefile:12: recipe for target 'syslog-node.so' failed
make: *** [syslog-node.so] Error 1

Can someone please guide me here ?

Thanks,
Nitish

-- 
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/c8b2f46a-78e2-4306-8e96-6c30bb7529f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.