Re: [go-nuts] Re: A proposal for generic in go

['Thomas Bushnell, BSG' via golang-nuts]

Really? How would you implement math.Max with generics?

Thomas

On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov 
wrote:

> https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are
> just two stdlib packages that would greatly benefit from some kind of
> generics. I'm pretty sure there are more packages in the stdlib that would
> be greatly improved. And that's just the standard library.
>
>
> On Tuesday, June 21, 2016 at 5:29:37 PM UTC+3, Henry wrote:
>>
>> You still haven't provided any argument why generics is indispensable.
>>
>> The reason why I am no longer sure about my position in this issue is
>> because -while I agree that generics is useful- I don't think that generics
>> is essential. In fact, all of C++ features are useful and implemented in a
>> very efficient manner, but take a look what happened when you slab that
>> many features together. If you can do away with less, I think you should go
>> for less. The trouble is deprecating language features is a lot harder than
>> deprecating APIs in the standard library, while programming fads come and
>> 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.
>

-- 
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: GODEBUG=gctrace=1 vs. debug.GCStats

[Caleb Spare]

Yes, truncating the digits (instead of rounding) indeed explains it.
Thanks Austin!

On Wed, Jun 22, 2016 at 5:30 PM, Austin Clements  wrote:
> I think what you're seeing is simply rounding in the values printed by the
> gctrace. You're correct that the two metrics are reporting the same thing.
> In fact, they come from the exact same time stamps internally. But
> formatting floating point numbers is hard. :) The gctrace printer simply
> truncates the printed value to a reasonable number of digits, so, for
> example, the 0.20ms in your second GC might actually be 0.207ms.
>
> On Wed, Jun 22, 2016 at 5:55 PM, Caleb Spare  wrote:
>>
>> Hi,
>>
>> I'm looking at GC statistics using both GODEBUG=gctrace=1 and
>> debug.ReadGCStats. My question is: should the pause durations reported
>> in debug.GCStats match the sum of the two STW phases listed in the
>> gctrace?
>>
>> I ask because they are generally close but not the same. I have a
>> trivial program (https://play.golang.org/p/9NYDjBW6ei) that prints gc
>> stats; when I run it with GODEBUG=gctrace=1, I see output like this:
>>
>> LastGC: 1969-12-31T16:00:00-08:00 NumGC: 0 PauseTotal: 0 Pause: []
>> LastGC: 1969-12-31T16:00:00-08:00 NumGC: 0 PauseTotal: 0 Pause: []
>> LastGC: 1969-12-31T16:00:00-08:00 NumGC: 0 PauseTotal: 0 Pause: []
>> gc 1 @3.427s 0%: 0.046+0.20+0.060 ms clock, 0.14+0.024/0.13/0.13+0.18
>> ms cpu, 4->4->0 MB, 5 MB goal, 4 P
>> LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
>> Pause: [106.965µs]
>> LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
>> Pause: [106.965µs]
>> LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
>> Pause: [106.965µs]
>> LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
>> Pause: [106.965µs]
>> gc 2 @7.320s 0%: 0.008+0.14+0.20 ms clock, 0.033+0/0.098/0.13+0.82 ms
>> cpu, 4->4->0 MB, 5 MB goal, 4 P
>> LastGC: 2016-06-22T16:46:17-07:00 NumGC: 2 PauseTotal: 322.029µs
>> Pause: [215.064µs 106.965µs]
>>
>> For the first GC, gctrace shows 0.046ms + 0.060ms = 106µs vs 106.965µs
>> from ReadGCStats.
>> For the second GC, gctrace shows 0.008ms + 0.20ms = 208µs vs 215.064µs
>> from ReadGCStats.
>>
>> I'm trying to understand whether these two metrics are reporting
>> essentially the same thing (as is my understanding), or whether there
>> is some source of STW pause time ReadGCStats is showing me that isn't
>> exposed in the gctrace.
>>
>> (I see similar results on 1.6.2 and tip.)
>>
>> 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] GODEBUG=gctrace=1 vs. debug.GCStats

[Caleb Spare]

Hi,

I'm looking at GC statistics using both GODEBUG=gctrace=1 and
debug.ReadGCStats. My question is: should the pause durations reported
in debug.GCStats match the sum of the two STW phases listed in the
gctrace?

I ask because they are generally close but not the same. I have a
trivial program (https://play.golang.org/p/9NYDjBW6ei) that prints gc
stats; when I run it with GODEBUG=gctrace=1, I see output like this:

LastGC: 1969-12-31T16:00:00-08:00 NumGC: 0 PauseTotal: 0 Pause: []
LastGC: 1969-12-31T16:00:00-08:00 NumGC: 0 PauseTotal: 0 Pause: []
LastGC: 1969-12-31T16:00:00-08:00 NumGC: 0 PauseTotal: 0 Pause: []
gc 1 @3.427s 0%: 0.046+0.20+0.060 ms clock, 0.14+0.024/0.13/0.13+0.18
ms cpu, 4->4->0 MB, 5 MB goal, 4 P
LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
Pause: [106.965µs]
LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
Pause: [106.965µs]
LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
Pause: [106.965µs]
LastGC: 2016-06-22T16:46:13-07:00 NumGC: 1 PauseTotal: 106.965µs
Pause: [106.965µs]
gc 2 @7.320s 0%: 0.008+0.14+0.20 ms clock, 0.033+0/0.098/0.13+0.82 ms
cpu, 4->4->0 MB, 5 MB goal, 4 P
LastGC: 2016-06-22T16:46:17-07:00 NumGC: 2 PauseTotal: 322.029µs
Pause: [215.064µs 106.965µs]

For the first GC, gctrace shows 0.046ms + 0.060ms = 106µs vs 106.965µs
from ReadGCStats.
For the second GC, gctrace shows 0.008ms + 0.20ms = 208µs vs 215.064µs
from ReadGCStats.

I'm trying to understand whether these two metrics are reporting
essentially the same thing (as is my understanding), or whether there
is some source of STW pause time ReadGCStats is showing me that isn't
exposed in the gctrace.

(I see similar results on 1.6.2 and tip.)

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.

RE: [go-nuts] Go test to run over sub packages?

[Dave Cheney]

Permitting symlinks inside GOPATH would introduce all the problems of one 
source package having multiple locations that currently plague users of the 
vendor/ feature. 

-- 
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] Any keyboard players here?

[Daniel Skinner]

tgui-harm looks pretty interesting, I'll have to check it out this weekend.

> Go is a very neat programming language, but it is not particulary
fast. On my rather old computer a sampling frequency of 44100Hz caused
problems, but 24000Hz did work

my package dasa.cc/snd defaults to 44100 sample rate with a 256 sample
buffer and works well for fairly simple things on a cheap mobile device
(moto g2). Anything that gets too complex on cheap mobile needs to have
those parts prerendered (facilitated by the Freeze type in the package).

For the piano sound in the example gui app (which you'd probably need to
back up to one the first commits since i have pending changes that need to
be resolved and pushed), you can see my approach here (and how package snd
works):
https://github.com/dskinner/snd/blob/master/example/piano/key.go#L134

It's a sawtooth oscillator at a given note's frequency, modulated by a
synthesized square sine at half the frequency, and phased at touch-over
half by square, duplicated at +10 and -10 cents. All three of these are
mixed together and fed into two different ADSR envelopes, one with a quick
attack and decay and spends most time in sustain, the other with
near-instant attack and spends most time in decay. These two envelopes are
further mixed together and gain adjusted. At this point there's a global
reverb built from lowpass over comb filter over a tapped delay line and a
separate lowpass filter that sits right before speaker output which overall
provides a decent piano sound.

Now, at this point, live rendering can start experiencing frequent hiccups
with the default sample rate and buffer I mentioned, but only on my cheap
mobile device. That could be compensated with an increased buffer but that
also increases software latency which is already at 5.8ms (although, maybe
i'm being a pain now given *hardware* latency on many android devices is
greater than 100ms anyway!), so instead I chose to freeze portions of the
rendering that are mostly inconsequential to live playback. But on my
laptop, none of this is a problem and everything runs fast.

I guess the point of all this being, I'd like to challenge your notion of
"not particularly fast" :) as I know there's still room for improvement in
my own package.

On Wed, Jun 22, 2016 at 12:45 PM Seb Binet  wrote:

> On Wed, Jun 22, 2016 at 6:37 PM,  wrote:
>
>> Hello,
>>
>> I created a (kind of) organ or piano, to be played with a MIDI keyboard.
>> It has a GUI running in the terminal, thanks to the excellent termbox-go
>> library. It's only for Linux, but porting should not be too difficult.
>> PulseAudio is used for sound.
>>
>> In my humble opinion this software instrument sounds very good. You can
>> add new patches of your own, adding to the about 20 built-in patches. What
>> you play can be dumped into a WAVE file.
>>
>> You can get it here: https://github.com/wboeke/tgui
>>
>
> FYI, there was this Go challenge some time ago:
>  http://golang-challenge.org/go-challenge7/
> with these winners:
>  https://jamescscott.io/2015/11/03/my-golang-challenge-experience/
>  https://github.com/dskinner/snd/tree/master/example/piano
>
> I also know Andrew Gerrand is dabbling into sound related activities
> (during his "copious" free time :P)
> https://github.com/nf/sigourney
>
> hth,
> -s
>
> --
> 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] Text template with same name - inconsistent errors

[Evan Digby]

I'm noticing that if I accidentally create a second template with the same 
name but no content there is no error reported when I "parse" it, but then 
when I attempt to execute it I do see an error:

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

Is this expected behaviour? Why wouldn't it simply return an error from the 
Parse call?

The key is the second template must have no content. The following does not 
return an error on execute:

https://play.golang.org/p/O5xv5rS-cg (both have content)
https://play.golang.org/p/kaoVWRunrP (only the second has content)

I have also noticed that this isn't an issue if they are not all based from 
the same template:

https://play.golang.org/p/iLoHokX4uy
https://play.golang.org/p/T07Z9rvfmW

The inconsistency in behaviour between the examples listed is a bit 
confusing. If there truly is expected that the one case that does error our 
on execute should error out, and not the others, I believe that the error 
makes more sense (and could be easily caught) on the Parse call, not the 
execute call.

Can someone provide some insight into why this might legitimately be 
behaving this way? 

Thank you!




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

RE: [go-nuts] Go test to run over sub packages?

[John Souvestre]

Ø  Symlinks and the go tools should be avoided.

 

Was this done intentionally?  If so, why?  If not, is it a bug which should be 
fixed?

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Dave Cheney
Sent: 2016 June 21, Tue 19:19
To: golang-nuts
Cc: gabriel.kop...@gmail.com
Subject: Re: [go-nuts] Go test to run over sub packages?

 

I'm sorry to say that that is bad advice. Symlinks and the go tools should be 
avoided.

On Wednesday, 22 June 2016 08:29:33 UTC+10, gabriel...@gmail.com wrote:

Hi Ian, thanks for the confirmation!

It turns out that the cause of this behavior is that I had followed the 
instructions at 
https://github.com/karlseguin/the-little-go-book/blob/9f95b4405760fe9d24d4f9b7da93889cc9306f58/en/go.md#getting-started
 and
symlinked thus: `$ ln -s ~/code/golang-workspace/src/github.com/foo/proj 
~/code/proj`

 

In a directory structure without the symlink, things work correctly :)

 

I'll file an issue on the Little Book of Go about this gotcha.

 

Gabe

 

 

On Tuesday, June 21, 2016 at 3:09:35 PM UTC-7, Ian Lance Taylor wrote:

On Tue, Jun 21, 2016 at 12:42 PM,   wrote: 
> Is `$ go test github.com/foo/proj/...`   
> really supposed to work? 

Yes. 

> When I run it I get 
> 
> warning: "github.com/foo/proj/..  ." matched no 
> packages 
> no packages to test 
> 
> But `cd src/github.com/foo/proj && go test ./...` does work as suggested. 

What is the value of your GOPATH environment variable? 

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.

-- 
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] Any keyboard players here?

[Seb Binet]

On Wed, Jun 22, 2016 at 6:37 PM,  wrote:

> Hello,
>
> I created a (kind of) organ or piano, to be played with a MIDI keyboard.
> It has a GUI running in the terminal, thanks to the excellent termbox-go
> library. It's only for Linux, but porting should not be too difficult.
> PulseAudio is used for sound.
>
> In my humble opinion this software instrument sounds very good. You can
> add new patches of your own, adding to the about 20 built-in patches. What
> you play can be dumped into a WAVE file.
>
> You can get it here: https://github.com/wboeke/tgui
>

FYI, there was this Go challenge some time ago:
 http://golang-challenge.org/go-challenge7/
with these winners:
 https://jamescscott.io/2015/11/03/my-golang-challenge-experience/
 https://github.com/dskinner/snd/tree/master/example/piano

I also know Andrew Gerrand is dabbling into sound related activities
(during his "copious" free time :P)
https://github.com/nf/sigourney

hth,
-s

-- 
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] feature request: allow literal digit underscore grouping

[Bakul Shah]

I should've realized go automatically coerced float constants to ints. Which is 
worse but never mind :-)

> On Jun 22, 2016, at 8:57 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Wed, Jun 22, 2016 at 5:54 PM Bakul Shah  wrote:
> 
> That can be dealt with an output format. Just as the hex or octal or the "e" 
> input format is lost.
> 
> > ... in Go there is a slight inconsistency: 1e6 is an int but 1e-6 is a 
> > float.
> 
> The literals 1e6 and 1e-6 are both untyped floating point constants.
> 
> 
> -- 
> -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] feature request: allow literal digit underscore grouping

[Jan Mercl]

On Wed, Jun 22, 2016 at 5:56 PM Andy Balholm  wrote:

> The same is true of brace styles :-P.

Brace style is a matter of preference. Wrong digit grouping in a given
place on Earth is wrong, not less preferred.

-- 

-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] feature request: allow literal digit underscore grouping

[Jan Mercl]

On Wed, Jun 22, 2016 at 5:54 PM Bakul Shah  wrote:

That can be dealt with an output format. Just as the hex or octal or the
"e" input format is lost.

> ... in Go there is a slight inconsistency: 1e6 is an int but 1e-6 is a
float.

The literals 1e6 and 1e-6 are both untyped floating point constants.


-- 

-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] feature request: allow literal digit underscore grouping

[Andy Balholm]

The same is true of brace styles :-P.

But my point is that by not allowing digit grouping, Go avoids style debates on 
that issue. The grouping could have been standardized with gofmt, but as it is, 
it is standardized by the compiler to a format that is universally understood 
(no grouping).

Andy

-- 
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] feature request: allow literal digit underscore grouping

[Bakul Shah]

That can be dealt with an output format. Just as the hex or octal or the "e" 
input format is lost.

With respect to the "e" notation Go seems to be an exception. Perhaps the sole 
one? Other prog languages I have used treat eas a floating pt. even 
in Go there is a slight inconsistency: 1e6 is an int but 1e-6 is a float. I 
find 1_000_000 clearer than 1e6. Not a big deal either way.

> On Jun 22, 2016, at 8:17 AM, Michael Jones  wrote:
> 
> Sorry, I sent that too soon. 
> 
> One argument against underscores in numbers and other discardable syntax is 
> the tooling in Go to parse and regenerate go code, as in gofmt. It may be 
> more complicated to keep the “original input format” around and that is a 
> pretty good argument—unless that is already there for input values in hex.
> 
> Michael Jones
> michael.jo...@gmail.com
> 
>>> On Jun 22, 2016, at 8:14 AM, Michael Jones  wrote:
>>> 
>>> https://github.com/golang/go/issues/42
>> 
>> Michael Jones
>> michael.jo...@gmail.com
>> 
>>> On Jun 22, 2016, at 7:29 AM, Roger Pack  wrote:
>>> 
>>> Could you drop me a link to the discussion by chance? Seems this
>>> feature is actually a reasonably common request :)
> 
> -- 
> 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.

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Andy Balholm]

Actually, the mention of gofmt brings up the issue of consistent formatting. If 
underscores in numbers were allowed, gofmt should automatically insert them for 
all numbers over a given length, and remove them for shorter numbers. Otherwise 
it would just be another opportunity for inconsistency, like indentation.

Andy

-- 
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] feature request: allow literal digit underscore grouping

[Michael Jones]

Sorry, I sent that too soon. 

One argument against underscores in numbers and other discardable syntax is the 
tooling in Go to parse and regenerate go code, as in gofmt. It may be more 
complicated to keep the “original input format” around and that is a pretty 
good argument—unless that is already there for input values in hex.

Michael Jones
michael.jo...@gmail.com

> On Jun 22, 2016, at 8:14 AM, Michael Jones  wrote:
> 
>> https://github.com/golang/go/issues/42
> 
> Michael Jones
> michael.jo...@gmail.com
> 
>> On Jun 22, 2016, at 7:29 AM, Roger Pack  wrote:
>> 
>> Could you drop me a link to the discussion by chance? Seems this
>> feature is actually a reasonably common request :)
> 

-- 
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] feature request: allow literal digit underscore grouping

[Michael Jones]

> https://github.com/golang/go/issues/42

Michael Jones
michael.jo...@gmail.com

> On Jun 22, 2016, at 7:29 AM, Roger Pack  wrote:
> 
> Could you drop me a link to the discussion by chance? Seems this
> feature is actually a reasonably common request :)

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

Re: [go-nuts] Re: Go 1.6.1 Link problem on Windows:

[Roger Pack]

FWIW this is not a failure, just a double define... and if the problem
is in mingw-w64 then it won't be fixed in golang any version of
course, though I'm not sure if that's the case or not.
Cheers!

On Wed, Jun 22, 2016 at 6:24 AM,   wrote:
> I am having the same issues with go1.6.2... I also tried go1.7beta2 with no
> luck.
> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
> c:/program
> files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dmads01971.o):(.idata$5+0x0):
> multiple definition of `__imp_sqrt'
> c:/program
> files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dygcs01179.o):(.idata$5+0x0):
> first defined here
>
>
>
> On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote:
>>
>> Hi,
>>
>> I'm just wondering what is the cause of the following error (multiple
>> definition of __something)?
>> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
>>
>> C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dyyls01966.o):(.idata$5+0x0):
>> multiple definition of `__imp_pow'
>>
>> This only happens on Windows10 but on Ubuntu/Linux.
>>
>> The Go code makes a call to LAPACK via a C interface as follows:
>> package main
>>
>> /*
>> #cgo CFLAGS: -O3
>> #cgo linux   LDFLAGS: -lm -llapack -lgfortran -lblas
>> #cgo windows LDFLAGS: -lm -llapack -lgfortran -lblas -LC:/GoslDeps/lib
>>
>> #include 
>>
>> void dgesvd_(const char* jobu, const char* jobvt, const int* M, const int*
>> N, double* A, const int* lda, double* S, double* U, const int* ldu, double*
>> VT, const int* ldvt, double* work,const int* lwork, const int* info);
>>
>> int lapack_svd(double *U, double *S, double *Vt, long m_long, double *A) {
>> int m = (int)(m_long);
>> int info  = 0;
>> charjob   = 'A';
>> int lwork = 10*m;
>> double* work  = (double*)malloc(lwork*sizeof(double));
>> dgesvd_(,   // JOBU
>> ,   // JOBVT
>> , // M
>> , // N
>> A,  // A
>> , // LDA
>> S,  // S
>> U,  // U
>> , // LDU
>> Vt, // VT
>> , // LDVT
>> work,   // WORK
>> , // LWORK
>> ); // INFO
>> free(work);
>> return info;
>> }
>> */
>> import "C"
>>
>> import (
>> "fmt"
>> "math"
>> "unsafe"
>> )
>>
>> func main() {
>> A := []float64{1, 2, 3, 2, -4, -9, 3, 6, -3} // col-major format
>> m := int(math.Sqrt(float64(len(A
>> I := func(i, j int) int { return j*m + i }
>> printmat(m, A, "A")
>> U := make([]float64, len(A))
>> S := make([]float64, len(A))
>> Vt := make([]float64, len(A))
>> info := C.lapack_svd(
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (C.long)(m),
>> (*C.double)(unsafe.Pointer([0])),
>> )
>> fmt.Printf("SVD: info = %d\n", info)
>> USVt := make([]float64, len(A))
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> for k := 0; k < m; k++ {
>> USVt[I(i, j)] += U[I(i, k)] * S[k] * Vt[I(k, j)]
>> }
>> }
>> }
>> printmat(m, USVt, "U*S*Vt")
>> }
>>
>> func printmat(m int, M []float64, msg string) {
>> fmt.Printf("%s =\n", msg)
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> fmt.Printf("%13.8f", M[j*m+i])
>> }
>> fmt.Println()
>> }
>> }
>>
>> Any help is much appreciated.
>>
>> Cheers.
>> Dorival
>
> --
> 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/fW4KZQ05G_8/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.

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Roger Pack]

Could you drop me a link to the discussion by chance? Seems this
feature is actually a reasonably common request :)

On Tue, Jun 21, 2016 at 12:47 PM, Michael Jones  wrote:
> I asked for this a while back ("drop underscore between digits as in Ada")
> and the answer was no. I try to ask just once.
>
> This was shut down without much discussion at
> https://github.com/golang/go/issues/42.
>
> I agree that it's a nice feature.
>
> By the way, though, one nice aspect of Go is that because of how
> untyped constants work you can write integers using scientific
> notation:
>
> for i := 0; i < 10e6; i++ {
> // ...
> }
>
> This is exactly the same as if you had written 1000.
>
> (I don't think you'd want to do this in C or Java because, although it
> would "work", 10e6 is a floating point number and so i would be
> converted to a double for comparison. I am not an expert in those
> languages, though, so someone can correct if I'm wrong here.)
>
> On Tue, Jun 21, 2016 at 8:44 AM, Roger Pack  wrote:
>> I found recently when doing some language comparisons
>>
>> In a few other languages (ruby, java, etc.) underscores within numeric
>> literals to make them more readable, ex:
>>
>> 10_000_000.times do
>>   ...
>> end
>>
>> go ex:
>>
>> for i := 0; i < 1000; i++ {
>> ...
>> }
>>
>> I find it helps readability, and think it would be a nice addition to the
>> language (or some way to group digits, perhaps there already is one?).
>> Consider this a feature request (go 2.0 or what not).
>> Cheers.
>> -roger-
>>
>> --
>> 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.

-- 
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: Goroutines vs OS threads

[Tu Pham Anh]

Thank you very much for your response, I think that at abstract level it is 
true.

When we go into more detail, we will that GO optimize to have Routine context ( 
that some kind of Thread context), I think that at the conception level it some 
kind of yeild (conception ) to start to GORoutine.

But I read somewhere that GoRoutine optimize to create the thread when it 
dispatched ( at REGIGER level, they said that 3 Registers  need to be handled 
to create new GoRoutine ).


You see that although you could create the large number of GORoutine but almost 
of them have status BLOCK, and small number of them are running ( basing OS 
Thread ). For the sharing data between routines, I think that in mode RUNNING, 
there are Routine context that keep this sharing work smoothly.

In my own opinion, it is one of the best choice to schedule job, Imagine that 
each time you start the GoRoutine, the new OS thread is created and start - I 
do not think that way cheap or lightweight routine as everyone said.



> On Jun 22, 2016, at 20:53, Konstantin Khomoutov 
>  wrote:
> 
> On Wed, 22 Jun 2016 00:34:56 -0700 (PDT)
> tu.p...@zalora.com wrote:
> 
>> I think that the idea of Goroutine come from
>> [https://en.wikipedia.org/wiki/Coroutine],
> 
> This is hardly true: coroutines imply cooperative scheduling, where
> each coroutine explictly relinquishes control to some other coroutine
> (typically it's said it "yields" some intermediate result) without
> actually returning.  In contrast, goroutines behave much more like
> OS-level threads in that the Go runtime scheduler is free to preempt any
> goroutine at will at certain key points of their execution (presently
> these include the event when a goroutine is about to block on a syscall
> or call another Go function).  Hence while it's not a "full" preemptive
> scheduling which commodity operating systems apply to their OS-level
> threads, it's still way more closer to it than the cooperative ("at
> will") scheduling used by coroutines.
> 
> One more point to this is that coroutines are usually considered as
> being executed by a single thread of execution which is not true for
> goroutines -- which, due to this reason, cannot safely access shared
> data without locking, and must synchronize all such access or use
> specific communication primitives -- channels.
> 
> Go draws its approach to goroutines from a number of languages which
> predates it, but ultimately this idea comes from [1].
> 
>> the number of Goroutines are mapped to OS Threads.
> 
> It's more accurate to say that an arbitrary number of goroutines can be
> mapped to an arbitrary number of OS threads, which is usually referred
> to as "N x M scheduling", with N -- the number of goroutines --
> typically being way larger than M -- the number of OS threads undelying
> them.
> 
>> In my own opinion, Go maintain the Thread pool and task queue to
>> dispatch the job.
> 
> At a very abstract level, this is mostly true.
> 
> [...]
> 
> 1. https://en.wikipedia.org/wiki/Communicating_sequential_processes

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Ian Lance Taylor]

On Wed, Jun 22, 2016 at 6:50 AM, Manlio Perillo
 wrote:
> On Wed, Jun 22, 2016 at 3:35 PM, Henrik Johansson  
> wrote:
>> Really?
>
> Yes.
> The problem is that many people coming from C like languages may
> incorrectly assume that i is a floating point number.

This doesn't strike me as a good reason to avoid writing numbers as
1e6 or whatever.  Go is a relatively simple language.  It's reasonable
to expect people using Go to learn the language.

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] feature request: allow literal digit underscore grouping

[Henrik Johansson]

Really? I find that counting digits in large numbers is harder, for me at
least, than expected. The scientific notation is sweet.

On Wed, Jun 22, 2016, 14:57 Manlio Perillo  wrote:

> Il giorno martedì 21 giugno 2016 18:35:13 UTC+2, Caleb Spare ha scritto:
>>
>> This was shut down without much discussion at
>> https://github.com/golang/go/issues/42.
>>
>> I agree that it's a nice feature.
>>
>> By the way, though, one nice aspect of Go is that because of how
>> untyped constants work you can write integers using scientific
>> notation:
>>
>> for i := 0; i < 10e6; i++ {
>> // ...
>> }
>>
>> This is exactly the same as if you had written 1000.
>>
>> (I don't think you'd want to do this in C or Java
>
>
> I would not do this even in Go, since it makes the code less readable IMHO.
>
> > [...]
>
>
> 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.
>

-- 
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] How to hide command line argument from ps

[Sean Russell]

On Tuesday, June 21, 2016 at 9:56:21 PM UTC-4, Lazytiger wrote:
> Thanks for all the replies. I agree that there is a better way to do the 
> security jobs. I ask this question just for curiosity, to find out if there 
> is a equivalence way to do this in golang. From all the replies I assume 
> there is a no.

Environment variables. github.com/namsral/flag implements a flags library that 
will populate flags from either command line args or environment variables at 
run time, and is a drop-in replacement for the standard flag library.

--- SER

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> The fact still remains that unlike a lot of other proposed languages 
additions that are immediately dropped, generics are still open for 
discussion by the language developers themselves. 

I think that the problerm only in the Go developers brcause them even does 
try to implement them experimentally.
That is so called "hidden" implementation when the runtime engine supports 
the feature but compiler does not.
That is, available for testing only through the reflection but without 
grammar specification on that how to declare and use time at compile time.
As for me, they should have them (support of the generic types) in the 
runtime engine and in the reflection for the testing purpose but does not 
introduce them until they not decide that them are ready for real use.

-- 
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: A proposal for generic in go

[Sean Russell]

On Tuesday, June 21, 2016 at 10:29:37 AM UTC-4, Henry wrote:
> You still haven't provided any argument why generics is indispensable. 

That can't be the litmus for language feature inclusion; if it was, Go would 
resemble ASM. 

In my personal experience, something North of 50% of my non-trivial 
applications could have been more simple with some form of generics allowing me 
to reduce code duplication. In particular, any application dealing with 
demarshaling of data from a large set of similar functions (e.g. web calls) are 
good examples. Have 30 functions to make the same web calls and perform the 
same demarshaling calls -- especially where the web call may be more complex, 
as in a SOAP call -- does not make the code cleaner, easier to cognitively 
parse, or more safe. Indeed, in almost every such case, generics reduce code 
duplication and make the code safer from bugs, and easier to maintain.

Indispensable? That's subjective, and very few language features satisfy that 
requirement. For me, the strongest argument against it is that if the core Go 
team can't think of a way to implement it cleanly and efficiently, then I trust 
it's a hard problem. I'm sure they've looked at it; it must be the single most 
commonly requested, hashed-over, and proposal-backed feature.

--- SER

-- 
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: A proposal for generic in go

[Egon]

On Wednesday, 22 June 2016 15:32:53 UTC+3, Andrew Mezoni wrote:
>
> >> The version without generics is necessary to compare how well a 
> particular generics approach improves the current language and code.
>
> I am sorry but this is obviously that any useful feature (in the context 
> of solving problems) improves the current language and code.
>

Yes.. Of course, this presupposes that the particular generics approach is 
useful.
How would you demonstrate that one generics approach is more useful than 
another?

Another question: how new (version of the) language will look cosmetically 
> with this newly added feature.
>
> I found that the second question here more important then the first.
>
> It is obviously correct that the code with a generics (in appropriate 
> place) would be more useful then other code.
>

Which generics approach?
Which places need that kind of generics?
Should the language solve all generics related problems or only some?
Are there better solutions to those problems than generics?
Would some meta-programming approach negate the need for generics?

Also, is "useful in some particular case" the best metric to decide whether 
something should be included in the language?

e*.g. #define max(a,b) ((a) < (b) ? (b) : (a))*

But here I undestand one interesting thing which states: Some obviously 
> useful feature can significantly spoil the overall picture of language.
>
> For me this is very strange only because even a C language also has been 
> improved after when it initially was introduced. 
>

Have you also looked at the proposals that were rejected? If someone made 
the proposal, it must have been useful to someone.

In the years following the publication of K C, several features were 
> added to the language, supported by compilers from AT and some other 
> vendors. These included:
>
>- void  functions (i.e., 
>functions with no return value)
>- functions returning struct 
>
> 
> or union  types 
>(rather than pointers)
>- assignment 
> for 
>struct data types
>- enumerated types 
>
> 
>
> Were there any competing proposal for those same feature sets? Why were 
the others rejected whereas these particular ones accepted?

Also, what if, instead functions just allowing returning struct/unions, it 
would have also allowed to return multiple parameters? Would that have 
resulted better or worse C code?
 

> C99 introduced several new features, including inline functions 
> ,
>  
> several new data types 
>  (including long long int and a complex type to represent complex numbers 
> ), variable-length arrays 
> 
>  and flexible array members 
> ,
>  
> improved support for IEEE 754  
> floating 
> point, support for variadic macros 
>  (macros of variable arity 
> ), and support for one-line comments 
> beginning with //
>
> The C11 standard adds numerous new features to C and the library, 
> including type generic macros, anonymous structures, improved Unicode 
> support, atomic operations, multi-threading, and bounds-checked functions. 
>
> P.S.
>
> I guess I should think that this is very bad, because my first 
> acquaintance with the language began with the ZX-Spetrum and continued with 
> the Borland Turbo C.
>
> Indeed, the C language is now looks much worse cosmetically than before. 
> But should I regret it?
> Maybe...
>

-- 
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] feature request: allow literal digit underscore grouping

[Manlio Perillo]

Il giorno martedì 21 giugno 2016 18:35:13 UTC+2, Caleb Spare ha scritto:
>
> This was shut down without much discussion at 
> https://github.com/golang/go/issues/42. 
>
> I agree that it's a nice feature. 
>
> By the way, though, one nice aspect of Go is that because of how 
> untyped constants work you can write integers using scientific 
> notation: 
>
> for i := 0; i < 10e6; i++ { 
> // ... 
> } 
>
> This is exactly the same as if you had written 1000. 
>
> (I don't think you'd want to do this in C or Java


I would not do this even in Go, since it makes the code less readable IMHO.

> [...]


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] Re: A proposal for generic in go

[Viktor Kojouharov]

On Tuesday, June 21, 2016 at 9:56:01 PM UTC+3, Axel Wagner wrote:
>
> The issue is, that a "KeyValuePair" (no matter if you implemented it 
> via generics or like you mention via interfaces) is a fundamentally useless 
> type and generics encourage people to add useless types. A "KeyValuePair V>" is a "struct { Key K, Value V }", plain and simple. It's not an 
> interface and it's not a generic type, it's simply a struct.
>

And yet the 'K' and 'V' within the struct are generic types. A struct is 
never simple. That's its whole point.
 

>
> I agree, that generics are useful, but they seem to be mainly useful for 
> people who write "frameworks", not so much for people who write 
> "applications" and so far, go is pretty much a language for the latter. 
> Whenever people try to justify generics, they do it from a "I want to write 
> a framework" POV - and whenever I miss generics, I do because I'm currently 
> writing a framework of some kind.
>

A lot of these 'applications' that you think are the language's main target 
are built on top of libraries, including stdlib, written by that same 
language. And these same libraries can benefit from having generics, once 
again, including stdlib.
 

>
> Generics empower abstractions, but most programmers are very bad at 
> building abstractions, so if you make it easy to build abstractions, you 
> will end up with a lot of bad abstractions (have a look at java). So, to a 
> certain degree, the value of go is, to *not* make building abstractions 
> overly simple. That leads to abstractions being used only where they are 
> essential and being left out where they are superfluous. This is where 
> reduced cognitive overhead comes into play - limiting the levels of 
> abstractions that people need to deal with to the bare essentials. Java is 
> bloated and hard to use, not because the language is bad, but because it 
> has a history of programmers building bad abstractions into it which gets 
> stacked on top of each other. So, yes, if you compare a bad abstraction 
> using interfaces with a bad abstraction using generics, generics will, in 
> general, compare very well. But you just shouldn't build the bad 
> abstraction in the first place.
>

I've found this type of thinking quite poisonous. The "lets bereave 
ourselves of something universally lauded as useful, because it _might_ be 
used in the wrong manner by some people" mentality is just wrong and 
prevents any kind of useful evolution under any context. 
 

>
> The second concern with complexity is the spec. The exact behavior and 
> semantics of generics need to be spec'ed and useful generics need a lot 
> specification. For example, the current rules for type inference can be 
> understood completely just by looking at a single expression and it's type 
> and it's correspondingly simple to implement and spec. Generics usually 
> need more powerful type inference methods to not be cumbersome, which will 
> take up a lot of space in the spec. As humans, just like computers, have 
> very little memory, the time it takes to understand the spec will grow 
> superlinear with the length of it, due to frequent cache misses, so a long 
> spec will significantly increase the time needed to learn the language. In 
> the same vein, to understand a language, you need to know about 
> interactions between it's different concepts, not just the concepts itself, 
> so the needed space and time complexity to learn a language also grows 
> quadratic in the number of concepts in the language (in general). All of 
> that contributes to why people are wary of adding new concepts to go - the 
> costs in terms of understanding and learning the language are huge and they 
> grow very much superlinear in the number of concepts added, so each added 
> concept must be carefully examined (I know go for years and I still learn 
> new things about interactions between different concepts all the time).
>

And yet this hasn't stopped people from successfully learning and utilizing 
languages that have generics are part of their specifications. The fact 
still remains that unlike a lot of other proposed languages additions that 
are immediately dropped, generics are still open for discussion by the 
language developers themselves. 

>
>
> I sometimes miss generics, yes, but I also believe adding them will make 
> the language significantly harder to learn and will significantly worsen 
> the quality of go code in the wild, so it would likely eliminate the 
> reasons I like go currently (which is that go code is usually of 
> exceptionally high quality, uniform and easy to understand).
>

I'm sorry, but that's just fearmongering. Unless you have some kind of 
magic crystal ball, there's now way you'd know how the quality of go code 
will change. You don't even know what the implementation will look like ...
 

>
> On Tue, Jun 21, 2016 at 5:06 PM,  
> wrote:
>
>> >> What I mean is that most people who have 

Re: [go-nuts] specific file cannot build

[indev]

Thank you very much.
I understand that _arm.go file means DO BUILD ONLY ARM PROCESSOR.

2016년 6월 22일 수요일 오후 9시 39분 25초 UTC+9, Jan Mercl 님의 말:
>
> On Wed, Jun 22, 2016 at 2:32 PM  wrote:
>
> > How this "magic" can be occurred?
>
> The magic is described here: 
> https://golang.org/pkg/go/build/#hdr-Build_Constraints
>
> -- 
>
> -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: Go 1.6.1 Link problem on Windows:

[Dorival Pedroso]

oh, bad news... I was expecting this to be fixed in 1.7...

On Wed, Jun 22, 2016 at 10:33 PM  wrote:

> I am having the same issues with go1.6.2... I also tried go1.7beta2 with
> no luck.
> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
>
> c:/program files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin
> /../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib
> /../lib/libntdll.a(dmads01971.o):(.idata$5+0x0): multiple definition of
> `__imp_sqrt'
> c:/program
> files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dygcs01179.o):(.idata$5+0x0):
> first defined here
>
>
>
> On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote:
>>
>> Hi,
>>
>> I'm just wondering what is the cause of the following error (multiple
>> definition of __something)?
>> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
>> C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dyyls01966.o):(.idata$5+0x0):
>> multiple definition of `__imp_pow'
>>
>> This only happens on Windows10 but on Ubuntu/Linux.
>>
>> The Go code makes a call to LAPACK via a C interface as follows:
>> package main
>>
>> /*
>> #cgo CFLAGS: -O3
>> #cgo linux   LDFLAGS: -lm -llapack -lgfortran -lblas
>> #cgo windows LDFLAGS: -lm -llapack -lgfortran -lblas -LC:/GoslDeps/lib
>>
>> #include 
>>
>> void dgesvd_(const char* jobu, const char* jobvt, const int* M, const
>> int* N, double* A, const int* lda, double* S, double* U, const int* ldu,
>> double* VT, const int* ldvt, double* work,const int* lwork, const int*
>> info);
>>
>> int lapack_svd(double *U, double *S, double *Vt, long m_long, double *A) {
>> int m = (int)(m_long);
>> int info  = 0;
>> charjob   = 'A';
>> int lwork = 10*m;
>> double* work  = (double*)malloc(lwork*sizeof(double));
>> dgesvd_(,   // JOBU
>> ,   // JOBVT
>> , // M
>> , // N
>> A,  // A
>> , // LDA
>> S,  // S
>> U,  // U
>> , // LDU
>> Vt, // VT
>> , // LDVT
>> work,   // WORK
>> , // LWORK
>> ); // INFO
>> free(work);
>> return info;
>> }
>> */
>> import "C"
>>
>> import (
>> "fmt"
>> "math"
>> "unsafe"
>> )
>>
>> func main() {
>> A := []float64{1, 2, 3, 2, -4, -9, 3, 6, -3} // col-major format
>> m := int(math.Sqrt(float64(len(A
>> I := func(i, j int) int { return j*m + i }
>> printmat(m, A, "A")
>> U := make([]float64, len(A))
>> S := make([]float64, len(A))
>> Vt := make([]float64, len(A))
>> info := C.lapack_svd(
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (C.long)(m),
>> (*C.double)(unsafe.Pointer([0])),
>> )
>> fmt.Printf("SVD: info = %d\n", info)
>> USVt := make([]float64, len(A))
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> for k := 0; k < m; k++ {
>> USVt[I(i, j)] += U[I(i, k)] * S[k] * Vt[I(k, j)]
>> }
>> }
>> }
>> printmat(m, USVt, "U*S*Vt")
>> }
>>
>> func printmat(m int, M []float64, msg string) {
>> fmt.Printf("%s =\n", msg)
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> fmt.Printf("%13.8f", M[j*m+i])
>> }
>> fmt.Println()
>> }
>> }
>>
>> Any help is much appreciated.
>>
>> Cheers.
>> Dorival
>>
> --
> 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/fW4KZQ05G_8/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.
>
-- 

Dorival Pedroso PhD +61 0420411142 www.cpmech.com Brisbane Australia

-- 
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: Goroutines vs OS threads

[tu . pham]

I think that the idea of Goroutine come from 
[https://en.wikipedia.org/wiki/Coroutine], the number of Goroutines are 
mapped to OS Threads. In my own opinion, Go maintain the Thread pool and 
task queue to dispatch the job.

This pattern has been implemented in some modern JEE container.
Hope that the answer 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] specific file cannot build

[indev]

Hi. I have a question about relation between building source code and its 
filename.

When I try to build with *store_arm.go* file, I cannot build(compiler 
ignore this file).

But after *just change filename of same source code*, it is built.

How this "magic" can be occurred?









-- 
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: GoFlow - Flow-based programming package for Go

[liewjoee]

Hello Vladimir,
Is there any further developement on goflow? I see that it has last updated 
since Nov 7, 2015.

Are there any further intergration in goflow with noflo-ui?  

On Tuesday, February 14, 2012 at 4:18:23 AM UTC+10:30, Vladimir Sibirov 
wrote:
>
> I'm glad to announce GoFlow package:
> https://github.com/trustmaster/goflow
>
> It provides a framework that lets you build Go applications in 
> flow-based/dataflow/reactive programming style. A flow-based program is a 
> graph of components which run in parallel and communicate by sending 
> information packets through channels. You could surely achieve the same 
> effect by writing plain Go code, but Flow-based programming (FBP) 
> distinguishes 2 viewpoints in programming:
>  - Graph view - what components the program consists of and how they are 
> connected to each other. This is similar to DFD/SADT and is preferably 
> represented by visual diagrams.
>  - Component view - what inputs and outputs a component has and how it 
> processes data. This viewpoint is focused on smaller entities which 
> implement one specific function and the actual data processing code.
>
> I'd describe major goals of Flow-based programming paradigm in general 
> this way:
>  * Concurrency by design, not by purpose. Operate with entities which work 
> in parallel and share by communication by default.
>  * Unified approach in software development from domain analysis and 
> architecture to coding. Start with diagrams and data flows and continue the 
> structural breakdown until you reach data processing algorithms.
>  * Practices of hardware engineering mapped to software development world. 
> Some say software could be as reliable as hardware if it was built in a 
> similar way :)
>  * Active use of visual diagrams. Human beings are likely to understand 
> high-level things from diagrams easier.
>
> Unfortunately GoFlow isn't capable of running visual diagrams yet. 
> Currently this package does the following:
>  * Turns your Go structs into FBP components and graphs.
>  * Enables you to program components in event-driven way.
>  * Lets you make networks consisting of process and other networks.
>  * Provides a runtime that makes it work alltogether.
>
> More information can be found on project page and wiki.
>
> Looking forward to hearing from dataflow enthusiasts from the Go community.
>
> Vladimir.
>

-- 
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: A proposal for generic in go

[Andrew Mezoni]

>> The version without generics is necessary to compare how well a 
particular generics approach improves the current language and code.

I am sorry but this is obviously that any useful feature (in the context of 
solving problems) improves the current language and code.
Another question: how new (version of the) language will look cosmetically 
with this newly added feature.

I found that the second question here more important then the first.

It is obviously correct that the code with a generics (in appropriate 
place) would be more useful then other code.
But here I undestand one interesting thing which states: Some obviously 
useful feature can significantly spoil the overall picture of language.

For me this is very strange only because even a C language also has been 
improved after when it initially was introduced.

In the years following the publication of K C, several features were 
added to the language, supported by compilers from AT and some other 
vendors. These included:

   - void  functions (i.e., 
   functions with no return value)
   - functions returning struct 
    or union 
    types (rather 
   than pointers)
   - assignment 
    for struct 
data 
   types
   - enumerated types 


C99 introduced several new features, including inline functions 
, several new data types 
 (including long long int and a 
complex type to represent complex numbers 
), variable-length arrays 
 and flexible array 
members , improved 
support for IEEE 754  floating 
point, support for variadic macros 
 (macros of variable arity 
), and support for one-line comments 
beginning with //

The C11 standard adds numerous new features to C and the library, including 
type generic macros, anonymous structures, improved Unicode support, atomic 
operations, multi-threading, and bounds-checked functions. 

P.S.

I guess I should think that this is very bad, because my first acquaintance 
with the language began with the ZX-Spetrum and continued with the Borland 
Turbo C.

Indeed, the C language is now looks much worse cosmetically than before. 
But should I regret it?
Maybe...

-- 
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] Getting a pointer in a type switch gives a *interface {} if case lists several options

[Marvin Renich]

* raidopah...@gmail.com  [160621 18:02]:
> I have encountered some unexpected and inconsistent behavior with type 
> switches. Can someone shed some light as to why Go behaves this way?
> 
> Take a look at https://play.golang.org/p/YPV5YPtWF8
> 
> I would expect both of the switches to behave the same way, but for some 
> reason the one with multiple options in the case ends up with a pointer to 
> an interface and the one with just one option ends up with a pointer to the 
> correct type.

(Aside: reusing the variable t makes it harder to discuss specific
instances of that variable.  I am pasting your code here with variable
name changes.)

package main

import "fmt"
import "reflect"

func main() {
var v uint8 = 0
var t interface{} = v
fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(v), reflect.TypeOf()))
switch w := t.(type) {
case uint8:
fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(w), 
reflect.TypeOf()))
}
switch x := t.(type) {
case uint8, int8:
fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(x), 
reflect.TypeOf()))
}
}

The compiler must know, at compile time, what type w and x are
everywhere except in the switch expression itself.  For w in the "case
uint8" clause, the type of w is known to be uint8.  For x in the "case
uint8, int8" clause, it cannot be determined whether x will be uint8 or
int8, so the compiler must use interface{} so that it can generate a
single block of code that works for both possible case types.

If you use different case clauses for the different types, you will get
what you expected.  (I.e. add a separate "case int8:" to the first
switch statement.)

...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: A proposal for generic in go

[andrew . mezoni]

>> You are not bringing anything new to the table here, except the attempt 
to insult my intelligence, apparently.
>
>
I do not have any claims to anyone personally.
I only defend my own point of view.

P.S.

Also I don't love to see or use some (not my own) code which written like a 
mess.
If I cannot understand some code then this does not means that this code is 
bad.

But if I know that a some code has been written carelessly and can be 
written more diligently then it gives me a negative reaction on that work 
(if there was no reason to write it carelessly).

That is, write code once and and use it everywhere.
Or more precisely, write (high quality and reusable) code once and and use 
it everywhere (and give the possibility to use it to everyone).

The generics programming are very good suit for that.

In the simplest definition, *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 
. 

The term *generic programming *describes a programming paradigm whereby 
fundamental requirements on types are abstracted from across concrete 
examples of algorithms and data structures and formalised as concepts, with 
generic functions implemented in terms of these concepts, typically using 
language genericity mechanisms as described above.

P.S.

I am sorry but here we discuss mostly about the advantages and 
disadvantages of the generic programming (of course, in Go language).
Here we do not discuss: How to coding in Go language without generic 
programming.
I think that it should be different topic with appropriate title.

-- 
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: A proposal for generic in go

['Axel Wagner' via golang-nuts]

You are not bringing anything new to the table here, except the attempt to
insult my intelligence, apparently.

There are huge software projects out there written in languages that are
less type safe than go and the vast majority of code written is not
reusable. Both also aren't absolutes. There is no binary "type safe or not
type safe" and no "reusable or not reusable". There are only more or less
expressive type systems and there are only pieces of code that are easier
or harder to reuse. Every language finds their own tradeoff for them and
every programmer must find their own preferences for the tradeoffs they
require. go is explicitly designed as an engineering language and the
defining characteristic of engineering is the acknowledgment of tradeoffs.
So, without acknowledging that this needs to be a tradeoff, there really is
not much point in talking about how to improve go. If someone prefers the
extreme, might I suggest agda instead of go? I don't know of a more type
safe language out there.

On Wed, Jun 22, 2016 at 10:11 AM,  wrote:

> We continue the discussion about the dangers of `to be both type safe
> *and* reusable`?
>

That is not what I was saying. I was talking about the dangers of generics
for producing clear and readable code. That is not an issue with being
both, it's an issue with generics. "It needs to be both" just isn't a very
good argument in favor of them.


> Me and most of us MUST focusing our energy on writing high quailty and
> reusable software.
>

Instead, we seem to focus your energy on debating whether we need to add
generics to go or not. There are people out there writing high quality and
reusable software *right now*, both in go and not in go. Coincidentally,
that's what I'm going to do now too.


> Want write software only for himself? Not a problem, your energy are your
> energy.
>

I get paid to write and maintain large software in large teams, in many
languages falling into very different spots on the scale of type safety and
re-usability and my opinions are informed by that. You shouldn't presume
that people disagree with you because they know less.

-- 
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: A proposal for generic in go

[andrew . mezoni]

Sorry for typo and possible spam but correct example here:

type Foo interface {
  Get(key K) V
  Set(key K, val V)
}
func foo() (int, Foo) {

  // Typo: foo := {}
  foo := {}
  // ...
  foos := []Foo{}
  // ...
  k := "London"
  // ...
  return 55, foo2(foos, 55, k)
}
// This code is type safe and reusable
foo2 (foos []Foo, i int, key K) (V, Foo) {
  foo := foos[i]
  return foo.Get(key), foo
}



-- 
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: A proposal for generic in go

['Axel Wagner' via golang-nuts]

And my point is and was: It doesn't *need* to be both type safe *and*
reusable, unless you are focusing your energy on writing frameworks or
treating type safety as a goal solely for it's own sake. It's perfectly
fine to write small stuff yourself (for example like this) with explicit
types and it's perfectly fine to locally not have strict compiler checks if
you are doing something complicated that needs to be reusable. If you focus
on application writers, instead of the authors of the frameworks they might
use, you'll recognize that either choice just isn't that bad.

On Wed, Jun 22, 2016 at 9:36 AM,  wrote:

> >> perfectly type safe.
>
> Perfectly type safe but not perfectly reusable.
>
> What If we slightly complicate the task?
>
> Now is my code and I want to see on your code exampe (perfectly type safe
> but and perfectly reusable)
>
> type Foo interface {
>   Get(key K) V
>   Set(key K, val V)
> }
> func foo() (int, Foo) {
>   foo := {}
>   // ...
>   foos := []Foo{}
>   // ...
>   k := "London"
>   // ...
>   return 55, foo2(foos, 55, k)
> }
> // This code is type safe and reusable
> foo2 (foos []Foo, i int, key K) (V, Foo) {
>   foo := foos[i]
>   return foo.Get(key), foo
> }
>
> --
> 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.

Re: [go-nuts] Re: A proposal for generic in go

[andrew . mezoni]

>> perfectly type safe.

Perfectly type safe but not perfectly reusable.

What If we slightly complicate the task?

Now is my code and I want to see on your code exampe (perfectly type safe 
but and perfectly reusable)

type Foo interface {
  Get(key K) V
  Set(key K, val V)
}
func foo() (int, Foo) {
  foo := {}
  // ...
  foos := []Foo{}
  // ...
  k := "London"
  // ...
  return 55, foo2(foos, 55, k)
}
// This code is type safe and reusable
foo2 (foos []Foo, i int, key K) (V, Foo) {
  foo := foos[i]
  return foo.Get(key), foo
}

-- 
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 failing In Mac 10.11.4

[Debraj Manna]

Thanks Krzysztof that was the issue. For cloning the repo I used:-

git clone https://github.com/jabong/florest/

So in mac my code checked out in a directory florest. But the actual repo
name was https://github.com/jabong/floRest/ and in code it was referenced as
floRest which was causing the issue.

On Wed, Jun 22, 2016 at 8:18 AM, Krzysztof Kowalczyk 
wrote:

> My guess is that's because Mac filesystem is case preserving but not
> case-sensitive, meaning that in mac os "floRest" and "florest" is the same
> file/directory while on linux those are 2 distinct files. (you can
> configure mac filesystem to be case-sensitive as well, but that's not the
> default).
>
> As you can see in the logs:
>
> mv $WORK/github.com/jabong/floRest/src/examples.a
>  /Users/debraj/golang/pkg/darwin_amd64/
> github.com/jabong/floRest/src/examples.a
>
> mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
> github.com/jabong/florest/src/
>
> cp $WORK/github.com/jabong/florest/src/examples.a
>  /Users/debraj/golang/pkg/darwin_amd64/
> github.com/jabong/florest/src/examples.a
>
> go install github.com/jabong/florest/src/examples: open
> /var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426/
> github.com/jabong/florest/src/examples.a: no such file or directory
>
>
> a file "floRest/src/examples.a" is moved and then there's an attempt to
> copy "florest/src/examples.a", which is the same file on mac os, and it's
> no longer there.
>
>
> The question is why do you have "florest" and "floRest" packages in your
> code. Are those 2 different packages? Did you make a typo in an import
> statement?
>
>
> -- kjk
>
>
> On Tuesday, June 21, 2016 at 8:16:26 AM UTC-7, DM wrote:
>
>> Below is the ouput using the -x flag:-
>>
>> jabongs-MacBook-Pro-4:florest debraj$ go get -x ./...
>>
>> WORK=/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426
>>
>> mkdir -p $WORK/github.com/jabong/floRest/src/examples/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/floRest/src/
>>
>> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/examples
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/floRest/src/examples.a -trimpath $WORK -p
>> github.com/jabong/floRest/src/examples -complete -buildid
>> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
>> github.com/jabong/floRest/src/examples -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
>> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go
>> ./hello_world_multipe_errors.go ./swagger.go
>>
>> mkdir -p $WORK/github.com/jabong/floRest/src/service/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/examples/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/
>>
>> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/service
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/floRest/src/service.a -trimpath $WORK -p
>> github.com/jabong/floRest/src/service -complete -buildid
>> f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
>> github.com/jabong/floRest/src/service -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go
>> ./business_logic_executor.go ./config_manager.go ./constants.go
>> ./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go
>> ./init_manager.go ./monitor_helper.go ./service_register.go
>> ./service_version_helper.go ./service_workflow_data.go ./uri_interpreter.go
>> ./web_server.go
>>
>> cd /Users/debraj/golang/src/github.com/jabong/florest/src/examples
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/florest/src/examples.a -trimpath $WORK -p
>> github.com/jabong/florest/src/examples -complete -buildid
>> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
>> github.com/jabong/florest/src/examples -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
>> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go
>> ./hello_world_multipe_errors.go ./swagger.go
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/examples/cachestrategy/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/examples/
>>
>> cd /Users/debraj/golang/src/
>> github.com/jabong/florest/src/examples/cachestrategy
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/florest/src/examples/cachestrategy.a -trimpath $WORK
>> -p github.com/jabong/florest/src/examples/cachestrategy -complete
>> -buildid c16efba4536c81f8b5b9f0090f909c0b3c71383c -D
>> _/Users/debraj/golang/src/
>> github.com/jabong/florest/src/examples/cachestrategy -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
>> ./cache_strategy_user.go ./sample_db_adapter.go
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/service/_obj/
>>
>> cd /Users/debraj/golang/src/github.com/jabong/florest/src/service
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>>