Re: [go-nuts] Need a way to check only key exist or not? without value?

[Brian Candler]

On Wednesday, 29 April 2020 01:33:55 UTC+1, Shishir Verma wrote:
>
> I think it is kind of intuitive that empty struct takes 0 bytes
>

To me it wasn't intuitive, but that's because my brain instinctively read 
it as "interface {}" and not "struct {}".

It's clear that a struct{} must occupy zero bytes.  It's not clear that 
such a construct is even legal, but it clearly is.  You can define a 
variable that takes zero bytes :-)  You can also define a zero-sized array, 
which achieves the same thing.
https://play.golang.org/p/16QuEbLj_89

Thanks for the trick!

-- 
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/d06c536a-8b4c-47a2-a40f-d145e6ef8218%40googlegroups.com.

[go-nuts] Re: Json Parse Data [unexecpted non whitespace 1 to 28]

[Brian Candler]

You have a specific piece of input data which is causing this error "json 
data parse after line 1 to 28"

Therefore, please modify your code to print the actual value just before 
parsing it; then do whatever triggers the error; then place that value 
inside the play.golang.org program to replicate the problem.

The JSON parser is saying that it's bad data, and so we want to see the 
exact data which cause the JSON parser to return this error.

-- 
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/a713371e-7053-430a-92c3-7084cefe7044%40googlegroups.com.

Re: [go-nuts] Re: marshal multiple json documents which may have different format versions into the latest struct version

[Chris Burkert]

That sounds like a good plan. I'm going to try that. Thank you Manlio!

Am Di., 28. Apr. 2020 um 15:11 Uhr schrieb Manlio Perillo <
manlio.peri...@gmail.com>:

> On Tuesday, April 28, 2020 at 10:52:56 AM UTC+2, Chris Burkert wrote:
>>
>> Dear all,
>>
>> my application users shall be able to provide multiple json documents
>> (files and urls) which I'd like to marshall into one structure.
>> Additionally these json documents may have different versions. I know how
>> to marshal a document into a version specific struct if I know the format
>> version before (for simplicity of this example I don't handle errors):
>> https://play.golang.org/p/ixVI5CzPqFP
>>
>> What I would like (in the example the village field was renamed to cities
>> ) is a struct of type ModelV2 with all four values merged in Cities.
>>
>> Is there a best practice for a backwards compatible behavior which:
>>
>>- identifies the json format version of each document
>>- skips that document if it is higher than the supported format
>>version in my application
>>- merges supported format versions into ONE struct
>>
>> Of course I have to implement the semantics on my own but how can I
>> approach the topic?
>>
>>
> You can first unmarshal a struct containing only the Version field.  As an
> example:
> https://play.golang.org/p/1oDzdWlTCfC
> 
>
>
> Manlio
>
>> 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/274e489d-afdb-4ec9-a5b3-26440364c489%40googlegroups.com
> 
> .
>

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

[go-nuts] Possible bug in turning versions into pseudo-versions

[volf . tomas]

Hello,

recently I've created a new golang library and released it with pre-release
version first to catch any bugs before doing proper 1.0.0 release.

The pre-release version was called 1.0.0-pre-release+1 , which according
to https://semver.org/ should be completely legal semver. If I read the
grammar correctly, it should fall under

 "-"  "+" 

with



 being 1.0.0, which is obviously correct.



 being pre-release, which should be ok
from this chain



 ::= 

 ::=

|  "." 

 ::= 
| 

 ::= 
|  
|  
|   

 ::= 
|  

 ::= 
| 

 ::= 
| "-"

so again, since all characters in pre-release fit into , that 
should
be ok as well.



 being 1 seems again obviously correct from

 ::=  | 



And despite the version being correct semver, it was mangled into 
pseudo-version
v1.0.0-pre-release.0.20200420093620-87861123c523. However, to quote from
https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-package-that-has-not-opted-in-to-modules

> If the repository does not have any valid semver tags, then the 
repository's
> version will be recorded with a "pseudo-version" such as
> v0.0.0-20171006230638-a6e239ea1c69



I see basically 3 possibilites here:

1. Documentation is incorrect since only *subset* of semver is actually
supported.

2. There is bug somewhere in the semver parsing causing my version not to be
considered correct.

3. I cannot read Backus-Naur and my version is *not* correct semver.

Is there something else I did miss in this analysis?


W.

-- 
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/b80dc21a-c1f1-44f0-82de-e968dbaa46e9%40googlegroups.com.

[go-nuts] Re: Getting pkcs12: unknown attribute with OID 1.3.6.1.4.1.311.17.2 with ToPEM call

[hannes . hayashi]

Well, FWIW, this still seems to be an issue in 2020 with Go 1.14

On Monday, November 5, 2018 at 6:25:53 AM UTC+1, jyo...@gmail.com wrote:
>
> Hi
>
> I'm trying to extract a certificates,keys from the .pfx file using the 
> call ToPEM.
>
> I get this error
>
> pkcs12: unknown attribute with OID 1.3.6.1.4.1.311.17.2
>
> I see Decode in pkcs12 package expects only one certificate and one key 
> file in the .pfx file. My scenario is it has multiple certs including 
> cacert in the .pfx form. So I used ToPEM call.
> But I get the above mentioned error.
>
> If anybody knows how to resolve this , pls let me  know
>
>
>

-- 
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/d237d3b9-d4ac-4603-b3cd-b515a7ad7015%40googlegroups.com.

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

[Uli Kunitz]

The documentation provided by go help modules doesn't refer to semver.org 
and the Backus-Naur-Form there, so you cannot assume it is supported. The 
semver.org BNF doesn't support the leading v letter, so Go modules versions 
are anyway incompatible.

-- 
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/27dfafcd-e3f9-449c-9748-df2b6b39beba%40googlegroups.com.

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

[volf . tomas]

On Wednesday, April 29, 2020 at 6:57:55 PM UTC, Uli Kunitz wrote:
>
> The documentation provided by go help modules doesn't refer to semver.org 
> and the Backus-Naur-Form there, so you cannot assume it is supported. The 
> semver.org BNF doesn't support the leading v letter, so Go modules 
> versions are anyway incompatible.
>
>
I don't know about `go help modules`, but 
https://github.com/golang/go/wiki/Modules#modules has link to semver.org, 
in sentence

> Modules must be semantically versioned according to semver 
, 

But if that link is a mistake and should be removed, where could I found 
what does go mean by "semver"?

W.

-- 
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/ddc2ab1e-4f6f-454a-82dd-ed780b6fba04%40googlegroups.com.

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

[volf . tomas]

On Wednesday, April 29, 2020 at 6:57:55 PM UTC, Uli Kunitz wrote:
>
> The documentation provided by go help modules doesn't refer to semver.org 
> and the Backus-Naur-Form there, so you cannot assume it is supported. The 
> semver.org BNF doesn't support the leading v letter, so Go modules 
> versions are anyway incompatible.
>
>
And even `go help modules` mentions the semver.org now that I actually 
checked:

+ $ go help modules | grep semver.org -C2

See https://research.swtch.com/vgo-import for more information about
semantic import versioning, and see https://semver.org/ for more about
semantic versioning. 



W.

-- 
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/1933ca45-d2f0-4ee6-ae95-293ab78bade9%40googlegroups.com.

[go-nuts] Safe ways to call C with less overhead

[nanokatze]

I am interested in having less overhead for Go-C-Go roundtrips, for C
programs that I know (or at least am very much sure) will behave, for
most part, similar to non-preemptible (as in prior to Go 1.14) loops
in Go. Concretely, I have a self-imposed exercise of making a
frankenprogram that talks graphics using Vulkan (this part is in C)
and talks to other computers over network (this one is in Go).

Background

Certain sizable class of Vulkan programs spend overwhelming majority
of their CPU time in a loop of recording command buffers. This means
calling vkCmd* functions some 1 to 10 or more times per
second. The frequency with which these functions are invoked makes it
infeasible to use the common Cgo mechanism because its constant
overhead becomes significantly larger than the time these functions
individually run for. In fact, it is likely that most of vkCmd* these
programs are interested in just merely copy their arguments to an
array and bump a counter. This property makes the assumption of Cgo
that a C program may block redundant. But this is an implementation
detail of a Vulkan driver and differs between drivers (we still assume
that driver is good and won't be doing nasty things like hanging
forever). Even if we knew memory layout of command buffer and
replicated in Go relevant vkCmd* functions from, say, mesa radv, this
will be broken by an inevitable driver update (the .so part of driver
is overwhelmingly common to be linked dynamically) and will not work
on a different driver such as mesa anvil (intel vulkan driver).

There is also a number of minor nuisances such as dynamic cgocheck
being constantly angry at pointers to Go memory being sent to C
(runtime.KeepAlives were carefully placed in the program) and general
discomfort of writing "Go-looking C" in Go.

I suspect there's an alternative way to making graphics card do work
by means of using indirect draw similar to OpenGL AZDO approach (this
is a speculation, since I'm not at all familiar with this
approach). This lets us to just write indirect draw commands to a
large array from Go and make calling into C much less frequent. This
approach appears to come at big cost of ergonomics: we have no way of
interleaving binding of anything with the draw calls. We would need a
separate logical buffer (offset in vkCmdDraw*Indirect) with indirect
draw commands between any two vkCmdBind* calls.

Another approach would be to have intermediate command buffer of our
own which would be, for example, an array of tagged unions (structs
with an integer tag and a union) describing which vkCmd* to call and
what parameters to give it.

This hoop-jumping motivates us to write a considerable partition of
program in C, which is not necessarily the thing we desire, which in
turn motivates us to find ways to call classes of C programs that we
hope will not misbehave with overhead that is significantly less than
that of Cgo.

rustgo: calling Rust from Go with near-zero overhead

I recalled stumbling upon https://blog.filippo.io/rustgo/ and reread
the article. The approach described is simple but extremely dangerous
for opaque C calls (which is what vkCmd* are). We have no idea about
how much stack the C function is going to need and if we had to make a
conservative guess, we would still want to have a stack guard at the
bottom, to be safe.

https://github.com/minio/c2goasm lets us do what is described in the
article in a less involved manner but (as far as I understood) assumes
that the C function is a leaf function.

I never tried installing stack guards at goroutine stacks in Go but in
my own exercise of re-implementing rsc's libtask I tried mprotecting
4k at the bottom of the stack to PROT_READ. I noted that I couldn't
have more than about 15k tasks. This is due to the default limit of
about 32k of memory maps in linux. mprotecting PROT_READ and then
restoring protection at each context switch removed this handicap but
slowed down context switching considerably. In Go, I imagine, stack
guard for C functions could be done as follows:

Withguard(func() {
// C functions are called here in a way described in rustgo article
})

where Withguard would ask for large morestack + 8k at bottom, install
PROT_READ page somewhere in the 8k part near the bottom of the stack,
call the function passed to it, munprotect and leave. But I speculate
this would lead to deadly interactions with GC such as ocassional
segfaults whenever GC would for whatever unknown reason access the
PROT_READ part of the stack.

runtime.systemstack

I stumbled upon this function when exploring Go runtime. It lets me
achieve things I would want to make Withguard for. It has an important
caveat: while we're on systemstack, we may not be preempted (also no
defers). This means that we probably should not allocate anything in
fear of dangerous interactions with GC. We also should probably leave
systemstack sooner, because I suspect GC will not be able to see roots
of the goroutine that switched to s

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

[Sean Liao]

go does mean semver.org when it refers to semver

> Modules must be semantically versioned according to semver[,...]

refers to what the numbers mean, the v prefix is required but not part of 
the version, more clearly explained in a faq on semver.org:

> Is “v1.2.3” a semantic version?
> No, “v1.2.3” is not a semantic version. However, prefixing a semantic 
version with a “v” is a common way (in English) to indicate it is a version 
number. Abbreviating “version” as “v” is often seen with version control. 
Example: git tag v1.2.3 -m "Release version 1.2.3", in which case “v1.2.3” 
is a tag name and the semantic version is “1.2.3”.

On Wednesday, April 29, 2020 at 4:50:54 PM UTC+2, volf...@gmail.com wrote:
>
> Hello,
>
> recently I've created a new golang library and released it with pre-release
> version first to catch any bugs before doing proper 1.0.0 release.
>
> The pre-release version was called 1.0.0-pre-release+1 , which according
> to https://semver.org/ should be completely legal semver. If I read the
> grammar correctly, it should fall under
>
>  "-"  "+" 
>
> with
>
>
>
>  being 1.0.0, which is obviously correct.
>
>
>
>  being pre-release, which should be ok
> from this chain
>
>
>
>  ::= 
>
>  ::=
> 
> |  "." 
>
>  ::= 
> | 
>
>  ::= 
> |  
> |  
> |   
>
>  ::= 
> |  
>
>  ::= 
> | 
>
>  ::= 
> | "-"
>
> so again, since all characters in pre-release fit into , that 
> should
> be ok as well.
>
>
>
>  being 1 seems again obviously correct from
>
>  ::=  | 
>
>
>
> And despite the version being correct semver, it was mangled into 
> pseudo-version
> v1.0.0-pre-release.0.20200420093620-87861123c523. However, to quote from
>
> https://github.com/golang/go/wiki/Modules#can-a-module-consume-a-package-that-has-not-opted-in-to-modules
>
> > If the repository does not have any valid semver tags, then the 
> repository's
> > version will be recorded with a "pseudo-version" such as
> > v0.0.0-20171006230638-a6e239ea1c69
>
>
>
> I see basically 3 possibilites here:
>
> 1. Documentation is incorrect since only *subset* of semver is actually
> supported.
>
> 2. There is bug somewhere in the semver parsing causing my version not to 
> be
> considered correct.
>
> 3. I cannot read Backus-Naur and my version is *not* correct semver.
>
> Is there something else I did miss in this analysis?
>
>
> W.
>

-- 
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/7a8c40e5-ff83-4624-9d8d-880be21a7a93%40googlegroups.com.

[go-nuts] Is this a safe way to block main thread but not main goroutine?

[Akhil Indurti]

I want to run the main goroutine on another thread besides the main thread, 
so that the main thread can block in darwin UI code. Is this a safe way to 
do it?

package main

/*
#include 
#include 

void block() {
printf("Blocking main thread? %d\n", pthread_main_np());
while(1);
}
*/
import "C"
import (
"fmt"
"runtime"
)

func init() {
runtime.LockOSThread()
go main()
C.block()
}

func main() {
fmt.Println("Blocking main goroutine?", C.pthread_main_np())
}


This prints out the following:

$ go run threadtrick.go
Blocking main thread? 1
Blocking main goroutine? 0

-- 
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/6b476ab1-c6b6-4f77-91d8-aba2dfbcc314%40googlegroups.com.

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

['Thomas Bushnell, BSG' via golang-nuts]

That seems needlessly complex. Why not just skip the weird init, and just
have main do a go to the thing you want to be not on the main thread, and
let the main thread do its thing?

On Wed, Apr 29, 2020 at 4:19 PM Akhil Indurti  wrote:

> I want to run the main goroutine on another thread besides the main
> thread, so that the main thread can block in darwin UI code. Is this a safe
> way to do it?
>
> package main
>
> /*
> #include 
> #include 
>
> void block() {
>   printf("Blocking main thread? %d\n", pthread_main_np());
>   while(1);
> }
> */
> import "C"
> import (
>   "fmt"
>   "runtime"
> )
>
> func init() {
>   runtime.LockOSThread()
>   go main()
>   C.block()
> }
>
> func main() {
>   fmt.Println("Blocking main goroutine?", C.pthread_main_np())
> }
>
>
> This prints out the following:
>
> $ go run threadtrick.go
> Blocking main thread? 1
> Blocking main goroutine? 0
>
> --
> 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/6b476ab1-c6b6-4f77-91d8-aba2dfbcc314%40googlegroups.com
> 
> .
>

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

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

[Sean Liao]

semver point 10:
> Build metadata MUST be ignored when determining version precedence. 

chat log from slack:
> 22:29 bcmills Tags with metadata are not unique: there is only a partial 
order among them, not a total order.
> 22:30 In contrast, MVS requires a total order. (We can't choose between 
vX.Y.Z+a and vX.Y.Z+b, because SemVer defines them to be of equal 
precedence.)
> 22:31 So instead, we accept the tag but convert it to a very nearby 
pseudo-version, which restores the total-order property.
> 22:32 bcmills (We can't just reduce it to vX.Y.Z, because that version 
could have its own tag on yet another different commit.)

-- 
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/b4e160e8-b5bd-4277-b224-dcdb7632485a%40googlegroups.com.

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

[Akhil Indurti]

I want to mirror (or control) the event loop inside the main goroutine. The 
main goroutine should be the one to block for events. Plus, as long as it's 
safe, it doesn't seem needlessly complex to me.

On Wednesday, April 29, 2020 at 4:38:27 PM UTC-4, Thomas Bushnell, BSG 
wrote:
>
> That seems needlessly complex. Why not just skip the weird init, and just 
> have main do a go to the thing you want to be not on the main thread, and 
> let the main thread do its thing?
>
> On Wed, Apr 29, 2020 at 4:19 PM Akhil Indurti  > wrote:
>
>> I want to run the main goroutine on another thread besides the main 
>> thread, so that the main thread can block in darwin UI code. Is this a safe 
>> way to do it?
>>
>> package main
>>
>> /*
>> #include 
>> #include 
>>
>> void block() {
>>  printf("Blocking main thread? %d\n", pthread_main_np());
>>  while(1);
>> }
>> */
>> import "C"
>> import (
>>  "fmt"
>>  "runtime"
>> )
>>
>> func init() {
>>  runtime.LockOSThread()
>>  go main()
>>  C.block()
>> }
>>
>> func main() {
>>  fmt.Println("Blocking main goroutine?", C.pthread_main_np())
>> }
>>
>>
>> This prints out the following:
>>
>> $ go run threadtrick.go
>> Blocking main thread? 1
>> Blocking main goroutine? 0
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/6b476ab1-c6b6-4f77-91d8-aba2dfbcc314%40googlegroups.com
>>  
>> 
>> .
>>
>

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

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

[Marcin Romaszewicz]

As Thomas said, this will work for sure, though, and doesn't require any
manual setup, and you don't need to do funny business with CGO.

func main() {
  go doAllYourOtherStuff()
  blockOnDarwinEventLoop()
}

Done.


On Wed, Apr 29, 2020 at 1:44 PM Akhil Indurti  wrote:

> I want to mirror (or control) the event loop inside the main goroutine.
> The main goroutine should be the one to block for events. Plus, as long as
> it's safe, it doesn't seem needlessly complex to me.
>
> On Wednesday, April 29, 2020 at 4:38:27 PM UTC-4, Thomas Bushnell, BSG
> wrote:
>>
>> That seems needlessly complex. Why not just skip the weird init, and just
>> have main do a go to the thing you want to be not on the main thread, and
>> let the main thread do its thing?
>>
>> On Wed, Apr 29, 2020 at 4:19 PM Akhil Indurti  wrote:
>>
>>> I want to run the main goroutine on another thread besides the main
>>> thread, so that the main thread can block in darwin UI code. Is this a safe
>>> way to do it?
>>>
>>> package main
>>>
>>> /*
>>> #include 
>>> #include 
>>>
>>> void block() {
>>> printf("Blocking main thread? %d\n", pthread_main_np());
>>> while(1);
>>> }
>>> */
>>> import "C"
>>> import (
>>> "fmt"
>>> "runtime"
>>> )
>>>
>>> func init() {
>>> runtime.LockOSThread()
>>> go main()
>>> C.block()
>>> }
>>>
>>> func main() {
>>> fmt.Println("Blocking main goroutine?", C.pthread_main_np())
>>> }
>>>
>>>
>>> This prints out the following:
>>>
>>> $ go run threadtrick.go
>>> Blocking main thread? 1
>>> Blocking main goroutine? 0
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/6b476ab1-c6b6-4f77-91d8-aba2dfbcc314%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5e80ed26-09c5-4133-875e-4b0f72e9e2af%40googlegroups.com
> 
> .
>

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

[go-nuts] Re: Possible bug in turning versions into pseudo-versions

[volf . tomas]

Aaah ok, so my usage should have been v1.0.0-pre-release.1 and 
v1.0.0-pre-release.2 ; and indeed,
when I've tested it it does work.

Thank you

On Wednesday, April 29, 2020 at 8:41:39 PM UTC, Sean Liao wrote:
>
> semver point 10:
> > Build metadata MUST be ignored when determining version precedence. 
>
> chat log from slack:
> > 22:29 bcmills Tags with metadata are not unique: there is only a partial 
> order among them, not a total order.
> > 22:30 In contrast, MVS requires a total order. (We can't choose between 
> vX.Y.Z+a and vX.Y.Z+b, because SemVer defines them to be of equal 
> precedence.)
> > 22:31 So instead, we accept the tag but convert it to a very nearby 
> pseudo-version, which restores the total-order property.
> > 22:32 bcmills (We can't just reduce it to vX.Y.Z, because that version 
> could have its own tag on yet another different commit.)
>

-- 
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/735eed3c-5920-4d25-9a31-4c8e0edede56%40googlegroups.com.

[go-nuts] Store function name as JSON?

[MichaelB]

Hey Gophers,

I'm trying to store a data point as a JSON (w/struct) with a Call back 
function to call when the item is loaded with data

Just marshaling the struct into JSON nets a blank item.. any suggestions?

example:

type Item struct {
 name string
 callback func()
 data int
}

...

func times100(i int) {
 return i * 100
}

m := Item{
 name: "first",
 callback: times100,
 data: 10,
}

.. data is loaded later after functions run... then it should run data 
through m.callback(data)

after striking out I thought about switching it to a string and doing a 
switch.. but let me know maybe i'm just doing something wrong with the 
callback definition 

thanks,
MB

-- 
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/04e5bc8a-2a75-49b8-9510-5de9425d3858%40googlegroups.com.

Re: [go-nuts] Safe ways to call C with less overhead

[Ian Lance Taylor]

On Wed, Apr 29, 2020 at 12:45 PM  wrote:
>
> 1) I have heard gccgo can call C much quicker than the standard go
> implementation can. If this statement is true, why is that?

It's because gccgo uses the C calling convention.  So you can use a
magic //go:linkname comment to rename a Go function declaration to a C
function, and then just call it.  This is completely unsafe, because
if the C function blocks or misuses pointers your program will crash
horribly.  But it is fast.

> 2) How could a systemstack-like function but which can be friends with
> preemption mechanism of Go 1.14 be achieved?

That is basically a cgo call: a preemption friendly switch to the system stack.

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/CAOyqgcWvk_f7JbpQgzOM17mKBRxwSA0Fb_3k2G34sX3KcLh8DQ%40mail.gmail.com.

Re: [go-nuts] External/internal linker and cgo packages

[Ian Lance Taylor]

On Tue, Apr 28, 2020 at 10:49 PM Vincent Blanchon
 wrote:
>
> I'm building a simple program that has a dependency to 
> github.com/DataDog/zstd, a wrapper of a C code.
> So by default, Go will use the external linker. When debugging with, I can see
>
> host link: "clang" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" 
> "-Wl,-pagezero_size,400" "-o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-build122622791/b001/exe/a.out"
>  "-Qunused-arguments" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/go.o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/00.o" 
> [...] 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/53.o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/54.o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/55.o" 
> "-g" "-O2" "-g" "-O2" "-g" "-O2" "-lpthread" "-g" "-O2" "-framework" 
> "CoreFoundation" "-framework" "Security" "-no-pie"
>
> It links 55 files, from 00.o to 55.oIf I had more custom debug, I can 
> see than those files are mostly duplication:
>
> 04.o is 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d
>  github.com/DataDog/zstd 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x005.o)
> 05.o is 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d
>  github.com/DataDog/zstd 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x006.o)
>
> I can see 40 times this zstd package among the 55 files. Is it expected? What 
> is the difference between them?
>
> Also, what would happen to the non known cgo packages (not net, os/user or 
> runtime/cgo) if cgo is not enabled? How the internal linker will manage this 
> cgo package?

I may be missing something, but that doesn't look like duplication to
me.  It looks like different files from an archive.  The first one is
_x005.o and the second one is _x006.o.

You will get files like these for each .c file in a package that uses cgo.

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/CAOyqgcXfXPmA5YiVZ39JqvpgqZ7mAn84EYiO-ZUXrn9kqjbSMQ%40mail.gmail.com.

Re: [go-nuts] External/internal linker and cgo packages

[Vincent Blanchon]

Hello Ian,

Thank you again for your reply!
I thought Go would compile all the C files in one .go, that makes sense.

By the way, how Go would deal with those files if cgo is not enabled - 
meaning the internal linker will do the job?
How the internal linker can deal with that?


Le jeudi 30 avril 2020 07:52:03 UTC+4, Ian Lance Taylor a écrit :
>
> On Tue, Apr 28, 2020 at 10:49 PM Vincent Blanchon 
> > wrote: 
> > 
> > I'm building a simple program that has a dependency to 
> github.com/DataDog/zstd, a wrapper of a C code. 
> > So by default, Go will use the external linker. When debugging with, I 
> can see 
> > 
> > host link: "clang" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" 
> "-Wl,-pagezero_size,400" "-o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-build122622791/b001/exe/a.out"
>  
> "-Qunused-arguments" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/go.o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/00.o" 
> [...] 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/53.o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/54.o" 
> "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/55.o" 
> "-g" "-O2" "-g" "-O2" "-g" "-O2" "-lpthread" "-g" "-O2" "-framework" 
> "CoreFoundation" "-framework" "Security" "-no-pie" 
> > 
> > It links 55 files, from 00.o to 55.oIf I had more custom debug, 
> I can see than those files are mostly duplication: 
> > 
> > 04.o is 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d
>  
> github.com/DataDog/zstd 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x005.o)
>  
>
> > 05.o is 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d
>  
> github.com/DataDog/zstd 
> /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x006.o)
>  
>
> > 
> > I can see 40 times this zstd package among the 55 files. Is it expected? 
> What is the difference between them? 
> > 
> > Also, what would happen to the non known cgo packages (not net, os/user 
> or runtime/cgo) if cgo is not enabled? How the internal linker will manage 
> this cgo package? 
>
> I may be missing something, but that doesn't look like duplication to 
> me.  It looks like different files from an archive.  The first one is 
> _x005.o and the second one is _x006.o. 
>
> You will get files like these for each .c file in a package that uses cgo. 
>
> 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/38760d5d-b8e3-4a42-b087-8b81ab4ebd87%40googlegroups.com.

Re: [go-nuts] External/internal linker and cgo packages

[Ian Lance Taylor]

On Wed, Apr 29, 2020 at 8:58 PM Vincent Blanchon
 wrote:
>
> Thank you again for your reply!
> I thought Go would compile all the C files in one .go, that makes sense.
>
> By the way, how Go would deal with those files if cgo is not enabled - 
> meaning the internal linker will do the job?
> How the internal linker can deal with that?

If you are using the internal linker, then you aren't using cgo, so
the linker won't see all those C files.

Ian


> Le jeudi 30 avril 2020 07:52:03 UTC+4, Ian Lance Taylor a écrit :
>>
>> On Tue, Apr 28, 2020 at 10:49 PM Vincent Blanchon
>>  wrote:
>> >
>> > I'm building a simple program that has a dependency to 
>> > github.com/DataDog/zstd, a wrapper of a C code.
>> > So by default, Go will use the external linker. When debugging with, I can 
>> > see
>> >
>> > host link: "clang" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" 
>> > "-Wl,-pagezero_size,400" "-o" 
>> > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-build122622791/b001/exe/a.out"
>> >  "-Qunused-arguments" 
>> > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/go.o" 
>> > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/00.o"
>> >  [...] 
>> > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/53.o"
>> >  
>> > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/54.o"
>> >  
>> > "/var/folders/bb/w1lgkjdx47qd7695hb5r400hgn/T/go-link-023224426/55.o"
>> >  "-g" "-O2" "-g" "-O2" "-g" "-O2" "-lpthread" "-g" "-O2" "-framework" 
>> > "CoreFoundation" "-framework" "Security" "-no-pie"
>> >
>> > It links 55 files, from 00.o to 55.oIf I had more custom debug, I 
>> > can see than those files are mostly duplication:
>> >
>> > 04.o is 
>> > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d
>> >  github.com/DataDog/zstd 
>> > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x005.o)
>> > 05.o is 
>> > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d
>> >  github.com/DataDog/zstd 
>> > /path/to/go-build/67/678a3a394ba4feae32a2ddb829ea65c1cf24be64248dcbcc3dae709b8e3b826d-d(_x006.o)
>> >
>> > I can see 40 times this zstd package among the 55 files. Is it expected? 
>> > What is the difference between them?
>> >
>> > Also, what would happen to the non known cgo packages (not net, os/user or 
>> > runtime/cgo) if cgo is not enabled? How the internal linker will manage 
>> > this cgo package?
>>
>> I may be missing something, but that doesn't look like duplication to
>> me.  It looks like different files from an archive.  The first one is
>> _x005.o and the second one is _x006.o.
>>
>> You will get files like these for each .c file in a package that uses cgo.
>>
>> 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/38760d5d-b8e3-4a42-b087-8b81ab4ebd87%40googlegroups.com.

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

[go-nuts] cgo can't find .so in same directory

[Dean Schulze]

I'm following a simple example 
 of using 
cgo to call a C library function from go.  Executing the binary gives

error while loading shared libraries: libperson.so: cannot open shared 
object file: No such file or director


Here's the relevant part from the main.go file:

/*
#cgo LDFLAGS: -L. -lperson
#include "person.h"
 */
import "C"


The file libperson.so is right in the same directory with main.go and 
person.h.  I've also created a soft link libperson.so.0 -> libperson.so but 
that doesn't have any effect.  I've tried this with go run and by go build 
to create a binary but both give the same error.

Does cgo recognize the LDFLAGS: -L. symbol at all?

What do I need to do to get a go binary to call a C function in a .so?  I 
really don't want to put my .so in the /usr/lib directory just to get a 
static linked binary for something like this.

-- 
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/f255f40f-ef31-488f-986a-4f5faeb6f453%40googlegroups.com.

Re: [go-nuts] Store function name as JSON?

[Reto]

On Wed, Apr 29, 2020 at 02:17:44PM -0700, MichaelB wrote:
> I'm trying to store a data point as a JSON (w/struct) with a Call back
> function to call when the item is loaded with data

Functions aren't serializeable to json, it's not one of the types json supports.

> Just marshaling the struct into JSON nets a blank item.. any suggestions?

> type Item struct {
>  name string
>  callback func()
>  data int
> }

If you json.Unmarshal into the above struct it can't work.
json is an external package and hence can only work with exported symbols.
You need to capitalize your struct fields in other words.

> after striking out I thought about switching it to a string and doing a
> switch.. but let me know maybe i'm just doing something wrong with the
> callback definition
Yes, enter a string and switch on that.

Greetings,
Reto

-- 
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/20200430045724.sw44mlpsgac3p7jb%40feather.localdomain.

[go-nuts] cgo can't find .so in same directory

[Tamás Gulácsi]

Tweak your ld.conf configs and call ldconfig till ldd finds all libs of your 
binary.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/57e19640-808c-460b-90d0-44634a79a505%40googlegroups.com.