Re: [go-nuts] Re: Go += Package Versioning

by importing reflect or executing external commands), and seems to be a feasible goal. On Thursday, February 22, 2018 at 11:31:35 AM UTC+3:30, Axel Wagner wrote: > > On Thu, Feb 22, 2018 at 7:10 AM dc0d <kaveh.sh...@gmail.com > > wrote: > >> I'm looking forward to see t

[go-nuts] Re: Go += Package Versioning

And also I would like the $GOPATH to stay. I clean it up from time to time - also $GOPATH/bin which go install uses. On Thursday, February 22, 2018 at 9:40:17 AM UTC+3:30, dc0d wrote: > > I'm looking forward to see this in official releases too! > > Also I would like to: > >

[go-nuts] Re: Go += Package Versioning

I'm looking forward to see this in official releases too! Also I would like to: - Have a mechanism for safe dependency packages (as in Safe-Tcl - this implies it would be possible to have meta-data other than versions for packages, too). - This one

[go-nuts] Re: All Forms of Wishful Generics

as to the field of multi-processing. Go >would be a good place to install that invention, as it is still a simple >language. > >2. And you mean go must *adapt*, perhaps by ad*o*pting new features... > > > On Monday, February 19, 2018 at 1:17:22 PM UTC+2,

[go-nuts] Re: All Forms of Wishful Generics

syntax or semantics - while it is a possibility. On Monday, February 19, 2018 at 2:47:22 PM UTC+3:30, dc0d wrote: > > Dogan, > > Why does it have to be a breaking change? And there are other things too > that are equally - if not more - important to me (the provided link to the > list). >

[go-nuts] Re: All Forms of Wishful Generics

If Go team add generics to Go 2, i am afraid that Go 2 will have the same > fate as python 3. > > Let's hope it never happens. > > On Friday, February 16, 2018 at 7:25:35 AM UTC+1, dc0d wrote: >> >> All forms of generics that I would love to have in Go:

Re: [go-nuts] Re: All Forms of Wishful Generics

trust. On Sunday, February 18, 2018 at 7:17:56 AM UTC+3:30, Lars Seipel wrote: > > On Sat, Feb 17, 2018 at 01:10:29AM -0800, dc0d wrote: > > There are other things too, that I would like to have in Go; like a > faster > > FFI/CGO, or safe packages by restricting features

[go-nuts] Re: All Forms of Wishful Generics

Indeed it's a form of package/block level code-specialization, so called generics. There is a proposal for package level generics by me too. My main concern here was to have this feature without invalidating current Go code bases, by allowing the rebinding of Type Aliases

[go-nuts] Re: All Forms of Wishful Generics

Agreed. But it's not necessarily a "obsolescence" vs "being crushed (...)" thing. With the brainpower behind Go, sure the best things will happen. I'm not saying that Go has to add generics (or not). In fact generics is just one of the things that I would like to see in Go. There are other

[go-nuts] Re: Implementation of sync.Once

, February 16, 2018 at 5:07:53 PM UTC+3:30, dja...@gmail.com wrote: > > > > On Friday, February 16, 2018 at 3:27:04 PM UTC+2, dc0d wrote: >> >> Why sync.Once uses a sync.Mutex in addition to atomic functions? >> >> What are the drawbacks/shortcomings/deficiencies of t

[go-nuts] Implementation of sync.Once

Why sync.Once uses a sync.Mutex in addition to atomic functions? What are the drawbacks/shortcomings/deficiencies of this implementation? type Once struct { done uint32 } func (o *Once) Do(f func()) { if !atomic.CompareAndSwapUint32(, 0, 1) { return } f() } -- You received this

[go-nuts] Re: All Forms of Wishful Generics

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup, I use other programming languages too - obviously. And I will continue to think of better ways to perform Go, if not complaining. Meanwhile this <https://github.com/d

[go-nuts] All Forms of Wishful Generics

All forms of generics that I would love to have in Go: -- You received this message because you are subscribed to the Google Groups "golang-nuts"

[go-nuts] Re: Safe Packages

And I did not mean this to be a language feature. Just a tool - or part of linter. On Monday, February 12, 2018 at 11:36:36 PM UTC+3:30, dc0d wrote: > > Awesome! > > (IMHO) > > Going for total immutability is not a best fit for Go. I was thinking like > excluding packages

[go-nuts] Re: Safe Packages

for the link, On Monday, February 12, 2018 at 11:23:42 PM UTC+3:30, matthe...@gmail.com wrote: > > We’ve been discussing stateless packages here: > https://github.com/golang/go/issues/23267 > > Matt > > On Monday, February 12, 2018 at 1:43:05 PM UTC-6, dc0d wrote: >> &g

[go-nuts] Re: Safe Packages

define as "safe"? > > > On Monday, February 12, 2018 at 12:43:05 PM UTC-7, dc0d wrote: >> >> Is there a way to identify a package as safe? >> >> Let's restrict the imported packages to built-in ones. Now assuming a >> package only imports "strings" and

[go-nuts] Safe Packages

Is there a way to identify a package as safe? Let's restrict the imported packages to built-in ones. Now assuming a package only imports "strings" and "net/url" can it considered as safe? Since it does not (can not) modify the environment (most notably executing code)? Of course the package

[go-nuts] Re: Difficulties Using golang.org/x/net/html

Solved: problem is component is not a standard html tag. That's why the parser does not respect the self closing version. So if instead of a properly closed one like is used, it will work properly. (Help from gophers slack) On Thursday, January 25, 2018 at 12:48:26 PM UTC+3:30, dc0d wrote

[go-nuts] Difficulties Using golang.org/x/net/html

How to parse custom (nested) elements using golang.org/x/net/html? It parses the custom element correctly but if there are nested custom elements, the next siblings are parsed as children of the parent custom element. https://play.golang.org/p/Iu4RP6qp60p the closing tag for another () should

Re: [go-nuts] Re: Nil Channels and Case Evaluation

You are right Alex. And seems I am wrong and it does not really matter that much and is not a fruitful topic. -- 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

Re: [go-nuts] Re: Nil Channels and Case Evaluation

d on a >> closed channel proceeds by causing a run-time panic. A send on a nil >> channel blocks forever. > > > https://golang.org/ref/spec#Send_statements > > So, yes. > > On Wed, Jan 24, 2018 at 8:43 PM, dc0d <kaveh.sh...@gmail.com > > wrote: > >&

Re: [go-nuts] Re: Nil Channels and Case Evaluation

> > If the channel is nil, there's nothing to lock. But also, there's no > sending happening. > So first the payload is computed and then the nil check happens? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

Re: [go-nuts] Re: Nil Channels and Case Evaluation

Is this applied when the channel is nil? Does select statement first lock the channel then check if it's nil? On Wednesday, January 24, 2018 at 6:07:50 PM UTC+3:30, Ian Lance Taylor wrote: > > On Tue, Jan 23, 2018 at 10:13 PM, dc0d <kaveh.sh...@gmail.com > > wrote: > >

[go-nuts] Re: Web Framework for Beginners

gobuffalo has a nice workflow (I've used it for two in-house apps). On Wednesday, January 24, 2018 at 5:20:05 PM UTC+3:30, pradam wrote: > > Hi Gophers, > > As for Newbie to Go.I am excited to learn a *web framework* but I > don't know where to start please help me out

Re: [go-nuts] Re: Nil Channels and Case Evaluation

> > -rob > > > On Wed, Jan 24, 2018 at 5:31 AM, Marvin Renich <mr...@renich.org > > wrote: > >> * dc0d <kaveh.sh...@gmail.com > [180123 08:45]: >> > Can anybody help me understand the reason? (It's in the spec. That's not >> > the reason) >>

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

Did not try that and changed that instance of this code. On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote: > > Have you tried out the behaviour on Go tip (or the go 1.10 beta)? > > On 23 Jan 2018 14:31, "Josh Humphries" > wrote: > > Roger, > I don't believe

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

Exactly. That's why I asked before why we are allowed to embed type aliases. It should be either not possible, or be properly handled by the type system (and tools). On Tuesday, January 23, 2018 at 6:02:54 PM UTC+3:30, Josh Humphries wrote: > > Roger, > I don't believe that patch will change

Re: [go-nuts] Re: Nil Channels and Case Evaluation

of side effects has no place inside the context of Go semantics. Go is an imperative programming language, like many other mainstream programming languages. On Tuesday, January 23, 2018 at 7:21:24 PM UTC+3:30, Jan Mercl wrote: > > On Tue, Jan 23, 2018 at 4:45 PM dc0d <kaveh.sh...@gmail.com &

Re: [go-nuts] Re: Nil Channels and Case Evaluation

In the sample you have provided, a send syntax is used. And considering that, (IMHO) f1() must be evaluated first. On Tuesday, January 23, 2018 at 6:13:08 PM UTC+3:30, Ian Lance Taylor wrote: > > On Tue, Jan 23, 2018 at 5:44 AM, dc0d <kaveh.sh...@gmail.com > > wrote: > >

[go-nuts] Re: Nil Channels and Case Evaluation

Can anybody help me understand the reason? (It's in the spec. That's not the reason) On Sunday, December 31, 2017 at 10:14:31 AM UTC+3:30, dc0d wrote: > > Assume there is this select statement: > > for { > select { > // ... > // ... >

[go-nuts] Re: Badger Write Performance

t; > > On Thursday, January 18, 2018 at 2:33:02 PM UTC-5, dc0d wrote: >> >> Badger write performance is a bit worse than boltdb. And badger suggests >> to batch writes. But so does boltdb. >> >> At the same time at badger's GitHub page it says it has high

[go-nuts] Re: JSON and Embedded Types (Aliases)

Then the main question would be why is it possible to embed type aliases? On Sunday, January 21, 2018 at 10:42:28 PM UTC+3:30, Kevin Malachowski wrote: > > Given the last playground post, I'd guess that the aliased type (i.e. > 'int' here) is being used for visibility rather than the alias's

[go-nuts] JSON and Embedded Types (Aliases)

Why embedded type aliases get ignored through JSON marshaling? For example, having: type Num = int type Count = int type Max = int type Test int type data struct { Num Count Max Test } The only embedded part that gets marshaled to JSON properly, is Test. -- You received this message

[go-nuts] Re: Badger Write Performance

t looks like the badger benchmarks from github.com/dgraph-io/badger-bench > do not sync. > > > On Thursday, January 18, 2018 at 1:33:02 PM UTC-6, dc0d wrote: >> >> Badger write performance is a bit worse than boltdb. And badger suggests >> to batch writes. But so does

[go-nuts] Badger Write Performance

Badger write performance is a bit worse than boltdb. And badger suggests to batch writes. But so does boltdb. At the same time at badger's GitHub page it says it has higher write performance compared to boltdb. Is there a sample of how to do high performance/throughput writes with badger? --

Re: [go-nuts] Nil Channels and Case Evaluation

Nothing is known beforehand indeed. That does not mean it's not possible to expect a certain semantic for a certain syntax beforehand. On Sunday, December 31, 2017 at 9:36:37 PM UTC+3:30, leaf...@gmail.com wrote: > > > How putting one channel inside the parameters has not any effect on the >

Re: [go-nuts] Nil Channels and Case Evaluation

the parameters has not any effect on the logic of that select statement. On Sunday, December 31, 2017 at 9:01:49 PM UTC+3:30, leaf...@gmail.com wrote: > > The point is, you will not know whether the caller send a nil or not. > > dc0d於 2018年1月1日星期一 UTC+8上午1時27分29秒寫道： >> >> I

Re: [go-nuts] Nil Channels and Case Evaluation

Or the (not only) other option is check for nil channels before entering the scope of select? -- 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

Re: [go-nuts] Nil Channels and Case Evaluation

Consider this: func first() bool { select {} } And inside another function/goroutine: func f() { var rcvd chan bool select { case rcvd <- first(): } } While rcvd is nil, this select statement (inside f) will block, forever. IMHO that's unexpected. -- You received this message because

Re: [go-nuts] Re: Nil Channels and Case Evaluation

Thanks leafbebop! Thanks Jan! I'm not convinced that, this might be a performance problem. Both actions happens anyway, so the total time would be the same. Also the function first() may block on it's own. So, the select statement might get blocked on a nil channel! That's bad! The only

Re: [go-nuts] Re: Nil Channels and Case Evaluation

Indeed everything works according to the specs. That is what is being questioned (the specs). > > This behavior for case clause of select statements have different semantics than case clause of switch statement. While the latter gets evaluated lazily (short circuited), the former gets

[go-nuts] Re: Nil Channels and Case Evaluation

Please read the first message in this thread. The first() function was *expected* to be ignored as in common sense, yet it gets evaluated. I am not wrong (or right), only making a point (maybe the point seems pointless) and I have read the specs. I am saying that this behavior was

[go-nuts] Re: Nil Channels and Case Evaluation

Indeed. But case clauses of a select statement evaluate all expressions even if the channel is nil, in which case it is ignored and it was expected for other expressions to not get evaluated (which is not the case). -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: Nil Channels and Case Evaluation

section: > https://golang.org/ref/spec#SendStmt > > "Both the channel and the *value expression are evaluated* before > communication begins" > > cheers, > silviu > > On Sunday, 31 December 2017 01:44:31 UTC-5, dc0d wrote: >> >> Assume there is this

[go-nuts] Nil Channels and Case Evaluation

Assume there is this select statement: for { select { // ... // ... case rcvd <- first(): } } The rcvd channel will be set to nil or a chan value, by it's own case or other cases. If the rcvd channel is nil, that case should have no effect. But even when rcvd channel is

[go-nuts] Having a Model Package

I've been reading the other day: "having a model package, is considered a code smell, in Go". 1 - Why? 2 - If so, what approach should be chosen? 3 - And how? (In Go code, Go features to employ, Patterns (small/big projects), etc) -- You received this message because you are subscribed to

Re: [go-nuts] go generate ignores files ignored for build

PM UTC+3:30, Jan Mercl wrote: > > On Thu, Dec 14, 2017 at 11:53 AM dc0d <kaveh.sh...@gmail.com > > wrote: > > > What is the reasoning for not executing //go:generate ... comments > inside a file, that is excluded from build by // +build ignore? > > 'ignore' is jus

[go-nuts] go generate ignores files ignored for build

What is the reasoning for not executing //go:generate ... comments inside a file, that is excluded from build by // +build ignore? -- 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,

Re: [go-nuts] Unused Variable Generates No Error

Thanks for the reply. Already done that: https://github.com/golang/go/issues/23116 On Wednesday, December 13, 2017 at 2:15:25 PM UTC+3:30, rog wrote: > > On 13 December 2017 at 09:13, Jan Mercl <0xj...@gmail.com > > wrote: > > On Wed, Dec 13, 2017 at 10:04 AM dc0d &

[go-nuts] Unused Variable Generates No Error

This code compiles and generates no errors. Why? func f(v interface{}) { switch x := v.(type) { } } -- 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

Re: [go-nuts] Re: Implement sub-commands using flag library

Thanks again Roger. I've applied those suggestions. -- 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,

Re: [go-nuts] Re: Implement sub-commands using flag library

r 2017 at 09:52, dc0d <kaveh.sh...@gmail.com > > wrote: > > Coming late, yet I've written a minimal package (which can be even just > > copied and paste or bundled) that uses only the flag package itself > without > > adding new types, just a single function. > &

Re: [go-nuts] Reading os.Stdin, Unbuffered

For example I want the program to exit, if any key has been pressed on keyboard. I can not find any way to skip the wait for a necessary split character (like '\n'). On Monday, November 27, 2017 at 6:36:35 PM UTC+3:30, Jan Mercl wrote: > > On Mon, Nov 27, 2017 at 4:00 PM dc0d <

[go-nuts] Reading os.Stdin, Unbuffered

Is there a way to read from `os.Stdin` in an unbuffered way? (Not waiting for a `\n` or anything). -- 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

[go-nuts] Re: Bulky (Payload) Structs in API

;. > > In the end -- you will either have some shared artifact or a translation > layer. I see no way of escaping it. > > + Egon > > On Monday, 13 November 2017 09:48:07 UTC+2, dc0d wrote: >> >> Thanks! >> >> That's what I do, though not happy

[go-nuts] Re: Bulky (Payload) Structs in API

still do not feel being confident that the approach is proper or not. On Monday, November 13, 2017 at 11:18:07 AM UTC+3:30, dc0d wrote: > > Thanks! > > That's what I do, though not happy with it. I had to write some helper > apps and scripts (I'm not fluent in playing

[go-nuts] Re: Bulky (Payload) Structs in API

l boundaries. > > https://play.golang.org/p/5LFw6U3yi6 > > But, can you show a real-world example to ground the conversation? > > + Egon > > On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote: >> >> It is a Go best practice to "accept interf

[go-nuts] Bulky (Payload) Structs in API

It is a Go best practice to "accept interfaces, return concrete types". Which helps greatly in implementing different architectures/designs (like Clean Architecture or the like). There are times that a package is used which returns fat structs (as the concrete type) - mostly POGO. Problem:

[go-nuts] Managing Dependencies (as in IoC) and Avoid Globals

There are Go packages that help with dependency injection, employing reflection. And other practices insist on passing everything as an argument, down the pipe; employing mostly factory methods. At the same time putting long-lived instances inside a context is not recommended - I like context

[go-nuts] Re: Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

Thanks! Seems to be the best solution. I just wanted to check what should be done; in such situations which that extra signaling about closing channel is undesirable. Actually since there is a timeout element too, here a method is used (func (p *Payload) WaitResult(timeout ...time.Duration)

[go-nuts] Re: Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

of a time.Ticker which will not get closed by the Stop() functions to prevent an incorrect notification. On Monday, October 30, 2017 at 11:22:16 AM UTC+3:30, dc0d wrote: > > Problem: After the completion of some task, the task issuer should be > informed about the completion/failure of the ta

[go-nuts] Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

Problem: After the completion of some task, the task issuer should be informed about the completion/failure of the task - like by using some struct { Result Result, Err error }. Question: Which mechanism is preferred: using channels or callbacks? Why the question: IMHO channels are the answer

Re: [go-nuts] Tiny FSM

ay essential information, and this > means we can interpret the free program in different ways, e.g, by adding > invariants, run the program either serially or parallel etc. Haskell > defines a "Free Monad" for this purpose. > > [0] http://okmij.org/ftp/tagless-final/index.html > &

Re: [go-nuts] Tiny FSM

Nice! At least I've not reinvented any wheel this time! Just rediscovered it! Thanks! On Sunday, September 24, 2017 at 12:43:51 PM UTC+3:30, Jan Mercl wrote: > > On Sun, Sep 24, 2017 at 11:07 AM dc0d <kaveh.sh...@gmail.com > > wrote: > > https://youtu.be/HxaD_trXwRE?t

[go-nuts] Tiny FSM

through future! - Sample usage here <https://gist.github.com/dc0d/f994f74dabf9854d8af30fa1e172046c>; Any feedback is most appreciated! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and st

[go-nuts] Why http header letter case changes?

It is true that http header keys are case-nonsensitive. Then why the letter case gets changed inside "*http.Response"? An "ETag" header added and in the response we had "Etag" (the letter T converted to lowercase). I've encountered this when doing some testing and this behavior was unpleasant

[go-nuts] Re: Calling Once (in the code)

Just for the record, today I really needed this so here is this <https://github.com/dc0d/glint> - primitive pkg, yet works for this purpose (mostly, and opinionated). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

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

That's a nice package with good design (and I've used it for a while). But I loose the info about where the error is happening. On Thursday, August 17, 2017 at 11:59:10 AM UTC+4:30, Peter Mogensen wrote: > > > > On 2017-08-17 09:24, dc0d wrote: > > Logging from a specific p

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

ogging initiative that was > on going? > Did I miss something about that? It seems very related to this. > > tors 17 aug. 2017 kl 09:10 skrev dc0d <kaveh.sh...@gmail.com > >: > >> As they say global variables/things are bad. But I even use a global >> Context a

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

Logging from a specific place in code helps with finding out *where* the error happened. And doing that manually is cumbersome. I for one can not give-up on this because it makes fixing things super fast. Fortunately current logging packages (like zap) take care of that case by providing the

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

> > Even better: my libraries expose only the LogFunc: i.e. > I am currently doing something similar; exposing an interface with four methods Error, Info, Errorf, Infof with a default logger that uses the built-in log, setup at init. Yet IMHO there is a need for a built-in package that allows

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

metrics (seems it can be)? On Monday, August 14, 2017 at 6:30:19 PM UTC+4:30, Peter Mogensen wrote: > > > > On 2017-08-14 11:04, dc0d wrote: > > That may be (still IMH-Experience in the majority of cases, this is the > > proper default to go). > > > >

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

g - it might be an error string, but it's not an error condition. > Only after bailing on handling an error should it stand out in an error > log. So I don't really agree with that approach, fine as it is. > > Just my 2¢. > > On Sun, Aug 13, 2017 at 8:59 PM, dc0d <kaveh.sh..

[go-nuts] Built-in log Package

(as in leveled loggers). If it's an error, it's an error. We could even have other types/interfaces that we could take proper action based on their type/interface much more flexible than just having 5 or 7 or 10 levels. This package <https://github.com/dc0d/logt> demonstrates this idea. All

[go-nuts] Re: Calling Once (in the code)

gths -- e.g. some people have better working memory and > some have better focus switching skills... I suspect this what leads some > people to prefer one style over the other. > > On Friday, 11 August 2017 22:12:09 UTC+3, dc0d wrote: >> >> Thanks for suggesting guru. I'll

[go-nuts] Re: Calling Once (in the code)

t; derive something from it. > > + Egon > > On Friday, 11 August 2017 10:39:16 UTC+3, dc0d wrote: >> >> "When you feel the need to write a comment, first try to refactor the >> code so that any comment becomes superfluous." >> - Martin Fowler, Kent Beck, John Br

[go-nuts] Re: Calling Once (in the code)

wrote: > > I am not aware of any such tools exist. You may need to roll out your own. > > However, don't you think that the purpose of Fowler,et al. proposing such > guideline is to encourage function reuse? > > On Friday, August 11, 2017 at 2:39:16 PM UTC+7, dc0d wrote: > &g

[go-nuts] Re: Calling Once (in the code)

> > On Friday, August 11, 2017 at 3:02:47 AM UTC+7, dc0d wrote: >> >> Is there a tool/linter to check if a private package function gets called >> exactly once *in the code*? (I'm not looking for a runtime solution like >> *sync.Once* but a code analysis tool/linter). &

Re: [go-nuts] Calling Once (in the code)

:04 AM UTC+4:30, Jan Mercl wrote: > > On Thu, Aug 10, 2017 at 10:03 PM dc0d <kaveh.sh...@gmail.com > > wrote: > > > Is there a tool/linter to check if a private package function gets > called exactly once in the code? > > Good luck with solving the halting pro

Re: [go-nuts] CGO & Plugins

Thanks for the post! I don't think those caveats could be a setback. Some clarifications on future of plugins would be nice though. On Saturday, June 3, 2017 at 6:32:22 PM UTC+4:30, Nick Groenen wrote: > > On 2017-06-02 19:24:40, Michael Brown wrote: > >Do you have any references on the

[go-nuts] CGO & Plugins

Assuming we have some *cgo* packages, is it fine to place them inside a plugin (added in Go 1.8)? It seems to ease deployment (on the same platform) and save some compilation time. But I'm not sure if it's safe to do so, mixing cgo & plugins. -- You received this message because you are

Re: [go-nuts] Proper Way of Defining a Custom Context

So just Value(...) then? Of-course I've implemented an adapter with no extra fields, just with some methods to work with Value(...). On Sunday, May 7, 2017 at 2:41:31 PM UTC+4:30, Peter Mogensen wrote: > > > > On 2017-05-07 11:58, dc0d wrote: > > What's the proper way of

[go-nuts] Proper Way of Defining a Custom Context

What's the proper way of defining a custom context? Is it enough to wrap the methods of parent `context.Context`? Is it fine to add fields and methods (we can type-assert later on, down the chain)? Or one should just use the `WithValue` and stores everything inside the context and handle them

[go-nuts] Pointer to Container Type

In Go there is no way to pass a reference to an instance of the container/enclosing type, to a function of an embedded type. What work around do you use for this? Any idiomatic Go way? Currently I model the shared functionality using an interface. Then the implementation is another struct,

[go-nuts] on gorm internals

Why in *gorm* source, callbacks get called via *CallMethod,* using *reflection*? And not by casting to an *interface* that has a callback method (say AfterFind)? I like to learn about the reasoning & it's implications. -- You received this message because you are subscribed to the Google

[go-nuts] Re: Use Specific json.Unmarshaler for a dynamic JSON

a direct field of the JSON, but maybe a field of a child JSON object). Token seems interesting! I'll look into it. On Tuesday, April 4, 2017 at 4:55:39 PM UTC+4:30, Egon wrote: > > What is the JSON input that you need to parse? > > + Egon > > On Tuesday, 4 April 2017 13:54:34

Re: [go-nuts] Supervisor Trees in Go

ion in Go. > > The rest_for_one strategy is the rarest one to be used. But it is hard to > implement with the other constructions, so it seems to be needed. > > > On Sat, Mar 11, 2017 at 2:32 PM dc0d <kaveh.sh...@gmail.com > > wrote: > >> Yes, this one is using

Re: [go-nuts] Supervisor Trees in Go

11 Mar 2017, at 09:19, dc0d <kaveh.sh...@gmail.com > > wrote: > > It just started as playing around recursive types in Go and ended up > writing this <https://github.com/dc0d/supervisor>. Though I could not > find a clean way ti implement rest_for_one strategy and error ha

[go-nuts] Supervisor Trees in Go

It just started as playing around recursive types in Go and ended up writing this <https://github.com/dc0d/supervisor>. Though I could not find a clean way ti implement rest_for_one strategy and error handling and simple_one_for_one is in TODO list; any feedback would be appreciated!

Re: [go-nuts] Put the CancelFunc inside Context

I was about to make a PR but saw in the tests that context is already being used as a closure and since I've been both wrong and do not have a convincing reasoning for this change, it seems things are working fine. On Monday, February 27, 2017 at 5:59:55 PM UTC+3:30, dc0d wrote: > > Acc

Re: [go-nuts] Put the CancelFunc inside Context

xt.Context) error)" instead of "func (g *Group) Go(f func() error)". On Monday, February 27, 2017 at 4:56:27 PM UTC+3:30, Ian Davis wrote: > > > On Mon, 27 Feb 2017, at 11:39 AM, dc0d wrote: > > Is there any drawbacks if we put the CancelFunc of a cancellable > cont

[go-nuts] Put the CancelFunc inside Context

Is there any drawbacks if we put the CancelFunc of a cancellable context.Context inside it's values? Problem: I needed a cross breed of WaitGroup and Context. So a WaitGroup and it's CancelFunc is put inside it's values and are used with some helper functions. I wrote a variant of WaitGroup -

Re: [go-nuts] Developing Microservices

ng) a microservices architecture. On Thursday, February 23, 2017 at 5:00:11 PM UTC+3:30, Nyah Check wrote: > > This should help: https://github.com/micro > > On Thu, Feb 23, 2017 at 2:17 PM, dc0d <kaveh.sh...@gmail.com > > wrote: > >> How do you develop a microservice

[go-nuts] Using the Plugin Feature in Go 1.8

Is the plugin feature in Go 1.8, production ready? Or is it experimental? On slack Andrei Tudor Călin led me to the list of current issues with plugins, which is somehow daunting. BTW even providing just

[go-nuts] Developing Microservices

How do you develop a microservice based (architecture) app? I have some scripts that are doing the building, starting and stopping and also running tests. But do you use any specific tools for developing microservices? - Env: Apps are communicating via NATS (& some HTTP), Go 1.8, Ubuntu 14.04

Re: [go-nuts] Single instance of program

Nice! Seems working! I could not get Unix Domain Socket to work, since I expected an error on Listen or Accept but there were no errors. On Wednesday, October 5, 2016 at 12:00:12 AM UTC+3:30, Ingo Oeser wrote: > > Are you looking for something like >

Re: [go-nuts] Single instance of program

I had the same question tonight! On Windows (using C#) I just create a Named Mutex, which is system wide. One of values that it returns identifies that if the mutex is already created by other instance, or it's the first time it's being created on this system. Is there something similar on

Re: [go-nuts] Initialize Fields

e zero type is, that it always is just zero-initialized > memory. > > On Sun, Oct 2, 2016 at 11:33 AM, dc0d <kaveh.sh...@gmail.com > > wrote: > >> Why there is no field initializer in Go? Like: >> >> type gate struct { >> outgoing = make(chan *send

[go-nuts] Initialize Fields

Why there is no field initializer in Go? Like: type gate struct { outgoing = make(chan *sendRequest) incoming = make(chan update, 10) } Doesn't that make zero value more useful? The syntax already exists for global variables so IMHO not much new would get introduced to the language

[go-nuts] How the main func started?

How to find out if the *main* function is started by executing the compiled binary or by *go run*? By examining *os.Args* it can be seen at the first case (running the app) we will have the *binary name* as the first argument without any path and when it is started using go run, we will have

  1   2   >