Re: [go-nuts] Performance issue with os.File.Write

[komuW]

The bufio package also uses a max buffer of 
64KB: https://go.googlesource.com/go/+/go1.15.6/src/bufio/scan.go#80  
io.copybuffer on the other hand uses 
32KB; https://go.googlesource.com/go/+/go1.15.6/src/io/io.go#398

On Monday, 21 December 2020 at 14:46:21 UTC+3 arn...@gmail.com wrote:

> @Ben interesting, I did something similar and also ended up with a 64KB 
> buffer (seemed like the default of 4KB didn't work very well in my 
> context).  How did you decide of the buffer size?
>
> Also, there is something that I don't understand.  The default buffer size 
> works really well for a toy example (like the one I posted in my original 
> question), but the improvements are much less dramatic in my program, for 
> the same pattern of writing to stdout.  I can't work out a reason for this 
> yet.
>
>
> On Sunday, 20 December 2020 at 20:31:52 UTC ben...@gmail.com wrote:
>
>> And os.Stdout (and friends) are all regular *os.File objects (which as 
>> Jan said, don't buffer). It was non-intuitive to me that stdout didn't 
>> buffer by default, because it's such a bad thing for efficiently writing 
>> lots of output, but I guess it makes sense when you want terminal output to 
>> appear right away. So I realized it made sense, and gives you more control. 
>> And it's so easy to wrap it in a bufio.NewWriter() ... Flush() if you need 
>> buffering.
>>
>> I ran into this exact same issue when implementing GoAWK ... a 10-line 
>> fix gave me a 10x speedup. 
>> https://github.com/benhoyt/goawk/commit/60745c3503ba3d99297816f5c7b5364a08ec47ab
>>
>> -Ben
>>
>> On Monday, December 21, 2020 at 12:27:43 AM UTC+13 arn...@gmail.com 
>> wrote:
>>
>>> Ah, that is it, thank you!
>>>
>>> On Sunday, 20 December 2020 at 11:06:05 UTC Jan Mercl wrote:
>>>
 On Sun, Dec 20, 2020 at 11:53 AM Arnaud Delobelle  
 wrote: 

 > TLDR; a simple test program appears to show that Go's 
 (*os.File).Write is 10x slower than C's fputs (on MacOS). 

 Apples and oranges. fputs buffers, os.File does not. Rewrite the 
 benchmark using bufio. 

>>>

-- 
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/f98810f0-9227-4002-a272-d458e21dcf2bn%40googlegroups.com.

Re: [go-nuts] Language line in go.mod

[komuW]

is go.sum documented? I have seen a couple of questions on the same in the 
#modules channel on gophers slack

On Tuesday, 18 December 2018 19:14:12 UTC+3, Ian Lance Taylor wrote:
>
> On Tue, Dec 18, 2018 at 8:07 AM Sam Whited  > wrote: 
> > 
> > I've been asked multiple times recently to point people to documentation 
> for the language line in a go.mod file (eg. the `go 1.12' line that's added 
> by recent builds), but I haven't been able to find any on the wiki or in 
> `go help modules` or similar, just the occasional list discussion. 
> > 
> > Is this documented anywhere and I'm just missing it? 
>
> https://tip.golang.org/cmd/go/#hdr-The_go_mod_file 
>
> Ian 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Types are contract -, v2

[komuW]

>
> A contract can also be written in terms of a struct:
>
> contract linkedListNode {
>   X struct {
> next *X
>   }
> }
>
>
In this example taken from the linked document; what is X? 


On Tuesday, 20 November 2018 05:38:31 UTC+3, Burak Serdar wrote:
>
> Hi, 
>
> A while ago I sent an email to this list proposing an alternative way 
> to specify contracts using existing types, with a "like" keyword to 
> represent contracts on primitives. The idea stirred up some 
> discussion, I got some useful feedback, and eventually, it died down. 
> The idea stuck with me though, because it wasn't complete when I 
> proposed it, it had inconsistencies and unresolved problems. It turned 
> into this puzzle that I kept working on on the side, I started writing 
> a contracts/generics simulator, which I never finished, but it allowed 
> me to figure out a way to solve the problems the original idea had. So 
> the latest version of that proposal is now here: 
>
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: gomobile: what's the right way to make widgets?

[komuW]

Do you plan on making that UI library public(open source or not) at some 
point?

On Monday, 29 October 2018 16:51:02 UTC+3, Elias Naur wrote:
>
>
>
> On Monday, October 29, 2018 at 11:48:06 AM UTC+1, Laurent Moussault wrote:
>>
>>
>> IMHO there is vacuum right-now, an opportunity for a native framework 
>> that allows the same design freedom as web interfaces, but implemented 
>> directly on top of the OSes (and Vulkan, probably). I think something like 
>> flutter, but implemented in a more mainstream language (and supporting the 
>> desktop), would have a shot at success. A GUI framework that does not come 
>> with a complete set of ready-to-use widgets and containers (as in 
>> traditional native UIs), but allows to easily design custom ones, with 
>> beautiful layouts. This is, obviously, a huge amount of work...
>>
>>
> I'm glad you think that; I happen to be working on such an UI library :) 
> Its core is 100% Go, and it only uses Cgo for the necessary integration 
> with the low level OS primitives, input, window management and GPU access 
> (OpenGL ES for now). My library is also inspired by Flutter: it took a lot 
> of work to get into a usable state, but is now very portable and flexible. 
> My other inspiration is imgui: I hope that getting rid of the implicit  
> widget hierarchy will result in UI programs that are much easier to 
> maintain and keep bug free.
>
>  - elias
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: One-liner README instructions for GitHub cross compiled binary assets

[komuW]

TJ's https://github.com/apex/up uses 
https://github.com/goreleaser/godownloader  to generate `curl bash` style 
downloads. 

On Wednesday, 31 October 2018 00:28:17 UTC+3, Paul Jolly wrote:
>
> Hi - I'm hoping someone can point me towards a "best practice" example on 
> adding binary assets to GitHub releases of a program.
>
> Take https://github.com/myitcv/gobin/releases/tag/v0.0.2 as an example. I 
> have added cross compiled binaries as assets to the v0.0.2 release. 
>
> What I would now like to do is provide one-liner release instructions to 
> the README for various OS's.
>
> One issue with the current approach is that when any of those binaries are 
> downloaded the file is missing the execute permissions. That's easily 
> fixable with chmod Or alternatively, I could upload archives instead of 
> the binaries themselves... 
>
> Indeed I'm sure there are plenty of other approaches.
>
> So I'm looking for advice on best practice, best practice that leads to 
> the most sensible one-liner install instructions in READMEs.
>
> Any pointers much appreciated.
>
> Thanks,
>
>
> Paul
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Constraints for generics

[komuW]

On Sunday, 30 September 2018 13:33:23 UTC+3, Christian Surlykke wrote:
>
> Hi 
>
> I made a proposal for generics with constraints about ½ a year ago, which 
> I posted to the (very long) thread on issue 15292. I've now made a version 
> 2 , 
> in case anybody would like to read it. 
>
> This version adapts to the generics syntax now proposed by the Go team and 
> is somewhat simpler than the previous version.
>
> br. Chr.
>

I think you should add it 
to: https://github.com/golang/go/wiki/Go2GenericsFeedback  

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Is it needed to close a HTTP request body ?

[komuW]

On Monday, 10 September 2018 17:27:43 UTC+3, Pierre Durand wrote:
>
> When I learned Go a few years ago, I was told to always defer/close the 
> HTTP request body, otherwise it will cause a resource leak.
>
> But today I read this: https://golang.org/pkg/net/http/#Request.Body
> // The Server will close the request body. The ServeHTTP
> // Handler does not need to.
>
> This is for Server requests. 

> Am I misunderstanding something ?
>
> Thanks.
>

You need to close the request body. 
The documentation you linked to says; 

*For client requests   The HTTP Client's Transport is responsible for 
calling the Close method *

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] A thought on contracts

[komuW]

On Thursday, 6 September 2018 23:22:34 UTC+3, Ian Lance Taylor wrote:
>
> On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips  > wrote: 
> > Interesting idea, but has the Go team expressed interest in creating 
> such a tool? 
>
> Yes, I think it's become clear that we should have a tool that, given 
> a contract body, produces a minimal contract body that expresses the 
> same contract.  I believe that if we are able to write a type checker 
> for the design draft, it will be a minor straightforward extension to 
> that code to produce such a tool. 
>
> And, of course, given such a tool, it's a trivial extension to take an 
> arbitrary function body and produce a minimal contract body for that 
> function. 
>
> Ian 
>

I think these words would have been very comforting if they were(or at 
least alluded to) in the original draft document. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [ANN] meli - an alternative to docker-compose.

[komuW]

Hey guys,

I'm happy to announce meli <https://github.com/komuw/meli>, an alternative 
to docker-compose written in Go.

Let me know what you think.

Cheers.


-- 
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.
For more options, visit https://groups.google.com/d/optout.