Re: [go-nuts] wrong ELF class error: How to compile 64 bit binary on Solaris 11 using gccgo

On Thu, Sep 27, 2018 at 5:34 PM, wrote: > Yes, this works for a simple program I have. Now I modified the helloworld > to use glog as follows: > > package main > > import ( > "fmt" > "github.com/golang/glog" > ) > > func main() { > fmt.Println("Hello world") > glog.Info("Hello

[go-nuts] Re: Canonical module arrangement in a multi-language project.

With the modules support added to Go 1.11 this should be straight forward. Create a subdirectory for your go code inside your working copy; change into that and run go mod init example.com/your/repo Where example.com/your/repo is a placeholder for the _prefix_ you want to apply to all of the

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Objects returned by Get() are not special in any way. They will be GCd just like an object returned by new(). In fact, they will often be just a new()'d object. There is no association of such an object with the pool. A pool is just a fancy free list. Get might return a previously Put'd object

Re: [go-nuts] Canonical module arrangement in a multi-language project.

The only thing I’ve found that works is the latter… and then I go yelled at that I wasn’t using proper structure… The only other choice is a different repo for the go code, and another repo for everything else. It doesn’t seem workable to me for large multi-language projects… but no one seems

[go-nuts] Canonical module arrangement in a multi-language project.

I am working on setting up NTPsec's build system to properly handle Go code, and can only find limited information of the preferred way of structuring the directory tree. Forcing the entire project into GOPATH would be sloppy and a giant kluge all around. Placing the go code in a folder with

Re: [go-nuts] Release 1.11.1 arrival estimate

Thanks Ian, I will start agitating. :) On Friday, 28 September 2018 00:17:38 UTC+2, Ian Lance Taylor wrote: > > On Thu, Sep 27, 2018 at 4:07 AM, Francis > wrote: > > Does anyone have a feeling for when the 1.11.1 release will be ready > > > > I can see from

Re: [go-nuts] Release 1.11.1 arrival estimate

On Thu, Sep 27, 2018 at 4:07 AM, Francis wrote: > Does anyone have a feeling for when the 1.11.1 release will be ready > > I can see from https://github.com/golang/go/milestone/80 that it's about > half done with no release date. But does anyone have a clearer feeling for > when it might be

Re: [go-nuts] wrong ELF class error: How to compile 64 bit binary on Solaris 11 using gccgo

On Thu, Sep 27, 2018 at 2:57 PM, Amandeep Gautam wrote: > Hi, >I am trying to compile a 64bit executable using gccgo on Solaris 11/10. > Following is what I have tried: > > CGO_LDFLAGS='-m64' go build hello_world.go > GOARCH=sparc64 CGO_LDFLAGS='-m64' go build hello_world.go > > Below is the

[go-nuts] wrong ELF class error: How to compile 64 bit binary on Solaris 11 using gccgo

Hi, I am trying to compile a 64bit executable using gccgo on Solaris 11/10. Following is what I have tried: CGO_LDFLAGS='-m64' go build hello_world.go GOARCH=sparc64 CGO_LDFLAGS='-m64' go build hello_world.go Below is the output of the first command: amandeep@s113ldom1:~/workspace$

Re: [go-nuts] Re: Debug Go program with GDB on macOS shows nothing

On Thu, Sep 27, 2018 at 11:13 AM, changkun wrote: > Works, thanks! Hope the information cloud added to golang.org/doc/gdb Sent https://golang.org/cl/138182 . Ian > On Thursday, September 27, 2018 at 8:02:20 PM UTC+2, David Chase wrote: >> >> You did nothing wrong, in 1.11 we started

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Ah, ok. In that case keeping a reference to a *Object in a uintptr will not prevent it from being garbage collected. For each garbage collection cycle the runtime visits every memory reference that is still 'alive'. Any references which were not visited will be reclaimed as free memory. So if

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Unless you are holding a real pointer to the value, they will have no root to hold them and so will by GC'd. Further, the uintptr in the map will not be updated if the value is moved (does not happen now but may in the future). What you're doing here is unsafe. On Thu, 2018-09-27 at 19:52 +0200,

[go-nuts] announce: LRMP - light weight reliable multicast protocol

I have ported LRMP (light weight reliable multicast protocol) to Go. It is available at lrmp There is also a Java implementation there, so it makes an ideal setup for local/wan notifications between processes/servers without a broker. The Java implementation

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

/favicon and /favicon/ is not the same! 2018. szeptember 27., csütörtök 20:18:43 UTC+2 időpontban Grey White a következőt írta: > > Good day guys, > I need help with attaching favicon.ico to my site > that is my folder structure. > i really can't tel what am doing wrong > > [image: Capture.PNG]

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

On Fri, Sep 28, 2018, 6:18 AM Grey White wrote: > Good day guys, > I need help with attaching favicon.ico to my site > that is my folder structure. > i really can't tel what am doing wrong > > [image: Capture.PNG] > func main() { >http.HandleFunc("/favicon", faviconHandler) >

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

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

[go-nuts] Re: Debug Go program with GDB on macOS shows nothing

Works, thanks! Hope the information cloud added to golang.org/doc/gdb On Thursday, September 27, 2018 at 8:02:20 PM UTC+2, David Chase wrote: > > You did nothing wrong, in 1.11 we started compressing the debug > information to reduce binary size, and gdb on the Mac does not understand >

[go-nuts] Re: Debug Go program with GDB on macOS shows nothing

You did nothing wrong, in 1.11 we started compressing the debug information to reduce binary size, and gdb on the Mac does not understand compressed DWARF. We had hoped that the several speedbumps involved in running gdb on modern OSX would have caused most users to move to Delve, which handles

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 07:44 PM, Francis wrote: > I believe the pool does not track the objects that it returns from a > call to `Get()`. I would be surprised if it did track these objects. > There is no real need for it to track these objects. Exactly, that was my point. Else there would be no reason

Re: [go-nuts] Dependency resolution weirdness with Go Modules.

Thanks Paul, I read through that issue you linked and was able to work through the dependency issues. Seems like the issue arises when the dependencies aren't tagging their releases properly. I had to update numerous dependencies to commits past their latest tagged release. On Thursday,

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

I believe the pool does not track the objects that it returns from a call to `Get()`. I would be surprised if it did track these objects. There is no real need for it to track these objects. The role of a sync pool is to give you an instance of *Object when you need it. As an optimisation if

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 07:19 PM, Francis wrote: > It is true that uintptr is not looked at by the garbage collector. This > will definitely reduce your GC costs. But there is no way (that I know > of) to convert your uintptr back into a *Object that is safe. I assume of course that we know that all

[go-nuts] Dead-simple dialog boxes?

So, I've been thinking about the GUI situation with Go and I'm seeing a lot of interesting projects coming up lately. However, none of these really satisfy my needs. All of these projects are suitable for larger graphical applications, but what I want is a dead simple, dependency- and

Re: [go-nuts] ticker for poisson processes?

Both use the runtime timers underneath. Ticker requires an extra channel send. Tracking this down was interesting! On Thu, 27 Sep 2018, 14:56 David Wahlstedt, wrote: > I mean that an ordinary go thread executing a sleep instruction may risk > to be starved by the scheduler, so the real

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

It's unclear to me how this could be useful. It is true that uintptr is not looked at by the garbage collector. This will definitely reduce your GC costs. But there is no way (that I know of) to convert your uintptr back into a *Object that is safe. Because uintptr is ignored by the GC it

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

Sure, feel free to do what you are comfortable with. I just couldn't understand why there is a need for the Update function at all. Hope that your Go transition goes smoothly :) -Agniva On Thu, 27 Sep 2018 at 21:29 Michael Ellis wrote: > Thanks for the feedback, Agni. I think I may not have

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

Thanks for the feedback, Agni. I think I may not have included enough detail in my original post. At present, the app is in the middle of transitioning to an all-Go implementation. For business reasons, that process will be stretched out over the next several months or longer. In the meantime,

[go-nuts] http router collaborators

https://github.com/golangdaddy/tarantula Docs: https://github.com/golangdaddy/tarantula/tree/master/router Hi, I wrote this http router over the last couple of years, I now have used it for many projects and employers. It's node based, has very flexible routing options and has full input

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

No offense, sorry for high jacking, I was trying to counter point their usefulness, as a way to limit additional resources being spent to improve GC when using them, since I think their application is error prone in many most? cases. > On Sep 27, 2018, at 9:30 AM, Peter Mogensen wrote: > >

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On Thu, 27 Sep 2018, at 3:06 PM, Peter Mogensen wrote: > > > On 09/27/2018 03:58 PM, Robert Engels wrote: > > It wasn’t necessarily a warning to you :) > > > > It comes from the days of GC bashing in Java and so everyone tried to > > manually write garbage free programs using pools and it had

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

In a highly concurrent system it can be difficult to know when to call Put if the object reference is shared among threads/routines. Similar to why C++ has shared pointers. It might be easy for the original author to know when a Put should be called but as a system grows and new functionality

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 03:58 PM, Robert Engels wrote: > It wasn’t necessarily a warning to you :) > > It comes from the days of GC bashing in Java and so everyone tried to > manually write garbage free programs using pools and it had a bad effect on > both performance and reliability. GC is there for

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

It wasn’t necessarily a warning to you :) It comes from the days of GC bashing in Java and so everyone tried to manually write garbage free programs using pools and it had a bad effect on both performance and reliability. GC is there for a reason, use it... :) I would just hate to see Go

Re: [go-nuts] ticker for poisson processes?

I mean that an ordinary go thread executing a sleep instruction may risk to be starved by the scheduler, so the real sleeping time is likely to be longer. But with the ticker, a incoming message in the channel waking up a routine that waits for it, things may behave differently? /David Den

[go-nuts] Debug Go program with GDB on macOS shows nothing

Debugging with GDB works fine on Linux, it is able to show everything with the breakpoint. However, nothing appears on macOS. A simple Go program, say `main.go`: package main func main() { println("hello, world!") } Then build with go build -gcflags "-N -l" -o main

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Based on my experience and I believe many others, I would caution against the use of pools. Although it can be useful for objects that are very expensive to create/initialize using it in a more general case just to improve GC can be fraught with issues in a highly concurrent and/or complex

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 03:25 PM, Robert Engels wrote: > Based on my experience and I believe many others, I would caution against the > use of pools. Although it can be useful for objects that are very expensive > to create/initialize using it in a more general case just to improve GC can > be

[go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 03:12 PM, Ian Davis wrote: > > > On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote: >> >> Of course... it requires that you handle any collisions in hashing the >> string key to an int yourself, but wrt. the value I curious if anyone >> can see issued with just storing a

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote: > > Of course... it requires that you handle any collisions in hashing the > string key to an int yourself, but wrt. the value I curious if anyone > can see issued with just storing a uintptr instead of the pointer for > sync.Pool managed

[go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Hi, I noticed the GC fix which avoids scanning maps if both key and value are not pointer types. [1] and see it used [2] and discussed [3] So... Initially, I figured this was not worth thinking too much about, but then I came to thing about the relatively common use case where your map value is

[go-nuts] Re: proposal: generic generics proposal

On Thursday, 20 September 2018 01:59:27 UTC+2, kortschak wrote: > > It's pretty clear for the flood of emails to golang-nuts and golang-dev > regarding the recent generics/contracts proposal that there are many > ways to implement generics proposals. > > Because of this and risks associated

Re: [go-nuts] [ANN] go-formal github organisation

Good question! There is an entire field of "formal" verification with associated conferences such as FMCAD, CAV, etc which has a long history, and the meaning has indeed changed over time. It may well mean different things to different people. In general, to me, "formal" comes from "formal

Re: [go-nuts] [ANN] go-formal github organisation

On Thu, Sep 27, 2018 at 11:38 AM Scott Cotton wrote: > I've just created a github organisation for formal tools in and for Go. Please expand on what a 'formal tool' is. I have no idea. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group.

[go-nuts] Re: [ANN] go-formal github organisation

And of course, it's at https://github.com/go-formal On Thursday, 27 September 2018 11:38:08 UTC+2, Scott Cotton wrote: > > Hi all, > > I've just created a github organisation for formal tools in and for Go. > > There's not much there now, but it is open to all to list and house > related repos.

[go-nuts] [ANN] go-formal github organisation

Hi all, I've just created a github organisation for formal tools in and for Go. There's not much there now, but it is open to all to list and house related repos. Membership is open upon request (for now just send an email to w...@iri-labs.com), we ask only that you be an open (not secret)

[go-nuts] why doesn't vgo use git checkout?

I think there was something absolutely wrong with my question. I'm not a professional software developer, so excuse me if I was wrong. I was just watching russ cox go with versions keynote , Why not one do a git checkout to the version which is