Re: [go-nuts] Go “service container” thoughts

[Zellyn]

Peter, thanks for that thoughtful and clear answer. It articulates very 
clearly the tussle I've been feeling, and is immensely helpful!

Happy New Year!

Zellyn

On Tuesday, December 25, 2018 at 1:37:14 PM UTC-5, Peter Bourgon wrote:
>
> I've repeatedly built "service container" or "corp kits" like the one 
> you're describing, as well as helped a number of orgs improve their 
> own versions of the thing in a consultant capacity. I think everyone 
> has the same reaction that you do: why are we duplicating all this 
> effort? But I can say with some breadth of experience that the 
> commonalities are fewer than they may appear. Once you take your e.g. 
> log shipper library, which is likely quite purpose-built not only for 
> your chosen MQ but the peculiarities of its runtime environment(s), 
> and provided switches and knobs to account for reasonable alternatives 
> to make it worth open-sourcing, you've rounded off a sufficient number 
> of corners to make it significantly less useful in your original 
> environment. The utility of these kits or containers is generally 
> proportional to how zero-conf they are: just use these pre-ordained 
> things, and you'll be good to go. Provide enough knobs to make them 
> generally useful, and the magic is replaced by config; new users, 
> faced with a sprawling YAML config and compiling in support for things 
> they'll never need, wonder why they can't eliminate all this cruft by 
> making a purpose-built jig for their specific conditions, and you're 
> back to square one. Advice from someone who's been down the path 
> enough times: accept as invariant that this code will never see the 
> light of open-source day, and hyper-specialize to your programming 
> environment, optimizing for ease-of-use. It's a better use of time and 
> energy. 
>
>
> On Wed, Dec 12, 2018 at 4:39 PM Zellyn > 
> wrote: 
> > 
> > Hi folks, 
> > 
> > At Square, we have a collection of shared frameworks and library code, 
> loosely referred to as the “service container” in each language. For 
> example, our framework code in Go includes: 
> > 
> > a lightweight "module" system for dependency injection 
> > config: a way of layering yaml files named for environments. For 
> instance, common.yaml gets loaded first, and production.yaml shadows over 
> it, and production-east-coast.yaml gets applied last. 
> > logging: code for sending log lines over kafka to our logging aggregator 
> > networking: our stubby-alike protobuf RPC mechanism, naming and 
> discovery, etc. Gradually migrating to "just use grpc and envoy" 
> > datasource config: a convention for configuring database sources via the 
> yaml configs 
> > 
> > People probably also think of our service container as including 
> slightly less core things too: 
> > 
> > sharded jobqueues 
> > feature flags (backed by zookeeper) 
> > cron jobs (again configurable via yaml) 
> > 
> > This stuff has gone a while with less-than-generous attention and 
> upkeep, and the extent of Square-specific code makes it more difficult for 
> new developers to come up to speed. 
> > 
> > What I'm trying to figure out is: what are folks at other companies 
> using to create a shared set of conventions and out-of-the-box setup for 
> their Go applications? We can knock some pieces out one by one (eg. replace 
> our Module system with Wire), but it would be nice to find an existing 
> lightweight “service container” that other companies are using. 
> > 
> > I suppose my main question is this: is the kind of flexibility required 
> for a shared, open-source “service container” antithetical to the kind of 
> simple, opinionated, internal-convention-obeying “service container” you'd 
> want for your company? To put it another way, it has never felt like using 
> gokit would be appropriate, because it obeys none of our conventions. 
> > 
> > Thoughts, comments, experience to relate? 
> > 
> > Yours, 
> > 
> > Zellyn 
> > 
> > -- 
> > 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...@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.

[go-nuts] Go “service container” thoughts

[Zellyn]

Hi folks,

At Square, we have a collection of shared frameworks and library code, 
loosely referred to as the “service container” in each language. For 
example, our framework code in Go includes:

   - a lightweight "module" system for dependency injection
   - config: a way of layering yaml files named for environments. For 
   instance, common.yaml gets loaded first, and production.yaml shadows over 
   it, and production-east-coast.yaml gets applied last.
   - logging: code for sending log lines over kafka to our logging 
   aggregator
   - networking: our stubby-alike protobuf RPC mechanism, naming and 
   discovery, etc. Gradually migrating to "just use grpc and envoy"
   - datasource config: a convention for configuring database sources via 
   the yaml configs

People probably also think of our service container as including slightly 
less core things too:

   - sharded jobqueues
   - feature flags (backed by zookeeper)
   - cron jobs (again configurable via yaml)

This stuff has gone a while with less-than-generous attention and upkeep, 
and the extent of Square-specific code makes it more difficult for new 
developers to come up to speed.

What I'm trying to figure out is: what are folks at other companies using 
to create a shared set of conventions and out-of-the-box setup for their Go 
applications? We can knock some pieces out one by one (eg. replace our 
Module system with Wire), but it would be nice to find an existing 
lightweight “service container” that other companies are using.

I suppose my main question is this: is the kind of flexibility required for 
a shared, open-source “service container” antithetical to the kind of 
simple, opinionated, internal-convention-obeying “service container” you'd 
want for your company? To put it another way, it has never felt like using 
gokit would be appropriate, because it obeys none of our conventions.

Thoughts, comments, experience to relate?

Yours,

Zellyn

-- 
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: Local repository for go modules

[Zellyn]

I think Project Athens is what you want? https://github.com/gomods/athens

On Thursday, August 16, 2018 at 12:12:11 PM UTC-4, Ignazio Di Napoli wrote:
>
> I'd like to experiment with modules, in a local directory. I know I can do 
> it setting GOPROXY to a file:/// url. 
> But what about looking for my own modules in a local folder, and the 
> others normally (optionally through the proxy)? Is there a simple proxy I 
> can configure in this way? Thank you.
>

-- 
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: [ANNOUNCE] for gopher audiophiles.

[Zellyn]

That's great to hear. Again, good luck!

On Wednesday, August 8, 2018 at 3:50:56 PM UTC-4, Scott Cotton wrote:
>
> Oops, I forgot to CC golang-nuts..
>
>
> -- Forwarded message --
> From: Scott Cotton >
> Date: 8 August 2018 at 21:48
> Subject: Re: [go-nuts] Re: [ANNOUNCE] for gopher audiophiles.
> To: Zellyn >
>
>
> Zellyn,
>
> We are collaborating with the go-audio github organisation.  They have 
> lots to offer more than the buffer datatypes, and Matt Aimonetti of 
> go-audio has been very helpful and supportive.   I'd also like to give him 
> credit in the zikichombo code as his reviews provoked profound changes that 
> I wouldn't have thought of otherwise.
>
> Zikichombo does not currently use go-audio buffers.  My feeling is that 
> they may be most useful in the context of codec implementations.
>
> It's unfortunate that we were unable to do everything together in one 
> place, hence 2 organisations.  But I am looking forward to continuing 
> working with go-audio synergistically or more. 
>
> Scott
>
>
>
>
>
> On 8 August 2018 at 20:49, Zellyn > wrote:
>
>> One other question. I know you're aware of it because you mentioned it in 
>> the kickoff blog post, but do you intend to use the underlying types from 
>> https://github.go-audio/audio?
>>
>> Just curious,
>>
>> Zellyn
>>
>> On Wednesday, August 8, 2018 at 2:37:12 PM UTC-4, Sebastien Binet wrote:
>>>
>>> Scott,
>>>
>>> One thing that wasn't completely clear to me in the blog post was 
>>> whether zikichombo was considering investigating a pure Go alsa compatible 
>>> package.
>>> If I am not mistaken, right now, on Linux and on Darwin, the package 
>>> actually performing audio stuff is using cgo.
>>>
>>> Also, while I understand the fft code currently part of zikichombo is 
>>> specifically tailored for the audio use cases.
>>> I was wondering whether you had considered using gonum/fft and dropped 
>>> it for some reason (and I'd be interested in knowing what that was) out 
>>> whether you just didn't know about its existence (it's pretty new, but 
>>> based on the netlib implementation, IIRC)
>>>
>>> Cheers,
>>> -s
>>>
>>> sent from my droid
>>>
>>> On Wed, Aug 8, 2018, 20:25 Zellyn  wrote:
>>>
>>>> Scott,
>>>>
>>>> Thank you for taking on this thorny and important area. I hope you 
>>>> manage to include the various interested parties, and reach a consensus 
>>>> that is both efficient and Go-like.
>>>>
>>>> Good luck!  I look forward to reading updates on the project blog.
>>>>
>>>> Zellyn
>>>>
>>>>
>>>> On Tuesday, August 7, 2018 at 11:33:48 PM UTC-4, Scott Cotton wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I am pleased to announce a new project dedicated to rendering 
>>>>> "awesome" sound processing and i/o in Go, ZikiChombo 
>>>>> <http://zikichombo.org>,  The project is in alpha, and this 
>>>>> announcement is mostly geared toward people potentially interested 
>>>>> in helping.
>>>>>
>>>>> (you may want to check out the launch blog post 
>>>>> <http://zikichombo.org/blog/launch> for a more personal introduction).
>>>>>
>>>>> Best,
>>>>> Scott
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>> 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...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> -- 
>> 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/F07t91S1hKM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Scott Cotton
> President, IRI France SAS
> http://www.iri-labs.com
>
>
>
>
>
> -- 
> Scott Cotton
> President, IRI France SAS
> http://www.iri-labs.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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANNOUNCE] for gopher audiophiles.

[Zellyn]

One other question. I know you're aware of it because you mentioned it in 
the kickoff blog post, but do you intend to use the underlying types 
from https://github.go-audio/audio?

Just curious,

Zellyn

On Wednesday, August 8, 2018 at 2:37:12 PM UTC-4, Sebastien Binet wrote:
>
> Scott,
>
> One thing that wasn't completely clear to me in the blog post was whether 
> zikichombo was considering investigating a pure Go alsa compatible package.
> If I am not mistaken, right now, on Linux and on Darwin, the package 
> actually performing audio stuff is using cgo.
>
> Also, while I understand the fft code currently part of zikichombo is 
> specifically tailored for the audio use cases.
> I was wondering whether you had considered using gonum/fft and dropped it 
> for some reason (and I'd be interested in knowing what that was) out 
> whether you just didn't know about its existence (it's pretty new, but 
> based on the netlib implementation, IIRC)
>
> Cheers,
> -s
>
> sent from my droid
>
> On Wed, Aug 8, 2018, 20:25 Zellyn > wrote:
>
>> Scott,
>>
>> Thank you for taking on this thorny and important area. I hope you manage 
>> to include the various interested parties, and reach a consensus that is 
>> both efficient and Go-like.
>>
>> Good luck!  I look forward to reading updates on the project blog.
>>
>> Zellyn
>>
>>
>> On Tuesday, August 7, 2018 at 11:33:48 PM UTC-4, Scott Cotton wrote:
>>>
>>> Hello all,
>>>
>>> I am pleased to announce a new project dedicated to rendering "awesome" 
>>> sound processing and i/o in Go, ZikiChombo <http://zikichombo.org>, 
>>>  The project is in alpha, and this announcement is mostly geared toward 
>>> people potentially interested 
>>> in helping.
>>>
>>> (you may want to check out the launch blog post 
>>> <http://zikichombo.org/blog/launch> for a more personal introduction).
>>>
>>> Best,
>>> Scott
>>>
>>>
>>>
>>> -- 
>> 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...@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.

[go-nuts] Re: [ANNOUNCE] for gopher audiophiles.

[Zellyn]

Scott,

Thank you for taking on this thorny and important area. I hope you manage 
to include the various interested parties, and reach a consensus that is 
both efficient and Go-like.

Good luck!  I look forward to reading updates on the project blog.

Zellyn


On Tuesday, August 7, 2018 at 11:33:48 PM UTC-4, Scott Cotton wrote:
>
> Hello all,
>
> I am pleased to announce a new project dedicated to rendering "awesome" 
> sound processing and i/o in Go, ZikiChombo <http://zikichombo.org>,  The 
> project is in alpha, and this announcement is mostly geared toward people 
> potentially interested 
> in helping.
>
> (you may want to check out the launch blog post 
> <http://zikichombo.org/blog/launch> for a more personal introduction).
>
> Best,
> Scott
>
>
>
>

-- 
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] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[Zellyn]

On Tuesday, April 24, 2018 at 9:38:36 AM UTC-4, matthe...@gmail.com wrote:
>
> For Go you may want to consider the AGPL which also requires any network 
>> app to provide its source code. These GNU licenses are from the Free 
>> Software Foundation which has a traditionally radical philosophy toward 
>> computers: https://www.gnu.org/licenses/why-affero-gpl.en.html So far I 
>> personally like the AGPL approach.
>
>
Nobody at Google (or many other companies) can touch anything AGPL.

Zellyn 

-- 
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: Mac OS Bluetooth Gamepad

[Zellyn]

Thanks for the pointers. I spent some time last night finding the gamepad 
code in the Chromium sources, although I haven't had a chance to really 
read it properly.

It makes sense that you'd read against some kind of OS-specific 
abstraction, but I was curious what it was because I don't see any gamepad 
config or listing in the Mac OS Settings panels.

Sounds like I'm going to be reading some source code… :-)

Thanks again,

Zellyn


On Tuesday, March 27, 2018 at 8:31:23 AM UTC-4, Egon wrote:
>
> Ah, just noticed the Mac part...
>
> https://github.com/glfw/glfw/blob/master/src/cocoa_joystick.m
>
> Also Chromium source for the Gamepad implementation:
>
>
> https://cs.chromium.org/chromium/src/device/gamepad/?q=gamepad=package:chromium
>
> Unfortunately I didn't notice a Go gamepad implementation for Mac... 
> however there might be one.
>
> On Tuesday, 27 March 2018 15:02:10 UTC+3, Egon wrote:
>>
>> Usually controllers don't speak directly to your application nor browser.
>>
>> Usually there is a driver that the controller has, this talks with the 
>> appropriate protocol to the device. The driver itself provides some common 
>> HID api that the OS has specified.
>>
>> The reading and writing the input is effectively about communicating with 
>> the OS.
>>
>> https://github.com/glfw/glfw/blob/master/src/linux_joystick.c
>> https://github.com/glfw/glfw/blob/master/src/win32_joystick.c
>>
>> You can do those calls using syscall package, e.g. one for Windows
>>
>>
>> https://github.com/egonelbre/exp/blob/master/game/gamepad/xinput_windows.go
>>
>> and a quick search on godoc.org revealed this:
>> https://godoc.org/?q=joystick
>> https://github.com/simulatedsimian/joystick
>>
>> Of course since it's OS specific, you need to implement for all of them. 
>> Where each might their own quirks.
>>
>> SDL and GLFW are both thoroughly tested. I'm not sure about the existing 
>> package, but it shouldn't be difficult to switch when you do encounter 
>> problems with the pure Go libs.
>>
>> + Egon
>>
>> On Tuesday, 27 March 2018 05:19:24 UTC+3, Zellyn wrote:
>>>
>>> Inspired by a Wired article 
>>> <https://www.wired.com/story/xbox-one-x-and-xbox-one-deals/> mentioning 
>>> XBox One gamepads for $34, I finally got a game controller.
>>>
>>> Naturally, now I'm wondering how to read it from Go :-)
>>>
>>> It connects to Mac OS over Bluetooth. Various games seem to vary in 
>>> whether they recognize or even notice it, but it works flawlessly in Chrome 
>>> using http://html5gamepad.com/ 
>>> <http://www.google.com/url?q=http%3A%2F%2Fhtml5gamepad.com%2F=D=1=AFQjCNHgk2HZ9Nwso2KFkEVEFST54APnmQ>
>>>
>>> So, if there's anyone here who even begins to know how gamepads work… am 
>>> I about to wade into an ocean of pain? I'd *like* to avoid linking to 
>>> sdl as gobot seems to do for joysticks: it would be lovely to have 
>>> something in pure Go. Is that unlikely?
>>>
>>> How are games (and Chrome) even finding the controller? Do they have to 
>>> interrogate the Bluetooth stack, and then speak both Bluetooth and the XBox 
>>> controller protocol?
>>>
>>> Any help appreciated.
>>>
>>> Zellyn
>>>
>>>

-- 
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] Mac OS Bluetooth Gamepad

[Zellyn]

Inspired by a Wired article 
<https://www.wired.com/story/xbox-one-x-and-xbox-one-deals/> mentioning 
XBox One gamepads for $34, I finally got a game controller.

Naturally, now I'm wondering how to read it from Go :-)

It connects to Mac OS over Bluetooth. Various games seem to vary in whether 
they recognize or even notice it, but it works flawlessly in Chrome 
using http://html5gamepad.com/

So, if there's anyone here who even begins to know how gamepads work… am I 
about to wade into an ocean of pain? I'd *like* to avoid linking to sdl as 
gobot seems to do for joysticks: it would be lovely to have something in 
pure Go. Is that unlikely?

How are games (and Chrome) even finding the controller? Do they have to 
interrogate the Bluetooth stack, and then speak both Bluetooth and the XBox 
controller protocol?

Any help appreciated.

Zellyn

-- 
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: ANN: gemacs, a lightweight emacs, written in pure Go

[Zellyn]

Heh. I didn't realize that godit isn't terminal-capable. I thought, “Who 
cares which terminal library it uses?” lol.
Thanks for the clarification :-)

Zellyn

On Tuesday, March 13, 2018 at 5:51:01 PM UTC-4, Jason E. Aten wrote:
>
> On Tuesday, March 13, 2018 at 9:03:15 AM UTC-5, Zellyn wrote:
>>
>>
>> What is the relationship between gemacs and godit? 
>>
>
> While that was answered in the very first two lines of the readme, I've 
> added language there to emphasize the contrast. Using tcell is the big one. 
> A bunch of smaller updates add some usability polish for fingers expecting 
> gnu emacs bindings.
>

-- 
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: ANN: gemacs, a lightweight emacs, written in pure Go

[Zellyn]

Nice!

What is the relationship between gemacs and godit? The readme seems mostly 
a copy, so I was expecting godit to be abandoned. But it's showing recent 
activity…

On Monday, March 12, 2018 at 5:10:20 PM UTC-4, Jason E. Aten wrote:
>
> *https://github.com/glycerine/gemacs *
>

-- 
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] Go += Package Versioning

[Zellyn Hunter]

On Fri, Feb 23, 2018 at 10:01 AM Nic Pottier <nicpott...@gmail.com> wrote:

> Right, that works for clients of the library (and I did manage to get
> my projects working with that and it now feels magical) but authors of
> modules above v1 are posed with a bit of a quandary as to how to give
> their users a nice vgo version without breaking current users on plain
> go.
>

 Why not just commit a mod.go with v3 in it at the root, and tag it
3.{y+1}?, assuming you're already on v3.y? Adding mod.go doesn't break
existing users. vgo users will use different import paths. If you like, you
can branch off of your 1.x tag, add a mod.go with v1 in it there, and tag
it 1.{x+1}. Same for v2.

Oh wait, is it a problem because your self-import paths need to change (or
not) depending on whether the client is using vgo? I think I'm unclear on
that detail :-)

Zellyn

-- 
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] Go += Package Versioning

[Zellyn]

Fantastic post. One small answer below:

On Friday, February 23, 2018 at 2:22:32 AM UTC-5, David Anderson wrote:
>
> The version to use in that replacement was hard to come by. Since vgo was 
> unable to compute the right dependency list without this replacement, it 
> bailed without giving me any version I might use. The date+hash format is 
> irritating to construct by hand, but could be trivially lifted into a tool 
> (perhaps even vgo itself).
>

git log -1 ae16178c028329cb0b979cd63bbd3921ddaf0945 
--date='format:%Y%m%d%H%M%S' --format='v.0.0.0-%cd-%h'
v.0.0.0-20180222211942-ae16178c02

Zellyn
 

-- 
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] Go += Package Versioning

[Zellyn]

On Wednesday, February 21, 2018 at 4:45:25 PM UTC-5, Bakul Shah wrote:
>
> Something like 
> import "foo" v2 
> would be mildly preferable to me as 
> import "foo/v2" 
> can also refer to version 1 of a package named v2 (as opposed 
> to version 2 of foo) and the current naming rules continue to 
> work. 
>

As I understood it, the fundamental philosophical point of today's rsc 
article was that you shouldn't use the the same "name" (identifier) for two 
different "things". If you look at it from that point of view, the "v2" 
should absolutely be part of the package URL. In fact, having the concept 
of version stored in some lookaside metadata outside of the name (eg. git 
tag) would be a mistake.

Zellyn

-- 
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] Go += Package Versioning

[Zellyn]

On Wednesday, February 21, 2018 at 2:23:07 PM UTC-5, Sam Whited wrote:
>
> Something that is still unclear to me even after reading todays post is 
> how I would manage the various package import paths created by the import 
> compatibility rule. 
> The way this is currently done is through tools such as gopkg.in, will 
> the import path be modified and rewritten by a package server in the 
> future? 
> If not,  do I maintain separate /v2 and /v3 trees in my directory and 
> copy/paste changes between them when I want to release security fixes as a 
> point release? 
> Do I maintain separate branches that have a single /v2 or /v3 tree (if so, 
> cherry-picking changes between them will be very difficult)? 
> Do I maintain separate repos and cherry pick or copy/paste files between 
> them? 
>
> None of these sound especially appealing except perhapse having a server 
> handle it for me, but this makes hosting my own packages harder. 
>
> —Sam 
>

Maintaining fixes on two different branches doesn't seem much easier. I 
guess you could cherry-pick the same commit onto both branches, if it 
worked. With both versions visible in the same repository, you can send one 
PR that applies the same fix in two places, which is nice for review.

I guess every approach has pros and cons. vgo seems particularly goish :-)

Zellyn 

-- 
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: Go += Package Versioning

[Zellyn]

A couple of initial questions:

   - The "pretend you're importing github.com/foo/bar but actually pull it 
   from localgit.host/foo/bar" functionality of dep was going to really 
   simplify things for us. I can't quite tell whether vgo includes that 
   functionality or not. We would want to do it at the monorepo level: ie. 
   *everything* should use our forked version of the `glog` and `protobuf` 
   packages.
   - For our (go monorepo) usecase: do you envision a single go.mod file 
   being placed at the root, or would we sprinkle them as needed for each 
   sub-project in the monorepo? Does vgo search upward for go.mod files?
   - More details on the zipfile module representation will be welcome.
   - Getting rid of GOPATH is nice. Where will `vgo install` drop binaries?
   
Thanks for your work on this. It looks very “Go-ish”. Interested to learn 
more.

Zellyn

On Tuesday, February 20, 2018 at 12:20:54 PM UTC-5, Russ Cox wrote:
>
> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
>

-- 
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: ANN: gijit, a Go interpreter

[Zellyn]

Very nice. You might be interested in this Group 
too: https://groups.google.com/forum/#!forum/go-interpreter

On Wednesday, February 7, 2018 at 3:00:06 PM UTC-5, Jason E. Aten wrote:
>
> https://github.com/gijit/gi
>
> My interactive Go REPL, gijit, is quite useful now. It has structs, 
> pointers, defer, and interfaces implemented.  You can call into native Go 
> packages.
>
> Enjoy,
>
> Jason
>

-- 
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: Announcing: Skylark in Go

[Zellyn Hunter]

Oh neat. So is it a sort of competitor to jsonnet? I guess jsonnet is
usually used to generate actual config files, not live-interpret executable
config.

Zellyn

On Tue, Nov 7, 2017 at 3:46 PM Alan Donovan <adono...@google.com> wrote:

> On 7 November 2017 at 15:36, Zellyn <zel...@gmail.com> wrote:
>
>> An only-2x-slower than CPython interpreter is pretty cool. Just very
>> curious what y'all are doing with it.
>>
>
> Various infrastructure projects (such as Copybara) are using Skylark as a
> configuration language since it has proven itself on a large scale within
> Bazel, is familiar to everyone at Google, and is pretty rational for a
> configuration language.  Some of those projects use Go, or would use Go if
> only it had an implementation of Skylark.
>
>

-- 
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: Announcing: Skylark in Go

[Zellyn]

Bump, since y'all seem to be actively posting here :-)  An only-2x-slower 
than CPython interpreter is pretty cool. Just very curious what y'all are 
doing with it.

On Thursday, November 2, 2017 at 3:22:44 PM UTC-4, Zellyn wrote:
>
> This looks neat. Are you able to provide more context on what this is/will 
> be used for at Google?
>

-- 
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: Announcing: Skylark in Go

[Zellyn]

This looks neat. Are you able to provide more context on what this is/will 
be used for at Google?

On Monday, October 2, 2017 at 12:39:43 PM UTC-4, Alan Donovan wrote:
>
> I'm pleased to announce the launch of Skylark in Go: an interpreter for 
> Skylark, implemented in Go.
>
> github.com/google/skylark
>
> Skylark is a dialect of Python intended for use as a configuration 
> language. Like Python, it is an untyped dynamic language with high-level 
> data types, first-class functions with lexical scope, and garbage 
> collection. Unlike CPython, independent Skylark threads execute in 
> parallel, so Skylark workloads scale well on parallel machines. Skylark is 
> a small and simple language with a familiar and highly readable syntax. You 
> can use it as an expressive notation for structured data, defining 
> functions to eliminate repetition, or you can use it to add scripting 
> capabilities to an existing application.
>

-- 
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] Why golang garbage-collector not implement Generational and Compact gc?

[Zellyn]

What a fantastic discussion. Thanks so much, folks!

-- 
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] Why golang garbage-collector not implement Generational and Compact gc?

[Zellyn]

Thanks for the enlightening and interesting reply, Ian.

One quick question: do you have a link or a short description of why 
“modern memory allocation algorithms, like the tcmalloc-based approach used 
by the Go runtime, have essentially no fragmentation issues”?

I was curious, but a quick search for [tcmalloc fragmentation] yielded 
mostly people struggling with fragmentation issues when using tcmalloc.

Zellyn

-- 
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] Weird performance with exp/shiny

[Zellyn]

Yes, the racy boolean access made me cringe but I was going for short :-)

Your suggestion to disentangle rendering from emulation is a good idea... now 
that I understand what's happening!

The really funny thing is that my emulator looked suspiciously close to the 
right speed: since I was calling the shiny update once per emulated frame, if 
it was delaying to the next 60th of a second, it may be *exactly* correct :-)

Thanks for the help. And for shiny!

Zellyn 

-- 
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] Weird performance with exp/shiny

[Zellyn]

I'm sure I'm doing something hideously wrong with shiny, since my emulator 
runs three times faster on my MacBook if I run it under VirtualBox/Ubuntu. 
Yes, you read that right.
Here, I tweeted an animated gif of them running side by 
side: https://twitter.com/zellyn/status/857674501928222720

I ripped out the emulator code and made it simply plot a pixel each frame. 
Here's the result, which still runs much faster under a virtual machine: 
https://play.golang.org/p/par16HK1X2

I'm sure I'm doing the wrong kind of texture update / buffer copy / 
something wrong. Please, educate me! Extra points for explaining enough to 
us all that we could understand what's actually going on.

Thanks,

Zellyn

-- 
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: togo: tool for converting files to .go

[Zellyn]

https://github.com/jteeuwen/go-bindata is the one I see most often. There 
are several alternatives listed in the README 
at https://github.com/shurcooL/vfsgen

On Monday, March 20, 2017 at 12:02:47 PM UTC-4, Francesco Lazzarino wrote:
>
> Hi,
>
> I made a handy tool that converts a file in a pkgs to a src file with a 
> []byte var. Then you can compile arbitrary files into a pkg. I found it 
> handy for use via go generate.
>
> https://github.com/flazz/togo
>
> If this is a solved problem (or a bad approach) let me know, I'll amend 
> the README with alternatives.
>
> Hope it helps anyone
>
> -Franco
>

-- 
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: Streaming EME mp3?

[Zellyn]

I'm not sure this is relevant to golang-nuts. This article 
 might be a good start 
though.

On Tuesday, January 3, 2017 at 10:27:05 AM UTC-5, Darko Luketic wrote:
>
> We have a site with many mp3 files.
>
> And every now and then someone would have the smart idea to download our 
> files and put them on Youtube for monetization purposes.
>
> I'd like to stop that.
> I read a bit about "Encrypted Media Extensions" aka browser drm.
>
> But I'm not sure how that is done on the server side.
>
> Has anyone played with this or has any experience with it?
> How do you encrypt a mp3 file so it's able to be unencrypted in the 
> browser and played via EME?
>

-- 
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: Tooling experience feedback

[Zellyn]

I run go tests with something like this:

while true; do go test ./foo/bar; fswatch -1 -r . > /dev/null; sleep 0.3; 
done


It would be nice if go test could do that itself. (The 0.3 second sleep is 
to let the file-write that triggered the test complete.)


Zellyn

On Tuesday, October 18, 2016 at 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
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.