Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon BC]

Why don't you try redirecting stdout to /dev/null and see how your program
behaves.

Also, which OS are you using?

On Sun, May 8, 2022 at 11:36 PM Const V  wrote:

> reading 1 line '\n' delimited 100MB file
> r1 := bufio.NewReader(file)
> s := ReadWithReadLine(r1)
> InputProcessing(strings.NewReader(s), os.Stdout)
>
> in InputProcessing"
> w.Write([]byte(s)) -> waiting forever
> w.Write([]byte(s)[:100]) -> working
> ---
> func InputProcessing(r io.Reader, w io.Writer) {
> find := "error"
> /
> s := ReadWithReadLine(r)
> if strings.Contains(s, find) {
> w.Write([]byte(s)[:100])
> w.Write([]byte("\n"))
> } else {
> w.Write([]byte(" \n"))
> }
> }
> ---
> On Sunday, May 8, 2022 at 3:21:52 PM UTC-7 Amnon wrote:
>
>> On Sun, May 8, 2022 at 10:41 PM Const V  wrote:
>>
>>> write to stdout is not working for MB long strings
>>>


>> That is very surprising indeed.
>> How do you reach the conclusion?
>> How can we replicate that failure?
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/IUMIxWx9aLk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b1259910-58ca-4a57-bb05-1dde2fc73443n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALg-z3X2P%3DEKpg%2BXAK1qUYtAKGYNL4qcQ-NyN-J5Wo7Kc8DLQA%40mail.gmail.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon BC]

On Sun, May 8, 2022 at 10:41 PM Const V  wrote:

> write to stdout is not working for MB long strings
>
>>
>>
That is very surprising indeed.
How do you reach the conclusion?
How can we replicate that failure?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALg-z3Uun-qPm2337DOsxyWRosFJRs-XXMu672NjVHhS1e5%3DVw%40mail.gmail.com.

Re: [go-nuts] Re: New edition of the Go Programming Language comming soon ?

[Amnon BC]

Great post, Rob!
CS people generally write books for people like themselves and find it hard
to
put themselves in the position of someone without a CS degree, learning
their first programming language.
A lot of people are aware of the lack of good beginner material, but few
people have the experience
in teaching beginners needed to write it. So great that you are taking
steps to rectify this.
Best of luck with the book! I will certainly be ordering a copy when it
comes out.




On Tue, Mar 15, 2022 at 4:59 AM Rob Muhlestein  wrote:

> The essential issue is that there are a number of resources for people
> "with prior programming experience" and literally none for people learning
> Go as a first language. I find this to be very unfortunate because so much
> of Go promotes solid programming practices that could significantly impact
> beginners for the rest of their coding lives (goroutines instead of
> promises, for example). Instead, the community seems content with simply
> suggesting beginners "learn another language first" and I've accepted that.
> I just find it a real loss of an excellent opportunity.
>
> The rest of this is just me blabbing on about helping beginners. 
>
> And I'm sorry, that book is anything but clear. In my experience, the
> people who say such things also say that K C is "clear." It's a matter of
> opinion and audience, and if you are a Ph.D in computer science with C
> coding under your belt, hell yeah, it's *very* clear. I just work with
> beginners with no CS experience a lot and they balk at the irrelevant
> examples, unnecessary bombastic voice, and excessive assumptions. I'm
> sincerely glad some do find it valuable.
>
> By the way, why doesn't our community promote more top-of-the-line, free
> resources over paid books that become immediately out of date? With all the
> money being dumped into "universities" and "free training" of late from
> different corporations facing the doubt of good IT talent I want to believe
> a dedicated team focused specifically on helping beginners adopt Go is a
> possibility --- especially given the critical dependency on Go in all of
> cloud native computing. Being able to read Go source (minimally) should be
> mandatory learning for any infrastructure engineer these days. I've solved
> so many problems simply from reading the K8S or Helm source rather than the
> docs.
>
> I get the impression so many are so busy doing amazing things *with* Go
> that there is very little energy left to do things to help others start,
> and by others I don't mean those paying for corporate training. I mean
> those capable of learning but with limited means; I mean the AP CS programs
> that are still mandating mastering of single OOP inheritance that
> completely neglect concurrent programming practices; I mean self-taught
> upskillers learning to write their own Kubernetes operators. Go could
> easily displace Java as the best AP CS language if more attention were
> given to these considerations.
>
> The Tour of Go is only about 60% finished according to the project
> milestones in the source of the project. And who thought throwing bitwise
> operators in the first chapter (or so) was a good idea?
>
> It just seems like people are content letting beginners fend for
> themselves, which is fine for most, but not for the vast majority of people
> for whom Go is supposedly created. This is the reason I regularly receive
> feedback about Go from the many I've helped who say, "Go just isn't
> beginner friendly" and I'm tired of them saying that "Rust is more
> welcoming" (which is just so untrue).
>
> I know I'm droning on, but someone has to bring this up. Go *is* for
> beginners. We just need help convince people, and frankly that starts with
> being able to make a simple, solid book/resource recommendation for
> beginners. There's just nothing out there. I've read 'em all. There are
> literally no books that cover even 1.17 for beginners. (Modules were one of
> the worst things to happen to beginners and we are finally getting on with
> a simpler future.) With Go 1.18 we have a real opportunity to correct this.
>
> For the record, I'm slowly putting together enough material to
> crowd-source a beginner Go 1.18 book and have probably a few dozen people
> interested in helping, but like so many others, I have other stuff I'm
> first required to focus on. Look forward to anything I can do to help.
>
> Thank you.
>
> ---
> Rob Muhlestein
> r...@rwx.gg
> https://twitch.tv/rwxrob
>
> --- Original Message ---
>
> On Monday, March 14th, 2022 at 1:06 PM, Steve Mynott <
> steve.myn...@gmail.com> wrote:
>
> > My experience with this book has been different. I thought it was
> >
> > superb -- a masterpiece of clarity.
> >
> > I don't think it's intended for absolute beginners to programming but
> >
> > it's great for people with prior programming experience.
> >
> > It seems to me unlikely there isn't a suitable absolute beginners book
> >
> > available from 

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Amnon BC]

> From the tests that I have performed, I can see that a Ticker pretty
accurately fires at every 1ms interval.

It will depend on the load on your machine. As the load on the machine
increases, so with the jitter in the tick time.

On Thu, Feb 3, 2022 at 1:19 AM Robert Engels  wrote:

> I am unclear why you need to use an N of M. I would make sure the hardest
> case is handled and you can use a variety of techniques to partition the
> work.
>
> On Feb 2, 2022, at 6:58 PM, envee  wrote:
>
> And I forgot to mention that approach I mentioned talks about waking up N
> goroutines at a time. The way I plan to do is to select a range of N
> goroutines from my list of goroutines and only allow those goroutines to
> send HTTP requests.
> I could use this approach to select the N goroutines or even use a
> Semaphore. I presume using a Semaphore, will allow a good amount of random
> N goroutines out of M goroutines to execute.
>
> On Thursday, 3 February 2022 at 10:26:28 UTC+11 envee wrote:
>
>> Thanks Robert, Uli and Ian for your suggestions.
>>
>> I think what I will probably do is use a Ticker with a duration of 1ms.
>> At every 1ms, I will "wake-up" N number of goroutines to trigger HTTP
>> requests.
>> That number N = (request rate per second / 1000)  = requests per ms.
>> So, if I need to ensure a rate of 1 requests per second, I believe it
>> should be possible for the Ticker to return after every 1ms and then fire
>> about 10 requests at every such interval.
>> From the tests that I have performed, I can see that a Ticker pretty
>> accurately fires at every 1ms interval.
>> I think it's only when the Ticker duration falls below 1ms, that I see
>> issues.
>>
>> If my desired rate is less than 1000 per second, then I will create a
>> Ticker to return every 1000/request rate milliseconds, which will be a
>> number greater than 1ms.
>>
>> This approach is closely based on Robert's suggestion about using a
>> higher duration for Ticker time and waking up a small subset of goroutines.
>>
>> I think it should be ok for a client to be accurate at the level of
>> granularity of 1ms.
>>
>>
>> On Thursday, 3 February 2022 at 01:14:20 UTC+11 ren...@ix.netcom.com
>> wrote:
>>
>>> Because 2 is a magnitude larger than 2000.
>>>
>>> > On Feb 1, 2022, at 1:44 PM, Uli Kunitz  wrote:
>>> >
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/209b18aa-1317-4d72-80a1-222f10a26013n%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/3GUnjdoWjqU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/F912EE7E-4F80-4C16-ABC1-943572FD576C%40ix.netcom.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALg-z3VpSw1dJwbn4YDd98qJsfj_NtSDJUrsA3p2xk%2BzQMChuQ%40mail.gmail.com.

Re: [go-nuts] JSON stream parsing help

[Amnon BC]

Awesome, thanks!

On Sat, Jul 25, 2020 at 3:50 PM burak serdar  wrote:

> On Sat, Jul 25, 2020 at 6:09 AM Amnon  wrote:
> >
> > Hi,
> >
> > I need to consume a stream of json objects.
> > But unfortunately the json objects are separated by commas.
> >
> > Is there any simple way I can convince the json.Decorder to skip the
> comma after each successful call to decode?
>
> You have to read the comma yourself from the stream after each
> element. You can read the next byte manually and discard it if it is a
> comma. If there can be other characters, you can wrap the reader with
> a bufio.Reader and use Read/Unread the comma/spaces between each JSON
> object.
>
> There is this package I wrote a while ago that does this, you can use
> that or get some ideas from it: https://github.com/bserdar/jsonstream
>
> >
> > My code looks like
> >
> > for {
> > var a st
> > err := dec.Decode()
> > if err == io.EOF {
> > break
> > }
> > if err != nil {
> > log.Fatalln(err)
> > }
> > log.Println(a)
> > }
> >
> >
> > https://play.golang.org/p/7lBhs0pXUx8
> >
> > Unfortunately the json comes from an external service, so I can't stop
> it inserting unecessesary comments.
> >
> > Thanks for any ideas,
> > Amnon
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e2a50435-aacd-4c13-8c79-2ce1f8dd3f8fo%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALg-z3U85vwW7tR0As9bXEMNo1qFPSvB-WbL6WeSerQvueL9UA%40mail.gmail.com.

Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Amnon BC]

Good point Jan, and I totally agree.

I noticed that the proposal states that it can only be implemented by the
core team.

I don't really understand the statement, as go fmt is written in Go and all
the sources are available online.
So it might be worth expanding this statement to explain why this proposal
can not be implemented by
people outside the core team.

On Thu, Feb 20, 2020 at 8:11 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Feb 19, 2020 at 7:26 PM Wojciech S. Czarnecki 
> wrote:
>
> > https://github.com/golang/go/issues/37299
>
> "I propose to add an opt-in go fmt solution meant to minimize
> whitespace changes to the block where a code author hinted at desired
> comments position."
>
> I believe the absence of any gofmt knobs (opt-ins) is a feature that's
> not going away. You can always use your private fork, if you want. But
> most people will not accept code that is not formatted by the
> "standard" gofmt. Because again, the uniformity is the whole point of
> gofmt's existence.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/kp5-wX2ONdc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-U%3DMomr0MMZcSpt5OdajMXF97G1XqmYhm8LLKVAiLXccA%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALg-z3U9Aya%3D2E4oUQNGU9HkdskkWSijsto1B%2B5NTsiyzu2%3DpA%40mail.gmail.com.