Re: [go-nuts] Persistent memory support for Go

of pmem I don’t see why it shouldn’t be treated like any other external resource. > On Apr 3, 2019, at 5:47 PM, Robert Engels wrote: > > I think the project needs to be distributed as a patch to the Go codebase - > too much to review/maintain for security controls. > > Also,

Re: [go-nuts] Persistent memory support for Go

, just curious, maybe the use cases have changed. > On Apr 3, 2019, at 5:47 PM, Robert Engels wrote: > > I think the project needs to be distributed as a patch to the Go codebase - > too much to review/maintain for security controls. > > Also, I’m curious about the Api

Re: [go-nuts] Persistent memory support for Go

n the past few years, > including efforts to change C and Java, and adhoc libraries for C/C++, Java > and Python. These changes are our efforts to make persistent memory > accessible to Go developers. > > Thanks! > Mohit > > From: Robert Engels > Date: Wednesday, Apr

Re: [go-nuts] Persistent memory support for Go

tself ”. > > There has been a lot of work around this technology in the past few years, > including efforts to change C and Java, and adhoc libraries for C/C++, Java > and Python. These changes are our efforts to make persistent memory > accessible to Go developers. > > Thanks!

Re: [go-nuts] What happens when you call another method within a method set at the end of a method

But yes, similar to how all recursive functions can be rewritten using loops, which are more efficient, that is essentially what tail call optimization does - just that the process it automatic. > On Apr 6, 2019, at 5:21 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Sat, Apr 6, 2019 at 9:34 A

Re: [go-nuts] What happens when you call another method within a method set at the end of a method

You are correct, but I think an explicit stack is faster than most function calls, but it depends on number of parameters needed, etc. but maybe not...:) > On Apr 6, 2019, at 12:20 PM, Ian Denhardt wrote: > > Quoting Robert Engels (2019-04-06 08:00:02) > >> But yes,

Re: [go-nuts] Re: Some issues with UDP and Go

I am not sure that is the case. It is “known” that UDP doesn’t support OOB, mainly since it is not a stream - it is packet oriented, but also because it is not part of the specification - it would have to be an application level transport that adds that as far I understand. That being said, I a

Re: [go-nuts] Modifying the Runtime Scheduler

The link to the repo does not allow not credentialed access... > On Apr 7, 2019, at 5:58 AM, Tharen Abela wrote: > > I'll preface this by saying this is for academic purposes. > > I am working in the following repository > , but the following files are the

Re: [go-nuts] Modifying the Runtime Scheduler

I think it would be helpful to if you providee a summary of the issue/idea before the detailed information - it makes it nearly impossible to understand - at least for me. > On Apr 7, 2019, at 1:41 PM, robert engels wrote: > > The link to the repo does not allow not credential

Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

-Original Message- >From: Ian Lance Taylor >Sent: Apr 8, 2019 2:24 PM >To: Cholerae Hu , Austin Clements >Cc: golang-nuts >Subject: Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex >while pinned to its P? > >[ + austin ] > >On Sun, Apr 7, 2019 at 11:31 PM Cholera

Re: [go-nuts] Re: Disable test result caching from within Go code?

Where are you getting the idea that results are cached? I can't even figure out how that would be useful in a testing framework - do you mean it auto-mocks services based on past requests? I've seen nothing like this - are you sure you just don't have the wrong HTTP header fields, so the HTTP reque

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

Many generational garbage collectors work based on that principle - that recently allocated objects are most likely to be garbage, so often they are freed in a single pass. Go doesn’t do this yet, but Go pointers coupled with value structures/slices can give similar performance for many types

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

Also, you can use manually managed memory in Go, it’s just not as simple as auto managed memory. > On Apr 16, 2019, at 10:46 PM, jlforr...@berkeley.edu wrote: > > Go's garbage collector is very nice, and solves many problems that come up in > C programs. > > However, one thing I've been wonde

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

I think the OP was implying that GC is inefficient and was inquiring about certain patterns of memory use could be freed more efficiently. I think certain GC systems allow a region to be used to allocate objects then the region can be freed at once. Similar to the ongoing Java effort of a noo

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

lot of work, Plus, let's say this memory is organized as > a linked list. Would it be sufficient to just modify the pointer that points > to the > head of the list, or would I have to go through the list from tail to head, > modifying > the pointers in each list elem

Re: [go-nuts] Current Thinking on Explicit Memory Freeing?

to the > head of the list, or would I have to go through the list from tail to head, > modifying > the pointers in each list element? > > And to answer Robert Engels question - no, I'm not concerned with the > GC's performance because the memory I'm thinking about wo

Re: [go-nuts] go execution speed for float64 based calculations vs float32

At least on intel, float64 should be faster than float32 since all math is done on the fpu in 64 bits, so it needs to be converted, but the memory bus also comes into play. I would doubt it. Float32 is designed for size not performance. > On Apr 21, 2019, at 8:55 PM, lgod...@gmail.com wrote:

Re: [go-nuts] go execution speed for float64 based calculations vs float32

/n12khle-mlY > The gist of which seems to suggest that 32-bit is faster than 64 > >> On Sunday, April 21, 2019 at 10:09:09 PM UTC-4, Robert Engels wrote: >> At least on intel, float64 should be faster than float32 since all math is >> done on the fpu in 64 bits, so it needs

Re: [go-nuts] ?? Does anyone know of a good on-line doc that describes how Go Garbage Collection works .. My recent web searches proved fruitless

Try this https://blog.golang.org/ismmkeynote > On Apr 23, 2019, at 5:46 PM, Wojciech S. Czarnecki wrote: > > On Tue, 23 Apr 2019 07:39:18 -0700 (PDT) > lgod...@gmail.com wrote: > >> all responses appreciated >> > > https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e?gi=da46a757af

Re: [go-nuts] Go if else syntax .. suggested replacement

Why? You have saved 5 characters for no practical gain. I think you would enjoy Ada. > On Apr 23, 2019, at 8:05 PM, lgod...@gmail.com wrote: > > It sure would be nice if Go syntax allowed programmers to replace > > if ( test) { > ...do sonething > } else { > ..do something else > } > > with

Re: [go-nuts] Go if else syntax .. suggested replacement

Though to the ops point, not sure why Go doesn’t have the ternary operator - which is pretty ubiquitous. > On Apr 23, 2019, at 9:56 PM, Robert Engels wrote: > > Why? You have saved 5 characters for no practical gain. I think you would > enjoy Ada. > >> On Apr 23, 2

Re: [go-nuts] Go if else syntax .. suggested replacement

That’s not what he meant. It takes 5 lines for a trivial assignment if/else rather than 1 line with a ternary with no loss in readability. > On Apr 24, 2019, at 7:11 AM, Jan Mercl <0xj...@gmail.com> wrote: > >> On Wed, Apr 24, 2019 at 2:04 PM Mark Volkmann >> wrote: >> >> The idea of adding

Re: [go-nuts] Go if else syntax .. suggested replacement

Yes, but the FAQ has similar concerns about readability and maintainability as reasons for not having generics, but adds the language “may change”... not sure that is consistent with the views on the tenant operator. > On Apr 24, 2019, at 9:52 AM, Ian Lance Taylor wrote: > > The lack of the ?

Re: [go-nuts] Go if else syntax .. suggested replacement

looks just about as unreadable as any > ternary operator out there): > > // ternary returns 12345 if x is positive (x > 0). > // It returns -1 otherwise. > func ternary(x int) int { > return map[bool]int{true:12345,false:-1}[x>0] > } > > > >> On Thur

Re: [go-nuts] Go if else syntax .. suggested replacement

gt;> example. >> if value != nil { >>datalen = len(value) >> } >> >> >> >>> On Thu, Apr 25, 2019 at 1:05 AM Robert Engels wrote: >>> I’m pretty sure you’re joking... but I think most are referring to simple >>> usages, like

Re: [go-nuts] Re: Go if else syntax .. suggested replacement

Your original proposal did not have the colon and also implied the {} were mandatory. And what stops the sane syntax from. Ring nested ? > On Apr 24, 2019, at 6:28 PM, lgod...@gmail.com wrote: > > Just to clarify : My original proposal was to include as part of Go the > syntax > > (test) ? {

Re: [go-nuts] Re: Go if else syntax .. suggested replacement

Wow that was some bad typing + bad auto correct... > On Apr 24, 2019, at 9:15 PM, Robert Engels wrote: > > Your original proposal did not have the colon and also implied the {} were > mandatory. And what stops the sane syntax from. Ring nested ? > >> On Apr 24, 2

Re: [go-nuts] Go if else syntax .. suggested replacement

Go vet doesn’t report on structural issues - and those are far harder to work with/debug than code with the proper use of ternary operators (or even poor use) Bad code is bad code no matter how you get there. On Apr 25, 2019, at 7:05 AM, Lucio wrote: >> >> But don't deny others the ability to

Re: [go-nuts] Parsing Raw Syslog messages

That package parses syslog msgs according to rfc3164 so if that works for you then use it. > On Apr 25, 2019, at 11:55 AM, Nitish Saboo wrote: > > Hi, > > Can someone please guide me on this ? > > Thanks > >> On Thu, Apr 25, 2019 at 2:27 PM Nitish Saboo >> wrote: >> Hi, >> >> I want to p

Re: [go-nuts] Go if else syntax .. suggested replacement

The problem is that Go already has if and else and else if (which would look really weird in your proposal) Changing a word to a symbol does not enhance meaning - it reduces it, and increases the learning curve. Like I said, you will probably like Ada - lots of symbols there. > On Apr 25,

Re: [go-nuts] Parsing Raw Syslog messages

164 format or was it in RFC 5424 format ? > 3)Since I have to send the parsed message to a syslog engine, Do I have to > send the entire LogParts to the Syslog-engine ? > > Thanks > >> On Fri, Apr 26, 2019 at 12:03 AM Robert Engels wrote: >> See >> https://g

[go-nuts] strange bug

I accepted a PR for my fixed project. It was done by an expectedly experienced developer and it includes a test case. I find it very hard to believe that the author didn’t run and verify the test case, so that leaves me to believe that something in Go has change

Re: [go-nuts] strange bug

Yes, I heard back from the author that he was using tip. Thanks for the help. > On Apr 28, 2019, at 10:03 AM, andrey mirtchovski > wrote: > >> So, the question is: why ‘i’ isn’t treated as unsigned, since it is a range >> index - won't it always be positive? > > The author of the PR was most

Re: [go-nuts] strange bug

But still, it would seem the range index should be unsigned - what would be the purpose of it being signed? Similarly, the slice indexing should be unsigned as well. Just thinking about it... > On Apr 28, 2019, at 10:03 AM, andrey mirtchovski > wrote: > >> So, the question is: why ‘i’ isn’t t

Re: [go-nuts] strange bug

Thanks. Interesting that in all my time with Go I didn’t really think about it. > On Apr 28, 2019, at 10:21 AM, andrey mirtchovski > wrote: > >> But still, it would seem the range index should be unsigned - what would be >> the purpose of it being signed? Similarly, the slice indexing should b

Re: [go-nuts] Re: Should IP.DefaultMask() exist in today's Internet?

The net mask is not part of the ip packet. It is a local config in the router. > On May 2, 2019, at 7:20 AM, Louki Sumirniy > wrote: > > Upon review one thing occurred to me also - Netmasks are specifically a fast > way to decide at the router which direction a packet should go. The interface

Re: [go-nuts] Why does this simple snip generate an infinite loop ?

Because when u add 1 to 0xff it goes back to 0 since it is only 8 bits > On May 2, 2019, at 12:22 PM, lgod...@gmail.com wrote: > > func main() { > > var c8 uint8; > var S [256] uint8; > >for c8 = 0x00; c8 <= 0xff; c8 += 0x01 { S[c8]= c8 } > } > -- > You received this message be

Re: [go-nuts] Re: using channels to gather bundles from inputs for batch processing

Channels use sync primitives under the hood so you are not saving anything by using multiple channels instead of a single wait group. > On May 2, 2019, at 5:57 PM, Louki Sumirniy > wrote: > > As I mentioned earlier, I wanted to see if I could implement a waitgroup with > channels instead of

Re: [go-nuts] Re: Should IP.DefaultMask() exist in today's Internet?

I only mentioned it because you wrote: > The interface netmask is part of the IP part of the header and I’m also fairly certain it is not part of ARP - ARP maps MAC addresses to IP addresses on the local subnet. > On May 2, 2019, at 7:22 PM, Louki Sumirniy > wrote: > > The interface netma

Re: [go-nuts] Re: Random panic in production with Sprintf

Whenever I see fast* I think someone took shortcuts to make something “faster” without fully implementing the spec (or external constraints, like safe data access) > On May 2, 2019, at 7:16 PM, Burak Serdar wrote: > >> On Thu, May 2, 2019 at 6:02 PM XXX ZZZ wrote: >> >> No use of C via CGO a

Re: [go-nuts] Extend map with another map

I think the most straight forward way in go is just use 2 calls (pseudo) done:= handleVerbs(g.Verbs) If !done && includeSysVerbs { handleVerbs(sys.Verbs) } If it is more involved than that then use an internal delegating to parent pattern and declare a struct like ActionMap, that takes a pare

Re: [go-nuts] Flushing keyboard buffer (cross platform) ?

You can easily write a portable one. Just read and discard until no more available. Then make the call to the input read. > On May 3, 2019, at 7:28 AM, Steve Mynott wrote: > > I've a terminal app where I read y/n confirm using fmt.Scanln and I'm trying > to flush the keyboard buffer before t

Re: [go-nuts] Re: Does fmt.Fprint use WriteString ?

I suggest that it might benefit you to understand cost of IO. In most systems the IO cost dwarfs the CPU cost of optimizations like these. I am not saying it never matters - I have significant HFT experience and sone HPC - but in MOST cases it holds true. So micro optimizing the CPU usually ha

Re: [go-nuts] Re: Does fmt.Fprint use WriteString ?

it addresses is > buffered, if performance is needing to be squeezed just a little more. But > the buffer matters far more. > >> On Friday, 3 May 2019 16:54:37 UTC+2, Robert Engels wrote: >> I suggest that it might benefit you to understand cost of IO. In most >>

Re: [go-nuts] Re: Flushing keyboard buffer (cross platform) ?

Since people keep referring to “flush”. I’ll chime in again. Thus is not the correct way to do this, as many routines buffer input. Flushing the driver does nothing to characters already in the buffer. Flushing the driver is only appropriate if also doing direct reads from the driver - if you ar

Re: [go-nuts] request for feedback on this channel based waitgroup

The reason your code is shorter is that it is broken. I tried to explain that to you. Try running the stdlib wait group tests against your code. They will fail. > On May 4, 2019, at 4:22 PM, Louki Sumirniy > wrote: > > Those who follow some of my posts here might know that I was discussing t

Re: [go-nuts] Re: Flushing keyboard buffer (cross platform) ?

Correct, and with Go’s lightweight IO, the timeouts are cheap, so a simple read with short timeouts is all you need to flush. > On May 4, 2019, at 3:32 PM, roger peppe wrote: > > > >> On Sat, 4 May 2019, 04:33 Robert Engels, wrote: >> Since people keep referring t

Re: [go-nuts] How to run a go method on multiple cores ?

I believe you can use lockOSThread to pin a processor to the current thread, then use native code to pin the thread to a particular processor, change its priority, etc. I haven’t tried it but I see no reason it wouldn’t work - similar to how it’s not supported in Java but you can still do it - w

Re: [go-nuts] Timers and implementation of a timeout system on requests

I don’t think your requirements are completely specified. For example, you say the timeout is 100ms - nothing is ever exact - what is the tolerance in the delay before it is cancelled ? Are the calls in the handler even cancelable? What type of hardware (64+ cores?) I think this is why you are

Re: [go-nuts] Timers and implementation of a timeout system on requests

That being said, 5000 requests per second is pretty low on any reasonable hardware. You can review github/robaho/go-trader - it does 30k requests per sec on desktop machines. > On May 10, 2019, at 7:58 AM, Robert Engels wrote: > > I don’t think your requirements are completely speci

Re: [go-nuts] Timers and implementation of a timeout system on requests

interval but you get the general idea. > On May 10, 2019, at 8:03 AM, Robert Engels wrote: > > That being said, 5000 requests per second is pretty low on any reasonable > hardware. You can review github/robaho/go-trader - it does 30k requests per > sec on desktop machines.

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

There is no claim because that is not how Go interfaces work - if you implement it, you are it - that being said, I wouldn’t use Read() with UDPConn - I would use one of the packet/msg reader methods instead. Read() is a pass through to fd.Read() so it will be implementation dependent, but posi

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

t a correct implementation of > io.Reader. Nor is an implementation correct if it retains the buffer. > > Just as the BDNF is not a complete definition of the grammar of the > language, interface type decls are not complete definitions of > interfaces. > > This is why I am aski

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

erface; net.Conn has the explicit method, not an embedding > of io.Reader. > > I'd like to hear from someone who contributed to net. > > On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote: >> Which is a big problem with the Go “interface” specification… >>

Re: [go-nuts] guarantees on net.Conn and net.UDPConn Read

endly and > helpful input. > > On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote: >> As I said, I reviewed the code - which you can do as well. It is >> below. At least for “unix-ish” systems - it goes to syscall.Read() >> which is why I linked you to the unix documentati

Re: [go-nuts] Passing structures containing other pointers to ioctl: Go vs Cgo memory

If Go ever adding a compacting collector I don't think these techniques would work - I would start with cgo as you will be protected then.-Original Message- From: Matt Layher Sent: May 17, 2019 9:44 AM To: golang-nuts Subject: Re: [go-nuts] Passing structures containing other pointers to

Re: [go-nuts] Passing structures containing other pointers to ioctl: Go vs Cgo memory

I only meant that if if the driver retains this pointers... In reading Ian's email, the top-level pointer will be retained and not collected, and it has references to the contained pointers.-Original Message- From: Robert Engels Sent: May 17, 2019 10:45 AM To: Matt Layher , golang

Re: [go-nuts] Re: io.Copy and Writer

You do not need to flush if you call close. Close will flush. There is some other bug in your code I believe. > On May 21, 2019, at 3:01 AM, Jan Mercl <0xj...@gmail.com> wrote: > >> On Tue, May 21, 2019 at 9:44 AM wrote: >> >> Usually though, you do not need to buffer the input or output at a

Re: [go-nuts] Re: io.Copy and Writer

mt.Println("Error while flushing writer:", err) > return > } else { > fmt.Println("Flushed writer.") > } > > fmt.Println("Copied", n, "bytes.") > } > > > Output: > > ➜ throttle-and-resume-download go run copyTest.go &g

Re: [go-nuts] Re: io.Copy and Writer

That’s what I was saying, I incorrectly thought that the Writer was a WriterCloser. Seems it should be with a noop if the contained Writer is not a WriterCloser. This would be pretty much how every other platform does buffered IO. > On May 21, 2019, at 11:19 AM, howardcs...@gmail.com wrote: >

Re: [go-nuts] Re: io.Copy and Writer

> would make it less general. > >> On Tue, 21 May 2019, 19:02 Robert Engels, wrote: >> That’s what I was saying, I incorrectly thought that the Writer was a >> WriterCloser. >> >> Seems it should be with a noop if the contained Writer is not a >> Write

Re: [go-nuts] Re: io.Copy and Writer

must pass the concrete class to subordinates so they can close, or the subordinates must do type casting. The bufio.Writer is badly broken and should be changed to declare Close and pass this to the contained Writer if it is a WriterCloser. > On May 21, 2019, at 5:42 PM, Robert Engels wr

Re: [go-nuts] Re: io.Copy and Writer

Now that’s a good idea ! Hopefully sometime today. :) > On May 22, 2019, at 8:15 AM, Ian Lance Taylor wrote: > >> On Wed, May 22, 2019 at 9:02 AM Robert Engels wrote: >> >> The more I think about this, the more I believe that this is a horrible >> situ

Re: [go-nuts] Re: io.Copy and Writer

The very fact that you downvote a proposal without reading it says a lot. > On May 22, 2019, at 8:21 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Wed, May 22, 2019 at 3:15 PM Ian Lance Taylor wrote: > >>> The bufio.Writer is badly broken and should be changed to declare Close and >>> pass t

Re: [go-nuts] Re: io.Copy and Writer

I don’t believe your example is correct. In order for a current wrapper to call Flush on Close on the bufio.Writer the Close would need to be defined on the Wrapper struct so there would be no name collision. I think it is best to see the proposal before commenting. I plan on addressing any co

Re: [go-nuts] Data race question in config package of harvester

Ignore the incorrect comments from the others. There are many valid cases where relaxed concurrency rules apply and you don’t need synchronization just atomic ops (and with certain platform this is not needed - eg java volatile)That is why GC systems can outperform non GC systems in concurrent s

Re: [go-nuts] Data race question in config package of harvester

I was referring to updating a reference to a string, which can be updated atomically. This is an advantage that Java offers over Go for concurrent programming. Since everything is reference you don’t face this distinction. Which is why most Go uses channels, which are implemented with locks.

Re: [go-nuts] Data race question in config package of harvester

Using atomics, which is what I stated to do, avoids the data race and is Edie sully useful with weak atomics. > On May 26, 2019, at 1:37 PM, Sotirios Mantziaris > wrote: > > I was thrown of by the previous comment. > I think i will create some "atomic" types that handle using mutexes with >

Re: [go-nuts] Data race question in config package of harvester

* especially > On May 26, 2019, at 1:51 PM, Robert Engels wrote: > > Using atomics, which is what I stated to do, avoids the data race and is Edie > sully useful with weak atomics. > >> On May 26, 2019, at 1:37 PM, Sotirios Mantziaris >> wrote: >> >>

Re: [go-nuts] Data race question in config package of harvester

PM, Wojciech S. Czarnecki wrote: > > On Sun, 26 May 2019 13:50:13 -0500 > Robert Engels wrote: > >> This is an advantage that Java offers over Go for concurrent programming. >> Since everything is reference you don’t face this distinction. Which is why >> most Go use

Re: [go-nuts] Data race question in config package of harvester

And for the OP, there are atomics defined for strings - so what I referred you to is still valid. > On May 26, 2019, at 4:21 PM, Robert Engels wrote: > > I said nothing to the contrary. I was referring to the structures the poster > discussed - which are not heap allocated wit

Re: [go-nuts] Data race question in config package of harvester

u must read the rest of this document to understand the behavior >> of your program, you are being too clever. >> >> Don't be clever. > > > On Sun, 2019-05-26 at 12:51 -0500, Robert Engels wrote: >> Ignore the incorrect comments from the others. There are man

Re: [go-nuts] Data race question in config package of harvester

ng, but not > what they are actually saying. > > On Mon, 2019-05-27 at 07:10 -0500, robert engels wrote: >> They are not clever. They are foundational in high performance lock- >> free structures and other techniques commonly found in HPC and HFT - >> and even the linux k

Re: [go-nuts] Data race question in config package of harvester

ce > optimisation. From the OP, the sensible approach looks like a > sync.RWLock-protected struct with getters and setters. > >> On Mon, 2019-05-27 at 14:58 -0500, robert engels wrote: >> I’m sorry if you think I put words in your mouth, I did not mean to. >> >> C

Re: [go-nuts] Re: Interesting public commentary on Go...

Watch out, you must not mention java here - at a minimum spell it with lowercase so you can pretend you were talking about coffee :) > On May 29, 2019, at 6:55 AM, JuciÊ Andrade wrote: > > Registering Go as a trademark is important to protect it against improper use. > Let's not forget "Sun vs

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

Is that really true though? You can have one package that defines min/max for the built-in types (because it uses operators), and then one that uses method(s) Less() and Equals() that works with generics. A similar technique can be used in sorting. -Original Message- >From: David Ri

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

Isn't a lack of ARC support a critical limitation, as ARC is required going forward, and many of the newer API's assume ARC behind the scenes?-Original Message- From: Greg Pomerantz Sent: May 30, 2019 8:25 AM To: golang-nuts Subject: [go-nuts] Announcing NSWrap -- a comprehensive Objectiv

Re: [go-nuts] Announcing NSWrap -- a comprehensive Objective-C binding generator for MacOS

ollection system. As long as Clang has a -fno-objc-arc > flag, there should be no problem turning ARC off. > > On Friday, May 31, 2019 at 11:51:01 AM UTC-4, Robert Engels wrote: > Isn't a lack of ARC support a critical limitation, as ARC is required going > forward, and many

Re: [go-nuts] How can I debug high garbage collection rate cause high CPU usage issue in golang

You really can't.You control CPU usage by the GC by allocation rate, the number of live objects, and the collection rate. If you slow the collector (lower CPU), you will have higher memory usage because the GC won't have time to collect the garbage.In general, the only things you are in control of

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

-Original Message- >From: Randall O'Reilly >Sent: Jun 5, 2019 1:58 PM >To: Ian Lance Taylor >Cc: Michal Strba , golang-nuts > >Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up restricting >types > >On Jun 5, 2019, at 12:03 PM, Ian Lance Taylor wrote: >> >> On Wed

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

-Original Message- >From: Randall O'Reilly >Sent: Jun 5, 2019 2:33 PM >To: Robert Engels >Cc: Ian Lance Taylor , Michal Strba , >golang-nuts >Subject: Re: [go-nuts] Go 2 generics counterproposal: giving up restricting >types > >That is a good

Re: [go-nuts] How to confirm a function is NOT compiled into a go binary

Since Go effectively requires source code for compilation, I think what you’re asking for is impossible as the dev can just copy the source under a different function name, including most stdlib code. > On Jun 8, 2019, at 1:48 PM, Andrew Klager wrote: > > Take a look at https://golang.org/cm

Re: [go-nuts] Re: weak references

Isn't the "Go Way" for something like this to have the listeners explicitly unregister themselves ?It does make certain event listener patterns more difficult, but I don't think it requires WeakRefs to implement.-Original Message- From: tgptial...@gmail.com Sent: Jun 13, 2019 5:39 AM To: go

Re: [go-nuts] Re: weak references

heard of it but I literally started programming Go yesterday x'Dquinta-feira, 13 de Junho de 2019 às 17:29:37 UTC+1, Robert Engels escreveu:Isn't the "Go Way" for something like this to have the listeners explicitly unregister themselves ?It does make certain event listener patter

Re: [go-nuts] Re: weak references

Alves Sent: Jun 13, 2019 2:12 PM To: "tgptial...@gmail.com" , golang-nuts , Robert Engels Subject: Re: [go-nuts] Re: weak references Yes, I understand. But if I have a productive language that doesn't need me to call it better. In C/C++ it's also easy, whoever ca

Re: [go-nuts] Re: weak references

d-in-weak-references-Original Message- From: Ricardo Alves Sent: Jun 13, 2019 2:46 PM To: "tgptial...@gmail.com" , golang-nuts , Robert Engels Subject: Re: [go-nuts] Re: weak references Thank you for your response again. In the case where anonymous classes are used, the ano

Re: [go-nuts] Re: is there a goroutine scope global veriable ?

Side-managed thread/execution context has been around since the concept of a thread. It is highly useful, and is more robust and secure than a Context object passed among methods.If Go had any concept of a "secure runtime" it would be essential, but it doesn't, so you make do with what you have.---

Re: [go-nuts] Re: is there a goroutine scope global veriable ?

nt: Jun 20, 2019 2:46 AM To: Michael Jones Cc: Robert Engels , golang-nuts , jake6...@gmail.com Subject: Re: [go-nuts] Re: is there a goroutine scope global veriable ? On a practical note I think thread local storage is more or less discouraged in for example Java as wellbecause it makes all the

Re: [go-nuts] Go runs multiple threads for a serial process

The Go runtime has several threads, for GC, scheduler, etc. > On Jun 26, 2019, at 4:48 AM, Subramanian Sridharan > wrote: > > Hi guys > > Today while analyzing CPU usage of one of our processes written in go, I > noticed that there were multiple threads associated with the process which is

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

If you don’t understand the history you are doomed to repeat it. The ‘try’ proposal is barely better than the current situation. There is as a reason exception handling with try catch was designed along with OO. It simplifies error handling immensely. “Try” as you might, you might think you are

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

dling). > On Jun 29, 2019, at 3:03 PM, Burak Serdar wrote: > > On Sat, Jun 29, 2019 at 1:45 PM Robert Engels <mailto:reng...@ix.netcom.com>> wrote: >> >> If you don’t understand the history you are doomed to repeat it. The ‘try’ >> proposal is barely better

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

o Survey and vocally invite everyone to participate. > > On Sat, Jun 29, 2019 at 2:03 PM Burak Serdar wrote: >> >> On Sat, Jun 29, 2019 at 1:45 PM Robert Engels wrote: >>> >>> If you don’t understand the history you are doomed to repeat it. The ‘try’ >>

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

Which is why nothing should be done, because every proposal is going to fall short of exception handling, and be little more than syntactic sugar over what is available today. And Go has advantages over in many areas so stating “if you want decent error handling use Java” makes my case quite n

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

was released in the last 2 years? > On Jun 29, 2019, at 6:11 PM, Wojciech S. Czarnecki wrote: > > On Sat, 29 Jun 2019 15:20:11 -0500 > robert engels wrote: > >> Java and C++ are the dominant languages in use today, > > Fortunately for the mankind both C++ and Java

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

t Andrey wrote; he said if you want java error handling > us java. No where in his post was any explicit value judgement on the > approach. > >> On Sat, 2019-06-29 at 15:41 -0500, Robert Engels wrote: >> And Go has advantages over in many areas so stating “if you want >>

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

superiority because you believe it's superior. Not everyone > agrees. Many see a nightmare. > > On Sat, 2019-06-29 at 18:27 -0500, Robert Engels wrote: >> It was certainly implied given the context - Java’s superior error >> handling will not make it to Go (for a variet

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

I think the hostility stems from the fact that there are two very distinct camps (sort of mirrors the current political world). There are those that think the current Go way is fine, and no need to fix it. There are others that think it needs to be radically overhauled (and that ‘try’ doesn’t go

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

at you consider significant we can better understand the types of projects you have in mind (in reference to my other email regarding focus). > On Jun 30, 2019, at 3:38 AM, Wojciech S. Czarnecki wrote: > > On Sat, 29 Jun 2019 18:25:37 -0500 > Robert Engels wrote: > >> What

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

great applications language, but I’m doubtful as the concerns are too distinct. > On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor wrote: > > On Sat, Jun 29, 2019 at 12:45 PM Robert Engels wrote: >> >> If you don’t understand the history you are doomed to repeat it. The

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

reviewer. > On Jun 30, 2019, at 6:16 AM, robert engels wrote: > > I am not sure the ‘unexpected flow control’ concern is of the same importance > as when this statement was first written, given paradigms like ‘reactive > programming’ (I don’t like it, but it seems most others a

<    1   2   3   4   5   6   7   8   9   10   >