[go-nuts] Re: [ANN] listser/mutexer/channeler: generators.

[omarshariffdontlikeit]

Interesting stuff! Thanks for the pointer on 
https://github.com/mh-cbon/mutexer 
,
 
missed that! I have noticed that the https://github.com/mh-cbon/mutexer 

 version 
doesnt implement all the methods the lister does (such as map, filter).

I was thinking of doing something similar myself for iterator types e.g. 
Next(), Rewind() etc.

Might have a play with a fork of Lister and see if I can get a version 
working.

Incidentally, out of curiosity, I noticed that the output code is "hard 
coded" into the main.go; would it not be clearer/more maintainable to use 
templates?



On Wednesday, May 3, 2017 at 4:37:42 PM UTC+1, mhh...@gmail.com wrote:
>
> hi
>
> > Can anyone else recommend any other generators that produce 
> lists/iterators like this?
>
> good Q.
>
> > Is the resulting generated code safe to use from multiple go routines?
>
> The slice itself nop, because, for that you want to use 
>
> https://github.com/mh-cbon/channeler
> or
> https://github.com/mh-cbon/mutexer
>
> You make a typed slice then you facade it with one of the syncer.
>
> So yep, that example is not TS,
> this was just for fun and demo
>
> backend := NewTomates() // This is not TS, it d need an additional 
> layer
> backend.Push(Tomate{Name: "red"})
> jsoner := NewJSONTomates(backend)
> httper := NewHTTPTomates(jsoner)
>
> // public views
> http.HandleFunc("/", httper.At)
>
> /*
> curl -H "Accept: application/json" -H "Content-type: 
> application/json" -X POST -d ' {"i":0}'  http://localhost:8080/
> */
>
> log.Fatal(http.ListenAndServe(":8080", nil))
>
>
> In the same manner if you have n collections in memory which needs TS,
> that d be inappropriate to have n TS lists communicating with each other 
> on the main routine,
> that d create additional contentions,
> you d better create a controller, that is totally TS, 
> that access those slice without syncing.
>
>
> On Wednesday, May 3, 2017 at 4:30:20 PM UTC+2, Ben Davies wrote:
>>
>> Is the resulting generated code safe to use from multiple go routines?
>>
>> On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> several generators i made to avoid some duplication.
>>>
>>> https://github.com/mh-cbon/lister
>>>
>>> Package lister is a generator to generate typed slice.
>>>
>>>
>>> https://github.com/mh-cbon/channeler
>>>
>>> Package channeler is a cli generator to generate channeled version of a 
>>> type.
>>>
>>> https://github.com/mh-cbon/mutexer
>>>
>>> Package mutexer is a cli generator to generate mutexed version of a type.
>>>
>>>
>>> so basically, using below code you got hundreds of line generated for 
>>> you,
>>>
>>>
>>> in that example to make a mutexed []Tomate.
>>>
>>>
>>> But as it s not too stupid, or tries too, it will be able to handle 
>>>
>>> pointer and basic types
>>>
>>> mutexed []*Tomate
>>>
>>> mutexed []string
>>>
>>> ect
>>>
>>>
>>> It should also be able to lookup for a constructor of the src type 
>>> (Tomate),
>>>
>>> and reproduce it into the dest type implementation.
>>>
>>>
>>> There is both mutexer / channeler because both cases applies for reasons.
>>>
>>>
>>> The lister is a convenient way to create typed slice.
>>>
>>>
>>> package demo
>>>
>>> // Tomate is about red vegetables to make famous italian food.
>>> type Tomate struct {
>>> Name string
>>> }
>>>
>>> // GetID return the ID of the Tomate.
>>> func (t Tomate) GetID() string {
>>> return t.Name
>>> }
>>>
>>> //go:generate lister vegetables_gen.go Tomate:Tomates
>>> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>>>
>>> hth
>>>
>>>

-- 
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] listser/mutexer/channeler: generators.

[omarshariffdontlikeit]

Is the resulting generated code safe to use from multiple go routines?

On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:
>
> Hi,
>
> several generators i made to avoid some duplication.
>
> https://github.com/mh-cbon/lister
>
> Package lister is a generator to generate typed slice.
>
>
> https://github.com/mh-cbon/channeler
>
> Package channeler is a cli generator to generate channeled version of a 
> type.
>
> https://github.com/mh-cbon/mutexer
>
> Package mutexer is a cli generator to generate mutexed version of a type.
>
>
> so basically, using below code you got hundreds of line generated for you,
>
>
> in that example to make a mutexed []Tomate.
>
>
> But as it s not too stupid, or tries too, it will be able to handle 
>
> pointer and basic types
>
> mutexed []*Tomate
>
> mutexed []string
>
> ect
>
>
> It should also be able to lookup for a constructor of the src type 
> (Tomate),
>
> and reproduce it into the dest type implementation.
>
>
> There is both mutexer / channeler because both cases applies for reasons.
>
>
> The lister is a convenient way to create typed slice.
>
>
> package demo
>
> // Tomate is about red vegetables to make famous italian food.
> type Tomate struct {
> Name string
> }
>
> // GetID return the ID of the Tomate.
> func (t Tomate) GetID() string {
> return t.Name
> }
>
> //go:generate lister vegetables_gen.go Tomate:Tomates
> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>
> hth
>
>

-- 
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] listser/mutexer/channeler: generators.

[omarshariffdontlikeit]

This looks really good. Can anyone else recommend any other generators that 
produce lists/iterators like this?

On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:
>
> Hi,
>
> several generators i made to avoid some duplication.
>
> https://github.com/mh-cbon/lister
>
> Package lister is a generator to generate typed slice.
>
>
> https://github.com/mh-cbon/channeler
>
> Package channeler is a cli generator to generate channeled version of a 
> type.
>
> https://github.com/mh-cbon/mutexer
>
> Package mutexer is a cli generator to generate mutexed version of a type.
>
>
> so basically, using below code you got hundreds of line generated for you,
>
>
> in that example to make a mutexed []Tomate.
>
>
> But as it s not too stupid, or tries too, it will be able to handle 
>
> pointer and basic types
>
> mutexed []*Tomate
>
> mutexed []string
>
> ect
>
>
> It should also be able to lookup for a constructor of the src type 
> (Tomate),
>
> and reproduce it into the dest type implementation.
>
>
> There is both mutexer / channeler because both cases applies for reasons.
>
>
> The lister is a convenient way to create typed slice.
>
>
> package demo
>
> // Tomate is about red vegetables to make famous italian food.
> type Tomate struct {
> Name string
> }
>
> // GetID return the ID of the Tomate.
> func (t Tomate) GetID() string {
> return t.Name
> }
>
> //go:generate lister vegetables_gen.go Tomate:Tomates
> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>
> hth
>
>

-- 
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: [blog post] go tool trace: Golang's hidden trace visualiser

[omarshariffdontlikeit]

This is awesome. Didn't even know this tool existed!

On Thursday, April 6, 2017 at 6:00:55 PM UTC+1, Will Sewell wrote:
>
> Apologies. I just realised I didn't actually link to the post! It's here: 
> https://making.pusher.com/go-tool-trace/.
>
> On Thursday, 6 April 2017 17:29:22 UTC+1, Will Sewell wrote:
>>
>> Hi, I've just written a blog post/tutorial on Go's relatively unknown, 
>> but incredibly useful, trace visualiser: `go tool trace`. The post provides 
>> a tour of the interface, and examples of the kind of problems it can aid in 
>> tracking down.
>>
>> I was originally made aware of it by Rhys Hiltner in my previous message 
>> to this mailing list when I was investigating long GC pause times: 
>> https://groups.google.com/d/msg/golang-nuts/nOD0fGmRp_g/4FEThB1bBQAJ. So 
>> thanks for pointing it out Rhys! As he mentions in that thread, it is 
>> currently not well documented, so I felt it was a good opportunity for a 
>> blog post after playing around with it for a bit.
>>
>> In the future I'd like to investigate and write about how the runtime 
>> event system itself actually works because it seems like an interesting 
>> area.
>>
>> Let me know if you have any feedback.
>>
>> Thanks,
>> Will
>>
>

-- 
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] jq (JSON Query) write support?

[omarshariffdontlikeit]

Just a quick one - anyone know of a JQ package that supports modifying 
values that match? I've found several packages that support reading values 
but none that support modifying values on match.

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.

[go-nuts] Re: Applying idiomatic Golang patterns to other languages?

[omarshariffdontlikeit]

I experimented using the function options (e.g. withFunc() ) in PHP. I know 
its unnecessary as PHP functions and methods can accept optional 
parameters, and I know that you cant have function types in PHP, but the 
approach is still so clean and self documenting I'd like to use it for much 
more in PHP:

$conn = new Beanstalk\Connection(
withHost('127.0.0.1'),
withPort(11300),
);

I've also found that my approach is much more "inside out", much more like 
Uncle Bobs clean architecture - a core library of domain objects is what I 
am building, with supporting tools for use cases e.g. PHAR command line 
tool.


On Tuesday, January 17, 2017 at 5:58:46 AM UTC, so.q...@gmail.com wrote:
>
> Just curious how often you find yourself applying idiomatic Go patterns to 
> other languages? (JavaScript, Python, C#, Java)
>
> For instance returning and handling an error value as opposed to 
> throw-try-catch. I understand this isn't the best example since try-catch 
> exceptions are more closely aligned to panics, but I do find myself 
> returning more error values since using Go.
>
>
>

-- 
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] http.Client interface

[omarshariffdontlikeit]

Thats what I think too. Thanks for the confirmation, I'll raise a pull 
request with the aforementioned third-party package.

Thanks everyone.

On Monday, December 12, 2016 at 10:25:10 AM UTC, Dave Cheney wrote:
>
> I don't think it's up to the std lib to define such an interface; that 
> should be the responsibility of the third party package -- it should define 
> an interface with the behaviour it requires
>
> On Monday, 12 December 2016 20:55:26 UTC+11, omarsharif...@gmail.com 
> wrote:
>>
>> Yeah, I thought as much.
>>
>> I will raise a pull request with the third-party package and implement 
>> the requirement of a http.Client as an interface that matches the 
>> http.Client methods used by the package.
>>
>> Should the standard library http.Client provide an interface for 
>> http.Client so that third-party packages can accept that instead of the 
>> concrete stdlib http.Client, or is it the communities opinion that 
>> third-party packages should create an interface they accept, which covers 
>> the methods they call?
>>
>> Cheers,
>> Ben
>>
>> On Sunday, December 11, 2016 at 7:59:12 PM UTC, Kevin Conway wrote:
>>>
>>> >  How would I swap out a http.Client that is required by a third-party 
>>> library with a another that supports, say retries with exponential back-off?
>>> I'd suggest looking at http.Transport and http.RoundTripper [
>>> https://golang.org/pkg/net/http/#RoundTripper]. The docs explicitly 
>>> forbid using RoundTripper to implement higher level protocol features like 
>>> retry-with-backoff based on HTTP response codes, but those are your only 
>>> hooks into making this a feature of the client rather than moving the retry 
>>> logic somewhere else.
>>>
>>>
>>> On Sun, Dec 11, 2016 at 4:07 AM  wrote:
>>>
 Just a quick question - I've noticed that the http package doesn't have 
 an interface for Client. How would I swap out a http.Client that is 
 required by a third-party library with a another that supports, say 
 retries 
 with exponential back-off? It appears that it is not possible? Would the 
 http package benefit from an interface for the http.Client?

 Cheers!
 Ben 

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

Re: [go-nuts] http.Client interface

[omarshariffdontlikeit]

Yeah, I thought as much.

I will raise a pull request with the third-party package and implement the 
requirement of a http.Client as an interface that matches the http.Client 
methods used by the package.

Should the standard library http.Client provide an interface for 
http.Client so that third-party packages can accept that instead of the 
concrete stdlib http.Client, or is it the communities opinion that 
third-party packages should create an interface they accept, which covers 
the methods they call?

Cheers,
Ben

On Sunday, December 11, 2016 at 7:59:12 PM UTC, Kevin Conway wrote:
>
> >  How would I swap out a http.Client that is required by a third-party 
> library with a another that supports, say retries with exponential back-off?
> I'd suggest looking at http.Transport and http.RoundTripper [
> https://golang.org/pkg/net/http/#RoundTripper]. The docs explicitly 
> forbid using RoundTripper to implement higher level protocol features like 
> retry-with-backoff based on HTTP response codes, but those are your only 
> hooks into making this a feature of the client rather than moving the retry 
> logic somewhere else.
>
>
> On Sun, Dec 11, 2016 at 4:07 AM  
> wrote:
>
>> Just a quick question - I've noticed that the http package doesn't have 
>> an interface for Client. How would I swap out a http.Client that is 
>> required by a third-party library with a another that supports, say retries 
>> with exponential back-off? It appears that it is not possible? Would the 
>> http package benefit from an interface for the http.Client?
>>
>> Cheers!
>> Ben 
>>
>> -- 
>> 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] http.Client interface

[omarshariffdontlikeit]

Just a quick question - I've noticed that the http package doesn't have an 
interface for Client. How would I swap out a http.Client that is required 
by a third-party library with a another that supports, say retries with 
exponential back-off? It appears that it is not possible? Would the http 
package benefit from an interface for the http.Client?

Cheers!
Ben 

-- 
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: A HTTP backed File System (FUSE)

[omarshariffdontlikeit]

WebDAV?

On Wednesday, November 30, 2016 at 1:21:22 PM UTC, 
prol...@shortcircuit.net.au wrote:
>
> Hey all, First time poster here so go easy on me :)
>
> Just sharing httpfs: https://github.com/prologic/httpfs
> (Naming is hard!)
>
> This is basically a HTTP backed FileSystem using FUSE via the wonderful 
> bazil.org/fuse library.
>
> Why? Scratching my own itch to present remote storage on my home NAS as a 
> regular folder for family.
> Also pan on extending and working more on this to build this out into a 
> docker volume driver.
>
> Critique and feedback welcome as well as testers and contributions!
>
> cheers
> James
>

-- 
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] synchronise read from two channels

[omarshariffdontlikeit]

Yup I thin I was frying my brain on this - it also led to questions such as 
"if I read a worker from the channel and there ISNT a URL waiting how do I 
write back into the channel making it available - what if more than one go 
routine is reading from the channel... etc"

I knew I was over complicating it I just couldnt see the forest for the 
trees! I assumed I wanted channels for the available and busy workers when 
really I wanted stacks.

thanks for the in-depth discussion - in future I will sleep on it next time 
and come at it afresh :)

(ironically I'd done exactly this before with stacks in an old project 
which is what gave me the lightbulb moment this morning)

Thanks everyone!

On Thursday, December 1, 2016 at 3:21:46 PM UTC, Jesper Louis Andersen 
wrote:
>
> On Wed, Nov 30, 2016 at 6:07 PM  
> wrote:
>
>> Hi, I'm having a bit of a slow day... I'm trying to synchronise two reads 
>> from two channels and can't get my fuzzy head round the problem.
>>
>>
> Go doesn't have support for an (atomic) read from multiple channels at 
> once. There are other systems which can do this (JoCaml, join-calculus, 
> Concurrent ML, Haskell's STM, Reagents[0] in Scala, ...)
>
> However, as you found out, one can often rearrange the code base as to 
> avoid the problem. There is also the problem of more advanced 
> select-constructs not being free in the performance sense: atomic sync on 
> multiple channels tend to be rather expensive.
>
> One reason it isn't that simple to implement is to consider the following 
> (hypothetical) snippet:
>
> select {
> case w := <-available && urlChan <- value:
> ..BODY..
> }
> }
>
> in which the atomic operation must simultaneously receive a message on the 
> 'available' channel and send a message on the 'urlChan' channel. And 
> further, since you introduced && to mean logical-and-between-channels, you 
> might as well introduce || to mean logical-or-between-channels. Once there, 
> you may want to introduce a new type
>
> event t
>
> for some type t alongside 'chan t'. Hence the expression (<-available) 
> becomes an expression of type 'event *worker' and now they can be composed 
> via && and ||. This means we can get rid of select since it is just an 
> expression which successively applies || to a slice of values. If we then 
> introduce an new statement, sync, which turns 'event t' into a 't', we are 
> done. And we have almost implemented the basis of Concurrent ML in the 
> process.
>
> In short, you could be opening a regular can of worms if you start 
> allowing for more complicated select-expressions. Hence the school of 
> keeping them relatively simple.
>
> [0] https://people.mpi-sws.org/~turon/reagents.pdf 
>

-- 
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: synchronise read from two channels

[omarshariffdontlikeit]

Just as a follow up for anyone else - in the end I used two simple stacks 
for available and active lists of workers and simply popped a worker of the 
available stack when a url came in, assigned it to the worker and then 
pushed it to the active stack. Job done!

On Thursday, December 1, 2016 at 9:07:42 AM UTC, omarsharif...@gmail.com 
wrote:
>
> Yeah I kinda figured I was coming to this wrong way - my tired brain had 
> an unterminated loop. Thanks for the pointers! (all puns intended)
>
> On Wednesday, November 30, 2016 at 5:08:06 PM UTC, omarsharif...@gmail.com 
> wrote:
>>
>> Hi, I'm having a bit of a slow day... I'm trying to synchronise two reads 
>> from two channels and can't get my fuzzy head round the problem.
>>
>> I have a channel containing urls (which will be feed periodically by a 
>> named pipe by another program) and I have a cannel which consists of a pool 
>> of available workers. I'd like to synchronise these and put a worker into a 
>> third channel for active workers if there is a url in the channel and if 
>> there is an available worker.
>>
>> Ideally I'd be able to do something like:
>>
>> go func(urlChan <-chan *url.URL, availableWorkerChan <-chan *worker, 
>> activeWorkerChan chan<- *worker){
>> for {
>> select{
>> case w := <-availableWorkerChan && w.Url = <-urlChan:
>> activeWorkersChan <- w
>> }
>> }
>> }(a, b, c)
>>
>> But obviously thats not right!
>>
>> Can anyone offer my tired brain a clue?
>>
>> Cheers!
>> Ben
>>
>

-- 
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: synchronise read from two channels

[omarshariffdontlikeit]

Yeah I kinda figured I was coming to this wrong way - my tired brain had an 
unterminated loop. Thanks for the pointers! (all puns intended)

On Wednesday, November 30, 2016 at 5:08:06 PM UTC, omarsharif...@gmail.com 
wrote:
>
> Hi, I'm having a bit of a slow day... I'm trying to synchronise two reads 
> from two channels and can't get my fuzzy head round the problem.
>
> I have a channel containing urls (which will be feed periodically by a 
> named pipe by another program) and I have a cannel which consists of a pool 
> of available workers. I'd like to synchronise these and put a worker into a 
> third channel for active workers if there is a url in the channel and if 
> there is an available worker.
>
> Ideally I'd be able to do something like:
>
> go func(urlChan <-chan *url.URL, availableWorkerChan <-chan *worker, 
> activeWorkerChan chan<- *worker){
> for {
> select{
> case w := <-availableWorkerChan && w.Url = <-urlChan:
> activeWorkersChan <- w
> }
> }
> }(a, b, c)
>
> But obviously thats not right!
>
> Can anyone offer my tired brain a clue?
>
> Cheers!
> Ben
>

-- 
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] synchronise read from two channels

[omarshariffdontlikeit]

Hi, I'm having a bit of a slow day... I'm trying to synchronise two reads 
from two channels and can't get my fuzzy head round the problem.

I have a channel containing urls (which will be feed periodically by a 
named pipe by another program) and I have a cannel which consists of a pool 
of available workers. I'd like to synchronise these and put a worker into a 
third channel for active workers if there is a url in the channel and if 
there is an available worker.

Ideally I'd be able to do something like:

go func(urlChan <-chan *url.URL, availableWorkerChan <-chan *worker, 
activeWorkerChan chan<- *worker){
for {
select{
case w := <-availableWorkerChan && w.Url = <-urlChan:
activeWorkersChan <- w
}
}
}(a, b, c)

But obviously thats not right!

Can anyone offer my tired brain a clue?

Cheers!
Ben

-- 
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: Implementation status of database/sql changes

[omarshariffdontlikeit]

I'd just like to say, as someone who is champing at the bit to access MySQL 
Stored Procedures from Go, that all these suggested changes look great and 
really well thought out from the developers side of things! Cracking job!



On Tuesday, November 8, 2016 at 5:17:48 PM UTC, mattn wrote:
>
> Hi list.
>
> I put the Google Spreadsheet that indicate implementation status of 
> database/sql changes.
>
> * Description of the changes
>
> https://docs.google.com/document/d/1F778e7ZSNiSmbju3jsEWzShcb8lIO4kDyfKDNm4PNd8/edit#
>
> * Implementation status
>
> https://docs.google.com/spreadsheets/d/1y7AzkFNPeTBado0xJJipB5MpWlcqylQg410Q5wHz2Ew/edit
>
> If you are an author of one of the drivers, please update the below 
> spreadsheet.
>
> Thanks
> - mattn
>
>

-- 
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 management proposal process

[omarshariffdontlikeit]

This is great news! For me this was the last wrinkle in the Go eco system, 
glad to here its getting an official solution with some talented people 
involved. Kudos to everyone involved in this.

On Friday, July 29, 2016 at 8:46:01 AM UTC+1, Peter Bourgon wrote:
>
> Hello, 
>
> For well over a year, a group of dedicated Gophers have been 
> discussing the package management situation on a dedicated mailing 
> list, in Slack #vendor, and several communication channels. A few 
> tools have emerged from those broad conversations, including Glide, 
> govendor, gb, and the SAT solver gps. And at GopherCon 2016, a panel 
> with several members of the core Go team was held. 
>
> While much remains to be decided, a few things are clear. The package 
> management solution, whatever it will be, will take the form of one or 
> more official Go language proposals. And the proposals (and their 
> eventual implementation) will be driven by a small committee of 
> dedicated Gophers. 
>
> In the interest of progress, I've volunteered to shepherd this process 
> from start to finish. I've created a document detailing a proposal for 
> the process itself. If this topic interests you, please review and 
> comment. 
>
>
> https://docs.google.com/document/d/18tNd8r5DV0yluCR7tPvkMTsWD_lYcRO7NhpNSDymRr8
>  
>
> As much as anything can be official, I hope that this will be the 
> official process, leading to the long-desired blessed solution. 
>
> Regards, 
> Peter Bourgon. 
>

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