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

(like 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 > > wrote: > >> I'm looking forward to see this in official r

[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 l

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

ntial Processes was 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

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

[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

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

st that I 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 restrictin

[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 thi

[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(&o.done, 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" gr

[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

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

[go-nuts] Re: Safe Packages

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

[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 st

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

> > Andy > > On Jan 25, 2018, at 11:05 PM, dc0d > > wrote: > > 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 context="{ctx}" /> a properly closed one lik

[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

[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 go

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

. A send 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 > > wrote: > >> If the channel is n

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 and

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 > wrote: > > > > The third o

[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 by

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

ation. > > -rob > > > On Wed, Jan 24, 2018 at 5:31 AM, Marvin Renich > wrote: > >> * dc0d > [180123 08:45]: >> > Can anybody help me understand the reason? (It's in the spec. That's not >> > the reason) >> > >> > On Sund

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 that patch will change

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 beh

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

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 > > wrote: > &g

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 > > wrote: > > > > Can anybod

[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 { > // ... > // ... > > case r

[go-nuts] Re: Badger Write Performance

p your data. > > > > > > 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

[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 new

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

Playground <https://play.golang.org/p/N4zc2FiECYC>, output: {"Test":100}. On Sunday, January 21, 2018 at 9:42:39 AM UTC+3:30, dc0d wrote: > > Why embedded type aliases get ignored through JSON marshaling? > > For example, having: > > type Num = int > type Cou

[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 be

[go-nuts] Re: Badger Write Performance

boltdb?) > > It 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

[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 > lo

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

day, December 31, 2017 at 8:15:35 PM UTC+3:30, leaf...@gmail.com wrote: > > > > dc0d於 2017年12月31日星期日 UTC+8下午11時40分44秒寫道： >> >> Or the (not only) other option is check for nil channels before entering >> the scope of select? >> > > Change a little b

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 golang-nuts+unsubsc

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

A more complete code: package main import ( "log" "time" ) func main() { f() } func first() bool { select {} } func f() { // for demonstration purpose var rcvd chan bool = nil select { case rcvd <- first(): case <-time.After(time.Second): log.Println("timeout") } log.Println("d

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 y

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 reaso

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 evaluate

[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 *unexpected*

[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

this 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

[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 n

[go-nuts] Channels vs Callbacks in API

The statement being made here: a receive only channel, as a return value of a function, in an API, is not bad. Reasoning: - can not be closed - can not be set to nil - it's more clear than callbacks - if signaling is the desired behavior, callbacks for sure are the wrong choice

[go-nuts] Re: Having a Model Package

Thanks for the reply! (IMHO): I understand the "Why", suffering from it everyday! This specific case is not MVC, but a bot. In it's simplest form: New messages come it, and based on user_id, a new agent (goroutine) comes to life, initiated by previous user state and processes the message. As

[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 the

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

[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 golang-nuts

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, vi

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

> > > That won't work if you don't pass any flags! Indeed. The best approach is to check against default values. > > I'd suggest that only one command can be specified at any one time (all the command line apps that I know work like this). True. I'll fix that. > As far as I can see from a b

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

017 at 09:52, dc0d > > 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. > > I like the minima

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

Coming late, yet I've written a minimal package <https://github.com/dc0d/clarg> (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. On Wednesday, January 1, 2014 at 1:03:07 PM UTC+3:30, A

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

[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 golang-nuts+un

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

uot;generic-bot". > > 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,

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

because I 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

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

convert at call 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 "a

[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: Red

[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 fo

[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

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 task

[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 b

Re: [go-nuts] Tiny FSM

ions. They are not throwing away 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:/

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 > > wrote: > > https://youtu.be/HxaD_trXwRE?t=14m7s > > -- &g

[go-nuts] Tiny FSM

#x27;t see 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 gr

[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 unsub

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

e (instead of io.Writer). On Thursday, August 17, 2017 at 3:43:21 PM UTC+4:30, Christian Joergensen wrote: > > On Thursday, August 17, 2017 at 11:40:08 AM UTC+2, dc0d wrote: >> >> That's a nice package with good design (and I've used it for a while). >> But I loos

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

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

ole logging 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 > >: > >> As they say global variables/things are bad. But I even use a global >> Context and WaitGroup for signaling

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 op

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

As they say global variables/things are bad. But I even use a global Context and WaitGroup for signaling the termination of the whole program. On exit the context will get canceled and the program waits for the WaitGroup with a timeout. I would like to have those inside another built-in package

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). > > > > But the

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

> in my log - 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 P

[go-nuts] Built-in log Package

to me (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

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

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

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

to > 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, J

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

Henry 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 wrot

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

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

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 > > 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 problem ;-) > > -- >

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

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). Purpose: A guideline on commenting code by Martin Fowler states that before writing a comment, see if

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 stabili

[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 subsc

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 pro

[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 u

Re: [go-nuts] Pointer to Container Type

n image might belong to some person in one context but not in another context (abstracted away inside the implementation struct and shared functionality). On Thursday, April 20, 2017 at 1:13:11 AM UTC+4:30, Ian Lance Taylor wrote: > > On Wed, Apr 19, 2017 at 1:35 PM, dc0d > > wrote

[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, whic

[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 Group

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

ily 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 201

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

Target: Assuming we want to deserialize some JSON dynamically and we want to unmarshal some fields using specific unmarshaling code (a certain UnmarshalJSON). The problem is using something like map[string]interface{} there is no way to specify that. Thought Experiment: I like to have something

Re: [go-nuts] Supervisor Trees in Go

rocesses, or of > goroutines. Chances are it is a less useful construction 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 >

  1   2   >