[go-nuts] stringer tool to generate string to const int conversion

[Randall O'Reilly]

I just made a few mods to the stringer tool to generate a function that 
converts a string back to the const int type, e.g., for this const int type:

// SignalType provides standard signals -- can extend by starting at iota + 
last signal here
type SignalType int64

const (
NilSignal SignalType = iota
SignalChildAdded // data is the added child
SignalChildDeleted   // data is deleted child
SignalChildrenDeleted// no data
SignalNodeUpdated// entire node updated
SignalFieldUpdated   // a field was updated -- data is name 
of field
SignalTypeBaseN  // number of base-level signal type 
consts -- this is start for any derived ones
)

it generates this function in the stringer output:

func StringToSignalType(s string) (SignalType, error) {
for i := 0; i < len(_SignalType_index)-1; i++ {
if s == 
_SignalType_name[_SignalType_index[i]:_SignalType_index[i+1]] {
return SignalType(i), nil
}
}
return 0, fmt.Errorf("String %v is not a valid option for type 
SignalType", s)
}

Seems like this might be of general utility?  Is there some other simpler way 
of doing this that I’m overlooking?  Patch below.  Didn’t handle the 
multiple-runs and map cases yet..

- Randy

diff --git a/cmd/stringer/stringer.go b/cmd/stringer/stringer.go
index 4b8d1ba4..291051f8 100644
--- a/cmd/stringer/stringer.go
+++ b/cmd/stringer/stringer.go
@@ -132,7 +132,7 @@ func main() {
g.Printf("\n")
g.Printf("package %s", g.pkg.name)
g.Printf("\n")
-   g.Printf("import \"strconv\"\n") // Used by all methods.
+   g.Printf("import (\"strconv\"; \"fmt\")\n") // Used by all methods.
 
// Run generate for each type.
for _, typeName := range types {
@@ -584,6 +584,15 @@ const stringOneRun = `func (i %[1]s) String() string {
}
return _%[1]s_name[_%[1]s_index[i]:_%[1]s_index[i+1]]
 }
+
+func StringTo%[1]s(s string) (%[1]s, error) {
+   for i := 0; i < len(_%[1]s_index)-1; i++ {
+   if s == _%[1]s_name[_%[1]s_index[i]:_%[1]s_index[i+1]] {
+   return %[1]s(i), nil
+   }
+   }
+   return 0, fmt.Errorf("String %%v is not a valid option for type %[1]s", 
s)
+}
 `
 
 // Arguments to format are:
@@ -600,6 +609,15 @@ const stringOneRunWithOffset = `func (i %[1]s) String() 
string {
}
return _%[1]s_name[_%[1]s_index[i] : _%[1]s_index[i+1]]
 }
+
+func StringTo%[1]s(s string) (%[1]s, error) {
+   for i := 0; i < len(_%[1]s_index)-1; i++ {
+   if s == _%[1]s_name[_%[1]s_index[i]:_%[1]s_index[i+1]] {
+   return %[1]s(i + %[2]s), nil
+   }
+   }
+   return 0, fmt.Errorf("String %%v is not a valid option for type %[1]s", 
s)
+}
 `
 
 // buildMultipleRuns generates the variables and String method for multiple 
runs of contiguous values.

-- 
You received this message because you are subscribed 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: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[Volker Dobler]

On Thursday, 8 March 2018 00:02:58 UTC+1, Ian Lance Taylor wrote:
>
>
> If we ignore the type context, then 
>
> var v int64 = 1 << s 
>
> fails on 32-bit systems if s > 31 (because 1 is assigned type int, 
> which is 32 bits, and the shifting a 32-bit value by more than 31 bits 
> gives you zero). 
>
> If we don't ignore the type context, then in 
>
> var v float32 = 1 << s 
>
> fails because we can't shift a float32. 
>
>
Thanks! This explanation is very clear. The spec already contains
an example of this rule: var k = uint64(1

[go-nuts] [Advice needed] How to vendor common dependencies for plugins

[Jay Guo]

Golang gurus,

I'm currently trying to modularize my project with the help of Golang 
plugin, and I come across this dependency vendoring dilemma.

Let's say we have a project layout:

   - Two different projects in separate repo: `Host` and `Guest`
   - `Host` depends on package `pkgA`
   - `Guest` depends on package `pkgA` too
   - `Guest` is compiled as plugin, and loaded by `Host`
   - `pkgA` is vendored into both `Host` and `Guest`

In this situation, `pkgA` would be loaded twice and independently, meaning 
there are two instance of the package in the program, one lives in `Guest` 
and one in `Host`. init() would be called twice as well

Particularly, I'm dealing with golang.org/x/net/trace package, which 
actually registers an endpoint /debug/requests. The second attempt would 
panic because of double-registration.

I'd appreciate any advice on how to manage common dependencies of plugin 
and main project, thank you!

- J

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

[go-nuts] golang tcp transport just like nc

[suconghou]

linux nc command port to golang 


in nc , we can do this

echo 'my id is 1' > /tmp/1
echo 'my id is 3' > /tmp/3
rm -rf /tmp/2 /tmp/4



server

nc -l 19090 < /tmp/1 > /tmp/2

( if you are in linux not mac this may be  ` nc -l -p 19090 `  )

client


nc 127.0.0.1 19090 < /tmp/3 > /tmp/4


when finish ,both server and client will be closed

client send /tmp/3 is saved by server to /tmp/2

server send /tmp/1 is saved by server to /tmp/4

then use golang do the same thing , but when finished , both server and 
client can not closed automaticly



echo 'my id is 1' > /tmp/1
echo 'my id is 3' > /tmp/3
rm -rf /tmp/2 /tmp/4





./nc serer < /tmp/1 > /tmp/2



./nc  < /tmp/3 > /tmp/4



please help me how to solve this and works like nc 


example code 

https://gist.github.com/suconghou/a1bfab9a30b3408400b6382d73051227



-- 
You received this message because you are subscribed 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: [ANN] Get Programming with Go

[Nathan Youngman]

Hi Matthew,

First of all, thanks for looking at the free chapters and providing
feedback.

I think I should reword the paragraph about the data centre, because there
is what Go was initially announced as, and then there is the niche that it
now occupies -- the later being predominately network services that tend to
run in data centres (65% according to
https://blog.golang.org/survey2017-results).

I'm not sure if "in English" really describes Go. Languages like Ruby
purport to offer English-like syntax (see "Beautiful Code: Leading
Programmers Explain How They Think") through metaprogramming tricks. On the
other hand, Go strives for simplicity and, in my opinion, clarity -- even
at the cost of verbosity in some cases. Whereas Ruby "reads like an essay",
code written in Go "does what it says."

The book layout isn't final, as it's still in early access. I think it will
look much nicer after it goes through the production phase -- finger's
crossed. A fair amount of that is outside of my control as the author. Even
the book cover is out of my hands, though I can and have given the
publisher feedback.

As far as competition, the only book that comes to mind as
beginner-oriented is Caleb Doxsey's "Introducing Go" published through
O'Reilly. There may be others that I'm not aware of.
http://shop.oreilly.com/product/0636920046516.do I'm not sure if either
Caleb's book or ours is suitable for the absolute beginner. Learning
something like Scratch may be advisable first, to get the concepts down.

Nathan.

P.S. If you decide to buy a copy or recommend it to others, the discount
code *39youngman* will give 39% off either the paper book or ebook. Also,
my affiliate link earns me a few bucks: https://bit.ly/programminggo


On 7 March 2018 at 09:02,  wrote:

> Go is designed for the modern data center, but its adoption isn’t
>> restricted to the workplace.
>
>
> While the garbage collector may point to this, and I’ve previously argued
> about data centers stepping on other applications’ feet, my understanding
> is the stated goal is systems programming. This term encompasses anything
> designed as part of a larger system in my mind; OS drivers and components
> have been mentioned, the compiler is written in Go, build and other scripts
> are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned
> embedded programming, small web servers with database definitely work, and
> of course data center applications and infrastructure are a major Go target
> and consumer.
>
> Perhaps something like “Go is designed for programming modern computers
> and computer systems in English” would be more accurate?
>
> I’ve only looked at the three free chapters, but one thing that stands out
> to me is the amount of formatting on each page. Although I’m looking on a
> computer and not at a book, it seems that all of the italics, bolds,
> blocks, lines, references, pictures, and other formatting add noise. I do
> think the graphics are creative, slicing the solar system is great.
>
> It’s been asked here about references for new programmers but I didn’t
> have an answer besides “what do you want to know?”. Can you share your
> competition here? I’ll mention “Get Programming with Go” in the future.
>
> Thanks,
> Matt
>
> On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>>
>> Learn about error handling and concurrent state in the latest release of
>> Get Programming with Go, available from Manning Books.
>>
>> The first draft is complete. If you have any feedback, now’s the time to
>> get it in, as we are currently editing the book before it goes to
>> production.
>>
>> https://bit.ly/programminggo
>>
>>
>> --
> 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/_-35shjZqUU/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.
>



-- 
Nathan Youngman
Email: he...@nathany.com
Web: https://nathany.com

-- 
You received this message because you are subscribed 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: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[digg]

On Wednesday, March 7, 2018 at 6:02:58 PM UTC-5, Ian Lance Taylor wrote:
>
> On Wed, Mar 7, 2018 at 1:36 PM,  > 
> wrote: 
> > 
> > On Wednesday, March 7, 2018 at 4:26:19 PM UTC-5, di...@veryhaha.com 
> wrote: 
> >> 
> >> get it almost. 
> >> 
> >> But I feel 
> >> 
> >> var v = float32(1< >> is a little different to 
> >> var v float32 = 1< >> 
> >> 
> >> For the former one, we think "1" can be assumed as an "int". 
> >> But anyway, I get the main point of the design. 
> >> It is just a wording accuracy problem. 
> >> 
> > 
> > On the other hand, any bad if "1" is deduced as an "int" value? 
>
> If we ignore the type context, then 
>
> var v int64 = 1 << s 
>
> fails on 32-bit systems if s > 31 (because 1 is assigned type int, 
> which is 32 bits, and the shifting a 32-bit value by more than 31 bits 
> gives you zero). 
>
> If we don't ignore the type context, then in 
>
> var v float32 = 1 << s 
>
> fails because we can't shift a float32. 
>
> We could ignore the type context for float types but not for integer 
> types, but then the rule is even more complicated. 
>
> Ian 
>
>
>
Good design.
Thanks for the explanation.
 

>
>
> >> On Wednesday, March 7, 2018 at 3:59:48 PM UTC-5, Ian Lance Taylor 
> wrote: 
> >>> 
> >>> On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler 
> >>>  wrote: 
> >>> > Looks suspicious. Without crosschecking the Spec: Might be 
> >>> > a bug.  File an issue? 
> >>> 
> >>> It's not a bug.  See Andrey's reply. 
> >>> 
> >>> Ian 
> >>> 
> >>> 
> >>> 
> >>> > On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com 
> wrote: 
> >>> >> 
> >>> >> var s uint = 33 
> >>> >> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot 
> shift 
> >>> > 
> >>> > -- 
> >>> > You received this message because you are subscribed to the Google 
> >>> > Groups 
> >>> > "golang-nuts" group. 
> >>> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >>> > an 
> >>> > email to golang-nuts...@googlegroups.com. 
> >>> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

[go-nuts] Re: go get does not create folder

[whitaker]

Ok Basically I reinstalled Git and allowed some more functionality in the 
windows cmd terminal. Seems to work now.


On Wednesday, March 7, 2018 at 4:00:13 PM UTC-7, Matt Whitaker wrote:
>
> Hi
>
> Total newbie question but I ave go installed and all the basic hello world 
> example are working fine. 
>
> However when I use go get to get a remote folder it will not create the 
> folders.
>
> So I'm doing
> go get github.com/golang/example/hello
>
> and get this
>  cd .; git clone https://github.com/golang/example C:\GoWork\src\
> github.com\golang\example
> package github.com/golang/example/hello: exit status 3221225595
>
> The folders under golang are not created.
>
> What am I doing wrong?
>
> Thanks
>
>
>

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

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[Ian Lance Taylor]

On Wed, Mar 7, 2018 at 1:36 PM,   wrote:
>
> On Wednesday, March 7, 2018 at 4:26:19 PM UTC-5, di...@veryhaha.com wrote:
>>
>> get it almost.
>>
>> But I feel
>>
>> var v = float32(1<> is a little different to
>> var v float32 = 1<>
>>
>> For the former one, we think "1" can be assumed as an "int".
>> But anyway, I get the main point of the design.
>> It is just a wording accuracy problem.
>>
>
> On the other hand, any bad if "1" is deduced as an "int" value?

If we ignore the type context, then

var v int64 = 1 << s

fails on 32-bit systems if s > 31 (because 1 is assigned type int,
which is 32 bits, and the shifting a 32-bit value by more than 31 bits
gives you zero).

If we don't ignore the type context, then in

var v float32 = 1 << s

fails because we can't shift a float32.

We could ignore the type context for float types but not for integer
types, but then the rule is even more complicated.

Ian




>> On Wednesday, March 7, 2018 at 3:59:48 PM UTC-5, Ian Lance Taylor wrote:
>>>
>>> On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler
>>>  wrote:
>>> > Looks suspicious. Without crosschecking the Spec: Might be
>>> > a bug.  File an issue?
>>>
>>> It's not a bug.  See Andrey's reply.
>>>
>>> Ian
>>>
>>>
>>>
>>> > On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com wrote:
>>> >>
>>> >> var s uint = 33
>>> >> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to golang-nuts...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] go get does not create folder

[MLW]

Hi

Total newbie question but I ave go installed and all the basic hello world 
example are working fine. 

However when I use go get to get a remote folder it will not create the 
folders.

So I'm doing
go get github.com/golang/example/hello

and get this
 cd .; git clone https://github.com/golang/example 
C:\GoWork\src\github.com\golang\example
package github.com/golang/example/hello: exit status 3221225595

The folders under golang are not created.

What am I doing wrong?

Thanks


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

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[Michael Jones]

of course you can force it:
https://play.golang.org/p/QIWDeMDJlAq

On Wed, Mar 7, 2018 at 1:36 PM,  wrote:

>
>
> On Wednesday, March 7, 2018 at 4:26:19 PM UTC-5, di...@veryhaha.com wrote:
>>
>> get it almost.
>>
>> But I feel
>>
>> var v = float32(1<> is a little different to
>> var v float32 = 1<>
>>
>> For the former one, we think "1" can be assumed as an "int".
>> But anyway, I get the main point of the design.
>> It is just a wording accuracy problem.
>>
>>
> On the other hand, any bad if "1" is deduced as an "int" value?
>
>
>>
>>
>> On Wednesday, March 7, 2018 at 3:59:48 PM UTC-5, Ian Lance Taylor wrote:
>>>
>>> On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler
>>>  wrote:
>>> > Looks suspicious. Without crosschecking the Spec: Might be
>>> > a bug.  File an issue?
>>>
>>> It's not a bug.  See Andrey's reply.
>>>
>>> Ian
>>>
>>>
>>>
>>> > On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com wrote:
>>> >>
>>> >> var s uint = 33
>>> >> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> > email to golang-nuts...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

-- 
You received this message because you are subscribed 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: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[digg]

On Wednesday, March 7, 2018 at 4:26:19 PM UTC-5, di...@veryhaha.com wrote:
>
> get it almost.
>
> But I feel
>
> var v = float32(1< is a little different to
> var v float32 = 1<
>
> For the former one, we think "1" can be assumed as an "int".
> But anyway, I get the main point of the design.
> It is just a wording accuracy problem.
>
>
On the other hand, any bad if "1" is deduced as an "int" value?
 

>
>
> On Wednesday, March 7, 2018 at 3:59:48 PM UTC-5, Ian Lance Taylor wrote:
>>
>> On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler 
>>  wrote: 
>> > Looks suspicious. Without crosschecking the Spec: Might be 
>> > a bug.  File an issue? 
>>
>> It's not a bug.  See Andrey's reply. 
>>
>> Ian 
>>
>>
>>
>> > On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com wrote: 
>> >> 
>> >> var s uint = 33 
>> >> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "golang-nuts" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to golang-nuts...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

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

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[digg]

get it almost.

But I feel

var v = float32(1<
> On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler 
> > wrote: 
> > Looks suspicious. Without crosschecking the Spec: Might be 
> > a bug.  File an issue? 
>
> It's not a bug.  See Andrey's reply. 
>
> Ian 
>
>
>
> > On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com wrote: 
> >> 
> >> var s uint = 33 
> >> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [go-nuts] Re: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[Ian Lance Taylor]

On Wed, Mar 7, 2018 at 12:54 PM, Volker Dobler
 wrote:
> Looks suspicious. Without crosschecking the Spec: Might be
> a bug.  File an issue?

It's not a bug.  See Andrey's reply.

Ian



> On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com wrote:
>>
>> var s uint = 33
>> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift
>
> --
> You received this message because you are subscribed 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: why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[Volker Dobler]

Looks suspicious. Without crosschecking the Spec: Might be
a bug.  File an issue?

V.

On Wednesday, 7 March 2018 21:39:32 UTC+1, di...@veryhaha.com wrote:
>
> var s uint = 33
> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift
>

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

Re: [go-nuts] why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[andrey mirtchovski]

the answer is hidden in the spec, i believe (it's not easy to parse,
so i suggest reading the whole thing):

"The right operand in a shift expression must have unsigned integer
type or be an untyped constant representableby a value of type uint.
If the left operand of a non-constant shift expression is an untyped
constant, it is first converted to the type it would assume if the
shift expression were replaced by its left operand alone."

https://golang.org/ref/spec#Operators

and then in the section Constant Expressions:

"A constant comparison always yields an untyped boolean constant. If
the left operand of a constant shift expression is an untyped
constant, the result is an integer constant; otherwise it is a
constant of the same type as the left operand, which must be of
integer type."

https://golang.org/ref/spec#Constant_expressions

I believe an example of your case as an "illegal" in the section
Operators will be beneficial.

On Wed, Mar 7, 2018 at 1:39 PM,   wrote:
> var s uint = 33
> var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift
>
> --
> You received this message because you are subscribed 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] Call for Papers: ManLang 2018 (Sept. 10-14, Linz, Austria)

[manl...@jku.at]

CALL FOR PAPERS

15th International Conference on Managed Languages & Runtimes (ManLang'18)

September 10-14, 2018, Linz, Austria

http://ssw.jku.at/manlang18/ 



ManLang (formerly PPPJ) is a premier forum for presenting and discussing 
novel results in all aspects of managed programming languages and runtime 
systems, which serve as building blocks for some of the most important 
computing systems, ranging from small-scale (embedded and real-time 
systems) to large-scale (cloud-computing and big-data platforms) and 
anything in between (mobile, IoT, and wearable applications).

==
Topics
==

Topics of interest include but are not limited to:

Languages and Compilers
---
- Managed languages (e.g., Java, Scala, JavaScript, Python, Ruby, C#, F#, 
Clojure, Groovy, Kotlin, R, Smalltalk, Racket, Rust, Go, etc.)
- Domain-specific languages
- Language design
- Compilers and interpreters
- Type systems and program logics
- Language interoperability
- Parallelism, distribution, and concurrency

Virtual Machines

- Managed runtime systems (e.g., JVM, Dalvik VM, Android Runtime (ART), 
LLVM, .NET CLR, RPython, etc.)
- VM design and optimization
- VMs for mobile and embedded devices
- VMs for real-time applications
- Memory management
- Hardware/software co-design

Techniques, Tools, and Applications
---
- Static and dynamic program analysis
- Testing and debugging
- Refactoring
- Program understanding
- Program synthesis
- Security and privacy
- Performance analysis and monitoring
- Compiler and program verification

===
Important Dates
===

Submission: May 4, 2018 (Abstracts: April 27)
Notification: July 6, 2018
Camera-ready version: August 3, 2018
Poster submission: August 6, 2018
Poster notification: August 13, 2018
Conference: September 10-14, 2018

==
Submission and Proceedings
==

Submissions to the conference will be evaluated on the basis of 
originality, relevance, technical soundness and presentation quality. 
Papers should be written in English and not exceed 12 pages in ACM format 
for full papers (6 pages for WiP, industry, and tool papers). You can also 
submit posters, which can be accompanied by a one-page abstract, and are 
due on August 6, 2018. The conference proceedings will be published as part 
of the ACM International Conference Proceedings Series and will be 
disseminated through the ACM Digital Library.

See the conference homepage for details on paper formats and submission.


Organization


General Chair:
Hanspeter Mössenböck, Johannes Kepler University Linz, Austria

Program Chair:
Eli Tilevich, Virginia Tech, USA

Steering Committee:
Walter Binder, University of Lugano (USI), Switzerland
Bruce Childers, University of Pittsburgh, USA
Martin Pluemicke, DHBW Stuttgart, Germany
Christian Probst, Technical University of Denmark, Denmark
Petr Tuma, Charles University, Czech Republic
Thomas Würthinger, Oracle Labs, Switzerland

Program Committee:
Godmar Back, Virginia Tech, USA
Clement Bera, INRIA, France
Christoph Bockisch, Philipps Universität Marburg, Germany
Man Cao, Google, USA
Shigeru Chiba, University of Tokyo, Japan
Yvonne Coady, University of Victoria, Canada
Julian Dolby, IBM Research, USA
Patrick Eugster, University of Lugano, Switzerland
Irene Finocchi, Sapienza University of Rome, Italy
Görel Hedin, Lund University, Sweden
Robert Hirschfeld, Hasso Plattner Institute, Germany
Tony Hosking, Purdue University, USA
Doug Lea, SUNY Oswego, USA
Eliot Moss, University of Massachusetts, USA
Nate Nystrom, University of Lugano, Switzerland
Tiark Rompf, Purdue University, USA
Jennifer B. Sartor, Vrije Universiteit Brussel, Belgium
Jeremy Singer, University of Glasgow, UK
Petr Tuma, Charles University, Czech Republic
Jan Vitek, Northeastern University, USA
Christian Wimmer, Oracle Labs, USA
Jianjun Zhao, Kyushu University, Japan


Location


Linz, the capital of Upper Austria, is both a city of culture and of 
industry. Located at the Danube it features a historic downtown and a 
modern university campus just north of the Danube, where the conference 
will take place. For information on JKU and Linz, also see: 
http://www.jku.at, https://en.wikipedia.org/wiki/Linz and 
https://www.linz.at/english/ 

=
Other Information
=

The 5th Virtual Machine Meetup (VMM) is a collocated event with ManLang 
'18. It is a venue for discussing the latest research and developments in 
the area of managed language execution.

ManLang'18 is organized in cooperation with ACM, ACM SIGPLAN and ACM ICPS, 
and is sponsored by the JKU Department of Computer Science, Oracle Labs, 
and Linz AG.

http://ssw.jku.at/ma

[go-nuts] why is the "1" in the code demoed in Go spec deduced as a "float64" value instead of an "int" value?

[digg]

var s uint = 33
var u2 = float64(1>>s)   // illegal: 1 has type float64, cannot shift

-- 
You received this message because you are subscribed 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] Get Programming with Go

[matthewjuran]

>
> Go is designed for the modern data center, but its adoption isn’t 
> restricted to the workplace. 


While the garbage collector may point to this, and I’ve previously argued 
about data centers stepping on other applications’ feet, my understanding 
is the stated goal is systems programming. This term encompasses anything 
designed as part of a larger system in my mind; OS drivers and components 
have been mentioned, the compiler is written in Go, build and other scripts 
are easy to write in Go, OS CLI tools are great in Go, you’ve mentioned 
embedded programming, small web servers with database definitely work, and 
of course data center applications and infrastructure are a major Go target 
and consumer.

Perhaps something like “Go is designed for programming modern computers and 
computer systems in English” would be more accurate?

I’ve only looked at the three free chapters, but one thing that stands out 
to me is the amount of formatting on each page. Although I’m looking on a 
computer and not at a book, it seems that all of the italics, bolds, 
blocks, lines, references, pictures, and other formatting add noise. I do 
think the graphics are creative, slicing the solar system is great.

It’s been asked here about references for new programmers but I didn’t have 
an answer besides “what do you want to know?”. Can you share your 
competition here? I’ll mention “Get Programming with Go” in the future.

Thanks,
Matt

On Wednesday, March 7, 2018 at 8:46:58 AM UTC-6, Nathan Youngman wrote:
>
> Learn about error handling and concurrent state in the latest release of 
> Get Programming with Go, available from Manning Books.
>
> The first draft is complete. If you have any feedback, now’s the time to 
> get it in, as we are currently editing the book before it goes to 
> production.
>
> https://bit.ly/programminggo
>
>
>

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

[go-nuts] [ANN] Get Programming with Go

[Nathan Youngman]

Learn about error handling and concurrent state in the latest release of 
Get Programming with Go, available from Manning Books.

The first draft is complete. If you have any feedback, now’s the time to 
get it in, as we are currently editing the book before it goes to 
production.

https://bit.ly/programminggo


-- 
You received this message because you are subscribed 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] Is there any equivalent `fork` in Golang?

[gansteed]

thanks

Lutz Horn 于2018年3月7日周三 下午7:40写道：

> > hello, is there any replacement for `fork` syscall in Golang?
>
> See https://stackoverflow.com/a/28371586
>
> > Note that fork() has been invented at the time when no threads were
> > used at all, and a process had always had just a single thread of
> > execution in it, and hence forking it was safe. With Go, the situation
> > is radically different as it heavily uses OS-level threads to power its
> > goroutine scheduling.
>
> Regards
>
> Lutz
>
> --
> 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/0Th87sxlzOE/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] Is there any equivalent `fork` in Golang?

[Lutz Horn]

hello, is there any replacement for `fork` syscall in Golang?


See https://stackoverflow.com/a/28371586

Note that fork() has been invented at the time when no threads were 
used at all, and a process had always had just a single thread of 
execution in it, and hence forking it was safe. With Go, the situation 
is radically different as it heavily uses OS-level threads to power its 
goroutine scheduling.


Regards

Lutz

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

[go-nuts] Is there any equivalent `fork` in Golang?

[Jiajun Huang]

hello, is there any replacement for `fork` syscall in Golang?

I've found:

- exec.Command
- syscall.ForkExec

but `exec.Command` can only execute a out side command.

syscall.ForkExec is needless, because what I need is `fork` only.

just like the C-way, fork, and return pid, then I entry different function. 
Is there any solution?

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

Re: [go-nuts] best practices of client middleware

[Jakob Borg]

I haven’t written anything like that, I’m merely offering a suggestion on why 
the docs say not to do it.

On 7 Mar 2018, at 09:28, eyal mailto:pose...@gmail.com>> 
wrote:

In your tests in the round-trippers you do change the requests, as far as i can 
see.

On Wed, Mar 7, 2018 at 10:13 AM Jakob Borg 
mailto:ja...@kastelo.net>> wrote:
On 7 Mar 2018, at 08:07, Eyal Posener 
mailto:pose...@gmail.com>> wrote:
>
> Very Nice stuff - shame he didn't merge it.
> But I see that you changes the request in the RoundTrip function, which is 
> claimed as forbidden in the docs.
> Again, I don't understand why the docs forbid it…

I expect that this is so that the user of the HTTP client API can reasonably 
reuse a *http.Request. If the RoundTripper where allowed to change it then it 
might have different URL, headers, method etc when the request is completed and 
you’d have to recreate it again from scratch.

//jb


--

sent from the milky way

--
You received this message because you are subscribed 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] best practices of client middleware

[eyal]

In your tests in the round-trippers you do change the requests, as far as i
can see.

On Wed, Mar 7, 2018 at 10:13 AM Jakob Borg  wrote:

> On 7 Mar 2018, at 08:07, Eyal Posener  wrote:
> >
> > Very Nice stuff - shame he didn't merge it.
> > But I see that you changes the request in the RoundTrip function, which
> is claimed as forbidden in the docs.
> > Again, I don't understand why the docs forbid it…
>
> I expect that this is so that the user of the HTTP client API can
> reasonably reuse a *http.Request. If the RoundTripper where allowed to
> change it then it might have different URL, headers, method etc when the
> request is completed and you’d have to recreate it again from scratch.
>
> //jb
>
>
> --

sent from the milky way

-- 
You received this message because you are subscribed 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] best practices of client middleware

[Jakob Borg]

On 7 Mar 2018, at 08:07, Eyal Posener  wrote:
> 
> Very Nice stuff - shame he didn't merge it.
> But I see that you changes the request in the RoundTrip function, which is 
> claimed as forbidden in the docs.
> Again, I don't understand why the docs forbid it…

I expect that this is so that the user of the HTTP client API can reasonably 
reuse a *http.Request. If the RoundTripper where allowed to change it then it 
might have different URL, headers, method etc when the request is completed and 
you’d have to recreate it again from scratch.

//jb


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