[go-nuts] Re: Easy to use (getopt based) flags package

[mhhcbon]

looks lovely, how do you manage sub commands ?

On Wednesday, April 10, 2019 at 2:24:21 AM UTC+2, Paul Borman wrote:
>
> I have never been quite happy with the flags packages available for Go, 
> including the standard flags package as well as my own getopt packages (v1 
> and v2).  They are just too cumbersome to use.  I finally have come up with 
> a solution that I like.  github.com/pborman/options 
> 
>
> The command line options are declared as a simple structure with struct 
> tags, for example:
>
> // Declare the command line flags.  The help information does not need to 
> line up,
> // I just think it looks prettier this way.
> var opts = struct {
> Helpoptions.Help  `getopt:"--help   display help"`
> Namestring`getopt:"--name=NAME  name of the widget"`
> Count   int   `getopt:"--count -c=COUNT number of widgets"`
> Verbose bool  `getopt:"-v   be verbose"`
> Timeout time.Duration `getopt:"--timeoutduration of run"`
> }{
> Name: “gopher”,
> }
>
> func main() {
> // Assign args to the positional parameters.
> args := options.RegisterAndParse()
>
> fmt.Printf(“Name is: %s\n”, opts.Name)
> …
> }
>
> The command usage displayed by passing —help to the above program will 
> look something like:
>
> Usage: prog [-v] [-c COUNT] [--help] [--name NAME] [--timeout value] 
> [parameters ...]
>  -c, --count=COUNT  number of widgets
>  --help display help
>  --name=NAMEname of the widget [gopher]
>  --timeout=value
> duration of run
>  -v be verbose
>
> The package is built on top of the github.com/pborman/getopt/v2 
>  package and as such they 
> can be used together.  The options package also supports reading command 
> line arguments from a file by using the options.Flags type.
>
> I hope that some of you might find this helpful in writing command line 
> programs.
>
> -Paul
>

-- 
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] Channels: selecting the last element

[mhhcbon]

> feel unbuffered channels are safer to use especially in an acyclic 
directed graph of flowing values. Buffered channels seem to reduce blocking 
but I feel they come with the cost of such side effects like my initial 
problem of forgotten results in their channels. 


that happens with unbuffered channel too, if, for example, you mix it with 
a select on context cancellation.
Maybe you are lucky and your data source provides a acknowledgment 
mechanism, maybe you are not and it s up to you to work around.
This becomes a problem when the code can t be rationalized via an api that 
is able to wrap those behaviors.

On Tuesday, December 18, 2018 at 8:50:20 PM UTC+1, Chris Burkert wrote:
>
> Robert,
> it seems to me that you have a clear understanding about unbuffered vs. 
> buffered channels. I feel unbuffered channels are safer to use especially 
> in an acyclic directed graph of flowing values. Buffered channels seem to 
> reduce blocking but I feel they come with the cost of such side effects 
> like my initial problem of forgotten results in their channels. I would 
> love to hear/read/see more on the unbuffered vs. buffered tradeoff to get 
> rid of this gut feeling I am currently based on :-). Any good article you 
> can point me to?
> Thanks
>
> Robert Engels > schrieb am Di. 18. 
> Dez. 2018 um 17:03:
>
>> That code is incorrect as well when using buffered channels. 
>>
>> On Dec 18, 2018, at 10:00 AM, Skip Tavakkolian > > wrote:
>>
>> why not just  drop the select? i think the following is guaranteed 
>> because putting things on rc has to succeed before putting true into dc:
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> func do(i int, rc chan<- int, dc chan<- bool) {
>> rc <- i
>> dc <- true
>> }
>>
>> func main() {
>> worker := 10
>> rc := make(chan int, worker)
>> done := 0
>> dc := make(chan bool, worker)
>> for i := 0; i < worker; i++ {
>> go do(i, rc, dc)
>> }
>> for done < worker {
>> r := <-rc
>> fmt.Println(r)
>> <-dc
>> done++
>> }
>> }
>>
>>
>> On Tue, Dec 18, 2018 at 5:35 AM Chris Burkert > > wrote:
>>
>>> Dear all,
>>>
>>> I have a couple of goroutines sending multiple results over a channel - 
>>> a simple fan-in. They signal the completion on a done channel. Main selects 
>>> on the results and done channel in parallel. As the select is random main 
>>> sometimes misses to select the last result. What would be the idiomatic way 
>>> to prevent this and completely drain the result channel?
>>>
>>> Here is a minmal example which sometimes prints one 0 but should always 
>>> print two of them:
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> )
>>>
>>> func do(rc chan<- int, dc chan<- bool) {
>>> rc <- 0
>>> dc <- true
>>> }
>>>
>>> func main() {
>>> worker := 2
>>> rc := make(chan int, worker)
>>> done := 0
>>> dc := make(chan bool, worker)
>>> for i := 0; i < worker; i++ {
>>> go do(rc, dc)
>>> }
>>> for done < worker {
>>> select {
>>> case <-dc:
>>> done++
>>> case r := <-rc:
>>> fmt.Println(r)
>>> }
>>> }
>>> }
>>>
>>> many thanks
>>> Chris
>>>
>>> -- 
>>> 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...@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] Important design missing from Errors overview

[mhhcbon]

hi, you are looking for this page 
https://github.com/golang/proposal/blob/master/design/go2draft.md

On Wednesday, November 28, 2018 at 9:13:19 AM UTC+1, gopher@gmail.com 
wrote:
>
> I do not understand how to respond in the wiki. Do I directly edit the 
> page? I don't see any comments or discussion. 
>
> Also I think that the article should be mentioned in the errors overview. 
> It is like an evolved version of the upspin method but much simpler to 
> implement and more general.
>
> On Tuesday, November 27, 2018 at 1:50:50 AM UTC+2, Ian Lance Taylor wrote:
>>
>> On Mon, Nov 26, 2018 at 1:31 PM  wrote: 
>> > 
>> > While reading 
>> https://go.googlesource.com/proposal/+/master/design/go2draft-error-values-overview.md#other-go-designs
>>  
>> I noticed that an important design is missing from the links below. I am 
>> talking about Ben's https://middlemost.com/failure-is-your-domain/ which 
>> I think offers some very good insights that are missing from the current 
>> proposals. I think it is important to be added and be considered. 
>>
>> Thanks, it's a good article, but I'm not sure what feedback to take 
>> from it regarding the error design drafts that were made.  In any case 
>> a good place to respond is the wiki feedback pages mentioned at 
>> https://go.googlesource.com/proposal/+/master/design/go2draft.md . 
>>
>

-- 
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: I am not in favor of generics.

[mhhcbon]

I was referring to this code

func (x type []K) Sum() (r type K) { 
  for type switch { 
  case K range int64(), uint64(), float64(), complex128(): 
   for _, v := range x { 
  r += v 
   } 
  case K big.Int: 
   for _, v := range x { 
  r.Add(r,v) 
   } 
  break  // or return in every case instead 
  } 
  return 
} 

I did not understand how "// For var x []AnyType. ANY. " relates to 
previous code.

for your question about the rune, i guess it d be like this 

func Sum(some []K, add func(l,r K) K) (ret K) {
  for _, v := range some {
ret = add(ret, v)
  }
  return ret 
}

func addOperator(l,r Z)Z{
   return l+r
}

func main(){
  total := Sum([]rune("whatever"), addOperator)
}

Consider Z,K as virtual types to be inferred from the call site. 

In regards to Russ Cox proposal this code is missing 
their explicitly declared contracts and the function instances declaration.
On the other hand, this is so much more readable *to me*.

maybe it looks likes c++, i did not think it was a concern 
as long as it respected desired behaviors of good error reporting, 
good readability, ease of usage, speed of compilation, 
proven useful and workable etc 

in regards to all those factors Russ Cox knows way better so he s probably 
right, 
yet the link provided by Robert is extremely interesting, repeating it here 
https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics

This was also an interesting reading
https://www.researchgate.net/publication/273718701_The_Reaction_of_Open-Source_Projects_to_New_Language_Features_An_Empirical_Study_of_C_Generics

Just quoting from it

Frankel [Fra 9 3]found that generics were not
widely used in Ada. Later, the principal designer of Ada suggested that, if 
he could,
he would eliminate parameterized types, because they were “less useful than 
originally
thought” [RSB05].

Anyways, I am polluting the thread against this proposal, sorry for that.

On Tuesday, September 18, 2018 at 10:54:02 PM UTC+2, ohir wrote:

> On Tue, 18 Sep 2018 10:11:52 -0700 (PDT) 
> mhh...@gmail.com  wrote: 
>
> > I agree with Robert, this is not re usable. 
>
> What is not reusable? A generic Sum function allowed by 
> the CGG that can sum any type of any base that accidentally 
> has anything countable in it? 
>
> > I much prefer this 
> > 
> > func Sum(some []K, add func(l,r K) K) (ret K) { 
> >   for _, v := range some { 
> > ret = add(ret, v) 
> >   } 
> >   return ret 
> > } 
> > 
> > func main(){ 
>
>
> >   total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r}) 
> > } 
>
> How clever and generic it looks. Generic, javish and cpluplusish. 
> And how readable call site it gave. 
>
> In CGG Go user code call is exactly the same for ANY type. 
>
> total := Sum(x) // For var x []AnyType. ANY. 
>
> var x []string 
> total := Sum(x) 
>
> may return sum of all runes in all strings and sprintf-ed to 
> the resulting string. 
>
> > this is not re usable. 
>
> How can I call your example to get string result of sum of all 
> runes? CGG's is as with any other type: `total := Sum(x)` 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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: I am not in favor of generics.

[mhhcbon]

I agree with Robert, this is not re usable.

I much prefer this 

func Sum(some []K, add func(l,r K) K) (ret K) {
  for _, v := range some {
ret = add(ret, v)
  }
  return ret 
}

func main(){
  total := Sum([]int{1,2,3,4}, func(l,r int) int {return l+r})
}


On Tuesday, September 18, 2018 at 5:59:18 PM UTC+2, ohir wrote:
>
> On Tue, 18 Sep 2018 08:26:29 -0700 (PDT) 
> alan...@gmail.com  wrote: 
>
> > There's no way that your generic Sum function can deal with big.Int 
>
> Oh, with CGG (https://github.com/ohir/gonerics) of course there is: 
>
> func (x type []K) Sum() (r type K) { 
>   for type switch { 
>   case K range int64(), uint64(), float64(), complex128(): 
>for _, v := range x { 
>   r += v 
>} 
>   case K big.Int: 
>for _, v := range x { 
>   r.Add(r,v) 
>} 
>   break  // or return in every case instead 
>   } 
>   return 
> } 
>
> :) Your welcome. 
>
> > Alan 
> > 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>

-- 
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] public interface with private method: totally dubious ? In which case is it useful ?

[mhhcbon]

hi,

in this code 
https://github.com/conformal/gotk3/blob/7a6ce3ecbc883d4d6a7aa1821bbc9633751fd67e/gtk/gtk.go#L7926

a public interface with a private method is declared.

At first read, totally dubious. yeah?

A bit more testing, and i wonder in which case this is suitable, a basic 
example yields,

./main2.go:7: cannot use b.XX literal (type b.XX) as type a.WW in argument 
to a.C: b.XX does not implement a.WW (missing a.private method) have 
b.private() want a.private()

*$GOPATH/src/test/a/a.go*
package a

type WW interface {
 private()
}

func C(h WW) {}

*$GOPATH/src/test/b/b.go*
package b

type XX struct{}

func (x XX) private() {}

*$GOPATH/src/test/main.go*
package main

import "test/a"
import "test/b"

func main() {
 a.C(b.XX{})
}

-- 
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: go1.9: problem with go get

[mhhcbon]

can this thread helps ?

https://groups.google.com/forum/#!topic/golang-nuts/wAYxijyyL5U

On Thursday, August 31, 2017 at 10:23:07 PM UTC+2, abriese wrote:
>
> ~/Download/ $ go build github.com/AndreasBriese/breeze
> # runtime
> /usr/local/go/src/runtime/mstkbar.go:151:10: debug.gcstackbarrieroff 
> undefined (type struct { allocfreetrace int32; cgocheck int32; efence 
> int32; gccheckmark int32; gcpacertrace int32; gcshrinkstackoff int32; 
> gcrescanstacks int32; gcstoptheworld int32; gctrace int32; invalidptr 
> int32; sbrk int32; scavenge int32; scheddetail int32; schedtrace int32 } 
> has no field or method gcstackbarrieroff)
> /usr/local/go/src/runtime/mstkbar.go:162:24: division by zero
> /usr/local/go/src/runtime/mstkbar.go:162:43: invalid expression 
> unsafe.Sizeof(composite literal)
> /usr/local/go/src/runtime/mstkbar.go:162:44: undefined: stkbar
> /usr/local/go/src/runtime/mstkbar.go:212:4: gp.stkbar undefined (type *g 
> has no field or method stkbar)
> /usr/local/go/src/runtime/mstkbar.go:213:15: gp.stkbar undefined (type *g 
> has no field or method stkbar)
> /usr/local/go/src/runtime/mstkbar.go:216:23: undefined: stackBarrierPC
> /usr/local/go/src/runtime/mstkbar.go:226:28: gp.stkbarPos undefined (type 
> *g has no field or method stkbarPos)
> /usr/local/go/src/runtime/mstkbar.go:227:19: gp.stkbarPos undefined (type 
> *g has no field or method stkbarPos)
> /usr/local/go/src/runtime/mstkbar.go:248:41: undefined: stkbar
> /usr/local/go/src/runtime/mstkbar.go:227:19: too many errors
>
> Did not really know, what's going wrong here. Never got build errors with 
> this package before.
>
> Best 
> Andreas
>
>

-- 
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: Generics and readability

[mhhcbon]

in my concern i could agree with everyone. so it does not go anywhere, 
does it ?

Axel resumes it well. I d just add one notion, complexity to build the 
desired generator.
Even though a great work has been made so golang compile in go,
it is not an easy api to handle.
So if go intends to reach a broader audience, 
compete on the field of dynamic language, 
well maybe, it is questionable to stay on the consensus that code gen is 
the way to go,
even though there are has good reasons.
I back this Q on this quote
https://youtu.be/7VcArS4Wpqk?t=13m50s

Then about the form of any evolution, 
this quote about sophistication talks by itself
https://youtu.be/7VcArS4Wpqk?t=3m4s

That being said, back to generics, from known implementation,
it is not an option to put that in the language,
but, so many times people want to parametrize the types.

Also, in the first quote it says, to be as expressiveness and convenient as 
dynamic language,
but, by design it can t, because all types representation 
available in the language are destructive.

take this code

type A struct{} 
func (a A) Hello(){}
func (a A) Whatsup(){}

type W interface{ Hello() }

func sayHello(a W) W { a.Hello(); return a }

func main(){ sayHello(A{}) }

In a dynamic language, the type out of sayHello can be anything, including 
the input type.
In that example, written in go1, it can be W or anything, but not the input 
type, the information has been destroyed at the func input signature.
There s a duality of types in the value 'a', it is W (and A),
when it enters sayHello, the signature used, reduces it to W and looses the 
original type.
That prevents code re usability, because this example is fixable as long as 
i control the definition of sayHello (it is not imported from a remote 
repository i don t have hand on).
If i don t, and this the case when you try to provide a re usable code, 
then i m stuck.

In a dynamic language, as types are not defined, the idea of returning the 
type that was inputed without knowing it is *totally implicit*.

// the return type is: whatever provided
func sayHello(a) { a.Hello(); return a } // within the body i want to use a 
W

This kind of ideas, and the lack of parametric type, participates to the 
situation where i can t totally, deeply, blindly agree to that:
... go provides the expressiveness and convenience of a dynamic typed 
interpreted language.


___

If that speaks to anyone else,

this might be a way to represent the flat type hierarchy of golang,
where moving a structs to an interface clearly states it is less,
and even less when it is moved to interface{}, 
in contrary the type assertion permits to navigate the other way around.

interface{}
> While having generics as part of the language and doing the code-gen in 
> the compiler has definite advantages (ease of use and potentially better 
> optimization of the generated code), doing it as a separate tool *also* 
> has advantages. For example, this way no one is bound to whatever notion of 
> generics will eventually be built into the language. Because it *will* 
> have limitations and provide a trade-off. With separate tooling outside the 
> language, people can make their own tradeoff.
>
> For example, yes, you can do template-like code generation at compile 
> time. But you could also box values in interface{} and have a tool that 
> verifies your desired notion of type-saftey statically. It's up to you - 
> whatever makes more sense for your use case.
>
> Honestly, right now I'd prefer good and easy to use meta-programming tools 
> for go. If I can write my own type-checks or code-gen to be run on a go 
> build, it enables far more powerful tools than generics alone… (yes, it 
> also has drawbacks. I'm aware).
>
> On Sun, Aug 27, 2017 at 5:08 PM,  wrote:
>
>> > That's how C++ started.
>>
>> And that's also why C++ is the ugly monster than it is today; with a 
>> design that wasn't quite thought thoroughly. Talking about C++ like it's an 
>> example to follow is just preposterous.
>>
>> Le dimanche 27 août 2017 16:25:54 UTC+2, Jan Mercl a écrit :
>>>
>>> And there's nothing wrong in it. That's how C++ started. Codegen allows 
>>> for easier protoyping throwaway experiments. Writing a full blown compiler 
>>> and realizing afterwards a better language/feature design costs probably 
>>> much more work.
>>>
>>> On Sun, Aug 27, 2017, 15:55  wrote:
>>>
 > Codegen can do 100% of what any compiler can do.

 Yes and it is called doing the compiler's job in place of 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...@googlegroups.com.
 For more 

[go-nuts] Re: Generics and readability

[mhhcbon]

simplicity is complicated: https://www.youtube.com/watch?v=rFejpH_tAHM
needlessly complex: https://youtu.be/IRTfhkiAqPw?t=19m40s
because i liked it very much: https://www.youtube.com/watch?v=QM1iUe6IofM

About code gen, as we know it in go1, i feel like it is a third class 
citizen.
In its current form i think it is not able to perform as good as it need to 
be to become a first class citizen.
being out of the language limits its capabilities. I need to find example 
about that.
Also my understanding is that it was not designed to be used for the kind 
of code gen like go-derive does it,
this usage seems to come from the community, as a workaround.
On the principles code-gen is the most capable, in practice its un-natural.

On Saturday, August 26, 2017 at 7:03:36 PM UTC+2, JuciÊ Andrade wrote:
>
> mhh:
> >Why would you put generics on a method ?
>
> I.e.: I could have a container type and a element type to be contained.
>
> myStack.push(myElement)
>
> mhh:
> >type Final notFinal
>
> Maybe it is a good idea to require an intermediate type like that, to keep 
> things readable.
>
> mhh:
> > none of this is as powerful as code gen.
>
> A lot of people consider code gen a second class solution when compared to 
> a more traditional generics implementation. I don't think so. Code 
> generation can be very effective. No major concerns about indecipherable 
> error messages. When in doubt you can inspect the generated code to 
> understand exactly what is the problem.
>
> Axel, I am very confident that no solution will be incorporated to Go 
> before deep thinking about all it's implications. Your points will be 
> considered, for sure.
>
> Jesper:
> >  if you don't get the above, you wouldn't have been able to pass the 
> first course at my university back in the day (around 2000).
>
> Generics user here, since Bjarne Stroustrup's CFront, the very first C++ 
> compiler.
>
> Whenever you use complex idioms you reduce the amount of people able to 
> understand your code and able to mantain it. The simpler the code, the more 
> people can help you.
>
> Abuse of generics is a common source of headaches in C++ code. I saw 
> seasoned developers fighting for hours or days to convince the compiler to 
> grasp new code. Due to the complexity explosion things get out of control 
> fast. For what? Just to throw that code away as soon as someone else needs 
> to mantain it. Write-only code. 
>
> Been there, done that. I learned it the hard way.
>
> Today if you see a code of mine you surely will say I learned to program 
> yesterday. That's exactly the way I like. People are able to read my code 
> like it was a comic book. No secrets, no head scratching. I am happy, my 
> employer is happy, my coworkers are happy. A lot of developers can jump to 
> my project if the need/oportunity arises.
>
> Simplicity is the single most important Go asset in my opinion, due to the 
> broader audience it brings.
>
>

-- 
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: can't use text filename on open that was read from stdin

[mhhcbon]

someone did answer you in your earlier thread,

but here you go

https://play.golang.org/p/VVTXPhSYPE



On Friday, August 25, 2017 at 9:18:18 PM UTC+2, Geoff Fridd wrote:
>
> When I use a literal as the filename in an os.Open statement it works. 
> When I use a variable defined as text as the filename, it works. When I 
> read in the text filename from stdin, it doesn't work. Why is that? What do 
> I need to do to make it work? See attached text file.
>
>
>

-- 
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] Help! Same code, different results

[mhhcbon]

[mh-cbon@pc2 rendez-vous] $ cd ../../go-dedup/fsimilar/
[mh-cbon@pc2 fsimilar] $ find test/sim -type f | ./fsimilar -i -d 12 -vv
[fsimilar]  n='GNU - 2001 - Python Standard Library', e='.pdf', s='1', d=
'test/sim/'
[fsimilar] +: Simhash of 55d4263ae1a6e6d6 added.
[fsimilar]  n='(eBook) GNU - Python Standard Library 2001', e='.pdf', s='1', 
d='test/sim/'
[fsimilar] =: Simhash of d5d6363ef9e6e6d7 ignored for 55d4263ae1a6e6d6 (8).
[fsimilar]  n='GNU - Python Standard Library (2001)', e='.rar', s='1', d=
'test/sim/'
[fsimilar] =: Simhash of 55d4263ae1a6e6d6 ignored for 55d4263ae1a6e6d6 (0).
[fsimilar]  n='Python Standard Library', e='.zip', s='1', d='test/sim/'
[fsimilar] =: Simhash of 55b47e2af1a4a4d2 ignored for 55d4263ae1a6e6d6 (11).
[fsimilar]  n='Audio Book - The Grey Coloured Bunnie', e='.mp3', s='1', d=
'test/sim/'
[fsimilar] +: Simhash of f8fde9fe7f7dbd5e added.
[fsimilar]  n='PopupTest', e='.java', s='1', d='test/sim/'
[fsimilar] +: Simhash of a0d9070f13c20979 added.
[fsimilar]  n='LayoutTest', e='.java', s='1', d='test/sim/'
[fsimilar] +: Simhash of 37299e9d4e277b87 added.
[fsimilar]  n='ColoredGrayBunny', e='.ogg', s='1', d='test/sim/'
[fsimilar] +: Simhash of 25eade3cd3db679c added.
[fsimilar] ## Similar items
 map[Similars:[map[Ext:.pdf Size:1 Dir:test/sim/ Hash:6184610222622303958 
Dist:0 SizeRef:1 Name:GNU - 2001 - Python Standard Library] map[Size:1 Dir:
test/sim/ Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - Python 
Standard Library (2001) Ext:.rar]]].
test/sim/GNU - 2001 - Python Standard Library.pdf
test/sim/GNU - Python Standard Library (2001).rar


[mh-cbon@pc2 fsimilar] $ go version
go version go1.8 linux/amd64
[mh-cbon@pc2 fsimilar] $ go env
GOARCH="amd64"
GOBIN="/home/mh-cbon/gow/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mh-cbon/gow"
GORACE=""
GOROOT="/home/mh-cbon/.gvm/gos/go1.8"
GOTOOLDIR="/home/mh-cbon/.gvm/gos/go1.8/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build580933895=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
[mh-cbon@pc2 fsimilar] $ git log -n 1
commit 10c9f3f50da4f00f7fd874c24aa7c7787dcf275e (HEAD -> master, origin/
master, origin/HEAD)
Author: Tong Sun 
Date:   Thu Aug 24 00:36:37 2017 -0400

- [+] add FileT.Similarity()
[mh-cbon@pc2 fsimilar] $

hth


On Friday, August 25, 2017 at 8:56:29 PM UTC+2, Tong Sun wrote:
>
>
> Update, 
>
>
> On Fri, Aug 25, 2017 at 11:39 AM, Tong Sun  > wrote:
>
>> Hi, 
>>
>> I'm experiencing a *very very* strange problem now -- the same Go code 
>> is producing different results *for me*. 
>> I'm not kidding, I can't believe that myself, so I've spent *the past 
>> few days* going back and forth to verify everything. 
>> Now, after all these days, the only conclusion that I can make is, albeit 
>> how bazzard it is, same code, different results. 
>>
>> Can someone verify for me what you get please? 
>>
>> go get github.com/go-dedup/fsimilar
>>
>> then 
>>
>> cd go-dedup/fsimilar
>> go build
>> find test/sim -type f | ./fsimilar -i -d 12 -vv 
>>
>> and tell me what's the last output that you got please. 
>>
>> The problem is that *two *of my machines produce:
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - 
>> 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU 
>> - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/ 
>> Hash:6184610222622303958 Dist:0 SizeRef:1]]].
>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>> *test/sim/GNU - Python Standard Library (2001).rar*
>>
>> But another one, the *only one*, produce:
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[{(eBook) GNU - Python Standard Library 2001 .pdf 1 
>> test/sim/ 15408562819203262167 8 1} {GNU - 2001 - Python Standard Library 
>> .pdf 1 test/sim/ 6184610222622303958 0 1} {GNU - Python Standard Library 
>> (2001) .rar 1 test/sim/ 6184610222622303958 0 1} {Python Standard Library 
>> .zip 1 test/sim/ 6175699711939618002 11 1}]].
>> *test/sim/(eBook) GNU - Python Standard Library 2001.pdf*
>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>> *test/sim/GNU - Python Standard Library (2001).rar*
>> *test/sim/Python Standard Library.zip*
>>
>> which is what I actually want. 
>>
>> The rest of the following output are exactly the same across all three 
>> machines:
>>
>> $ go version 
>> go version go1.8.1 linux/amd64
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 17.04
>> Release:17.04
>> Codename:   zesty
>>
>> $ git status 
>> On branch master
>> Your branch is up-to-date with 'origin/master'.
>> nothing to commit, working tree clean
>>
>>
> - all the original source on three machines are pulled from 

[go-nuts] https://golang.org/pkg/builtin/#append

[mhhcbon]

looks broken here 

__

File builtin builtin 

/src/builtin/builtin.go:88:11: expected type, found '=' (and 1 more errors) 

-- 
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: Generics and readability

[mhhcbon]

mh, what do you think of this quote ? Not to reject the whole work, 
just an example i stumble upon.

___

Note that type deduction requires types to be identical. This is stronger 
than the usual requirement when calling a function, namely that the types 
are assignable.


func [T] Find(s []T, e T) bool
type E interface{}
var f1 = 0
// Below does not compile.  The first argument means that T is
// deduced as E. f1 is type int, not E. f1 is assignable to
// E, but not identical to it.
var f2 = Find([]E{f1}, f1)
// Below does compile. Explicit type specification for Find
// means that type deduction is not performed.
var f3 = Find[E]([]E{f1}, f1)

___


Stupid remark, in "Note that type deduction requires types to be 
identical", if the type must be identical, 
there is no mechanism for type deduction that can take place.

>From human point of view,
[]interface is as good as []int to store/receive ...int


On Friday, August 25, 2017 at 1:06:44 PM UTC+2, Henrik Johansson wrote:
>
> Ah yes unfortunate that Ians proposal was rejected.
>
> fre 25 aug. 2017 kl 10:39 skrev 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com >:
>
>> Maybe a loaded question but what is the goal of this thread? Is it to 
>> establish whether or not generics impact readability? In that case it 
>> should get a lot more civil and charitable on both sides.
>>
>> Anyway, my take on that: The examples mentioned, in a very real way, are 
>> not really suitable to discuss that question. Any readability impact comes 
>> not so much from simple declarations, but from a) how frequent 
>> type-parameterized objects are going to be and b) how often we can omit the 
>> type-parameteres. The issues are things like parameterized type-parameters 
>> (today this example 
>>  flew 
>> through my twitter stream, to illustrate the point) and extra layers of 
>> abstraction (like using a Map instead of a 
>> map[string]int).
>>
>> Basically, we have three opposing forces: 1) How powerful the generics 
>> implementation is, that is what are the things that can be parameterized, 
>> 2) How powerful type-inference is for them, that is in which specific 
>> circumstances types can be omitted (this is the vital "readability" part) 
>> and 3) How simple the description of them is, that is how easy is it to 
>> understand failed type-checks to the programmer and how much space would 
>> they take up in the spec and/or implementation.
>>
>> Currently, Go *mostly* has 1 near zero (it is a little positive due to 
>> the existence of map, [], chan… and append/copy/…), in preference of 2 and 
>> 3. Most people agree, that 1 should get a little more love though. It's 
>> easy to come up with syntax or semantics that make 1 large, but the issue 
>> is, that while we want to increase 1, we don't just want to neglect 2 and 3.
>>
>> Most languages with powerful generics will also include a lot of 
>> machinery for 2, that is a complicated type-inference mechanism. Because 
>> it's so complicated, they will mostly omit 3, that is they will not specify 
>> how exactly it works and leave that up to the implementation, giving them 
>> the flexibility to tune the intelligence over time. Most of them (*cough* 
>> C++ 
>> 
>>  
>> *cough*) also completely fail to provide meaningful error messages for even 
>> reasonably simple failures.
>>
>> Now, it's easy to just write down *some* generic (or not generic) code to 
>> illustrate some level of readability. But to actually see the effects, a 
>> lot more and realistic code is needed and we *need* to talk about 2 and 3. 
>> An incredibly good example for how to discuss these is Ian's Proposal 
>> for type parameters 
>> .
>>  
>> It gives a detailed description of the power, the type-inference mechanism 
>> and the complexity of implementation. AIUI, it failed because of 3.
>>
>> Not every message or opinion about this, of course, needs this level of 
>> detail. But just ignoring the complexity is oversimplifying and doesn't do 
>> your position a lot of favor.
>> A better way to talk about readability would be, to take a real piece of 
>> code that you'd like to write generically (or predict that people would 
>> write), take one or two of the existing (declined) proposals and write your 
>> code down assuming it where implemented. The advantage is, that the 
>> proposals usually are detailed enough to meaningfully talk about the 
>> tradeoffs involved and to be sure that "the compiler can infer that" isn't 
>> just hand-waved.
>>
>> But Hot-Takes don't really help anyone.
>>
>> On Fri, Aug 25, 2017 at 10:11 AM, Egon  
>> wrote:
>>
>>> package tree
>>>
>>> type Node<$Entry> 

[go-nuts] Re: Generics and readability

[mhhcbon]

In first example Value can not do Less, its Entry, Entry has not been 
defined yet, its nothing.
Unless you introduce a Lesser interface and specify Node<$Entry:Lesser>

Given that specific example this notation looks pretty heavy, 
and even worse if d that be 
As this is all scoped into a type definition, why this prefix "node." ?
Also there s node everywhere, its confusing.


I m confused by the second example, the package declaration seems to 
declare what should be parametric.
It looks weird to import from another package.
Entry generic type is an interface, isn it ?


apart from this, why is side a double pointer ?


On Friday, August 25, 2017 at 10:11:11 AM UTC+2, Egon wrote:
>
> package tree
>
> type Node<$Entry> struct {
> Value $Entry
> Left  *Node<$Entry>
> Right *Node<$Entry>
> }
>
> func (node *Node) Insert(value node.$Entry) {
> var side **Node
> if node.Value.Less(value) {
> side = 
> } else {
> side = 
> } 
>
> if *side == nil {
> *side = {Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
> --
>
> package tree
>
> type Entry generic {
> Less(Entry) bool
> }
>
> type Node struct {
> Value Entry
> Left  *Node
> Right *Node
> }
>
> func (node *Node) Insert(value Entry) {
> var side *Node
> if node.Value.Less(value) {
> side = 
> } else {
> side = 
> } 
>
> if *side == nil {
> *side = {Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
>
> On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>>
>> Why would you put generics on a method ?
>>
>> The syntax you demonstrate is horrible, indeed.
>>
>> what if generics are type related
>>
>> type notFinal struct {
>>p1 
>>p2 
>> }
>>
>> func (n notFinal) whatever(in ) string {
>>return fmt.Sprintf(in) // anything to interface{}, works.
>> }
>>
>> type Final notFinal
>>
>> Final.whatever(1) // "1"
>>
>> //notFinal not instantiable, not type assertable
>>
>>
>>
>> Or func related
>>
>> type notFinal func(in ) string
>>
>> func Final notFinal
>>
>> Final(1) // "1"
>>
>>
>> That said, ultimately, the more the syntax is parametrized the more 
>> complex it become. when there are many func signature as you demonstrate, 
>> it will get worse.
>>
>> Named type might help, could be vetted too ?
>>
>> Also 
>> none of this is as powerful as code gen.
>> None of those examples are better than interface{}.
>>
>> On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>>>
>>> A lot of people like Go because code is very readable even for beginners.
>>>
>>> func f(x, y int)
>>>
>>> f is a function that receives x and y as int parameters, returning 
>>> nothing. Simple enough.
>>>
>>> func f(x, y int) int
>>>
>>> f is a function that receives x and y as int parameters, returning yet 
>>> another int. Fine.
>>>
>>> func f(x, y int) (z int, err error)
>>>
>>> f is a function that receives x and y as int parameters, returning two 
>>> values: a first int, that we name z and an error named err. A little bit 
>>> weird, but ok.
>>>
>>> func (r MyType) f(x, y int) (z int, err error)
>>>
>>> f is a method for a value of type MyType, henceforth named r, that 
>>> receives x and y as int parameters, returning two values: a first int, that 
>>> we name z and an error named err. Definitely not so simple.
>>>
>>>  func (r genType1) f(x, y genType2) (z getType2, err 
>>> error)
>>>
>>> You must be kidding. STOP RIGHT THERE!
>>>
>>>

-- 
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: Generics and readability

[mhhcbon]

Why would you put generics on a method ?

The syntax you demonstrate is horrible, indeed.

what if generics are type related

type notFinal struct {
   p1 
   p2 
}

func (n notFinal) whatever(in ) string {
   return fmt.Sprintf(in) // anything to interface{}, works.
}

type Final notFinal

Final.whatever(1) // "1"

//notFinal not instantiable, not type assertable



Or func related

type notFinal func(in ) string

func Final notFinal

Final(1) // "1"


That said, ultimately, the more the syntax is parametrized the more complex 
it become. when there are many func signature as you demonstrate, it will 
get worse.

Named type might help, could be vetted too ?

Also 
none of this is as powerful as code gen.
None of those examples are better than interface{}.

On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
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: Next generation code generator for go

[mhhcbon]

coolest repo to watch at that moment

On Wednesday, August 23, 2017 at 9:38:42 AM UTC+2, Walter Schulze wrote:
>
> I created gogoprotobuf, but I wanted to create a new code generator for go 
> that does not only work for protocol buffers, but for all go types.
>
> Here is my next generation code generation for go:
> https://github.com/awalterschulze/goderive
> goderive parses your go code for functions which are not implemented and 
> then generates these functions for you by deriving their implementations 
> from the parameter types.
>
> These functions includes:
>   - recursive functions like GoString and CopyTo
>   - functions for sets like Contains and Union and 
>   - functions from functional programming like Filter, Fmap and Compose 
> (monad)
>   - future: concurrent functions like applicative Do (from haxl)
>
> Use cases:
>   - More maintainable code
>   - Experience or experiment with what it would be like to use generic 
> functions in Go ... today.
>   - Create user stories for Go 2 in favour of or against generics.
>   - Don't argue about using labels and gotos, instead of just writing a 
> contains function.
>   - Do functional programming in go.  Well only partly because mutability 
> is still a thing.
>   - Less typing of: `if err != nil return err`. The compose function 
> implements monadic error handling.
>   - future: less error prone concurrency.
>
> Ready for production and experimentation.
>
>

-- 
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 one-line installer

[mhhcbon]

Hi,

As you at this kind of work, have you considered a reliable one-liner to 
install dependencies ?

I got that own, just today, from a gae repo (?), anyways here it is,

go get -u -v $(go list -f '{{join .Imports "\n"}}{{"\n"}}{{join 
.TestImports "\n"}}' ./... | sort | uniq | grep -v golang-samples)

Problem is, it did not quiet work for me when i put that into my travis :x
https://travis-ci.org/mh-cbon/dht/jobs/260206514

even when i restart the job.

Do you have any ideas how to fix that ?


thanks

On Tuesday, August 1, 2017 at 9:42:00 PM UTC+2, Steve Francia wrote:
>
> Greetings Gophers,
>
> I've been working on a "one line installer" for Go with Jess Frazelle and 
> Chris Broadfoot and we think it's ready to share a bit more broadly.
>
> The installer is designed to both install Go as well as do the initial 
> configuration of setting up the right environment variables and paths.
> It will install the Go distribution (tools & stdlib) to "/.go" inside your 
> home directory by default.
> It will setup "$HOME/go" as your GOPATH. 
>
> If Go is already installed *via this installer* it will upgrade it to the 
> latest version of Go.
>
> Currently supported systems:
>   linux, darwin, windows / amd64, 386 / bash, zsh, powershell
>
>
> *Usage*
> Windows Powershell:
> (New-Object System.Net.WebClient).DownloadFile('
> https://get.golang.org/installer.exe', 'installer.exe'); Start-Process 
> -Wait -NonewWindow installer.exe; Remove-Item installer.exe
>
> Shell (Linux/macOS/Windows):
> curl -LO https://get.golang.org/$(uname)/go_installer && chmod +x 
> go_installer && ./go_installer && rm go_installer
>
>
> As we discovered developing this, installers are really all edge cases. 
> We're certain we've not found many of them. 
> *Our goal is that this becomes the primary mechanism to install Go. *
> *To do that, we need your help testing, improving and fixing it. *
>
> The source can be found at 
> https://go.googlesource.com/tools/+/master/cmd/getgo/
> If you find any issues please report them on Github 
> https://github.com/golang/go/issues/new?title=tools/cmd/getgo:
>
> Thanks,
> Steve
>

-- 
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: Generics are overrated.

[mhhcbon]

"This thread was about concerns that generics would divide Go community"

that d would dismiss any attempt to propose generics *because* it s 
generics,
instead of the observation that the proposal does breaks everything 
including the community.

maybe the first thing to do is to ban this word "generics", so we can start 
thinking about facts,
rather than trying to pull a model and put it into go ?


On Sunday, July 30, 2017 at 3:14:27 PM UTC+2, dogan...@dodobyte.com wrote:
>
> Daily reminder: This thread was about concerns that generics would divide 
> Go community. Not about necessity of generics in general.
>
> Two possible scenarios:
>
> 1) Go have programmers from very different backgrounds, some used generics 
> often while others never used it. (e.g. Java and C). So different people 
> will use different features of Go with different style and practices. This 
> is the C++ mistake.
>
> 2) Go 2 will have such a fundamental new feature and Go 1 programmers will 
> avoid Go 2. To use old code base with Go 2, you have two options;
>  a- Mix Go 1 code with Go 2 code, new code uses generics while old code 
> does not.
>  b- Update Go 1 code to utilize generics.
>
> Personally i would rather stay with Go 1. This is the Python mistake.
>
> I may be wrong, this is only my concerns. 
>
> 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.

[go-nuts] Re: Generics are overrated.

[mhhcbon]

i have not read this,

1. i do go because the type system is helping me,
if i do js, i have no type system, so i have to figure this out by myself, 
its hard
if i d be doing java, i d end up with complex giant scaled type hierarchy, 

both cases, it d more a difficulty than an helper to my attempt to solve a 
real problem.

2. generics / not generics ?
i d rather think in terms of *capability*.
- i can t declare a func which returns the type it received, i feel like 
its a lack of basic capability.
- i can t generalize easily / elegantly some algo, again this looks likes a 
basic functionality.

should any of this be necessarily over complex, *i hope not*.

should any existing implementation is the right one, i believe not, for as 
much as i know (not that much, true :),
because they thought generics as a piece of software to integrate in a 
complex hierarchy of types (so they needed to parametrized their generics),
they made generics in their ways of thinking.

The day GO has found its way around those two difficulties *using **its way 
of thinking*,
- how to let the runtime leaks into the static type system (dont pre 
emptively define the world, locally solves problems)
- elegantly provide re usable algo (be DRY)
it d be an awesome language to write.

As a comparison, quickly i want to talk about php, before php4, there was 
not a type system,
since php5 they implemented a type system with class hierarchy based on 
Java and co (so called "leaders"),
IMHO, a total failure, php is no more php, its not java and co either, it 
became a bloat,
years later, i think about it and wish they took their inspiration from the 
go language,
they did not.

Do i want GO to become java because "its a leader", really not please, i d 
rather keep go 1.

3. compile time worries
I found it inadequate to worries yet about the compiler speed without a 
clear and meaningful change proposal.
Also, i wonder if we are worrying about a compilation time with no-cache, 
or with a hot cache.
Said as a question, is it a worry about 1% use case, or the 99% use cases ?
The consequence would be, how to re think this worry with new metrics, 
thresholds, explanations ?


On Friday, July 28, 2017 at 2:41:10 PM UTC+2, dogan...@dodobyte.com wrote:
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely 

[go-nuts] pointer lifetime management ?

[mhhcbon]

Hi,

in this silly code, with a very naive main, 
which i think is a small representation of some situations 
we might face irl on larger code base.

https://play.golang.org/p/qv5ymHDzr2

Lets say the story of this code is,
at first we needed to store values,
then we discovered an allocation issue,
third, we tried to fix it,
fifth all tests passed with no changes,
sixth when we run it on long duration, 
everything was misbehaving.

is there anything that can be done so 
the naive programming of the main does not behave unexpectedly ?

As a side note, i d say if consumer would not take an interface, 
but a concrete value, it is then possible to enforce a copy,
but i did choose an interface on purpose for the silly example.

-- 
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: Proposal: Blank types instead of Generics for Go 2

[mhhcbon]

if we could have a list of use case, 
written in g1, with an explanation about why it can t be generalized, 
we could check any proposal that at first it answers them, 
then enter into more detailed study and proposals ?

I m reluctant to provide examples about concurrency, 
i have some ideas of what functions i need, 
i m not hot to write them...

At least here is some func i wish was generalized
- concurrentSync(sync func(...)..., concurrency int) (wrappedSync 
func(...), cancel chan struct{})

- concurrentAsync(async func(..., jobDoneSignal chan struct{})..., 
concurrency int) (wrappedSync func(..., jobDoneSignal chan struct{})..., 
cancel chan struct{})
(this sig is s long...)

- throttle (call a func at most once every D time.Duration) 
 throttle(f func(...)..., d time.Duration, head bool) (throttledFunc 
func(...)..., cancel chan struct{})
- mustNorErr ?

then stuff like map.Each, slice.Each etc.

That being said, in

func Add1(key $A, val $B, m map[$A]$B) {
m[$A] = $B
return
}


It will trigger a runtime error if $A is of type []byte (met that error 
yesterday with an interface{} type).

So, as the bloat already exists with interface{}, is it something to 
keep or to remove ?
More generally at which extent runtime 42 errors are acceptable, 
or should be used to compromise a prefect/ideal model in order to 
simplify/fix  ?



On Sunday, July 23, 2017 at 10:17:04 AM UTC+2, meta keule wrote:
>
>
> Hi,
>
> here is a proposal for an alternative to Generics for Go2:
>
> https://github.com/golang/go/issues/21132
>
> Please discuss!
>
>
>

-- 
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] "interface{} says nothing", lets consider it destroys information

[mhhcbon]

here is a solution to what i described in previous.

The result of
func mustNotErr(f func() (, error)) func() () {}
is the transitivity of t -to> func (...) (..., *-*error)

mustNotErr takes in input
a func T with any inputs, and a *traling* error, 
returns in output,
the func T *less* the trailing error.

- Given
func W() (X, error){}
func W1(a A, b *B) (Y, X, error){}
- Want
func MustW() (X){}
func MustW1(a A, b *B) (Y, X){}

Which literally is,
W() (X, error) -> less a trailing error ->MustW() (X)
W1(a A, b *B) (Y, X, error) -> less a trailing error ->MustW1(a A, b *B) 
(Y, X)

Which in can be written such as
W() (X, error) -> func (...) (..., *-error*) ->MustW() (X)
W1(a A, b *B) (Y, X, error) -> func (...) (..., *-error*) ->MustW1(a A, b 
*B) (Y, X)

So the solution might looks like

mustNotErr := func(f ) t->func (...) (..., *-error*) 
{
 return func(params ...Parameters) ... {
...ret, err := f(params...)
if err != nil {
panic(err)
}
return ret...
 }
}


On Friday, July 21, 2017 at 10:32:21 AM UTC+2, mhh...@gmail.com wrote:
>
> so wise! thanks for those clarification.
>
> I did not deeply understand why it is called an identity func, and why it 
> has to be this signature.
> It seems so narrowed to a specific case, makes me unhappy.
>
> Now, i realized that even if , for some specific cases, seems to solve 
> some situations,
> it won t be enough to implement the kind of things i presented, 
> function composition (do -> to composition).
>
> My example was to simple.
>
> A better func to think about is *mustNotErr*.
>
> mustNotErr is not implementable using , but lets take a look what he d 
> be,
>
> func mustNotErr(f func() (, error)) func() () {}
>
> In plain text, it is a func that takes in parameter a func and returns a 
> func.
>
> but if you take some realistic example you ll get something like
>
> func W() (X, error){}
> func W1(a A, b *B) (Y, X, error){}
>
> And now we can observe that size, positions, and types 
> of the delayed func IO/parameters are the differences 
> that are not matched in my previous declaration of mustNotErr.
>
> mustNotErr takes no parameter, returns only 2 parameters
> f() (A,B) -> matches W, but not W1.
>
> But, intuitively we feel that W and W1 can be factorized to something like 
> this,
> a func  func(
> with any input parameters   ...
> ,   ) (
> returns any parameters,  ...
> followed,,
> by a traling error  error
> )
>
> yeah ?
>
> Using that definition, let s see what it might look likes,
>
> mustNotErr := func(f ) *???* {
>  return func(params ...Parameters) *???* {
> ...ret, err := f(params...)
> if err != nil {
> panic(err)
> }
> return ret...
>  }
> }
>
> Where Parameters{Value,Type}
> Where "...,error" ~~ any front parameters until error
> Where "...ret, err :=" ~~ any front parameters until error
> Where "return ret..." ~~ any values in []Parameters
>
> The problem now is about the type of the returned func,
> it is not  anymore, because the error return parameter was removed,
> on the other hand, as a declarer we dont know enough about f, to return a 
> complete function,
> it literally is func(...)(...)
>
> But func(...)(...) is not a type a receiver can consume
>
> At that point, some sort of templating is required, indeed,
> or what, partial types ? looks bad...
>
>
> On Thursday, July 20, 2017 at 10:25:30 PM UTC+2, Jesper Louis Andersen 
> wrote:
>>
>> On Mon, Jul 17, 2017 at 11:07 AM  wrote:
>>
>>> does it make sense to consider a "value type of any type that carries 
>>> out its input type" ?
>>>
>>
>> Yes. This is called a "universal" and is related to the concept of 
>> parametrization by J. Reynolds.
>>
>> Your 'do' function is often called 'id' for the obvious reason that it is 
>> the identity function. In SKI logic it is the I combinator. If we annotate 
>> the type as you would in type theory, you would write something like
>>
>> id : (T : Type) -> T -> T
>> id t x = x
>>
>> to say that the function can be instantiated with any type 'T' you 
>> desire. The actual implementation of 'id' takes two parameters. First it 
>> takes the desired type and then it takes the parameter and returns it. 
>> Writing 'id Int' is a partial invocation. It "plugs in" the T and yields a 
>> function of type 'Int -> Int'. Likewise, 'id String' plugs in strings in 
>> the position. Interestingly, Reynolds showed that if the function 'id' is 
>> to work for *any* type T at the same time, it *must* have the above 
>> implementation. No other implementation is valid. This is the concept of 
>> parametrization. Even better, the type T can be a type outside of the type 
>> system of the programming language!
>>
>> But do note there is no 

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

[mhhcbon]

In func Foo(value T)T { /.../ }

It makes sense to anchor the definition of T to the func name.

I feel like it is not needed, and i wonder about multiple T parameters.

Where the question here is about

func Foo(x , y ) (, ){}
Or
func Foo(x t, y u) (t, u){}


At least, it is possible to say your version has more impact on the overall 
syntax than my initial proposal,
because using your version there will be new things like

bar := Foo(3)

In my proposal, because 3 is an int,  is solved.


another very questionable thing, 
if you have  (basic type), you can return only a (string), or 
destruct it into another type (strconv.Atoi).
that happens because string does not match any interface, its basic.
So f() seems totally useless and redundant to f(string).

  is really interesting with structs and interfaces,
because struct can have as many facets as there is interface it satisfies.
- its open for the caller, you can inject and receive any type that 
satisfies the contract
- closed to the declarer, it must become a meaningful type before you 
actually interact with it




Aside of this, i have lots of troubles to write the clear distinction 
between interface{} and interface.
I d really like we had another keyword like *contract* to define an 
interface.
or empty{} rather than interface{}.

Anything that get rides of this naming problem.

On Thursday, July 20, 2017 at 3:40:00 PM UTC+2, M P r a d e s wrote:
>
> Go could have least have parametric functions (ex :
>
> func Foo(value T)T { /.../ }
>
> bar := Foo(3) //types are verified at compile time, no need for 
> reflection or interface {} on any runtime trick.
>
> ).
>
> But talking about this is kind of useless until Go rids itself of its over 
> reliance on runtime features like reflection. I suspect Go reflection 
> capabilities are why the language stopped evolving significantly at first 
> place. String tags are another symptom of that "disease".
>
> It's possible to write the snippet above with reflection today 
> (reflect.MakeFunc) , it shouldn't be.
>
>
>

-- 
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: "interface{} says nothing", lets consider it destroys information

[mhhcbon]

I think your example is not relevant, as it clearly intend to change the 
input type,
the goal is to preserve it, while still working with its value.


interface{} value type destroys the input type information,
so you might have the opposite value type, 
a type that preserves.
A type that let you write, *func, please, return the type i got*.

I did not mention templating, code generate / whatever/  like in 
https://en.wikipedia.org/wiki/Generic_programming

I read something related in "*Generic programming* is a style of computer 
programming  in which 
algorithms  are written in terms 
of types  *to-be-specified-later* 
that are then *instantiated* when needed for specific types provided as 
parameters 
." 

...*to-be-specified-later... *runtime leaks in the static type system, 
mostly a question of pov.

-  behaves like interface{} value type, because it does still say 
absolutely nothing. Not because it lacks of identity, but because it 
represents too many possible type.
-  is a shorthand to avoid a, probably, very repetitive type 
assert in order to use a , much like an interface{}, but better, because 
its shorter
-  can be use only in func/method parameter (*excluded *receiver) ? I 
have not been able to find it meaningful elsewhere. 
- if you don t need to return the input type, you don t need 
- ultimately, []interface{} == [], they both are list of stuff we have 
no idea what its about, but  has no sense if it is not scoped to a 
function call stack.
- ultimately, [] does not make sense.

- when you receive a func (x )  {}, it does actually says nothing to 
you, the declarer of the func, not because it lacks of identity, but 
because it represents too many possible types. If you d want to do 
something of it, you need to type assert it, to narrow it to something 
meaningful.
- when you receive a constrained , you can work on value of 
type Interface, and you can return whatever, including the input parameter 
type
- when you call a func with a constrained type, you can actually statically 
verify that the input value satisfies the constraint.
- when you call a , anything is as good as nil (i guess)



On Wednesday, July 19, 2017 at 11:47:40 PM UTC+2, Eric Johnson wrote:
>
> While I lean towards the view that Go should add support for type 
> generics, I'm not sure your example actually provides sufficient detail to 
> be an argument for them.
>
> On Monday, July 17, 2017 at 2:07:46 AM UTC-7, mhh...@gmail.com wrote:
>>
>> in func do(i interface{}) interface{} (return i), do says nothing because 
>> "interface{} says nothing", 
>>
>> from the caller pov, it looses information at the return call, 
>>
>> var x = "o"
>> do(x) // <- return lost the track it was a string
>>
>> if you delegate that func to another func, 
>> it can t says anything else rather than nothing unless it introduces type 
>> assertion.
>> func to(do func(interface{})interface{}) func (interface{}) interface{} { 
>> return func (i interface{}) interface{} {return do(i)} }
>>
>> if the observation become "interface{} destroys information", 
>> does it make sense to consider a "value type of any type that carries out 
>> its input type" ?
>> func do(any )  {return any}
>> do("thing") <- this is explicitly string
>>
>> Acting the same way as interface, except that little thing about 
>> destroying/preserving an information.
>>
>> It can be delegated to func that works on anything, still returns 
>> concrete types.
>> func to(do func(**)) func () ** { return func (i )  
>> {return do(i)} }
>>
>> to(do)("whatever") // got a string, right ?
>>
>> One step forward, 
>> what if  might be able to say "any type with a constraint on that 
>> interface",
>> func do(any )  {return any}
>> do(WhateverStringerCapable{}) <- much like using a regular parameter of 
>> type Stringer/interface{}, but now the return call reflects the invoke call 
>> , so its more complete than interface{}/Stringer.
>>
>
> If the "do" method takes and returns a Stringer, then why not just declare 
> it that way? To make this a more interesting discussion, you have to get 
> into the details of what the "do" function actually needs to do? Why can't 
> it just use standard interfaces?
>
> As I see it, one of the generics problems comes from using the built-in 
> slices and maps. As it current stands, if I create a method:
>
> func concat(foo []Stringer) String {
> result = ""
> for _, s := range foo {
> result = result + s.String() + ";
> }
> return result
> }
>
> but suppose I have two structs, Foo, and Bar, and both *Foo, and *Bar 
> implement Stringer.
>
> I cannot do this:
> func myFunc(f []*Foo, b []*Bar) string {
> return concat(f) + concat(b)
> }
>
> This seems like a more concrete scenario than the one you identified.
>
> Eric.
>  
>

[go-nuts] "interface{} says nothing", lets consider it destroys information

[mhhcbon]

in func do(i interface{}) interface{} (return i), do says nothing because 
"interface{} says nothing", 

from the caller pov, it looses information at the return call, 

var x = "o"
do(x) // <- return lost the track it was a string

if you delegate that func to another func, 
it can t says anything else rather than nothing unless it introduces type 
assertion.
func to(do func(interface{})interface{}) func (interface{}) interface{} { 
return func (i interface{}) interface{} {return do(i)} }

if the observation become "interface{} destroys information", 
does it make sense to consider a "value type of any type that carries out 
its input type" ?
func do(any )  {return any}
do("thing") <- this is explicitly string

Acting the same way as interface, except that little thing about 
destroying/preserving an information.

It can be delegated to func that works on anything, still returns concrete 
types.
func to(do func(**)) func () ** { return func (i )  
{return do(i)} }

to(do)("whatever") // got a string, right ?

One step forward, 
what if  might be able to say "any type with a constraint on that 
interface",
func do(any )  {return any}
do(WhateverStringerCapable{}) <- much like using a regular parameter of 
type Stringer/interface{}, but now the return call reflects the invoke call 
, so its more complete than interface{}/Stringer.

no?

Or maybe there is a reason in destroying that information ?

-- 
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: Pure go based Automated Browser simulation without any driver

[mhhcbon]

chromedp seems lovely.

https://www.youtube.com/watch?v=_7pWCg94sKw

On Thursday, July 13, 2017 at 2:48:54 AM UTC+2, Tong Sun wrote:
>
> I bumped into a pure go based tools that can be used as an automated 
> Browser simulation, just like Selenium but *without any driver* 
> selenium-webdriver/PhantomJS or anything, just *pure go based*.
>
> However, I didn't save the URL and now I just can't find it anywhere any 
> more. That why I have to describe it as fully and as closely I can remember 
> about it. 
>
> Does the above rings a bell for anybody? Do you know anything that sounds 
> similar? 
> It's still in its very early stage, and the web site says that the 
> features maybe changed any moment. 
> Thx!
>
>
>

-- 
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: justforfunc: a Go YouTube series

[mhhcbon]

yes that s right, a good back to basics. 
But not only, it also make sense of TeeReader 
(https://golang.org/pkg/io/#TeeReader).

Also, i wanted to comment afterward that none of fmt.Fprintf(os.Stderr / 
log.PrintF are perfect.
Using fmt, its laboriously long to write, using log.Printf, it might not be 
the desired formatting.

On Tuesday, July 11, 2017 at 2:07:25 AM UTC+2, Francesc Campoy Flores wrote:
>
> Hi gophers,
>
> Sorry to spam you, but I'll do it only once! Today I published the episode 
> 15 of a YouTube series 
> 
>  
> I've been working on for a while.
>
> I think it is becoming a quite good resource for gophers looking for best 
> practices, code reviews, and some fun projects.
> All of the code is of course open source at github.com/campoy/justforfunc.
>
> You're invited to check it out, and send any feedback to 
> form.justforfunc.com or directly to my email :)
>
>
> 
>
> Francesc
>

-- 
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: RFC: Blog post: How to not use an HTTP router

[mhhcbon]

hi,

I understand what / why you came to that given your explanation,
but I disagrees a lot to it.

I don t feel like expanding code helps to better explain 
the how/what/why of a sudden 42 question ? (why this /whatever/ has failed, 
I believe it should not)

I m pretty sure its a good way to multiply keystrokes, and harden 
maintenance and changes.

In the example you taken, because its not representative of all 42 
questions** (only few ones),
the solution is to provide a more speaky app.

In your post you take that route example,
"/articles/{category}/{id:[0-9]+}"

And later expand and rewrite it to return a proper error when an id is not 
an int,
Behavior that is totally excluded at the moment you decided
to apply a pattern on your route.

You are comparing things that are not comparable, 

the route can be
"/articles/{category}/{id}"

The gorilla handler can handle the type checking and return a proper error 
code.

So, you can resolve the 42 question,
not by diving in the code,
but by reading the error messages, 
or *reading at the documentation.*

(note: reading the error messages=> totally fail when you develop a 
website, not an api, as the error page is often generic and do not provide 
a deep explanation of the error, as the end user does not care about it, 
sometimes you can trick about it (put that in some comments/whatever/) but 
any serious security test team will warn you about it)

Or that /foo/123 is, technically, an illegal argument, not a missing page. 
I couldn't really find a good answer to any of these questions in the 
documentation of gorilla/mux for what it's worth. Which meant that when my 
web app suddenly didn't route requests correctly, I was stumped and needed 
to dive into code.


None of the solution compared here, ie gorilla vs plain code, manages 
correctly this feature.
In both case its an additional job to be done, in one way or another.

Somewhere you also talk about the idea that using a router would tightly 
link
components by their types, adn that is bad in your opinion.

In my opinion, I m very happy about tight types coupling. 
Like very very very very very very very happy about that.

Its the only thing i can rely on 
to apply an understanding and validates that things gonna work 
without being able to provide a formal proof (if i could, tbh).

*Type* here can be an interface or a value, that does not matter, their 
guarantees matter.


Something i truly agree with you,

They only need to know about the immediate handlers they delegate to and 
they only need to know about the sub-path they are rooted at


Local problem solving is always way easier to handle 
than large scaled problems across files/packages/concepts.

In that regard i do agree with you about the last proposal you give in its 
intentions,
I clearly disagree in its implementation,
it just not gonna work for me to write that much of code to solve those 
problems.

** the other kind of 42 questions is about functions that behaves 
differently from what the user expects.
Which happens in few cases, wrong documentation from author, misreading 
from consumer, and at least that third one, a name which is both too vague 
and too precise to give sufficient meaning about its purposes by itself,
example

/whatever/.Each() /whatever/ {...}

You can t tell what s going to happen in Each (will that call allocate?) 
without knowing what is /whatever/,
if whatever is an array, you can *deduce* there will be an allocation,
if its something else like a stream, you can *deduce* it won t.
Because the name is not sufficient to describe its meaning on a so vague / 
general context, 
the problems takes scale, thus have an air of mystery.

That happens only with some kind of names, 
as soon as you enter a specific context (what mean to Put to a dht table 
?), 
you gonna need to learn the specifics of the problem before, 
by definition the local question is scaled to the context of your general 
situation (something like this),
naturally its has an air of mystery, 
naturally you need to learn and assert about the details (via the code or 
the doc).

_

about the question, why there s so much alternative routers.

My personal opinion, gorilla mux is great, but its an enter step for many 
people,
so they need to learn both the language + the framework + quickly they need 
to assimilate
some pretty fine tune trick of the language to keep going,
and so it become difficult, and so alternatives has a reason to happen.

Also some constructs, while being very verbose, are not obvious...

http.Handle("/static/", http.StripPrefix("/static/", 
http.FileServer(http.Dir("./public"


Super verbose.

So clear that we need stackoverflow to make it happen the first time.

Another possible reason, as all in things in golang, 
it has to be verbose,
we ain t all like that, 
easy path for a developer to think that i can fix that.

And no, i m not saying verbosity is bad, 
i m saying that verbosity is not 

[go-nuts] Re: go get in parallel

[mhhcbon]

hi,

in immediate terms, assuming you have something like
go get a
go get b
go get c

Can this https://github.com/mh-cbon/cct#usage be of help ?

I did not tested, but it should be,

cct -add -timeout 20 go get a
cct -a 1 go get b
...

cct -wait 1


I m sorry it looks likes i have not implemented exit code management yet
https://github.com/mh-cbon/cct/issues/1 ... : /

On Monday, June 5, 2017 at 6:43:34 PM UTC+2, David Prime wrote:
>
> Hi All,
>
> I've got a few jenkins jobs that end up doing quite a lot of go-getting as 
> part of a clean build process. I find the slowest bit of the whole process 
> is go get sequentially resolving/downloading everything. Would making this 
> parallel be doable? Would it be desirable? Am I doing something wrong in 
> the first place which means I probably shouldn't need parallel getting?
>
> Thanks,
> David
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

On Sunday, June 4, 2017 at 6:25:17 PM UTC+2, Egon wrote:
>
> I think you are missing the point of my comment.
>
> I'm all for generics, but I also can survive without them without much of 
> a problem. (I'm even maintaining 
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4
>  
> to understand the problem better)
>

that s actually a good pointer.
 

>
> The issue I was trying to highlight was that you are proposing solutions 
> to a problem, but other people don't know what your exact problem is. Hence 
> my 3 lines version are equivalent in their result and value, because the 
> problem is missing. 
>
 
if i m right you argue the fact i did not come up with a complete 
formalized approach.
I did not intended to, i think i tried to force open door of what is hiding 
under the noise, to think out loud.
In the end i expect to either provide one example where its a definitive 
no-go and its possible to explain why.
or sufficient expected real world use cases to start consider it for later 
implementation.
But in one-way-communication this obviously can not happen.
 

>
> Similarly, when we don't have a concrete problem we could over-engineer 
> the generics or alternatively solve the wrong problems.
>
> For example, when the solution you propose only solves 5% of the problems 
> that generics needs to solve... or vice-versa... a generics solution 100x 
> simpler would solve 99% of the cases... then what is the value of the 
> proposed solution?
>
> So, which of the 147 different generics approaches/implementations works 
> better for Go and why? (I'm also counting the ones that aren't known yet :D)
>
> When you would use a real-world example and problem, it would be possible 
> to argue that one approach is better than the other... without one, this 
> discussion doesn't lead to anywhere.
>
> + Egon
>
>
Just to clarify, 
i m not really in favor of generics per se,
i have enough to deal with right now to not add more complexity here.
In *here* I mean both declarer and consumer sides of an api programming.

But still i can t go with the existing, 
so i did try to solve the problem on my hand, 
but it happens it simply require a more in depth solution, 
the current superficial solution i can think about will always be limited 
by what has been well resumed earlier by utyug 
"or I could use empty interfaces which throws type safety out the window".
 

> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote:
>>
>> given the fact that actually everybody disagrees on that idea, 
>> or even something similar according to some feedback.
>>
>> I want to put the question differently.
>>
>> My mean is to say that golang is a basis to build upon in general that is 
>> better
>> than other existing solutions.
>>
>> imho, golang is governed by its compatibility requirement,
>> and, an extremely vertical approach,
>> which blocks every possible update to the dogma: 
>> is it go 1.0 compatible ?
>>
>> And because its vertical, is it to my taste ?
>>
>> The go 1.0 compatibility requirement makes everybody very happy.
>>
>> Still, I dont believe the language is considered as finalized by a 
>> majority of users.
>> Some will say it misses generics, some other (..) will try different 
>> approach.
>>
>> Why should it be that much of frictions ?
>>
>> Why can t we evaluate a solution where multiple vision co exists ?
>> Handle the change.
>>
>> Aint there existing case of such kind of symbiosis which benefits each 
>> other on the long term ?
>>
>> A solution where the go 1.0 requirement is kept valuable, 
>> and a new language target where this requirement has been removed.
>> A transpiler to go 1.0 compatible code ? 
>> So both can exist ?
>>
>> my 2 cents, 
>> that close and negative answer i got,
>> is not helpful nor inclusive,
>> its like take or leave attitude,
>>
>> it d just be more inclusive to say that 
>> it is ok to make a transpiler/or whatever it should be/ implementing your 
>> idea, 
>> check that resource for further implementation come back here for 
>> questions.
>>
>> Other consideration, 
>> the idea that golang 1.0 is used to build a different language target 
>> that compiles back to go1.0, 
>> looks cool.
>>
>> On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote:
>>>
>>> for the fun, with early return,
>>>
>>> https://play.golang.org/p/I9AORKOYQm
>>>
>>> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:

 > Generics enable more than just replacing loops. For example, they can 
 enable libraries of generic algorithms to be used with any type of array. 
 Here's an example:

 in my demonstration every type got this kind of method,
 the problem become how do you jump from Type A to type B.
 in []A to []B or A -> B

 indeed it works on the item level, no more on the collections.

 This question is solved in two ways,
 - interface definitions (not interface value)
 - static 

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

as anyway the thread has completely derived,
its the right place to put about that.

I recently read about stanford choosing to use JS over Java
for some its courses.
https://www.theregister.co.uk/2017/04/24/stanford_tests_javascript_in_place_of_java/

I can t understand.
If a beginner ask me which language he should learn,
i d say go,
i d say him, stay put, its unfortunately not easy to enter, but its gonna 
be a great learning place.

I was an heavy user of javascript, 
i loved it for its stream api,
i hated it because of its stream api.

I say its not a good language for beginners,
its apparent ease hides a much greater complexity,
and it does not teach the traditional programming science,
but it has those good things like 
its a local problem solver rather than a define all the world approach.

Anyway, my point is to say that i see in this decision of the stanford 
university 
the proof that something has to happen.

THey were teaching Java before, how it come they chosen JS over go ?

On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>
> see the title, only for what s needed 
> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
> so interface system serves the userland by its definition of struct, and 
> the basic slice type provided by the language is fully operational, without 
> breaking, btw. i don t go further in evaluation, i leave that to the 
> reader, just trying to work decently.
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

I want to emphases that go generate 
is so far an awesome solution, 
but not a definitive answer.

Yes, it could made easier,
about that, its already great that all the tools we need 
are written in go itself, this is really really really helpful.

On Monday, June 5, 2017 at 5:59:46 AM UTC+2, utyug...@mail.com wrote:
>
>
>
> On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote:
>>
>> I think you are missing the point of my comment.
>>
>> I'm all for generics, but I also can survive without them without much of 
>> a problem. (I'm even maintaining 
>> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4
>>  
>> to understand the problem better)
>>
>
> create a custom container type that I can use with any type out-of-the-box.
>
> for example: iset := make(Set[int],9); sset := make(Set[string],9); pset 
> := make(Set[Person]);
>
> right now, my solution is to rewrite the source with go generate calling a 
> tool i wrote which grew out from a great talk from robert griesemer. The 
> video: https://www.youtube.com/watch?v=vLxX3yZmw5Q
>
> This solution has nearly twice the performance increase over maps with 
> almost every type used so far. Now I could have just written the 500 lines 
> of code over and over again for every type needed until the end of time(or 
> copy and paste and edit until the end of time), or I could use empty 
> interfaces which throws type safety out the window, but I chose to write a 
> tool, and when go generate came to be I chose to use that tool like a 
> simple script executed within a '//go:generate go run..' tag.
>
>
> Over time golang(I do this now to annoy the zealots) provided the 
> tools(reflection, /go packages, go generate) that made creating custom 
> generic type safe containers easier. These things weren't always this easy, 
> and these things could be easier.
>
> And I am serious about create a custom container type that I can use with 
> any type out-of-the-box. Please indulge me, how would you solve this 
> problem. Provide a solution for a simple type-safe container type Set that 
> takes any type, with a simple api of 
> insert,remove,contain,union,difference,intersection, 
> complement,superset,subset.
>
> I've seen you provide solutions in the past, so I would like to see your 
> solution to this not-much-of-a-problem.
>  
>
>>
>> The issue I was trying to highlight was that you are proposing solutions 
>> to a problem, but other people don't know what your exact problem is. Hence 
>> my 3 lines version are equivalent in their result and value, because the 
>> problem is missing.
>>
>> Similarly, when we don't have a concrete problem we could over-engineer 
>> the generics or alternatively solve the wrong problems.
>>
>> For example, when the solution you propose only solves 5% of the problems 
>> that generics needs to solve... or vice-versa... a generics solution 100x 
>> simpler would solve 99% of the cases... then what is the value of the 
>> proposed solution?
>>
>> So, which of the 147 different generics approaches/implementations works 
>> better for Go and why? (I'm also counting the ones that aren't known yet :D)
>>
>> When you would use a real-world example and problem, it would be possible 
>> to argue that one approach is better than the other... without one, this 
>> discussion doesn't lead to anywhere.
>>
>> + Egon
>>
>> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote:
>>>
>>> given the fact that actually everybody disagrees on that idea, 
>>> or even something similar according to some feedback.
>>>
>>> I want to put the question differently.
>>>
>>> My mean is to say that golang is a basis to build upon in general that 
>>> is better
>>> than other existing solutions.
>>>
>>> imho, golang is governed by its compatibility requirement,
>>> and, an extremely vertical approach,
>>> which blocks every possible update to the dogma: 
>>> is it go 1.0 compatible ?
>>>
>>> And because its vertical, is it to my taste ?
>>>
>>> The go 1.0 compatibility requirement makes everybody very happy.
>>>
>>> Still, I dont believe the language is considered as finalized by a 
>>> majority of users.
>>> Some will say it misses generics, some other (..) will try different 
>>> approach.
>>>
>>> Why should it be that much of frictions ?
>>>
>>> Why can t we evaluate a solution where multiple vision co exists ?
>>> Handle the change.
>>>
>>> Aint there existing case of such kind of symbiosis which benefits each 
>>> other on the long term ?
>>>
>>> A solution where the go 1.0 requirement is kept valuable, 
>>> and a new language target where this requirement has been removed.
>>> A transpiler to go 1.0 compatible code ? 
>>> So both can exist ?
>>>
>>> my 2 cents, 
>>> that close and negative answer i got,
>>> is not helpful nor inclusive,
>>> its like take or leave attitude,
>>>
>>> it d just be more inclusive to say that 
>>> it is ok to make a transpiler/or whatever it should be/ implementing 
>>> your idea, 
>>> check that 

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

given the fact that actually everybody disagrees on that idea, 
or even something similar according to some feedback.

I want to put the question differently.

My mean is to say that golang is a basis to build upon in general that is 
better
than other existing solutions.

imho, golang is governed by its compatibility requirement,
and, an extremely vertical approach,
which blocks every possible update to the dogma: 
is it go 1.0 compatible ?

And because its vertical, is it to my taste ?

The go 1.0 compatibility requirement makes everybody very happy.

Still, I dont believe the language is considered as finalized by a majority 
of users.
Some will say it misses generics, some other (..) will try different 
approach.

Why should it be that much of frictions ?

Why can t we evaluate a solution where multiple vision co exists ?
Handle the change.

Aint there existing case of such kind of symbiosis which benefits each 
other on the long term ?

A solution where the go 1.0 requirement is kept valuable, 
and a new language target where this requirement has been removed.
A transpiler to go 1.0 compatible code ? 
So both can exist ?

my 2 cents, 
that close and negative answer i got,
is not helpful nor inclusive,
its like take or leave attitude,

it d just be more inclusive to say that 
it is ok to make a transpiler/or whatever it should be/ implementing your 
idea, 
check that resource for further implementation come back here for questions.

Other consideration, 
the idea that golang 1.0 is used to build a different language target that 
compiles back to go1.0, 
looks cool.

On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote:
>
> for the fun, with early return,
>
> https://play.golang.org/p/I9AORKOYQm
>
> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:
>>
>> > Generics enable more than just replacing loops. For example, they can 
>> enable libraries of generic algorithms to be used with any type of array. 
>> Here's an example:
>>
>> in my demonstration every type got this kind of method,
>> the problem become how do you jump from Type A to type B.
>> in []A to []B or A -> B
>>
>> indeed it works on the item level, no more on the collections.
>>
>> This question is solved in two ways,
>> - interface definitions (not interface value)
>> - static conversion, which always resumes to 
>> func(in-type) out-type
>>
>> and some alternatives for convenience (producer/consumer)
>> func (func(in-type) out-type
>> func (in-type) func() out-type
>> func (func(in-type) func() out-type
>> // this is unfinished explanation it should include error management to 
>> be handled more completely. see please previous conv() fn introduced 
>> earlier to statically re decorate a func signature.
>>
>> So far the sum/reduce things operation,
>> i left them as exercise to the stream declarer
>> and did not consider them as core.
>> Take become => filter (func(10 elements))
>> Map is map
>> Sort is All(fn sorter) []out
>> Reduce is a map operation, preceded by a conv if it reduces to a 
>> different type.
>>
>>
>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
>> wrote:
>>>
>>> Generics enable more than just replacing loops. For example, they can 
>>> enable libraries of generic algorithms to be used with any type of array. 
>>> Here's an example:
>>>
>>> foo := GetArray()
>>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>>
>>> That is simple to understand and in one line of code. Imagine the 
>>> acrobatics (and lines of code) needed to do this using Go's loops!
>>>
>>> You can read my full article on why Go needs generics here: 
>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>>
>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:

 Since everyone thinks it but nobody bothers to reply to it: this whole 
 thing you propose can be currently done with a for loop, which not only is 
 explicit about what it doing, but it also lets you control if you want to 
 exit early from it and so on. Complicating the whole language because 
 something is cool (yet looks like a really complex thing that you need to 
 think about while reading the code) is in no one's benefit. Stop trying to 
 avoid a couple of extra rows of for {} (where the third row is literally 
 just an "}")  and start embracing the fact that you can understand the 
 code 
 by looking at it and not apply any complex mental acrobatics to figure out 
 what those three lines of code are doing. Your future self/person after 
 you 
 will thank you for 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

I feel much better with this, 
than its counter part,
but what s the point, this is so much about a personal opinion.

func (p PackageInfo) DeepEmbeddeds(structName string) (ret StringSlice) {
strut := p.GetStruct(structName)
if strut.GetName() == structName {
e := strut.Embeddeds()
e.Filter(p.IsInterface).Each(ret.Append)
e.Filter(p.IsStruct).Each(func(s string) {
p.DeepEmbeddeds(s).Each(ret.Append)
})
}
return 
}

Ain t exactly what i want, 
still can t convert with ease,
but so much clearer.

If you put performance issue aside,
i feel like the only argument opposed so far 
is a about 
- a somehow more complex code,
- a subjective matter of taste.

for 1, take a look at SO and newbies questions
about chan, you should have some fun.
fun² I remember some trying to build very similar constructs on top of chan.

for 2,
2.1 YOLO, i want better structure to program faster, i might not be doing 
the right thing because i ain t yet understood the language correctly, yet, 
i want to benefit the whole environment provided by it, ultimately, that i 
m right or wrong, does not matter in the immediate terms of getting 
productive, i m only looking for ways to program faster by reducing all 
those additional constructs.

In other words, 
I want to trade *write speed* Vs *write clarity*.

See also that unwinding such constructs, when its not non sense, is trivial.
Thus, if you do a performance analysis and you find that construct in a hot 
path, you can tell, 
lets unwind it.

2.2 blah, if google wants to try to rule the world
with its internal guideline book, 
well it look likes it might keep trying,
users will still look for this kind of structure, i believe.

Down that path, the question does not become,
what s acceptable for my guidelines book,
but,
how i can best handle user needs, 
provides what s needed to avoid a disaster with the tools given by the 
language.

Anyway, if golang is to be successful (I mean like java), 
i don t doubt that down the road 
it will come to something similar, 
with generics, or not.

gettin' the pop corn : )

On Saturday, June 3, 2017 at 6:35:49 PM UTC+2, Egon wrote:
>
> On Saturday, 3 June 2017 13:11:04 UTC+3, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> yes generics / not generics.
>>
>> That is, in what i proposed, only the consumer is enhanced, thus generics 
>> are not required anymore on the declarer, except for this conv method, 
>> indeed.
>>
>> also as the declarer can rely on more powerful tool on the consumer, 
>> it needs to declare less to able more.
>>
>> That being said,
>>
>> Can you take a look to that, genericity less, it works
>>
>> https://gist.github.com/mh-cbon/2062efef48e246592bdb0665f0ab8547
>>
>> IMHO, its simple, it does what i need, it helps me to avoid obvious 
>> gotchas,  after many attempt i feel satisfy, 
>> please critic it.
>>
>
> I think this version is much clearer: https://play.golang.org/p/9DfxObeDj3 
> :P
>  
>
>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
>> wrote:
>>>
>>> Generics enable more than just replacing loops. For example, they can 
>>> enable libraries of generic algorithms to be used with any type of array. 
>>> Here's an example:
>>>
>>> foo := GetArray()
>>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>>
>>> That is simple to understand and in one line of code. Imagine the 
>>> acrobatics (and lines of code) needed to do this using Go's loops!
>>>
>>> You can read my full article on why Go needs generics here: 
>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>>
>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:

 Since everyone thinks it but nobody bothers to reply to it: this whole 
 thing you propose can be currently done with a for loop, which not only is 
 explicit about what it doing, but it also lets you control if you want to 
 exit early from it and so on. Complicating the whole language because 
 something is cool (yet looks like a really complex thing that you need to 
 think about while reading the code) is in no one's benefit. Stop trying to 
 avoid a couple of extra rows of for {} (where the third row is literally 
 just an "}")  and start embracing the fact that you can understand the 
 code 
 by looking at it and not apply any complex mental acrobatics to figure out 
 what those three lines of code are doing. Your future self/person after 
 you 
 will thank you for 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

for the fun, with early return,

https://play.golang.org/p/I9AORKOYQm

On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote:
>
> > Generics enable more than just replacing loops. For example, they can 
> enable libraries of generic algorithms to be used with any type of array. 
> Here's an example:
>
> in my demonstration every type got this kind of method,
> the problem become how do you jump from Type A to type B.
> in []A to []B or A -> B
>
> indeed it works on the item level, no more on the collections.
>
> This question is solved in two ways,
> - interface definitions (not interface value)
> - static conversion, which always resumes to 
> func(in-type) out-type
>
> and some alternatives for convenience (producer/consumer)
> func (func(in-type) out-type
> func (in-type) func() out-type
> func (func(in-type) func() out-type
> // this is unfinished explanation it should include error management to be 
> handled more completely. see please previous conv() fn introduced earlier 
> to statically re decorate a func signature.
>
> So far the sum/reduce things operation,
> i left them as exercise to the stream declarer
> and did not consider them as core.
> Take become => filter (func(10 elements))
> Map is map
> Sort is All(fn sorter) []out
> Reduce is a map operation, preceded by a conv if it reduces to a different 
> type.
>
>
> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
> wrote:
>>
>> Generics enable more than just replacing loops. For example, they can 
>> enable libraries of generic algorithms to be used with any type of array. 
>> Here's an example:
>>
>> foo := GetArray()
>> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>>
>> That is simple to understand and in one line of code. Imagine the 
>> acrobatics (and lines of code) needed to do this using Go's loops!
>>
>> You can read my full article on why Go needs generics here: 
>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>>
>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:
>>>
>>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>>> thing you propose can be currently done with a for loop, which not only is 
>>> explicit about what it doing, but it also lets you control if you want to 
>>> exit early from it and so on. Complicating the whole language because 
>>> something is cool (yet looks like a really complex thing that you need to 
>>> think about while reading the code) is in no one's benefit. Stop trying to 
>>> avoid a couple of extra rows of for {} (where the third row is literally 
>>> just an "}")  and start embracing the fact that you can understand the code 
>>> by looking at it and not apply any complex mental acrobatics to figure out 
>>> what those three lines of code are doing. Your future self/person after you 
>>> will thank you for 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

> Generics enable more than just replacing loops. For example, they can 
enable libraries of generic algorithms to be used with any type of array. 
Here's an example:

in my demonstration every type got this kind of method,
the problem become how do you jump from Type A to type B.
in []A to []B or A -> B

indeed it works on the item level, no more on the collections.

This question is solved in two ways,
- interface definitions (not interface value)
- static conversion, which always resumes to 
func(in-type) out-type

and some alternatives for convenience (producer/consumer)
func (func(in-type) out-type
func (in-type) func() out-type
func (func(in-type) func() out-type
// this is unfinished explanation it should include error management to be 
handled more completely. see please previous conv() fn introduced earlier 
to statically re decorate a func signature.

So far the sum/reduce things operation,
i left them as exercise to the stream declarer
and did not consider them as core.
Take become => filter (func(10 elements))
Map is map
Sort is All(fn sorter) []out
Reduce is a map operation, preceded by a conv if it reduces to a different 
type.


On Friday, June 2, 2017 at 2:59:41 PM UTC+2, gary.wi...@victoriaplumb.com 
wrote:
>
> Generics enable more than just replacing loops. For example, they can 
> enable libraries of generic algorithms to be used with any type of array. 
> Here's an example:
>
> foo := GetArray()
> result := foo.Take(10).map(...).Sort(...).Reduce(...)
>
> That is simple to understand and in one line of code. Imagine the 
> acrobatics (and lines of code) needed to do this using Go's loops!
>
> You can read my full article on why Go needs generics here: 
> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/
>
> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote:
>>
>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>> thing you propose can be currently done with a for loop, which not only is 
>> explicit about what it doing, but it also lets you control if you want to 
>> exit early from it and so on. Complicating the whole language because 
>> something is cool (yet looks like a really complex thing that you need to 
>> think about while reading the code) is in no one's benefit. Stop trying to 
>> avoid a couple of extra rows of for {} (where the third row is literally 
>> just an "}")  and start embracing the fact that you can understand the code 
>> by looking at it and not apply any complex mental acrobatics to figure out 
>> what those three lines of code are doing. Your future self/person after you 
>> will thank you for 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

yes true.

I m not sure i intend to change that asap, 
but this another topic,
i want not deep into right now.

That being said again agreed, understood, prone to happen, maybe.

On Friday, June 2, 2017 at 12:05:52 PM UTC+2, Egon wrote:
>
> On Friday, 2 June 2017 12:06:54 UTC+3, mhh...@gmail.com wrote:
>>
>> Sorry for this crime of thought, i was thinking it was a chance to talk 
>> about it and explore different paths.
>> That, this, is the only answer, well, life is hard.
>>
>
> Thinking and discussion is helpful, but I think the format here could be 
> improved.
>
> The problem in this thread is that these comments are "random thoughts" 
> instead of "organized thoughts" about different aspects, without 
> referencing any prior art.
>
> Organizing these thoughts and points works for these things much, much 
> better. Even better is a article / blog-post for something bigger.
>
> E.g. I would consider this form:
>
> 1. real-world problem (no "animal" or "bunny" examples)
> 1.1. where it exists
> 1.2. how frequent
> 2. Current solutions
> 2.1. current solution 1 (pros/cons)
> 2.2. current solution 2 (pros/cons)
> 2.3. current solution 3 (pros/cons)
> 3. Alternative approaches
> 3.1 alternative approach 1 (pros/cons/prior-art)
> 3.2 alternative approach 2 (pros/cons/prior-art)
> 3.3 alternative approach 3 (pros/cons/prior-art)
> 4. Comparison between solutions.
> 5. Cost / benefit discussion.
>
> *Each of these around 1-3 paragraphs.*
>
> This has a good basis for a good discussion, whereas random thoughts often 
> don't. Also there's always room for a middle-ground.
>
> Thinking aloud and random thoughts work somewhat in chats, but often 
> doesn't end-up in something tangible that can be used later on.
>
> + Egon
>
>
>> Just for the records, i did stop thinking like that when i started 
>> golang, its not like you are given the choice.
>>
>> Psst ... I must ask you about the address of the shop where you bought 
>> this wonderful magical crystal bowl you use to read in the future.
>> I kind of fail to find one for my current self.
>> thanks ;)
>>
>> On Friday, June 2, 2017 at 10:17:54 AM UTC+2, Florin Pățan wrote:
>>>
>>> Since everyone thinks it but nobody bothers to reply to it: this whole 
>>> thing you propose can be currently done with a for loop, which not only is 
>>> explicit about what it doing, but it also lets you control if you want to 
>>> exit early from it and so on. Complicating the whole language because 
>>> something is cool (yet looks like a really complex thing that you need to 
>>> think about while reading the code) is in no one's benefit. Stop trying to 
>>> avoid a couple of extra rows of for {} (where the third row is literally 
>>> just an "}")  and start embracing the fact that you can understand the code 
>>> by looking at it and not apply any complex mental acrobatics to figure out 
>>> what those three lines of code are doing. Your future self/person after you 
>>> will thank you for 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

Sorry for this crime of thought, i was thinking it was a chance to talk 
about it and explore different paths.
That, this, is the only answer, well, life is hard.

Just for the records, i did stop thinking like that when i started golang, 
its not like you are given the choice.

Psst ... I must ask you about the address of the shop where you bought this 
wonderful magical crystal bowl you use to read in the future.
I kind of fail to find one for my current self.
thanks ;)

On Friday, June 2, 2017 at 10:17:54 AM UTC+2, Florin Pățan wrote:
>
> Since everyone thinks it but nobody bothers to reply to it: this whole 
> thing you propose can be currently done with a for loop, which not only is 
> explicit about what it doing, but it also lets you control if you want to 
> exit early from it and so on. Complicating the whole language because 
> something is cool (yet looks like a really complex thing that you need to 
> think about while reading the code) is in no one's benefit. Stop trying to 
> avoid a couple of extra rows of for {} (where the third row is literally 
> just an "}")  and start embracing the fact that you can understand the code 
> by looking at it and not apply any complex mental acrobatics to figure out 
> what those three lines of code are doing. Your future self/person after you 
> will thank you for 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

What d be awesome is that the stream like interface 
i have bee thinking about provides a convert method,
so it can answer to this question

given []string how to move on to []int, or,

[]stream.Map(...) -> give me the length of each string

So if the interface contains a magic signature like this,
Conv( conv(), sink) 
sink

It s possible to write,

[]stream.Map(...).Conv(strToLen, []int{}).Sum()

where 
strToLen := func(s string) int { return len(s) }

which, for the fun, could be turned into

strLen := conv(func(v string) int, len)
[]stream.Map(...).Conv(strLen, []int{}).Sum()
// twice conv looks not so good.

On Tuesday, May 30, 2017 at 8:26:35 PM UTC+2, mhh...@gmail.com wrote:
>
> one more case where conv d be awesome,
>
>
> with 
> fnUtils.InputParams() ParamSlice
>
> Where 
> ParamSlice []struct{Name,Type string}
>
> With little help, I can do stuff like
>
> ctxFilter := astutil.FilterParamSlice.ByType(ctxCtx)
> fnUtils.InputParams().Filter(ctxFilter).Map(func(p 
> astutil.Param) astutil.Param {
> ...
> return p
> })
>
> that works, but its not the best factorization possible,
>
> let say the language provide a construct 
> - to make a getter of a type property
> - a deep eq func of a type
>
> such as an approximation would be
>
> typeGet := get.(Param.Type) // func() string
> strEq := conv(func(left func() string) func(right string) 
> bool, eq.(string))
> ctxFilter := strEq(typeGet)
>
> in short
> - make a getter of Param.type => func()string
> - convert string.eq from func(s,s) to a string consumer 
>  => strEq := func(left func() string) func(right string) bool
> - create the value eqer, of a value getter,
> => ctxFilter := strEq(typeGet)
>
> then pass it to a stream/array like data structure (to be defined)
>
> the provider can provides struct only, 
> and the declarer has more ways to handle the declared api.
>
> On Tuesday, May 30, 2017 at 5:14:57 PM UTC+2, mhh...@gmail.com wrote:
>>
>> I just realized what d be awesome is that the language 
>> does not only provide boiler plate []basicType enhanced types,
>> but provides streamed version of them,
>> that d be much better.
>>
>> when you do 
>> [15Million]string.map().filter().count().
>>
>> with a naive implementation over array of those intents,
>> you effectively end up with a copy at each stage,
>> which is not cool.
>>
>> Instead if that d be a stream api, 
>> that d be almost same call, with small changes to be determined, 
>> but a much better allocation,
>> as each item is processed once by each function, one item at a time,
>> you don t need the intermediate (stupid, after all) arrays.
>>
>> [15Million]string.map().filter().count().
>>
>> The difference being 
>> that some func call must become terminal, count() int
>> some must probably become contiguous to > user>, filter() stream
>>
>> can this help to reduce over multiple goroutine?
>>
>> something like ?
>> [15Million]string.chunks(size int, concurrent int).Parrallel(receiver 
>> []string{}.filter() stream).count().
>>
>> count is sequential, it receives results from // filters, 
>> receiver is a worker space (memory+work) aka what a stream ? a []string ?,
>>
>> so ParrallelChunk is (input stream/[]string) stream/[]string
>>
>> why not ?
>>
>> On Tuesday, May 30, 2017 at 4:43:54 PM UTC+2, mhh...@gmail.com wrote:
>>>
>>> I m just gonna add more examples as it come,
>>>
>>> from
>>> hasPrefix := func(prefix string) func(string) bool {
>>> return func(s string) bool { return strings.HasPrefix(s, 
>>> prefix) }
>>> } // this is not cool
>>>
>>> if fnUtils.AllTypes().Filter(hasPrefix("post")).NotEmpty() {
>>> ...
>>> }
>>>
>>> to
>>> hasPrefix, _ := conv(func(prefix string) func(s string) 
>>> bool, strings.HasPrefix)
>>> // does this make sense given 
>>> https://golang.org/pkg/strings/#HasPrefix ? 
>>>
>>> if fnUtils.AllTypes().Filter(hasPrefix("post")).NotEmpty() {
>>> ...
>>> }
>>>
>>> On Friday, May 26, 2017 at 2:47:45 PM UTC+2, mhh...@gmail.com wrote:

 oops... mistake in it.


 printS, err := conv(func(s string, err error), fmt.Println) or 
 panic(err)
 _, err := []string{"hello}.Map(strings.
 ToUpper).MustEach(printS) or panic(err)

 count, err := conv(func(s string) n int, fmt.Println) or panic(err)
 n := []string{"hello}.Map(strings.ToUpper).Sum(count)

 count, err := conv(func(s string) (n int, err error), fmt.Println) or 
 panic(err)
 n, err := []string{"hello}.Map(strings.ToUpper).MustSum(count) or 
 panic(err)

 more like this, take advantage of return type and names to do more 
 conversion.

 On Friday, May 26, 2017 at 2:45:33 PM UTC+2, mhh...@gmail.com wrote:
>
> or this,
>
> printS, err := conv(func(s string, err 

[go-nuts] Re: To panic or not to panic, that's the question

[mhhcbon]

understood the same, was going to give same example. 
panic at init is ok to me while it look likes 
a compile error
a system requirement error



On Wednesday, May 31, 2017 at 9:41:37 PM UTC+2, Pierre Durand wrote:
>
> I use these functions in init():
> https://golang.org/pkg/html/template/#Must
> https://golang.org/pkg/regexp/#MustCompile
>
> Le mercredi 31 mai 2017 21:24:58 UTC+2, Peter Kleiweg a écrit :
>>
>> If a package can't be used because some precondition can't be fulfilled, 
>> you can use a panic. Then the whole program will crash at start-up.
>>
>> The alternative would be to not panic in the init, but have all function 
>> calls return an error. If the package is used in a large program, part of 
>> it may still be functional.
>>
>> Using panic in an init function of a package, do or don't?
>>
>>

-- 
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: did anyone tried // template exec ?

[mhhcbon]

I see, interesting, thanks for that.

Note, those are different problems.

One is about trying to cheaply speed up template execution by //,
I still wonder if that can be worthy,
i foresee with the future translation package it might because of the 
additional call costs,
but you know side effects, allocations, contentions... stuff like that.. 
and you are back to (unfinished...) alternatives ;)

The second is about handling data injection into the template.

Where i do have several critics too,
I d simply won t put my services in a kv[string]interface{}, 
better to use another language if that is the final solution.

To compare with context, at least context is a kv[interface{}]interface{},
which you can take advantage to be protective.

On large scale, this approach is difficult to manage.



Anyways some extended thoughts.

For that specific case it happens i m working on what might be a solution,
like the article you presented it does code introspection 
so the computer does the *** job for us.

I use typed struct to do data injection, 

of services
type TemplateData struct {
SvcWhatever ServiceTypeToLookupFor
}

of other view components services
type TemplateData struct {
ViewWhatever ViewTypeToLookupFor
}

so far it seems to be perfect fit to rely on the type system rather than 
raw text.

Then i do some preprocessing (rather than reflect) to bind that 
automatically.

With more help from the computer i also decoupled 
the transport controller and the view controllerS,
so i ll never have this stupid global head context
to manage every details of the page to be generated.

views won t be that stupid dead code anymore, 
it will manage its input to produce the desired output.
So everyone is more autonomous on his task assignment 
and the code is generally more localized which looks better to me.

Last, i d really like the same article techniques applied to translation 
management.
The translation are always sparse across the application,
every time its a pain to handle, either way, 
by declare ahead and use in the template, 
or use in template than declare in the translations.

I d rather have a consume first approach with the help of 
a tool that inspects the templates for translation call, 
and process them to dedicated dictionaries to answer
several useful questions,
howto
Insert translation of ID I for language N?
Where is that translation ID used in the application?
Does this translation requires plural support in the app ?
Prepare the file to update/create the translations?
etc etc

On Thursday, June 1, 2017 at 8:05:16 AM UTC+2, Michael Brown wrote:
>
> I posted on another thread today one solution for this (Subj: "How to 
> parallelize text/template long-running functions")
>
> I got something simple working using a two-pass template execution, and 
> somebody else pointed me to 
> https://blog.gopheracademy.com/advent-2014/soy-programmable-templates/ 
> (which I haven't yet examined).
> --
> Michael
>
> On Tuesday, May 30, 2017 at 3:09:35 AM UTC-5, mhh...@gmail.com wrote:
>>
>> hi,
>>
>> wonder, if anyone,
>> - tried to make an implementation of template that works in // ?
>> - was it successful ?
>> - useful for perf ?
>>
>> 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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

I m just gonna add more examples as it come,

from
hasPrefix := func(prefix string) func(string) bool {
return func(s string) bool { return strings.HasPrefix(s, 
prefix) }
} // this is not cool

if fnUtils.AllTypes().Filter(hasPrefix("post")).NotEmpty() {
...
}

to
hasPrefix, _ := conv(func(prefix string) func(s string) bool, 
strings.HasPrefix)
// does this make sense given 
https://golang.org/pkg/strings/#HasPrefix ? 

if fnUtils.AllTypes().Filter(hasPrefix("post")).NotEmpty() {
...
}

On Friday, May 26, 2017 at 2:47:45 PM UTC+2, mhh...@gmail.com wrote:
>
> oops... mistake in it.
>
>
> printS, err := conv(func(s string, err error), fmt.Println) or panic(err)
> _, err := []string{"hello}.Map(strings.
> ToUpper).MustEach(printS) or panic(err)
>
> count, err := conv(func(s string) n int, fmt.Println) or panic(err)
> n := []string{"hello}.Map(strings.ToUpper).Sum(count)
>
> count, err := conv(func(s string) (n int, err error), fmt.Println) or 
> panic(err)
> n, err := []string{"hello}.Map(strings.ToUpper).MustSum(count) or 
> panic(err)
>
> more like this, take advantage of return type and names to do more 
> conversion.
>
> On Friday, May 26, 2017 at 2:45:33 PM UTC+2, mhh...@gmail.com wrote:
>>
>> or this,
>>
>> printS, err := conv(func(s string, err error), fmt.Println) or panic(err)
>> _, err := []string{"hello}.Map(strings.ToUpper).MustEach(printS) or 
>> panic(err)
>>
>> count, err := conv(func(n int), fmt.Println) or panic(err)
>> n := []string{"hello}.Map(strings.ToUpper).Sum(count)
>>
>> count, err := conv(func(n int, err error), fmt.Println) or panic(err)
>> n, err := []string{"hello}.Map(strings.ToUpper).MustSum(count) or 
>> panic(err)
>>
>> that'd be great...
>>
>> On Friday, May 26, 2017 at 2:25:37 PM UTC+2, mhh...@gmail.com wrote:
>>>
>>> for the fun, 
>>>
>>> I want to write
>>> []string{"hello}.Map(strings.ToUpper).Each(fmt.Println)
>>>
>>> would not work, func param are incompatible.
>>>
>>> let s apply static rules to convert it,
>>>
>>> printS, err := conv(func(s string), fmt.Println) or panic(err)
>>> []string{"hello}.Map(strings.ToUpper).Each(printS)
>>>
>>> Now it s possible.
>>>
>>> And if one does a fmt.MustPrintln to get ride of the error while still 
>>> handling it (recoverable)
>>> rather than ignore it as of today, 
>>> you can write that, and handle error via recover, 
>>> or simply ignore it as in the previous ex.
>>>
>>> printS, err := conv(func(s string), fmt.MustPrintln) or panic(err)
>>>
>>> []string{"hello}.Map(strings.ToUpper).Each(printS)
>>>
>>>
>>>
>>> On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:

 see the title, only for what s needed 
 Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
 so interface system serves the userland by its definition of struct, and 
 the basic slice type provided by the language is fully operational, 
 without 
 breaking, btw. i don t go further in evaluation, i leave that to the 
 reader, just trying to work decently.

>>>

-- 
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: did anyone tried // template exec ?

[mhhcbon]

obviously not,
go func t.Exec...
go func t.Exec...

but

`
{{slowcall}}
{{fastcall}}
{{slowcall}}
{{$y := CanNot//}}
`

ect

On Tuesday, May 30, 2017 at 10:09:35 AM UTC+2, mhh...@gmail.com wrote:
>
> hi,
>
> wonder, if anyone,
> - tried to make an implementation of template that works in // ?
> - was it successful ?
> - useful for perf ?
>
> 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.

[go-nuts] did anyone tried // template exec ?

[mhhcbon]

hi,

wonder, if anyone,
- tried to make an implementation of template that works in // ?
- was it successful ?
- useful for perf ?

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.

[go-nuts] Re: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

oops... mistake in it.


printS, err := conv(func(s string, err error), fmt.Println) or panic(err)
_, err := []string{"hello}.Map(strings.
ToUpper).MustEach(printS) or panic(err)

count, err := conv(func(s string) n int, fmt.Println) or panic(err)
n := []string{"hello}.Map(strings.ToUpper).Sum(count)

count, err := conv(func(s string) (n int, err error), fmt.Println) or 
panic(err)
n, err := []string{"hello}.Map(strings.ToUpper).MustSum(count) or panic(err)

more like this, take advantage of return type and names to do more 
conversion.

On Friday, May 26, 2017 at 2:45:33 PM UTC+2, mhh...@gmail.com wrote:
>
> or this,
>
> printS, err := conv(func(s string, err error), fmt.Println) or panic(err)
> _, err := []string{"hello}.Map(strings.ToUpper).MustEach(printS) or 
> panic(err)
>
> count, err := conv(func(n int), fmt.Println) or panic(err)
> n := []string{"hello}.Map(strings.ToUpper).Sum(count)
>
> count, err := conv(func(n int, err error), fmt.Println) or panic(err)
> n, err := []string{"hello}.Map(strings.ToUpper).MustSum(count) or 
> panic(err)
>
> that'd be great...
>
> On Friday, May 26, 2017 at 2:25:37 PM UTC+2, mhh...@gmail.com wrote:
>>
>> for the fun, 
>>
>> I want to write
>> []string{"hello}.Map(strings.ToUpper).Each(fmt.Println)
>>
>> would not work, func param are incompatible.
>>
>> let s apply static rules to convert it,
>>
>> printS, err := conv(func(s string), fmt.Println) or panic(err)
>> []string{"hello}.Map(strings.ToUpper).Each(printS)
>>
>> Now it s possible.
>>
>> And if one does a fmt.MustPrintln to get ride of the error while still 
>> handling it (recoverable)
>> rather than ignore it as of today, 
>> you can write that, and handle error via recover, 
>> or simply ignore it as in the previous ex.
>>
>> printS, err := conv(func(s string), fmt.MustPrintln) or panic(err)
>>
>> []string{"hello}.Map(strings.ToUpper).Each(printS)
>>
>>
>>
>> On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>>>
>>> see the title, only for what s needed 
>>> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
>>> so interface system serves the userland by its definition of struct, and 
>>> the basic slice type provided by the language is fully operational, without 
>>> breaking, btw. i don t go further in evaluation, i leave that to the 
>>> reader, just trying to work decently.
>>>
>>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

or this,

printS, err := conv(func(s string, err error), fmt.Println) or panic(err)
_, err := []string{"hello}.Map(strings.ToUpper).MustEach(printS) or 
panic(err)

count, err := conv(func(n int), fmt.Println) or panic(err)
n := []string{"hello}.Map(strings.ToUpper).Sum(count)

count, err := conv(func(n int, err error), fmt.Println) or panic(err)
n, err := []string{"hello}.Map(strings.ToUpper).MustSum(count) or panic(err)

that'd be great...

On Friday, May 26, 2017 at 2:25:37 PM UTC+2, mhh...@gmail.com wrote:
>
> for the fun, 
>
> I want to write
> []string{"hello}.Map(strings.ToUpper).Each(fmt.Println)
>
> would not work, func param are incompatible.
>
> let s apply static rules to convert it,
>
> printS, err := conv(func(s string), fmt.Println) or panic(err)
> []string{"hello}.Map(strings.ToUpper).Each(printS)
>
> Now it s possible.
>
> And if one does a fmt.MustPrintln to get ride of the error while still 
> handling it (recoverable)
> rather than ignore it as of today, 
> you can write that, and handle error via recover, 
> or simply ignore it as in the previous ex.
>
> printS, err := conv(func(s string), fmt.MustPrintln) or panic(err)
>
> []string{"hello}.Map(strings.ToUpper).Each(printS)
>
>
>
> On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>>
>> see the title, only for what s needed 
>> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
>> so interface system serves the userland by its definition of struct, and 
>> the basic slice type provided by the language is fully operational, without 
>> breaking, btw. i don t go further in evaluation, i leave that to the 
>> reader, just trying to work decently.
>>
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

for the fun, 

I want to write
[]string{"hello}.Map(strings.ToUpper).Each(fmt.Println)

would not work, func param are incompatible.

let s apply static rules to convert it,

printS, err := conv(func(s string), fmt.Println) or panic(err)
[]string{"hello}.Map(strings.ToUpper).Each(printS)

Now it s possible.

And if one does a fmt.MustPrintln to get ride of the error while still 
handling it (recoverable)
rather than ignore it as of today, 
you can write that, and handle error via recover, 
or simply ignore it as in the previous ex.

printS, err := conv(func(s string), fmt.MustPrintln) or panic(err)

[]string{"hello}.Map(strings.ToUpper).Each(printS)



On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>
> see the title, only for what s needed 
> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
> so interface system serves the userland by its definition of struct, and 
> the basic slice type provided by the language is fully operational, without 
> breaking, btw. i don t go further in evaluation, i leave that to the 
> reader, just trying to work decently.
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

as i m on it,

please consider, what below code might be with little imagination,


// Create a new Tomate
func (t Controller) Create(postColor *string) (jsonResBody *Tomate, err error) {
 
   mustNot(postColor, nil) or 
 return ... {errors.New("Missing color parameter")}
 
   color, _ := mustNot(strings.TrimSpace(*postColor), "") or 
 return ... {errors.New("color must not be empty")}

   t.backend.Transact(func(backend *Tomates) {
 
 must(backend.Filter(FilterTomates.ByColor(color)).Empty(), true) or {
   err = {errors.New("color must be unique")}
   return
 }
 
 jsonResBody = {ID: fmt.Sprintf("%v", backend.Len()), Color: color}
 backend.Push(jsonResBody)
 
 })

 return jsonResBody, err
}

>From that go compatible code,


// Create a new Tomate
func (t Controller) Create(postColor *string) (jsonResBody *Tomate, err 
error) {
if postColor == nil {
return nil, {errors.New("Missing color parameter")}
}
color := strings.TrimSpace(*postColor)
if color == "" {
return nil, {errors.New("color must not be empty")}
}
t.backend.Transact(func(backend *Tomates) {
exist := backend.Filter(FilterTomates.ByColor(color)).Len()
if exist > 0 {
err = {errors.New("color must be unique")}
return
}
jsonResBody = {ID: fmt.Sprintf("%v", backend.Len()), Color: 
color}
backend.Push(jsonResBody)
})
return jsonResBody, err
}



On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>
> see the title, only for what s needed 
> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
> so interface system serves the userland by its definition of struct, and 
> the basic slice type provided by the language is fully operational, without 
> breaking, btw. i don t go further in evaluation, i leave that to the 
> reader, just trying to work decently.
>

-- 
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: idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

would not it be nice to write []string{"hello}.Map(strings.ToUpper) ? 

And so for userland types the language accept, 
[]*MyType.Filter(func(*MyType)*MyType).Map(...).First()//etc.

IRL, because the total lack of such struct in the language might let you 
think the idea is superfluous with the currrent 
language/idioms/whateveryounameit, 
I have this example i like,

// GetByID read the Tomate of given IDfunc (t Controller) GetByID(getID string) 
(jsonResBody *Tomate, err error) {
t.backend.Transact(func(backend *Tomates) {
jsonResBody = backend.
Filter(FilterTomates.ByID(getID)).
First()
})
if jsonResBody == nil {
err = {errors.New("Tomate not found")}
}
return jsonResBody, err
}


The code is not cluttered with extra if/else/for statements that i d have 
to introduce using regular constructs proposed by the language.


What are the example that needs extended generic support that interface can 
fulfilled ?
This one ?

type B string

func A([]string){}

func main(){ 
 var x []B
 A(x)
} 

? 
What else chan  ?
https://gist.github.com/mchirico/df9fad3e7a5ea0c4527a ?
map ?




in all cases, it ends up with a manual conversion should occur, can t the 
language handle it ?
Do the compatibility check needed to slice conversion and produce the 
results or err appropriately.
Even better, take advantage of it to implement compilation rules ?

sX, err := conv([]string, x) or panic(err)
A(sX)

outChan, err := conv(<- chan /whatever compatible/, inputChan) or panic(err)

Are there more examples in sight ?




On Wednesday, May 24, 2017 at 9:52:27 AM UTC+2, mhh...@gmail.com wrote:
>
> see the title, only for what s needed 
> Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
> so interface system serves the userland by its definition of struct, and 
> the basic slice type provided by the language is fully operational, without 
> breaking, btw. i don t go further in evaluation, i leave that to the 
> reader, just trying to work decently.
>

-- 
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: bash completion for flag package

[mhhcbon]

worked like a charm since i understood i needed to source my bashrc!

great package here! thanks a lot!

On Tuesday, May 23, 2017 at 9:21:07 PM UTC+2, Eyal Posener wrote:
>
> I recently did the complete package , 
> that enables bash completion for the go command line.
> I came to be really satisfied with the result, but the package downside is 
> that the completion can be inconsistent with the actual flags provided by 
> the program.
> I thought how is it possible to add support to the standard library flag 
> package for automatic bash completion, more or less in the same way. 
> (Including installation, and that the program binary will provide bash 
> completion for itself)
>
> Here is what I came out with: https://github.com/posener/flag.
>
> It is 100% interchangeable with the standard library flag package.
> The implementation is also interesting, I only add to make 
> 'flat.Flag.Value' implement an interface I called 'Completer'. All the 
> standard library flags, which do not implement this interface don't 
> complete anything (which is fine) and additional flag types can complete 
> all sort of stuff.
>
> Please let me know your opinion about it.
>
> Cheers,
> Eyal
>

-- 
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: bash completion for flag package

[mhhcbon]

wahou :) trying it now!

On Tuesday, May 23, 2017 at 9:21:07 PM UTC+2, Eyal Posener wrote:
>
> I recently did the complete package , 
> that enables bash completion for the go command line.
> I came to be really satisfied with the result, but the package downside is 
> that the completion can be inconsistent with the actual flags provided by 
> the program.
> I thought how is it possible to add support to the standard library flag 
> package for automatic bash completion, more or less in the same way. 
> (Including installation, and that the program binary will provide bash 
> completion for itself)
>
> Here is what I came out with: https://github.com/posener/flag.
>
> It is 100% interchangeable with the standard library flag package.
> The implementation is also interesting, I only add to make 
> 'flat.Flag.Value' implement an interface I called 'Completer'. All the 
> standard library flags, which do not implement this interface don't 
> complete anything (which is fine) and additional flag types can complete 
> all sort of stuff.
>
> Please let me know your opinion about it.
>
> Cheers,
> Eyal
>

-- 
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] idea: generic methods on slices with some generic type support []string.Map(string) []string => [].Map() []

[mhhcbon]

see the title, only for what s needed 
Slice/Splice/Each/Map/First/Last/Reverse/Sort ect ect not len, for reason. 
so interface system serves the userland by its definition of struct, and 
the basic slice type provided by the language is fully operational, without 
breaking, btw. i don t go further in evaluation, i leave that to the 
reader, just trying to work decently.

-- 
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/loader] write a conf to load faster a program ?

[mhhcbon]

Do you think i could take advantage of importer to serialize stdlib, 
then unserialize it rather than process it every times ?

Are those types linked to some sort of unserializable resource that would 
prevent that to happen ?

On Tuesday, May 16, 2017 at 1:43:44 AM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> I wrote this func to load a program,
> its faster but it has drawbacks about error managements.
> It might hide some messages.
>
> the first time i ran this function,
> without a special typechecker error handler,
> I felt overwhelmed by the amount of errors generated.
>
> in this func s is an import path, 
> and only that path should be loaded (so far).
> The import is very superficial.
>
> Is there a better/correct way to write a conf 
> that achieves similar speed goal 
> but with good error triage ?
>
> Should i use another api ?
>
> I m mostly interested into 
> inspecting the definitions,
> create new definitions,
> update some definitions in place,
> to be able to process the source even if it contains errors,
> unless they are critical.
>
> Thanks
>
>
> // GetFastProgramLoader returns a fast program loader
> func GetFastProgramLoader(s string) loader.Config {
> var conf loader.Config
> conf.ParserMode = parser.ParseComments
> conf.TypeChecker.IgnoreFuncBodies = true
> conf.TypeChecker.DisableUnusedImportCheck = true
> conf.TypeChecker.Error = func(err error) {
> if !err.(*types.Error).Soft {
> panic(err)
> }
> if strings.Index(err.Error(), "could not import") == -1 ||
> strings.Index(err.Error(), "undeclared name:") == -1 {
> return
> }
> log.Println(err)
> }
>
> // this really matters otherise its a pain to generate a partial 
> program.
> conf.AllowErrors = true
> originalPkgFinder := (*build.Context).Import
> conf.FindPackage = func(ctxt *build.Context, fromDir, importPath 
> string, mode build.ImportMode) (*build.Package, error) {
> if fromDir == s {
> return originalPkgFinder(ctxt, fromDir, importPath, mode)
> }
> return nil, fmt.Errorf("skipped %v %v", fromDir, importPath)
> }
> return conf
> }
>
>
>
>

-- 
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] The zero value of a slice is nil

[mhhcbon]

hi

At
https://blog.golang.org/go-slices-usage-and-internals#TOC_3.

It says,

> The zero value of a slice is nil. The len and cap functions will both 
return 0 for a nil slice. 


Then looked at https://youtu.be/ynoY2xz-F8s?t=10m20s


I found the second explanation much better to explain

https://play.golang.org/p/bSTmNrAtjA

-- 
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: Stop HTTP Server with Context cancel

[mhhcbon]

> Is it OK to use context cancellation for stopping long running functions ?

yes, i d say so. 

About contexts, 
https://www.youtube.com/watch?v=LSzR0VEraWw
https://www.youtube.com/watch?v=8M90t0KvEDY

>From scratch, 
with some mocks to test

package main

import (
"context"
"log"
"time"
)

func main() {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.
Millisecond)
defer cancel()
var err error
listenSig := make(chan error)
go func() { listenSig <- <-listenAndServe() }()//IRL, not sure if that 
will return if server has shutdown.
// this is unclear at 
https://beta.golang.org/src/net/http/server.go?s=79791:79837#L2615
// i d say its all about timeouts.
select {
case err = <-listenSig:
log.Println("server soft end")

case <-ctx.Done():
log.Println("context ended")

log.Println("server hard stop")
if err = shutdown( /*context.Background()*/ ); err == nil {
err = ctx.Err()
}
log.Println("server ended")
}
log.Println(err)

}

func listenAndServe() chan error {
e := make(chan error)
go func() {
<-time.After(time.Second)
e <- nil
}()
return e
}

func shutdown() error {
<-time.After(2 * time.Second)
return nil
}


that being said, server.Shutdown seems blocking,
https://beta.golang.org/pkg/net/http/#Server.Shutdown
> Shutdown ... waiting indefinitely for connections to return to idle and 
then shut down.
https://beta.golang.org/src/net/http/server.go?s=74304:74358#L2440

If so, d go func that one and put its err to a sink logger.
It will hang there until all clients are out, so the server must be 
configured with timeouts.
Or use a context with deadline ?
I m not sure what s the best, maybe both are needed ?
It looks likes this ctx parameter is sugar only.

Apart, does server.Shutdown allows a straight restart ?
+/- like if i d use socket_reuse port/addr?

> This code ensures that there is not leaking goroutine.

How do you know ? 

I mean for race detection there is a tool, 

for routine leak see those findings,
https://github.com/fortytw2/leaktest
https://godoc.org/github.com/anacrolix/missinggo#GoroutineLeakCheck
https://github.com/google/gops
https://medium.com/golangspec/goroutine-leak-400063aef468

https://github.com/golang/go/issues/12989
https://github.com/golang/go/issues/5308
https://github.com/golang/go/issues/6705

It has been set to
"Adding Release=None to all Priority=Someday bugs."


On Tuesday, April 4, 2017 at 8:02:16 PM UTC+2, Pierre Durand wrote:
>
> Hello
>
> I wrote a small helper to stop an HTTP Server when a Context is canceled.
> https://play.golang.org/p/Gl8APynVdh
>
> What do you think ?
> Is it OK to use context cancellation for stopping long running functions ?
>

-- 
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/loader] write a conf to load faster a program ?

[mhhcbon]

Hi,

I wrote this func to load a program,
its faster but it has drawbacks about error managements.
It might hide some messages.

the first time i ran this function,
without a special typechecker error handler,
I felt overwhelmed by the amount of errors generated.

in this func s is an import path, 
and only that path should be loaded (so far).
The import is very superficial.

Is there a better/correct way to write a conf 
that achieves similar speed goal 
but with good error triage ?

Should i use another api ?

I m mostly interested into 
inspecting the definitions,
create new definitions,
update some definitions in place,
to be able to process the source even if it contains errors,
unless they are critical.

Thanks


// GetFastProgramLoader returns a fast program loader
func GetFastProgramLoader(s string) loader.Config {
var conf loader.Config
conf.ParserMode = parser.ParseComments
conf.TypeChecker.IgnoreFuncBodies = true
conf.TypeChecker.DisableUnusedImportCheck = true
conf.TypeChecker.Error = func(err error) {
if !err.(*types.Error).Soft {
panic(err)
}
if strings.Index(err.Error(), "could not import") == -1 ||
strings.Index(err.Error(), "undeclared name:") == -1 {
return
}
log.Println(err)
}

// this really matters otherise its a pain to generate a partial 
program.
conf.AllowErrors = true
originalPkgFinder := (*build.Context).Import
conf.FindPackage = func(ctxt *build.Context, fromDir, importPath string, 
mode build.ImportMode) (*build.Package, error) {
if fromDir == s {
return originalPkgFinder(ctxt, fromDir, importPath, mode)
}
return nil, fmt.Errorf("skipped %v %v", fromDir, importPath)
}
return conf
}



-- 
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: adding context.Context to new code

[mhhcbon]

+1 for any feedback.

> One issue was libraries that were used both in paths from http requests 
(so they needed the context propagated through them) but were also used in 
places where their callers (starting at main) didn't have any contexts at 
all

yup. 
Imagine also in the middle of the call you invoke a third party package 
without context support.

The problem mlight be even worst because of the weaknesses of the current 
type system.
You can t simply declare a type *mypackage.TContexted* of *foreign.T* and 
hope it will work.
I suspect it might need a whole re-factoring/re-integration of the foreign 
package *and* its dependencies.

> or, like appengine's log, split packages into one that requires contexts 
and one that doesn't)

yes i think its an approach that can work if taken appropriately.

Taken in its basic form:
- its expensive, money costs * 2
- its prone to bug, duplicated code, duplicated bugs
- its not genuine nor magic, it still needs lots of handcrafted work



A sarcastic question that bugs me, 
and probably wrong in its term as is,

Is go the language of the 21th century, 
or the last language of the 20th century
?


On Saturday, May 13, 2017 at 2:27:21 PM UTC+2, Peter Weinberger wrote:
>
> Hi. I was one of the people who failed in an attempt to auto-insert 
> contexts in all of google3. I no longer remember all the obstacles I failed 
> to overcome, but would encourage others to take on the project.
>
> One issue was libraries that were used both in paths from http requests 
> (so they needed the context propagated through them) but were also used in 
> places where their callers (starting at main) didn't have any contexts at 
> all. Sitting by my coffee this morning this no longer seems like an 
> insuperable obstacle (e.g., pass nils and change them to 
> context.Background() inside, or, like appengine's log, split packages into 
> one that requires contexts and one that doesn't). But I had lots of what I 
> thought were plausible ideas that broke on the hard rock of google3, and I 
> suspect these would too.
>
> (The project wasn't a total failure. It did plumb contexts through a bunch 
> of packages. But the general case was too hard for me.)
>
> On Sat, May 13, 2017 at 3:50 AM,  wrote:
>
>> A reference i found about "reactive programming"
>> https://github.com/dsyer/reactive-notes/blob/master/intro.adoc
>>
>> Hope this introduced the concept correctly, thanks for pointing that.
>>
>> Following are only some thoughts,
>>
>> Two things surprising here,
>> 1/ a programmer prefers not to solve a problem
>> 2/ one failed attempt mean the end of all attempts**
>>
>> That being said, my little understanding so far is that current context 
>> is used for two purposes,
>> - cancellation
>> - data (transmission? not sure) (+/- ts, have not checked i expect so in 
>> regards to previous referenceS cited)
>>
>> While cancellation is a feature i really want to take advantage of,
>> the other one is much more arguable in the sense that
>> it can remains expressed purely by the end user without bloating 
>> his productivity and quality (you don t really need it everywhere, just 
>> where it is needed), 
>> it seems to be highly software context dependent.
>>
>> Whereas cancellation, while it looks likes simple, is maybe more subtle.
>> After all it is about assigning uuid to a chain of call and 
>> appropriately propagate, disjoint/rejoin new uuids with the previous one, 
>> so that we can ask to stop execution of a sub selection of a chain of 
>> calls
>> via an handle. 
>> Am i too simplistic?
>>
>> Its difficulty reside in its requirement to be passed absolutely 
>> everywhere,
>> That reveals an important fact about the nature of cancellation,
>> it is there, it is everywhere, at all time (...within the program 
>> lifetime),
>> it is somewhere in the background of every ops since the very beginning 
>> the program began,
>> but not necessarily enabled, and certainly not a straight line.
>>
>> That is where the syntax might help to establish the plots
>> that the runtime consumes to connect the dots 
>> and support what the developers want to achieve,
>> in my understanding so far.
>>
>> My best comparison to cancellation is 
>> request rays tracing in micro services oriented architecture,
>> on both end it is a multi-tenant,
>> it always start with one ray,
>> the ray always split into multiple rays,
>> because we do programming, we need ways
>> to create, control distribute existing/new rays,
>> and possibly let the userland introduce a new behavior for the rays.
>>
>> So yeah basically main has a ray,
>> if you process an http request,
>> you to create a new ray 
>> to be able to cancel only that request,
>> but it needs to be connected to the main ray
>> because if main should be canceled,
>> that signals should propagate to all rays connected with it,
>> probably.
>>
>> ** i want to put emphasis because in 

[go-nuts] Re: New fully featured bash completion for go - written in go

[mhhcbon]

looks awesome!!

In this,
https://github.com/posener/complete/blob/master/example/self/main.go

Just wonder why i can t simply do something similar to,


var name string
whatever.StringVar(, "name", "", "Give your name", complete.
PredictAnything)

if whatever.Run() {
return
}

Anyway, great stuff here!

On Saturday, May 13, 2017 at 10:29:47 AM UTC+2, Eyal Posener wrote:
>
> Simple to install (Assuming GOPATH and PATH are correct):
>
> go install github.com/posener/complete/gocomplete
> gocomplete -install
>
>
> Features:
>
>- Complete go command, sub commands and flags.
>- Complete package names, .go files and ellipsis when necessary.
>- Complete test names after -run flag!
>
> Works with bash / zsh shells
>
> This is also a package, that enables writing bash completion scripts, or 
> add them to an existing go program.
>
> Please, open issues, contribute and star!
>

-- 
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: adding context.Context to new code

[mhhcbon]

A reference i found about "reactive programming"
https://github.com/dsyer/reactive-notes/blob/master/intro.adoc

Hope this introduced the concept correctly, thanks for pointing that.

Following are only some thoughts,

Two things surprising here,
1/ a programmer prefers not to solve a problem
2/ one failed attempt mean the end of all attempts**

That being said, my little understanding so far is that current context is 
used for two purposes,
- cancellation
- data (transmission? not sure) (+/- ts, have not checked i expect so in 
regards to previous referenceS cited)

While cancellation is a feature i really want to take advantage of,
the other one is much more arguable in the sense that
it can remains expressed purely by the end user without bloating 
his productivity and quality (you don t really need it everywhere, just 
where it is needed), 
it seems to be highly software context dependent.

Whereas cancellation, while it looks likes simple, is maybe more subtle.
After all it is about assigning uuid to a chain of call and 
appropriately propagate, disjoint/rejoin new uuids with the previous one, 
so that we can ask to stop execution of a sub selection of a chain of calls
via an handle. 
Am i too simplistic?

Its difficulty reside in its requirement to be passed absolutely everywhere,
That reveals an important fact about the nature of cancellation,
it is there, it is everywhere, at all time (...within the program lifetime),
it is somewhere in the background of every ops since the very beginning the 
program began,
but not necessarily enabled, and certainly not a straight line.

That is where the syntax might help to establish the plots
that the runtime consumes to connect the dots 
and support what the developers want to achieve,
in my understanding so far.

My best comparison to cancellation is 
request rays tracing in micro services oriented architecture,
on both end it is a multi-tenant,
it always start with one ray,
the ray always split into multiple rays,
because we do programming, we need ways
to create, control distribute existing/new rays,
and possibly let the userland introduce a new behavior for the rays.

So yeah basically main has a ray,
if you process an http request,
you to create a new ray 
to be able to cancel only that request,
but it needs to be connected to the main ray
because if main should be canceled,
that signals should propagate to all rays connected with it,
probably.

** i want to put emphasis because in the description provided
by Sameer, as i tried to summarize, It has been tried to handle
the problem via the type system as if it was 
a completely defined set of types.
Which in go is wrong (yeah i m very affirmative here :), 
from my understanding, that might be correct in other oop languages.
Technically it is possible to rewrite interfaces, methods signatures, taken 
individually, 
as a whole, and from the consumer pov, 
i d say it is an impossible task in go because it it goes against its 
nature.
And i confirm/understand that by reading to Sameer feedback.

Notes: i m a strong lover of go type system (not talking about values and 
pointers ;)


On Friday, May 12, 2017 at 4:42:54 PM UTC+2, Henrik Johansson wrote:
>
> With the whole "Reactive" movement thread locals have started to vanish at 
> least in the Java ecosystem. 
> I agree with Sameer that, while convenient, it comes with a whole set of 
> obscure bugs. 
>
> On Fri, May 12, 2017, 14:57 Sameer Ajmani  
> wrote:
>
>> Hmm, I'm not finding good open-source examples of ThreadLocal context 
>> propagation in C++ and Java.  My experience with this is based on what 
>> Google uses internally.  Perhaps someone more familiar with context use 
>> (tracing?) outside Google can chime in? +Jaana Burcu Dogan  
>>
>> On Thu, May 11, 2017 at 7:02 AM  wrote:
>>
>>> thanks,
>>>
>>> ..integrating Context into the runtime..
>>>
>>>
>>> 50% runtime, 50% syntax with explicit contextualization.
>>>
>>> ..The flow of request processing in Go may include multiple goroutines 
>>> and may move across channels;
>>>
>>>
>>> yes big ? mark here. might the 50% of an handy and explicit syntax help 
>>> with it?
>>>
>>>
>>> C++ and Java use thread-local Contexts, and while this is convenient, it 
>>> is often a source of mysterious bugs.
>>>
>>> thanks! I don't know them, 
>>>
>>> I quickly checked according to this 
>>>
>>> https://dzone.com/articles/painless-introduction-javas-threadlocal-storage 
>>> I may have totally wrong, the syntax does not look like, not even from a 
>>> 100km,
>>> to how i represent go contexts in my head.
>>>
>>> This is more like the actor pattern dave cheney talks about in
>>> https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions
>>> (search for  Let’s talk about actors)
>>>
>>> Is the dzone link correctly describe 
>>> what you mentioned as being go context equivalent in java ?
>>>
>>> sorry my questions are so basic.
>>>
>>>
>>> On Thursday, May 11, 2017 at 

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

One more try : )
 

> I think what you're saying is that it's more natural and obvious that when 
> you have a function that changes something it would be more obvious and 
> simple if it actually did modify the thing you gave it.
>

That the receiver always act as a ref to a value stored /wherever/
That only the consumer decides where that value is stored using 
pointer/not.,
unless the declarer installed a barrier.



On Thursday, May 11, 2017 at 1:10:21 PM UTC+2, Chris Hopkins wrote:
>
> I think what you're saying is that it's more natural and obvious that when 
> you have a function that changes something it would be more obvious and 
> simple if it actually did modify the thing you gave it.
> Having to jump through hoops to actually make the change you asked for 
> stick is annoying.
>
> Yes? Is that what you mean? Is this a commentary on the effect this has on 
> ease of code read and writability?
>
> What I have come to realise recently by working on ever larger projects is 
> that no that's not annoying. When debugging code I don't understand often 
> half the challenge is working out how a piece of data has changed that 
> shouldn't have been. 
>

 

> In the world you describe anything that touched that variable could be to 
> blame for my problems. If instead you have to jump through hoops to make 
> modifications and those modifications are really obvious where they are 
> happening you make debugging easier.
>
same as today with pointer no ?
 

> Forcing the behaviour that "functions/methods don't modify their 
> associated structures" means people structure their code differently that 
> in my experience means instead of code that reads:
> foo.DoUsefulStuff(i) // has foo become corrupted? changed, who knows?
>
> if foo is not referencable, then the method DoUsefulStuff() 
necessarily provides an out param such DoUsefulStuff() 
That you did not copied back the returned value in your scope
is already an error today.

 

> you instead see code like:
> fred = foo.Lookup(i) // Complex function that changes nothing in foo
> foo = foo.ReturnUsefulStuff(fred) // This returns a corrupted structure
>

I dont get it, to return a corrupted state shall we not use an extra error 
parameter?
Still, that situation will apply if you use pointer.
 

For a start you look at the function definitions and see quickly that they 
> are not modifying the underlying structures so it's quick to discount a 
> large chunk of code as the a source of the problem. This is not so much of 
> a problem in your examples but in large undocumented projects where you 
> don't understand 99% of the code the small things make it much faster to 
> isolate where things could be going wrong.
>

because you focus on the type definition to lookup for possible suspects.
yes i argue its all about var definition and func in params.
yes it looks like they way i think multiply the place of errors.
 

>
> Please don't take this though as anything other than a commentary on the 
> code I like to read. "Code is written for humans to read and only 
> incidentally for machines to execute". I believe code is read by humans way 
> more times than it is written, so anything at all that isolates the code 
> and makes it easier to understand is worth putting time and effort into. 
>
> YMMV
>
>
I sincerely thanks everyone on the thread,
not easy task.

After all,
Happy we kindly disagree  :) 


On Thursday, 11 May 2017 11:39:18 UTC+1, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> thanks again!
>>
>> I m not the one to validate a perfect answer,
>> i can simply tell that from my go learning and understanding,
>> i agree top notch 200% no question there 
>> on this description,
>> which is weird in fact.
>>
>> I d only remark about this,
>> > so there are actually just two cases: Method is on pointer receiver or 
>> not. 
>>
>> From the declarer side, 
>> there is indeed only 2 cases, 
>> which accounts for 50% of the whole,
>> declaration + consumption,
>> the consumer is still accountable for the remaining
>> 50% of the instance consumption and usage.
>>
>> Does it make it less dead simple ?
>>
>> In my example i might have named the method as `whatever`,
>> still there is an explicit value set on a receiver property.
>> I don t feel like i have assumed anything from the method name.
>>
>>
>> On Thursday, May 11, 2017 at 12:17:00 PM UTC+2, Volker Dobler wrote:
>>>
>>> On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:

 //defined
> var x {} // put on heap
> var x T // put on stack
>
> This is definitely a misconception: Allocation on heap vs stack is
> totaly unrelated to value methods vs pointer methods. Both examples
> might be allocated on the stack or on the heap and this depends
> on other factors than methods of T.
>

 what are other factors ? 

>>>
>>> Roughly: If the compiler cannot prove that x *can* be safely put on the
>>> stack then it must go to the heap. Values cannot go safely 

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

I honestly don t know.

Seems my example is OK for you,
i really thought it was demonstrative 
of some confusion,
seems not.

If i m correct in following your understanding and comparisons,
in those two cases,

x := valueType{}
> x.SetName("yo!")
> fmt.Println(x.Name)
>
> y := {}
> y.SetName("yo!")
> fmt.Println(y.Name)
>

that the instance (x or y) is pointer or value 
does not matter because the receiver is a dictator.
And indeed it behaves so on the play.

I admit i never noticed before... 

Whatever, 
i did not understand, 
its flawed,
i failed to express appropriately,
no idea.

Most people do not
> think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
> for basically all natural usage these four things are just
> one, the number 3
>

i m a bit chocked, but ok, 
i can t find words to convince you that 
you mixed results and expression.

That is an error to think those 
4 different ways to express the same results
are identical in their form and identical in their result.
Some have identical parameters, ultimately,
they only share the same result.

Its typically a reasoning from mathematics, 
btw, just thinking.


On Thursday, May 11, 2017 at 1:08:30 PM UTC+2, Volker Dobler wrote:
>
> On Thursday, 11 May 2017 12:39:18 UTC+2, mhh...@gmail.com wrote:
>>
>>
>> I d only remark about this,
>> > so there are actually just two cases: Method is on pointer receiver or 
>> not. 
>>
>> From the declarer side, 
>> there is indeed only 2 cases, 
>> which accounts for 50% of the whole,
>> declaration + consumption,
>> the consumer is still accountable for the remaining
>> 50% of the instance consumption and usage.
>>
>>
> I do not agree. Your "other 50%" are indistinguishable,
> they have no observable difference. Most people do not
> think if 1+1+1, 1+2, 2+1 and 3 as four *different* things,
> for basically all natural usage these four things are just
> one, the number 3. It is the same here:
>
> var p *T
> p.M(), (*p).T, (&(*p)).T and so forth might be formally
> different but they are not.
>
> There a two things. Methods on pointer receivers and
> method on values and it does not matter in reasoning about
> the behaviour of the code on how the method is invoked.
>
> V.
>
>
>  
>

-- 
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: adding context.Context to new code

[mhhcbon]

thanks,

..integrating Context into the runtime..


50% runtime, 50% syntax with explicit contextualization.

..The flow of request processing in Go may include multiple goroutines and 
may move across channels;


yes big ? mark here. might the 50% of an handy and explicit syntax help 
with it?

C++ and Java use thread-local Contexts, and while this is convenient, it is 
often a source of mysterious bugs.

thanks! I don't know them, 

I quickly checked according to this 
https://dzone.com/articles/painless-introduction-javas-threadlocal-storage 
I may have totally wrong, the syntax does not look like, not even from a 
100km,
to how i represent go contexts in my head.

This is more like the actor pattern dave cheney talks about in
https://dave.cheney.net/2016/11/13/do-not-fear-first-class-functions
(search for  Let’s talk about actors)

Is the dzone link correctly describe 
what you mentioned as being go context equivalent in java ?

sorry my questions are so basic.

On Thursday, May 11, 2017 at 12:29:11 PM UTC+2, Sameer Ajmani wrote:
>
> I think you are asking whether we considered integrating Context into the 
> runtime, so that it does not need to be passed explicitly. Yes, we 
> discussed this, but decided against it. The flow of request processing in 
> Go may include multiple goroutines and may move across channels; we decided 
> an explicit Context made this much easier to get right. C++ and Java use 
> thread-local Contexts, and while this is convenient, it is often a source 
> of mysterious bugs.
> On Thu, May 11, 2017 at 4:08 AM  wrote:
>
>> Thanks a lot!
>>
>> Might i guess and try to generalize your explanations into
>> "we tried to write a plumber for all cases possible"
>>
>> Which matters a lot, in my humble opinion.
>>
>> At least for the various reasons you put there,
>> simply put,
>> because it seems not technically achievable.
>>
>> Still i m happy you gave me those details, they are of interest indeed.
>>
>> I rather intent to solve the problem on a smaller surface
>> with more predictability, less impossible solution to find.
>> I hope so.
>> And if it saves 90% of the time, that s already a win, imho.
>>
>> May i ask another question, 
>> have you considered to create the plumbing 
>> at runtime rather than statically ?
>> With some intents from the syntax, necessarily 
>> (and yeah go 1 compat will be a problem, let s forget it for 1 minute).
>>
>> I suspect in some aspects in might be handier, 
>> because it might be all about chained func calls and not type system 
>> handling,
>> and it might be easier to interleave the ctx.check in the flaw of ops,
>> I don t know enough to realize for sure.
>>
>>
>>
>> On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:
>>
>>> Our approach was to identify function calls that consume a Context 
>>> (indicated by a call to context.TODO in the function body) and function 
>>> calls that provide a Context (such as RPC and HTTP handlers). Then we use 
>>> the guru callgraph tool to find all call paths from context providers to 
>>> context consumers. These are the call paths that need to have a context 
>>> plumbed through them. 
>>>
>>> Starting from a context consumer, we can work upward to the context 
>>> provider, adding a context parameter to reach intervening function 
>>> signature. Replace context.TODO in the consumer function body with the new 
>>> ctx parameter, then update all the places that call the consumer to pass 
>>> context.TODO. Now we have a new set of context consumers. Repeat until you 
>>> reach the context providers (if you reach main or a Test function, pass 
>>> context.Background instead).
>>>
>>> This works OK for static function calls but gets messy for dynamic 
>>> calls. If you need to add a context parameter to an interface method, now 
>>> you have to update all implementations of that method, too (guru can find 
>>> these for you). And if that interface is outside your control (like 
>>> io.Writer), you cannot change its signature, so you have to pass the 
>>> context some other way (such as via the method receiver).
>>>
>>> This gets yet more complicated if you cannot make atomic changes to all 
>>> callers of your functions, because callers may be in other repositories. In 
>>> this case, you must do an incremental refactoring in multiple steps: each 
>>> change to a function signature involves adding a new function that has the 
>>> context parameter, then changing all existing calls to use the new 
>>> function, while preventing new calls to the old function, so that you can 
>>> finally delete it.
>>>
>>> Inside Google, we ended up not needing to build all this: Context was 
>>> introduced early enough that Go users could plumb it manually where needed. 
>>> I think a context plumbing tool could still be interesting and useful to 
>>> other Go users. I'd love to see someone build it! 
>>>
>>> S
>>>
>>> On Tue, May 9, 2017 at 10:54 AM  wrote:
>>>
 > 

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

Hi,

thanks again!

I m not the one to validate a perfect answer,
i can simply tell that from my go learning and understanding,
i agree top notch 200% no question there 
on this description,
which is weird in fact.

I d only remark about this,
> so there are actually just two cases: Method is on pointer receiver or 
not. 

>From the declarer side, 
there is indeed only 2 cases, 
which accounts for 50% of the whole,
declaration + consumption,
the consumer is still accountable for the remaining
50% of the instance consumption and usage.

Does it make it less dead simple ?

In my example i might have named the method as `whatever`,
still there is an explicit value set on a receiver property.
I don t feel like i have assumed anything from the method name.


On Thursday, May 11, 2017 at 12:17:00 PM UTC+2, Volker Dobler wrote:
>
> On Thursday, 11 May 2017 11:28:33 UTC+2, mhh...@gmail.com wrote:
>>
>> //defined
>>> var x {} // put on heap
>>> var x T // put on stack
>>>
>>> This is definitely a misconception: Allocation on heap vs stack is
>>> totaly unrelated to value methods vs pointer methods. Both examples
>>> might be allocated on the stack or on the heap and this depends
>>> on other factors than methods of T.
>>>
>>
>> what are other factors ? 
>>
>
> Roughly: If the compiler cannot prove that x *can* be safely put on the
> stack then it must go to the heap. Values cannot go safely to the stack
> if they might outlive the scope of this stack frame / the current function.
> This can happen if e.g. a pointer to such value leaves the function, e.g.
> in a return or a channel send. Search for escape analysis if you are 
> interested in the gory details, but I'd urge you not to until the basic 
> stuff
> is total clear.
>  
>
>> (let s keep it short, optimized code is not a topic for me)
>> I understood that the next func call (might be method) 
>> will decide how the instance (to not say value here) is passed.
>>
>> is it ?
>>
>
> Each and every function --- be it a normal function, a function literal,
> a closure, a method, whatever --- completely determines its arguments.
> This includes the receiver of a method which technical is just a normal
> (the first) function argument.
> A func f(int) is called with an argument of type int and a func g(*int) is
> called with a *int. The same is true for receivers. There is *no* magic 
> here! 
>
> The only thing "magical" with methods and their special receiver
> argument that the compiler automatically (automagically) takes the
> address of a value or dereferences a pointer to match the method
> signature. That's all. That's convenience only. A bit less typing, a bit
> fewer braces, it reads nicer.
>
> So: Yes, it is. 
>
>
>>
>>> What can i do with `func (x *T)...` i can not do with `func (x T)`,
 except checking for T==nil ?

>>>
>>> Like explained several times in this thread:
>>> func (x *T) lets you modify *x 
>>>
>>
>> yes, i really want not to question
>>  the ability to modify a value in place.
>>
>> its really about its form.
>>
>> In this code,
>> starting at 0,
>> is case 1 not an aberration,
>> is case 3 is useless
>> https://play.golang.org/p/VyOfZyt7rw
>>
>> Note case 0 is expected to fail and might be detected.
>>
>> ?
>>
>
> All four cases a perfectly fine and useful.
> The problem here is *not* the language construct but probably
> your prejudice that a method called "SetName" should
> modify the x it is "applied" to in any case as it does e.g.
> in Java where there are no (non-primitive) value types.
>
> Let's use abstract function names and let's add some real
> code (as setters and getter in Go are a bit funny).
>
> type T { s string }
> func (t T) M(s string) {
>   if t.s == "" { t.s = "GET" }  // default HTTP method used if nothing 
> else selected
>   foo(t, s)
> }
>
> default := T{}
> default.M("bar")
> post := T{s: "POST"}
> post.M("bar")
>
> Can you see it? M operates on a copy of the value it is invoked
> on. Both default and post will be copied. The copy of default is
> modified and this modification is passed foo. This is nice and
> useful and there is no reason the disallow this type of code.
>
> It is really dead simple: If your methods intend to modify the receiver,
> the receiver must be a pointer. This is one simple rule, clear and
> straightforward, easy to remember and easy to derive in case one
> forgets it.
>
> Again. This all does not depend on what the x in x.M is. it can
> be a pointer or a value, the compiler will take the address or dereference
> as needed, so there are actually just two cases: Method is on
> pointer receiver or not. As I said. Dead simple.
>  
>
>>
>> Probably i miss some understanding about why i can do that,
>> - handle value handling in two places of the program
>> - at initialization, at consumption
>>
>> does it help ?
>>
>
> I'm sorry I do not understand the question.
>
>
> V. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 

[go-nuts] Re: why received can be defined with/without pointer?

[mhhcbon]

to be honest, i m killed because i agree 100% with that explanation.

I friendly scratch my head too because 
i m less interested by the implementation 
than by the packaging you put on it, 
and the effects that it produces on the end user,
if i can say so.

In that regards the explanation you gave can t 
help me to get that idea out of my head,
i think.


On Thursday, May 11, 2017 at 11:53:37 AM UTC+2, Chris Hopkins wrote:
>
>
>>
>> In this code,
>> starting at 0,
>> is case 1 not an aberration,
>> is case 3 is useless
>> https://play.golang.org/p/VyOfZyt7rw
>>
>> Note case 0 is expected to fail and might be detected.
>>
>>>
>>> As a dumb hardware engineer I too have struggled with this in the past.
> 2 rules I find helped:
> 1) Everything into a function is passed as a copy
> 2) If you need to modify something passed to you in a function then you 
> need not a copy of the thing but the address of the thing you want to modify
> so taking your code for both cases 0 & 1:
>  func (v valueType) SetName(n string) {
> v.Name = n
> }
> when this function runs a local bit of storage is created (probably on the 
> stack as escape analysis would determine that the value can't escape the 
> scope) and the current value of the data is copied into that storage. That 
> storage is then modified. The function then returns. The local storage goes 
> out of scope and you are left with your original data unchanged.
>
> for cases 2&3
> func (v *refType) SetName(n string) {
> v.Name = n
> }
> This time again the function runs and there is a local piece of storage 
> created (again called v) this time the local storage (probably on the stack 
> as v cannot escape the scope of that function) and v gets the pointer to 
> the variable it was called on copied into it instead of the value.
> So when you set the name it uses the local copy of the pointer to access 
> the Name field. Because this is pointing to the underlying storage for the 
> original structure that structure is modified. 
> What might be causing confusion here (because it used to confuse me with 
> go) is that go is doing something automatically under the hood. When you 
> type v.Name it knows that *refType does not have a field Name. It knows 
> that you're trying to access the structure addressed by the pointer and so 
> automatically de-references the pointer for you i.e. takes the address held 
> in v, works out what offset from that address it has to use to get at the 
> Name field and then directs the assignment to that new address.
>
> At least that's how I think it works. I'm sure someone will correct me, as 
> this would otherwise be the first time I had this low level detail of 
> software correct ;-)
>
> HTH
>
> Chris
>

-- 
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: why received can be defined with/without pointer?

[mhhcbon]

yeah i totally admit i don t master the subject at all,
and i would prefer not have to talk about heap/stack thing, 
by incidence what, still, bugs me is on the intersection
of many topics which make it difficult to talk about.

thanks again for your attempts even though i lost you 
and, i guess, hurt your love for English grammar, 
if you have any.

in this

//defined
> var x {} // put on heap
> var x T // put on stack
>
> This is definitely a misconception: Allocation on heap vs stack is
> totaly unrelated to value methods vs pointer methods. Both examples
> might be allocated on the stack or on the heap and this depends
> on other factors than methods of T.
>

what are other factors ? 
(let s keep it short, optimized code is not a topic for me)
I understood that the next func call (might be method) 
will decide how the instance (to not say value here) is passed.

is it ?


> What can i do with `func (x *T)...` i can not do with `func (x T)`,
>> except checking for T==nil ?
>>
>
> Like explained several times in this thread:
> func (x *T) lets you modify *x 
>

yes, i really want not to question
 the ability to modify a value in place.

its really about its form.

In this code,
starting at 0,
is case 1 not an aberration,
is case 3 is useless
https://play.golang.org/p/VyOfZyt7rw

Note case 0 is expected to fail and might be detected.

?

Probably i miss some understanding about why i can do that,
- handle value handling in two places of the program
- at initialization, at consumption

does it help ?

if not, no worries, i ll learn more and try again later.

On Saturday, May 6, 2017 at 9:39:56 AM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> Question about the receiver of a func.
>
> It can be defined as star/no star, and consumed as star/nostar.
>
> The understanding i have so far is,
> it let the developer define the memory model he d like to use.
>
> It leads to cases such as 
> - define start/nostar on a type
> - consume a stared type as a value
> - consume a value type as a pointer
>
> Which is quiet confusing for beginners, and me.
>
> While i understand that someone would like to declare
> a type is consumed by value, I do not understand the last two cases.
> when why they might happen.
>
> Can you explain their value added ?
>
> Thinking further more,
>
> Not speaking about dereferencing a pointer,
> but initialization of a type in a way that is undesired to the provider.
>
> The way a type is consumed by value or reference,
> is an act of design rules (i add a property on the type that make sure it 
> is never copied/referenced)
> or an act of consumption, 
> the designer did not enforce any rule on the type, i might initialize it 
> as star/nostar at convenience.
>
> The fact it is let possible today 
> - to not enforce the way a type is manipulated, 
>leads to confusion and error (famous one is https://godoc.org/sync)
> - to define at both declaration / usage the star/nostar,
>is confusing, again
>
> so yeah, wondering quiet a lot about that,
> and given the fact i do not understand few use cases,
> i think this could be better handled.
>
> For example, 
>
> if a new keyword appear to ensure a type is 
> consumed by value, that might be helpful to provide
> a function to make sure that type won t exceed the stack size
> and escape to the heap.
> that keyword would help api designer to avoid consumption problems.
> nop ?
>
> If a new keyword would appear to ensure a type is initialized by reference,
> might help to detect value copy and warn/error when that case is met.
> That would helped consumers to avoid problems.
> nop ?
>
> If the receiver type was not able to be star/nostar,
> that d probably help to get ride of confusion,
> nop ?
>

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

[go-nuts] Re: [ANN] scaffolder - web application servers to order

[mhhcbon]

It s awesome, 
in my opinion, this is the way i want to consume go in the future.

pragmatic, correct, fast, repeatable.

in additions to what go provides, 
fast build, cross platform, easy to package

Although, my very personal opinion,
lets do smaller program that combines together,
in the spirit of unix tooling, rather than a
big boiler plate thing in the spirit of symfony 
or alike (really just an example sorry i cited your project).

A big Yes for such projects!

Let s generate all the thing and get drinks to talk about it :D

PS: i remember you talked about it earlier, shame i missed it at that time.

On Wednesday, May 10, 2017 at 6:31:22 PM UTC+2, Simon Ritchie wrote:
>
> Given a JSON description of some database tables, the scaffolder tool 
> creates the database and generates a web application server to manage it.  
> The resulting app server implements the Create, Read, Update and Delete 
> (CRUD) operations on the tables.
>
> The idea for the scaffolder comes from the Ruby-on-Rails scaffold 
> generator.
>
> The app server is presented as Go source code and HTML templates, plus 
> some unit and integration tests.  The design follows the Model, View 
> Controller (MVC) pattern.  The HTTP requests follow the REST pattern.
>
> The tool is here:  https://github.com/goblimey/scaffolder
>
> There are some screen shots of the resulting web pages here:   
> http://www.goblimey.com/scaffolder/2.4.running.the.server.html
>
> Producing any web application involves a lot of boilerplate work, and this 
> tool aims to automate some of that without imposing too many design 
> decisions on the result.  
>
> The generated web pages are fairly primitive, with very little styling.  
> This is deliberate - if you want to use the result as a basis for building 
> your own application, you will want to define your own styling, and the 
> pages are structured to allow that.
>
> The material produced by the scaffolder is defined by a set of text 
> templates.  For each table it produces from these templates a model, a 
> controller and set of HTML templates to produce the views.  (So we have 
> templates producing templates.)
>
> The scaffolder tool itself is very simple.  It just reads the JSON 
> specification into a data structure, enhances that data a little and then 
> iterates through it, supplying it to the templates.   This approach makes 
> the tool very flexible - if it doesn't do quite what you want, it's very 
> easy to tweak it.
>
> This idea of using a simple driver program, JSON data and templates to 
> generate a result is very powerful.  It can be used to produce all sorts of 
> material that follows a prototypical pattern.
>
> All comment on this project are welcome.
>

-- 
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: adding context.Context to new code

[mhhcbon]

Thanks a lot!

Might i guess and try to generalize your explanations into
"we tried to write a plumber for all cases possible"

Which matters a lot, in my humble opinion.

At least for the various reasons you put there,
simply put,
because it seems not technically achievable.

Still i m happy you gave me those details, they are of interest indeed.

I rather intent to solve the problem on a smaller surface
with more predictability, less impossible solution to find.
I hope so.
And if it saves 90% of the time, that s already a win, imho.

May i ask another question, 
have you considered to create the plumbing 
at runtime rather than statically ?
With some intents from the syntax, necessarily 
(and yeah go 1 compat will be a problem, let s forget it for 1 minute).

I suspect in some aspects in might be handier, 
because it might be all about chained func calls and not type system 
handling,
and it might be easier to interleave the ctx.check in the flaw of ops,
I don t know enough to realize for sure.


On Wednesday, May 10, 2017 at 11:40:27 PM UTC+2, Sameer Ajmani wrote:
>
> Our approach was to identify function calls that consume a Context 
> (indicated by a call to context.TODO in the function body) and function 
> calls that provide a Context (such as RPC and HTTP handlers). Then we use 
> the guru callgraph tool to find all call paths from context providers to 
> context consumers. These are the call paths that need to have a context 
> plumbed through them. 
>
> Starting from a context consumer, we can work upward to the context 
> provider, adding a context parameter to reach intervening function 
> signature. Replace context.TODO in the consumer function body with the new 
> ctx parameter, then update all the places that call the consumer to pass 
> context.TODO. Now we have a new set of context consumers. Repeat until you 
> reach the context providers (if you reach main or a Test function, pass 
> context.Background instead).
>
> This works OK for static function calls but gets messy for dynamic calls. 
> If you need to add a context parameter to an interface method, now you have 
> to update all implementations of that method, too (guru can find these for 
> you). And if that interface is outside your control (like io.Writer), you 
> cannot change its signature, so you have to pass the context some other way 
> (such as via the method receiver).
>
> This gets yet more complicated if you cannot make atomic changes to all 
> callers of your functions, because callers may be in other repositories. In 
> this case, you must do an incremental refactoring in multiple steps: each 
> change to a function signature involves adding a new function that has the 
> context parameter, then changing all existing calls to use the new 
> function, while preventing new calls to the old function, so that you can 
> finally delete it.
>
> Inside Google, we ended up not needing to build all this: Context was 
> introduced early enough that Go users could plumb it manually where needed. 
> I think a context plumbing tool could still be interesting and useful to 
> other Go users. I'd love to see someone build it! 
>
> S
>
> On Tue, May 9, 2017 at 10:54 AM  wrote:
>
>> > I've done a limited form of this using awk ;-)
>>
>> if you have a minute,
>>
>> can you tell more about what limited you 
>> in your attempts and which trade made you stop (guessing), 
>> if any ?
>>
>> Do you still think it be awesome ? 
>> Or have you made your mind to an opposite position ? 
>> if so, For which reasons?
>>
>> My tool is very poor, consider it as on going, a place for inspiration to 
>> get started from absolutely no idea to lets get a dirty prototype.
>> not sure yet how long is going to be the road, still digging :)
>>
>>
>> On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote:
>>
>>> The eg tool can execute simple refactoring steps, but automating context 
>>> plumbing through a chain of calls is an open problem. Alan Donovan put some 
>>> thought into this a few years ago, and I've done a limited form of this 
>>> using awk ;-)
>>>
>> On Tue, May 9, 2017 at 6:10 AM  wrote:
>>>
>> I want something similar too.

 Automatic and smart insertion of context args in a chain of calls.

 Methods signature updates are easy, but how to appropriately insert 
 context check in the ast  ?
 I m not sure yet.


 >The difficulty here seems to differentiate intra package calls from 
 calls to standard/3rd party libraries which shouldn't be having new param.

 That does not sound too difficult, from the pkg identifier, lookup for 
 the import path, for every import path, exists in GOROOT ?

 Please put updates here anything you want to share.

 At that moment i m using this package to help me with ast, 
 https://github.com/mh-cbon/astutil

 might be a start even though it needs refactoring.


 On Monday, May 8, 

Re: [go-nuts] Re: adding context.Context to new code

[mhhcbon]

> I've done a limited form of this using awk ;-)

if you have a minute,

can you tell more about what limited you 
in your attempts and which trade made you stop (guessing), 
if any ?

Do you still think it be awesome ? 
Or have you made your mind to an opposite position ? 
if so, For which reasons?

My tool is very poor, consider it as on going, a place for inspiration to 
get started from absolutely no idea to lets get a dirty prototype.
not sure yet how long is going to be the road, still digging :)

On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote:
>
> The eg tool can execute simple refactoring steps, but automating context 
> plumbing through a chain of calls is an open problem. Alan Donovan put some 
> thought into this a few years ago, and I've done a limited form of this 
> using awk ;-)
>
> On Tue, May 9, 2017 at 6:10 AM  wrote:
>
>> I want something similar too.
>>
>> Automatic and smart insertion of context args in a chain of calls.
>>
>> Methods signature updates are easy, but how to appropriately insert 
>> context check in the ast  ?
>> I m not sure yet.
>>
>>
>> >The difficulty here seems to differentiate intra package calls from 
>> calls to standard/3rd party libraries which shouldn't be having new param.
>>
>> That does not sound too difficult, from the pkg identifier, lookup for 
>> the import path, for every import path, exists in GOROOT ?
>>
>> Please put updates here anything you want to share.
>>
>> At that moment i m using this package to help me with ast, 
>> https://github.com/mh-cbon/astutil
>>
>> might be a start even though it needs refactoring.
>>
>>
>> On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote:
>>>
>>> I'm adding tracing to an existing code base with many packages and it 
>>> seems the best way to have context's passed around is to just have every 
>>> method take a context.Context. 
>>>
>>> Is there any tooling for converting a code base/package to have:
>>> (a) context.Context as the first parameter in each function - ctx 
>>> context.Context
>>> (b) for any function that has changed, have its callers (within that 
>>> package) pass ctx as the first arg
>>>
>>> The difficulty here seems to differentiate intra package calls from 
>>> calls to standard/3rd party libraries which shouldn't be having new param.
>>>
>> -- 
>> 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: use of builtin print for debug

[mhhcbon]

On Tuesday, May 9, 2017 at 2:46:03 PM UTC+2, Marvin Renich wrote:
>
> [I set an explicit Reply-To header because I do not want duplicate 
> emails.  Please do not CC me; I read this list.] 
>

sure.
 

>
> * mhh...@gmail.com   [170509 
> 07:40]: 
> > : ( thanks 
> > 
> > $ man gofmt 
> > Aucune entrée de manuel pour gofmt 
> > /no such entry/ 
>
> One of many advantages of the Debian distribution is that policy 
> mandates that any command which the end user is expected to use must 
> have a man page.  Many thanks go to the Debian maintainers of the Go 
> packages for their hard work, including, but not limited to, converting 
> Go package documentation into proper man pages.  This is not busy work; 
> rather it is very, very helpful! 
>

yeah that sounds awesome, why its not standardized?
 

>
> > *$ gofmt -husage: gofmt [flags] [path ...]  -r stringrewrite 
> rule 
> > (e.g., 'a[b:len(a)] -> a[b:]')* 
> > 
> > https://golang.org/cmd/gofmt/#hdr-Examples 
>
> Indeed, this is the right place to find the official Go documentation 
> for this tool. 
>

yes indeed, i m more interested to compare it with your man pages,
they looks awesome.
 

>
> > How to take advantage of it ? 
> > He needs to add new func, probably. 
> > And maybe to rename expr.Call.Name. 
>
> If I were trying to extricate myself from the OP's position, my first 
> attempt would be 
>
>   gofmt -r 'print -> debug.Print' 
>

For completeness,

gofmt -r 'print -> debug.Print' ...file.go
 
otherwise it stucks on stdin.


> and then add a debug package where I could make that function empty if I 
> wanted.  


Maybe he could declare the package in its gopath then run goimports ?
I mean that command that adds imports automagically.
 

> If you want to get fancy, use build tags so that 
>
>   go build -tags debug 
>
> will build with debugging turned on, but without the tag, the debug 
> functions are empty. 
>

mhh, not convinced :)
 

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

Re: [go-nuts] why received can be defined with/without pointer?

[mhhcbon]

On Tuesday, May 9, 2017 at 2:21:52 PM UTC+2, Volker Dobler wrote:
>
> On Tuesday, 9 May 2017 12:30:38 UTC+2, mhh...@gmail.com wrote:
>>
>> in short and put straightly,
>> 1- i think its not appropriate to let us 
>> define pointer/non pointer attribute 
>> of a type over multiple points in the code.
>> In my experience of a beginner, its a pain that teaches you to always use 
>> pointer by default.
>>
>
> Please keep in mind that while "friendly to newcomers/beginner"
> _is_  important it cannot be the main (or even only) goal of a language
> targeting productivity.
>

I don t intend to, did i, i have not noticed, i want not.
I intent to think about it from my pov.
The how a solution might embrace all those cases expresses,
is subject to debate, if any there should be indeed.
 

>  
>
>> 2- The current way to define a type as value/pointer does indeed serves 
>> its job, but absolutely nothing more,
>> that is where i feel there are certain lacks. 
>>
>
> What more than "serve[...] its job" would you expect from a
> language construct. Go offers two types of methods, those
> defined on value types and those defined on pointer types.
> Both are useful, both server their job. What's wrong here?
>  
>

Help me to not copy a pointer value when its inappropriate.
If there s a purpose at defining star/nostar on a type,
but not mix them either,
help me to make that happen with ease, rather than pain.
 
That is, i agree there s point in defining star/nostar like property on a 
type,
(note i don t speak of receiver at purpose), see below.


I have read both your thoughts and the doc, i have not found a 
>> "useful feature". I respectfully did not.
>> (hope the ability of value/pointer is not the feature you talk about 
>> because i don t intend to remove it, and its barely just a feature i think, 
>> its critical)
>>
>
> It is useful to have methods on values and it is useful to have
> methods on pointers. Both are useful: Pointer methods make
> mutation possible and value methods provide a notion of 
> const-ness which is useful too and value methods can be invoked
> on non-addressable values which is useful too.
> This type of usefulness might not be obvious on first encounter
> with these two types of methods.
>

yes. The consumer can decide how to consume the value,
according if its provided/defined type is star/nostar.

//defined
var x {} // put on heap
var x T // put on stack

// provided
//func (r Value) n(x T) {().Hello()} // x passed from stack (there might 
be some magic here, not the point, i think)
//func (r Value) n(x *T) {(*x).Hello()} // always get x from heap
//func (r Value) n(x InterfaceDef){x.Hello()} // x is pointer to value that 
matches intf.

Why does it matter that the declarer knows about this in its receiver ? 
I can t find much examples about that, besides testing if the receiver is 
nil.

That the declarer defines a type to be handled by copy 
needs proper out values,
not only nostar def on the receiver,
does it ?



>  
>
imho, we should not defines the way the type is stored in memory
>> at its declaration, unless it produces useful barriers to mistakes.
>>
>
> I'm not sure I understand: Something like
> type S struct { a int64; b[3]complex128 }
> actually defines storage layout and I think that the ability to control
> is this in Go is a good (and useful thing).
>
>
yes, i m really focused about the receiver.

by incidence i come to think about the struct, indeed somehow,

type S ref { a int64; b[3]complex128 } // prevent copy of S
type S value { a int64; b[3]complex128 } // prevent referencing to S
type S struct { a int64; b[3]complex128 } // does not matter

What can i do with `func (x *T)...` i can not do with `func (x T)`,
except checking for T==nil ?


So i think there should be only no-star on receiver.
>>
>  
> A "non-star" receiver would be a method on a value
> (non-pointer, non-interface) type.
> This would basically disallow methods to mutate the receiver
> state as only a copy of the receiver would be mutated.
> Are you proposing that methods on values should not
> operate on a copy of the value? 
>

The consumer can tell about it.

If he receives a value `func (x T)` he can say `x.Hello()` or `().Hello()`
If he receives a pointer `func (x *T)` he can say `x.Hello()` or 
`(*x).Hello()` 

if he defines `var x T` and do  `().Hello()` is weird.
if he defines `var x *T` and do  `(*x).Hello()` is weird.

 This would be possible but

> it would be an exception to the normal rules how values
> are copied during function invocation. 
>

Possibly yes.
 

> Would such an exception
> really make the language easier to understand? 
>

digging.
 

> And if yes:
> We would lose the notion of const-ness and method
> invocation on non-addressable values would be limited.
>
> I think we misunderstood and hope that helps you to find out about it.
or else, hope i can understand your misunderstanding of my questions.
 

>  
>
>> And that to the question "where to store that 

Re: [go-nuts] Re: use of builtin print for debug

[mhhcbon]

: ( thanks

$ man gofmt
Aucune entrée de manuel pour gofmt
/no such entry/




*$ gofmt -husage: gofmt [flags] [path ...]  -r stringrewrite rule 
(e.g., 'a[b:len(a)] -> a[b:]')*

https://golang.org/cmd/gofmt/#hdr-Examples


How to take advantage of it ?
He needs to add new func, probably.
And maybe to rename expr.Call.Name.


On Tuesday, May 9, 2017 at 1:34:26 PM UTC+2, Marvin Renich wrote:
>
> * mhh...@gmail.com   [170509 
> 07:10]: 
> > Also i think go has already several patchers that you might get 
> > inspiration from, not sure where they are located. Sorry : x 
>
> Try man gofmt and look at -r. 
>
> ...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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: suggest: improve go gen intergration for non core code ?

[mhhcbon]

thanks for feedback,

i put that in regards to my understanding of go generate,
re run it anytime its needed, anytime you changed your code,

please see
https://groups.google.com/forum/#!topic/golang-nuts/8L_bjxB-_T0

that concretely demonstrates why i don t go with the "usual thinking".

On Tuesday, May 9, 2017 at 1:29:54 PM UTC+2, Ian Davis wrote:
>
>
> On Tue, 9 May 2017, at 12:12 PM, mhh...@gmail.com  wrote:
>
> Maybe that could be a simple go sub command: 
>
> go gun [...packages]
>
> gen+run=>gun 
>
> Sure i could do on my end, it won t be adopted so ... useless.
>
>
> Usually go generate is intended to be run once and the results committed 
> to the repository. It's not expected that end users of the code re-run it 
> regularly.
>
> 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.

[go-nuts] Re: suggest: improve go gen intergration for non core code ?

[mhhcbon]

Maybe that could be a simple go sub command: 

go gun [...packages]

gen+run=>gun 

Sure i could do on my end, it won t be adopted so ... useless.

On Friday, May 5, 2017 at 3:15:25 PM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> just a suggestion to improve go gen adoption rate, maybe.
>
> go generate is not included in the go build pipeline,
> for good reasons, especially for the core code.
>
> It s a two step command,
> 1- go gen
> 2- go build
>
> Although, since vendoring is implemented,
> I think it would be good to re think its usage,
> depending if you are building core code Vs random package.
>
> When you write a random package (no better name sorry),
> if `go gen` was included into the `go run` command,
> i believe that d help to improve its adoption rate.
>
> In that case that would only apply to the package files,
> excluding core code, vendored code,
> and those generated files must be committed to the vcs.
>
> Doing so, when pkg A depends on B,
> and that B uses go gen, the files would already be present, 
> thus no need to gen then B.
>
> Only pkg A might need 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] Re: use of builtin print for debug

[mhhcbon]

ast transformation seems a good candidate for your problem.

Should not be very difficult.

start with 
https://godoc.org/golang.org/x/tools/go/loader

Learn ast struct with 
https://golang.org/pkg/go/ast/#Print
might be helpful 
https://gist.github.com/mh-cbon/3ed5d9c39e9635cfed0f89698133

Also i think go has already several patchers that you might get inspiration 
from,
not sure where they are located. Sorry : x

On Tuesday, May 9, 2017 at 2:01:19 AM UTC+2, Tong Sun wrote:
>
> I know using of builtin print is not encouraged, but it's convenient, and 
> I've sprinted it all over my code. 
>
> Now debugging is over, I need to disable all the builtin prints. Is there 
> any easy way to toggle the printing on and off, so that I can enable 
> debugging any time in the future? I've tried many ways, but seems 
> commenting them off is the only way I can find. 
>
> Please help. 
>

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

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

[mhhcbon]

Hi,

i want to share some more with you as i feel like it looks good to whoever 
interested into speeding up his programming experience with go ;)

Until now i presented works that took a type T and produce a derived type 
T2 of it.
Easy stuff, not so useful unless you only want to do rpc stuffs.
But still cool as this pattern helps to implement implement of 
proxy-like/facade type that are interesting.

Today i want to share a new feature i added, contextual parameters.

The methods parameters are not only meaningful by their type definition, 
but also by their names.

So it become possible to write this kind of thing and got them to work 
seamlessly,

func (t *Controller) UpdateByID(urlID int, reqBody *Tomate) *Tomate {


Simply put, 
UpdateByID look for an ID value in the URL (might be route params, query 
values),
takes the req body and somehow decodes it to an *Tomate instance.

That s it, you combine that +jsoner +httper and 
you got hundreds of lines of generated for you, 
ready to consume.
boom, lets get a beer.

That works with cookies/session/post/req/url/get because the type is 
consumed by http domain related generators (aka the context).

Also some methods parameters signature are recognized to work in the 
context of an http thing,
so you can write

func (t *Controller) TestVars1(w http.ResponseWriter, r *http.Request) {



And it just works too. the generators at each step understand them and 
behave appropriately.


But its not all, what i described is pretty interesting to maintain code 
easily,
but there s no way to declare additional information such route pattern or 
else,

So i added annotations support.


Thus i can write,

// GetByID ... 
// @route /{id} 
// @methods GET 
func (t *Controller) GetByID(urlID int) *Tomate

And get a program generated that handles all those intents for me in a 
coherent manner :D

Gonna have a beer now.


Have fun!



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

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

Re: [go-nuts] why received can be defined with/without pointer?

[mhhcbon]

thanks, 

> The definition of the 
method always makes it clear whether you are passing a value of the 
type or a pointer to the type.  People defining methods on large types 
should know which one want to use.

in short and put straightly,
1- i think its not appropriate to let us 
define pointer/non pointer attribute 
of a type over multiple points in the code.
In my experience of a beginner, its a pain that teaches you to always use 
pointer by default.
2- The current way to define a type as value/pointer does indeed serves its 
job, but absolutely nothing more,
that is where i feel there are certain lacks. 

As you say the keyword is superfluous, but not practical imho,
in any cases can it be made helpful to help us prevent error or undesired 
side effects ?
Can the compiler helped not to copy a pointer when it is inappropriate.


> That would lose a clearly useful feature from the language.  In 
particular, if you only permit pointer receivers or value receivers, 
which one do you permit?  See also 
https://golang.org/doc/faq#methods_on_values_or_pointers . 

I have read both your thoughts and the doc, i have not found a 
"useful feature". I respectfully did not.
(hope the ability of value/pointer is not the feature you talk about 
because i don t intend to remove it, and its barely just a feature i think, 
its critical)

imho, we should not defines the way the type is stored in memory
at its declaration, unless it produces useful barriers to mistakes.

So i think there should be only no-star on receiver.
And that to the question "where to store that instances" (use pointer or 
value?) the answer should be provider only
at the instanciation time. (see below i have a tech question about it btw, 
please)

The only feature it disables i can think about is the feature which helps 
to tell
if your receiver is nil/or not.
I question this feature and wonder if it was a worthy trade against other 
possibilities,
if one wants to imagine them, obviously.


Side Q,

Given this program, with an hypothetical Value type with a method Hello 
without side effects.

func main(){
x(T{})
}

func x(T Value){
().Hello() // How is this happening ? 
// Does it escape the variable ahead of time so x become x(T *Value) ? 
// Or does it take the address of T wherever it is in memory to manipulate 
it ?
// or maybe it does a copy of T to new *T, do the work, copies, then frees 
it ?
}

thanks again for your time.


On Monday, May 8, 2017 at 8:39:48 PM UTC+2, Ian Lance Taylor wrote:
>
> On Sun, May 7, 2017 at 3:37 AM,   wrote: 
> > yes, sorry you scratched your head 
> > 
> > https://play.golang.org/p/Gg6Euyvsw6 
> > 
> > this example shows that it is possible to do all the things. 
> > hth. 
> > 
> > I m curious to know more about other questions. 
> > Maybe they are not good idea, or not technically achievable. 
> > Just curious. 
>
>
> > if a new keyword appear to ensure a type is 
> > consumed by value, that might be helpful to provide 
> > a function to make sure that type won t exceed the stack size 
> > and escape to the heap. 
> > that keyword would help api designer to avoid consumption problems. 
> > nop ? 
>
> To me that seems like a very abstract concern.  The definition of the 
> method always makes it clear whether you are passing a value of the 
> type or a pointer to the type.  People defining methods on large types 
> should know which one want to use.  There is no need for an additional 
> keyword; the method definition is clear in any case. 
>
>
> > If a new keyword would appear to ensure a type is initialized by 
> reference, 
> > might help to detect value copy and warn/error when that case is met. 
> > That would helped consumers to avoid problems. 
> > nop ? 
>
> Where would such a keyword be used?  The definition of the type makes 
> clear whether it has values or pointers. 
>
>
> > If the receiver type was not able to be star/nostar, 
> > that d probably help to get ride of confusion, 
> > nop ? 
>
> That would lose a clearly useful feature from the language.  In 
> particular, if you only permit pointer receivers or value receivers, 
> which one do you permit?  See also 
> https://golang.org/doc/faq#methods_on_values_or_pointers . 
>
> 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.

[go-nuts] Re: adding context.Context to new code

[mhhcbon]

I want something similar too.

Automatic and smart insertion of context args in a chain of calls.

Methods signature updates are easy, but how to appropriately insert context 
check in the ast  ?
I m not sure yet.

>The difficulty here seems to differentiate intra package calls from calls 
to standard/3rd party libraries which shouldn't be having new param.

That does not sound too difficult, from the pkg identifier, lookup for the 
import path, for every import path, exists in GOROOT ?

Please put updates here anything you want to share.

At that moment i m using this package to help me with ast, 
https://github.com/mh-cbon/astutil

might be a start even though it needs refactoring.

On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote:
>
> I'm adding tracing to an existing code base with many packages and it 
> seems the best way to have context's passed around is to just have every 
> method take a context.Context. 
>
> Is there any tooling for converting a code base/package to have:
> (a) context.Context as the first parameter in each function - ctx 
> context.Context
> (b) for any function that has changed, have its callers (within that 
> package) pass ctx as the first arg
>
> The difficulty here seems to differentiate intra package calls from calls 
> to standard/3rd party libraries which shouldn't be having new param.
>

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

Re: [go-nuts] why received can be defined with/without pointer?

[mhhcbon]

yes, sorry you scratched your head

https://play.golang.org/p/Gg6Euyvsw6

this example shows that it is possible to do all the things.
hth.

I m curious to know more about other questions.
Maybe they are not good idea, or not technically achievable.
Just curious.


On Sunday, May 7, 2017 at 2:55:58 AM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, May 6, 2017 at 3:39 AM,   wrote: 
> > 
> > Question about the receiver of a func. 
> > 
> > It can be defined as star/no star, and consumed as star/nostar. 
> > 
> > The understanding i have so far is, 
> > it let the developer define the memory model he d like to use. 
> > 
> > It leads to cases such as 
> > - define start/nostar on a type 
> > - consume a stared type as a value 
> > - consume a value type as a pointer 
>
> You are not permitted to define a method on a named type defines as a 
> pointer type, so I don't understand your cases.  Can you describe them 
> using actual Go code rather than words? 
>
> 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.

[go-nuts] Re: download link - 400 error code

[mhhcbon]

hi,

you are referring to the downloads available here 
https://golang.org/dl/?

Here the linux one works.

i can t find mirror of them.
Have you searched for yourself ?

Maybe we might try to host it over bt if no one come up with a mirror.

Do you know a host that works for you?

On Saturday, May 6, 2017 at 2:12:05 PM UTC+2, Abbas Naghdi wrote:
>
> hi.
>
> Yes, I am an Iranian.
> Error number 403 download for my queries.
> Then I use VPN to my display error number 400.
> Where is problem?
>

-- 
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 with comments

[mhhcbon]

awesome package :) The syntax looks great!

Especially the forgiving one.



On Saturday, May 6, 2017 at 2:01:26 PM UTC+2, Michael Gross wrote:
>
> Hi,
>
> even tough json is a data exchange format I find it sometimes useful to 
> use these files as configs. 
> Then after a while you would like to add a comment or some other person 
> has forgotten to format the file and the formatter you are using messes the 
> file up. also when it gets bigger its sometimes very unreadable.
>
> A solution to this could be to use a file format with comments which 
> extends json. Something like
> YAML or http://hjson.org/
>
> If I did know about hjson earlier I would probably just try to have people 
> use the same formatter in project I take part. Since I did not, here is a 
> proposal for a json extension with a formatter which tries to mimic the 
> behavior of gofmt.
>
> https://komkom.github.io/
>
> This is all in early development - any feedback would be greatly 
> appreciated!
>
> Best Michael
>

-- 
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 received can be defined with/without pointer?

[mhhcbon]

Hi,

Question about the receiver of a func.

It can be defined as star/no star, and consumed as star/nostar.

The understanding i have so far is,
it let the developer define the memory model he d like to use.

It leads to cases such as 
- define start/nostar on a type
- consume a stared type as a value
- consume a value type as a pointer

Which is quiet confusing for beginners, and me.

While i understand that someone would like to declare
a type is consumed by value, I do not understand the last two cases.
when why they might happen.

Can you explain their value added ?

Thinking further more,

Not speaking about dereferencing a pointer,
but initialization of a type in a way that is undesired to the provider.

The way a type is consumed by value or reference,
is an act of design rules (i add a property on the type that make sure it 
is never copied/referenced)
or an act of consumption, 
the designer did not enforce any rule on the type, i might initialize it as 
star/nostar at convenience.

The fact it is let possible today 
- to not enforce the way a type is manipulated, 
   leads to confusion and error (famous one is https://godoc.org/sync)
- to define at both declaration / usage the star/nostar,
   is confusing, again

so yeah, wondering quiet a lot about that,
and given the fact i do not understand few use cases,
i think this could be better handled.

For example, 

if a new keyword appear to ensure a type is 
consumed by value, that might be helpful to provide
a function to make sure that type won t exceed the stack size
and escape to the heap.
that keyword would help api designer to avoid consumption problems.
nop ?

If a new keyword would appear to ensure a type is initialized by reference,
might help to detect value copy and warn/error when that case is met.
That would helped consumers to avoid problems.
nop ?

If the receiver type was not able to be star/nostar,
that d probably help to get ride of confusion,
nop ?

-- 
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] suggest: improve go gen intergration for non core code ?

[mhhcbon]

Hi,

just a suggestion to improve go gen adoption rate, maybe.

go generate is not included in the go build pipeline,
for good reasons, especially for the core code.

It s a two step command,
1- go gen
2- go build

Although, since vendoring is implemented,
I think it would be good to re think its usage,
depending if you are building core code Vs random package.

When you write a random package (no better name sorry),
if `go gen` was included into the `go run` command,
i believe that d help to improve its adoption rate.

In that case that would only apply to the package files,
excluding core code, vendored code,
and those generated files must be committed to the vcs.

Doing so, when pkg A depends on B,
and that B uses go gen, the files would already be present, 
thus no need to gen then B.

Only pkg A might need 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.

Re: [go-nuts] go get + build flag to set version var

[mhhcbon]

sorry, mistake,

** My point is not criticize, but the way you describe the *how*
that pipeline should happen IRL.
That desciption seems taken from
controlled environment such as 
- internal company
- oss distro

On Friday, May 5, 2017 at 2:57:44 PM UTC+2, mhh...@gmail.com wrote:
>
> yeah i agree.
>
> But (:/), i think its pipeline issue in the consumption of a go package.
>
> In the same way the language is made to prevent user errors (as much as 
> possible, and its difficult)
> that go get pipeline usage should help in that matter too.
>
> My point is not criticize, but the way you describe the *how*
> that pipeline should happen IRL seems taken from
> controlled environment such as 
> - internal company
> - oss distro
>
> where every users is somehow subordinated to a common decision taker, a 
> commander ;)
>
> Typically inside google you can use such rules and later blame the end dev 
> which did not followed it.
>
> On the internet it is much less possible.
>
> And yes hopefully, so far, only one ticket :)
>
> But scale it by number of package providers * number of package users and 
> you get a mess of repeated questions, 
> no ?
>
>
> On Friday, May 5, 2017 at 2:47:51 PM UTC+2, Jakob Borg wrote:
>>
>> On 5 May 2017, at 14:41, mhh...@gmail.com wrote: 
>> > 
>> > Just to add on this that the fact i provide pre built bin is not 
>> winning against go get, 
>> > 
>> > The repo i took as example is providing, 
>> > https://github.com/mh-cbon/emd/releases 
>> > 
>> > and all possible ways to install it i can provide, 
>> > https://github.com/mh-cbon/emd#install 
>> > 
>> > So yeah i did my best, i loosed. 
>>
>> You don't have *that* many issues opened. :) Here you are probably 
>> targeting developers. They may be somewhat more likely to grab it from 
>> source than others. They can probably also answer the question "what git 
>> hash did you build from?" if that seems relevant. 
>>
>> On issues from other users I can usually get a feeling for whether the 
>> bug is something I expect or something that should not be possible. If the 
>> latter and the build seems suspect, "can you retry this with the latest 
>> official build please?". 
>>
>> But yeah. The source is out there, you can't *prevent* people from 
>> compiling it. (Other than not being go-gettable, which has advantages and 
>> disadvantages.) 
>>
>> //jb
>
>

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

Re: [go-nuts] go get + build flag to set version var

[mhhcbon]

yeah i agree.

But (:/), i think its pipeline issue in the consumption of a go package.

In the same way the language is made to prevent user errors (as much as 
possible, and its difficult)
that go get pipeline usage should help in that matter too.

My point is not criticize, but the way you describe the *how*
that pipeline should happen IRL seems taken from
controlled environment such as 
- internal company
- oss distro

where every users is somehow subordinated to a common decision taker, a 
commander ;)

Typically inside google you can use such rules and later blame the end dev 
which did not followed it.

On the internet it is much less possible.

And yes hopefully, so far, only one ticket :)

But scale it by number of package providers * number of package users and 
you get a mess of repeated questions, 
no ?


On Friday, May 5, 2017 at 2:47:51 PM UTC+2, Jakob Borg wrote:
>
> On 5 May 2017, at 14:41, mhh...@gmail.com  wrote: 
> > 
> > Just to add on this that the fact i provide pre built bin is not winning 
> against go get, 
> > 
> > The repo i took as example is providing, 
> > https://github.com/mh-cbon/emd/releases 
> > 
> > and all possible ways to install it i can provide, 
> > https://github.com/mh-cbon/emd#install 
> > 
> > So yeah i did my best, i loosed. 
>
> You don't have *that* many issues opened. :) Here you are probably 
> targeting developers. They may be somewhat more likely to grab it from 
> source than others. They can probably also answer the question "what git 
> hash did you build from?" if that seems relevant. 
>
> On issues from other users I can usually get a feeling for whether the bug 
> is something I expect or something that should not be possible. If the 
> latter and the build seems suspect, "can you retry this with the latest 
> official build please?". 
>
> But yeah. The source is out there, you can't *prevent* people from 
> compiling it. (Other than not being go-gettable, which has advantages and 
> disadvantages.) 
>
> //jb

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

Re: [go-nuts] go get + build flag to set version var

[mhhcbon]

Just to add on this that the fact i provide pre built bin is not winning 
against go get,

The repo i took as example is providing,
https://github.com/mh-cbon/emd/releases

and all possible ways to install it i can provide,
https://github.com/mh-cbon/emd#install

So yeah i did my best, i loosed.

On Friday, May 5, 2017 at 2:38:34 PM UTC+2, mhh...@gmail.com wrote:
>
> I totally agree with you and implemented such build pipeline.
>
> But still, the fact is i have such situation, 
> I might run after each and every ticket like this,
> that does not seem a run i can win ;)
>
> On Friday, May 5, 2017 at 2:21:58 PM UTC+2, Jakob Borg wrote:
>>
>> For end users I strongly recommend distributing a binary. That gives you 
>> the ability to tag it properly and to know what goes into it - your code, 
>> your dependencies, and the compiler used. Typically this would happen by 
>> vendoring and using a Makefile or build script in the repo, running on some 
>> trusted CI platform. 
>>
>> If your end users really should build it themselves, I would have a build 
>> process that describes downloading the code, putting it in the correct 
>> place (...), and using your build script / Makefile. The resulting binary 
>> should know what it is (i.e., what hash it came from and how it was 
>> compiled) and be able to report that to you. 
>>
>> "go get" is a development tool. It does none of the things you need to 
>> happen in a "real" build for end users (imho, ymmv, etc). I would default 
>> your VERSION variable to something like "unsupported-dev" and treat the 
>> binaries correspondingly... "go get" is still perfectly fine for initially 
>> grabbing packages and developer tools where you don't particularly care 
>> what version they are. I sometimes use it as a shortcut for mkdir+git-clone 
>> for non-Go projects. :) 
>>
>> //jb 
>>
>> > On 5 May 2017, at 14:09, mhh...@gmail.com wrote: 
>> > 
>> > Hi, 
>> > 
>> > For a program i provide a pre build binary built with 
>> > 
>> >   go install --ldflags "-X main.VERSION=$VERSION" 
>> > 
>> > So when users met a problem they can report the version easily 
>> > and  certainty. 
>> > 
>> > the version variable is set by default to "0.0.0", could be empty 
>> string. 
>> > 
>> > What should be the cmd line to give the user so that they can go get, 
>> > and set the version to the git hash using the build flag ? 
>> > 
>> > From my computer i could do, 
>> > 
>> > go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or 
>> similar 
>> > 
>> > because i have the repo locally. 
>> > 
>> > But for an end user which did not clone it locally, 
>> > how could that happen in one cross platform command line ? 
>> > 
>> > Note that i might 
>> > - hardcode it into the README or godoc, but that require an additional 
>> control to generate the file containing the instructions, 
>> > - or manual update. 
>> > 
>> > First solution is available only for those who uses such tool, not 
>> everyone. 
>> > Second solution is prone to errors. 
>> > 
>> > 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...@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] go get + build flag to set version var

[mhhcbon]

I totally agree with you and implemented such build pipeline.

But still, the fact is i have such situation, 
I might run after each and every ticket like this,
that does not seem a run i can win ;)

On Friday, May 5, 2017 at 2:21:58 PM UTC+2, Jakob Borg wrote:
>
> For end users I strongly recommend distributing a binary. That gives you 
> the ability to tag it properly and to know what goes into it - your code, 
> your dependencies, and the compiler used. Typically this would happen by 
> vendoring and using a Makefile or build script in the repo, running on some 
> trusted CI platform. 
>
> If your end users really should build it themselves, I would have a build 
> process that describes downloading the code, putting it in the correct 
> place (...), and using your build script / Makefile. The resulting binary 
> should know what it is (i.e., what hash it came from and how it was 
> compiled) and be able to report that to you. 
>
> "go get" is a development tool. It does none of the things you need to 
> happen in a "real" build for end users (imho, ymmv, etc). I would default 
> your VERSION variable to something like "unsupported-dev" and treat the 
> binaries correspondingly... "go get" is still perfectly fine for initially 
> grabbing packages and developer tools where you don't particularly care 
> what version they are. I sometimes use it as a shortcut for mkdir+git-clone 
> for non-Go projects. :) 
>
> //jb 
>
> > On 5 May 2017, at 14:09, mhh...@gmail.com  wrote: 
> > 
> > Hi, 
> > 
> > For a program i provide a pre build binary built with 
> > 
> >   go install --ldflags "-X main.VERSION=$VERSION" 
> > 
> > So when users met a problem they can report the version easily 
> > and  certainty. 
> > 
> > the version variable is set by default to "0.0.0", could be empty 
> string. 
> > 
> > What should be the cmd line to give the user so that they can go get, 
> > and set the version to the git hash using the build flag ? 
> > 
> > From my computer i could do, 
> > 
> > go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or 
> similar 
> > 
> > because i have the repo locally. 
> > 
> > But for an end user which did not clone it locally, 
> > how could that happen in one cross platform command line ? 
> > 
> > Note that i might 
> > - hardcode it into the README or godoc, but that require an additional 
> control to generate the file containing the instructions, 
> > - or manual update. 
> > 
> > First solution is available only for those who uses such tool, not 
> everyone. 
> > Second solution is prone to errors. 
> > 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

[go-nuts] go get + build flag to set version var

[mhhcbon]

Hi,

For a program i provide a pre build binary built with

  go install --ldflags "-X main.VERSION=$VERSION"

So when users met a problem they can report the version easily
and  certainty.

the version variable is set by default to "0.0.0", could be empty string.

What should be the cmd line to give the user so that they can go get,
and set the version to the git hash using the build flag ?

>From my computer i could do,

go install --ldflags "-X main.VERSION=`git log | head -n 1`" // or similar

because i have the repo locally.

But for an end user which did not clone it locally, 
how could that happen in one cross platform command line ?

Note that i might 
- hardcode it into the README or godoc, but that require an additional 
control to generate the file containing the instructions,
- or manual update.

First solution is available only for those who uses such tool, not everyone.
Second solution is prone to errors.

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.

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

[mhhcbon]

hi,

happy it helped!

On Thursday, May 4, 2017 at 10:13:42 AM UTC+2, Ben Davies wrote:
>
> Interesting stuff! Thanks for the pointer on 
> https://github.com/mh-cbon/mutexer 
> ,
>  
> missed that! I have noticed that the https://github.com/mh-cbon/mutexer 
> 
>  version 
> doesnt implement all the methods the lister does (such as map, filter).
>
> Yes, the demo code is a bit outdated, moving quickly on it. 
It will update (automatically) on next release.

The mutexer / channeler unlike the lister /plumber are made to dig the 
input type and reproduce its methods.
So that should work fine, unless you get caught by uncovered cases, and 
there are some definitely (likely gonna have pb if you have a channel 
params, as an example).
Hope you ll issue/pr that if you stubble on it, they really are small 
problems to cover.

 

> I was thinking of doing something similar myself for iterator types e.g. 
> Next(), Rewind() etc.
>
>
Sure yes. 
Im not a purist of the computer science, 
I just did what worked and needed for me.

What s cool with that generator idea, 
is that if you make a generator based on the work i presented,
anybody can re use it and combine its types in a glance!

I really love it, 
there no performance penalties related to reflection,
its way easier to understand than generics, 
and covers much more than this last thing.
(imho generic are a subset of generators, 
stucked into a complex paradigm of type to handle, 
but its another topic)

Though, this is all quiet new for me, so there are situations 
and difficulties to uncover (like what would be the right way to magically 
log?)
 

> Might have a play with a fork of Lister and see if I can get a version 
> working.
>
>
would be cool :)
 

> Incidentally, out of curiosity, I noticed that the output code is "hard 
> coded" into the main.go; would it not be clearer/more maintainable to use 
> templates?
>
>
Yes, if one can define an API to deal with the AST and the types.

It s not a simple topic at all, in fact i already tried this approach but, 
at that moment, 
i abandoned because its too complex and heavy for myself, 
and i was inventing new language, 
which i want not.

See this example, https://github.com/mh-cbon/gigo/blob/master/demo.gigo.go
which aims to generate a typed slice with its mutex facade.
Its +/- ok, 

but that other example that should reproduce the chan facade,
starts to get slightly more complex (error prone) for templating
https://github.com/mh-cbon/gigo/blob/master/chanmux.gigo.go


Just so you know my next steps are 
- a generator for the RPC-JSON client, the inverse of jsoner.
- a begin of database handling on top of what i presented so far

 

> On Wednesday, May 3, 2017 at 4:37:42 PM UTC+1, mhh...@gmail.com wrote:
>>
>> hi
>>
>> > Can anyone else recommend any other generators that produce 
>> lists/iterators like this?
>>
>> good Q.
>>
>> > Is the resulting generated code safe to use from multiple go routines?
>>
>> The slice itself nop, because, for that you want to use 
>>
>> https://github.com/mh-cbon/channeler
>> or
>> https://github.com/mh-cbon/mutexer
>>
>> You make a typed slice then you facade it with one of the syncer.
>>
>> So yep, that example is not TS,
>> this was just for fun and demo
>>
>> backend := NewTomates() // This is not TS, it d need an additional 
>> layer
>> backend.Push(Tomate{Name: "red"})
>> jsoner := NewJSONTomates(backend)
>> httper := NewHTTPTomates(jsoner)
>>
>> // public views
>> http.HandleFunc("/", httper.At)
>>
>> /*
>> curl -H "Accept: application/json" -H "Content-type: 
>> application/json" -X POST -d ' {"i":0}'  http://localhost:8080/
>> */
>>
>> log.Fatal(http.ListenAndServe(":8080", nil))
>>
>>
>> In the same manner if you have n collections in memory which needs TS,
>> that d be inappropriate to have n TS lists communicating with each other 
>> on the main routine,
>> that d create additional contentions,
>> you d better create a controller, that is totally TS, 
>> that access those slice without syncing.
>>
>>
>> On Wednesday, May 3, 2017 at 4:30:20 PM UTC+2, Ben Davies wrote:
>>>
>>> Is the resulting generated code safe to use from multiple go routines?
>>>
>>> On Saturday, April 29, 2017 at 4:06:27 PM UTC+1, mhh...@gmail.com wrote:

 Hi,

 several generators i made to avoid some duplication.

 https://github.com/mh-cbon/lister

 Package lister is a generator to generate typed slice.


 https://github.com/mh-cbon/channeler

 Package channeler is a cli generator to generate channeled version of a 
 type.

 https://github.com/mh-cbon/mutexer

 Package mutexer is a cli generator to generate mutexed version of a 
 type.


 

[go-nuts] Re: [ANN] the busy man: init repo quickly

[mhhcbon]

hi,

I HEARD YOU : )

It is installing the software for you JIT, 
see https://github.com/mh-cbon/the-busy-man/blob/master/emd/tbm.go#L36 ;)

And yes, unfortunately, it does not *yet* complete the whole setup like
https://github.com/mh-cbon/go-github-release

And yes it uses HEAD everywhere, 
its not so great, waiting for dep to jump in to take decision.

In regards to apt/dnf lately i got caught by them pretty often lately,
because, either i did not understand, either they are too weak,
so i want to see dep in action to decide.

Lastly, this tool is quiet specific to developers, 
so far given its visibility mostly gophers, 
so go get seems reasonable to me.

But yes i agree with you, just not enough arms and brains 
Maybe someday we ll be able to type in like
 in the animé ghost in the shell (btw the movie is awesome)
https://www.youtube.com/watch?v=KlJ8eTuFe9U


On Wednesday, May 3, 2017 at 6:23:48 PM UTC+2, Tong Sun wrote:
>
> Hi, 
>
> That'd be very useful, but only under one condition IMO, is that people 
> can do 
>
> apt get install the-busy-man
>
> and get all the dependent tools of the-busy-man installed *automatically*. 
> Otherwise, if people have to figure out the dependencies *themselves*, 
> and install them *one by one* themselves, I'd see only few people willing 
> to do that, i.e., terrible adaption rate. 
>
>
> On Wednesday, May 3, 2017 at 6:52:32 AM UTC-4, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> made that because i was super lazy...
>>
>> https://github.com/mh-cbon/the-busy-man
>>
>> So now i can do,
>>
>> 1/ add an alias of my preferred repo init,
>>
>> $ cat <> ~/.bashrcalias tbm="the-busy-man git:init license:mit 
>> emd:mh-cbon/emd golang gump:mh-cbon/gump git:commit changelog 
>> git:commit+amend"EOTsource ~/.bashrc
>>
>> 2/ run `tbm` into a directory to get a package ready to code
>>
>> For plugins such a `license`, `emd` ect,
>> they rely on external go bin, 
>> so the program will install them via go get,
>> BUT, take care its HEAD everywhere (not so great.)
>>
>> its not a bultin pipe of init 
>> because everyone is doing something
>> a bit different of his neighbor
>> so i suggest you pr  plugins for your needs.
>>
>> A basic miss is the Makefile, because i m not Makefile user,
>> the idea would be to add a new plugin named `make`
>> and let it receive an intent such `cznic/sqlite`
>> and the program would init the makefile using the file existing in the repo
>> https://github.com/cznic/sqlite/blob/master/Makefile
>>
>> Its basically what i shown in my alias with plugins like emd/gump.
>>
>> hth
>>
>>

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

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

[mhhcbon]

hi

> Can anyone else recommend any other generators that produce 
lists/iterators like this?

good Q.

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

The slice itself nop, because, for that you want to use 

https://github.com/mh-cbon/channeler
or
https://github.com/mh-cbon/mutexer

You make a typed slice then you facade it with one of the syncer.

So yep, that example is not TS,
this was just for fun and demo

backend := NewTomates() // This is not TS, it d need an additional layer
backend.Push(Tomate{Name: "red"})
jsoner := NewJSONTomates(backend)
httper := NewHTTPTomates(jsoner)

// public views
http.HandleFunc("/", httper.At)

/*
curl -H "Accept: application/json" -H "Content-type: 
application/json" -X POST -d ' {"i":0}'  http://localhost:8080/
*/

log.Fatal(http.ListenAndServe(":8080", nil))


In the same manner if you have n collections in memory which needs TS,
that d be inappropriate to have n TS lists communicating with each other on 
the main routine,
that d create additional contentions,
you d better create a controller, that is totally TS, 
that access those slice without syncing.


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

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

[go-nuts] Re: bug or not?

[mhhcbon]

similarly, it is possible to rewrite len, or a package id. 

I got caught some times about that, 
since then i take care about that.

but yeah, feels weird.

btw, what means RHS / LHS in ast package and in the comment by cznic ?
many times i read it and wonder..

On Wednesday, May 3, 2017 at 2:32:47 PM UTC+2, T L wrote:
>
> https://github.com/golang/go/issues/20219
>
>
>

-- 
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: iota with gaps

[mhhcbon]

indeed, totally misleading for me,

https://play.golang.org/p/pMbeLffTnS

On Wednesday, May 3, 2017 at 1:05:35 PM UTC+2, rog wrote:
>
> On 3 May 2017 at 09:36, Egon  wrote: 
> > On Wednesday, 3 May 2017 07:34:16 UTC+3, Tong Sun wrote: 
> >> 
> >> Hi, 
> >> 
> >> How to use `iota` to define consts that have gap(s) in them? 
> >> 
> >> E.g., If my consts are, 
> >> 
> >> 1, 2, 3, 7, 8, 9 
> >> 
> >> How to use iota to define them? Thx. 
> > 
> > 
> > You don't have to use iota. If these are predefined constants, such as a 
> > protocol -- it's usually better to assign them explicitly rather than to 
> use 
> > iota. 
> > 
> > There are also: 
> > 
> > // use skip 
> > const ( 
> > A = iota 
> > B 
> > C 
> > D = iota + 3 // for skip 3 
>
> I think this is slightly misleading - this idiom doesn't 
> skip three - it adds 3 to the current value of iota. 
>
> For example, given 
>
>const ( 
>A = iota 
>B 
>C 
>D = iota + 10 
>E 
>F = iota + 2 
>G 
>) 
>
> G will be 8, not 18. 
>

-- 
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] [ANN] the busy man: init repo quickly

[mhhcbon]

Hi,

made that because i was super lazy...

https://github.com/mh-cbon/the-busy-man

So now i can do,

1/ add an alias of my preferred repo init,

$ cat <> ~/.bashrcalias tbm="the-busy-man git:init license:mit 
emd:mh-cbon/emd golang gump:mh-cbon/gump git:commit changelog 
git:commit+amend"EOTsource ~/.bashrc

2/ run `tbm` into a directory to get a package ready to code

For plugins such a `license`, `emd` ect,
they rely on external go bin, 
so the program will install them via go get,
BUT, take care its HEAD everywhere (not so great.)

its not a bultin pipe of init 
because everyone is doing something
a bit different of his neighbor
so i suggest you pr  plugins for your needs.

A basic miss is the Makefile, because i m not Makefile user,
the idea would be to add a new plugin named `make`
and let it receive an intent such `cznic/sqlite`
and the program would init the makefile using the file existing in the repo
https://github.com/cznic/sqlite/blob/master/Makefile

Its basically what i shown in my alias with plugins like emd/gump.

hth

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

[go-nuts] Re: Fully-qualified import paths and Pull Requests

[mhhcbon]

Thanks!

Alright, i need to test that, im not used to HG, bzr. Kind of forgotten 
about svn (:/)


meanwhile,

https://github.com/mh-cbon/fork

On Wednesday, May 3, 2017 at 12:19:07 PM UTC+2, Dave Cheney wrote:
>
> You can simulate this with most source control systems by manually 
> checking out your fork in the original location.
>
> Say
>
> hg clone https://bitbucket.org/davecheney/pkg $GOPATH/src/
> bitbucket.org/project/pkg
>
>

-- 
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: Fully-qualified import paths and Pull Requests

[mhhcbon]

Do you have any idea how that d work with other vcs ?



On Wednesday, May 3, 2017 at 8:55:41 AM UTC+2, Nathan Kerr wrote:
>
> http://blog.sgmansfield.com/2016/06/working-with-forks-in-go/ gives some 
> good pointers on how to do 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.

[go-nuts] Re: Testing reflect.type for equality with another type

[mhhcbon]

yes, you can use Name / PgkPath methods to test equality.

https://golang.org/pkg/reflect/#Type

Those methods might be useful too,

// Implements reports whether the type implements the interface type u.
Implements(u Type ) bool 


// AssignableTo reports whether a value of the type is assignable to 
type u.
AssignableTo(u Type ) bool 


// ConvertibleTo reports whether a value of the type is convertible to 
type u.
ConvertibleTo(u Type ) bool 


And the doc says,


// String returns a string representation of the type.
// The string representation may use shortened package names
// (e.g., base64 instead of "encoding/base64") and is not
// guaranteed to be unique among types. To test for type identity,
// compare the Types directly.
String() string 


>compare the Types directly.

I understand it means you need to iterate field and methods to test more.


On Tuesday, May 2, 2017 at 4:47:37 AM UTC+2, nz wrote:
>
> Hi
>
> As far as I can tell two reflect.Type's should be equal, but they fail 
> equality (==) test, printing the reflect.Type using "%#v" of the types 
> yields identical values
>
> {size:0x8, ptrdata:0x8, hash:0xdd3884e8, tflag:0x1, 
> align:0x8, fieldAlign:0x8, kind:0x36, alg:(*reflect.typeAlg)(0x136b930), 
> gcdata:(*uint8)(0xd60948), str:145804, ptrToThis:0}
> {size:0x8, ptrdata:0x8, hash:0xdd3884e8, tflag:0x1, 
> align:0x8, fieldAlign:0x8, kind:0x36, alg:(*reflect.typeAlg)(0x136b930), 
> gcdata:(*uint8)(0xd60948), str:145804, ptrToThis:0}
>
> When I invoke them they appear to create the same instance (printing using 
> "%#v") -
> (**my.TestObject)(0xc420196140)
> (**my.TestObject)(0xc420196148)
>
> Yet equality between types fails ... Is there something else that I can 
> test for ?
>
> thanks
> Nz
>
>

-- 
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: Feedback welcome: "Shorten your URL"

[mhhcbon]

hi,

some more sharings,

like val said, https://github.com/lutzhorn/shorturl/blob/master/main.go#L42 
is not optimum,

get ride of the anonymous func is obvious.
Note: that would have been useful in a loop iteration that spawns go 
routine.

To go beyond, I think you can do, signatures seems to match from here.

http.HandleFunc("/index.html", handler.Index)

when index is invoked, it will keep its receiver.


To serve static files,
you can use one of the many pre defined go http handlers,

  fs := http.FileServer(http.Dir("static"))
  http.Handle("/", fs)


found this article, among many others, 
http://www.alexedwards.net/blog/serving-static-sites-with-go


Based on that i suspect some changes will happen into handler.Root.

I suspect this code here
https://github.com/lutzhorn/shorturl/blob/master/db.go#L34
might be optimized to avoid cpu consumption.

If you d flood that url, that would trigger as many heavy computations as 
req,
so all reqs will be impacted by the slow cpu, 
including those not doing this computation (and that is where is the pb).

You might put that computation into a limited worker pool
to slow down only that url and not impact all the server.

But, maybe this hashing is very fast, i don t know about that.


https://github.com/lutzhorn/shorturl/blob/master/db.go#L63
this is tricky to make better in place, but it smells useless complexity.

https://github.com/lutzhorn/shorturl/blob/master/db.go#L74
you might try something like this to avoid repeating the rollback on error,
https://play.golang.org/p/DC2S1nVD8U

I also invite you to also check packages like dbr or gorm to handle the DB.



On Tuesday, May 2, 2017 at 9:32:45 AM UTC+2, Lutz Horn wrote:
>
> Hi Go Nuts, 
>
> to practice my Go skills, I've implemented a simple web application that 
> allows you to shorten an URL. The application consists of a backend 
> written in Go and a web frontend using jQuery with some plugins and 
> Bootstrap for layout. 
>
> The code is available on GitHub at https://github.com/lutzhorn/shorturl, 
> the application is deployed on https://u.lhorn.de. 
>
> I would very much appreciate any feedback you can give especially on the 
> Go part. Coming from a Java and Python background, I'm trying to get 
> into the Go way of programming, In Python there is a 'Pythonic' way to 
> write code, I am sure there is something similar in Go: File structure, 
> name choice, exporting names, error handling, ... 
>
> If you have a little time, please tak a look at the code, play with the 
> deployed application, and please give me feedback. 
>
> Thanks! 
>
> Lutz 
>
>
>

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

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

[mhhcbon]

Hi,


Some more about that.

I added tow new generators jsoner / httper.

jsoner takes a type in input, 
parses method args from a json body req, 
output func params to a json body response.
JSON-RPC.

httper, takes an http req in input,
interprets it as a json-rpc request,
pass it to the underlying RPC decoder (jsoner?)
and handle the response.

Still work to be done,
but looks at this main to get a json api,

package main

import (
"log"
"net/http"
)

// Tomate is about red vegetables to make famous italian food.
type Tomate struct {
Name string
}

// GetID return the ID of the Tomate.
func (t Tomate) GetID() string {
return t.Name
}

//go:generate lister vegetables_gen.go Tomate:Tomates
//go:generate jsoner json_vegetables_gen.go *Tomates:JSONTomates
//go:generate httper http_vegetables_gen.go *JSONTomates:HTTPTomates

func main() {

backend := NewTomates()
backend.Push(Tomate{Name: "red"})
jsoner := NewJSONTomates(backend)
httper := NewHTTPTomates(jsoner)

// public views
http.HandleFunc("/", httper.At)

/*
curl -H "Accept: application/json" -H "Content-type: 
application/json" -X POST -d ' {"i":0}'  http://localhost:8080/
*/

log.Fatal(http.ListenAndServe(":8080", nil))
}


Last note: can generics handle that ? (I dont think so)

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

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

[go-nuts] Re: All the Go project history, live in RAM

[mhhcbon]

looks awesome!

On Sunday, April 30, 2017 at 11:42:03 PM UTC+2, bradfitz wrote:
>
> Gophers,
>
> Want to analyze the Go project's Git, GitHub, and Gerrit history?
>
> Here a package to make it easy:
>
>  https://godoc.org/golang.org/x/build/maintner/godata
>
> See the example:
>
> 
> https://godoc.org/golang.org/x/build/maintner/godata#example-Get--NumComments
>
> If you run that, it'll download 350 MB (once) and then tell you there have 
> been 111228 GitHub comments on Go repos.
>
> Run it again a few seconds later and the number might increase.
>
> The data is generally under 1 second behind reality, thanks to the 
> webhook+incoming-SMTP server we run now at 
> https://pubsubhelper.golang.org/ to get updates from GitHub & Gerrit.
>
> gopherbot now uses this infrastructure. See 
> https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go 
> for some more examples.
>
> Thanks to Kevin Burke for all the help & code reviews.
>
> - Brad
>
>

-- 
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:generate won t work, //go:generate will

[mhhcbon]

Hi,

its reasonable, but not satisfying, 
at least because lint/vet are not mandatory to build.

A satisfying solution, imho, involves a more in depth change,
which won t happen for reasons cited previously.

Thanks.

On Sunday, April 30, 2017 at 2:55:12 PM UTC+2, Caleb Doxsey wrote:
>
> Hi,
>
> Just a reminder that Go is an open source project. Although changing 
> go:generate probably isn't going to happen, your comment about lint not 
> catching the issue seemed reasonable to me. So I went ahead and implemented 
> it and created a pull request:
>
> https://github.com/golang/lint/pull/291
>
> - Caleb
>
> On Saturday, April 29, 2017 at 7:33:20 AM UTC-4, mhh...@gmail.com wrote:
>>
>> Hi,
>>
>> just a note about the //go:gen comment.
>>
>> If there is a space in front of go:gen, it won t work, this,
>> // go:gen...
>>
>> I did not check, but i bet 100 boxes there s already a rule about that. 
>> Clear crystal.
>>
>> Still, there is no warning about that in vet/lint,
>> so for a beginner,
>> assuming he got them installed, and he is using both of them,
>> he will still fail and stubble in front of this situation.
>>
>> If he is not using any of them, well... dead end.
>>
>> And even for someone who did that in the past,
>> me?,
>> it is highly frustrating (back to un-typed/weak languages problem... 
>> there s a mistake, where the  is 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.