Re: [go-nuts] Statically Typed Context
Hi Adam,
thanks for that article. I really like the idea and will try it on one of my
next projects.
Cheers,
Chris
On Thu, Apr 07, 2022 at 01:33:49PM -0700, 'Adam Berkan' via golang-nuts wrote:
> Khan Academy Engineering Blog Post:
> https://blog.khanacademy.org/statically-typed-context-in-go/
>
> Khan Academy has been porting our backend from Python to Go. One thing we
> hoped to get from it was fewer uses of implicit global resources and
> request data. We looked at explicitly passing everything as parameters, or
> hiding things in the context.
>
> In the end we decided to extend the context interface to provide access to
> these global & request elements. This gives us strongly typed interfaces,
> with less verbosity than writing every parameter out.
>
> func DoTheThing(
> ctx interface {
> context.Context
> RequestContext
> DatabaseContext
> HttpClientContext
> SecretsContext
> LoggerContext
> },
> thing string,
> ) {...}
>
> I've written a whole blog post about the idea, our motivations, and our
> experience with it. There's also some sample code available showing the
> different approaches we considered: https://github.com/Khan/typed-context/
>
> I realize this is not a wholly uncontroversial idea, but I'd appreciate any
> feedback.
>
> Adam
>
> --
> 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/2a1928ab-051b-492b-b4a1-154602d4067cn%40googlegroups.com.
--
Nothing to see here. Move along.
--
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/YlKVuiqAEOUaCsma%40chusuk.dune.
Re: [go-nuts] golang webserver incorrect rendering in browser
Hi,
your program never defines and registers a handler for the browser to get the
PNG file from the server. You essentially only serve test2.html. If you take a
look at
the developer console on the browser (network tab) and reload the page you'll
see that "blank grey.png" will be the same size as test2.html. That's because
your server always returns test2.html for any request... registering "/" is
essentially a catch-all if no other routes are defined.
Chris
On Thu, Feb 24, 2022 at 01:27:41PM -0800, buzze...@gmail.com wrote:
> This little program (attached: weird1.go) reads a small file of html code
> and delivers it through the golang webserver to a browser. The html code
> (test2.html) defines a box which it fills with an image ("blank grey.png").
>
> If you point the browser to the html file, the image is correctly
> displayed. If the go program reads the same file and sends it to the
> browser through the webserver on localhost:8080, the html is displayed
> correctly except that the image is omitted. If you do a copy of the
> 'view-page-source' for the incorrectly displayed htm and present it to the
> browser as a file (identical to the original html file) the image is shown
> correctly. What is wrong?
>
> --
> 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/8e262895-95de-4bdf-ab60-0f168ce7455cn%40googlegroups.com.
>
--
Nothing to see here. Move along.
--
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/YhgKAmC9FZnbdmWA%40chusuk.dune.
Re: [go-nuts] Idiomatic Go code
Hi, thank you for the helpful comments. That's what I love about the Go community. On Thu, Mar 04, 2021 at 03:14:04PM +0100, 'Axel Wagner' via golang-nuts wrote: > - Who's responsible for doing that work? If I return *os.File directly > from getFile(), there's an implicit assumption that the file needs to be > closed by the caller. But what if it's os.Stdout? > > > One possibility that we need to mention is that it would be possible to return > a new file, connected to stdout, for example by using syscall.Dup. You could > also wrap `os.Stdout` in a new type, with a no-op `Close` method. I actually hadn't thought of that. So instead of a Writer and a cleanup function I could just as easily return an io.WriteCloser. This would make it explicit, that the caller is supposed to call Close. A custom type (wrapping the actual writer) with a Close method can then just return nil in case there's nothing to be done. > - The alternative of putting all that in run() is kinda ugly because > run() potentially has to do a lot more. > > Nevertheless, personally, I think it's the right choice, ultimately. In small programs I'd actually do that. But in the real case that inspired this small example run() has to do a lot of setup work and I'd rather like to keep it clean by encapsulating the various steps in separate functions. > A potential problem I see? The error from os.File.Close() is never > checked, neither is the error from bufio.Writer.Flush(). In this small > example that wouldn't bother me because it means the program ends > anyway. But in other cases it might become more of a problem. > > > Yes, at the very least, your cleanup function should return an `error`. That > `error` might just be statically `nil`, but the failure when flushing/closing > (FTR, I don't think you need to flush, if you close the file anyway) should > definitely be handled some way. That's why I think your code as-is is actually > buggy. "The program will end anyway" isn't a good reason to silently leave a > corrupt file behind. I agree. By using a wrapping type and returning an io.WriteCloser that's actually possible. Side note about flushing: I'm flushing the wrapping bufio.Writer there. I'd be surprised closing the underlying os.File would be enough to ensure all buffer contents have been written. Thanks for the feedback. Chris -- 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/YED8ezxQZPxB6hls%40junction.dune.
[go-nuts] Idiomatic Go code
Hello Gophers, since I obviously don't have enough Twitter followers to get more than one answer to my Go question I'm posting it here ;-) Would you consider this idiomatic Go code? https://play.golang.org/p/ymPt_9tKQ9p I'm talking specifically about returning a cleanup function. My reasoning for it goes kinda like this: - doSomething doesn't care whether the output is a file or a buffer or os.Stdout, so it should just get an io.Writer. - The cleanup work for using os.Stdout (or a buffer in tests) is different than for *os.File. - Who's responsible for doing that work? If I return *os.File directly from getFile(), there's an implicit assumption that the file needs to be closed by the caller. But what if it's os.Stdout? - The alternative of putting all that in run() is kinda ugly because run() potentially has to do a lot more. A potential problem I see? The error from os.File.Close() is never checked, neither is the error from bufio.Writer.Flush(). In this small example that wouldn't bother me because it means the program ends anyway. But in other cases it might become more of a problem. What do you think? Kind regards, Chris -- 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/7baf0ec35696fc5501dfbe6ce8f161f8%40vonkietzell.de.
Re: [go-nuts] Reading bytes into uint32
I've read that post and I agree. I can only speculate that they designed the API that way either because of premature optimisation - saving the underlying binary from potentially having to swap the byte order - or out of laziness and an assumption that it's easy to read four bytes into an int in whatever programming language is used. Chris On Thu, Aug 24, 2017 at 06:56:38AM +1000, Rob Pike wrote: > I know the use of native byte order didn't come from you, but that's > lazy and wrong. > > https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html > > -rob > > > On Thu, Aug 24, 2017 at 12:12 AM, Wojciech S. Czarnecki > wrote: > > On Wed, 23 Aug 2017 10:51:25 +0200 > > Christian von Kietzell wrote: > > > >> [*1] The data comes from a web browser extension using the native > >> messaging API, which specifies that messages sent to external programs > >> are prefixed with the 32-bit length of the message in native byte order. > > > > I understand that 'native bo' in this context means 'remote client side > > endianess'. If so the safest way is to parse incoming request headers, > > guess byte order from that and tag data as appropriate. > > > > If it meant just local2local (local browser talking over lo/pipe) > > may simply compile endianess variants according to GOARCH. > > > > https://godoc.org/go/build#hdr-Build_Constraints > > > > -- > > Wojciech S. Czarnecki > > << ^oo^ >> OHIR-RIPE > > > > -- > > 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. > > -- > 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. -- Nothing to see here. Move along. -- 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] Re: Reading bytes into uint32
Thanks rob, that works, although I would have prefered a solution without unsafe. I found a thread from a few years back where someone proposed adding NativeEndian to encoding/binary which would always do the right thing. Too bad that never got anywhere. Chris On Thu, Aug 24, 2017 at 08:40:12AM +1000, Rob Pike wrote: > Apologies, typo. This is it: https://play.golang.org/p/9XWoCiUH2D > > On Thu, Aug 24, 2017 at 8:39 AM, Rob Pike wrote: > > I believe there is no safe (that is, unsafe-free) way to discover the > > native byte order. In a sense, this is because depending on the native > > byte order is intrinsically unsafe. It is by definition not portable. > > It is a terrible design decision. > > > > By the way, that program may work but it's not sound. It has a hidden > > assumption about how bytes are laid out in arrays and the > > correspondence with words. (Some machines, like the PDP-11, actually > > confused some matters like this). This is a better way to discover the > > byte order, at which point you can use portable methods from > > encoding/binary: https://play.golang.org/p/7svQ66wl7I > > > > -rob > > > > On Thu, Aug 24, 2017 at 8:24 AM, wrote: > >> It use unsafe, but works even in playground: > >> https://play.golang.org/p/S1rw157M9C > >> > >> > >> On Wednesday, August 23, 2017 at 3:49:39 PM UTC+3, Christian von Kietzell > >> wrote: > >>> > >>> Hi, > >>> > >>> I've stumbled across a problem I don't know how to solve. > >>> > >>> I'm trying to read (from stdin) four bytes into a uint32 value. Those > >>> bytes are provided in _native_ byte order by an external program.[*1] > >>> > >>> Since I've found nothing in the standard library to determine the > >>> machine's native byte order I can't decide whether to use > >>> binary.BigEndian.Uint32 or binary.LittleEndian.Uint32. > >>> > >>> Is there a way without involving package unsafe? Am I missing something > >>> obvious? > >>> > >>> [*1] The data comes from a web browser extension using the native > >>> messaging API, which specifies that messages sent to external programs > >>> are prefixed with the 32-bit length of the message in native byte order. > >>> > >>> > >>> Thanks, > >>> Chris > >>> > >>> -- > >>> Nothing to see here. Move along. > >> > >> -- > >> 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. -- Nothing to see here. Move along. -- 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] Reading bytes into uint32
Hi, I've stumbled across a problem I don't know how to solve. I'm trying to read (from stdin) four bytes into a uint32 value. Those bytes are provided in _native_ byte order by an external program.[*1] Since I've found nothing in the standard library to determine the machine's native byte order I can't decide whether to use binary.BigEndian.Uint32 or binary.LittleEndian.Uint32. Is there a way without involving package unsafe? Am I missing something obvious? [*1] The data comes from a web browser extension using the native messaging API, which specifies that messages sent to external programs are prefixed with the 32-bit length of the message in native byte order. Thanks, Chris -- Nothing to see here. Move along. -- 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] How to cast type alias and interface to int
On Tue, Dec 20, 2016 at 12:45:33AM -0800, so.qu...@gmail.com wrote: > How would I cast type alias MyInt and interface Foo, to an int? > > https://play.golang.org/p/Sb80WoKh4Y bar = int(foo.(MyInt)) Chris -- Nothing to see here. Move along. -- 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.
