Re: [go-nuts] S2 Compression Index

Ah thanks, but then in the S2 docs it states to use zstandard for better compression https://github.com/klauspost/compress/tree/master/zstd#zstdOn Jun 2, 2025, at 5:30 PM, Robert Snedegar wrote:On Mon, Jun 2, 2025 at 1:52 PM Robert Engels <reng...@ix.netcom.com> wrote:Have you looked at

Re: [go-nuts] S2 Compression Index

Have you looked at the S2 Geometry library? http://s2geometry.io/about/overview.htmlOn Jun 2, 2025, at 3:33 PM, Kanak Bhatia wrote:Hi Everyone,I’m currently working with MinIO and diving into its use of s2 compression for optimizing object storage performance. One area I’m curious about is the S2

Re: [go-nuts] Comparison of pointers to distinct zero-sized variables

The bigger lesson is that this is yet another example of premature optimization biting you. Developers love to prove how smart they are through clever code - few realize the ultimate cost of this. I could laugh about it if it wasn’t so common. > On Jun 1, 2025, at 10:21 AM, Oliver Eikemeier

Re: [go-nuts] eXtensible Markup for Go

It’s already there. Read up on go templates. On May 26, 2025, at 4:42 PM, Hydroper wrote:I have been looking for whether Go could be used for creating user-facing apps. If so, it would be useful to support eXtensible markup directly nested in Go code, in the form of eXtensible Markup Language (XM

Re: [go-nuts] Guaranteeing deterministic execution of Golang code

ty ones.On Monday, May 26, 2025 at 12:58:17 PM UTC+1 Robert Engels wrote:I am pretty sure that isn’t correct. You can still easily create deadlocks. The reason it is random is to avoid channel starvation.  -- You received this message because you are subscribed to the Google Groups "golang-

Re: [go-nuts] Guaranteeing deterministic execution of Golang code

I am pretty sure that isn’t correct. You can still easily create deadlocks. The reason it is random is to avoid channel starvation. On May 26, 2025, at 2:09 AM, Jason E. Aten wrote:Since I've been researching reproducible simulation testing recently, andthinking about how to maximize determinism,

Re: [go-nuts] great talk on database/memory trends, DST, and the weaknesses of Raft

I’ll learn something new. On May 24, 2025, at 8:24 PM, Robert Engels wrote:That last part is what is incorrect in my opinion. Even if the network bandwidth exceeds the memory bandwidth there is the IO overhead - which means that remote memory will be slower than local memory - as the remote memory

Re: [go-nuts] great talk on database/memory trends, DST, and the weaknesses of Raft

etwork link can now be accessed with > no penalty in throughput (although we’ll need the right software architecture to manage latency)Maybe this old news to you? :) I found it eye opening.On Sunday, May 25, 2025 at 1:52:17 AM UTC+1 robert engels wrote:I understand, but it makes no practical sens

Re: [go-nuts] great talk on database/memory trends, DST, and the weaknesses of Raft

gist I got from the OP was that because now network is faster than memory - that something fundamental has changed. This is not the case. > On May 24, 2025, at 7:51 PM, robert engels wrote: > > I understand, but it makes no practical sense. The 800GB/sec is the > throughput the f

Re: [go-nuts] great talk on database/memory trends, DST, and the weaknesses of Raft

om Gen3 to Gen5, > > and Ethernet throughput increased eightfold, to 800 Gbps on a single link > > On Sunday, May 25, 2025 at 1:19:41 AM UTC+1 robert engels wrote: >> That doesn’t make sense. Memory can’t be slower than disk - disk is either >> physical, or memory bac

Re: [go-nuts] great talk on database/memory trends, DST, and the weaknesses of Raft

That doesn’t make sense. Memory can’t be slower than disk - disk is either physical, or memory backed - which means its upper speed limit is the memory speed limit. If the presentation means to imply that ethernet is so fast - faster than memory busses themselves - that you could fan out to ach

Re: [go-nuts] minicrypt released

Stefan > > On Wednesday, May 21, 2025 at 1:15:18 AM UTC+2 robert engels wrote: >> The github readme has screen shots, but I agree with Roger that I don’t >> think that is sufficient. >> >> One thing, it appears it is not just a wrapper/GUI around GnuPG, and rather >

Re: [go-nuts] minicrypt released

The github readme has screen shots, but I agree with Roger that I don’t think that is sufficient. One thing, it appears it is not just a wrapper/GUI around GnuPG, and rather uses it’s own encryption scheme/format. If this is the case, the bar will be very high for adoption. It would need a secu

Re: [go-nuts] I saw the news today, oh boy

Well said Jason. Thanks for everything Ian. > On May 14, 2025, at 11:30 AM, Jason E. Aten wrote: > > ...that Ian Lance Taylor is departing Google > and taking a break from Go. > > Ian has been an inspiration and a leader by example > of how to foster and create a vibrant technical > community.

Re: [go-nuts] deterministic runtime with pseudo-random-number generator?

Pretty sure you cannot do this for two reasons: the runtime creates internal threads for IO and other purposes that you cannot control. Also the kernel IO / poll is non deterministic. You might have better luck with a custom tiny Go. On May 13, 2025, at 1:53 PM, Jason E. Aten wrote:I'd like to ru

Re: [go-nuts] Adding methods to non local types that use more state than available in the non local type

41599728         46.34 ns/op       18 B/op        1 allocs/opBenchmarkReadWriteSyncMap/frac_10BenchmarkReadWriteSyncMap/frac_10-8                     1         11.96 ns/op        8 B/op        1 allocs/opOn Monday, May 12, 2025 at 5:34:08 PM UTC+1 Robert Engels wrote:Why not just modify

Re: [go-nuts] Adding methods to non local types that use more state than available in the non local type

Why not just modify the code generator to add a user data pointer to the structure?I can’t imagine something like that isn’t already there? Either the code generator should be easy to enhance or it should have a side car data field - anything else is hard to rationalize as even rudimentary design. 

Re: [go-nuts] Adding methods to non local types that use more state than available in the non local type

e, and alsocall new methods that you add to EntrichedResponse.On Monday, May 12, 2025 at 1:11:22 AM UTC+1 Robert Engels wrote:Just have the parameters be interfaces and do reflection/type casting. On May 11, 2025, at 5:25 PM, Alexander Shopov <a...@kambanaria.org> wrote:Hi all,I need some guidance

Re: [go-nuts] Re: Goroutines and channels optimization

Of that I’m not sure. It is based on deep knowledge of how these things are built from the hardware to the kernel to network protocols to the service layers. It broadly falls under performance tuning of which there is lots of literature. The key element of how channels and go routines play into thi

Re: [go-nuts] single instance of package/mutex in a build?

Yes, what Axel said is what I was referring to - with the last clause in the affirmative that I don’t consider them the same package. But using a stable third package to enforce a single instance works and is what I would do. On May 11, 2025, at 3:23 AM, Jason E. Aten wrote:Thanks for the reply,

Re: [go-nuts] single instance of package/mutex in a build?

I think adding a project to your issue that demonstrates the problem would make things easier to understand. On May 10, 2025, at 11:45 PM, Jason E. Aten wrote:Is there a way to insure I've only got one versionof a package in a build?  I need to make surea single mutex is used by all goroutines.De

Re: [go-nuts] single instance of package/mutex in a build?

I don’t think a Go program can have two different version of the same package. That is what go.mod ensures and why most (all?) Go builds require access to all source code. On May 10, 2025, at 11:45 PM, Jason E. Aten wrote:Is there a way to insure I've only got one versionof a package in a build? 

Re: [go-nuts] hhtp mux performance question

he wall time which is not OK for benchmarks. I just > want to understand why it takes so long, and why is chromium twice slower ? > > Is there a scheduling switch just in the w.Write(msg) or time.Now() ? > > My CPU frequency is only 0.80Ghz showing that it’s not doing much. > >

Re: [go-nuts] hhtp mux performance question

> want to understand why it takes so long, and why is chromium twice slower ? > > Is there a scheduling switch just in the w.Write(msg) or time.Now() ? > > My CPU frequency is only 0.80Ghz showing that it’s not doing much. > > > > Le mardi 29 avril 2025 à 14:05:40 U

Re: [go-nuts] Re: hhtp mux performance question

Hi. Unless you provide a standalone test program it will very difficult for anyone to assist you. On Apr 29, 2025, at 5:03 AM, christoph...@gmail.com wrote:More strange result.With Firefox, the time measured with time.Since is 55μs on average, and with Chromium it’s on average 200μs but with a bi

Re: [go-nuts] Should os.WriteFile call Sync()?

is there and anyone doing database or critical system design knows when and why to use it. On Apr 17, 2025, at 9:18 AM, Robert Engels wrote:Even if the OS writes it to disk there is the possibility of failure due to lazy writes by the drive itself. Which is why you need full fsync- which is

Re: [go-nuts] Should os.WriteFile call Sync()?

Even if the OS writes it to disk there is the possibility of failure due to lazy writes by the drive itself. Which is why you need full fsync- which is coordinated all the way down. It is also many orders of magnitude slower. See this for performance difference details https://github.com/robaho/cpp

Re: [go-nuts] How to use weak pointers?

I think the documentation is incorrect. Normally, weak pointers are used to break retain cycles in a system that uses references to implement garbage collection. Since Go has a tracing GC this isn’t necessary. Usually, a “soft” reference, not a “weak” reference is used to implement caches. A “

Re: [go-nuts] Memory leak from sqlite3 leads to go runtime?

In principle, I would argue that there is a correctness problem. You should not rely on finalizers ever - they are catches and often optional - so the design relying on finalizers to run is what is broken. In the real world they can make solving certain problems much easier - especially with shared

Re: [go-nuts] Potential language feature for testing value membership in if statements?

For a gut check, I asked AI to generate a basic parser and tokenizer. It wrote it pretty much the way I would, except for a few places if I was really concerned about performance I MIGHT change. For instance, the isOperator() should have a precheck that the rune is even in the range before sear

Re: [go-nuts] Inconsistency in GC behavior depending on runtime.Goexit

runtime.GC()if releaseFlag.Load() {fmt.Println("released, cond:", goexit)return}time.Sleep(10 * time.Millisecond)} On Thursday, April 3, 2025 at 8:50:24 PM UTC+3 robert engels wrote:It states this in the API docs:"The cleanup(arg) cal

Re: [go-nuts] Inconsistency in GC behavior depending on runtime.Goexit

;, goexit)return}time.Sleep(10 * time.Millisecond)} On Thursday, April 3, 2025 at 8:50:24 PM UTC+3 robert engels wrote:It states this in the API docs:"The cleanup(arg) call is not always guaranteed to run; in particular it is not guaranteed to run before program exit."

Re: [go-nuts] Inconsistency in GC behavior depending on runtime.Goexit

It states this in the API docs: "The cleanup(arg) call is not always guaranteed to run; in particular it is not guaranteed to run before program exit." > On Apr 3, 2025, at 10:23 AM, Yaroslav Brustinov wrote: > > Hello, experts. > > Given following code as example: > > package main > > impo

Re: [go-nuts] Logging best practices with log/slog

I don’t think this is that complicated. The go team can change the implementation of both log to delegate to slog with some defaults. slog already has the infrastructure to support additional handlers which I think is all that is needed to support custom requirements - aka side effects - of ext

Re: [go-nuts] Potential language feature for testing value membership in if statements?

I suspect if you wrote a small real world parser you would find a negligible performance difference. I’ll look for one on GitHub. > On Mar 19, 2025, at 3:24 PM, Mike Schinkel wrote: > >  >> >> On Mar 19, 2025, at 1:55 PM, Ian Lance Taylor wrote: >> >>> On Wed, Mar 19, 2025 at 10:43 AM Mi

Re: [go-nuts] Memory leak from sqlite3 leads to go runtime?

I build it manually the routine is invisible using pprof.On Wednesday, 19 March 2025 at 13:38:04 UTC+2 Robert Engels wrote:In fact the code you reference - the close() - does things the Go docs warn specifically not to do. You may be better off using runtime.AddCleanup()On Mar 19, 2025, at 6:32 AM

Re: [go-nuts] Memory leak from sqlite3 leads to go runtime?

In fact the code you reference - the close() - does things the Go docs warn specifically not to do. You may be better off using runtime.AddCleanup()On Mar 19, 2025, at 6:32 AM, Robert Engels wrote:In principle, I would argue that there is a correctness problem. You should not rely on finalizers

Re: [go-nuts] Potential language feature for testing value membership in if statements?

Why not use something like if token.in(EOL,EOF) … with varadic args this is trivial. And with generics you probably only need to write a single ‘in’ function (haven’t tested). > On Mar 18, 2025, at 6:50 PM, Mike Schinkel wrote: > > Hi all, > > While working on a parser, I've repeatedly en

Re: [go-nuts] sharded rw mutex approaches?

uuuper slow for deletes.On Friday, March 14, 2025 at 5:32:08 AM UTC Robert Engels wrote:I know some people are put off by stuff like this, but reading the Java JDK concurrent package provides a wealth of information- it is well documented and almost all are referenced implementations of academic paper

Re: [go-nuts] sharded rw mutex approaches?

I think it is easier to just hash and shard the data set the lock is protecting - ie a lock per shard. On Mar 13, 2025, at 10:52 PM, atomly wrote:On Thu, Mar 13, 2025 at 20:29 Jason E. Aten wrote:Is there a common way to do sharded read-write locks now?I mean faster than sync

Re: [go-nuts] sharded rw mutex approaches?

ee. I canjust take the hash value modulo a the size of a fixed set of locks... Thanks Robert.p.s. awl, thanks, yes... saw that. thank you.On Friday, March 14, 2025 at 4:29:46 AM UTC Robert Engels wrote:I think it is easier to just hash and shard the data set the lock is protecting - ie a lock per shard. O

Re: [go-nuts] Memory leak from sqlite3 leads to go runtime?

debug deployment will go. I'll also check out your suggestion (problem is this reproduces only at customer env). By the way, the author of sqlite 3 package removed the finalizer for rows but the reason was "redundant call". Thanks! On Mon, Mar 10, 2025, 06:14 Robert Engels &l

Re: [go-nuts] Memory leak from sqlite3 leads to go runtime?

y setting GODEBUG=detectcleanupleaks=1, if you want to try it. It's https://go.dev/cl/634599. Happy to explain how to patch and build the Go toolchain if you're up for it.On Sunday, March 9, 2025 at 5:49:03 PM UTC-4 robert engels wrote:Looks to me like you are reading a lot of rows under a

Re: [go-nuts] Memory leak from sqlite3 leads to go runtime?

Looks to me like you are reading a lot of rows under a lock, and never releasing the lock, so the rows remain in memory. I don’t know the internals of the SQLite very well, but my understanding is that it is not really a “driver” in the traditional sense that communicates with a db - but rather

Re: [go-nuts] CGO Threads and Memory Not Being Released in Go

in my real program, it seems to help? Is >> there some underlying mechanism in Go’s thread management or memory >> allocator that could explain this difference? >> >> Thanks again for your help! >> >> >> On Tuesday, 4 March 2025 at 23:16:37 UTC+2 robert

Re: [go-nuts] CGO Threads and Memory Not Being Released in Go

Or at the github issue points out, if the thread will exit, LockOSThread my work. On Tuesday, March 4, 2025 at 2:23:28 PM UTC-6 robert engels wrote: > One way you can address this is to put a semaphore on the Go side around > the C call, so you ensure only so many C calls ar

Re: [go-nuts] CGO Threads and Memory Not Being Released in Go

This is going to create 5000 OS threads. The loop runs really quickly, and since CGO cannot use Go routines, you quickly allocate 5000 OS threads. See https://github.com/golang/go/issues/14592 > On Mar 4, 2025, at 1:26 PM, David Bell wrote: > > Hi everyone, > > I'm relatively new to Go and ev

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

ng wouldn't change that.Thanks for your interest in chasing this :)Cheers,AndiOn Tuesday, March 4, 2025 at 3:09:11 PM UTC+1 Robert Engels wrote:Actually all if the channels need to be unbuffered. Otherwise you have pending data that isn’t read when the channel is closed. When I make them all unbu

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

I think this is applicable https://github.com/golang/go/issues/30372On Mar 4, 2025, at 8:08 AM, Robert Engels wrote:Actually all if the channels need to be unbuffered. Otherwise you have pending data that isn’t read when the channel is closed. When I make them all unbuffered it works. On Mar 4

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

- the unsubscribe is the root cause of the panic- while it's still in the buffer the channel won't be closed.Cheers,AndiOn Tuesday, March 4, 2025 at 3:01:37 PM UTC+1 Robert Engels wrote:You can’t make the unsubscribe channel buffered. On Mar 4, 2025, at 7:55 AM, cpu...@gmail.com <cpu

Re: [go-nuts] Why does this channel-based pub/sub broker panic?

You can’t make the unsubscribe channel buffered. On Mar 4, 2025, at 7:55 AM, cpu...@gmail.com wrote:Thanks Jan, but this just confirms that there is a send on a closed channel. It makes me wonder though (far, very far shot): given the map of subscriptions is using the new swissmap, might that be

Re: [go-nuts] Re: GC hint for collection timing

new pages. On Feb 27, 2025, at 5:51 PM, Robert Engels wrote:Btw this technique is common place for small utility programs - it is often harder to code the object life cycle in a complicated tree - so just don’t free until the process ends. Which is why GC is so beneficial for most programs. On

Re: [go-nuts] Re: GC hint for collection timing

Btw this technique is common place for small utility programs - it is often harder to code the object life cycle in a complicated tree - so just don’t free until the process ends. Which is why GC is so beneficial for most programs. On Feb 27, 2025, at 5:47 PM, Robert Engels wrote:This is a

Re: [go-nuts] Re: GC hint for collection timing

This is a perfect case of weak references BUT these are still objects the GC needs to track, etc. A better solution for a compiler, is that if the original code did not need to free - and that was a substantial amount of the compiler garbage to make a difference - just run the compiler with GC turn

Re: [go-nuts] Re: Exposing newcoro/coroswitch

I agree. Simplifying the number of ways to perform iteration is a huge win for readability. I’ve never seen an advanced use of co routines I would consider readable. A higher level construct is immensely more readable. The blog post I shared goes into the reasons why. A language that doesn’t

Re: [go-nuts] Re: Exposing newcoro/coroswitch

That project has a link to a very interesting get in the weeds related blog post https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/On Feb 25, 2025, at 8:02 AM, Robert Engels wrote:Also, there’s this project in Go that looks interesting https://github.com

Re: [go-nuts] Re: Exposing newcoro/coroswitch

Also, there’s this project in Go that looks interesting https://github.com/sourcegraph/concOn Feb 25, 2025, at 7:17 AM, Robert Engels wrote:Hi Jason. I don’t think I was clear. I think a parser implementation is a natural fit for a generator - a generator being a specialization of a coroutine

Re: [go-nuts] Re: Exposing newcoro/coroswitch

at 4:29:44 AM UTC Robert Engels wrote:You don’t need co routines if you have real concurrency. The generator use case is simply an optimization that wouldn’t be necessary if the concurrency model was more efficient - and there was a more expressive way to use it.Hi Robert,I always enjoy your

Re: [go-nuts] Re: Exposing newcoro/coroswitch

You don’t need co routines if you have real concurrency. The generator use case is simply an optimization that wouldn’t be necessary if the concurrency model was more efficient - and there was a more expressive way to use it. I demonstrated on some Java boards that generators are easily implemented

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

I agree. When parsing you should be strict according to specifications - otherwise system security can be more easily compromised. > On Feb 20, 2025, at 11:47 PM, Kurtis Rader wrote: > > > > On Thu, Feb 20, 2025 at 9:39 PM robert engels <mailto:reng...@ix.netcom.com>

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

uts > wrote: > > On Thu, 2025-02-20 at 23:38 -0600, robert engels wrote: >> Also, see https://datatracker.ietf.org/doc/html/rfc2396#section-3 for >> more details on the scheme + authority. > > > The BNF is (including only the parts that are necessary to show > validity

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

I don’t think it is a valid url according to the rfc https://datatracker.ietf.org/doc/html/rfc3986#section-3.2 An http scheme url requires the //, see https://datatracker.ietf.org/doc/html/rfc2616#section-3.2.2 > On Feb 20, 2025, at 11:18 PM, 'Dan Kortschak' via golang-nuts > wrote: > > On T

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

- using a single slash is not valid. > On Feb 20, 2025, at 11:30 PM, robert engels wrote: > > I don’t think it is a valid url according to the rfc > https://datatracker.ietf.org/doc/html/rfc3986#section-3.2 > > An http scheme url requires the //, see > https://datatracker.ietf

Re: [go-nuts] parallel blake3, broadcast non-zero values, wait-groups integrated with chan

This sounds incorrect to me. I think the better approach might be to signal/cancel the jobs, and as the jobs cancel themselves, they will decrement the waitGroup - releasing the waiter eventually. A shared context across the jobs in a pool seems natural. > On Feb 15, 2025, at 4:18 PM, Jason E.

Re: [go-nuts] "go-import" is great, we need "go-delete"

Agreed. Better to have the Go tooling state “xxx module has been marked as a security risk” during compilation. On Feb 6, 2025, at 12:56 PM, 'Sean Liao' via golang-nuts wrote:a delete in the control of the module author would make it worse, as you can serve malicious modules for a while, then del

Re: [go-nuts] 100% CPU on load of my go application

I would start by testing on the latest Go version. You really haven’t provided anywhere enough details to help. I suspect if your app is not starting at all you have a bad image. On Feb 6, 2025, at 7:32 AM, Gavra wrote:Hi,We encountered an issue where our application consumed 100% CPU. The app wa

Re: [go-nuts] stamped lock in Go?

stic >> reads (which I suspect is really when you'd want to consider this anyway), >> the optimistic reads themselves should scale just as well and you won't need >> to apply any //go:norace annotations. This suggestion is in the same vein as >> the "don&#x

Re: [go-nuts] stamped lock in Go?

till did not complain (not sure if the results are the > expected ones. More testing would be needed). In other words, this still > seems to work: > > func (sl *StampedLock) TryOptimisticRead() uint64 { > return atomic.LoadUint64(&sl.stamp) > } > > > On

Re: [go-nuts] stamped lock in Go?

0% correct so take it for what it will) and I was >> surprised that the race detector did not really complain about anything. >> >> https://go.dev/play/p/R1alMCc-xN9 >> >> -Bruno >> >> >> On Fri, Jan 31, 2025, 6:13 AM Robert Engels > <mailto:reng...

Re: [go-nuts] stamped lock in Go?

d that the race detector did not really complain about anything. > > https://go.dev/play/p/R1alMCc-xN9 > > -Bruno > > > On Fri, Jan 31, 2025, 6:13 AM Robert Engels <mailto:reng...@ix.netcom.com>> wrote: >> Hi, >> >> Do you think it is possible to impl

[go-nuts] stamped lock in Go?

Hi, Do you think it is possible to implement a stamped lock in Go https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/StampedLock.html ? It would seem that the Go race detector would always report the “optimistic read” mode as a data race? (The docs state for Java that the va

Re: [go-nuts] PDF to text

at 19:56 robert engels  wrote:You typically can’t convert a PDF to text and do what you are trying to do.Look for PDF to XML converters - you need the “blocks” and the hierarchy in order to interpret most PDFs with any sort of complex formatting.But even with XML, tables may not work, because there

Re: [go-nuts] PDF to text

You typically can’t convert a PDF to text and do what you are trying to do. Look for PDF to XML converters - you need the “blocks” and the hierarchy in order to interpret most PDFs with any sort of complex formatting. But even with XML, tables may not work, because there is no guarantee that the

Re: [go-nuts] Issue with Adding Exception Vector Handler in Go

After more reading, if you install the vectored exception handler it should work as it can receive the exceptions outside its own stack frames. On Jan 19, 2025, at 7:47 AM, Robert Engels wrote:Read this section: Go handles the exceptions listed otherwise this is the process:Raising an exception

Re: [go-nuts] Issue with Adding Exception Vector Handler in Go

t handling based on the exception type. For most exceptions, the default action is to call the ExitProcess function.On Jan 19, 2025, at 7:45 AM, Robert Engels wrote:You need to install a handler using CGO. When it is not a Go exception it uses “continue” - eventually your handler will be called. You

Re: [go-nuts] Issue with Adding Exception Vector Handler in Go

an be translated to a go signal ...Le samedi 18 janvier 2025 à 20:20:27 UTC+1, robert engels a écrit :Are you certain the exception isn’t already being translated to a signal?go/src/syscall/types_windows.go at 40b3c0e58a0ae8dec4684a009bf3806769e0fc41 · golang/gogithub.comOn Jan 18, 2025, at 12:

Re: [go-nuts] Issue with Adding Exception Vector Handler in Go

ets continue > Continued > ``` > > I still not fully understand how you handle AddVectoredExceptionHandler in > the go runtime and why Go decided not to let the user handle their signal ... > (as you see it seems easy, escepcially when the signal is exterior to the go > ru

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

You may also want to look into ago “signal handling” as a potential solution. On Jan 18, 2025, at 8:06 AM, Robert Engels wrote:If that wasn’t clear. It doesn’t seem to be supported. You need to catch the exception in the native code and return an error code back to Go. On Jan 18, 2025, at 7

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

If that wasn’t clear. It doesn’t seem to be supported. You need to catch the exception in the native code and return an error code back to Go. On Jan 18, 2025, at 7:32 AM, Robert Engels wrote:Go and C handle errors differently: Go: Go uses error values returned from functions to handle errors

Re: [go-nuts] Re: Issue with Adding Exception Vector Handler in Go

Go and C handle errors differently: Go: Go uses error values returned from functions to handle errors. This approach makes error handling explicit and encourages developers to handle them gracefully. C: C often uses exceptions and signals to handle errors. However, C's error handling mechanisms don

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

> if err != nil { >>> return n, err >>> } > > > On 13/01/25, robert engels (reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>) wrote: >> As has been pointing out, you don’t need to read the whole thing into >> memory,

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

gt;>> Thanks very much for the links, pointers and possible solution. >>>>> >>>>> Trying to read base64 standard (padded) encoded data with >>>>> base64.RawStdEncoding can produce an error such as >>>>> >>>>>i

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

> Yes, the use of a "Rewind" method would be crucial. I guess this would need > to: > 1. error if more than one buffer of data has been read > 2. else re-read from byte 0 > > Thanks again very much for these suggestions. > > Rory > >> On 12/01/25, ro

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

Also, see this https://stackoverflow.com/questions/69753478/use-base64-stdencoding-or-base64-rawstdencoding-to-decode-base64-string-in-go as I expected the error should be reported earlier than the end of stream if the chosen format is wrong. > On Jan 12, 2025, at 2:57 PM, robert engels wr

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

ly read data. If you need to support arbitrary pushback, you'll need a more complex solution. Generative AI is experimental. > On Jan 12, 2025, at 2:53 PM, Robert Engels wrote: > > You can see the two pass reader here > https://stackoverflow.com/questions/20666594/how-can-i-p

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

ader that would be great to know. > > Since the base64 decoding error I'm looking for is an EOF, I guess the > wrapper approach will not work when the EOF byte position is > than the > io.ReadSeeker buffer size. > > Rory > >> On 12/01/25, robert engels (reng.

Re: [go-nuts] Efficiently switch io.Reader to another decoder on error

create a ReadSeeker that wraps the Reader providing the buffering (mark & reset) - normally the buffer only needs to be large enough to detect the format contained in the Reader. You can search Google for PushbackReader in Go and you’ll get a basic implementation. > On Jan 12, 2025, at 12:52 P

Re: [go-nuts] Golang ORM Performances

of simple interfaces ORM does its work well. > > If I got you wrong, please show me some example that can optimize the other > queries after returning the first result set. > > PSK > > On Sat, Dec 21, 2024 at 2:06 PM Robert Engels <mailto:reng...@ix.netcom.com>>

Re: [go-nuts] Golang ORM Performances

This is incorrect. Most ORM will efficiently execute the first query with a single SQL statement.  It’s called the N+1 Select problem and it is solvable. On Dec 21, 2024, at 3:43 AM, Luca Pascali wrote:In my experience, ORM has a structural flaw, and it cannot be otherwise (as well as a lot of au

Re: [go-nuts] Golang ORM Performances

It is not slow - but it will be if you don’t use it properly or set the database up properly. > On Dec 20, 2024, at 1:19 AM, Kerem Üllenoğlu wrote: > > Hey, > > I keep hearing ORMs - especially GORM - is slow. But I have never felted like > it was slow and used in a couple of projects now. I

Re: [go-nuts] Golang ORM Performances

I go back and forth on ORMs. I think a lot depends on the complexity of the project. Still, I wouldn’t expect the overhead of an ORM to be more than 1-2% for IO/db bound systems - if it is I suspect it is not properly configured and it is generating inefficient queries or the database tables lack p

Re: [go-nuts] Performance of using splice(2) for TCP to File case

Normally the pipe size doesn’t need to be very large if the producer and consumer “costs” are roughly the same. If the producer is costlier than the consumer than a large buffer does nothing. If the consumer is costlier than a large buffer only allow the producer to complete sooner. Otherwise, y

Re: [go-nuts] Issue with CGO and GOGC when dealing with large buffers

Sorry, you did delete a message - which was confusing... On Monday, December 2, 2024 at 4:44:09 PM UTC-6 Jason E. Aten wrote: > Sorry. I've deleted those unhelpful suggestions. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

Re: [go-nuts] Issue with CGO and GOGC when dealing with large buffers

This is exactly why people have moved to memory safe languages for critical infrastructure. Just to hard to get right and have the server be malleable. On Dec 3, 2024, at 3:31 PM, Jason E. Aten wrote:Lealem, I wasn't able to reproduce the error you were seeing (perhaps write a test case that does

Re: [go-nuts] Issue with CGO and GOGC when dealing with large buffers

You might want to run under asan, msan, and tsan - as maybe the library is corrupting it’s own data structures? Just an idea. > On Dec 2, 2024, at 4:52 PM, robert engels wrote: > > I don’t think either suggestion was unhelpful. My first thought was the > library was broken as

Re: [go-nuts] Issue with CGO and GOGC when dealing with large buffers

I don’t think either suggestion was unhelpful. My first thought was the library was broken as well, as Ian provided some evidence of. And not using CGO should almost always be your first choice when there are Go only solutions available. Too many things to get right in a highly concurrent system

Re: [go-nuts] Issue with CGO and GOGC when dealing with large buffers

Apologies - didn’t look closely - it doesn’t appear the buffer in the connection is used at all. I suspect though if you read the wolfssl api that the implementation may be async - meaning the data must remain referenced until it is sent. > On Dec 2, 2024, at 11:38 AM, robert engels wr

Re: [go-nuts] Issue with CGO and GOGC when dealing with large buffers

You are using the same buffer for reading and writing - I suspect that is your problem... > On Dec 2, 2024, at 11:00 AM, Lealem Amedie wrote: > > Hi, > > I’m trying to get an https server working by overwriting the > accept/read/write methods in the http module. I’m using go-wolfssl for TLS.

Re: [go-nuts] Do we need to drain a closed channel ?

Yes you need to manage your producers and consumers. Think about it more deeply - given your scenario what would you want to happen? Is that universal - probably not. On Nov 24, 2024, at 10:13 PM, Henry wrote:Hi all,I have been wondering about this as well. Let's say there is a channel, and the s

Re: [go-nuts] query for runtime.reportZombies data race PoC code

As I shared, ANY data race can lead to a panic. You can be interfering with the GC object tracking. I agree with you that it seems not possible, but I was surprised to learn that it is. It is not the case in Java as there are assignment guarantees even without concurrency - but the data race can ca

  1   2   3   4   5   6   7   8   9   10   >