Re: [go-nuts] Re: Getting '[signal SIGSEGV: segmentation violation code=0x1 addr=0xffffffff04d07885 pc=0x7fe62f2d2922]' during cgo_call

[K.S. Bhaskar]

I think you may be right, and I think I was barking up the wrong tree. 
Sorry.

Regards
– Bhaskar

On Monday, February 17, 2020 at 11:20:07 AM UTC-5, Nitish Saboo wrote:
>
> Hi,
>
> How can runtime.Keepalive be helpful here ?
>
> Thanks,
> Nitish
>
> On Mon, Feb 17, 2020 at 9:14 PM K.S. Bhaskar  > wrote:
>
>> See whether runtime.Keepalive (https://golang.org/pkg/runtime/#KeepAlive) 
>> helps.
>>
>> Regards
>> – Bhaskar
>>
>> On Monday, February 17, 2020 at 10:33:42 AM UTC-5, Nitish Saboo wrote:
>>>
>>> Hi,
>>>
>>> These are my Go and C functions.I cannot explicitly garbage collect the 
>>> C method before use, not sure if that is the issue.
>>> The first line in the 'match' method itself is not getting printed.
>>>
>>> void match(const gchar *x, size_t len_x, const gchar *y, size_t len_y)
>>> {
>>>  printf("Reached match method ");
>>>   LogMessage *msg = log_msg_new_empty();
>>>   log_msg_set_value(msg, LM_V_MESSAGE, x, len_x);
>>>   log_msg_set_value(msg, LM_V_PROGRAM, y, len_y);
>>>   pattern_db_process(db_pattern, msg);
>>>   log_msg_unref(msg);
>>>
>>> }
>>>
>>> func (obj parser) ParseMessage(x string, y string)
>>> {
>>>
>>>   app := C.CString(x)
>>>   defer C.free(unsafe.Pointer(app))
>>>   msg := C.CString(y)
>>>   defer C.free(unsafe.Pointer(msg))
>>>   C.match(msg, C.size_t(len(y)), app, C.size_t(len(x)))
>>> }
>>>
>>> Thanks,
>>> Nitish
>>>
>>> On Mon, Feb 17, 2020 at 8:14 PM K.S. Bhaskar  wrote:
>>>
>>>> Chances are that a parameter or structure you are passing from Go to C 
>>>> is getting garbage collected by Go before the C code is done with it. Read 
>>>> the CGO documentaton – it's dense, but every sentence, every word, has a 
>>>> purpose.
>>>>
>>>> In case it helps, take a look at the video of my recent talk at FOSDEM 
>>>> 2020 in Brussels (https://fosdem.org/2020/schedule/event/dragonscgo/); 
>>>> slides at 
>>>> https://docs.yottadb.com/Presentations/200202-1DragonsofCGOFOSDEM.pdf
>>>>
>>>> Regards
>>>> – Bhaskar
>>>>
>>>> On Monday, February 17, 2020 at 9:33:00 AM UTC-5, Nitish Saboo wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> This is my go env:
>>>>>
>>>>> nsaboo@ubuntu:~$ go version
>>>>> go version go1.12.4 linux/amd64
>>>>> nsaboo@ubuntu:~$ go env
>>>>> GOARCH="amd64"
>>>>> GOBIN=""
>>>>> GOCACHE="/home/nsaboo/.cache/go-build"
>>>>> GOEXE=""
>>>>> GOFLAGS=""
>>>>> GOHOSTARCH="amd64"
>>>>> GOHOSTOS="linux"
>>>>> GOOS="linux"
>>>>> GOPATH="/home/nsaboo/Documents/goworkspace"
>>>>> GOPROXY=""
>>>>> GORACE=""
>>>>> GOROOT="/usr/local/go"
>>>>> GOTMPDIR=""
>>>>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>>>>> GCCGO="gccgo"
>>>>> CC="gcc"
>>>>> CXX="g++"
>>>>> CGO_ENABLED="1"
>>>>> GOMOD=""
>>>>> CGO_CFLAGS="-g -O2"
>>>>> CGO_CPPFLAGS=""
>>>>> CGO_CXXFLAGS="-g -O2"
>>>>> CGO_FFLAGS="-g -O2"
>>>>> CGO_LDFLAGS="-g -O2"
>>>>> PKG_CONFIG="pkg-config"
>>>>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>>>>> -fdebug-prefix-map=/tmp/go-build659816641=/tmp/go-build 
>>>>> -gno-record-gcc-switches"
>>>>>
>>>>> 'go build -v -x main.go' went through fine and the binary(main) was 
>>>>> created successfully.
>>>>>
>>>>> While making a cgo call from go code to C code I am getting the 
>>>>> following error:
>>>>>
>>>>> nsaboo@ubuntu:~/Documents/goworkspace/src/poc$ ./main 
>>>>> GOMAZPROCS : 2
>>>>> START
>>>>> DIR: /home/nsaboo/Documents/goworkspace/src/poc
>>>>> Reached C module path :/usr/local/lib/syslog-ng
>>>>> Reached C filepath 
>>>>&g

Re: [go-nuts] Re: Getting '[signal SIGSEGV: segmentation violation code=0x1 addr=0xffffffff04d07885 pc=0x7fe62f2d2922]' during cgo_call

[K.S. Bhaskar]

See whether runtime.Keepalive (https://golang.org/pkg/runtime/#KeepAlive) 
helps.

Regards
– Bhaskar

On Monday, February 17, 2020 at 10:33:42 AM UTC-5, Nitish Saboo wrote:
>
> Hi,
>
> These are my Go and C functions.I cannot explicitly garbage collect the C 
> method before use, not sure if that is the issue.
> The first line in the 'match' method itself is not getting printed.
>
> void match(const gchar *x, size_t len_x, const gchar *y, size_t len_y)
> {
>  printf("Reached match method ");
>   LogMessage *msg = log_msg_new_empty();
>   log_msg_set_value(msg, LM_V_MESSAGE, x, len_x);
>   log_msg_set_value(msg, LM_V_PROGRAM, y, len_y);
>   pattern_db_process(db_pattern, msg);
>   log_msg_unref(msg);
>
> }
>
> func (obj parser) ParseMessage(x string, y string)
> {
>
>   app := C.CString(x)
>   defer C.free(unsafe.Pointer(app))
>   msg := C.CString(y)
>   defer C.free(unsafe.Pointer(msg))
>   C.match(msg, C.size_t(len(y)), app, C.size_t(len(x)))
> }
>
> Thanks,
> Nitish
>
> On Mon, Feb 17, 2020 at 8:14 PM K.S. Bhaskar  > wrote:
>
>> Chances are that a parameter or structure you are passing from Go to C is 
>> getting garbage collected by Go before the C code is done with it. Read the 
>> CGO documentaton – it's dense, but every sentence, every word, has a 
>> purpose.
>>
>> In case it helps, take a look at the video of my recent talk at FOSDEM 
>> 2020 in Brussels (https://fosdem.org/2020/schedule/event/dragonscgo/); 
>> slides at 
>> https://docs.yottadb.com/Presentations/200202-1DragonsofCGOFOSDEM.pdf
>>
>> Regards
>> – Bhaskar
>>
>> On Monday, February 17, 2020 at 9:33:00 AM UTC-5, Nitish Saboo wrote:
>>>
>>> Hi,
>>>
>>> This is my go env:
>>>
>>> nsaboo@ubuntu:~$ go version
>>> go version go1.12.4 linux/amd64
>>> nsaboo@ubuntu:~$ go env
>>> GOARCH="amd64"
>>> GOBIN=""
>>> GOCACHE="/home/nsaboo/.cache/go-build"
>>> GOEXE=""
>>> GOFLAGS=""
>>> GOHOSTARCH="amd64"
>>> GOHOSTOS="linux"
>>> GOOS="linux"
>>> GOPATH="/home/nsaboo/Documents/goworkspace"
>>> GOPROXY=""
>>> GORACE=""
>>> GOROOT="/usr/local/go"
>>> GOTMPDIR=""
>>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>>> GCCGO="gccgo"
>>> CC="gcc"
>>> CXX="g++"
>>> CGO_ENABLED="1"
>>> GOMOD=""
>>> CGO_CFLAGS="-g -O2"
>>> CGO_CPPFLAGS=""
>>> CGO_CXXFLAGS="-g -O2"
>>> CGO_FFLAGS="-g -O2"
>>> CGO_LDFLAGS="-g -O2"
>>> PKG_CONFIG="pkg-config"
>>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>>> -fdebug-prefix-map=/tmp/go-build659816641=/tmp/go-build 
>>> -gno-record-gcc-switches"
>>>
>>> 'go build -v -x main.go' went through fine and the binary(main) was 
>>> created successfully.
>>>
>>> While making a cgo call from go code to C code I am getting the 
>>> following error:
>>>
>>> nsaboo@ubuntu:~/Documents/goworkspace/src/poc$ ./main 
>>> GOMAZPROCS : 2
>>> START
>>> DIR: /home/nsaboo/Documents/goworkspace/src/poc
>>> Reached C module path :/usr/local/lib/syslog-ng
>>> Reached C filepath 
>>> :/home/nsaboo/Documents/goworkspace/src/poc/patterns_test.xml
>>> Printing patterndb address: 0x151e1e0
>>> Just before parsing
>>> fatal error: unexpected signal during runtime execution
>>> [signal SIGSEGV: segmentation violation code=0x1 addr=0x04d07885 
>>> pc=0x7fe62f2d2922]
>>>
>>> runtime stack:
>>> runtime.throw(0x4f7e77, 0x2a)
>>> /usr/local/go/src/runtime/panic.go:617 +0x72
>>> runtime.sigpanic()
>>> /usr/local/go/src/runtime/signal_unix.go:374 +0x4a9
>>>
>>> goroutine 1 [syscall]:
>>> runtime.cgocall(0x4b7380, 0xc44d90, 0xca8000)
>>> /usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc44d60 
>>> sp=0xc44d28 pc=0x404f4b
>>> main._Cfunc_match(0x16e3880, 0x16c, 0x154d680, 0x7)
>>> _cgo_gotypes.go:165 +0x45 fp=0xc44d90 sp=0xc44d60 pc=0x4b4825
>>> main.Syslogparser.ParseMessage(0xca4000, 0x3c, 0x4f47dd, 0x18, 
>>> 0xca6000, 0x0, 0x7, 0x4f915f, 0x16c)
>>> /home/nsaboo/Documents/goworkspace/src/poc/main.go:120 +0x12c 
>

[go-nuts] Re: Getting '[signal SIGSEGV: segmentation violation code=0x1 addr=0xffffffff04d07885 pc=0x7fe62f2d2922]' during cgo_call

[K.S. Bhaskar]

Chances are that a parameter or structure you are passing from Go to C is 
getting garbage collected by Go before the C code is done with it. Read the 
CGO documentaton – it's dense, but every sentence, every word, has a 
purpose.

In case it helps, take a look at the video of my recent talk at FOSDEM 2020 
in Brussels (https://fosdem.org/2020/schedule/event/dragonscgo/); slides at 
https://docs.yottadb.com/Presentations/200202-1DragonsofCGOFOSDEM.pdf

Regards
– Bhaskar

On Monday, February 17, 2020 at 9:33:00 AM UTC-5, Nitish Saboo wrote:
>
> Hi,
>
> This is my go env:
>
> nsaboo@ubuntu:~$ go version
> go version go1.12.4 linux/amd64
> nsaboo@ubuntu:~$ go env
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/nsaboo/.cache/go-build"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/nsaboo/Documents/goworkspace"
> GOPROXY=""
> GORACE=""
> GOROOT="/usr/local/go"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD=""
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build659816641=/tmp/go-build 
> -gno-record-gcc-switches"
>
> 'go build -v -x main.go' went through fine and the binary(main) was 
> created successfully.
>
> While making a cgo call from go code to C code I am getting the following 
> error:
>
> nsaboo@ubuntu:~/Documents/goworkspace/src/poc$ ./main 
> GOMAZPROCS : 2
> START
> DIR: /home/nsaboo/Documents/goworkspace/src/poc
> Reached C module path :/usr/local/lib/syslog-ng
> Reached C filepath 
> :/home/nsaboo/Documents/goworkspace/src/poc/patterns_test.xml
> Printing patterndb address: 0x151e1e0
> Just before parsing
> fatal error: unexpected signal during runtime execution
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x04d07885 
> pc=0x7fe62f2d2922]
>
> runtime stack:
> runtime.throw(0x4f7e77, 0x2a)
> /usr/local/go/src/runtime/panic.go:617 +0x72
> runtime.sigpanic()
> /usr/local/go/src/runtime/signal_unix.go:374 +0x4a9
>
> goroutine 1 [syscall]:
> runtime.cgocall(0x4b7380, 0xc44d90, 0xca8000)
> /usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc44d60 
> sp=0xc44d28 pc=0x404f4b
> main._Cfunc_match(0x16e3880, 0x16c, 0x154d680, 0x7)
> _cgo_gotypes.go:165 +0x45 fp=0xc44d90 sp=0xc44d60 pc=0x4b4825
> main.Syslogparser.ParseMessage(0xca4000, 0x3c, 0x4f47dd, 0x18, 
> 0xca6000, 0x0, 0x7, 0x4f915f, 0x16c)
> /home/nsaboo/Documents/goworkspace/src/poc/main.go:120 +0x12c 
> fp=0xc44e10 sp=0xc44d90 pc=0x4b56ec
> main.main()
> /home/nsaboo/Documents/goworkspace/src/poc/main.go:219 +0x3c1 
> fp=0xc44f98 sp=0xc44e10 pc=0x4b6031
> runtime.main()
> /usr/local/go/src/runtime/proc.go:200 +0x20c fp=0xc44fe0 
> sp=0xc44f98 pc=0x42cd7c
> runtime.goexit()
> /usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc44fe8 
> sp=0xc44fe0 pc=0x4548a1
>
> 1)How can I debug this error further ?
>
> 2)What could be the reason for this error ?
>
> 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/4ce0c9a3-9ed7-4408-9d49-d8b0b2960ea4%40googlegroups.com.

Re: [go-nuts] Panicking in public API ?

[K.S. Bhaskar]

Those are good guidelines. I'd like to add a couple of nuances.

For “system” or “operations” errors (we have a database engine that 
executes in the address space of processes, so there can be errors such as 
an IO error or an inability to expand because of insufficient space in the 
file systems), neither the user nor the programmer can do much. In such 
cases, log the error to the syslog and return an error that the application 
can catch and do something with, like terminate gracefully. In such cases a 
stack trace or dump only uses up more storage space.

When writing out stack traces or core dumps (we do the latter under certain 
circumstances), make the content and location operationally configurable. 
Sometimes processes can contain sensitive (confidential) data. In 
development and test environments, you usually do want all or most of the 
data. When an application is promoted to production, you may – or may not – 
want that core dump to contain data from the process heap (for example). As 
you should not change the application when you promote to production, this 
type of configuration should be done externally, e.g, with environment 
variables, configuration files, etc.

Regards
– Bhaskar

On Thursday, January 9, 2020 at 2:38:24 PM UTC-5, Scott Pakin wrote:
>
> On Tuesday, January 7, 2020 at 12:47:28 AM UTC-7, Axel Wagner wrote:
>>
>> Thus, panics are the right tool to use when reporting an issue that 
>> requires programmer attention and errors are the right tool when reporting 
>> an issue that requires user-attention (or, of course, can be handled 
>> programmatically).
>>
>
> Nicely presented guideline!
>
> — Scott
>

-- 
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/f257f90b-c643-4bbb-9a12-acc6b72c140a%40googlegroups.com.

[go-nuts] [ANN] YottaDB r1.28 released; Go wrapper now production grade

[K.S. Bhaskar]

For users of YottaDB using the Go API, r1.28 is a major release because it 
is required for production grade access to YottaDB from Go. For others, it 
is a minor release with a small set of enhancements and fixes as detailed 
in the release notes (https://gitlab.com/YottaDB/DB/YDB/-/tags/r1.28).

There is additional discussion on our web site 
(https://yottadb.com/whats-new/yottadb-r1-28-released). Please do try 
YottaDB r1.28 and tell us what you think. Also, as the Go wrapper exposes 
all the basic operations of YottaDB global & local variables and locks, 
please do try the Go wrapper and see what access to YottaDB data is like 
from Go.

Thank you for using YottaDB software.

Regards
– Bhaskar

K.S. Bhaskar
President, YottaDB LLC
40 Lloyd Avenue, Suite 104
Malvern, PA 19355, USA
bhas...@yottadb.com
https://yottadb.com
+1 (610) 644-1898 landline
+1 (484) 873-4467 Google voice

-- 
YottaDB - Rock solid. Lightning fast. Secure. Pick any three.

-- 
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/c8f177e4-40c5-448f-9de3-ee2334cb0ac0%40googlegroups.com.

[go-nuts] Re: Odd runtime errors

[K.S. Bhaskar]

cgo is very picky, as is signal handling if you have Go and non-Go signal 
handlers. My advice is:


   - Understand everywhere that cgo is used.
   - Read every sentence in the cgo documentation, no matter how dense the 
   prose is.
   - Read every sentence pertaining to signal handling if you have Go and 
   non-Go signal handlers.


We are about to release the production grade code for a cgo based wrapper 
to make YottaDB (https://yottadb.com) accessible from Go 
(https://godoc.org/lang.yottadb.com/go/yottadb). It took more than twice as 
long as we anticipated, probably three times the amount of person-hours we 
felt it should take, and more than four times any reasonable expectation of 
heartache. https://docs.yottadb.com/Presentations/DragonsofCGO.pdf is a 
presentation we gave recently, and we will be giving an updated one at All 
Things Open in October.

If you don't have cgo anywhere in your stack, ignore what I said. And good 
luck.

Regards
– Bhaskar


On Sunday, August 25, 2019 at 4:08:42 AM UTC-4, Jakob Borg wrote:
>
> Hi all,
>
> We develop an open source program for consumers that has a reasonably 
> large usage within its niche, on a mix of operating systems and platforms. 
> Recently we enabled crash reporting to get panic traces back from 
> cooperating users. With that we've discovered a bunch of panics of our own 
> creation, plus a lot of noise in terms of fatal errors outside of our 
> control -- typically users running out of memory or threads.
>
> There remains a lot of "unexplained" oddness however, some of which I'm 
> sure is attributable to hardware errors (bad RAM/CPU/etc). It's hard to be 
> sure either way, but we get a lot of stacks. The list below is a (probably 
> non-exhaustive) selection of crashes from the last week or so that are odd 
> in my mind:
>
>- fatal error: defer on system stack
>- fatal error: fatal error: unexpected signal during runtime execution
>- fatal error: found bad pointer in Go heap (incorrect use of unsafe 
>or cgo?) (this could be ours, though we have no cgo I'm sure there is 
>unsafe deep in the dependencies)
>- fatal error: gc: unswept span
>- fatal error: malloc deadlock
>- fatal error: mSpanList.insertBack
>- fatal error: non in-use span in unswept list
>- fatal error: out of memory allocating heap arena metadata (I guess 
>this is just a niche case of OOM)
>- fatal error: runtime: stack split at bad time
>- fatal error: runtime.newosproc (out of threads?)
>- fatal error: runtime·unlock: lock count
>- fatal error: s.allocCount != s.nelems && freeIndex == s.nelems
>- fatal error: slice bounds out of range (deep in the malloc code)
>- fatal error: stopm holding locks
>- fatal error: sweep increased allocation count
>- fatal error: sync: inconsistent mutex state
>- fatal error: wirep: invalid p state
>- panic: sync: inconsistent mutex state
>
> I'm not going to spend any energy hunting these down or pester with bug 
> reports, especially as I have no idea who the originating user is and no 
> way to communicate with them or experiment. :) However, if there's anyone 
> of you out there who think "Huh? That GC error should never happen, wonder 
> what's going on?" I would be happy to forward a bunch of crashes for that 
> particular crash or provide access to the crash database for searching.
>
> (A limitation of our crash reporting is that output prior to the 
> panic/fatal error is trimmed as potentially sensitive user data. This means 
> we miss the description that some fatal-error crashes print before the 
> "fatal error:" line. We might fix this at some point.)
>
> //jb
>
>

-- 
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/715233ea-c731-4b5b-8435-e8733737cc03%40googlegroups.com.

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

[K.S. Bhaskar]

Apologies for the delayed reply; I have been traveling.

The Go API is currently in a field test state (hopefully getting to 
production state in the next few weeks). The Go wrapper version to use with 
YottaDB r1.26 is the 'develop' branch at YDBGo. Or use YottaDB r1.24 and 
the master branch of YDBGo which will be stable until we release the 
production version of the Go wrapper, at which time a new YottaDB release, 
r1.28 will be required (the reason a new r1.28 release of YottaDB will be 
required is to work around an issue – a feature, a misfeature, or a bug, we 
are not sure which – in Go).

Apologies also for the inconvenience.

Regards
– Bhaskar

On Wednesday, July 10, 2019 at 8:42:55 AM UTC-4, tptan...@gmail.com wrote:
>
> 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/bec2ad46-bc2b-4d54-843b-caffa9517fd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Is runtime.Keepalive() needed inside the methods for a receiver object?

[K.S. Bhaskar]

Thank you very much, Ian.

Regards
– Bhaskar

On Wednesday, July 3, 2019 at 5:44:58 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Jul 3, 2019 at 1:32 PM K.S. Bhaskar  > wrote: 
> > 
> > https://github.com/golang/go/issues/13347#issuecomment-158568326 seems 
> to suggest runtime.KeepAlive() is not needed but it does not seem 
> definitive. 
> > 
> > If there is a function such as the one below (from 
> https://gitlab.com/YottaDB/Lang/YDBGo/blob/47f5960d03b2c00ae33222ec1d3bdc60a98226c1/buffer_t.go#L151)
>  
> in an application that has Go structures with pointers to C structures and 
> which uses Finalizers to free the C structures when the Go structures are 
> collected, is the runtime.KeepAlive(ibuft) required to guarantee that ibuft 
> is never collected by the Go garbage collector until after the return from 
> Free()? 
> > 
> > // Calls C.free on any C memory owned by this internalBuffer 
> > 
> > func (ibuft *internalBufferT) Free() { 
> > 
> > printEntry("internalBufferT.Free()") 
> > 
> > if nil == ibuft { 
> > 
> >return 
> > 
> > } 
> > 
> > cbuftptr := ibuft.cbuft 
> > 
> > if nil != cbuftptr { 
> > 
> >// ydb_buffer_t block exists - free its buffer first if 
> it exists 
> > 
> >if nil != cbuftptr.buf_addr { 
> > 
> >C.free(unsafe.Pointer(cbuftptr.buf_addr)) 
> > 
> >} 
> > 
> >C.free(unsafe.Pointer(cbuftptr)) 
> > 
> >ibuft.cbuft = nil 
> > 
> > } 
> > 
> > runtime.KeepAlive(ibuft) 
>
> In the exact code I don't think the runtime.KeepAlive is needed, 
> because the assignment "ibuft.cbuft = nil" should keep ibuft alive. 
>
> But if I were writing that code I would definitely write the 
> runtime.KeepAlive.  Follow a simple rule: if you use 
> runtime.SetFinalizer on instances of a type, then always use 
> runtime.KeepAlive in every method of that type.  It costs you 
> essentially nothing and may save your program from memory corruption. 
>
> 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/7de41346-cc17-4263-a4f5-ae94ec85778b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Is runtime.Keepalive() needed inside the methods for a receiver object?

[K.S. Bhaskar]

https://github.com/golang/go/issues/13347#issuecomment-158568326 seems to 
suggest runtime.KeepAlive() is not needed but it does not seem definitive.

If there is a function such as the one below (from 
https://gitlab.com/YottaDB/Lang/YDBGo/blob/47f5960d03b2c00ae33222ec1d3bdc60a98226c1/buffer_t.go#L151)
 
in an application that has Go structures with pointers to C structures and 
which uses Finalizers to free the C structures when the Go structures are 
collected, is the runtime.KeepAlive(ibuft) required to guarantee that ibuft 
is never collected by the Go garbage collector until after the return from 
Free()?

// Calls C.free on any C memory owned by this internalBuffer

func (ibuft *internalBufferT) Free() {

printEntry("internalBufferT.Free()")

if nil == ibuft {

   return

}

cbuftptr := ibuft.cbuft

if nil != cbuftptr {

   // ydb_buffer_t block exists - free its buffer first if it 
exists

   if nil != cbuftptr.buf_addr {

   C.free(unsafe.Pointer(cbuftptr.buf_addr))

   }

   C.free(unsafe.Pointer(cbuftptr))

   ibuft.cbuft = nil

}

runtime.KeepAlive(ibuft)
}

Thank you very much.

Regards
– Bhaskar

-- 
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/d7324145-f422-4453-8524-930d2882aa16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: the Dominance of English in Programming Languages

[K.S. Bhaskar]

And let's not forget Indian English - between the countries in the Indian 
Sub-continent (India, Pakistan, Nepal, Bangladesh), that should add up to 
another couple hundred million at least, with its own peculiarities like 
"Horn OK Tata" on the back of every truck (sorry, lorry). Interestingly, 
those dialects have not made their mark on any programming language, 
despite the large number of people of Indian ancestry in the software 
business.

Regards
- Bhaskar

On Friday, May 17, 2019 at 7:44:33 PM UTC-4, Rob 'Commander' Pike wrote:
>
> It is of course more complicated than most people believe. The right is 
> often wrong; the wrong often has long precedence. The British -ise ending 
> is an early 20th century misguided respelling based on invalid theories of 
> etymology. Programme is just something that came out of the blue, from 
> Scotland I believe, replacing the older program again relatively recently 
> (the occasional American pronunciation that rhymes with pogrom is a 
> catastrophe of its own). And so on and so on. What is perceived as British 
> and correct is often felt worthy through its Britishness but is in fact 
> more recently constructed than, for instance theater replacing theatre.
>
> Webster did indeed drop the colourful u's, with good reason (we are not 
> French), and jail is a clear improvement over the ludicrous gaol, with 
> similar favorable positions taken on draft/draught etc., but most of his 
> adjustments never caught on as canon, thru being the closest to making it. 
> Most of his attempts died on his tung (sic).
>
> Canada mostly follows the American (-ize, jail, tire, etc.) but keeps the 
> French u's and re's. Australia is closer to Britain but sticks with jail 
> and tire. I'm sure every English speaking country has its own set, and each 
> is valid in place.
>
> Language is rich, English orthography perhaps richest of all. Don't cast 
> aspersions, just be consistent. Most of all, don't believe that the Brits 
> are always "proper".
>
> The Go team's spelling standard honors the modern American style. It needs 
> to pick something to be consistent, but you are of course free to do as you 
> will in your own world, and you should.
>
> -rob
>
>
>
>
> On Sat, May 18, 2019 at 8:08 AM Michael Jones  > wrote:
>
>> In addition to being a daily Go programmer, I'm also a corporate 
>> executive in the US and a venture investment partner in the UK. This has me 
>> constantly surrounded by "proper" English and has made me very aware of the 
>> linguistic habits of my American upbringing. It seems that I've become an 
>> amalgam of the two, I say that "I was in hospital" for example, but name 
>> variables 'color' -- the result earning awkward glances on both sides of 
>> the Atlantic. My ear now prefers English English, in part from my love of 
>> the character of English people.
>>
>> On Fri, May 17, 2019 at 2:07 PM stíobhart matulevicz > > wrote:
>>
>>>
>>> I know that a lot of what we think of as "American English"  words are 
>>> actually archaic forms of early 'English English'. Words like "gotten" 
>>> instead of "got", for example. But there's also a lot of blame or credit 
>>> (depending on your point of view) for the differences to be laid at the 
>>> door of a certain Mr. Noah Webster:
>>>
>>>
>>> https://blog.oxforddictionaries.com/amp/2018/05/07/noah-webster-american-identity-simplified-spelling-movement/
>>>
>>> I was kind of half-joking in my original post.  But, as someone who 
>>> considers himself highly literate,  I do actually find it does grate a 
>>> bit,  having to (from my point of view) deliberately spell words wrong, 
>>> when I'm coding. 
>>>
>>> I get my revenge in the code comments though,  where I resolutely stick 
>>> to "colour", "centre", "programme", etc.
>>>
>>> I wonder if I'm am isolated case,  or whether any other native English 
>>> speakers are slightly irked by having to code in "bad spelling" too?
>>>
>>>
>>> On 17 May 2019 21:26:29 Michael Jones > 
>>> wrote:
>>>
 I know that you joke here, but I had an interesting dinner conversation 
 in London last year with erudite, scholarly friends who shared with me 
 that 
 recent research supports a different view of the "barbaric Americanised 
 false English" that is the prevailing sentiment you share. 

 According to the scholars they mentioned, "American English" is indeed 
 a true, pure, "real" English; just one from a time-capsule, an English 
 from 
 1776 that did not advance significantly since American independence. This 
 view suggests that were a BBC presenter and an American to travel back to 
 meet with King George, it would be the American who sounded "right" and 
 not 
 the other way around.

 This time-capsule argument is not an argument against modern evolved 
 English, but it is an interesting notion of a living language in the 
 homeland might become a historical artifact through cargo culting in the 
>>>

[go-nuts] Re: the Dominance of English in Programming Languages

[K.S. Bhaskar]

For historical reasons, languages and activities tend to be associated. Is 
the need for programmers to know relevant English technical terms any 
different from opera singers needing to know relevant Italian technical 
terms or fencers needing to know relevant French technical terms?

Regards
– Bhaskar

On Tuesday, May 7, 2019 at 12:33:46 PM UTC-4, skinne...@gmail.com wrote:
>
> When I first used IBM's UniComal the manual was Danish but the keywords 
> were English. Sometimes the function names in the examples were Danish. I 
> un derstand your problem.
>
> However, I do think that language is irrellevent. The keywords are tokens 
> that can be replaced programmatically with SED or AWK. You can display all 
> programs in your native language and write code in your native language, 
> when you save your code, it then translates that language source to English 
> language source and then when to edit the English language source you 
> translate it back to your native language source.
>
> I once wrote a process in Comal that would read a legal contract defining 
> a database program, it would parse the file, convert it to C++ code, that 
> would then compile into a working program. If the program did not perform 
> as needed, I sometimes had to write new C++ code but more often the sale 
> person would have to do a change order on the contract for the software.
>
> I do think that all programmers are multi-lingual, they have their native 
> language and one or more computer languages. Sometimes it is easier to 
> learn a new language than to build the tools needed to remain in ones 
> current comfort zone.
>
> My final comment is a bit off topic, I do not consider English to be a 
> language, it has over 120,000 words. If you have a vocabulary of 500 words 
> of Latin you can read most any ancient history. ESL speakers typically have 
> a subset of only 3k words. Most native English speakers use only 10k-20k 
> words depending on their training and locale. Native English speakers can 
> sometimes be incomprehensible to ESL or other English dialects. Vocabulary 
> can be vastly different depending upon class, heritage, region, training. 
>
> On Monday, April 29, 2019 at 12:36:37 AM UTC-5, Chris Burkert wrote:
>>
>> I recently read an article (German) about the dominance of English in 
>> programming languages [1]. It is about the fact that keywords in a language 
>> typically are English words. Thus it would be hard for non English speakers 
>> to learn programming - argue the authors.
>>
>> I wonder if there is really demand for that but of course it is weird to 
>> ask that on an English list.
>>
>> I also wonder if it would be possible on a tooling level to support 
>> keywords in other languages e.g. via build tags: // +language german
>>
>> Besides keywords we have a lot of names for functions, methods, structs, 
>> interfaces and so on. So there is definitely more to it.
>>
>> While such a feature may be beneficial for new programmers, to me it 
>> comes with many downsides like: readability, ambiguous naming / clashes, 
>> global teams ...
>>
>> I also believe the authors totally miss the point that learning Go is 
>> about to learn a language as it is because it is the language of the 
>> compiler.
>>
>> However I find the topic interesting and want to hear about your opinions.
>>
>> thanks - Chris
>>
>> 1: 
>>
>> https://www.derstandard.de/story/2000101285309/programmieren-ist-fuer-jeden-aber-nur-wenn-man-englisch-spricht
>>
>

-- 
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/f9e6b57b-7c71-4664-9456-70ba55be804c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[K.S. Bhaskar]

You can see how the YottaDB (https://yottadb.com) Go wrapper does it. 
Documentation of the API is at 
https://docs.yottadb.com/MultiLangProgGuide/goprogram.html and source code 
is at https://gitlab.com/YottaDB/Lang/YDBGo

Regards
– Bhaskar

On Friday, March 29, 2019 at 5:16:05 AM UTC-4, Ashutosh Baghel wrote:
>
> Thanks let me check. Will update.
>
> On Friday, 29 March 2019 09:23:31 UTC+5:30, Justin Israel wrote:
>>
>>
>>
>> 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.

[go-nuts] Announcing a Go API for YottaDB

[K.S. Bhaskar]

YottaDB (https://yottadb.com) is a mature, proven, free / open source 
multi-valued key-value NoSQL database. Between YottaDB and the upstream 
GT.M (https://sourceforge.net/projects/fis-gtm), the code base currently 
runs some of the largest real-time core-banking systems as well as 
nation-scale electronic health record systems. From a technical 
perspective, features that set YottaDB apart from other databases include a 
database engine that runs in process address space (with processes 
cooperating to manage the database), ACID transactions implemented using 
Optimistic Concurrency Control, real-time database replication both for 
business continuity as well as for applications like reporting, decision 
support, fraud detection, etc. Since it first went into production in 1986 
the code base has seen continuous investment in enhancements and fixes. 
YottaDB is available for Linux on the 64-bit x86 architecture, as well as 
Linux on ARM for both 32- and 64-bit architectures. You can also run it in 
a Docker container (see https://yottadb.com/product/get-started/).

All of our software (https://gitlab.com/YottaDB) is free / open source; our 
revenue comes from providing support on commercial terms with assured 
service levels, and from funded enhancements.

We are announcing a YottaDB Go API (which we call a wrapper – see 
https://yottadb.com/yottadb-go-wrapper/ & 
https://gitlab.com/YottaDB/Lang/YDBGo). Although YottaDB itself is mature 
and proven, the Go wrapper is new, and we are currently designating it as 
field test grade, meaning that it is suitable for development and testing, 
but not yet for live production use. In the near future (several weeks to a 
small number of months), we plan to follow-up with a production grade 
release.

Essential documentation is at https://godoc.org/lang.yottadb.com/go/yottadb 
with detailed information at https://docs.yottadb.com/MultiLangProgGuide 
(including a Go Quick Start at 
https://docs.yottadb.com/MultiLangProgGuide/MultiLangProgGuide.html#go-quick-start).

Apart from the sample wordfreq.go program in the Quick Start there are 
programs for the 3n+1 problem 
(https://yottadb.com/solving-the-3n1-problem-with-yottadb/) at 
https://gitlab.com/YottaDB/DB/YDBTest/blob/master/go/inref/threeenp1B1.go 
and 
https://gitlab.com/YottaDB/DB/YDBTest/blob/master/go/inref/threeenp1B2.go

Please use YottaDB and tell us what you think, either by posting here or by 
creating an Issue at https://gitlab.com/YottaDB/Lang/YDBGo/issues

Thank you very much.

Regards
– Bhaskar (yes. it's my last name, but that's what everyone calls me)

K.S. Bhaskar
President, YottaDB LLC
40 Lloyd Avenue, Suite 104
Malvern, PA 19355, USA
bhas...@yottadb.com
https://yottadb.com
+1 (610) 644-1898 landline
+1 (484) 873-4467 Google voice

-- 
YottaDB - Rock solid. Lightning fast. Secure. Pick any three.

-- 
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.