[go-nuts] Badger Write Performance

[dc0d]

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?

-- 
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: Badger Write Performance

[dc0d]

In docs for boltdb it is stated that NoSync should be used very carefully 
because it can leave the database in an inconsistent state.

If a full fledged distributed database was the case, a no-sync manner would 
be acceptable. But for an embedded database, it is not a plus (to be 
performant in no-sync mode, assuming that mode would not leave database in 
an inconsistent state, in case of a dirty shutdown of the app or the 
machine).

On Saturday, January 20, 2018 at 3:56:10 PM UTC+3:30, Jordan Krage wrote:
>
> Are you using 'SyncWrites=false'? (Or 'NoSync' with 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 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?
>>
>

-- 
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] JSON and Embedded Types (Aliases)

[dc0d]

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 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: JSON and Embedded Types (Aliases)

[dc0d]

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 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 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: JSON and Embedded Types (Aliases)

[dc0d]

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 name.
>
> It's also a little weird to use embedded types that dont need to be 
> (there's no method promotion here because 'int' has no methods), or seeing 
> aliases to primitive types. Do you need to do both of those things?
>

-- 
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: Badger Write Performance

[dc0d]

I've followed badger since it's beta and the discussions it emitted. Those 
"lines" and discussions, alongside it's history, do not provide the most 
happy influence that one would hope for.

On Sunday, January 21, 2018 at 7:51:52 PM UTC+3:30, Diego Medina wrote:
>
> The use of SyncWrites=false on badger's benchmark was called out on reddit 
> and the benchmark author's reply was along the lines of "it's ok for our 
> use case to lose the last few [seconds|ms] of data"
>
> You draw your conclusion on where you want to keep 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'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?
>>
>

-- 
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: Nil Channels and Case Evaluation

[dc0d]

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 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 nil, the first() function will be called.
>
> I did not expect that. Why is that so?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 anybody help me understand the reason? (It's in the spec. That's not 
> the 
> > reason) 
>
> It gives a precise order of evaluation of the select statement.  Consider 
> case f1() <- f2(): 
> It's useful to specify the order in which f1 and f2 are evaluated. 
> The spec says that f2 is evaluated first.  If we don't evaluate f2 for 
> nil cases, then we would have to evaluate f1 first.  Either choice 
> could work.  The spec makes a specific choice.  I happen to think it 
> is the least confusing choice, but I can understand if others 
> disagree. 
>
> Ian 
>
>
>
> > On Sunday, December 31, 2017 at 10:14:31 AM UTC+3:30, dc0d wrote: 
> >> 
> >> 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 nil, the first() function will be called. 
> >> 
> >> I did not expect that. Why is that so? 
> > 
> > -- 
> > 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] Re: Nil Channels and Case Evaluation

[dc0d]

1 - The case clause clearly represents a send action.
2 - So there must be a channel to send to, and f1() must return a channel.
3 - If that channel (returned by f1()) is nil, then the clause must get 
ignored.
4 - If the returned channel (returned by f1()) is not nil, then f2() will 
be executed.
5 - The returned value of f2() will be sent to channel returned by f1()

Any unexpected side effects caused by either f1() or f2() are not relevant 
in the context of the above workflow.

And since Go has not any specific semantics regarding side effects (like 
Haskell or Elixir), the problem 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 > 
> wrote:
>
> > In the sample you have provided, a send syntax is used. And considering 
> that, (IMHO) f1() must be evaluated first.
>
> Consider f1() is a dispatcher. If it is to be evaluated first then it may 
> create and return a new channel that will not be used. Or consider if f1() 
> has a side effect of incrementing some send counter.
>
> I don't think asking a function to return a channel to send a value to, 
> while possibly later figuring out there's nothing available to send, is a 
> good idea.
>
>
>
> -- 
>
> -j
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 behavior. See my last message: the 
> fields appear to be unexported according to reflection.
>
> That patch has the encoding/json package checking StructField.PkgPath, 
> which should be blank for exported fields. For these fields, it is 
> "go.builtin", which appears to be a pseudo-package name for builtins 
> (interestingly, it's not just "builtin" which is what Go doc would lead one 
> to expect). That means it will behave the same and skip the three fields in 
> question.
>
>  This is non-intuitive based on the language spec, since the field names 
> are upper-cased. I think this is either a bug in reflect -- which should 
> set StructField.PkgPath to "" since the field name is exported -- OR a bug 
> in the compiler which should complain that there are three fields whose 
> resolved name appears to be the unexported identifier "int".
>
>
> 
>
> Josh Humphries
>
> FullStory   |  Atlanta, GA
>
> Software Engineer
>
> j...@fullstory.com 
>
> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  > wrote:
>
>> This is a bug that has been fixed on Go tip by
>> https://go-review.googlesource.com/c/go/+/65550.
>>
>>
>> On 23 January 2018 at 00:45, Josh Humphries > > wrote:
>> > I think have misspoken. Even though the field's name appears exported 
>> via
>> > reflection (it has a name that starts with a capital letter), 
>> attempting to
>> > use the reflect.Value's SetInt method panics, indicating that the field 
>> was
>> > obtained using an unexported field. So the encoding/json package is thus
>> > consistent with that in that it ignores unexported fields.
>> >
>> > It is still not obvious from the spec what should be happening. I would
>> > expect it to be exported due to the resolved field name. But if it is
>> > unexported because the compiler resolves the alias first, then I would
>> > expect a compiler error because the four fields all resolve to the same
>> > name. The spec states this is not allowed:
>> >
>> > The following declaration is illegal because field names must be unique 
>> in a
>> > struct type:
>> >
>> > struct {
>> >   T // conflicts with embedded field *T and *P.T
>> >   *T// conflicts with embedded field T and *P.T
>> >   *P.T  // conflicts with embedded field T and *T
>> > }
>> >
>> > So it is possible that this is not a bug in the encoding/json package 
>> but in
>> > the compiler.
>> >
>> > 
>> > Josh Humphries
>> > jh...@bluegosling.com 
>> >
>> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries > >
>> > wrote:
>> >>
>> >> I think that is expected, and it is the JSON marshaling that is 
>> surprising
>> >> (and erroneous).
>> >>
>> >> If it were expected that the embed field names resolved to the alias
>> >> target type name, it would instead be a compiler error since the 
>> compiler
>> >> does not allow embedded types that would result in name collisions. 
>> Using
>> >> reflection, one can see the fields are named just as in your example, 
>> after
>> >> the type aliases, not its underlying type name. The bug is that JSON
>> >> marshaling is not looking at the field name and instead looking 
>> directly at
>> >> the field type name (which, in this case, has been resolved to int).
>> >>
>> >> 
>> >> Josh Humphries
>> >> jh...@bluegosling.com 
>> >>
>> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
>> >> > wrote:
>> >>>
>> >>> This is sort of surprising though: 
>> https://play.golang.org/p/mjfkzIqAo_b
>> >>>
>> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>> >>> > From the Language Specification -
>> >>> >
>> >>> > A field declared with a type but no explicit field name is called an
>> >>> > *embedded
>> >>> > field*. An embedded field must be specified as a type name T or as a
>> >>> > pointer to a non-interface type name *T, and T itself may not be a
>> >>> > pointer
>> >>> > type. The unqualified type name acts as the field name.
>> >>> >
>> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>> >>> > *P.T4
>> >>> > struct {
>> >>> > T1// field name is T1
>> >>> > *T2   // field name is T2
>> >>> > P.T3  // field name is T3
>> >>> > *P.T4 // field name is T4
>> >>> > x, y int  // field names are x and y
>> >>> > }
>> >>> >
>> >>> >
>> >>> > From the encoding/json#Marshal documentation -
>> >>> >
>> >>> > Struct values encode as JSON objects. Each exported struct field
>> >>> > becomes a
>> >>> > member of the object, using the field name as the object key, unless
>> >>> > the
>> >>> > field is omitted for one of the reasons given below.
>> >>> >
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google 
>> Gr

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

[dc0d]

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 behavior. See my last message: the 
> fields appear to be unexported according to reflection.
>
> That patch has the encoding/json package checking StructField.PkgPath, 
> which should be blank for exported fields. For these fields, it is 
> "go.builtin", which appears to be a pseudo-package name for builtins 
> (interestingly, it's not just "builtin" which is what Go doc would lead one 
> to expect). That means it will behave the same and skip the three fields in 
> question.
>
>  This is non-intuitive based on the language spec, since the field names 
> are upper-cased. I think this is either a bug in reflect -- which should 
> set StructField.PkgPath to "" since the field name is exported -- OR a bug 
> in the compiler which should complain that there are three fields whose 
> resolved name appears to be the unexported identifier "int".
>
>
> 
>
> Josh Humphries
>
> FullStory   |  Atlanta, GA
>
> Software Engineer
>
> j...@fullstory.com 
>
> On Tue, Jan 23, 2018 at 3:44 AM, roger peppe  > wrote:
>
>> This is a bug that has been fixed on Go tip by
>> https://go-review.googlesource.com/c/go/+/65550.
>>
>>
>> On 23 January 2018 at 00:45, Josh Humphries > > wrote:
>> > I think have misspoken. Even though the field's name appears exported 
>> via
>> > reflection (it has a name that starts with a capital letter), 
>> attempting to
>> > use the reflect.Value's SetInt method panics, indicating that the field 
>> was
>> > obtained using an unexported field. So the encoding/json package is thus
>> > consistent with that in that it ignores unexported fields.
>> >
>> > It is still not obvious from the spec what should be happening. I would
>> > expect it to be exported due to the resolved field name. But if it is
>> > unexported because the compiler resolves the alias first, then I would
>> > expect a compiler error because the four fields all resolve to the same
>> > name. The spec states this is not allowed:
>> >
>> > The following declaration is illegal because field names must be unique 
>> in a
>> > struct type:
>> >
>> > struct {
>> >   T // conflicts with embedded field *T and *P.T
>> >   *T// conflicts with embedded field T and *P.T
>> >   *P.T  // conflicts with embedded field T and *T
>> > }
>> >
>> > So it is possible that this is not a bug in the encoding/json package 
>> but in
>> > the compiler.
>> >
>> > 
>> > Josh Humphries
>> > jh...@bluegosling.com 
>> >
>> > On Mon, Jan 22, 2018 at 7:28 PM, Josh Humphries > >
>> > wrote:
>> >>
>> >> I think that is expected, and it is the JSON marshaling that is 
>> surprising
>> >> (and erroneous).
>> >>
>> >> If it were expected that the embed field names resolved to the alias
>> >> target type name, it would instead be a compiler error since the 
>> compiler
>> >> does not allow embedded types that would result in name collisions. 
>> Using
>> >> reflection, one can see the fields are named just as in your example, 
>> after
>> >> the type aliases, not its underlying type name. The bug is that JSON
>> >> marshaling is not looking at the field name and instead looking 
>> directly at
>> >> the field type name (which, in this case, has been resolved to int).
>> >>
>> >> 
>> >> Josh Humphries
>> >> jh...@bluegosling.com 
>> >>
>> >> On Mon, Jan 22, 2018 at 5:58 PM, Dan Kortschak
>> >> > wrote:
>> >>>
>> >>> This is sort of surprising though: 
>> https://play.golang.org/p/mjfkzIqAo_b
>> >>>
>> >>> On Mon, 2018-01-22 at 10:20 -0800, C Banning wrote:
>> >>> > From the Language Specification -
>> >>> >
>> >>> > A field declared with a type but no explicit field name is called an
>> >>> > *embedded
>> >>> > field*. An embedded field must be specified as a type name T or as a
>> >>> > pointer to a non-interface type name *T, and T itself may not be a
>> >>> > pointer
>> >>> > type. The unqualified type name acts as the field name.
>> >>> >
>> >>> > // A struct with four embedded fields of types T1, *T2, P.T3 and
>> >>> > *P.T4
>> >>> > struct {
>> >>> > T1// field name is T1
>> >>> > *T2   // field name is T2
>> >>> > P.T3  // field name is T3
>> >>> > *P.T4 // field name is T4
>> >>> > x, y int  // field names are x and y
>> >>> > }
>> >>> >
>> >>> >
>> >>> > From the encoding/json#Marshal documentation -
>> >>> >
>> >>> > Struct values encode as JSON objects. Each exported struct field
>> >>> > becomes a
>> >>> > member of the object, using the field name as the object key, unless
>> >>> > the
>> >>> > field is omitted for one of the reasons given below.
>> >>> >
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google 
>>

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

[dc0d]

The third option was the expected one. Locking aside (as the thought line 
behind the original question), the time spent on preparing/calculating a 
result value to be sent to a channel, is not directly relevant to the case 
for nil channels - which were expected to get ignored. I do not understand 
the internals of select statement and did not know it locks the channel.

Thanks for the reply.

On Tuesday, January 23, 2018 at 11:42:17 PM UTC+3:30, Rob 'Commander' Pike 
wrote:
>
> Marvin: That's pretty much the thinking behind the design. Thanks for the 
> clear explanation.
>
> -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 Sunday, December 31, 2017 at 10:14:31 AM UTC+3:30, dc0d wrote:
>> > >
>> > > 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 nil, the first() function will be called.
>> > >
>> > > I did not expect that. Why is that so?
>>
>> There are several candidate designs for this.  Here is my analysis of
>> the choices that I think are most worthy of consideration:
>>
>> 1.  (The current spec)  Evaluate all channel operands (send and receive)
>> and all expressions for values to be sent.  Choose one of the
>> communication operations that is ready to proceed and do it.
>>
>> 2.  Evaluate all channel operands.  For all non-nil send channels,
>> evaluate all expressions for values to be sent.  Choose one of the
>> communication operations that is ready to proceed and do it.
>>
>> 3.  Evaluate all channel operands.  Choose one of the communication
>> operations that is ready to proceed.  If it is a send operation, now
>> evaluate its value expression.  Perform the operation.
>>
>> It is unclear to me whether you were expecting (2) or (3), but I don't
>> like either of these.
>>
>> I do not like (2) because it is not determinable until execution of the
>> select statement which expressions for send operations will be executed.
>> Some values that will not be sent may be evaluated even though they will
>> not be used, while others might not be evaluated.  This can vary from
>> one execution of the select statement to another within the same
>> invocation of the program.
>>
>> I do not like (3) because, in order to ensure that the communication
>> operation that was chosen is still ready to proceed after evaluating its
>> value to be sent, the channel must be locked during evaluation of the
>> value, blocking other go routines that try to use the channel.  This
>> might take any amount of time (e.g. tens of minutes, or even hours).
>> This goes completely against the design principles and goals of
>> channels.
>>
>> Thus (1) is the clear winner.  Did I miss the design that you were
>> expecting?
>>
>> ...Marvin
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Web Framework for Beginners

[dc0d]

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 suggesting a good framework 
> for beginners.
>
> thank you,
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 option was the expected one. Locking aside (as the thought 
> line 
> > behind the original question), the time spent on preparing/calculating a 
> > result value to be sent to a channel, is not directly relevant to the 
> case 
> > for nil channels - which were expected to get ignored. I do not 
> understand 
> > the internals of select statement and did not know it locks the channel. 
>
> Regardless of internal details, conceptually it has to lock the 
> channel.  The select statement has to atomically 1) decide that the 
> channel has room for a new value; 2) send the new value to the 
> channel.  There could be many goroutines sending to the channel 
> simultaneously.  If the select statement picks the channel first and 
> then computes the value to send, then it has to ensure that no other 
> goroutine can send to the channel while computing the value, as 
> otherwise once it has the value it might not be able to send it. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

>
> 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 stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

It is as described in the spec. Regarding the specs it's correct. But 
that's not the reason. 

The original question is about the "why".

Why is that so? This behavior was unexpected.

On Wednesday, January 24, 2018 at 11:20:01 PM UTC+3:30, Axel Wagner wrote:
>
> Both the channel and the value expression are evaluated before 
>> communication begins. Communication blocks until the send can proceed. A 
>> send on an unbuffered channel can proceed if a receiver is ready. A send on 
>> a buffered channel can proceed if there is room in the buffer. 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 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 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] Re: Nil Channels and Case Evaluation

[dc0d]

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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 be before span.

-- 
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: Difficulties Using golang.org/x/net/html

[dc0d]

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:
>
> 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 be before span.
>

-- 
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] Difficulties Using golang.org/x/net/html

[dc0d]

Thanks Andy! I'll try read the spec to learn more.

On Friday, January 26, 2018 at 7:29:47 PM UTC+3:30, Andy Balholm wrote:
>
> The prescription is correct; the diagnosis is close but not exactly right.
>
> The html package actually doesn’t pay any attention to the XML-style 
> self-closing tag syntax. It accepts it, in accordance with the HTML5 spec, 
> as an alternate style of opening tag, but it never closes an element just 
> because of the final slash. The only elements that are automatically closed 
> are those that are always automatically closed, like .
>
> 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 like  context="{ctx}"> 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:
>>
>> 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 be before span.
>>
>
> -- 
> 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] Safe Packages

[dc0d]

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 still can behave in a malicious manner by (for 
example) creating too many goroutines.

This came to mind when I was reading about package managers and learnt some 
problems that they have. 

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

[dc0d]

Only in the context of imported packages and only in terms of causing 
side-effects "outside" the context of current executable binary.


On Monday, February 12, 2018 at 11:19:13 PM UTC+3:30, Paul Brousseau wrote:
>
> I think that might depend on what qualities you 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 "net/url" can it considered as safe? 
>> Since it does not (can not) modify the environment (most notably executing 
>> code)?
>>
>> Of course the package still can behave in a malicious manner by (for 
>> example) creating too many goroutines.
>>
>> This came to mind when I was reading about package managers and learnt 
>> some problems that they have. 
>>
>

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

[dc0d]

Awesome!

(IMHO) 

Going for total immutability is not a best fit for Go. I was thinking like 
excluding packages like unsafe, reflect, executing external programs and 
the like.

Capabilities seems unnecessarily complicated - getting used to them is not 
easy, like in Pony/ponylang.

Thanks 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:
>>
>> 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 still can behave in a malicious manner by (for 
>> example) creating too many goroutines.
>>
>> This came to mind when I was reading about package managers and learnt 
>> some problems that they have. 
>>
>

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

[dc0d]

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 like unsafe, reflect, executing external programs and 
> the like.
>
> Capabilities seems unnecessarily complicated - getting used to them is not 
> easy, like in Pony/ponylang.
>
> Thanks 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:
>>>
>>> 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 still can behave in a malicious manner by (for 
>>> example) creating too many goroutines.
>>>
>>> This came to mind when I was reading about package managers and learnt 
>>> some problems that they have. 
>>>
>>

-- 
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] All Forms of Wishful Generics

[dc0d]

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" 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: All Forms of Wishful Generics

[dc0d]

“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/dc0d/goreuse> is a tool to write generic 
code in Go, employing code generation (that I wrote) - not waiting for day 
dreams to come true and instead get done with the job.

This was just some thought sharing.

Especially the last two form - the generic Method Expression and the 
interface one - if they be a single-type-parameter type of generics, are 
interesting to investigate.

Like if we could write:

type method func (*) append(n int, m anotherConcreteType, prev *)



type comparer interface {
 (*) compare(*)
}

None of these mean that Go has to change - while it might, a bit - but 
brain teasers.

On Friday, February 16, 2018 at 3:45:33 PM UTC+3:30, M P r a d e s wrote:
>
> Have a look at Rust, Ada or even C++, they all have some form of generic 
> programming and are fast or faster than Go. Bonus, none of these use 
> garbage collection.
>
> Don't hold your breath with Go getting any substantial changes in its type 
> system. Move on. 
>
> Developers should use tools that suit them, not tools that force 
> developers to adapt them. 
>

-- 
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] Implementation of sync.Once

[dc0d]

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 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 of sync.Once

[dc0d]

Thanks!

Note To Self (or anyone whom may find it useful): Since sync.Once is 
usually used for doing initialization, it matters that the consecutive 
calls wait until the first call to f() gets completed. With provided 
implementation in the first post, there is no such guarantee.

On Friday, 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 this implementation? 
>>
>> type Once struct {
>>  done uint32
>> }
>>
>>
>> func (o *Once) Do(f func()) {
>>  if !atomic.CompareAndSwapUint32(&o.done, 0, 1) {
>>  return
>>  }
>>  f()
>> }
>>
>>
>
> You implementation returns immediately, if f() is still running, while in 
> original implementation all concurrent calls to Do() returns when f() 
> return.
>
> Djadala
>
>  
>

-- 
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: All Forms of Wishful Generics

[dc0d]

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 things too, that I would like to have in Go; like a faster 
FFI/CGO, or safe packages by restricting features so that a Go package 
cannot harm the hosting machine or application, like Safe Tcl 
. A list of those things is available 
here 

.

On Saturday, February 17, 2018 at 6:10:44 AM UTC+3:30, Dave Cheney wrote:
>
> I certainly don’t want what happened to C++ to happen to Go. If it’s a 
> choice between obsolescence or being crushed under the weight of self 
> inflicted complexity, I’ll gladly vote with my feet for the former. 

-- 
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: All Forms of Wishful Generics

[dc0d]

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 

.

For block level generics - as suggested at the first post - there might be 
some substantial changes needed to be made to the language - except for the 
last form: Interface Receivers with Original Types, which allows to not 
touch current Go code bases.

All in all Go is a fantastic tool with it's own merits.

On Saturday, February 17, 2018 at 6:25:58 AM UTC+3:30, Mandolyte wrote:
>
> I think this falls into a variation of package level generics.
>
> Look over the document below and see if there is any changes you would 
> recommend.
>
>
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit?usp=drivesdk
>
> Thanks for sharing!
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

Lars,

That's nice! Yet it's a sandboxed execution context. The Safe Packages 
mentioned above are just Go packages, with source code.

And when the day comes for a proper dependency manager, I would like to be 
able to tell the DM fail on import any unsafe packages - except for a list 
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 restricting features so that a Go package 
> > cannot harm the hosting machine or application, like Safe Tcl 
>
> Go already has a NaCl backend which might fit the bill. See 
> misc/nacl/README for how to set it up. It links to a design document 
> (https://golang.org/s/go13nacl) with some background. 
>

-- 
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: All Forms of Wishful Generics

[dc0d]

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

RickyS,

The success of Go in the field of application development (besides it's 
success in the devops and infrastructure sector) was unexpected - as Rob 
Pike himself stated, they expected to attract C and C++ developers and 
instead they've got developers from Python and .NET and other PLs that are 
mostly used for application development.

Having that in mind, Go must adopt. It does not have to be an adoption in 
terms of syntax. It might at some point. But - in my experience - the far 
more important factors that can affect this and push the adoption further, 
are 1) the expansion of tools and workflow and 2) the cultural roadmaps, 
which if handled in a pragmatic and realistic way, can bear fruit beyond 
initial any anticipation made by now.

There is something amiss in the current situation with Go. While the Go 
team are doing their best (they are the best after all), other things can 
get improved in far more effective ways by a coherent community which cares 
about quality and staying real to real world problems most.

On Monday, February 19, 2018 at 2:25:54 PM UTC+3:30, Doğan Kurt wrote:
>
> Generics would divide the Go community.
>
> I would probably never use it, like many people who comes to Go from C. 
> People who are already experienced Go programmers also likely to avoid it. 
> Java programmers on the other hand will surely overuse it.
>
> There it is, you have two different Go code bases that looks nothing like 
> each others. One uses Generics and the other does not. Nobody wants Go to 
> have the same fate as C++. We love how there is only one way to accomplish 
> something in Go.
>
> There are billions of lines of code written in Go. Nobody would happily 
> transform all those working codes just to use new idiomatic Go with 
> generics. I suspect even Go team would hesitate to transform all the 
> standard library.
>
> 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:
>>
>>
>> <https://lh3.googleusercontent.com/-0MymimUkuVw/WoZ4cB5KaxI/KA8/tqVeo41vDeQej_R9CmhQP73lKNREEAycgCLcBGAs/s1600/block-level-generics-3.png>
>>
>>

-- 
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: All Forms of Wishful Generics

[dc0d]

This <https://www.youtube.com/watch?v=Sg4U4r_AgJU&feature=youtu.be> is a 
great talk on designing PLs, by Brian Kernighan in which he describes (too) 
how Perl stops being relevant by providing too little, too late.

Again, improvements can be made in term of things other than just the 
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).
>
> RickyS,
>
> The success of Go in the field of application development (besides it's 
> success in the devops and infrastructure sector) was unexpected - as Rob 
> Pike himself stated, they expected to attract C and C++ developers and 
> instead they've got developers from Python and .NET and other PLs that are 
> mostly used for application development.
>
> Having that in mind, Go must adopt. It does not have to be an adoption in 
> terms of syntax. It might at some point. But - in my experience - the far 
> more important factors that can affect this and push the adoption further, 
> are 1) the expansion of tools and workflow and 2) the cultural roadmaps, 
> which if handled in a pragmatic and realistic way, can bear fruit beyond 
> initial any anticipation made by now.
>
> There is something amiss in the current situation with Go. While the Go 
> team are doing their best (they are the best after all), other things can 
> get improved in far more effective ways by a coherent community which cares 
> about quality and staying real to real world problems most.
>
> On Monday, February 19, 2018 at 2:25:54 PM UTC+3:30, Doğan Kurt wrote:
>>
>> Generics would divide the Go community.
>>
>> I would probably never use it, like many people who comes to Go from C. 
>> People who are already experienced Go programmers also likely to avoid it. 
>> Java programmers on the other hand will surely overuse it.
>>
>> There it is, you have two different Go code bases that looks nothing like 
>> each others. One uses Generics and the other does not. Nobody wants Go to 
>> have the same fate as C++. We love how there is only one way to accomplish 
>> something in Go.
>>
>> There are billions of lines of code written in Go. Nobody would happily 
>> transform all those working codes just to use new idiomatic Go with 
>> generics. I suspect even Go team would hesitate to transform all the 
>> standard library.
>>
>> 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:
>>>
>>>
>>> <https://lh3.googleusercontent.com/-0MymimUkuVw/WoZ4cB5KaxI/KA8/tqVeo41vDeQej_R9CmhQP73lKNREEAycgCLcBGAs/s1600/block-level-generics-3.png>
>>>
>>>

-- 
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: All Forms of Wishful Generics

[dc0d]

Yeah! And since I've learnt English mostly from SciFi and Fantasy movie 
heroes (with a misplaced sense of self-righteousness), I make boo boos from 
time to time - which are not that harmful and entertain people! :)

There are other things that I might be interested to be improved about Go 
(MO-Oriented improvements which MO-Oriented tweaks about the syntax are 
just a small part of it). But as for this thread seems the discussion made 
it's way to a level that needs some more time to manifest itself as 
conclusions - if it meant to be any at all.

And I'm positive Go will continue to grow and get better at things.

On Monday, February 19, 2018 at 3:03:18 PM UTC+3:30, RickyS wrote:
>
>
>1. Oh, I'm all for improvement. I just want somebody to invent 
>something in the field of re-use that is as much a breakthrough as 
>Cooperating Sequential 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 at 1:17:22 PM UTC+2, dc0d wrote:
>>
>>  ...Go must adopt.  ...
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 looks like a minor change in import syntax and might bring in 
some security concerns: being able to use env-vars in imports: import 
"$MY_OTHER_PKG".
- I love managing major versions in git by having different branches for 
major versions because it makes patching fixes much more logical and 
cleaner. It would be great to be able to perform go get based on branch 
name too - the concept is common in major source controls of today.


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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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:
>
> - Have a mechanism for safe dependency packages (as in Safe-Tcl 
> <https://en.wikipedia.org/wiki/Tcl#Safe-Tcl> - this implies it would be 
> possible to have meta-data other than versions for packages, too).
> - This one looks like a minor change in import syntax and might bring in 
> some security concerns: being able to use env-vars in imports: import 
> "$MY_OTHER_PKG".
> - I love managing major versions in git by having different branches for 
> major versions because it makes patching fixes much more logical and 
> cleaner. It would be great to be able to perform go get based on branch 
> name too - the concept is common in major source controls of today.
>
>
> On Tuesday, February 20, 2018 at 8:50:54 PM UTC+3:30, Russ Cox wrote:
>>
>> Hi everyone,
>>
>> I have a new blog post you might be interested in.
>> https://research.swtch.com/vgo.
>>
>> I'll try to watch this thread to answer any questions.
>>
>> Best,
>> Russ
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

Thanks Axel,

You are right about env-vars and as I've noted, there might be security 
concerns. The main goal here was to represent an idea for the source of the 
import. It can be the module descriptor of vgo.

And the first idea is about having packages that does not harm the 
environment (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 releases too!
>>
>> Also I would like to:
>>
>> - Have a mechanism for safe dependency packages (as in Safe-Tcl 
>> <https://en.wikipedia.org/wiki/Tcl#Safe-Tcl> - this implies it would be 
>> possible to have meta-data other than versions for packages, too).
>> - This one looks like a minor change in import syntax and might bring in 
>> some security concerns: being able to use env-vars in imports: import 
>> "$MY_OTHER_PKG".
>>
>
> Please don't. This is the antithesis to what vgo is trying to do. vgo 
> tries very hard to marry reproducible builds with simplicity. Having 
> environment variables determine what gets built destroys that completely.
>
> The occasional edge-case that might benefit from this should write their 
> own tool which generates an appropriate package.
>

-- 
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] Shuffle Items in a Slice

[dc0d]

Hi;

To shuffle items in a slice I'm doing this:

var res []Item

//fill res logic

shuffle := make(map[int]*Item)
for k, v := range res {
 shuffle[k] = &v
}
res = nil
for _, v := range shuffle {
 res = append(res, *v)
}

Which inserts items into a map then ranges over that map. Ranging over a 
map in Go returns the items in random order.

1 - I thought it's a cool trick!
2 - Is anything bad about doing this?

-- 
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] Shuffle Items in a Slice

[dc0d]

Please explain what other properties are you referring to?

I'm using this to choose from a list of tickets/tokens from database to 
reduce contention (CouchDB). So being cryptographic is not a concern here 
but rather being fast.

And if I'm not mistaken package rand uses a mutex internally - I thing that 
can be ignored compared to other tasks at hand (IO, db, disk) though; and 
thanks for mentioning Perm! Yet again you can range over a map concurrently 
in a read-only manner - randomized for free!

I've not tried/take a look at crypto/rand yet.

On Friday, June 24, 2016 at 4:16:47 PM UTC+4:30, Jan Mercl wrote:
>
> map ranging randomization has to be fast - at the cost of the 
> randomization other properties. Use instead perhaps 
> https://golang.org/pkg/math/rand/#Rand.Perm to get a random slice of 
> indexes of a proper length. Later range that slice instead and indirectly 
> use the original slice item at the particular index fetched from the first 
> slice.
>
> On Fri, Jun 24, 2016, 13:05 dc0d > 
> wrote:
>
>> Hi;
>>
>> To shuffle items in a slice I'm doing this:
>>
>> var res []Item
>>
>> //fill res logic
>>
>> shuffle := make(map[int]*Item)
>> for k, v := range res {
>>  shuffle[k] = &v
>> }
>> res = nil
>> for _, v := range shuffle {
>>  res = append(res, *v)
>> }
>>
>> Which inserts items into a map then ranges over that map. Ranging over a 
>> map in Go returns the items in random order.
>>
>> 1 - I thought it's a cool trick!
>> 2 - Is anything bad about doing this?
>>
>> -- 
>> 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.
>>
> -- 
>
> -j
>

-- 
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] Shuffle Items in a Slice

[dc0d]

Thanks Val for explanation & clarification;

On Friday, June 24, 2016 at 5:24:30 PM UTC+4:30, Val wrote:
>
> The playground caches everything, so running multiple times the same 
> program will just serve the previously generated output.
>
> Also in the playground everything is frozen at some point in the past : 
> the clock, the randomness sources, and you can't make outgoing requests to 
> import randomness from the network.
>
> On Friday, June 24, 2016 at 2:47:13 PM UTC+2, dc0d wrote:
>  
>
>> Better be something wrong with playground! :)
>>
>>

-- 
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: Namespacing hack using method on empty type

[dc0d]

Personally I do that (despite that everyone advocates against it). Just 
remember your struct should be just "struct{}" and nothing else. This 
helped me to use shorter & cleaner names for my functions - actually it 
converts a function pile to a batch of functions).

On Wednesday, August 3, 2016 at 7:37:35 PM UTC+4:30, atd...@gmail.com wrote:
>
> No it can have its uses.
>
> It really depends on what you are doing. However, I've never done this as 
> a way to declare some kind of namespace.
>
> Typically, I use that in testing when I want a dummy type to implement an 
> interface.
>
> That's just an example.
>
> It can be used also if you export the struct type. That allows to transfer 
> a group of functions (closer to your idea of namespace).
> Instead of exporting each function separately.
>

-- 
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] Initialize Variables in case clause of a switch

[dc0d]

In Go we can write:

if _, ok := input.(*data); ok {
//...
}

Why is it we can't do that in the case clause of a switch statement:

switch {
case x1,ok:=input.(*data1); ok && otherCond1:
case x2,ok:=input.(*data2); ok && otherCond2:
}

(I've read the language specification - which BTW speaks about the "case 
expressions" - I'm just curious about the reason)

-- 
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] Search for Another JSON Package

[dc0d]

Is there a JSON package that have these characteristics?


   - can marshal numeric integer values to strings (like 
   using `json:",string"` tag)
   - can unmarshal  numeric integer values from *either* string or the 
   number; based on the type of the field (some field like `MessageID int64`)

Why? Because IEEE 754 is really annoying and JSON standard treats all 
numeric values as `float64`. So when a big integer number (a big `int64` 
for example) gets serialized - which does perfectly - it can not get 
deserialized.

-- 
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: Search for Another JSON Package

[dc0d]

Thanks; the problem is I'm using a third party package with lots of 
data-structures and those data is going into CouchDB and deserializing 
would set the IEEE 754 hell loose.

Also the `IntegerAsString` on `codec.JsonHandle` in ugorji package does not 
works - created an issue for that.

I ended up forking the lib and use a custom Int and Int64 everywhere 
(implementing Marshaler and Unmarshaler interfaces).

I hope this problem get solved inside standard lib too.

Thanks;

On Wednesday, August 24, 2016 at 9:33:10 PM UTC+4:30, Ugorji Nwoke wrote:
>
> https://godoc.org/github.com/ugorji/go/codec
> https://github.com/ugorji/go
> package name: github.com/ugorji/go/codec
>
> On Wednesday, August 24, 2016 at 5:30:10 AM UTC-4, dc0d wrote:
>>
>> Is there a JSON package that have these characteristics?
>>
>>
>>- can marshal numeric integer values to strings (like 
>>using `json:",string"` tag)
>>- can unmarshal  numeric integer values from *either* string or the 
>>number; based on the type of the field (some field like `MessageID int64`)
>>
>> Why? Because IEEE 754 is really annoying and JSON standard treats all 
>> numeric values as `float64`. So when a big integer number (a big `int64` 
>> for example) gets serialized - which does perfectly - it can not get 
>> deserialized.
>>
>

-- 
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: Search for Another JSON Package

[dc0d]

Yes; I was super frustrated with big integers in JSON & your packages saved 
me big time! Thanks a lot!

On Thursday, August 25, 2016 at 3:19:19 PM UTC+4:30, Ugorji Nwoke wrote:
>
> I just checked the issue you created: 
> https://github.com/ugorji/go/issues/168 . I see you already closed it as 
> an error in your code.
>
> You typically shouldn't have to fork the library and make changes. It is 
> designed that you can achieve most of the customization you need by 
> implementing an interface or configuring a custom (en|de)code function for 
> given types.
>
> Glad it works for you.
>
> On Thursday, August 25, 2016 at 2:39:07 AM UTC-4, dc0d wrote:
>>
>> Thanks; the problem is I'm using a third party package with lots of 
>> data-structures and those data is going into CouchDB and deserializing 
>> would set the IEEE 754 hell loose.
>>
>> Also the `IntegerAsString` on `codec.JsonHandle` in ugorji package does 
>> not works - created an issue for that.
>>
>> I ended up forking the lib and use a custom Int and Int64 everywhere 
>> (implementing Marshaler and Unmarshaler interfaces).
>>
>> I hope this problem get solved inside standard lib too.
>>
>> Thanks;
>>
>> On Wednesday, August 24, 2016 at 9:33:10 PM UTC+4:30, Ugorji Nwoke wrote:
>>>
>>> https://godoc.org/github.com/ugorji/go/codec
>>> https://github.com/ugorji/go
>>> package name: github.com/ugorji/go/codec
>>>
>>> On Wednesday, August 24, 2016 at 5:30:10 AM UTC-4, dc0d wrote:
>>>>
>>>> Is there a JSON package that have these characteristics?
>>>>
>>>>
>>>>- can marshal numeric integer values to strings (like 
>>>>using `json:",string"` tag)
>>>>- can unmarshal  numeric integer values from *either* string or the 
>>>>number; based on the type of the field (some field like `MessageID 
>>>> int64`)
>>>>
>>>> Why? Because IEEE 754 is really annoying and JSON standard treats all 
>>>> numeric values as `float64`. So when a big integer number (a big `int64` 
>>>> for example) gets serialized - which does perfectly - it can not get 
>>>> deserialized.
>>>>
>>>

-- 
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] Confused about defer

[dc0d]

Assuming we have this test:

func TestRecover(t *testing.T) {
 f := func() (interface{}, error) {
 panic(`TEST`)
 }
 r, e := Recover(f)
 t.Log(r, e)
}

And two versions of *Recover* function.

Version 1:
func Recover(f func() (interface{}, error)) (interface{}, error) {
 var result interface{}
 var err error

 defer func() {
 if e := recover(); e != nil {
 err = errors.Error(fmt.Sprintf("%v", e))
 }
 }()

 result, err = f()

 return result, err
}


Version 2:
func Recover(f func() (interface{}, error)) (res interface{}, err error) {
 defer func() {
 if e := recover(); e != nil {
 err = errors.Error(fmt.Sprintf("%v", e))
 }
 }()

 res, err = f()

 return res, err
}


*Question:* Why the output of test for Version 1 is * * (*not 
expected/wrong*) but for Version 2 is * TEST* (*as expected/correct*)?

- Go 1.7, Ubuntu 14.04 x64

-- 
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: Confused about defer

[dc0d]

There deferred function here has not any return value - to get discarded. 
It rather assigns a value to the *closure* *err* variable.

Since a defer statement "*invokes a function whose execution is deferred to 
the moment the surrounding function returns*", so I expected the *err* 
variable should have a value just before the return statement executes.

The *err* variable is just a closure. Still I'm confused why the first 
version does not behave as expected - because the actual function *is not 
invoked yet* at the position of defer statement but just it's parameters. 
"*Instead, 
deferred functions are invoked immediately before the surrounding function 
returns*".

Why this is not behaving as expected?

On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>
> I put your code snippet in the playground for easier sharing: 
> https://play.golang.org/p/ZvuNwjS7ZF
>
> I think the spec has the answer you're looking for regarding how named 
> result parameters are handled during a panic.
> https://golang.org/ref/spec#Defer_statements
>
> Specifically the sentence:
>
>> If the deferred function has any return values, they are discarded when 
>> the function completes. (See also the section on handling panics 
>> <https://golang.org/ref/spec#Handling_panics>.)
>>
>
> Also,
>
>> If the function's signature <https://golang.org/ref/spec#Function_types> 
>> declares 
>> result parameters, the function body's statement list must end in a 
>> terminating 
>> statement <https://golang.org/ref/spec#Terminating_statements>.
>>
> https://golang.org/ref/spec#Function_declarations
>
> And the panic is the 'terminating statement'
>
> Hope this helps,
> Vasko.
>
> On Thursday, August 25, 2016 at 4:19:17 PM UTC-6, dc0d wrote:
>>
>> Assuming we have this test:
>>
>> func TestRecover(t *testing.T) {
>>  f := func() (interface{}, error) {
>>  panic(`TEST`)
>>  }
>>  r, e := Recover(f)
>>  t.Log(r, e)
>> }
>>
>> And two versions of *Recover* function.
>>
>> Version 1:
>> func Recover(f func() (interface{}, error)) (interface{}, error) {
>>  var result interface{}
>>  var err error
>>
>>  defer func() {
>>  if e := recover(); e != nil {
>>  err = errors.Error(fmt.Sprintf("%v", e))
>>  }
>>  }()
>>
>>  result, err = f()
>>
>>  return result, err
>> }
>>
>>
>> Version 2:
>> func Recover(f func() (interface{}, error)) (res interface{}, err error) 
>> {
>>  defer func() {
>>  if e := recover(); e != nil {
>>  err = errors.Error(fmt.Sprintf("%v", e))
>>  }
>>  }()
>>
>>  res, err = f()
>>
>>  return res, err
>> }
>>
>>
>> *Question:* Why the output of test for Version 1 is * * (*not 
>> expected/wrong*) but for Version 2 is * TEST* (*as expected/correct*
>> )?
>>
>> - Go 1.7, Ubuntu 14.04 x64
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Confused about defer

[dc0d]

Yes; it seemed to me that the return statement would get evaluated even 
after a panic. I thought of it as a special case of a deferred context - 
confused.

Thank you very much;

On Friday, August 26, 2016 at 12:11:03 PM UTC+4:30, Axel Wagner wrote:
>
> I'd think, the spec is reasonably unambiguous, if not very explicit. The 
> second version works, because of
>
> For instance, if the deferred function is a function literal and the 
>> surrounding function has named result parameters that are in scope within 
>> the literal, the deferred function may access and modify the result 
>> parameters before they are returned.
>
>
> and
>
> The recover function allows a program to manage behavior of a panicking 
>> goroutine. Suppose a function G defers a function D that calls recover and 
>> a panic occurs in a function on the same goroutine in which G is executing. 
>> When the running of deferred functions reaches D, the return value of D's 
>> call to recover will be the value passed to the call of panic. If D returns 
>> normally, without starting a new panic, the panicking sequence stops. In 
>> that case, the state of functions called between G and the call to panic is 
>> discarded, and normal execution resumes. Any functions deferred by G before 
>> D are then run and G's execution terminates by returning to its caller.
>
>
> i.e. after recover(), the execution continues as normally and the normal 
> behavior is, that you can modify named return parameters and the modified 
> version will then be returned.
>
> The first version also works as expected: recover() resumes execution as 
> normal and you can modify result and error as wished, but they are just 
> variables, not return values. Thus the function returns with the return 
> parameters unset (as you panic'ed before setting them with return).
>
> If it helps, you can imagine the return values as variables, initialized 
> to their zero values, which can be set in two ways: Either by having a 
> return or by naming them, which gives you direct access. A panic won't 
> modify them, but a defer'ed function might, if they are named. In your 
> first version, you never set them; return isn't called and they are not 
> named. In the second version you do set them; return isn't called, but you 
> name them and set them from the defer'ed function.
>
> Maybe the confusion is about what "after the surrounding function returns" 
> means? Maybe you interpret that as basically a "goto the line of the return 
> statement and execute it", whereas the spec means it as "executing the 
> function epilogue and return control to the caller"? The goto-like 
> interpretation doesn't make sense, in any case; there could be multiple, 
> pairwise contradictory return statements and it wouldn't be clear which is 
> executed.
>
> FWIW I do believe the spec could be clearer here. The behavior seems 
> logical and expected to me, but I do have trouble justifying this intuition 
> with the spec.
>
> On Fri, Aug 26, 2016 at 9:11 AM, dc0d 
> > wrote:
>
>> There deferred function here has not any return value - to get discarded. 
>> It rather assigns a value to the *closure* *err* variable.
>>
>> Since a defer statement "*invokes a function whose execution is deferred 
>> to the moment the surrounding function returns*", so I expected the *err* 
>> variable should have a value just before the return statement executes.
>>
>> The *err* variable is just a closure. Still I'm confused why the first 
>> version does not behave as expected - because the actual function *is 
>> not invoked yet* at the position of defer statement but just it's 
>> parameters. "*Instead, deferred functions are invoked immediately before 
>> the surrounding function returns*".
>>
>> Why this is not behaving as expected?
>>
>>
>> On Friday, August 26, 2016 at 3:25:11 AM UTC+4:30, Vasko Zdravevski wrote:
>>>
>>> I put your code snippet in the playground for easier sharing: 
>>> https://play.golang.org/p/ZvuNwjS7ZF
>>>
>>> I think the spec has the answer you're looking for regarding how named 
>>> result parameters are handled during a panic.
>>> https://golang.org/ref/spec#Defer_statements
>>>
>>> Specifically the sentence:
>>>
>>>> If the deferred function has any return values, they are discarded when 
>>>> the function completes. (See also the section on handling panics 
>>>> <https://golang.org/ref/spec#Handling_panics>.)
>>>>
>>>
&

[go-nuts] Length of Channel Using len Function

[dc0d]

TL;DR

Does assigning a (buffered) channel, already in a variable, to a second 
variable, affects the result of len function?

Long version:
What is happening here? - Code at the end; Go 1.7.

*Output 1*:

Nine times:
[  info ] 2016/08/28 19:51:28 LEN_BEFORE=0 
   
[  info ] 2016/08/28 19:51:28 LEN=7 
  
[  info ] 2016/08/28 19:51:28 S00=7

But if the second case gets commented like this:

case <-limiter.C:
 // if len(actualBuffer) > 0 {
 // buffer = actualBuffer
 // } else {
 // buffer = nil
 // }

It works as expected; *Output2*:

[  info ] 2016/08/28 19:54:28 LEN_BEFORE=0 
   
[  info ] 2016/08/28 19:54:28 LEN=7 
  
[  info ] 2016/08/28 19:54:28 S00=7 
  
[  info ] 2016/08/28 19:54:29 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:30 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:31 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:32 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:33 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:34 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:35 LEN_BEFORE=7 
   
[  info ] 2016/08/28 19:54:36 LEN_BEFORE=7
...

Code:

package main


import (
 "log"
 "time"


 "github.com/comail/colog"
)


func status00Channeler() {
 <-start


 limiter := time.NewTicker(time.Second / maxMsgPerSec)
 fetchLimiter := time.NewTicker(time.Second)


 var buffer chan *Data
 actualBuffer := make(chan *Data, maxMsgPerSec)
 db, err := newDB()
 if err != nil {
 log.Panic(err)
 }


FIRST:
 for {
 select {
 case <-interrupted:
 break FIRST
 case <-limiter.C:
 // if len(actualBuffer) > 0 {
 // buffer = actualBuffer
 // } else {
 // buffer = nil
 // }
 case i := <-buffer:
 select {
 case status00 <- i: // will block here
 case <-interrupted:
 break FIRST
 }
 case <-fetchLimiter.C:
 log.Printf("LEN_BEFORE=%d", len(actualBuffer))
 if len(actualBuffer) > 0 {
 continue
 }


 s00, err := db.GetIncomings()
 if err != nil {
 log.Println(`error:`, err)
 time.Sleep(time.Second)
 continue
 }
 if s00 == nil || len(s00) == 0 {
 continue
 }


 FILL_BUFFER:
 for _, v := range s00 {
 select {
 case actualBuffer <- v:
 default:
 break FILL_BUFFER
 }
 }


 log.Printf("LEN=%d", len(actualBuffer))
 log.Printf("S00=%d", len(s00))
 }
 }
}


func main() {
 go status00Channeler()
 close(start)


 <-time.After(time.Second * 30)
}


var (
 status00 = make(chan *Data, maxMsgPerSec)
)


type Data struct{}


const (
 maxMsgPerSec = 60
)


func newDB() (*DB, error) {
 res := new(DB)
 return res, nil
}


func (db *DB) GetIncomings() ([]*Data, error) {
 var res []*Data
 res = append(res, &Data{})
 res = append(res, &Data{})
 res = append(res, &Data{})
 res = append(res, &Data{})
 res = append(res, &Data{})
 res = append(res, &Data{})
 res = append(res, &Data{})


 return res, nil
}


type DB struct{}


func init() {
 colog.Register()
}


var (
 start   = make(chan struct{})
 interrupted = make(chan struct{}) // comes from sys interrupts SIGINT, 
SIGTERM, etc
)


-- 
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] Length of Channel Using len Function

[dc0d]

Would you please elaborate on that?

As I understand it there is no concurrent use of len happening here. It's a 
for loop and all calling to len is happening sequentially. Unless the 
channels make the code inside cases of one select statement concurrent - 
which will be super confusing for me.

On Sunday, August 28, 2016 at 8:03:10 PM UTC+4:30, Jan Mercl wrote:
>
> Using len(ch) like this in a concurrency scenario is a big no because then 
> the value you get carries 0 bits of useful information. It's not a data 
> race, it's worse, the race is semantic and not fixable without removing the 
> use of len(ch).
>
> On Sun, Aug 28, 2016, 17:26 dc0d > 
> wrote:
>
>> TL;DR
>>
>> Does assigning a (buffered) channel, already in a variable, to a second 
>> variable, affects the result of len function?
>>
>> Long version:
>> What is happening here? - Code at the end; Go 1.7.
>>
>> *Output 1*:
>>
>> Nine times:
>> [  info ] 2016/08/28 19:51:28 LEN_BEFORE=0   
>>  
>> [  info ] 2016/08/28 19:51:28 LEN=7 
>>   
>> [  info ] 2016/08/28 19:51:28 S00=7
>>
>> But if the second case gets commented like this:
>>
>> case <-limiter.C:
>>  // if len(actualBuffer) > 0 {
>>  // buffer = actualBuffer
>>  // } else {
>>  // buffer = nil
>>  // }
>>
>> It works as expected; *Output2*:
>>
>> [  info ] 2016/08/28 19:54:28 LEN_BEFORE=0   
>>  
>> [  info ] 2016/08/28 19:54:28 LEN=7 
>>   
>> [  info ] 2016/08/28 19:54:28 S00=7 
>>   
>> [  info ] 2016/08/28 19:54:29 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:30 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:31 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:32 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:33 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:34 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:35 LEN_BEFORE=7   
>>  
>> [  info ] 2016/08/28 19:54:36 LEN_BEFORE=7
>> ...
>>
>> Code:
>>
>> package main
>>
>>
>> import (
>>  "log"
>>  "time"
>>
>>
>>  "github.com/comail/colog"
>> )
>>
>>
>> func status00Channeler() {
>>  <-start
>>
>>
>>  limiter := time.NewTicker(time.Second / maxMsgPerSec)
>>  fetchLimiter := time.NewTicker(time.Second)
>>
>>
>>  var buffer chan *Data
>>  actualBuffer := make(chan *Data, maxMsgPerSec)
>>  db, err := newDB()
>>  if err != nil {
>>  log.Panic(err)
>>  }
>>
>>
>> FIRST:
>>  for {
>>  select {
>>  case <-interrupted:
>>  break FIRST
>>  case <-limiter.C:
>>  // if len(actualBuffer) > 0 {
>>  // buffer = actualBuffer
>>  // } else {
>>  // buffer = nil
>>  // }
>>  case i := <-buffer:
>>  select {
>>  case status00 <- i: // will block here
>>  case <-interrupted:
>>  break FIRST
>>  }
>>  case <-fetchLimiter.C:
>>  log.Printf("LEN_BEFORE=%d", len(actualBuffer))
>>  if len(actualBuffer) > 0 {
>>  continue
>>  }
>>
>>
>>  s00, err := db.GetIncomings()
>>  if err != nil {
>>  log.Println(`error:`, err)
>>  time.Sleep(time.Second)
>>  continue
>>  }
>>  if s00 == nil || len(s00) == 0 {
>>  continue
>>  }
>>
>>
>>  FILL_BUFFER:
>>  for _, v := range s00 {
>>  select {
>>  case actualBuffer <- v:
>>  default:
>>  break FILL_BUFFER
>>  }
>>  }
>>
>>
>>  log.Printf("LEN=%d", len(actualBuffer))
>>  log.Printf("S00=%d", len(s00))
>>  }
>>  }
>> }
>>
>>
>> func main() {
>>  go status00Channeler()
>>  close(start)
>>
>>
>>  <-time.After(time.Second * 30)
>> }
>>
>>
>> var (
>>  status00 = make(chan *Data, maxMsgPerSec)
>> )
>>
>>
>> type Data struct{}
>>
>>
>> const (
>>  maxMsgPerSec = 60
>> )
>>
>>
>> func newDB() (*DB, error) {
>>  res := new(DB)

Re: [go-nuts] Length of Channel Using len Function

[dc0d]

Thanks for comments. The status00 should be not-buffered (status00 = 
make(chan *Data)); was rate limiting on two channels.

On Sunday, August 28, 2016 at 8:16:50 PM UTC+4:30, Henrik Johansson wrote:
>
> The race is between the len call and the use of the channel. Entries can 
> have been added in between. 
>
> On Sun, Aug 28, 2016, 17:40 dc0d > 
> wrote:
>
>> Would you please elaborate on that?
>>
>> As I understand it there is no concurrent use of len happening here. It's 
>> a for loop and all calling to len is happening sequentially. Unless the 
>> channels make the code inside cases of one select statement concurrent - 
>> which will be super confusing for me.
>>
>>
>> On Sunday, August 28, 2016 at 8:03:10 PM UTC+4:30, Jan Mercl wrote:
>>
>>> Using len(ch) like this in a concurrency scenario is a big no because 
>>> then the value you get carries 0 bits of useful information. It's not a 
>>> data race, it's worse, the race is semantic and not fixable without 
>>> removing the use of len(ch).
>>>
>>> On Sun, Aug 28, 2016, 17:26 dc0d  wrote:
>>>
>> TL;DR
>>>>
>>>> Does assigning a (buffered) channel, already in a variable, to a second 
>>>> variable, affects the result of len function?
>>>>
>>>> Long version:
>>>> What is happening here? - Code at the end; Go 1.7.
>>>>
>>>> *Output 1*:
>>>>
>>>> Nine times:
>>>> [  info ] 2016/08/28 19:51:28 LEN_BEFORE=0 
>>>>
>>>> [  info ] 2016/08/28 19:51:28 LEN=7   
>>>> 
>>>> [  info ] 2016/08/28 19:51:28 S00=7
>>>>
>>>> But if the second case gets commented like this:
>>>>
>>>> case <-limiter.C:
>>>>  // if len(actualBuffer) > 0 {
>>>>  // buffer = actualBuffer
>>>>  // } else {
>>>>  // buffer = nil
>>>>  // }
>>>>
>>>> It works as expected; *Output2*:
>>>>
>>>> [  info ] 2016/08/28 19:54:28 LEN_BEFORE=0 
>>>>
>>>> [  info ] 2016/08/28 19:54:28 LEN=7   
>>>> 
>>>> [  info ] 2016/08/28 19:54:28 S00=7   
>>>> 
>>>> [  info ] 2016/08/28 19:54:29 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:30 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:31 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:32 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:33 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:34 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:35 LEN_BEFORE=7 
>>>>
>>>> [  info ] 2016/08/28 19:54:36 LEN_BEFORE=7
>>>> ...
>>>>
>>>> Code:
>>>>
>>>> package main
>>>>
>>>>
>>>> import (
>>>>  "log"
>>>>  "time"
>>>>
>>>>
>>>>  "github.com/comail/colog"
>>>> )
>>>>
>>>>
>>>> func status00Channeler() {
>>>>  <-start
>>>>
>>>>
>>>>  limiter := time.NewTicker(time.Second / maxMsgPerSec)
>>>>  fetchLimiter := time.NewTicker(time.Second)
>>>>
>>>>
>>>>  var buffer chan *Data
>>>>  actualBuffer := make(chan *Data, maxMsgPerSec)
>>>>  db, err := newDB()
>>>>  if err != nil {
>>>>  log.Panic(err)
>>>>  }
>>>>
>>>>
>>>> FIRST:
>>>>  for {
>>>>  select {
>>>>  case <-interrupted:
>>>>  break FIRST
>>>>  case <-limiter.C:
>>>>  // if len(actualBuffer) > 0 {
>>>>  // buffer = actualBuffer
>>>>  // } else {
>>>>  // buffer = nil
>>>>  // }
>>>>  case i := <-buffer:
>>>>  select {
>>>>  case status00 <- i: // will block here
>>>>  case <-interrupted:
>>>>  break F

[go-nuts] Reflection: Set the Pointer to Zero Value of Direct Type

[dc0d]

How can I fill a pointer to point to the zero value of underlying type?

Like in:

if fd.Kind() == reflect.Ptr {
 if fd.IsNil() {
 // how to set v (pointer) to point to a zero value of underlying type?
 // using this:
 // v = reflect.Zero(fd.Type()).Interface()
 // still gives a nil value.
 } else {
 v = fd.Interface()
 }
}



I want to fill v with the zero value of the underlying direct 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Reflection: Set the Pointer to Zero Value of Direct Type

[dc0d]

Exactly! Thanks! Now, how to put it inside the pointer? I mean, how to get 
it's address and put that address inside the pointer variable?

On Monday, September 5, 2016 at 10:47:23 PM UTC+4:30, Roberto Zanotto wrote:
>
> I should learn to read the questions more carefully before answering -_-
> In the code you commented out, fd.Type() is a pointer type, so the zero 
> value of a pointer type is a nil pointer.
> If you do fd.Type().Elem() it gives you the "dereferenced" type of the 
> value.
> So, maybe you want:
> v = reflect.Zero(fd.Type().Elem()).Interface()
>
> On Monday, September 5, 2016 at 7:28:13 PM UTC+2, dc0d wrote:
>>
>> How can I fill a pointer to point to the zero value of underlying type?
>>
>> Like in:
>>
>> if fd.Kind() == reflect.Ptr {
>>  if fd.IsNil() {
>>  // how to set v (pointer) to point to a zero value of underlying type?
>>  // using this:
>>  // v = reflect.Zero(fd.Type()).Interface()
>>  // still gives a nil value.
>>  } else {
>>  v = fd.Interface()
>>  }
>> }
>>
>>
>>
>> I want to fill v with the zero value of the underlying direct 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Reflection: Set the Pointer to Zero Value of Direct Type

[dc0d]

You're awesome! And Go's reflection is much better than what I've expected 
-  and yes, I like it, I use it!

On Tuesday, September 6, 2016 at 12:57:45 AM UTC+4:30, Roberto Zanotto 
wrote:
>
> If you want a pointer instead of the direct value, just use New instead of 
> Zero:
> v = reflect.New(fd.Type().Elem()).Interface()
>
> On Monday, September 5, 2016 at 9:30:13 PM UTC+2, dc0d wrote:
>>
>> Exactly! Thanks! Now, how to put it inside the pointer? I mean, how to 
>> get it's address and put that address inside the pointer variable?
>>
>> On Monday, September 5, 2016 at 10:47:23 PM UTC+4:30, Roberto Zanotto 
>> wrote:
>>>
>>> I should learn to read the questions more carefully before answering -_-
>>> In the code you commented out, fd.Type() is a pointer type, so the zero 
>>> value of a pointer type is a nil pointer.
>>> If you do fd.Type().Elem() it gives you the "dereferenced" type of the 
>>> value.
>>> So, maybe you want:
>>> v = reflect.Zero(fd.Type().Elem()).Interface()
>>>
>>> On Monday, September 5, 2016 at 7:28:13 PM UTC+2, dc0d wrote:
>>>>
>>>> How can I fill a pointer to point to the zero value of underlying type?
>>>>
>>>> Like in:
>>>>
>>>> if fd.Kind() == reflect.Ptr {
>>>>  if fd.IsNil() {
>>>>  // how to set v (pointer) to point to a zero value of underlying type?
>>>>  // using this:
>>>>  // v = reflect.Zero(fd.Type()).Interface()
>>>>  // still gives a nil value.
>>>>  } else {
>>>>  v = fd.Interface()
>>>>  }
>>>> }
>>>>
>>>>
>>>>
>>>> I want to fill v with the zero value of the underlying direct 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] sector - Dependency Injection for Go

[dc0d]

This <https://github.com/dc0d/sector> is a Dependency Injection package for 
Go. Point of interest here (for me) was separating the creation concern 
from injection concern. Creating objects is done using factories and 
injecting values into struct fields is done using the injector - which can 
go down to the object tree if needed.

Love to hear back from anybody who decided to use it!


-- 
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] On Concurrent-Safety

[dc0d]

Is setting a channel to nil, or to another channel, concurrent safe?

I guess it is not safe. Because it's a normal variable carrying the 
channel. But Go does some hidden optimizations, I wondered if this one is 
of those cases too.

-- 
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] How the main func started?

[dc0d]

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 something like 
*/tmp/go-build899137799/command-line-arguments/_obj/exe/appname* as the 
first argument.

Is this a reliable way for performing this task? To assume if the path is 
similar to this - for example using regex - it is running using go run?

*Motivation:*
The *go run* mode is used for some code generation - I've not tested if it 
works with *//go:generate go run main.go* or not; yet.

-- 
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] Initialize Fields

[dc0d]

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 
syntax - I can not tell of it's pros & cons for semantic or overall, 
deeply, but seems a practical thing for making the zero value even more 
interesting.

-- 
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] Initialize Fields

[dc0d]

You are right. But this felt clean and obvious syntax. Back to NewGate!

On Sunday, October 2, 2016 at 1:47:27 PM UTC+3:30, Axel Wagner wrote:
>
> Because that wouldn't be "the zero value" anymore.
> It would require that, when you do e.g.
> x := make([]gate, 4096)
> that the compiler emits the code to initialize everything. The same 
> recursively for each type that contains a gate and for each function which 
> uses a local gate variable.
> So this would imply a significant hidden runtime overhead when using that 
> type.
>
> The advantage of the zero type is, that it always is just zero-initialized 
> memory.
>
> On Sun, Oct 2, 2016 at 11:33 AM, dc0d 
> > wrote:
>
>> 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 
>> syntax - I can not tell of it's pros & cons for semantic or overall, 
>> deeply, but seems a practical thing for making the zero value even more 
>> interesting.
>>
>> -- 
>> 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] Single instance of program

[dc0d]

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 Linux?

On Tuesday, July 19, 2011 at 3:55:45 PM UTC+4:30, Dave Cheney wrote:
>
> Hi. 
>
> This is a glib answer, but you should check the resource that your 
> application requires to be a singleton.
>
> If that is a TCP port, then exit if you cannot bind. If it's a database, 
> then use a lock file, etc. 
>
> This isn't a Go specific problem. If you can give some more details, maybe 
> someone will be able to give a more specific answer. 
>
> Cheers
>
> Dave
>
> Sent from my iPhone
>
> On 19/07/2011, at 16:56, Ruslan Mezentsev  > wrote:
>
> > Hello.
> > How check only one instance of program is running? Use sockets,
> > mutexes or pid files, or other?
> > Thanks.
>
>

-- 
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] Single instance of program

[dc0d]

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 
> https://godoc.org/github.com/nightlyone/lockfile ?

-- 
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] Single instance of program

[dc0d]

Splendid! Thanks Justin! Thanks Dave! I was doing it wrong l, err := 
net.Listen("unix", "/tmp/lablock") which as Justin said should be l, err := 
net.ListenUnix("unix", &net.UnixAddr{Name: "@/tmp/lablock", Net: "unix"}).

BTW @ was very handy! But it should be at start of the whole file path, not 
file name. It works great and even if I don't call l.Close() explicitly 
(i.e. panic), the socket gets freed!

On Thursday, October 6, 2016 at 8:34:52 AM UTC+3:30, Dave Cheney wrote:
>
> It's a Linux thing, Google abstract domain socket. 

-- 
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] CGO & Plugins

[dc0d]

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 stability of the current plugin system 
> >that I can use for reference? I'm building a system now that I 
> contemplate 
> >using with some plugins and I'd like to know up front the challenges. 
>
> I wrote a blogpost on plugins earlier this year. The "caveats" section 
> has some remarks and references you might find interesting in this 
> context. 
>
> You can find it at 
> https://nick.groenen.me/posts/2017/01/09/plugins-in-go-18/ 
>
> -- 
> Nick Groenen 
> https://nick.groenen.me/ 
>

-- 
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] Calling Once (in the code)

[dc0d]

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 it is possible to put that part inside a 
meaningful function. I've followed that guideline for sometime and it helps 
to have a cleaner code base. But those explanatory functions should get 
called only from where that they are meant to make it more clear.

-- 
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] Calling Once (in the code)

[dc0d]

How can that get applied here (The Halting Problem)? We use functions 
everywhere and this is the same as we already do (with same level of 
probability for Halting Problem).

What I do currently:

1 - abstracting some parts of a long function in another function.
2 - the name of that second function starts with a Japanese character 
(because I have not those characters and I can not type them by accident)

This way I have a function that is called just once "in the code" but the 
caller function may call this child function as much as it needs.

On Friday, August 11, 2017 at 12:38: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 ;-)
>
> -- 
>
> -j
>

-- 
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: Calling Once (in the code)

[dc0d]

"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 Brant, William Opdyke, and Don Roberts 
(1999) Refactoring: Improving the Design of Existing Code. Addison-Wesley.

Based on this practice, the code below (this code's sole purpose is to 
demonstrate):

func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) 
error {
if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
return errInvalidName
}

if !isAddressOK(data.Address1, data.Address2) {
return errInvalidAddress
}

if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
return errInvalidPhone
}

p.Address1 = data.Address1
p.Address2 = data.Address2
p.BirthDate = data.BirthDate
p.FirstName = data.FirstName
p.LastName = data.LastName
p.MiddleName = data.MiddleName
p.MobileNumber = data.MobileNumber
p.PhoneNumber = data.PhoneNumber

return nil
}

Can get refactored to (instead of adding comments):

func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) 
error {
if err := validateData(data); err != nil {
return err
}

transferData(data, p)

return nil
}

func validateData(data *Data) error {
if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
return errInvalidName
}

if !isAddressOK(data.Address1, data.Address2) {
return errInvalidAddress
}

if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
return errInvalidPhone
}

return nil
}

func transferData(data *Data, p *DLO) {
p.Address1 = data.Address1
p.Address2 = data.Address2
p.BirthDate = data.BirthDate
p.FirstName = data.FirstName
p.LastName = data.LastName
p.MiddleName = data.MiddleName
p.MobileNumber = data.MobileNumber
p.PhoneNumber = data.PhoneNumber
}

Now the sole purpose of functions validateData and transferData is 
providing a clean and more descriptive code. They should appear only in one 
place in the code inside the body of 
sampleSloppyFuncForDescribingThisSpecificProblem. This is what I need to 
check.

On Friday, August 11, 2017 at 8:57:46 AM UTC+4:30, Henry wrote:
>
> I don't fully understand the problem, but if you need a quick and dirty 
> way to ensure a function is called exactly once, you can always use a 
> global variable, have the function checks the variable when the function is 
> called. If the function is called the first time, it will set the variable. 
> If the function has been called more than once, it should panic and returns 
> the stacktrace.
>
> 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).
>>
>> Purpose: A guideline on commenting code by Martin Fowler states that 
>> before writing a comment, see if it is possible to put that part inside a 
>> meaningful function. I've followed that guideline for sometime and it helps 
>> to have a cleaner code base. But those explanatory functions should get 
>> called only from where that they are meant to make it more clear.
>>
>

-- 
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: Calling Once (in the code)

[dc0d]

As he cleared up in his later quotes and tweets it's about replacing 
comments with functions. IMHO this way comments will turn into active 
(code) specifications and would help greatly specially in a statically 
types languages. They might even make writing more clear tests easier. But 
(IMHO) having more functions does not necessarily means having better 
reusable code.

In this case the functions in question are *private* functions in a package 
and their sole purpose is to replace comments in another (one specific) 
function.

On Friday, August 11, 2017 at 4:43:29 PM UTC+4:30, 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 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 Brant, William Opdyke, and Don Roberts 
>> (1999) Refactoring: Improving the Design of Existing Code. Addison-Wesley.
>>
>> Based on this practice, the code below (this code's sole purpose is to 
>> demonstrate):
>>
>> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) 
>> error {
>> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
>> return errInvalidName
>> }
>>
>> if !isAddressOK(data.Address1, data.Address2) {
>> return errInvalidAddress
>> }
>>
>> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
>> return errInvalidPhone
>> }
>>
>> p.Address1 = data.Address1
>> p.Address2 = data.Address2
>> p.BirthDate = data.BirthDate
>> p.FirstName = data.FirstName
>> p.LastName = data.LastName
>> p.MiddleName = data.MiddleName
>> p.MobileNumber = data.MobileNumber
>> p.PhoneNumber = data.PhoneNumber
>>
>> return nil
>> }
>>
>> Can get refactored to (instead of adding comments):
>>
>> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) 
>> error {
>> if err := validateData(data); err != nil {
>> return err
>> }
>>
>> transferData(data, p)
>>
>> return nil
>> }
>>
>> func validateData(data *Data) error {
>> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
>> return errInvalidName
>> }
>>
>> if !isAddressOK(data.Address1, data.Address2) {
>> return errInvalidAddress
>> }
>>
>> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
>> return errInvalidPhone
>> }
>>
>> return nil
>> }
>>
>> func transferData(data *Data, p *DLO) {
>> p.Address1 = data.Address1
>> p.Address2 = data.Address2
>> p.BirthDate = data.BirthDate
>> p.FirstName = data.FirstName
>> p.LastName = data.LastName
>> p.MiddleName = data.MiddleName
>> p.MobileNumber = data.MobileNumber
>> p.PhoneNumber = data.PhoneNumber
>> }
>>
>> Now the sole purpose of functions validateData and transferData is 
>> providing a clean and more descriptive code. They should appear only in one 
>> place in the code inside the body of 
>> sampleSloppyFuncForDescribingThisSpecificProblem. This is what I need to 
>> check.
>>
>> On Friday, August 11, 2017 at 8:57:46 AM UTC+4:30, Henry wrote:
>>>
>>> I don't fully understand the problem, but if you need a quick and dirty 
>>> way to ensure a function is called exactly once, you can always use a 
>>> global variable, have the function checks the variable when the function is 
>>> called. If the function is called the first time, it will set the variable. 
>>> If the function has been called more than once, it should panic and returns 
>>> the stacktrace.
>>>
>>> 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).
>>>>
>>>> Purpose: A guideline on commenting code by Martin Fowler states that 
>>>> before writing a comment, see if it is possible to put that part inside a 
>>>> meaningful function. I've followed that guideline for sometime and it 
>>>> helps 
>>>> to have a cleaner code base. But those explanatory functions should get 
>>>> called only from where that they are meant to make it more clear.
>>>>
>>>

-- 
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: Calling Once (in the code)

[dc0d]

Thanks for suggesting guru. I'll try it.

If there is a convention for naming, it makes code more clear, otherwise, 
yes, it makes code more unclear - in my experience. In times it's not an 
easy task. But having a long function too, is not a good thing (IMHO).

On Friday, August 11, 2017 at 6:02:31 PM UTC+4:30, Egon wrote:
>
> Note, this can fragment the code and make it harder to understand... (
> http://number-none.com/blow/john_carmack_on_inlined_code.html)
>
> As for the tool:
>
> guru can give you the callers of a function, so you might be able 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, John Brant, William Opdyke, and Don Roberts 
>> (1999) Refactoring: Improving the Design of Existing Code. Addison-Wesley.
>>
>> Based on this practice, the code below (this code's sole purpose is to 
>> demonstrate):
>>
>> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) 
>> error {
>> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
>> return errInvalidName
>> }
>>
>> if !isAddressOK(data.Address1, data.Address2) {
>> return errInvalidAddress
>> }
>>
>> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
>> return errInvalidPhone
>> }
>>
>> p.Address1 = data.Address1
>> p.Address2 = data.Address2
>> p.BirthDate = data.BirthDate
>> p.FirstName = data.FirstName
>> p.LastName = data.LastName
>> p.MiddleName = data.MiddleName
>> p.MobileNumber = data.MobileNumber
>> p.PhoneNumber = data.PhoneNumber
>>
>> return nil
>> }
>>
>> Can get refactored to (instead of adding comments):
>>
>> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *DLO) 
>> error {
>> if err := validateData(data); err != nil {
>> return err
>> }
>>
>> transferData(data, p)
>>
>> return nil
>> }
>>
>> func validateData(data *Data) error {
>> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
>> return errInvalidName
>> }
>>
>> if !isAddressOK(data.Address1, data.Address2) {
>> return errInvalidAddress
>> }
>>
>> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
>> return errInvalidPhone
>> }
>>
>> return nil
>> }
>>
>> func transferData(data *Data, p *DLO) {
>> p.Address1 = data.Address1
>> p.Address2 = data.Address2
>> p.BirthDate = data.BirthDate
>> p.FirstName = data.FirstName
>> p.LastName = data.LastName
>> p.MiddleName = data.MiddleName
>> p.MobileNumber = data.MobileNumber
>> p.PhoneNumber = data.PhoneNumber
>> }
>>
>> Now the sole purpose of functions validateData and transferData is 
>> providing a clean and more descriptive code. They should appear only in one 
>> place in the code inside the body of 
>> sampleSloppyFuncForDescribingThisSpecificProblem. This is what I need to 
>> check.
>>
>> On Friday, August 11, 2017 at 8:57:46 AM UTC+4:30, Henry wrote:
>>>
>>> I don't fully understand the problem, but if you need a quick and dirty 
>>> way to ensure a function is called exactly once, you can always use a 
>>> global variable, have the function checks the variable when the function is 
>>> called. If the function is called the first time, it will set the variable. 
>>> If the function has been called more than once, it should panic and returns 
>>> the stacktrace.
>>>
>>> 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).
>>>>
>>>> Purpose: A guideline on commenting code by Martin Fowler states that 
>>>> before writing a comment, see if it is possible to put that part inside a 
>>>> meaningful function. I've followed that guideline for sometime and it 
>>>> helps 
>>>> to have a cleaner code base. But those explanatory functions should get 
>>>> called only from where that they are meant to make it more clear.
>>>>
>>>

-- 
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: Calling Once (in the code)

[dc0d]

Well said! Still I prefer functions to comments, when possible. As it's 
been said, code never lies, comments sometimes do. And a boom is simpler to 
understand (for me). Functions go boom; comments do not.

On Saturday, August 12, 2017 at 1:48:05 AM UTC+4:30, Egon wrote:
>
> There are no good things... only trade-offs.
>
> Clarity is not directly about naming, but rather balancing locus of 
> attention and working memory. When you put too many things together (such 
> as a long function), you fill up your short term memory when reading the 
> code... on the other side, when you make too many pieces you have to 
> constantly switch from one piece to another to understand something. But 
> yes, good names enable learning chunks and make recalling easier.
>
> So yeah... you want balance between these two aspects... though people 
> have different 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. I'll try it.
>>
>> If there is a convention for naming, it makes code more clear, otherwise, 
>> yes, it makes code more unclear - in my experience. In times it's not an 
>> easy task. But having a long function too, is not a good thing (IMHO).
>>
>> On Friday, August 11, 2017 at 6:02:31 PM UTC+4:30, Egon wrote:
>>>
>>> Note, this can fragment the code and make it harder to understand... (
>>> http://number-none.com/blow/john_carmack_on_inlined_code.html)
>>>
>>> As for the tool:
>>>
>>> guru can give you the callers of a function, so you might be able 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, John Brant, William Opdyke, and Don Roberts 
>>>> (1999) Refactoring: Improving the Design of Existing Code. Addison-Wesley.
>>>>
>>>> Based on this practice, the code below (this code's sole purpose is to 
>>>> demonstrate):
>>>>
>>>> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *
>>>> DLO) error {
>>>> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
>>>> return errInvalidName
>>>> }
>>>>
>>>> if !isAddressOK(data.Address1, data.Address2) {
>>>> return errInvalidAddress
>>>> }
>>>>
>>>> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
>>>> return errInvalidPhone
>>>> }
>>>>
>>>> p.Address1 = data.Address1
>>>> p.Address2 = data.Address2
>>>> p.BirthDate = data.BirthDate
>>>> p.FirstName = data.FirstName
>>>> p.LastName = data.LastName
>>>> p.MiddleName = data.MiddleName
>>>> p.MobileNumber = data.MobileNumber
>>>> p.PhoneNumber = data.PhoneNumber
>>>>
>>>> return nil
>>>> }
>>>>
>>>> Can get refactored to (instead of adding comments):
>>>>
>>>> func sampleSloppyFuncForDescribingThisSpecificProblem(data *Data, p *
>>>> DLO) error {
>>>> if err := validateData(data); err != nil {
>>>> return err
>>>> }
>>>>
>>>> transferData(data, p)
>>>>
>>>> return nil
>>>> }
>>>>
>>>> func validateData(data *Data) error {
>>>> if !isNameOK(data.FirstName, data.MiddleName, data.LastName) {
>>>> return errInvalidName
>>>> }
>>>>
>>>> if !isAddressOK(data.Address1, data.Address2) {
>>>> return errInvalidAddress
>>>> }
>>>>
>>>> if !isPhoneOK(data.PhoneNumber, data.MobileNumber) {
>>>> return errInvalidPhone
>>>> }
>>>>
>>>> return nil
>>>> }
>>>>
>>>> func transferData(data *Data, p *DLO) {
>>>> p.Address1 = data.Address1
>>>> p.Address2 = data.Address2
>>>> p.BirthDate = data.BirthDate
>>>> p.FirstName = data.FirstName
>>>

[go-nuts] Built-in log Package

[dc0d]

Many packages use the built-in log package. It could log data with help 
from it's type. If we could set the output of the logger to something other 
than *io.Writer*, like:

type Output interface {
Printf(format string, vset ...interface{})
Flags() (flag int)
Prefix() (prefix string)
SetFlags(flag int)
SetPrefix(prefix string)
}

Then, inside the output handler we could perform proper actions for logging 
the data. Usual informative data would just get logged, and error would get 
logged as error - as it should be. *logger.Error(err)* looks unnecessary 
redundant 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 this idea. All 
data gets logged as info and if it is/contains error, it gets logged as 
error (hence, two levels). Most functions from standard log package are 
implemented. 

-- 
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] Built-in log Package

[dc0d]

That may be (still IMH-Experience in the majority of cases, this is the 
proper default to go).

But the main concern to express here is, the default logger should accept 
an interface like *Output* instead of *io.Writer*. That way any necessary 
mechanism can be added without touching the log package, which is used in 
many packages.

Best would be if it could just accept the same logger interface as the 
destination.

And if the log package is going to change to support leveled logging (or 
another package is going to be added for this purpose), it's the best if 
the destination could accept object themselves, not a byte slice (*[]byte*).

On Monday, August 14, 2017 at 3:03:00 AM UTC+4:30, Axel Wagner wrote:
>
> I'd consider it quite sensible to log an error *and* handle it (e.g. by 
> retrying). In that case, I wouldn't want it to appear with error-severity 
> 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 PM, dc0d 
> > wrote:
>
>> Many packages use the built-in log package. It could log data with help 
>> from it's type. If we could set the output of the logger to something other 
>> than *io.Writer*, like:
>>
>> type Output interface {
>> Printf(format string, vset ...interface{})
>> Flags() (flag int)
>> Prefix() (prefix string)
>> SetFlags(flag int)
>> SetPrefix(prefix string)
>> }
>>
>> Then, inside the output handler we could perform proper actions for 
>> logging the data. Usual informative data would just get logged, and error 
>> would get logged as error - as it should be. *logger.Error(err)* looks 
>> unnecessary redundant 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 this idea. All 
>> data gets logged as info and if it is/contains error, it gets logged as 
>> error (hence, two levels). Most functions from standard log package are 
>> implemented. 
>>
>> -- 
>> 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] Built-in log Package

[dc0d]

Some packages tried that approach, adding levels as prefixes (which I 
prefer to defining methods). But did not get enough attention.

Whatever approach that may get chosen for a logging package, the logger 
struct should implement some Logger interface and should accept an instance 
of another object which also implements the Logger interface.

This way it will be possible to not only handle the log entries at lower 
layers but also to have a hierarchy of loggers to the top (where logging is 
happening) which can behave differently based on the (conceptual) context - 
choosing the formatters, the destinations or notifying another system.

And levels could be expanded to tags. A tagged entry can be processed based 
on its tags (including a concept like level) - but it seems (sadly) that 
levels are more wide-spread than just being a tag.

That sort of interface, is what I would like to see. And you are right 
about that there is no conclusive agreement on what it should like.

Another question that I failed to answer properly (by myself) is: are 
metrics same as logs? Or they are a higher level concept (which also can be 
logged)? And should logging be in charge of delivering 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 main concern to express here is, the default logger should 
> > accept an interface like /Output/ instead of /io.Writer/. 
>
> I would agree, if not for the fact that there seem to be very little 
> consensus on exactly what such an interface should look like. 
>
> systemd support a very simple (but useful) interface for leveled 
> logging. Just prefix what you write to stdout or stderr with "" where 
> X is the syslog log-level. Systemd takes care of anything else. 
> Exactly this is pretty much impossible to do efficiently with many 
> log-packages, including the stdlib "log". 
>
> /Peter 
>

-- 
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] Built-in log Package

[dc0d]

>
> 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 to change the 
source and works with objects, instead of byte slices.

-- 
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] Built-in log Package

[dc0d]

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.

There are many cases (/packages) that one can not pass the Context (and the 
WaitGroup) to each and every goroutine. It's possible to define a struct 
and use it as a closure for those functions(now methods). But one has to 
rewrite the whole interface to a package.

Forcing the function signature *everywhere* is not a practice/pattern 
anymore (hint: if it was not forced to be *everywhere*, it was a pattern). 
It's something else.

-- 
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] Built-in log Package

[dc0d]

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 option to register them as the output for the standard log 
package - all at info level.

On Thursday, August 17, 2017 at 11:36:54 AM UTC+4:30, Peter Mogensen wrote:
>
>
>
> On 2017-08-15 21:34, Tamás Gulácsi wrote: 
> > Even better: my libraries expose only the LogFunc: i.e. 
> > var Log = func(keyvals ...interface{}) error { return nil} 
> > 
> > Which is easy to override with any logger, is not tied to go-kit/log, 
> but provides structured logging! 
>
> ... or exposing some lib.SetLogger(...) function. 
>
> But preferably, one should try not to log from libraries and return 
> errors instead and leave logging to the application - if possible. 
>
> There's few things more annoying than libraries spitting something out 
> where you least need it. 
>
> /Peter 
>
>

-- 
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] Built-in log Package

[dc0d]

Henrik,

Here I've tried to put a sample (other than the built-in log package) for 
cases that global stuff makes things more clear and pragmatic (IMHO).

On Thursday, August 17, 2017 at 11:44:09 AM UTC+4:30, Henrik Johansson 
wrote:
>
> Sorry to but in but what happened to the whole 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 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.
>>
>> There are many cases (/packages) that one can not pass the Context (and 
>> the WaitGroup) to each and every goroutine. It's possible to define a 
>> struct and use it as a closure for those functions(now methods). But one 
>> has to rewrite the whole interface to a package.
>>
>> Forcing the function signature *everywhere* is not a practice/pattern 
>> anymore (hint: if it was not forced to be *everywhere*, it was a 
>> pattern). It's something else.
>>
>> -- 
>> 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] Built-in log Package

[dc0d]

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 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. 
>
> github.com/pkg/errors 
>
> ...solves many of those problems w/o logging inside the libray. 
> That's not to say that there are not situations were you really really 
> want to log a message inside a library, but it can be kept to a minimum. 
>
> /Peter 
>

-- 
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] Built-in log Package

[dc0d]

Christian,

By where I mean package/file.go:lineNumber which I have a helper method for 
that:


//-

var (
errNotAvailable = errors.New("N/A")
)

// Here .
func Here(skip ...int) (funcName, fileName string, fileLine int, callerErr 
error) {
sk := 1
if len(skip) > 0 && skip[0] > 1 {
sk = skip[0]
}
var pc uintptr
var ok bool
pc, fileName, fileLine, ok = runtime.Caller(sk)
if !ok {
callerErr = errNotAvailable
return
}
fn := runtime.FuncForPC(pc)
name := fn.Name()
ix := strings.LastIndex(name, ".")
if ix > 0 && (ix+1) < len(name) {
name = name[ix+1:]
}
funcName = name
nd, nf := filepath.Split(fileName)
fileName = filepath.Join(filepath.Base(nd), nf)
return
}

//-

I do not know if it's the best in the class though!

I like the approach that package took to keep track of the source error. 
But never have take a look to those interfaces. And that's my point. There 
is something wrong with being forced to adapt every single package to your 
underlying logger, just to provide logging.

And going back to the my initial concern: There is a need for an interface 
for a logger (whatever it should look like) and the standard log package 
should be able to consume that interface (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 loose the info about where the error is happening.
>>
>
> What do you mean by where the error is happening?
>
> Have you checked out 
> http://godoc.org/github.com/pkg/errors#hdr-Retrieving_the_stack_trace_of_an_error_or_wrapper
>  
>
> Cheers,
>
> Christian
>

-- 
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: Calling Once (in the code)

[dc0d]

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 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] Why http header letter case changes?

[dc0d]

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

-- 
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] Tiny FSM

[dc0d]

What cons (or pros) there might be in this implementation?

type State func() (State, error)


func (s State) Activate() (funcErr error) {
 next := s
 for next != nil && funcErr == nil {
 next, funcErr = next()
 }
 return
}


type FSM interface {
 Start() State
}



   - Calling it a FSM (Finite State Machine) might be inaccurate. But that 
   was what came to my mind at the moment.
   - I got exited by this (and other amazing things than we can do in Go) 
   but I wanted to make sure using this would not bring much harm into a 
   code-base. I've used it just a bit, but couldn'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 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] Tiny FSM

[dc0d]

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

-- 
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] Tiny FSM

[dc0d]

I've done F# for some years before but it's not always very fruitful to 
apply practices from other domains. Also I've already implemented other 
version of the runner engine (the Activate method) for (as an example) 
handling a final state. But I've been discouraged from doing many things in 
Go, so I always try to double check if it's a good approach or not.

Keeping track of not-reduced state was a nice trick! I feel it can be used 
for undo scenarios (backtracking?).

Thanks for the informative and instructive reply!

On Sunday, September 24, 2017 at 2:59:31 PM UTC+3:30, Jesper Louis Andersen 
wrote:
>
> This method is common in functional programming as well. You are, 
> essentially, computing a fixed point over the state machine (or in Rob's 
> example a lexer state). That is, you are taking a set of state transitions 
> and turning them into a function when looked at from the "outside".
>
> If you have a description of a problem which can be cast as a state table, 
> the method is often good. You can just 1-1 verbatim copy the state table 
> into code and have the system derive a correct function out of it for you, 
> which you can then call. Updates to the state machine naturally grafts 
> itself into the correct points in the state system.
>
> Another useful feature of such a representation is that it allows you to 
> write different interpreters for your state machine. You can, for instance, 
> add an operation in between each state transition quite naturally by 
> altering your runner. Do something before you call the next state. If you 
> define the correct methods, this allows you to naturally add debugging aids 
> to a system.
>
> The next level up in representations such as these are tagless-final 
> representations[0], in which the state machine is written as an abstract 
> DSL. By implementing different concrete functions for the abstract 
> specification, you can interpret the same piece of code differently in 
> different contexts. It is popular to use as a way to handle testing, or by 
> writing a self-certifying FSM: verify the invariant between each function 
> call. It also allows one to write optimization passes on the DSL and stack 
> them up on top of each other. Or extend the DSL implementation gradually in 
> a modular way.
>
> A similar idea are those of "free constructions". Roughly speaking a 
> construction is "free" if it "doesn't throw away information". For 
> instance, the term "2 + 2" bears more information than "4". This is because 
> if we have the result of the computation, 4, we don't know if this was 
> computed from "1 + 3", "3 + 1", "0 + 4", "(2*2) + (3*5) - 15" and so on. 
> Now, if we squint our eyes a bit and look at *programs* as free 
> constructions. 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://okmij.org/ftp/tagless-final/index.html
>
>
> On Sun, Sep 24, 2017 at 11:47 AM dc0d > 
> wrote:
>
>> 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
>>>
>>> -- 
>>>
>>> -j
>>>
>> -- 
>> 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] Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[dc0d]

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 but there is this problem 
with channels that after sending the result to the channel, if we close it, 
there would be another signal which notifies the other side about the 
channel be closed (in _, ok := <-rsultChan; ok will be false).

-- 
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: Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[dc0d]

BTW currently a private channel with length of 1 is being used and the 
other side must call a function to get the result (with a timeout). This 
way the second signal about closing the channel is not a problem. And we 
see this inside the standard library too, like in the time 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 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 but there is this problem 
> with channels that after sending the result to the channel, if we close it, 
> there would be another signal which notifies the other side about the 
> channel be closed (in _, ok := <-rsultChan; ok will be false).
>

-- 
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: Notify The Completion And Provide Result - And The Extra Notification Of Closing a Channel

[dc0d]

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) (*Result, error) {...}). 
And an explicit ErrTimeout is preferred here, instead of overloading the 
semantic of closing channel, with the concept of timeout. But since there 
can not be any other sort of errors (the Result has an error field itself) 
I wonder if I should use that.

On Monday, October 30, 2017 at 12:40:07 PM UTC+3:30, Dave Cheney wrote:
>
> I think you should use a channel. If the communication is between two 
> parities then there is no need to close the channel after sending the 
> result as the are not other parties to inform that they missed the message. 

-- 
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] Managing Dependencies (as in IoC) and Avoid Globals

[dc0d]

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 for cancellation (and hierarchy of 
cancellations) and I like it for passing state when every step in a 
pipeline is concurrent and short lived; for other uses, using context seems 
a not proper choice.

Struggling with these thoughts, something like a hierarchical service 
locator came to my mind:

type DepRegistry struct {
 parent *DepRegistry
 deps   sync.Map
}


func (r *DepRegistry) Register(name string, dep interface{}) {
 r.deps.Store(name, dep)
}


// Load first loads from current instance, then tries
// to load from parent (panics if fails to find)
func (r *DepRegistry) Load(name string) interface{} {
 dep, ok := r.deps.Load(name)
 if !ok {
 if r.parent != nil {
 return r.parent.Load(name)
 }
 panic("unknown dep " + name)
 }
 return dep
}


func NewDepRegistry(parent ...*DepRegistry) *DepRegistry {
 res := &DepRegistry{}
 if len(parent) > 0 && parent[0] != nil {
 res.parent = parent[0]
 }
 return res
}


I would love to hear thoughts on this matter. Is it an acceptable solution? 
Is there anything missing?

Sample App: There is this app, with different packages that are using 
services like logging, creating/modifying images, sending/receiving 
messages from bots and the like. Those parts are already separate 
executables, communication via NATS. 

-- 
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] Bulky (Payload) Structs in API

[dc0d]

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:
Redefining some domain models for those payloads is cumbersome and 
sometimes impractical. At the same time using them directly, exposes other 
packages to that package that we want to abstract out it's functionality. 
Some unwelcome dependency.

Question:
Should we redefined all those data types in upper layers for using them? If 
no what is the solution?

-- 
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: Bulky (Payload) Structs in API

[dc0d]

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 with Go ast yet).

An example would be the API to Telegram Bot (package 
<https://github.com/go-telegram-bot-api/telegram-bot-api>). Requests and 
responses from the API are big, fat JSONs; wrapped up in Go structs. These 
Go structs are the one in question.

As it can be seen, they are pretty big and bulky (can not be helped, it's 
how the Telegram API is). But passing them up/out, makes other packages, 
become dependent on *tgbotapi* package.

As for functionality, interfaces work great. But for payloads that are 
being passed between packages (even if they are POGOs) I can not find a 
clean approach for sharing them.

On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>
> One possibility is copy-paste the structure and 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 "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:
>> Redefining some domain models for those payloads is cumbersome and 
>> sometimes impractical. At the same time using them directly, exposes other 
>> packages to that package that we want to abstract out it's functionality. 
>> Some unwelcome dependency.
>>
>> Question:
>> Should we redefined all those data types in upper layers for using them? 
>> If no what is the solution?
>>
>

-- 
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: Bulky (Payload) Structs in API

[dc0d]

BTW another approach that I've tried is to use Type Aliases. A third 
package created and type aliases (with the same names) defined for those 
POGO payloads.

Then type aliases (and interfaces) from this third package can be used in 
upper/other packages.

But I've not used it heavily 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 in playing with Go ast yet).
>
> An example would be the API to Telegram Bot (package 
> <https://github.com/go-telegram-bot-api/telegram-bot-api>). Requests and 
> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
> Go structs are the one in question.
>
> As it can be seen, they are pretty big and bulky (can not be helped, it's 
> how the Telegram API is). But passing them up/out, makes other packages, 
> become dependent on *tgbotapi* package.
>
> As for functionality, interfaces work great. But for payloads that are 
> being passed between packages (even if they are POGOs) I can not find a 
> clean approach for sharing them.
>
> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>
>> One possibility is copy-paste the structure and 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 "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:
>>> Redefining some domain models for those payloads is cumbersome and 
>>> sometimes impractical. At the same time using them directly, exposes other 
>>> packages to that package that we want to abstract out it's functionality. 
>>> Some unwelcome dependency.
>>>
>>> Question:
>>> Should we redefined all those data types in upper layers for using them? 
>>> If no what is the solution?
>>>
>>

-- 
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: Bulky (Payload) Structs in API

[dc0d]

Thanks!

The bot package was just an example. This is a general concern IMHO. 
Interfaces do nicely when we want to hide implementation details (on 
accepting things as an interface). For example package A is a low-level, 
infrastructure package at Infrastructure layer/area. Now at the Interfaces 
layer, the package B is placed, which provides a nice set of abstractions 
for package A. In a use-case package named C, those abstractions from 
package B is used.

So far, so good! Now, as explained, package A has those bulky fat payloads; 
which forces us to use package A, directly inside package C.

This nullifies the purpose of package B.

This indeed, happens when a generic bot is being implemented. But even if 
that was not the case, I failed to find a way to prevent A from leaking 
into C.

At the end of the day it's all about trade-offs! I think you are right that 
there is no other way around and we have to either use A directly or write 
a translation layer.

Yet I'm curious about using type aliases as (yet another level of) an 
indirection.

On Monday, November 13, 2017 at 12:00:27 PM UTC+3:30, Egon wrote:
>
> Is there a problem created from sharing the package or creating a separate 
> package? Or why is that dependency a problem?
>
> There's some knowledge about the requests/responses shared between 
> packages. Trying to hide it, doesn't gain anything -- it only makes the 
> sharing implicit rather than explicit.
>
> When you are writing a "telegram-bot" you should know the request/response.
>
> However, when you are writing a "generic-bot" that works with "telegram" 
> then the solution is to implement some sort of translation layer and 
> provide a minimal API for the "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, though not happy with it. I had to write some helper 
>> apps and scripts (I'm not fluent in playing with Go ast yet).
>>
>> An example would be the API to Telegram Bot (package 
>> <https://github.com/go-telegram-bot-api/telegram-bot-api>). Requests and 
>> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
>> Go structs are the one in question.
>>
>> As it can be seen, they are pretty big and bulky (can not be helped, it's 
>> how the Telegram API is). But passing them up/out, makes other packages, 
>> become dependent on *tgbotapi* package.
>>
>> As for functionality, interfaces work great. But for payloads that are 
>> being passed between packages (even if they are POGOs) I can not find a 
>> clean approach for sharing them.
>>
>> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>>
>>> One possibility is copy-paste the structure and 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 "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:
>>>> Redefining some domain models for those payloads is cumbersome and 
>>>> sometimes impractical. At the same time using them directly, exposes other 
>>>> packages to that package that we want to abstract out it's functionality. 
>>>> Some unwelcome dependency.
>>>>
>>>> Question:
>>>> Should we redefined all those data types in upper layers for using 
>>>> them? If no what is the solution?
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Reading os.Stdin, Unbuffered

[dc0d]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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 > 
> wrote:
>
> > Is there a way to read from `os.Stdin` in an unbuffered way? (Not 
> waiting for a `\n` or anything).
>
> n, err := os.Stdin.Read(buf)
>
> does not wait for `\n`. Or do you actually mean setting a terminal in raw 
> mode? Because os.Stdin does not have to be a terminal.
>
>
>
> -- 
>
> -j
>

-- 
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: Implement sub-commands using flag library

[dc0d]

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, Archos wrote:
>
> Another more, flagplus, but with has a simple API:
>
> https://github.com/kless/flagplus
> http://godoc.org/github.com/kless/flagplus
>
> Example of usage: 
> https://github.com/kless/flagplus/blob/master/testing/test.go
>
> El miércoles, 1 de enero de 2014 04:18:36 UTC, Steve Francia escribió:
>>
>> A lot of people are finding Cobra useful.
>>
>> https://github.com/spf13/cobra
>>
>> Inspired by go, go-Commander, gh and subcommand, Cobra improves on these 
>> by providing fully posix compliant flags (including short & long versions), 
>> nesting commands, and the ability to define your own help and usage for any 
>> or all commands.
>>
>> Cobra has an exceptionally clean interface and simple design without 
>> needless constructors or initialization methods.
>>
>> Disclaimer, I'm the author of this project and would love any feedback. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

The way it is implemented currently, it supports multiple commands. And it 
can be decided by checking the flags against their default values.

Maybe it should return a []string. Any specific suggestions?

On Thursday, December 7, 2017 at 7:13:57 PM UTC+3:30, rog wrote:
>
> On 7 December 2017 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 minimalism, but how are you supposed to know which subcommand 
> has been chosen? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

>
> > 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 brief glance, your package doesn't allow any 
non-flag arguments to be passed to a subcommand. 

They are just the builtin FlagSet, so the Args() function returns the 
non-flag args.

>
> How about making Parse return the name of the selected subcommand (or the 
empty string if none is specified) ? 

Seems the only logical option! Thanks!

> BTW as of Go 1.10, you'll be able to avoid the dubious reflect hack to 
get the name from the FlagSet. 

Looking forward to that!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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, visit https://groups.google.com/d/optout.

[go-nuts] Unused Variable Generates No Error

[dc0d]

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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  > wrote: 
> > 
> >> This code compiles and generates no errors. Why? 
> > 
> > It's legal code according to the language specification. 
>
> To be fair, so is every other Go program with unused variables. 
> This looks like a bug to me - could you open an issue please, Kaveh? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[dc0d]

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, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.