Hi there,
Thank you for the suggestions. I'll explore the Document AI as a potential
solution and will look into PDF to XML converters as well.
Best regards,
Hugh
On Thu, Jan 23, 2025, 4:35 PM wrote:
> golang-nuts@googlegroups.com
> <https://groups.google.com/forum/?utm
50ns is approximately the cost of a cross-CPU L2 cache miss. Any time you
have tight cross-CPU communication, you're going to incur that cost no
matter how the communication is performed — whether it's via a sync.Mutex,
a channel, or an atomic write.
The way to eliminate that cost is to elimina
t; ./main.go:13:12: undefined: gols
> ./main.go:60:12: undefined: gols
>
> These are the lines referred to in the compiler output above
>
> import (
> "github.com/drgo/gols"
> )
>
> var config gols.Config
>
> if err :=gols.Serve(&config); err!= ni
n has an upper limit cost of 50 ns.
> So tomorrow we try the custom sync approach. Results will be published.
>
> Meanwhile, thanks to all for thoughts and advice
>
> — P
>
>
>> On Jan 18, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote:
>>
>> golang-nuts@googlegro
18, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote:
>
> golang-nuts@googlegroups.com
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics>
> Google Groups
> <https://groups.google.com/forum/?utm_source=dig
I think it is simpler to create a SyncPoint with Wait and Release methods - it
is easily implemented with a WaitGroup and a Semaphore.
> On Jan 16, 2021, at 9:31 PM, Pete Wilson wrote:
>
> By ‘at the same time’ I would understand that none of them are able to see
> the counter in the wait gr
By ‘at the same time’ I would understand that none of them are able to see the
counter in the wait group after one member had triggered release.
That is, I believed that “release by any go routine (that is, a Wait() done by
any collaborating goroutine which saw a zero counter) " happened before
It does release them all at once. They all become ready to run at the “same
time” - the scheduler has to get them to run. Even if the release was atomic it
would make no difference in the race condition.
> On Jan 16, 2021, at 7:35 PM, Pete Wilson wrote:
>
> Makes sense.
> Thanks very much.
>
Makes sense.
Thanks 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 are deterministic in that sense. Whether they are all
Brian
Thanks for advice. I’ll take a look
— P
> On Jan 16, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote:
>
> Brian Candler mailto:b.cand...@pobox.com>>: Jan 16
> 01:02PM -0800
>
> On Saturday, 16 January 2021 at 16:28:59 UTC Pete Wilson wrote:
>
> &g
resets.
>
> But that with extra path length I should also look again at channels.
>
> — P
>
>
>> On Jan 16, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote:
>>
>> golang-nuts@googlegroups.com Google Groups
>> Topic digest
>> View all topics
&g
ed to construct it from two
waitgroups, and whack one then the other being careful about resets.
But that with extra path length I should also look again at channels.
— P
> On Jan 16, 2021, at 5:23 PM, golang-nuts@googlegroups.com wrote:
>
> golang-nuts@googlegroups.com
> <https://gro
berg*
On Mon, Jun 15, 2020 at 10:06 AM wrote:
> golang-nuts@googlegroups.com
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/golang-nuts/topics>
> Google
> Groups
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=emai
deployment); and pay to push ‘free software’ throught he Labs.
Even better if the charity owned the Labs…
— P
> On May 14, 2018, at 10:35 AM, golang-nuts@googlegroups.com wrote:
>
> golang-nuts@googlegroups.com
> <https://groups.google.com/forum/?utm_source=digest&utm_medium=
On Mon, May 14, 2018 at 5:33 AM Pete Wilson
wrote:
> And then the quality of software will improve, because not everybody can
afford a few billion
Depends on how you define quality. Catch: bug-free is not a usable
definition of software quality. At least while humans write and test it.
--
-j
quality of software will improve, because not everybody can afford
a few billion
— P
> On May 13, 2018, at 6:27 PM, golang-nuts@googlegroups.com wrote:
>
> I would point out that a complete disclaimer of liability is fairly common
> even in commercial relationships. Just now I d
.From: golang-nuts@googlegroups.comSent: Saturday, September 17, 2016 7:35 PMTo: Abridged recipientsSubject: [go-nuts] Abridged summary of golang-nuts@googlegroups.com - 24 updates in 11 topics
17 matches
Mail list logo