Re: [go-nuts] syscall.Read() with timeout: syscall.Select() vs golang's select statement

On 7/24/16 12:49 PM, fabian.stae...@gmail.com wrote: > The idea is obvious: When the timeout is reached, fd is closed, which > interrupts the blocking syscall.Read(), which terminates the goroutine. I'm wondering how to do this safely for filehandles I don't want to close, for instance stdin or

Re: [go-nuts] syscall.Read() with timeout: syscall.Select() vs golang's select statement

On 7/26/16 4:05 PM, Matt Harden wrote: > Select and epool actually aren't useful for fd's that are opened on > regular files. As I understand it, they always indicate those files > are ready for I/O. That may well be the case for regular files. I'm talking in particular about filehandles which

Re: [go-nuts] What dependency management tool do you use?

On 7/12/16 1:15 PM, Johann Höchtl wrote: > I use godep. There has been lots of rumour lately to use gb. > > What do others use? > > If there is a blog post available somewhere comparing the pros and > cons, please provide one. > I know https://github.com/golang/go/wiki/PackageManagementTools > > I

Re: [go-nuts] on GOPATH

Hi Maurizio, I tend to use go vendoring for this purpose. I set GOPATH to $HOME, and this is my "global" environment. Each project is checked out to its module path. Instead of using 'go get' to get dependencies, I use git submodules via vendetta. This checks out all of the dependencies for

Re: [go-nuts] Built-in log Package

On 8/15/17 7:14 AM, Chris Hines wrote: I would be curious what you think of github.com/go-kit/kit/log (and related "sub"-packages). See my talk about it's design here: Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw Slides:

Re: [go-nuts] Built-in log Package

The main problem with the Printf-style interface is that it's not worth building real applications with. For anything with non-trivial logging needs, you need: * tagging of log lines with identifiers such as PID, host, request ID, etc * structured for easier downstream analysis by tools like the

Re: [go-nuts] Re: [Blog] Context should go away for Go 2

see similar ideas hinted at in > this thread. > > I hope this can help to steer the discussion into the more helpful > underlying questions, instead of getting hung up on details of the current > implementation. > > On Sat, Aug 12, 2017 at 12:59 AM, Sam Vilain <s...@vi

[go-nuts] Go 2.0 proposal: context scoped variables

Many have written about this; there's an index on Go wiki under ExperienceReports#context including my own writing for the 2016 advent calendar. I would like to propose a simpler way to solve the "optional variable access" part of

Re: [go-nuts] git submodule vs normal go vendoring

In theory, the git submodule builds are *more* reproducible, because all your build servers etc have clones of those sub-repos cached under their .git, even though they are not under your control. If the upstream goes away, you can just re-publish the repo (which you'll have cloned locally) and

Re: [go-nuts] Simple web crawler question. How to avoid crawling visited links?

Why not be even more concurrent?Pass "to visit" links to a channel.Reader of channel holds the map, de-dupes and passes to worker channel.Multiple workers dequeue the channel and feed back into the "to visit" channel.SamOn Sep 24, 2017 10:13 AM, Michael Jones wrote:you

Re: [go-nuts] Re: Ternary ... again

have ternary > operators, but after long and hard discussions, they caved", what I'm > hearing is "even *Python* didn't really need them". ;) > > (Disclaimer: This isn't meant as a dig at Python. I think Python is a > great language. But its design goals are very differe

Re: [go-nuts] Re: Ternary ... again

I haven't seen all the discussion referenced, but I remember digging deep into the python language archives where Guido and others eventually relented and added ternaries (with the syntax "a if val else b"). I can't remember the argument which swung the consensus but the arguments against seem

Re: [go-nuts] Local cache of dependencies

Check out vendetta - it uses git submodules, so you keep a cache of the 3rd party repo in git but not the actual content. You get small repos and reproducible builds.SamOn Aug 22, 2018 3:25 PM, Conor Hackett wrote:Hey Guys,So, adding your "vendor" directory to SCM is a contentious topic at best.I

Re: [go-nuts] A thought on contracts

Is that the go team's job, though?  It's about go and automatically inferring duck types, so surely we should really be asking DuckDuckGo.Sam -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

Re: [go-nuts] How to test the 'noasm' code?

is defined? (b) is it possible to write assembly functions that avoid the wrapper code, assuming that one follows the platform's calling convention? Sam On Tuesday, 25 April 2023 at 13:48:57 UTC-4 Ian Lance Taylor wrote: > On Tue, Apr 25, 2023 at 10:03 AM Sam Vilain wrote: > > > &

[go-nuts] How to test the 'noasm' code?

I have a module that has a couple of assembly functions (for CLZ aka BSR/LZCNT, which despite widespread availability[1] don't get any language support). So I've got the assembly versions in per–arch files, and a "noasm" version that builds with "noasm" (amongst other typical conditions. My

Re: [go-nuts] How to test the 'noasm' code?

w! Cheers, Sam On Tuesday, 25 April 2023 at 11:59:28 UTC-4 Ian Lance Taylor wrote: > On Tue, Apr 25, 2023 at 8:38 AM Sam Vilain wrote: > > > > I have a module that has a couple of assembly functions (for CLZ aka > BSR/LZCNT, which despite widespread availability[1] don't get

Re: [go-nuts] Parsing time with timezones seem to fail

> On Feb 13, 2023, at 9:55 AM, Sven Rebhan wrote: > > I do not yet see where timezone abbreviations are ambiguous... Do you mean > there are multiple timezones with the same abbrev? This is certainly not the > case for MST... > What is the point in taking the timezone into account only if

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

On 2/17/24 1:32 AM, Axel Wagner wrote: On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain wrote: I would argue that the matter can be simply decided by choosing the /calling/ stack, not the destination stack. I agree that this is *one choice*. But the point is, that *sometimes* you'd want

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

always file a proposal to get a more official response. On Tue, Feb 20, 2024 at 8:18 PM Sam Vilain wrote: On 2/17/24 1:32 AM, Axel Wagner wrote: On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain wrote: I would argue that the matter can be simply decided by choosing the

[go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Hi all, Many moons ago I wrote a proposal to make /execution context/ a fundamental concept in Go, effectively moving `context.Context` to being part of the language, not just an extension. The main reason to do this is

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Hey Axel, thanks for the response. /The general reason this has not been accepted for Go, is that passing a Context explicitly removes ambiguities what is meant, in the presence of closures and goroutines./ /If you pass a closure to a different execution context (e.g. via a

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

y, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote: Alright, well thanks for your input. I do think these questions can be answered; exploring the use cases in a proposal format should hopefully show that the impact of closures would not normally be an issue. Possibly th

Re: [go-nuts] Adding context.Context as first parameter in every function

Hi Yash, unfortunately that's the only approach at the moment. Your request is very apropos of my thread, "Could we trade all the `ctx context.Context` arguments for one pointer in `g`?". This is the exact use case I have in mind.  I believe it should be possible, and even a fairly naïve

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Thanks for your examples!  I'll cover them in reverse order, to build up the syntax. On 2/29/24 6:18 AM, 'TheDiveO' via golang-nuts wrote: The second example is unit test code, so TEST: