Re: [go-nuts] Re: Algorithm Club

[Egon]

On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote:
>
> Egon:
>
> >See 
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
>
> I don't see the Implicit Boxing section point out that this is what 
> happens now when you shoehorn everything into interface{}.
>

Because it can also be implemented in other ways.
 

> In this sense, I don't see a performance downside for boxing generics 
> compared to the current state of things.
>

As said... there is a performance upside for some other approaches.


> >You can also use copy-paste, code-generation.
>
> I was referring to the downsides of copy/paste here: "You could have the 
> same opt-in performance tax in the form of bloated binaries/slow builds as 
> well, but lack of an official debugger right now is predicated on builds 
> being fast, so that seems like a no-go."
>

The builds being fast are necessary for many things, mainly iterating on 
features, tests.
 

>
> >It would be slower than copy-paste and generated approaches.
>
> It wouldn't be slower than interface{}, right?
>

Yes.
 

>
> >When generics are added, then they will be (almost) impossible to avoid. 
> So the opt-in "slow builds" isn't really opt-in unless you really try...
>
> By opt-in, I meant the code we write ourselves. In shared code, it would 
> be no more impossible to avoid generics than interface{} is now, which 
> doesn't seem to have been a problem. If there's a case where the 
> performance is too slow, one could always copy/paste the code and remove 
> the generics from it.
>

Copy-paste wouldn't remove generics used in the standard-library... i.e. 
it's hard to avoid the compile-time overhead. I agree, it's possible, but 
unlikely that anyone will do it.
 

>
> On Tue, Mar 28, 2017 at 12:28 AM, Egon  
> wrote:
>
>> On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote:
>>>
>>> Something I've never seen addressed in the generics tradeoffs debate 
>>> (not saying it hasn't been, but I haven't see it personally)
>>>
>>
>> See 
>> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
>>
>> is that without generics, you're forced to use interface{}
>>>
>>
>> You can also use copy-paste, code-generation.
>>  
>>
>>> which just boxes the values anyway. So you're already paying a 
>>> performance cost for type-agnostic code without generics. And if you 
>>> copy/paste code instead of boxing, you're just bloating the size of the 
>>> binary like generic templates would. It seems to me if boxing generics was 
>>> added, there wouldn't be a downside:
>>>
>>
>> It would be slower than copy-paste and generated approaches.
>>  
>>
>>> if you didn't want to pay the performance cost of boxing generics, then 
>>> don't use generics; if you can pay the cost, then use them, and it won't 
>>> perform any worse than it would now with interface{}, and perhaps could 
>>> perform even better, depending on the semantics and implementation. You 
>>> could have the same opt-in performance tax in the form of bloated 
>>> binaries/slow builds as well,
>>>
>>
>> When generics are added, then they will be (almost) impossible to avoid. 
>> So the opt-in "slow builds" isn't really opt-in unless you really try...
>>  
>>
>>> but lack of an official debugger right now is predicated on builds being 
>>> fast, so that seems like a no-go.
>>>
>>> On Friday, March 24, 2017 at 12:10:08 PM UTC-7, Mandolyte wrote:

 The recent survey reveled that generics was thing that would improve Go 
 the most. But at 16%, the responses were rather spread out and only 1/3 
 seemed to think that Go needed any improvement at all - see link #1. I 
 think most will concede that generics would help development of 
 algorithms, 
 libraries, and frameworks. So in the spirit of friendly rivalry, here is a 
 list of algorithms developed for Swift:

 https://github.com/raywenderlich/swift-algorithm-club

 As you might guess, it is chock-full of generics. Yeah, I'm a little 
 envious. :-) enjoy...



 #1 https://blog.golang.org/survey2016-results

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/VbWfF865C3s/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] how to debug in gomobile? & can gomobile support mac or linux sometime

[hui zhang]

As too me gomobile now are more like a game engine (for ui is gl) , like 
cocos2dx.
but unlike cocos2dx, it only support mobile, and did not offer a way to 
debug in wiki.

how to debug,   if it could not be debug in mobile.
at least let it support mac or linux so , so  we are easy to debug

-- 
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] New Smallcaps Go Fonts; other Go Fonts updated

[Nigel Tao]

Bigelow & Holmes have prepared new versions of the Go Fonts that we
released late last year (https://blog.golang.org/go-fonts). The
version numbers have changed from 2.004 to 2.008. ChangeLog:

* New! 2 new fonts, bringing the total to 12: Go Smallcaps and Go
Smallcaps Italic.
* New! U+FFFD REPLACEMENT CHARACTER glyph added.
* U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE ring tweaked.
* U+00F0 LATIN SMALL LETTER ETH glyph lightened.
* Superfluous U+0005  glyph removed.
* Split integral, chart draw, block, shade and related glyphs now span
the full height and have fewer seams when tiled.
* Raised most capital letter diacritics and some lowercase diacritics.
* Mono character widths fixed to be uniform.
* Underline position adjusted.
* SFNT glyph order and cmap table optimized.
* SFNT glyph names (post table) regularized, consistent with the AGLFN.
* ttfautohint upgraded to the latest version, from 1.5 to 1.6.

The golang.org/x/image git repository has been updated with commit
f03a0464 (CL 38870). The TTF files still live in the font/gofont/ttfs
directory under 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.

Re: [go-nuts] Re: Algorithm Club

[Will Faught]

Egon:

>See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-
HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9

I don't see the Implicit Boxing section point out that this is what happens
now when you shoehorn everything into interface{}. In this sense, I don't
see a performance downside for boxing generics compared to the current
state of things.

>You can also use copy-paste, code-generation.

I was referring to the downsides of copy/paste here: "You could have the
same opt-in performance tax in the form of bloated binaries/slow builds as
well, but lack of an official debugger right now is predicated on builds
being fast, so that seems like a no-go."

>It would be slower than copy-paste and generated approaches.

It wouldn't be slower than interface{}, right?

>When generics are added, then they will be (almost) impossible to avoid.
So the opt-in "slow builds" isn't really opt-in unless you really try...

By opt-in, I meant the code we write ourselves. In shared code, it would be
no more impossible to avoid generics than interface{} is now, which doesn't
seem to have been a problem. If there's a case where the performance is too
slow, one could always copy/paste the code and remove the generics from it.

On Tue, Mar 28, 2017 at 12:28 AM, Egon  wrote:

> On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote:
>>
>> Something I've never seen addressed in the generics tradeoffs debate (not
>> saying it hasn't been, but I haven't see it personally)
>>
>
> See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-
> HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
>
> is that without generics, you're forced to use interface{}
>>
>
> You can also use copy-paste, code-generation.
>
>
>> which just boxes the values anyway. So you're already paying a
>> performance cost for type-agnostic code without generics. And if you
>> copy/paste code instead of boxing, you're just bloating the size of the
>> binary like generic templates would. It seems to me if boxing generics was
>> added, there wouldn't be a downside:
>>
>
> It would be slower than copy-paste and generated approaches.
>
>
>> if you didn't want to pay the performance cost of boxing generics, then
>> don't use generics; if you can pay the cost, then use them, and it won't
>> perform any worse than it would now with interface{}, and perhaps could
>> perform even better, depending on the semantics and implementation. You
>> could have the same opt-in performance tax in the form of bloated
>> binaries/slow builds as well,
>>
>
> When generics are added, then they will be (almost) impossible to avoid.
> So the opt-in "slow builds" isn't really opt-in unless you really try...
>
>
>> but lack of an official debugger right now is predicated on builds being
>> fast, so that seems like a no-go.
>>
>> On Friday, March 24, 2017 at 12:10:08 PM UTC-7, Mandolyte wrote:
>>>
>>> The recent survey reveled that generics was thing that would improve Go
>>> the most. But at 16%, the responses were rather spread out and only 1/3
>>> seemed to think that Go needed any improvement at all - see link #1. I
>>> think most will concede that generics would help development of algorithms,
>>> libraries, and frameworks. So in the spirit of friendly rivalry, here is a
>>> list of algorithms developed for Swift:
>>>
>>> https://github.com/raywenderlich/swift-algorithm-club
>>>
>>> As you might guess, it is chock-full of generics. Yeah, I'm a little
>>> envious. :-) enjoy...
>>>
>>>
>>>
>>> #1 https://blog.golang.org/survey2016-results
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/VbWfF865C3s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: directory name versus package name

[Dorival Pedroso]

I like the idea that the go tool would enforce matching directory and 
package names.

This would help us in case we forget to be consistent...

On Wednesday, March 29, 2017 at 5:18:52 PM UTC+10, Dorival Pedroso wrote:
>
> Hello,
>
> I haven't noticed that the code below (located at *$GOPATH/src/MyWrapper*
> ):
>
> package mylib
>
> import "fmt"
>
> func SayHello() {
> fmt.Println("hello")
> }
>
> is actually being installed (go install) as a *MyWrapper* package, even 
> though the package name was explicitly given as *mylib*.
>
> I couldn't find in the documentation where the handling of this situation 
> is described; i.e. how the final package name is decided (apparently the 
> directory name is chosen).
>
> Anyway, so, why using *package mylib* then?
>
> Cheers.
> Dorival
>
>
>

-- 
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] time: error prone implementation of Time.Format

[Ian Lance Taylor]

On Wed, Mar 29, 2017 at 2:29 PM, Manlio Perillo
 wrote:
> Il giorno mercoledì 29 marzo 2017 23:18:09 UTC+2, Ian Lance Taylor ha
> scritto:
>>
>> On Wed, Mar 29, 2017 at 2:03 PM, Manlio Perillo
>>  wrote:
>> > In a program I have a function that formats the time in Italian date
>> > format:
>> > dd/mm/, but, due to an oversight, I wrote the layout string as
>> > "02/02/2006", instead of "02/01/2006".
>> > This caused all the dates to be incorrectly formatted.
>> >
>> > IMHO, this is a nasty behavior.  The layout is clearly incorrect and the
>> > implementation should report an error, instead of returning an
>> > incorrectly
>> > formatted time.
>>
>> I think it would be difficult to define "clearly incorrect" in a way
>> that does not introduce any false negatives while remaining useful.
>
>
> In my case I specified stdZeroDay twice.
>
> The AppendFormat function can define some additional boolean variables:
> hasYear, hasMonth, hasDay, ...
> and return an error if a variable is set to true more than one time.

But it's not clearly incorrect to write

"2006-01-02 or Jan 02, 2006"

Ian

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

Re: [go-nuts] time: error prone implementation of Time.Format

[Manlio Perillo]

Il giorno mercoledì 29 marzo 2017 23:18:09 UTC+2, Ian Lance Taylor ha 
scritto:
>
> On Wed, Mar 29, 2017 at 2:03 PM, Manlio Perillo 
>  wrote: 
> > In a program I have a function that formats the time in Italian date 
> format: 
> > dd/mm/, but, due to an oversight, I wrote the layout string as 
> > "02/02/2006", instead of "02/01/2006". 
> > This caused all the dates to be incorrectly formatted. 
> > 
> > IMHO, this is a nasty behavior.  The layout is clearly incorrect and the 
> > implementation should report an error, instead of returning an 
> incorrectly 
> > formatted time. 
>
> I think it would be difficult to define "clearly incorrect" in a way 
> that does not introduce any false negatives while remaining useful. 
>

In my case I specified stdZeroDay twice.

The AppendFormat function can define some additional boolean variables:
hasYear, hasMonth, hasDay, ...
and return an error if a variable is set to true more than one time.


Manlio 

-- 
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] time: error prone implementation of Time.Format

[Ian Lance Taylor]

On Wed, Mar 29, 2017 at 2:03 PM, Manlio Perillo
 wrote:
> In a program I have a function that formats the time in Italian date format:
> dd/mm/, but, due to an oversight, I wrote the layout string as
> "02/02/2006", instead of "02/01/2006".
> This caused all the dates to be incorrectly formatted.
>
> IMHO, this is a nasty behavior.  The layout is clearly incorrect and the
> implementation should report an error, instead of returning an incorrectly
> formatted time.

I think it would be difficult to define "clearly incorrect" in a way
that does not introduce any false negatives while remaining useful.

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] time: error prone implementation of Time.Format

[Manlio Perillo]

In a program I have a function that formats the time in Italian date 
format: dd/mm/, but, due to an oversight, I wrote the layout string as 
"02/02/2006", instead of "02/01/2006".
This caused all the dates to be incorrectly formatted.

IMHO, this is a nasty behavior.  The layout is clearly incorrect and the 
implementation should report an error, instead of returning an incorrectly 
formatted time.


Thanks
Manlio

-- 
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] [POC] gigo: go generate on steroids!

[mhhcbon]

Hi !

I m very happy to share with you gigo

Its a go generate on steroids, Its more close to something like babel than 
go generate, see,

in input it takes


type Todo struct {
  Name string
  Done bool
}

type Todos implements {
  // it reads as a mutexed list of todo.
}

func (t *Todos) Hello(){fmt.Println("Hello")}


template Mutexed<.Name> struct {
  lock *sync.Mutex
  embed <.Name>
}

 func (m Mutexed<$.Name>) <$m.Name>(<$m.Params>) <$m.
Out> {
  lock.Lock()
  defer lock.Unlock()
  m.embed.<$m.GetName>(<$m.Args>)
}

template <.Name>Slice struct {
  items []<.Name>
}

func (s <.Name>Slice) Push(item <.Name>) int {
  s.items = append(s.items, item)
  return len(s.items)
}

func (s <.Name>Slice) Index(item <.Name>) int {
  for i, items := range s.items {
if item == search {
  return i
}
  }
  return -1
}

func (s <.Name>Slice) RemoveAt(i index) int {
s.items = append(s.items[:i], s.items[i+1:]...)
}

func (s <.Name>Slice) Remove(item <.Name>) int {
  if i:= s.Index(item); i > -1 {
s.RemoveAt(i)
return i
  }
  return -1
}



It produces




type Todo struct {
  Name string
  Done bool
}


type TodoSlice struct {
  items []Todo
}


func (s TodoSlice) Push(item Todo) int {
  s.items = append(s.items, item)
  return len(s.items)
}


func (s TodoSlice) Index(item Todo) int {
  for i, items := range s.items {
if item == search {
  return i
}
  }
  return -1
}


func (s TodoSlice) RemoveAt(i index) int {
s.items = append(s.items[:i], s.items[i+1:]...)
}


func (s TodoSlice) Remove(item Todo) int {
  if i:= s.Index(item); i > -1 {
s.RemoveAt(i)
return i
  }
  return -1
}
// while this is compatible with its local contracts,
// it will work and still takes advantages of concrete types exported by 
consumed package.

type MutexedTodoSlice struct {
  lock *sync.Mutex
  embed TodoSlice
}


 func (m MutexedTodoSlice)  Push((item Todo))  int {
  lock.Lock()
  defer lock.Unlock()
  m.embed.<$m.GetName>(<$m.Args>)
}
 func (m MutexedTodoSlice)  Index((item Todo))  int {
  lock.Lock()
  defer lock.Unlock()
  m.embed.<$m.GetName>(<$m.Args>)
}
 func (m MutexedTodoSlice)  RemoveAt((i index))  int {
  lock.Lock()
  defer lock.Unlock()
  m.embed.<$m.GetName>(<$m.Args>)
}
 func (m MutexedTodoSlice)  Remove((item Todo))  int {
  lock.Lock()
  defer lock.Unlock()
  m.embed.<$m.GetName>(<$m.Args>)
}


type Todos struct {
MutexedTodoSlice
  // it reads as a mutexed list of todo.
}

func (t *Todos) Hello(){fmt.Println("Hello")}

Still some work to be done, but you got the idea!



It implements a whole tokenizer/interpreter  of go code (almost), 

a bit like go/ast, but its way more lighter(so far), 

the idea being to be able add more customization based on that.


The package currently tokenize a source code,

interprets it into declarations,

manipulates nodes to use a regular go template.Template

to execute the generation,

finally it builds a go file and output its.


It adds new syntaxes such as


implements, which produces a struct

type Todos implements 


template, to define virutal structs type

template Mutexed<.Name> struct


Then the systems understands instructions blocks 

such as "regular" method declaration to template
func (s <.Name>Slice) Push(item <.Name>) int {
  s.items = append(s.items, item)
  return len(s.items)
}


And pure template expressions,

(although, at that moment, its a limited to methods only)
 func (m Mutexed<$.Name>) <$m.Name>(<$m.Params>) 
<$m.Out> {
  lock.Lock()
  defer lock.Unlock()
  m.embed.<$m.GetName>(<$m.Args>)
}


I plan to be able to declare func to inject into template instructions,

so you ll be able to do pretty much anything i think.


I m not sure the new syntaxes are correct, 

but i d that this project is the starting point of an effort to 

improve go coding experience.

In that goal, any comments are welcome!


Last thing, at that very moment the package is extremly new,

don t expect too much, 

it did work with the demo file 
https://github.com/mh-cbon/gigo/blob/master/demo.gigo.go ;)


~~ Happy coding !

-- 
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 build from windows 32bits to linux

[anthony soto]

>
>
> 
>
>
> 
>
> set goos=linux
>
set goarch=386
set CGO_ENABLED=1
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.

Re: [go-nuts] Syscalls inside loops + runtime.KeepAlive

[Ian Lance Taylor]

On Wed, Mar 29, 2017 at 9:42 AM, Caleb Spare  wrote:
> I have a question about this runtime.KeepAlive call:
>
> https://github.com/golang/go/blob/041ecb697f0e867a2bb0bf219cc2fd5f77057c2e/src/os/dir_unix.go#L68
>
> (There are other examples in the stdlib as well, I think.)
>
> It seems to me that, strictly speaking, KeepAlive is unnecessary here
> since the compiler/runtime cannot know whether the loop will terminate
> before the result of the ReadDirent is seen. Is that true?
>
> I'm not arguing that the KeepAlive should be removed; it's probably
> best to stick with the pattern syscall(f.Fd(), ...);
> runtime.KeepAlive(f) in most cases. I'm just checking my understanding
> here.

Yes, I think you are correct.

Ian

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

Re: [go-nuts] Re: Last Gasp Call for Native Decimal Support

[a . matuschek]

> No!


We want to use operators like + , - , *  and /  with decimal values. This 
is actualy a "No Go" !

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

[go-nuts] Syscalls inside loops + runtime.KeepAlive

[Caleb Spare]

I have a question about this runtime.KeepAlive call:

https://github.com/golang/go/blob/041ecb697f0e867a2bb0bf219cc2fd5f77057c2e/src/os/dir_unix.go#L68

(There are other examples in the stdlib as well, I think.)

It seems to me that, strictly speaking, KeepAlive is unnecessary here
since the compiler/runtime cannot know whether the loop will terminate
before the result of the ReadDirent is seen. Is that true?

I'm not arguing that the KeepAlive should be removed; it's probably
best to stick with the pattern syscall(f.Fd(), ...);
runtime.KeepAlive(f) in most cases. I'm just checking my understanding
here.

Thanks!
Caleb

-- 
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: Workspace and dependencies

[mhhcbon]

To add to the previous answer,

> I've read that GOPATH is the location of my workspace, where all of my go 
code belongs (personal project and dependencies of all of these projects). 

yes (so far)

> If I want to push one of my project on github, will I push only my 
project source code or will I also push the dependencies ? 
you might do both, depending on the project.
If you decide to push your deps, they have to be located under vendor 
folder of the repo.
If you prefer not to push the deps, you might want to try dep 
https://github.com/golang/dep/ or glide (glide.sh)

> Can I have two projects using two different version of the same project ?
Yes, if the dependency exists within the vendor folder of each project.
On that subject, remember 
- go resolves dependencies by their longest path (might be more complex in 
some cases, not sure),
- go resolves deps firstly in vendor, then into the WSpace (using above 
strat)

Welcome !

On Monday, March 27, 2017 at 7:15:51 AM UTC+2, Rafo Ufoun wrote:
>
> Hello everyone ! 
>
> I'm new to golang and I have some questions about the workspace and the 
> dependencies management. 
>
> I've read that GOPATH is the location of my workspace, where all of my go 
> code belongs (personal project and dependencies of all of these projects). 
>
> If I want to push one of my project on github, will I push only my project 
> source code or will I also push the dependencies ? 
> If I must push only my code, how another developer who wants to clone my 
> repo can find the list of my dependencies and use the rights versions ? 
>
> Can I have two projects using two different version of the same project ? 
> (It seems to be impossible if all of my project and dependencies are in the 
> same folder). 
>
> Thanks for you answers !

-- 
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: Workspace and dependencies

[Prabesh P]

https://blog.gopheracademy.com/advent-2015/vendor-folder/

On Monday, March 27, 2017 at 10:45:51 AM UTC+5:30, Rafo Ufoun wrote:
>
> Hello everyone ! 
>
> I'm new to golang and I have some questions about the workspace and the 
> dependencies management. 
>
> I've read that GOPATH is the location of my workspace, where all of my go 
> code belongs (personal project and dependencies of all of these projects). 
>
> If I want to push one of my project on github, will I push only my project 
> source code or will I also push the dependencies ? 
> If I must push only my code, how another developer who wants to clone my 
> repo can find the list of my dependencies and use the rights versions ? 
>
> Can I have two projects using two different version of the same project ? 
> (It seems to be impossible if all of my project and dependencies are in the 
> same folder). 
>
> Thanks for you answers !

-- 
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: directory name versus package name

[Scott Lewis-Kelly]

This is touched upon in this blog post 
. It is confusing that the 
import path would not match the package it contains. 

On Wednesday, March 29, 2017 at 6:18:52 PM UTC+11, Dorival Pedroso wrote:
>
> Hello,
>
> I haven't noticed that the code below (located at *$GOPATH/src/MyWrapper*
> ):
>
> package mylib
>
> import "fmt"
>
> func SayHello() {
> fmt.Println("hello")
> }
>
> is actually being installed (go install) as a *MyWrapper* package, even 
> though the package name was explicitly given as *mylib*.
>
> I couldn't find in the documentation where the handling of this situation 
> is described; i.e. how the final package name is decided (apparently the 
> directory name is chosen).
>
> Anyway, so, why using *package mylib* then?
>
> Cheers.
> Dorival
>
>
>

-- 
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] directory name versus package name

[Jan Mercl]

On Wed, Mar 29, 2017 at 9:19 AM Dorival Pedroso 
wrote:

> Anyway, so, why using package mylib then?

'mylib' is the implicit qualifier used to access the exported identifiers
from that package from within a package importing it.

-- 

-j

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

Re: [go-nuts] Re: Unexpected behavior with panic/defer/recover

['Axel Wagner' via golang-nuts]

There is also one additional caveat (not for your example, but just in case
you stumble upon it): recover must be called *from a deferred
function, *meaning
"defer recover()" won't work either. You *always* need to wrap recover in a
function and that function *always* needs to be directly defer'd.

On Wed, Mar 29, 2017 at 4:21 AM, T L  wrote:

> http://www.tapirgames.com/blog/golang-panic-recover-mechanism
>
>
> On Wednesday, March 29, 2017 at 6:48:52 AM UTC+8, Stefan Engstrom wrote:
>>
>> Playing with recovery from a panic - this code does what i expect: (
>> https://play.golang.org/p/p5KvOYc1sx)
>>
>> package main
>>
>> import "fmt"
>>
>> func main() {
>>   defer func() {
>> fmt.Println("main:",recover())
>>   }()
>>   a()
>> }
>>
>> func a() {
>>   panic("yikes")
>> }
>>
>> Results in:
>>
>> main: yikes
>>
>>
>>
>>
>> A simpler version without the closure doesn't catch the panic: (
>> https://play.golang.org/p/0ICqqdi2kL)
>>
>> package main
>>
>> import "fmt"
>>
>> func main() {
>>   defer fmt.Println("main:",recover())
>>   a()
>> }
>>
>> func a() {
>>   panic("yikes")
>> }
>>
>> Produces:
>>
>> main: 
>> panic: yikes
>>
>> goroutine 1 [running]:
>> main.a()
>> /tmp/sandbox638763687/main.go:11 +0x60
>> main.main()
>> /tmp/sandbox638763687/main.go:7 +0x100
>>
>>
>> I see the same behavior on linux/amd64 go1.8
>>
>> Any idea why the second version fails to catch that panic?
>>
>> Thanks,
>>
>> Stefan
>>
>> --
> 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.
>

-- 
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] directory name versus package name

[Dorival Pedroso]

Hello,

I haven't noticed that the code below (located at *$GOPATH/src/MyWrapper*):

package mylib

import "fmt"

func SayHello() {
fmt.Println("hello")
}

is actually being installed (go install) as a *MyWrapper* package, even 
though the package name was explicitly given as *mylib*.

I couldn't find in the documentation where the handling of this situation 
is described; i.e. how the final package name is decided (apparently the 
directory name is chosen).

Anyway, so, why using *package mylib* then?

Cheers.
Dorival


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