[go-nuts] Help debugging atomic.AddInt64 usage

Is your handler panicking? If so there are also other issues to address, but you can test/quickfix this by deferring your decrement so it runs regardless: atomic.AddInt64(&concur, 1) defer atomic.AddInt64(&concur, -1) h.ServeHTTP(w, r) -- You received this message because you are subscribed to

[go-nuts] Pause failures, GC, & StopTheWorld

s in P* or M*. After that we see a health check handler logged and in the sample after that gcwaiting and stopwait are 0. What can G188/M6/P0 be doing such that it doesn’t notice the request to preempt itself for 5 seconds? And while having mallocing=1? Thanks for any insights or sugges

[go-nuts] print pointer value to json...

hi, i am newer in golang. i want to marshal pointer value to json. but, i can't. how can i do that ? thanks, package main import ( "encoding/json" "fmt" ) type KV struct { k string v string } func main() { kv := []*KV{} obj := new(KV) obj.k = "eric" obj

[go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

ng GC). To make this discussion more concrete, using the example of glDrawElements above, I want to figure out an appropriate type for T: func GoGlDrawElements(uint32 mode, int32 count, uint32 type, T indices) { C.glDrawElementsWrapper(mode, count, type, indices) } Thanks, Eric -- Y

Re: [go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

xist a good way to treat C memory as a slice. On Monday, February 19, 2018 at 12:03:00 PM UTC-8, Jan Mercl wrote: > > On Mon, Feb 19, 2018 at 8:35 PM Eric Woroshow > wrote: > > > Using uintptr might work, but my concern is that passing a Go pointer > into C by way of a uintptr

Re: [go-nuts] Appropriate Go type for cgo void* param that accepts either an offset or pointer?

yhow. On Mon, Feb 19, 2018 at 5:59 PM Ian Lance Taylor wrote: > On Mon, Feb 19, 2018 at 3:09 PM, Eric Woroshow > wrote: > > > > Right, declaring the type as uintptr but requiring that the memory come > from > > C.malloc is workable, but definitely compromises ease-of-u

[go-nuts] Unexpected behavior of %+02d in Sprintf() and friends

Under Go 1.10.1, feeding an 0 value to a %+02d specifier sometimes yields "+0", not "+00". The attached tiny Go program may reproduce this behavior. I say "may" because I first observed it in a series of unit tests of date format conversions - in different format strings %+02d expanded differ

[go-nuts] Re: Unexpected behavior of %+02d in Sprintf() and friends

On Tuesday, August 28, 2018 at 4:49:02 PM UTC-4, peterGo wrote: > > "Width is specified by an optional decimal number immediately preceding > the verb. If absent, the width is whatever is necessary to represent the > value. " > > https://golang.org/pkg/fmt/ > > Width is two. > Thanks for the cla

[go-nuts] More trouble with date formatting

The attached program emits go1.10.1: value '2010-10-27 18:43:32 + +' error on my system. Note the duplicated zone field. Is this expected? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiv

Re: [go-nuts] Re: Unexpected behavior of %+02d in Sprintf() and friends

On Wednesday, August 29, 2018 at 7:57:23 AM UTC-4, Borman, Paul wrote: > > Is it possible you used the format string “+%02d” vs “%+02d”? The first > will give you the +00 you expected while the second is +0, as discussed. > Alas, no. Here's the line from my test program: fmt.Printf("%s: %+02d

[go-nuts] Reference to type satisfying a specified interface

I apologize if this seems like an elementary question, but web searches and reading the Go documentation is not turning up an answer. I'm in the process of translating reposurgeon, an editor for version-control histories, from Python into Go for improved performance, .The central data structure

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote: > > On Thu, Aug 30, 2018, 18:57 Eric Raymond > > wrote: > >> I'm trying to translate this to Go in a type-safe way. To do this, I need >> to be able to write two declarations: "Slice of p

[go-nuts] Re: Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 1:32:18 PM UTC-4, Akram Ahmad wrote: > > Your work on porting *reposurgeon* (from Python into Go) for improved > performance sounds very cool, Eric (BTW, your work in, and musings on, Lisp > and UNIX have been a huge influence on my evolution as

Re: [go-nuts] Reference to type satisfying a specified interface

> > If Event is your interface and EventImpl is your struct, what you need > is a map[string]Event, not map[string]*Event. Make sure you put > &EvenImpl{} to your slices and maps, not EventImpl{} > > Here'a what is confusing me. Yes, I can write _mark_to_object map[string]Event and b.re

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 2:18:38 PM UTC-4, Burak Serdar wrote: > > If b is an interface to a *Blob, what's stored in the slice is {Type: > *Blob, Value: pointer to the object}. A copy of this interface value > is also in the map. So you have two copies of the interface value, > both poi

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 3:00:18 PM UTC-4, Burak Serdar wrote: > > If you're porting from another language, you're likely to encounter > this situation soon, if not already. > Right, and because Python code often makes aggressive use of runtime polymorphism it's *particularly *likely

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 7:25:10 PM UTC-4, Nigel Tao wrote: > > On Fri, Aug 31, 2018 at 4:18 AM Burak Serdar > wrote: > > If b is an interface to a *Blob, what's stored in the slice is {Type: > > *Blob, Value: pointer to the object}. A copy of this interface value > > is also in the ma

Re: [go-nuts] Reference to type satisfying a specified interface

On Thursday, August 30, 2018 at 8:31:44 PM UTC-4, Ian Lance Taylor wrote: > > > That was helpful. I feel like I have a more solid grasp now, though > I'm a > > bit worried about what details might have changed. Is there any chance > of > > getting the author to update this and add it to th

[go-nuts] Some background on reposurgeon and my Go translation problem

There's been enough interest here in the technical questions I've been raising recently that a bit of a backgrounder seems in order. Back in 2010 I noticed that git's fast-import stream format opened up some possibilities its designers probably hadn't anticipated. Their original motivation was

Re: [go-nuts] Some background on reposurgeon and my Go translation problem

On Friday, August 31, 2018 at 4:30:08 AM UTC-4, Jan Mercl wrote: > > In case you haven't heard it before, Google was thinking on the same lines > and released Grumpy last year: > https://opensource.googleblog.com/2017/01/grumpy-go-running-python.html. > I never used the tool and it may possibl

Re: [go-nuts] Reference to type satisfying a specified interface

On Friday, August 31, 2018 at 12:06:44 AM UTC-4, Nigel Tao wrote: I'm only guessing, but I think Ian's "which docs did you look at" was referring to your previous "I was unable to extract this enlightenment from the documentation, despite sweating over it pretty hard" Well, that could be. I gro

Re: [go-nuts] Reference to type satisfying a specified interface

On Friday, August 31, 2018 at 6:55:28 AM UTC-4, ohir wrote: > > On Thu, 30 Aug 2018 18:41:48 -0700 (PDT) > Eric Raymond > wrote: > > > Oh, actually, I have one other issue; how to translate virtual methods > in a > > Python base class into Go's object m

Re: [go-nuts] Reference to type satisfying a specified interface

On Tuesday, September 4, 2018 at 7:13:50 AM UTC-4, Jan Mercl wrote: > > I'm worried the suggested editing pass could make the docs better for > newbies and less useful for non-newbies in the same time. Maybe the docs > for beginner's should be the edited, but separate _version_ of the current

[go-nuts] Space-optimization question

If I have multiple occurrences of a string constant in source code - say, "M" - can I count on the compiler to create one static instance and pass references to it everywhere? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

Re: [go-nuts] Space-optimization question

On Wednesday, September 5, 2018 at 10:12:51 AM UTC-4, Jan Mercl wrote: > > On Wed, Sep 5, 2018 at 4:00 PM Eric Raymond > wrote: > > > If I have multiple occurrences of a string constant in source code - > say, "M" - can I count on the compiler to create

Re: [go-nuts] Space-optimization question

On Wednesday, September 5, 2018 at 10:38:16 AM UTC-4, Jan Mercl wrote: > > On Wed, Sep 5, 2018 at 4:23 PM Eric Raymond > wrote: > > > Matters in my case because the deserialization of a repository history > can contain hundreds of thousands of constants like

[go-nuts] Reflecting on an outer struct from a method of an inner one.

This question is intended to assist implementation of a Go workalike for the Python Cmd library. This workalike will be made publicly available, The attached program lists Inner id as expected - that is, the fieldnames of the Outer structure. But ListFields is a method of Inner. In the attac

Re: [go-nuts] Reflecting on an outer struct from a method of an inner one.

On Thursday, September 6, 2018 at 9:45:37 PM UTC-4, Nigel Tao wrote: > > Asking about embedding and reflection sounds like an XY problem > (http://xyproblem.info/). Can you elaborate on what "walk through the > user-defined methods of a Cmd-like interpreter instance" is? > Sure. My reposurge

[go-nuts] Gitlab CI loses its marbles attempting go get.

Anyone seen behavior like this before? GOPATH=/builds/esr/reposurgeon go get golang.org/x/crypto/ssh/terminal # golang.org/x/sys/unix src/golang.org/x/sys/unix/env_unix.go:30: undefined: syscall.Unsetenv src/golang.org/x/sys/unix/ioctl.go:18: undefined: runtime.KeepAlive src/golang.org/x/sys/unix/

[go-nuts] Re: Gitlab CI loses its marbles attempting go get.

On Monday, September 10, 2018 at 5:56:23 PM UTC-4, Uli Kunitz wrote: > > Use > > GOPATH= go get *-u* golang.org/x/crypto/ssh/terminal > > The package golang.org/x/sys/unix is probably old and requires updating. > I have no problems on my machine to go get -u > golang.org/x/crypto/ssh/termi

[go-nuts] Interaction of signals with defer

If interruption of a function with defers is interrupted by an uncaught signal (say, ^C from the keyboard) do its defer hooks fire? What about defer hooks in functions up the call stack? If the interrupt happens during a defer hook's execution, do the remaining hooks in the implied LIFO queue

Re: [go-nuts] Interaction of signals with defer

On Tuesday, September 18, 2018 at 4:10:52 PM UTC-4, Ian Lance Taylor wrote: > > Signals in Go never interrupt functions. > Thank you, that was an admirably clear reply. I think this needs to be documented more prominently. Can I file an MR against the Go documentation? Web search is not telli

Re: [go-nuts] Interaction of signals with defer

On Tuesday, September 18, 2018 at 6:14:54 PM UTC-4, Ian Lance Taylor wrote: > > > Under "Default behavior of signals in Go programs" in the Signals > package > > documentation, the one sentence "Defer hooks are *not* fired after > signal > > receipt." would head off potential confusion on this

Re: [go-nuts] Interaction of signals with defer

MR and CLA submitted. -- 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/

[go-nuts] Announcing pytogo. a crude but surprisingly effective Python to Go translator

I have mentioned before on this list that I am engaged in source translation of a largeish Python prgram - 14KLOC - to Go. I found the automated AST-based translation tools already available unsatisfactory; they don't produce a quality of Go code I would consider maintainable. So I wrote my o

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

Thanks, I'll fix the bug and add that to my test loads. > > I discovered earlier today that an incautious rule steps on lambda expressions and some kinds of slice indexing. The risks of not using a parser... Until I ship 1.1 (shortly, probably tomiorrow), I recommend filtering your file in sma

[go-nuts] Re: Announcing pytogo. a crude but surprisingly effective Python to Go translator

I've fixed the bug in handling of multiline strings. 1.1 also translate commion for-loop patterns to Go, including traversing lists and dictionaries and doing enumerates. On Sunday, September 30, 2018 at 6:02:21 PM UTC-4, Michael Ellis wrote: > > I'd love to make use of pytogo my own project. I

[go-nuts] Rule-swarm attacks can outdo deep reasoning

Is promised in the thread on pytogo, I have blogged on the general topic of rule-swarm attacks in the domain of language transformation. http://esr.ibiblio.org/?p=8153 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this gro

[go-nuts] Re: Rule-swarm attacks can outdo deep reasoning

On Wednesday, October 3, 2018 at 4:05:30 PM UTC-4, Michael Ellis wrote: > > Nice writeup. Thanks. Based on today's xkcd , I > think Randall Munroe must have read it, too ;-) > Seems likely. Randall and I have been friendly. -- You received this message because you

Re: [go-nuts] Announcing pytogo. a crude but surprisingly effective Python to Go translator

On Thursday, October 4, 2018 at 4:26:44 AM UTC-4, Peter Waller wrote: > > My approach is a bit different, and works by printing the Python AST in > Go. There is an overlap in our philosophy of 'produce standalone code' and > 'help a human do the translation into idiomatic Go'. However, mine was

[go-nuts] pytogo 1.2 has shipped

I am pleased to announce the release of pytogo 1.2. https://gitlab.com/esr/pytogo New features in this release: * PEP484 type hints are now converted into Go type signatures. * Without PEP484 hints, return types of functions are now sometimes deduced. * Docstrings are moved to the godoc-prefer

[go-nuts] Generics: an unwelcome conclusion and a proposal

Recent discussion of possible generics designs has forced me to a conclusion I'm not happy with, because it requires a feature-cluster that I thought I was glad to be leaving behind in Python. That is this: The simplest and most effective way to solve the generics problem is to embrace operat

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:02:18 PM UTC-4, Ian Denhardt wrote: > > > There are other operators in the language that don't behave like > functions or methods (e.g. boolean operators like && and ||, which > short-circut), but the rest of them are things that don't have gobs of > use cases

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:32:23 PM UTC-4, Eric Raymond wrote: > > Fair enough. I am completely willing to discard the possibility of > overloading && and || > A little thought showed me that this is not required. The straightforward way to write the contract of

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 12:16:16 AM UTC-4, Beoran wrote: > > For niw, I don't see what complelling benefits allowing operators in > generic contracts would bring. > Consider Ian Lance Taylor's smoke test for generics. It is: can we implement min() and max() on a generic type. What

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Monday, October 15, 2018 at 11:59:44 PM UTC-4, Ian Denhardt wrote: > > I'm not in love with the inconsistency, and expect it to cause some > confusion with newbies, but I'd have to use it to see how big of a > footgun it is in practice. There are certainly worse ideas. > Yes. If that's th

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 6:33:26 AM UTC-4, alanfo wrote: > > However, I think it's important to learn the lessons of the past and not > follow languages such as C++ or Scala where you can overload virtually > anything or even make up your own operators which can result in confusing > or e

[go-nuts] Re: Generics with adaptors

On Tuesday, October 16, 2018 at 6:34:10 AM UTC-4, Patrick Smith wrote: > > Yet another generics discussion at > https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302 > > This one looks at what programmers would be able to do if very basic > generics were added to Go, without contr

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 9:44:23 AM UTC-4, Ian Lance Taylor wrote: > > It's not clear to me what other aspects of various generic proposals > you are picking up here. The answer is "none of them". That wasn't my goal, because all the previous generics proposals I have seen struck me as

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote: > > With regard to your reply to Ian, I'm afraid I can't agree with you that > the type parameters shouldn't be specified 'up front'. That's just too > 'dynamic' for me and not very go-like. I'd imagine it would give the > compil

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane wrote: > > Why is the implements keyword a better solution than magic names? > Because you get syntactic uniformity with primitive types without claiming namespace you don't need. It's more minimalist. Would there be any rule

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The partial vs. total order thing brings up another issue that I think > needs to be kept in mind: what are the contracts for the various > operators? > I don't undetstand rte q -- You received this message because

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

(Sorry about the post fragment that got away from me.) On Tuesday, October 16, 2018 at 3:33:58 PM UTC-4, Ian Denhardt wrote: > > > The alternative though is having to implement several different methods > with obvious implementations in terms of one another, and make sure > they're consistent.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:03:16 PM UTC-4, Ian Lance Taylor wrote: > > It's a feasible approach. But unless I misunderstand, testing > arguments at the call site means that you've discarded contracts. > I don't understand that claim. A contract (in my plan, an "implements" clause) is

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:17:36 PM UTC-4, Ian Denhardt wrote: > > What is this intended to buy us? Is this as Ian T suggests in lieu of > any kind of contract system? Oh , no. You *need* a contract system (or at least my implements clause) so you can know if a < b has a meaning when

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:41:53 PM UTC-4, Dave MacFarlane wrote: > > Now I'm confused about what problem regarding generics you're trying > to solve with operator overloading. If you can't assume anything about > the meaning of an operator other than "it returns a bool", how could a >

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 4:52:54 PM UTC-4, Ian Denhardt wrote: > > The trouble is that (in the case where you compile using the implements > <, rather than throwing an error) the type signature no longer tells you > what the constraints actually are; this information is only in the body

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Wednesday, October 17, 2018 at 11:12:19 AM UTC-4, Ian Denhardt wrote: > > My instinct here is to be conservative; we've got a boatload of use > cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail > for operators after that. Eric's proposal makes it trivial to add more >

[go-nuts] Re: Proposed changes to the Go draft generics design in the light of feedback received

On Friday, October 19, 2018 at 1:48:36 PM UTC-4, alanfo wrote: > > In the light of all the feedback there's been, I've put together a > proposal which sticks closely to the original design and only changes what > most people consider needs to be changed in some way. Some recent ideas > which s

[go-nuts] Avoiding overloading

I think Ian Denhardt is right to argue that fear of operator overloading is driving people in the generics debate to complicated, ugly workarounds that should not be. I myself do not actually want overloading as a surface feature of the language. In my original "implements" proposal, I accept

[go-nuts] Re: [ANN] pygor: yet another Python to Go regurgitator

On Saturday, October 20, 2018 at 12:17:16 AM UTC-4, Raffaele Sena wrote: > > Inspired by ESR pytogo (and tired of writing python code), I went the > complete opposite way and came up with pygor: > Bravo. I am amused by the name - puts me in mind of Discworld Igors. And if my sadly departed f

[go-nuts] Failed iterator proposals?

I have a real-world case where I need Python style iterators for performance. It's not good to eager-evaluate an event-list 259K items when you know that in the typical case you're only going to select two or three orders of magnitude fewer of them to be passed to a work function. (The list

Re: [go-nuts] Failed iterator proposals?

Thank you, that was a helpful response. -- 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://

[go-nuts] Example of setting a struct field value via reflection requested

I need an equivalent of Python setattr() - that is, set a struct member by string name - but the only example I've found on line (SetField in oleiade/reflections on GitHub) panics and dies due to what looks like a spurious Elem() call. I thought I could see how to fix it, but the resulting cod

Re: [go-nuts] Example of setting a struct field value via reflection requested

On Monday, November 5, 2018 at 6:18:27 PM UTC-5, kortschak wrote: > > https://play.golang.org/p/EtXlOCR1fDY > Thanks, I was able to adapt that into working code. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group a

[go-nuts] cmd/link: go-link-{random}/ filename breaks reproducible build on ppc64le

(First-time post; please let me know if this is the wrong place to ask or if I missed a previous post or issue when I searched. I'm willing to file in https://github.com/golang/go/issues/new if that's the agreed way to keep track, or to wait until I understand the linker infrastructure on ppc6

Re: [go-nuts] Pause failures, GC, & StopTheWorld

508s 0%: 5560+26+0.067 ms clock, 5560+7.3/26/22+0.067 ms cpu, 18->19->11 MB, 19 MB goal, 4 P gc 18 @824.133s 1%: 40566+16+0.035 ms clock, 40566+6.8/15/10+0.035 ms cpu, 23->24->18 MB, 24 MB goal, 4 P I've attached a file that also includes the schedtrace=1000, health check log m

Re: [go-nuts] Pause failures, GC, & StopTheWorld

exactly what’s happening I’ll see about a workaround such as explicit calls to runtme.GC() at safe spots or periodically, etc. Eric p.s. Here’s the top of a stack trace triggered with a panic in SIGTERM handler. It shows the make([]byte, 0, 8 * 1024 *1024) triggering gcStart(). goroutine 15

Re: [go-nuts] Pause failures, GC, & StopTheWorld

“stuck”) > and review that. Or maybe use an external sampler like ‘Instruments’ on osx, > or similar. It certainly seems like some routine is spinning - prevent GC > from happening and pausing everything else. > >> On Dec 12, 2018, at 5:20 PM, Eric Hamilton > <mailto:e.

[go-nuts] Re: C++ 11 to Golang convertor

On Thursday, January 3, 2019 at 12:11:06 PM UTC-5, Jake Montgomery wrote: > > I would note that any tool that ports from C++, or even C, to Go is going > to produce ugly, unmaintainable, and non-idiomatic code, at best. > These are two different cases. I agree that graceful C++ to Go transpilat

Re: [go-nuts] Re: C++ 11 to Golang convertor

On Friday, January 4, 2019 at 2:41:19 PM UTC-5, robert engels wrote: > > I still think it would be a nearly impossible task given the C code in the > wild - outside of threading, the common usage of ‘unions’ - there is no > way I know of to map these to a simple Go struct, or even several - y

Re: [go-nuts] boringcrypto+fipsonly: way more strict than fips 140-2?

On Wednesday, March 20, 2019 at 12:07:49 PM UTC-7, ohir wrote: > > Adam Langley is a well recognized expert in the field. I trust in his > decisions. +1 > Validated is exact version of boringcrypto: 24e.d6f5 > It will not lose its validation even if it has a bug. > If it will fix thi

Re: [go-nuts] Re: No Allman-Style, No go!

As I said, I perfecly understand you decision, and the context in which it was made. Anyway, many people here have *strongly* suggested that I must fork the Go compiler source code and fix it by myself, so I guess I'll have to do it, and find a way to add a pragma which allows to disable the se

Re: [go-nuts] No Allman-Style, No go!

2013/9/21, Michael Daconta : > I assume you say this with tongue-in-cheek; however, I cannot believe this > design decision was made. For something to borrow so liberally from C only > > to enforce "one-true" bracing style is frankly ridiculous. > When someone has coded for a long time usin

Re: [go-nuts] Re: GO Vs D

I'm still not convinced that using a language which is especially limited by design always helps in implementing the simplest solution, that will be the easiest to maintain. Maybe it's the case most of the time, but from my personal experience, you can only get that result by using the right to

Re: [go-nuts] Re: GO Vs D

I agree that despite genericity is the #1 feature requested by Go developers in Google's last official survey, there are few chances they change their mind. Idem for polymorphism. So indeed, I've clearly understood that Google and most Go developers don't care at all about having templating, g

[go-nuts] runtime.GOOS case

This may be a completely stupid or trivial question; however... I currently use this on some old code I'm working on and trying to clean things up: switch os := strings.ToLower(runtime.GOOS); os { case "windows": // do windows stuff here case "linux": // do linux stuff here default: //

[go-nuts] Re: runtime.GOOS case

penbsd` > const GOOS = `plan9` > const GOOS = `solaris` > const GOOS = `windows` > > But it's usually better to rely on build constraints rather than > conditionals at runtime. > > > > On Monday, August 7, 2017 at 5:00:24 PM UTC-4, Eric Brown wrote: >> >> Thi

[go-nuts] check for *string that is nil

Let's say I have a struct... type Contact struct { Idint `json:"id"` FirstName *string `json:"firstname"` LastName *string `json:"lastname"` Email *string `json:"email"` Phone *string `json:"phone"` Ext *string `json:"ext"` } I define contact... var contact Contac

[go-nuts] Re: check for *string that is nil

act) If anybody knows of a less-dirty way to handle this, or make that code cleaner... please let me know. I don't like the way it's being handled now, but at least it's working now. Thank you! On Tuesday, August 22, 2017 at 5:48:09 PM UTC-5, Eric Brown wrote: > > Let'

Re: [go-nuts] check for *string that is nil

/golang/2016/01/23/golang-when-to-use-string-pointers.html On Tuesday, August 22, 2017 at 7:31:55 PM UTC-5, kortschak wrote: > > Is there a reason to have the fields be *string rather than just > string? > > On Tue, 2017-08-22 at 15:48 -0700, Eric Brown wrote: > > Let

[go-nuts] Why is the cpu usage so high in a golang tcp server?

I try to implement a golang tcp server, and I found the concurrency is satisfied for me, but the CPU usage is too high(concurrency is 15W+/s, but the CPU usage is about 800% in a 24 cores linux machine). At the same time, a C++ tcp server is only about 200% usage with a similar concurrency(wit

Re: [go-nuts] Re: iconvg: a compact, binary format for simple vector graphics

Ok, thanks for your answer. As I need something really simple and lightweight, I'll probably end up writing my own format :-) Regards -- 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

Re: [go-nuts] How to build gollvm on arm platform

> > >>I'll write down a more specific list of tips and pointers to the code > later today; stay tuned. > Hi Than, I'm also very interested in this work and look forward to your update. I'm reading the gollvm code, but I haven't figured out the relationship between the various modules (llvm,

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, Thanks for your guide, this certainly helps. I don't have any specific questions at the moment. Thanks again. -- 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 em

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, when I read the code, I found enable_gc_ is false by default, the description of option "-enable-gc=" is "Enable stack map generation". I guess gollvm should have implemented garbage collection. My question are: 1, what kind of gc does gollvm currently implement, and what is the diffe

Re: [go-nuts] How to build gollvm on arm platform

o look at only life > heap pointers during scanning. > > There are some other small differences between Gollvm and GC garbage > collection (notably the representation of the global roots list) but in > general they are using pretty much the same collector. > > Thanks, Than

Re: [go-nuts] How to build gollvm on arm platform

Hi, Another three questions about test and benchmark. 1, Currently I can build all unit test executable files by "% ninja GoBackendUnitTests", but in order to run all tests, I have to run the test executable files under all the directories. Do we have a single command to perform all unit test

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, Thanks for your help, "check-gollvm" is exactly what I'm looking for. But on x86-64, there are two test failures, as the log is very long, we just put some key info here. [152/189] Checking Go package go/internal/gccgoimporter FAILED: tools/gollvm/libgo/CMakeFiles/check_libgo_go_interna

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, I'm trying to implement the abi part for arm64, and got two questions for you: 1, function CABIOracle::canPassDirectly in gollvm/bridge/go-llvm-cabi-oracle.cpp, I'm not quite understand the first if statement: if (regsInt + regsSSE == 1) return true; Why not consider whether th

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, I got it, thanks for your detailed explanation. And I'm also thinking about how to write test cases, the cabi-testgen project would be a great help, I will keep you informed if there are other questions or updates, thank you. -- You received this message because you are subscribed to

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, I got another question for you. For indirect parameters, arm-aapcs abi requires to do a copy of the parameter on stack, and then pass the address of the copied parameter to callee. I tried to do a memcpy of the indirect parameter in function Llvm_backend::genCallMarshallArgs, but fail

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, I think here should be the right place to handle this case, and I have corrected the code. I should use BlockLIRBuilder instead of BinstructionLIRBuilder. I have implemented a prototype of the code and at present everything is normal. Next I will start writing some unit test cases. The

Re: [go-nuts] ptrace arm64

Hi Ian, go-delve for arm64 (https://github.com/go-delve/delve/issues/1715) also encountered this problem, I want to fix this problem. unix.PtraceGetRegsArm64 may be not work on Linux arm64 since version 2.6.34, because PTRACE_GETREGS has been replaced with PTRACE_GETREGSET, no longer support PT

Re: [go-nuts] How to build gollvm on arm platform

Hi Than, I'm porting the unit test cases of x86 to arm64. As the difference between x86 abi and arm64 abi, for the same go code snippet, the generated llvm IRs maybe different. How do you get the correct IR result of a unit test? Such as unit test TEST(BackendCABIOracleTests, RecursiveCall1).

Re: [go-nuts] How to build gollvm on arm platform

> > The way that I had imagined this working was that either each > testpoint has a loop over the various supported ABI flavors (and checks > output for each flavor) > Yes, for those common test cases, I just did this. > or we have separate testpoints for each ABI > (e.g. TEST(BackendCABIOra

[go-nuts] glog incorrectly checks CommandLine.Parsed()

e does not seem like an acceptable tradeoff. I would like to see this PR reverted and would be happy to talk about how to better address this if others have ideas. -Eric -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubs

[go-nuts] Enforcing decimal output when using json.Encode

It appears that until go 1.8 releases, float64 values with six places of precision will always be output in scientific notation when sent through json.Marshal(). This recently fixed issue explains this: https://github.com/golang/go/issues/6384#issuecomment-261140529 In short, encoding float64

Re: [go-nuts] Re: Deleting the /r/golang subreddit

suggested? I know it's not your responsibility (Brad F.) to come up with one. I would like to see some suggestions outside of a mailing list though. Eric On Thu, Nov 24, 2016 at 3:56 PM, Brian Ketelsen wrote: > Kill it. > It's a wretched hive of scum and villainy. The Go subreddit

Re: [go-nuts] Re: Deleting the /r/golang subreddit

rk. I appreciate you reaching out to a larger audience. Is there an official way to do this, or is one needed? I would be interested in hearing what your and others thoughts are on this. - Eric On Thu, Nov 24, 2016 at 9:28 PM, Brad Fitzpatrick wrote: > To be clear, this is just my opinio

  1   2   3   >