Re: [go-nuts] Still "missing" priority or ordered select in go?

Here is a simple priority select implementation using unbuffered channels. https://play.golang.org/p/Hvl0iMr-cFW Uncomment the lines as instructed and you will see that channel A is always picked. What this demonstrates is that ‘priority’ and ‘event

Re: [go-nuts] Still "missing" priority or ordered select in go?

To simply this :your request is easily accommodated if all channel state changes and all selects are synchronized. This is easily doable but would crush performance. > On May 6, 2021, at 6:11 PM, Robert Engels wrote: > >  > > >>> On May 6, 2021, at 5:12 PM, 'Axel

Re: [go-nuts] Still "missing" priority or ordered select in go?

> On May 6, 2021, at 5:12 PM, 'Axel Wagner' via golang-nuts > wrote: > >  >> On Thu, May 6, 2021 at 11:38 PM Robert Engels wrote: > >> Yes, but barring the nanosecs of a window this is simply implemented as Ian >> wrote with >> >

Re: [go-nuts] Still "missing" priority or ordered select in go?

t`, which uses > source order to express priority and under the semantics I'm asking about, > this would always block, because `lo` would never be read. > >> On Thu, May 6, 2021 at 10:05 PM Axel Wagner >> wrote: >> >> >>> On Thu, May 6, 2021 at 9:4

Re: [go-nuts] Still "missing" priority or ordered select in go?

not “unblocking a sender” is a dubious endeavor. > On May 6, 2021, at 1:30 PM, 'Axel Wagner' via golang-nuts > wrote: > >  >> On Thu, May 6, 2021 at 8:22 PM Robert Engels wrote: > >> “If lo” means that if the lo channel was read. > > Exactly. To fulfill the requir

Re: [go-nuts] Still "missing" priority or ordered select in go?

e.g. the sender was already unblocked. A `select` would not unblock the other > side unless that's the actual branch taken. > >> On Thu, May 6, 2021 at 7:32 PM Robert Engels wrote: >> I already showed you - just change it to >> >> Select hi >> Defaul

Re: [go-nuts] Still "missing" priority or ordered select in go?

I already showed you - just change it to Select hi Default: Select hi,lo If lo: Select hi Default : Pass And enqueue the lo if a hi and lo are read. That is all that is needed. > On May 6, 2021, at 10:28 AM, 'Axel Wagner' via golang-nuts > wrote: > >  > > >> On

Re: [go-nuts] Go: pointer bit stealing technique

The Java implementation does not use bit stealing - it uses an atomic pointer to an immutable struct - the same can be done in Go. > On May 6, 2021, at 6:16 AM, Vitaly Isaev wrote: > >  > In a well-known book "The Art of Multiprocessor Programming" by Herlihy, > Shavit some of lock-free and

Re: [go-nuts] Still "missing" priority or ordered select in go?

To Ian’s point, you can try to synchronize using an external shared or multiple synced clocks - but the error is too great when comparing cpu frequency events. > On May 5, 2021, at 4:34 PM, Bakul Shah wrote: > > On May 5, 2021, at 9:55 AM, Øyvind Teig wrote: >> >> Here is my cognitive test

Re: [go-nuts] Still "missing" priority or ordered select in go?

You are over complicating things. Start with simple code based on Ian’s. Still, I think you might be misunderstanding the tug between priority and starvation. It depends on the frequency and latency of events processing. There is no structure/language that can address this. You either drop or

Re: [go-nuts] Still "missing" priority or ordered select in go?

Yes, C for instance. It doesn’t print ‘client 2’ because your code is broken. It prints “late arrival” if you remove the sleep. The main program finishes before the go routine runs. > On May 3, 2021, at 2:24 PM, Øyvind Teig wrote: > >> mandag 3. mai 2021 kl. 21:11:48 UTC+2 skrev

Re: [go-nuts] Still "missing" priority or ordered select in go?

In most “select” implementations a set of “ready” endpoints is returned. So it is trivial for the reader to prioritize some endpoints over others. Because of the way Go select works it is more difficult - requiring nested selects - and it is more easily implemented using multiple readers and

Re: [go-nuts] Still "missing" priority or ordered select in go?

I already gave you the solution to this. Trust me it works. I did HFT for 7+ years - the algo is well known. > On Apr 29, 2021, at 2:05 PM, Øyvind Teig wrote: > >  >> torsdag 29. april 2021 kl. 20:22:32 UTC+2 skrev rog: > >> I agree with Axel's take here. It seems, Øyvind, that you are

Re: [go-nuts] Still "missing" priority or ordered select in go?

To clarify, you might never process a low item if a high is always available - but I believe that is what the OP is requesting. It is also fairly trivial to add fairness to this ti always process a low if available every N cycles. > On Apr 29, 2021, at 9:31 AM, robert engels wr

Re: [go-nuts] Still "missing" priority or ordered select in go?

items. There are no free lunches. But no deadlock. > On Apr 29, 2021, at 9:26 AM, Ian Davis wrote: > > On Thu, 29 Apr 2021, at 3:09 PM, robert engels wrote: >> I will give you the pseudo code: >> >> { // step #1 do select on both >>select high >>

Re: [go-nuts] Still "missing" priority or ordered select in go?

It needs one other fix, and that is to have a check of the queue and poll high, in case the queue has elements when the method is entered. But if you implement the queue using a buffered channel it is trivial to change the step #1 to handle this (the low and queue channels are mimic the high

Re: [go-nuts] Still "missing" priority or ordered select in go?

I will give you the pseudo code: { // step #1 do select on both select high select low } if high read: return high else: // we read a low so do a high poll { select high: default: } if high read: enqueue low and return high else: if queue empty:

Re: [go-nuts] Still "missing" priority or ordered select in go?

It is trivial to do a priority select. Check the high priority channel again after getting a low priority value. If the high priority is available enqueue the low value and handle the high. It is also trivial to “delay” the handling to allow more time for high events to arrive if dealing with

Re: [go-nuts] Re: How to do vdso calls in my own code?

The point is that if you are timing “so much” that a 1-2 % overhead (so you must have tons of very small operations) matter to throughput - sampling will still capture enough that a representative event will be recorded. Still, optimizing time.Now() is always a good idea but I am guessing much

Re: [go-nuts] Re: How to do vdso calls in my own code?

If you are timing so short operations that the overhead is 1-2%, just time every 1000 calls - reduces the overhead to a minimum. Normally makes no difference if the operations are that short. Similar to how benchmarking works - time the total and divide by the number of operations. > On Apr

Re: [go-nuts] Case for Cond.WaitTimeout()

Have the channel hold a slice of objects and process them as a batch. Batch in - batch out. Typically unless your traffic is bursty - a faster producer than consumer will either cause blocking, data loss (drops) or failure (oom). > On Apr 13, 2021, at 8:00 AM, Roman Leventov wrote: > >  >

Re: [go-nuts] Re: Releasing a V2 module and interacting with git branches

Having a different v2 directory is a bad idea. It is not sustainable. It is a pain because you will have N copies of everything - so backporting bug fixes will be a pain. > On Apr 8, 2021, at 7:07 PM, Martin Atkins wrote: > > I had some experiences with doing this sort of thing for what

Re: [go-nuts] Big variations in benchmarking results ?

OSX has a very different scheduler and often many more background processes. Also, you need to ensure you are running on the exact same chipset due to variations in cpu cache sizes and implementations. > On Apr 7, 2021, at 12:27 PM, christoph...@gmail.com > wrote: > > Hello, > > I'm

Re: [go-nuts] gob non-optimal serialization in case of interface

Since Dimension can hold any instance type it needs to encode each type for each element of the slice. I would file an enhancement to use RLE when encoding interface slices. It won’t be backwards compatible though. > On Apr 4, 2021, at 10:22 AM, 'Axel Wagner' via golang-nuts > wrote: > > 

Re: [go-nuts] Re: Design patterns. builder ?

The Go protobufs impl uses the builder pattern. > On Apr 1, 2021, at 2:21 AM, Brian Candler wrote: > > The builder pattern generally isn't needed in go, because go has flexible > struct literals where you can omit any members you don't want. > > You can implement it if you like, but it

Re: [go-nuts] No generic, part -2

Generics support a library handling type-safe registry services. Using such a library will not require advanced generics understanding. > On Mar 19, 2021, at 11:53 AM, cpu...@gmail.com wrote: > > On Thursday, March 18, 2021 at 1:53:30 PM UTC+1 ren...@ix.netcom.com wrote: >> One other point

Re: [go-nuts] No generic, part -2

nd it hard to >>> avoid generics, even if they want. Usage of the language is very likely to >>> change and generics are very likely to be used in a lot of Go code. >>> >>> So, if we didn't think generics would make the language better, we >>> shoul

Re: [go-nuts] No generic, part -2

I think the most plausible events are that various collections apis make it into the api as a “replacement” for the non type safe interface based ones. > On Mar 18, 2021, at 11:20 AM, Kent Sandvik wrote: > >  > I'm very dumb, but if you don't want to use generics or think they are bad > for

Re: [go-nuts] No generic, part -2

before, I would of taken a more go-like approach - generics seem too technical for most go developers - but in the end they will be a net benefit. > On Mar 15, 2021, at 8:28 PM, Robert Engels wrote: > >  > Very well said. > >>> On Mar 15, 2021, at 7:04 PM, Jeremy F

Re: [go-nuts] About the efficency of modifying map elements.

Generics will solve this. > On Mar 17, 2021, at 4:23 PM, Matthew Holiday > wrote: > >  > Isn't this really just another form of issue 3117? > > >> On Wed, Mar 17, 2021 at 3:19 PM 'Axel Wagner' via golang-nuts >> wrote: >>> On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com >>> wrote:

Re: [go-nuts] Healthy tinygo Was: No generic, part -2

Java was actually very successful on micros. It is running on billions of IOT and smart card devices - and android on SoC. > On Mar 17, 2021, at 4:47 AM, Kevin Chadwick wrote: > >  >> >>> Go will loose its uniqueness and values, will never become a next big >> thing. No cross platform GUI,

Re: [go-nuts] Is there a final document on generics?

AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Tue, Mar 16, 2021 at 1:10 PM 'Axel Wagner' via golang-nuts > wrote: > >>> On Tue, Mar 16, 2021 at 1:05 PM Robert Engels wrote: >>> >>> Failure to provide a standard “collections” package would be a h

Re: [go-nuts] Is there a final document on generics?

Failure to provide a standard “collections” package would be a huge mistake. It is certainly a top 3 reason for the success of Java. > On Mar 16, 2021, at 6:52 AM, 'Axel Wagner' via golang-nuts > wrote: > >  > The very detailed design doc is linked in the proposal issue. That's the >

Re: [go-nuts] No generic, part -2

Very well said. > On Mar 15, 2021, at 7:04 PM, Jeremy French wrote: > > I was really trying not to weigh in here, mostly because it's a decision > that has been decided, so there's not a lot of point in continuing the > discussion, and yesterday it seemed like the thread would die, yet...

Re: [go-nuts] insane idea to eliminate CGO latency

I think it is more of using a specialized compiler on unmodified C code and expecting it to work. > On Mar 15, 2021, at 3:58 PM, Andy Balholm wrote: > >  > By the way, this existed at one point. Early versions of the Go toolchain > included C compilers (6c, 8c, etc.) designed to work

Re: [go-nuts] insane idea to eliminate CGO latency

Totally agree and that was my point. If the desire is to speed up calls to C there are many options - done explicit (like marking calls non blocking), or implicit - once a routine makes a “unknown” C native call that routine is always bound to a dedicated thread - clearly you are trading

Re: [go-nuts] insane idea to eliminate CGO latency

the scheduler is the bottleneck in calling C code. > On Mar 14, 2021, at 9:38 PM, Ian Lance Taylor wrote: > > On Sun, Mar 14, 2021 at 1:46 PM Robert Engels wrote: >> >> That was my point, based on Java, there is the ability to make the GC >> coordination extreme

Re: [go-nuts] insane idea to eliminate CGO latency

to tackle than this proposal. > On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor wrote: > > On Sun, Mar 14, 2021 at 12:00 PM Robert Engels wrote: >> >> Based on two decades of Java FFI - the overhead comes from type mapping not >> the housekeeping to control GC.

Re: [go-nuts] insane idea to eliminate CGO latency

Based on two decades of Java FFI - the overhead comes from type mapping not the housekeeping to control GC. The latter can be as simple as a volatile read and 2 writes per call and can usually be coalesced in tight loops. Since Go already has easy native C type mapping the FFi should be very

Re: [go-nuts] sort string slice like it contains key,val

That wasn’t specified in the assignment :) > On Mar 13, 2021, at 2:59 PM, Levieux Michel wrote: > >  > Your need is not only to sort your data elements then..? > Using the previously advised solution you can just range the slice *after* > you sort it, so you can just check for the next

Re: [go-nuts] struct conversion, new fields, and incompatibility

I don’t think you can separate the two - it seems the OP purpose of using the struct conversion is to facilitate a different serialization format. This is a place where Gos convenience (struct tags) is running into explicitness. The struct conversion is nothing more than a magic copy. Make this

Re: [go-nuts] struct conversion, new fields, and incompatibility

a proto-message > and try to do the same struct-conversion Colin mentions, you will run into > exactly the same problem. We are talking about language facilities here, not > third party code generators. > >> On Thu, Mar 11, 2021 at 11:48 PM Robert Engels wrote: >> If you use p

Re: [go-nuts] struct conversion, new fields, and incompatibility

If you use protobufs and the current guidelines you can always add new fields. > On Mar 11, 2021, at 12:43 PM, 'Axel Wagner' via golang-nuts > wrote: > >  > Hi, > > in some sense, every change to an exported symbol is a breaking change. So a > straight-forward "does this change have the

Re: [go-nuts] Contrary to popular opinion...

I wasn’t referring to the mixed tab/space issue. I mean you copy a few live that are at one indentation to another location with a different indentation - everything is mucked up usually. You don’t have these issues with brackets - the code is easily formatted correctly or a bracket added then

Re: [go-nuts] Contrary to popular opinion...

I think the only time the indentation is a problem is when refactoring code - copying pasting code blocks seems to be a guessing game with my IDEs and often require manual fixes - the issue seems far less common (and more easily corrected) when using brackets. > On Feb 28, 2021, at 12:12 PM,

Re: [go-nuts] Contrary to popular opinion...

Popularity has nothing to do with good - thus Twitter and the Kardashians. . > On Feb 28, 2021, at 2:35 AM, 'Dan Kortschak' via golang-nuts > wrote: > > On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote: >> I meant, for example, in regexp notation, ` *` vs `\n *` between a >> function

Re: [go-nuts] Golang problem

Please provide your answer/code and we’ll look it over. > On Feb 27, 2021, at 5:47 AM, Vignesh Kumar wrote: > > Hello all, > > Thanks in advance, please help me to finish this assignment > > You are given a string S consisting of letters 'a' and 'b'. You want to split > it into three

Re: [go-nuts] Contrary to popular opinion...

ot;delivered code". But in a personal single > machine single developer environment, all the extra complexity and manual > overhead might not worth it. I'd guess that most students and hobbyists don't > even use SCMs. My point was that GOPATH mode is good for them. > > On T

Re: [go-nuts] Incompatibility of reflection libraries (reflect versus go-reflect), on json-iterator (Go 1.15.8)

Maybe direct your inquiries to the developer if go-reflect? > On Feb 26, 2021, at 8:11 AM, Yan Titarenko > wrote: > >  > CC'ing to committers. > > Ian, > please provide some advise. > > Thanks in advance > >> On Wed, Feb 24, 2021 at 2:00 PM Yan Titarenko >> wrote: >> Hi. >> >> Since

Re: [go-nuts] Contrary to popular opinion...

That is 100% true but a important point is that using GOPATH requires manual dependency management via ‘vendoring’. This can be very labor intensive and error prone - leading to security issues in your delivered code. > On Feb 25, 2021, at 3:08 PM, Bob Alexander wrote: > >  > GOPATH mode

Re: [go-nuts] Orderly exit

rror handling should prevent/limit that. > On Feb 24, 2021, at 5:29 PM, Kevin Chadwick wrote: > > On February 24, 2021 11:16:46 PM UTC, robert engels > wrote: >> I’m sorry but that is not correct. If you have a “server process” that >> handles requests for 1000’s of clients -

Re: [go-nuts] Orderly exit

You can read the section ‘Apache Vulnerabilities’ and the difference in forking vs multi-threader Apache configuration and how that triggers a DoS. See https://www.feistyduck.com/library/apache-security/online/apachesc-CHP-5.html > On Feb 24, 2021, at 5:16 PM, robert engels wrote: >

Re: [go-nuts] Orderly exit

- especially with round-robin servicing - you can take down 1000’s of servers with 1:1 requests. > On Feb 24, 2021, at 4:04 PM, Kevin Chadwick wrote: > > On February 24, 2021 8:00:36 PM UTC, Robert Engels > wrote: >> Depending on other infrastructure that can easily lead to e

Re: [go-nuts] Orderly exit

Depending on other infrastructure that can easily lead to easy DoS attacks. > On Feb 24, 2021, at 12:15 PM, Kevin Chadwick wrote: > > On 2/24/21 9:53 AM, roger peppe wrote: >> On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick > > wrote: >> >>I only instigate panic

Re: [go-nuts] Error handling

I’ll only add to this, there is no reason to close in the exception handler - it is automatic by the try-with-resource. The only reason to check null is if you needed to “do something else” based on that state. I think a better pattern with the “something else” is to always use standard

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

I would refer you back to the other article I linked to on setting up your host name properly. When I test using the default DNS resolving I can resolve both ‘iMac’ and ‘iMac.local’ in 2-3 milliseconds without any entry in my /etc/hosts file. If I add the entry ‘iMac.local’ to my /etc/hosts

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

Nice work. > On Feb 23, 2021, at 10:16 AM, Shulhan wrote: > >  >> On 23 Feb 2021, at 12.40, Peng Yu wrote: >> >> I don’t understand why ping does not have the same problem. Ping is not >> based on C library? >> > > Looking at the source code, the ping command on macOS use

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

20 PM UTC, Robert Engels > wrote: >> I am not 100% certain but the build statement at the top of the Unix >> dns client specified Darwin. I would read the Go issues I linked to in >> the code snippet. > > I believe it varies. Android has no universal textual interfac

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

;On Darwin I believe that by > default we pass DNS lookups to the C > library." (I assume "we" means Go developers.) > > Are you correct or Ian is correct? > >> On Tue, Feb 23, 2021 at 8:14 AM Robert Engels wrote: >> >> As I pointed out, Go does not use

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

library should not be > relied on in this case. I just want to use /etc/hosts but not > resolve.conf. > >> On 2/22/21, robert engels wrote: >> It looks like the Go runtime implements its own DNS client on *unix >> platforms including OSX. >> >>>> On

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

golang.org/issue/16739. func avoidDNS(name string) bool { if name == "" { return true } if name[len(name)-1] == '.' { name = name[:len(name)-1] } return stringsHasSuffixFold(name, ".onion") } so Go issue 16739 might help. > On Feb 22, 2021, at 11:51 P

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

Still, if you follow that article I referred you to it may fix your issue - as the resolv.conf is auto-generated on OSX and includes hostname mappings. > On Feb 22, 2021, at 11:48 PM, robert engels wrote: > > It looks like the Go runtime implements its own DNS client on *unix

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

It looks like the Go runtime implements its own DNS client on *unix platforms including OSX. > On Feb 22, 2021, at 11:40 PM, Peng Yu wrote: > > I don’t understand why ping does not have the same problem. Ping is not based > on C library? > > On Mon, Feb 22, 2021 at 11:20 PM Ian Lance Taylor

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

This https://apple.stackexchange.com/questions/175320/why-is-my-hostname-resolution-taking-so-long may help you. > On Feb 22, 2021, at 11:20 PM, Ian Lance Taylor wrote: > > On Mon, Feb 22, 2021

Re: [go-nuts] Error handling

> On Feb 21, 2021, at 8:51 PM, Ian Davis wrote: > > On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote: >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes to crickets &

Re: [go-nuts] Error handling

> On Feb 22, 2021, at 8:33 AM, Wojciech S. Czarnecki wrote: > > Dnia 2021-02-21, o godz. 11:23:24 > robert engels napisał(a): > >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? > > May you please explain the bene

Re: [go-nuts] Error handling

21, 2021, at 8:52 PM, Ian Davis wrote: > > On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote: >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes to crickets >> - I have to believe th

Re: [go-nuts] Error handling

See below: > On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor wrote: > > On Sun, Feb 21, 2021 at 9:23 AM robert engels wrote: >> >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it go

Re: [go-nuts] Error handling

Can someone please explain the benefit of ‘error return’ over ‘checked exceptions’ ? I have made the point a few times and it goes to crickets - I have to believe that is because there is none, or it is difficult to communicate. The ‘handle where they occur claim’ is weak, as you can handle

Re: [go-nuts] Error handling

ut any line of code would be capable of throwing an exception. But > exceptions typically aren't counted, so that functions are thought to be far > less complex than they really are in the presence of exceptions. > > Invisible (magic) return paths through a function go against the noti

Re: [go-nuts] Error handling

robust and reliable systems. > On Feb 20, 2021, at 2:30 PM, Ian Lance Taylor wrote: > > On Sat, Feb 20, 2021 at 12:11 PM Robert Engels wrote: >> >> Can you clarify what you mean mean by “the code does exactly what it shows >> on the page”? How do you know by looking at

Re: [go-nuts] Error handling

Can you clarify what you mean mean by “the code does exactly what it shows on the page”? How do you know by looking at the code, or even compiling the code, that all possible errors returned by a function are handled? That to me is biggest difficult in reading (or using) others Go code.

Re: [go-nuts] A goroutine question

For parallelizing code like this, you will probably see better performance by having each routine process a full row rather than a cell. You amortize the overhead better. Still the matrix is probably too small to make a difference. > On Feb 19, 2021, at 8:56 AM, 'Peter Weinberger ' via

Re: [go-nuts] Error handling

There's no crossfire :) I think most of the issues I have can probably be addressed with some standardized packages without converting panic/recover into full-blown exceptions and making them the default. The key is “standardized”, which is why I’m sad to see lack of progress towards a new

Re: [go-nuts] Error handling

Yes but without robust error information (stack trace, typed error) it is very hard to write that top-level handler - at least not a robust one. Plus you are relying on the proper use of defer etc up the chain. This is much simpler with exceptions - to me anyway. > On Feb 18, 2021, at 10:39

Re: [go-nuts] Error handling

To clarify, the Java like/runtime reference I made does not strictly refer to startup costs - I am also referring to runtime costs as in additional threads for GC, housekeeping, overall binary size, etc. I don’t think ‘single shot, short lived processes’ are the typical Go paradigm - they are

Re: [go-nuts] Error handling

But - the issue is that most of the time - for complex systems - the errors cannot be handled where they are encountered - even in Go, most of the error handling becomes boilerplate returning the error detected and expecting some higher level to handle it. With exceptions this is enforced, or

Re: [go-nuts] Error handling

And I will tell you that after working with error returns and exceptions, exceptions are superior - but much depends on the complexity of the system. For small system level tools that are pieced together via pipes, C error handling is fine - because the process serves as the exception handling

Re: [go-nuts] Error handling

I think ’strong census’ is not accurate - thus the discussions around improving error handling in Go2. Many have commented here and elsewhere that the number one reason they don’t use Go is due to lack of exception handling. > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki wrote: > >

Re: [go-nuts] Re: Unable to find small memory leak

Are you using CGo or libraries that use CGo? If so, you probably have an off-heap, i.e malloc() leak > On Feb 11, 2021, at 11:11 AM, Tom Mitchell wrote: > >  > >> On Thu, Feb 11, 2021 at 3:40 AM Uli Kunitz wrote: >> You are writing: The device crashes with out of memory. What does crash?

Re: [go-nuts] x/image/font: Font serialization

If you don’t write the font “exactly” you might run into copyright/TOS problems. In most cases though, you are better off using standard fonts and using the correct name in the pdf - and let the viewer find/replace the font - you will not have a problem in that case. > On Feb 5, 2021, at

Re: [go-nuts] x/image/font: Font serialization

;> On Thursday, February 4th, 2021 at 8:28 PM, Robert Engels >> wrote: >> >> If you have the data to pass to Parse then you have the data to embed the >> font in the pdf. >> >>>> On Feb 4, 2021, at 12:02 PM, Sebastien Binet s...@sbine

Re: [go-nuts] R.I.P. Michael Jones

A sad day. A great tribute. Thanks. > On Feb 4, 2021, at 5:13 PM, Jan Mercl <0xj...@gmail.com> wrote: > >  > https://www.geospatialworld.net/blogs/goodbye-michael-jones-the-man-who-gave-the-power-of-maps-in-our-hands/ > -- > You received this message because you are subscribed to the Google

Re: [go-nuts] x/image/font: Font serialization

If you have the data to pass to Parse then you have the data to embed the font in the pdf. > On Feb 4, 2021, at 12:02 PM, Sebastien Binet wrote: > > hi there, > > Right now, I am pretty happy with the state of the > x/image/font{,/sfnt,/opentype}} packages. I can load TTF/OTF files, draw >

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

s in Go, better to be explicit and report errors rather than be clever. > On Feb 2, 2021, at 12:34 PM, 'Axel Wagner' via golang-nuts > wrote: > > On Tue, Feb 2, 2021 at 6:43 PM Robert Engels <mailto:reng...@ix.netcom.com>> wrote: > What “padding” are you referring to

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

gt; outside of a-zA-Z0-9. The most common ones use +/ and -_, so it's easy to >>> tell which is used and just accept either (and padding can be viewed as >>> optional during decoding anyway). >>> >>>> On Tue, Feb 2, 2021 at 2:37 PM Robert Engels wrote: >>&

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

Base64 is always ASCII. The encoded data may be in an arbitrary format. You need to pass additional metadata or try and detect its encoding. > On Feb 2, 2021, at 6:50 AM, roger peppe wrote: > >  > In case you find it helpful, here's a clone of the base64 command that I > wrote in Go. I did

Re: [go-nuts] How to improve the parallelism of go routine？

Unless it is an in memory database, I would expect the IO costs to dwarf the cpu costs, but I guess a lot depends on how you define ‘analytical processing’. In my experience, “out of the box” performance of Go routines in IO processing is outstanding. For the cpu bound case, I think with

Re: [go-nuts] How to improve the parallelism of go routine？

You wrote “I found that cache misses from routines switching is also a headache”. They would not be switching if they are cpu bound and there are less of than number of cpus. Remember too that you need some % of the cpus to execute the runtime GC code and other housekeeping. > On Feb 1,

Re: [go-nuts] How to improve the parallelism of go routine？

If you look at the “disrupter pattern” you’ll see what I mean. If the tasks are cpu bound - by having more threads/routines than cpus you cause inefficiencies (scheduling overhead, cache locality / invalidation, lock contention). > On Feb 1, 2021, at 9:02 PM, 颜文泽 wrote: > >  > I don't

Re: [go-nuts] How to improve the parallelism of go routine？

Having more cpu bound routines than you have physical cpus is not a good idea. > On Feb 1, 2021, at 8:21 PM, 颜文泽 wrote: > > I'll try 1.14, when writing cpu-intensive programs (I'm mainly a database), > I found that cache misses from routines switching is also a headache and I > don't know

Re: [go-nuts] normal mode and starve mode of sync.Mutex and runtime mutex?

Not sure the runtime needs it - as all lock usages are known - so the users in the runtime can ’negotiate’ fairness through other means for a particular mutex. > On Jan 31, 2021, at 8:56 PM, xie cui wrote: > > mutex in sync package and runtime is different, > mutex in runtime package is here,

Re: [go-nuts] Re: []byte and string convert?

And if you use byte[] everywhere rather than string be prepared for lots of panics and hard to detect bugs. :) > On Jan 29, 2021, at 8:35 AM, Amnon wrote: > > Generally yes. > As strings are immutable, and []byte is not, > if you convert from string -> []byte, you need a new copy which can

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

Channels are built with locks which without biased locking can lead to delays as routines are scheduled / blocked under -especially under contention. github.com/robaho/go-concurrency-test might illuminate some other options to try. > On Jan 18, 2021, at 8:13 PM, Pete Wilson wrote: > > No

Re: [go-nuts] Advice, please

in > occam, so channel-y stuff is lapsed second nature - channels just work - and > all this building barrier stuff is terribly unnatural. So my instincts are > (were?) good, but platform performance doesn’t seem to want to play along] > >> On Jan 17, 2021, at 9:21 AM, Robert En

Re: [go-nuts] Advice, please

If there is very little work to be done - then you have N “threads” do M partitioned work. If M is 10x N you’ve decimated the synchronization cost. > On Jan 17, 2021, at 9:11 AM, Pete Wilson wrote: > > The problem is that N or so channel communications twice per simulated clock > seems to

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

Wait()” > > If that were the case, none of them would ever see a non-zero count after any > one of them had seen it, and so no race condition could exist > > You suggest that that is not the case. > > (I don’t intend to be obtuse, even if I seem so) > > — P > >

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

ks very much. > Simpler than a double waitgroup, same overall effect. > > I may have a weird use case, but maybe this might be worth adding to the > examples. > > — P > >>> On Jan 16, 2021, at 6:14 PM, Robert Engels wrote: >>> >>> WaitGroups ar

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

WaitGroups are deterministic in that sense. Whether they are all released at once (there is no such thing as “at once” in practice) you have a race. You can restructure this to avoid the race. You should Add() to to the stage 1 and 2 wait groups after the Wait() returns and before you Wait()

Re: [go-nuts] Re: Advice, please

I forgot. But it’s to important to mention that different synchronization methods perform differently under contention so what works well for 2 might be really poor with 64. > On Jan 13, 2021, at 10:04 PM, Kurtis Rader wrote: > >  >> On Wed, Jan 13, 2021 at 7:58 PM Rober

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