Re: [go-nuts] Possible issue with math.Floor on Linux

[Andrei Avram]

Yes, this could be it. First I was fooled by println rounding 2.9 to 3, 
thinking floor is not working properly on Linux.

Thanks!

On Saturday, May 5, 2018 at 1:49:34 AM UTC+3, Steven Hartland wrote:
>
> You could be seeing a side effect on fact that windows only ticks every 
> 15ms.
>
> On Fri, 4 May 2018 at 21:56, Andrei Avram  > wrote:
>
>> This code is extracted from something real. Someone on the team noticed 
>> the unit tests (which I wrote on a Linux machine) were failing on their 
>> Windows machine.
>> I'll continue studying this and come back if I find something new.
>>
>> Thank you both for your time, I appreciate it!
>>
>>
>> On Friday, May 4, 2018 at 11:42:00 PM UTC+3, speter wrote:
>>
>>> To file a bug (and have it treated seriously) you would need to 
>>> demonstrate that it is causing problems in a program that actually does 
>>> something useful, not just a pathological code sample. My expectation would 
>>> be that once you start doing some real processing, the difference between 
>>> time.Now() invocations becomes non-zero, that is this "issue" doesn't 
>>> reproduce with "real" practical programs.
>>>
>>>
>>> On Fri, May 4, 2018 at 10:26 PM, Andrei Avram  
>>> wrote:
>>>
 But I don't think it is because Windows is so much faster than Linux
>
  
 Yeah... :) I was exploring all cases.


  and/or the way the time package implemented is different between 
> Windows and Linux


 Could this be considered a possible Go bug and would it worth opening 
 an issue on Github?


 On Friday, May 4, 2018 at 10:57:46 PM UTC+3, speter wrote:
>
> So on Linux it's working as expected. In the playground time is 
> "virtual"; the start time is fixed and it doesn't progress unless you 
> explicitly Sleep -- because you don't Sleep in your program, time.Now() 
> returns the same time on both invocation.
>
> So the only slightly surprising part is that on Windows, time as 
> measured by time.Now() doesn't progress between the two statements. But I 
> don't think it is because Windows is so much faster than Linux. :) I'd 
> guess this is because the way Windows manages time is different from how 
> Linux manages it, and/or the way the time package implemented is 
> different 
> between Windows and Linux. The result of the cross-platform differences 
> seems to be less precision on Windows -- at least in this specific 
> scenario.
>
> Peter
>  
>
> On Fri, May 4, 2018 at 9:33 PM, Andrei Avram  
> wrote:
>
>> Peter and Ian, you are both wright regarding the printing. Still, on 
>> Linux I have different values than on Go Playground.
>>
>> Regarding the speed, Peter, do you think that on Windows the two 
>> calls just run faster every time?
>>
>> On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>>>
>>> b is slightly less than 3 because there is a bit of time between the 
>>> two calls to time.Now().
>>>
>>> If you substitute this:
>>> fmt.Printf("input: %20.18f\n", b)
>>>
>>> you get something like
>>> input: 2.99965553350911
>>>
>>> HTH
>>> Peter
>>>
>>> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram  
>>> wrote:
>>>
 Hello everyone,

 Today I ran into a situation that is strange to me. I ran the 
 following code on two Linux machines (go run floor.go), on two Windows 
 ones, and on Go Playground.

 package main

 import (
 "time"
 "math"
 )

 func main() {
 datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
 seconds := -1 * int(time.Now().Sub(datetime).Seconds())
 a := 29030400
 b := float64(seconds) / float64(a)

 println("input:", b)
 println("floor:", math.Floor(b))
 }

 On Linux the output is:

 input: +3.00e+000
 floor: *+2.00e+000*

 On Windows and Playground:

 input: +3.00e+000
 floor: *+3.00e+000*

 As you can see, on Linux the floor value of float value 3 is 
 rounded down to 2, while on Windows/Playground it's 3.

 The code was ran with Go 1.10 and 1.10.2.

 The system details of one of the Linux machines, as reported by "go 
 bug":

 go version go1.10.2 linux/amd64
 GOARCH="amd64"
 GOBIN=""
 GOCACHE="/home/msd/.cache/go-build"
 GOEXE=""
 GOHOSTARCH="amd64"
 GOHOSTOS="linux"
 GOOS="linux"
 GOPATH="/home/msd/go/"
 GORACE=""
 GOROOT="/usr/local/go"
 GOTMPDIR=""
 

[go-nuts] Re: I don't know about callbacks in Golang

[Krzysztof Kowalczyk]

You can read Essential Go (https://www.programming-books.io/essential/go/)

On Friday, May 4, 2018 at 5:53:13 PM UTC-7, Eduardo Moseis Fuentes wrote:
>
> HI everyone I´m Eduardo from Guatemala and I'm beginer. I'm  interesting 
> in all scope golang in fact  I was download a little book about it, but I 
> need learn more about callbacks because the book don´t has enough 
> information on callbacks. May somebody  tell me where can I  find more 
> information?. HELP ME PLEASE  THANKS God Bless 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.

[go-nuts] I don't know about callbacks in Golang

[Eduardo Moseis Fuentes]

HI everyone I´m Eduardo from Guatemala and I'm beginer. I'm  interesting in 
all scope golang in fact  I was download a little book about it, but I need 
learn more about callbacks because the book don´t has enough information on 
callbacks. May somebody  tell me where can I  find more information?. HELP 
ME PLEASE  THANKS God Bless 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.

[go-nuts] Re: Go routines hanging

[Michael Andersen]

When you say it hangs, do you mean that every single goroutine hangs or 
just some of them? If it is just some of them, I don't have any ideas, but 
you could try running with -race to catch deadlocks. If it is all of them 
then you might be running into a problem that I had where the GC suspends 
all goroutines waiting for an unpreemptable goroutine to finish. 

Try adding a goroutine that just prints "hello" and sleeps for a second in 
a loop. If that goroutine stops printing hello then it is very likely to be 
the problem I described.

On Friday, May 4, 2018 at 7:24:56 AM UTC-7, s...@whites.team wrote:
>
> Hi all,
>
> I'm having an issue with a messaging server I'm trying to write in Go (my 
> first real Go project). I'm having an issue that I've not come across 
> before in Go - the code executes as expected, then hangs after a second or 
> so indefinitely, no errors, no logs showing it's exited. The code is 
> available here 
> .
>  
> The functions of note are RedisWriteHandler and addRedisSender. In func 
> main I'm seeding a channel with the max amount of items (currently 100k) 
> then starting RedisWriteHandler, this should auto scale up and down 
> according to the length of the channel. However before it gets a chance to 
> scale down it hangs. I've checked with redis-cli and the senders are still 
> connected, but no more messages are coming though. Unfortunately I can't 
> replicate this in the go playground as it's never going to return, and it 
> will take too long and get kicked. I also asked this question here 
>  
> but it seems to have gone quiet.
>
> Based on comments from a couple other questions in this group I've killed 
> the process manually to get the stack trace which I'll attach, hopefully 
> this is helpful.
>
> Any thoughts would be greatly appreciated!
>
> Thanks,
>
> Sam
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

[Denis Cheremisov]

I meant true-false is not expected behaviour, true-true is what I would 
love to see.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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/types] Implements doesn't work for types from different packages when the interface signature has types from the package where the interface lies.

[Denis Cheremisov]

Hi!

I am writing a special linting-like piece of code and struggle dealing with 
the Implements  that doesn't 
work for my configuration. I made a simplified testing example to show the 
issue:


   - I have package speaker with interface Speaker and its default 
   implementation.
   
   package speaker
   type Default struct{}
   func (Default) Speak(Arg) string {
  return "speak"
   }
   type Arg struct{}
   type Speaker interface {
  Speak(Arg) string
   }
   
   - 
   
   Now, I have another package, with "Russian speaker":
   
   
   package ru
   import "awesome/speaker"
   type Russian struct{}
   func (Russian) Speak(speaker.Arg) string {
  return "говорить"
   }
   
   - 
   
   An finally I have a main package
   
   
   package main
   
   import (
  "fmt"
  "go/ast"
  "go/importer"
  "go/parser"
  "go/token"
  "go/types"
  "path/filepath"
  "runtime"
   )
   
   func getPath() string {
  fpcs := make([]uintptr, 5)
  frameIter := runtime.CallersFrames(fpcs[:runtime.Callers(1, fpcs)])
  var frames []runtime.Frame
  frame, more := frameIter.Next()
  frames = append(frames, frame)
  if !more {
 panic("stack frames must exists for a call")
  }
  return filepath.Dir(frame.File)
   }
   
   func getTypes(path ...string) *types.Package {
  path = append([]string{getPath()}, path...)
  fullpath := filepath.Join(path...)
  fset := token.NewFileSet()
  pkgs, err := parser.ParseDir(fset, fullpath, nil, parser.ParseComments)
  if err != nil {
 panic(err)
  }
  for _, pkg := range pkgs {
 config := {
IgnoreFuncBodies: false,
FakeImportC:  false,
Error:nil,
Importer: importer.Default(),
Sizes:nil,
DisableUnusedImportCheck: false,
 }
 info := types.Info{
Types: map[ast.Expr]types.TypeAndValue{},
Defs:  map[*ast.Ident]types.Object{},
Uses:  map[*ast.Ident]types.Object{},
 }
 var files []*ast.File
 for _, file := range pkg.Files {
files = append(files, file)
 }
 typeInfo, err := config.Check(fullpath, fset, files, )
 if err != nil {
panic(err)
 }
 return typeInfo
  }
  return nil
   }
   
   func main() {
  mainPkg := getTypes("speaker")
  ruPkg := getTypes("ru")
   
  iface := 
mainPkg.Scope().Lookup("Speaker").Type().Underlying().(*types.Interface)
  dflt := mainPkg.Scope().Lookup("Default").Type()
  russian := ruPkg.Scope().Lookup("Russian").Type()
   
  fmt.Println(types.Implements(dflt, iface))
  fmt.Println(types.Implements(russian, iface))
   }
   
   
Output is:
true
false

The output is true-true without the argument. Is it a feature or a bug? How 
can I walk around it?

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


package.tar.xz
Description: Binary data

Re: [go-nuts] Possible issue with math.Floor on Linux

[Steven Hartland]

You could be seeing a side effect on fact that windows only ticks every
15ms.

On Fri, 4 May 2018 at 21:56, Andrei Avram 
wrote:

> This code is extracted from something real. Someone on the team noticed
> the unit tests (which I wrote on a Linux machine) were failing on their
> Windows machine.
> I'll continue studying this and come back if I find something new.
>
> Thank you both for your time, I appreciate it!
>
>
> On Friday, May 4, 2018 at 11:42:00 PM UTC+3, speter wrote:
>
>> To file a bug (and have it treated seriously) you would need to
>> demonstrate that it is causing problems in a program that actually does
>> something useful, not just a pathological code sample. My expectation would
>> be that once you start doing some real processing, the difference between
>> time.Now() invocations becomes non-zero, that is this "issue" doesn't
>> reproduce with "real" practical programs.
>>
>>
>> On Fri, May 4, 2018 at 10:26 PM, Andrei Avram 
>> wrote:
>>
>>> But I don't think it is because Windows is so much faster than Linux

>>>
>>> Yeah... :) I was exploring all cases.
>>>
>>>
>>>  and/or the way the time package implemented is different between
 Windows and Linux
>>>
>>>
>>> Could this be considered a possible Go bug and would it worth opening an
>>> issue on Github?
>>>
>>>
>>> On Friday, May 4, 2018 at 10:57:46 PM UTC+3, speter wrote:

 So on Linux it's working as expected. In the playground time is
 "virtual"; the start time is fixed and it doesn't progress unless you
 explicitly Sleep -- because you don't Sleep in your program, time.Now()
 returns the same time on both invocation.

 So the only slightly surprising part is that on Windows, time as
 measured by time.Now() doesn't progress between the two statements. But I
 don't think it is because Windows is so much faster than Linux. :) I'd
 guess this is because the way Windows manages time is different from how
 Linux manages it, and/or the way the time package implemented is different
 between Windows and Linux. The result of the cross-platform differences
 seems to be less precision on Windows -- at least in this specific 
 scenario.

 Peter


 On Fri, May 4, 2018 at 9:33 PM, Andrei Avram 
 wrote:

> Peter and Ian, you are both wright regarding the printing. Still, on
> Linux I have different values than on Go Playground.
>
> Regarding the speed, Peter, do you think that on Windows the two calls
> just run faster every time?
>
> On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>>
>> b is slightly less than 3 because there is a bit of time between the
>> two calls to time.Now().
>>
>> If you substitute this:
>> fmt.Printf("input: %20.18f\n", b)
>>
>> you get something like
>> input: 2.99965553350911
>>
>> HTH
>> Peter
>>
>> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Today I ran into a situation that is strange to me. I ran the
>>> following code on two Linux machines (go run floor.go), on two Windows
>>> ones, and on Go Playground.
>>>
>>> package main
>>>
>>> import (
>>> "time"
>>> "math"
>>> )
>>>
>>> func main() {
>>> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
>>> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
>>> a := 29030400
>>> b := float64(seconds) / float64(a)
>>>
>>> println("input:", b)
>>> println("floor:", math.Floor(b))
>>> }
>>>
>>> On Linux the output is:
>>>
>>> input: +3.00e+000
>>> floor: *+2.00e+000*
>>>
>>> On Windows and Playground:
>>>
>>> input: +3.00e+000
>>> floor: *+3.00e+000*
>>>
>>> As you can see, on Linux the floor value of float value 3 is rounded
>>> down to 2, while on Windows/Playground it's 3.
>>>
>>> The code was ran with Go 1.10 and 1.10.2.
>>>
>>> The system details of one of the Linux machines, as reported by "go
>>> bug":
>>>
>>> go version go1.10.2 linux/amd64
>>> GOARCH="amd64"
>>> GOBIN=""
>>> GOCACHE="/home/msd/.cache/go-build"
>>> GOEXE=""
>>> GOHOSTARCH="amd64"
>>> GOHOSTOS="linux"
>>> GOOS="linux"
>>> GOPATH="/home/msd/go/"
>>> GORACE=""
>>> GOROOT="/usr/local/go"
>>> GOTMPDIR=""
>>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>>> GCCGO="gccgo"
>>> CC="gcc"
>>> CXX="g++"
>>> CGO_ENABLED="1"
>>> CGO_CFLAGS="-g -O2"
>>> CGO_CPPFLAGS=""
>>> CGO_CXXFLAGS="-g -O2"
>>> CGO_FFLAGS="-g -O2"
>>> CGO_LDFLAGS="-g -O2"
>>> PKG_CONFIG="pkg-config"
>>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
>>> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build

Re: [go-nuts] Implementing method overloading using first class functions

[Louki Sumirniy]

I sorta only vaguely understand what you mean about being 'too big'. I only 
have 4 comparators, 5 walk operators and a small collection maybe around 8 
helper functions. But now that I'm working with inter-convertible slice 
types, I don't have to do any interfaces in fact. I only have 5 types I 
actually need to use now, byte, uint8, 16, 32 and 64. I can use switch 
blocks to implement each one depending on the data being worked on. There 
won't be any package scoping issues either nor any closure scoping issues 
as I won't need to do this, the configurations in the main struct will be 
used as conditions in the switches.

Scoping and side effects from it were causing me huge headaches up to now. 
Data was not being read or written to the right locations and I couldn't 
figure out why, something to do with interfaces and package scoping I 
think. None of this will be a problem as I kinda don't even need to use 
type interfaces at all, I will try to avoid this. It's a very low level 
code I will be writing, something that will evoke halcyon days of assembly 
programming, but with GC, type safety and neat infix operators.

On Saturday, 5 May 2018 00:26:11 UTC+3, matthe...@gmail.com wrote:
>
> With byte slices you’ll need to pay attention to reallocation of the 
> backing array as a possible source of performance problems (
> https://blog.golang.org/go-slices-usage-and-internals).
>
> I can see clearly how freakin complex code gets when you try to do 
>> generics and polymorphism.
>
>
> I think it’s only complex because you’re not using the best possible 
> idioms. For example I mentioned in the other thread that I think your 
> interface is too big. Have you thought of other ways to do the typing?
>
> Perhaps try another language like Rust?
>
>
> I think Go could work.
>
> Matt
>
> On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>>
>> Perhaps try another language like Rust?
>>
>> atomly
>>
>> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy > > wrote:
>>
>>> Well after bashing my head against a brick wall I finally understand 
>>> what a mess it is for my specific purpose to work with Go. Nobody really 
>>> specifically said it in any discussions up to now but what my design needs 
>>> is generics. If code generation could be done more transparently I could 
>>> use that but it really kicks interactivity and flow in the nuts. I'm going 
>>> to probably abandon Golang on this basis. I am inclined to go with C but I 
>>> am nervous about  issues relating to pointers and runtime breaks but oh 
>>> well. . 
>>>
>>> If there was a way to transparently add code generation that would be 
>>> sufficient and remain type safe. *sigh*
>>>
>>> The biggest headache I am running up against is that between packages. I 
>>> think that before I throw in the towel I am going to study exactly how the 
>>> sort package is implemented, since in essence my library does the same 
>>> thing, so maybe I just don't understand well enough how to use interfaces, 
>>> embedding and composition.
>>>
>>>
>>> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:

 Yep, you are correct, more or less. My code is using interfaces and 
 panicking when it's fed the wrong thing.

 For example, in my test I had a literal number going into a write 
 function to put a value into a node in the tree. The insert implementation 
 panicked saying it couldn't put an int into a uint32 slot. Eventually I 
 worked out it was the assumed int typing of the literal causing the 
 problem 
 (happens all the time, I should be used to it by now).

 The thing is, it is intended that the user of the type specific library 
 that imports the tree library will not make a type assumption like the 
 compiler did about a literal. The type specific part has to be written for 
 any given type. There is a little verbosity in the part that wraps the 
 injected functions with syntactic sugar so the base library has the 
 functions to work on the concrete data agnostic of its content and only 
 the 
 return values provided by the functions it gets to do various comparisons 
 and whatnot. It's not excessively wordy for my tastes and I know it's 
 doing 
 it the best way possible.

 It's just learning how to play with interfaces that I was struggling 
 with and I seem to have pretty much got it all figured out now.  I'm happy 
 with how the code is developing and pretty much joyous that I can do this 
 inside a type safe language. Type safety is a big part of how Go is such a 
 fast compiling language. Implicit casts and inheritance have a massive 
 cost 
 in complexity not just a naive translation to binary code, but also in 
 optimising it. When can it cut out the dereferencing to methods and when 
 not? Since one could be using a method to do a relatively simple thing, in 
 very long, tight loops, if 

Re: [go-nuts] Implementing method overloading using first class functions

[Louki Sumirniy]

There won't be reallocations as I won't be resizing the pages. I think I 
have to think carefully about the sizes of the elements in the arrays, and 
when creating them pad them out if there is a remainder of space after the 
elements are allocated. I think I will probably work with, in fact, uint32 
elements in these arrays as this is a fairly optimal read/write size in 
most cpus, per throughput in some cases 64 bits is better. This will vary 
between CPUs, and sometimes it may be better to work with 64 bit elements.

Regarding the typing, I don't even need to concern myself with this if I am 
dealing with byte slices as an intermediate format in processing, they can 
be easily joined together to make 16, 32 and 64 bit integers (and these can 
also similarly be easily cut up and joined to other sizes as well). If 
there is strings or runes they also still fit neatly and easily convert to 
and from byte slices. Conversion will come at some cost but possibly I can 
algorithmically decide depending on the data size. 128 bit long elements 
would make more sense to read and write as 64 bit values, whereas 96 bits 
it would have to be 32 bits. Most likely conversions from byte slice inputs 
(as in from the hash functions) will only have to be done once and most of 
the computation will occur with larger integer sizes. 

This is the thing about slices, strings and maps in Go. They are already 
generics and have relatively easy convertibility between each other. The 
main concern will be ensuring that the byte slices are the right size. I 
saw in the binary library how to do some of  this with regards to bounds 
checking (minimising it) but I can also do checks using len().

On Saturday, 5 May 2018 00:26:11 UTC+3, matthe...@gmail.com wrote:
>
> With byte slices you’ll need to pay attention to reallocation of the 
> backing array as a possible source of performance problems (
> https://blog.golang.org/go-slices-usage-and-internals).
>
> I can see clearly how freakin complex code gets when you try to do 
>> generics and polymorphism.
>
>
> I think it’s only complex because you’re not using the best possible 
> idioms. For example I mentioned in the other thread that I think your 
> interface is too big. Have you thought of other ways to do the typing?
>
> Perhaps try another language like Rust?
>
>
> I think Go could work.
>
> Matt
>
> On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>>
>> Perhaps try another language like Rust?
>>
>> atomly
>>
>> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy > > wrote:
>>
>>> Well after bashing my head against a brick wall I finally understand 
>>> what a mess it is for my specific purpose to work with Go. Nobody really 
>>> specifically said it in any discussions up to now but what my design needs 
>>> is generics. If code generation could be done more transparently I could 
>>> use that but it really kicks interactivity and flow in the nuts. I'm going 
>>> to probably abandon Golang on this basis. I am inclined to go with C but I 
>>> am nervous about  issues relating to pointers and runtime breaks but oh 
>>> well. . 
>>>
>>> If there was a way to transparently add code generation that would be 
>>> sufficient and remain type safe. *sigh*
>>>
>>> The biggest headache I am running up against is that between packages. I 
>>> think that before I throw in the towel I am going to study exactly how the 
>>> sort package is implemented, since in essence my library does the same 
>>> thing, so maybe I just don't understand well enough how to use interfaces, 
>>> embedding and composition.
>>>
>>>
>>> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:

 Yep, you are correct, more or less. My code is using interfaces and 
 panicking when it's fed the wrong thing.

 For example, in my test I had a literal number going into a write 
 function to put a value into a node in the tree. The insert implementation 
 panicked saying it couldn't put an int into a uint32 slot. Eventually I 
 worked out it was the assumed int typing of the literal causing the 
 problem 
 (happens all the time, I should be used to it by now).

 The thing is, it is intended that the user of the type specific library 
 that imports the tree library will not make a type assumption like the 
 compiler did about a literal. The type specific part has to be written for 
 any given type. There is a little verbosity in the part that wraps the 
 injected functions with syntactic sugar so the base library has the 
 functions to work on the concrete data agnostic of its content and only 
 the 
 return values provided by the functions it gets to do various comparisons 
 and whatnot. It's not excessively wordy for my tastes and I know it's 
 doing 
 it the best way possible.

 It's just learning how to play with interfaces that I was struggling 
 with and I seem to have pretty much got 

[go-nuts] Re: Is there any #blog which writes about how to succeed as a fresher Go programmer?

[matthewjuran]

I’m assuming you’re asking how to make a career around Go.

For a career you might be best served by blogs about general software 
development or software engineering. Others here may be able to point you 
in the right direction for blogs. I’m not sure if “software” is still the 
best word for it.

Often these jobs will require ability to work in more than one programming 
language and with varying kinds of computing systems. Go is like a hammer 
and you probably won’t be hired as just a hammer operator.

A university might be the most straightforward career maker. I like 
electrical engineering specializing in computer programming, but computer 
science is another route to software work. Some universities may offer 
direct software degrees.

Being a software professional is not the only way to use programming, you 
may find Go or other languages help you with information work applied to 
another career.

Matt

On Friday, May 4, 2018 at 2:06:51 PM UTC-5, heyi...@gmail.com wrote:
>
> Is there any blog which writes about how to succeed as a new Go coder? 
>
> I mean: 
>
> - How should one learn Go and make his/her career? 
> - What should one do after learning Go? 
> - How should one get/find job as freshman Go programmer? 
> - and what skills should one have to land to his first Go programming Job 
> as starter? 
>
> Please suggest some good blogs if you know, because it will be very 
> helpful to me to follow the right way/track.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] GoKi Trees and GoGi GUI

[Randall O'Reilly]

Matt — thanks a ton for all the detailed comments!  Just quickly I figured out 
the git/hub steps to split out the top-level repositories into separate “ki” 
and “gi” repos, so the link and package paths are now:

https://github.com/goki/gi and ki

and hopefully this now works for the demo — just worked for me on my mac..

> go get github.com/goki/gi
> cd ~/go/src/github.com/goki/gi/examples/widgets
> go get ...
> go build
> ./widgets

More reactions later but just wanted to get that done so the paths should be 
stable now!  Cheers,

- Randy

> On May 4, 2018, at 9:09 AM, matthewju...@gmail.com wrote:
> 
> Hi Randy, here’s a code review.
> 
> Thanks for the BSD license.
> 
> I prefer the look of a minimized import path, I would have put the title 
> library at the top level (github.com/goki/ki).
> 
> To me the README doesn’t balance text and code examples well enough, I’d like 
> to see more example uses and less text. In package ki I’d hope the library 
> does enough work to not require so much README.
> 
> I think ki isn’t a bad package name after reading what it means but seeing 
> the package used in app code won’t show the point as obviously as an English 
> word for some people. tree.New() to me says “new data structure var” while 
> ki.New() says “I have to read the docs now”.
> 
> (when I say 'app' I mean a program that uses your library or a program 
> written to compile with a Go compiler; an application of the library, an 
> application of the Go programming language)
> 
> The Ki interface is a code smell to me. Usually I interpret library 
> interfaces as saying “the app provides an implementation of the interface and 
> the library provides shared logic that uses the interface methods” or in this 
> case I expect the ki lib will provide varying data structures and behaviors 
> that implement the ki var. Just reading down to line 42 of ki.go I feel like 
> this isn’t very Go-like.
> 
> You’re getting into generics territory with this:
> 
> func NewOfType(typ reflect.Type) Ki {
> 
> My view is idiomatic Go code tends to avoid this kind of thing due to 
> maintenance and readability burden. I haven’t used your lib but I am 
> concerned about it not being a big win over a per-app implementation. I can 
> see you’ve done a lot of work to make generics work.
> 
> In type Node I would consider embedding Props.
> 
> I haven’t looked at all of the methods but do the methods on Node need to be 
> to a pointer?
> 
> func (n *Node) Fields() []uintptr {
> 
> Seeing uintptr in a public method is a code smell to me.
> 
> In type Deleted consider maybe embedding sync.Mutex.
> 
> // fmt.Printf("finding path: %v\n", k.Path)
> 
> Instead of comments you may want to consider this pattern:
> 
> const debug = false
> …
> if debug {
> fmt.Printf("finding path: %v\n", k.Path)
> }
> 
> I think this library would be a good study for the Go 2 
> (https://blog.golang.org/toward-go2) generics effort, if you have time 
> consider writing an experience report and posting it: 
> https://github.com/golang/go/issues/15292
> 
> Perhaps consider embedding ki.Signal in gi.Action, and MakeMenuFunc, 
> ki.Signal, *Icon, and ButtonStates in ButtonBase, some fields in ColorView, 
> Dialog, FillStyle, FontStyle, LayoutStyle, LayoutData, Layout, MapView, 
> MapViewInline, Node2DBase, Paint, ImagePaintServer, SliceView, 
> SliceViewInline, SliderBase, SplitView, StrokeStyle, StructView, 
> StructViewInline, BorderStyle, ShadowStyle, Style, TabView, TextStyle, 
> TextField, SpinBox, ComboBox, TreeView, ValueViewBase, Viewport2D, Window. I 
> like to avoid any unnecessary field symbols.
> 
> These kinds of structs are a code smell to me:
> 
> type ColorValueView struct {
> ValueViewBase
> }
> 
> Why a Base type? Can your types be simpler?
> 
> type Node2D and type ValueView seem like other possible overuses of interface 
> to me. The size of type PaintServer is closer to what I’d expect with an 
> interface, and Labeler seems idiomatic.
> 
> I like the screenshot.
> 
> // check for interface implementation
> var _ Node2D = {}
> 
> I don’t like this pattern.
> 
> Given the amount of code and project maturity I wouldn’t expect you to make a 
> lot of changes, but I do think it could have been built with a stronger 
> resilience to change. Thanks for sharing here.
> 
> Matt
> 
> On Friday, May 4, 2018 at 5:39:35 AM UTC-5, Randall O'Reilly wrote:
> https://github.com/goki/goki — key demo in: 
> https://github.com/goki/goki/tree/master/gi/examples/widgets 
> 
> This is the first release of a new Go framework built around the Tree as a 
> core data structure (Ki = Tree in Japanese), which includes as its first 
> application a fully-native Go GUI (built on top of a modified version of the 
> Shiny OS-specific backend drivers, supporting Mac, Linux, and Windows so 
> far). 
> 
> Building on the central idea in Go that having a few powerful data-structures 
> is essential for making many problems easier to solve, the GoKi 

Re: [go-nuts] [ANN] GoKi Trees and GoGi GUI

[Wojciech S. Czarnecki]

On Fri, 4 May 2018 04:39:06 -0600
Randall O'Reilly  wrote:

> https://github.com/goki/goki — key demo in:
> https://github.com/goki/goki/tree/master/gi/examples/widgets
> 
> This is the first release of a new Go framework built around the Tree as a
> core data structure (Ki = Tree in Japanese),

Hats off! 

If even for trying/seeding.

#
Problems seen so far:

$ ./widgets 
2018/05/04 23:18:07 x11driver: no window found for event xproto.FocusOutEvent
^C

$ ./widgets 
FontLib: error accessing path "/usr/local/share/fonts":
lstat /usr/local/share/fonts: no such file or directory
FontLib: error walking the path "/usr/local/share/fonts":
lstat /usr/local/share/fonts: no such file or directory
2018/05/04 23:19:28 x11driver: no window found for event xproto.FocusOutEvent
^C
(This one likely stem from somewhere hardcoded path)


# github.com/goki/goki/gi/oswin/touch
goki/goki/gi/oswin/touch/touch.go:97:5: cannot use Event literal (type
*Event) as type oswin.Event in assignment:
*Event does not implement oswin.Event (missing HasPos method)
^C

> impressed with the language and ecosystem etc.  The contrast in complexity
> and build time between Qt and GoGi is really striking, and has kept me
> going despite the huge amount of effort it took to get this new project off
> the ground..

Such giant enterprise deserves a detailed blog post, IMO. In lines of other
"why I personally get to go from X/y/C++; what I do like and what I do not"
posts. 

Awaiting your goki brainchild to mature and flourish :)
 
> - Randy
> 

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

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

Re: [go-nuts] Implementing method overloading using first class functions

[matthewjuran]

With byte slices you’ll need to pay attention to reallocation of the 
backing array as a possible source of performance problems 
(https://blog.golang.org/go-slices-usage-and-internals).

I can see clearly how freakin complex code gets when you try to do generics 
> and polymorphism.


I think it’s only complex because you’re not using the best possible 
idioms. For example I mentioned in the other thread that I think your 
interface is too big. Have you thought of other ways to do the typing?

Perhaps try another language like Rust?


I think Go could work.

Matt

On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>
> Perhaps try another language like Rust?
>
> atomly
>
> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy  > wrote:
>
>> Well after bashing my head against a brick wall I finally understand what 
>> a mess it is for my specific purpose to work with Go. Nobody really 
>> specifically said it in any discussions up to now but what my design needs 
>> is generics. If code generation could be done more transparently I could 
>> use that but it really kicks interactivity and flow in the nuts. I'm going 
>> to probably abandon Golang on this basis. I am inclined to go with C but I 
>> am nervous about  issues relating to pointers and runtime breaks but oh 
>> well. . 
>>
>> If there was a way to transparently add code generation that would be 
>> sufficient and remain type safe. *sigh*
>>
>> The biggest headache I am running up against is that between packages. I 
>> think that before I throw in the towel I am going to study exactly how the 
>> sort package is implemented, since in essence my library does the same 
>> thing, so maybe I just don't understand well enough how to use interfaces, 
>> embedding and composition.
>>
>>
>> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>>>
>>> Yep, you are correct, more or less. My code is using interfaces and 
>>> panicking when it's fed the wrong thing.
>>>
>>> For example, in my test I had a literal number going into a write 
>>> function to put a value into a node in the tree. The insert implementation 
>>> panicked saying it couldn't put an int into a uint32 slot. Eventually I 
>>> worked out it was the assumed int typing of the literal causing the problem 
>>> (happens all the time, I should be used to it by now).
>>>
>>> The thing is, it is intended that the user of the type specific library 
>>> that imports the tree library will not make a type assumption like the 
>>> compiler did about a literal. The type specific part has to be written for 
>>> any given type. There is a little verbosity in the part that wraps the 
>>> injected functions with syntactic sugar so the base library has the 
>>> functions to work on the concrete data agnostic of its content and only the 
>>> return values provided by the functions it gets to do various comparisons 
>>> and whatnot. It's not excessively wordy for my tastes and I know it's doing 
>>> it the best way possible.
>>>
>>> It's just learning how to play with interfaces that I was struggling 
>>> with and I seem to have pretty much got it all figured out now.  I'm happy 
>>> with how the code is developing and pretty much joyous that I can do this 
>>> inside a type safe language. Type safety is a big part of how Go is such a 
>>> fast compiling language. Implicit casts and inheritance have a massive cost 
>>> in complexity not just a naive translation to binary code, but also in 
>>> optimising it. When can it cut out the dereferencing to methods and when 
>>> not? Since one could be using a method to do a relatively simple thing, in 
>>> very long, tight loops, if the OOP compiler guesses wrong and puts 
>>> dereferences in where they are not needed, it's a big cost over 1 million 
>>> iterations compared to being aware of it, like in my code, and avoiding the 
>>> need for dereferencing.
>>>
>>> I firmly believe that Go could replace C as a language to write systems 
>>> kernels in. I saw an amusing post recently relating to Dan Larimer's work 
>>> on EOS mentioning an automated code correctness checking application for 
>>> C++... Having intimately dealt with Dan's C++ source code, I can see why he 
>>> might be waking up to this, especially with the ether leaks going on, that 
>>> EOS has inherited (literally, I presume).
>>>
>>> This would not happen if it were written in Go. Note also that Geth 
>>> lacks this problem and there was almost going to be a split over code 
>>> changes from the Go side.
>>>
>>> Linus Torvalds famously said he wrote the Git CVS in C specifically to 
>>> exclude C++ programmers. But as any avid gopher would know, C has all kinds 
>>> of gotchas to do with busting out of stacks, heaps, allocated memory, and 
>>> forgetting to free memory. This does not happen in Go. 
>>>
>>> So to cut a long story short, this is why I choose to program in Go. I 
>>> have a background in low level programming, I used to do a bit of M68k 
>>> 

Re: [go-nuts] Possible issue with math.Floor on Linux

[Andrei Avram]

This code is extracted from something real. Someone on the team noticed the 
unit tests (which I wrote on a Linux machine) were failing on their Windows 
machine.
I'll continue studying this and come back if I find something new.

Thank you both for your time, I appreciate it!

On Friday, May 4, 2018 at 11:42:00 PM UTC+3, speter wrote:
>
> To file a bug (and have it treated seriously) you would need to 
> demonstrate that it is causing problems in a program that actually does 
> something useful, not just a pathological code sample. My expectation would 
> be that once you start doing some real processing, the difference between 
> time.Now() invocations becomes non-zero, that is this "issue" doesn't 
> reproduce with "real" practical programs.
>
>
> On Fri, May 4, 2018 at 10:26 PM, Andrei Avram  > wrote:
>
>> But I don't think it is because Windows is so much faster than Linux
>>>
>>  
>> Yeah... :) I was exploring all cases.
>>
>>
>>  and/or the way the time package implemented is different between Windows 
>>> and Linux
>>
>>
>> Could this be considered a possible Go bug and would it worth opening an 
>> issue on Github?
>>
>>
>> On Friday, May 4, 2018 at 10:57:46 PM UTC+3, speter wrote:
>>>
>>> So on Linux it's working as expected. In the playground time is 
>>> "virtual"; the start time is fixed and it doesn't progress unless you 
>>> explicitly Sleep -- because you don't Sleep in your program, time.Now() 
>>> returns the same time on both invocation.
>>>
>>> So the only slightly surprising part is that on Windows, time as 
>>> measured by time.Now() doesn't progress between the two statements. But I 
>>> don't think it is because Windows is so much faster than Linux. :) I'd 
>>> guess this is because the way Windows manages time is different from how 
>>> Linux manages it, and/or the way the time package implemented is different 
>>> between Windows and Linux. The result of the cross-platform differences 
>>> seems to be less precision on Windows -- at least in this specific scenario.
>>>
>>> Peter
>>>  
>>>
>>> On Fri, May 4, 2018 at 9:33 PM, Andrei Avram  
>>> wrote:
>>>
 Peter and Ian, you are both wright regarding the printing. Still, on 
 Linux I have different values than on Go Playground.

 Regarding the speed, Peter, do you think that on Windows the two calls 
 just run faster every time?

 On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>
> b is slightly less than 3 because there is a bit of time between the 
> two calls to time.Now().
>
> If you substitute this:
> fmt.Printf("input: %20.18f\n", b)
>
> you get something like
> input: 2.99965553350911
>
> HTH
> Peter
>
> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram  
> wrote:
>
>> Hello everyone,
>>
>> Today I ran into a situation that is strange to me. I ran the 
>> following code on two Linux machines (go run floor.go), on two Windows 
>> ones, and on Go Playground.
>>
>> package main
>>
>> import (
>> "time"
>> "math"
>> )
>>
>> func main() {
>> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
>> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
>> a := 29030400
>> b := float64(seconds) / float64(a)
>>
>> println("input:", b)
>> println("floor:", math.Floor(b))
>> }
>>
>> On Linux the output is:
>>
>> input: +3.00e+000
>> floor: *+2.00e+000*
>>
>> On Windows and Playground:
>>
>> input: +3.00e+000
>> floor: *+3.00e+000*
>>
>> As you can see, on Linux the floor value of float value 3 is rounded 
>> down to 2, while on Windows/Playground it's 3.
>>
>> The code was ran with Go 1.10 and 1.10.2.
>>
>> The system details of one of the Linux machines, as reported by "go 
>> bug":
>>
>> go version go1.10.2 linux/amd64
>> GOARCH="amd64"
>> GOBIN=""
>> GOCACHE="/home/msd/.cache/go-build"
>> GOEXE=""
>> GOHOSTARCH="amd64"
>> GOHOSTOS="linux"
>> GOOS="linux"
>> GOPATH="/home/msd/go/"
>> GORACE=""
>> GOROOT="/usr/local/go"
>> GOTMPDIR=""
>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>> GCCGO="gccgo"
>> CC="gcc"
>> CXX="g++"
>> CGO_ENABLED="1"
>> CGO_CFLAGS="-g -O2"
>> CGO_CPPFLAGS=""
>> CGO_CXXFLAGS="-g -O2"
>> CGO_FFLAGS="-g -O2"
>> CGO_LDFLAGS="-g -O2"
>> PKG_CONFIG="pkg-config"
>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build 
>> -gno-record-gcc-switches"
>> GOROOT/bin/go version: go version go1.10.2 linux/amd64
>> GOROOT/bin/go tool compile -V: compile version go1.10.2
>> uname -sr: Linux 4.13.0-37-generic
>> Distributor ID: Ubuntu
>> Description: Ubuntu 16.04.4 LTS
>> Release: 

Re: [go-nuts] Possible issue with math.Floor on Linux

[speter]

To file a bug (and have it treated seriously) you would need to demonstrate
that it is causing problems in a program that actually does something
useful, not just a pathological code sample. My expectation would be that
once you start doing some real processing, the difference between
time.Now() invocations becomes non-zero, that is this "issue" doesn't
reproduce with "real" practical programs.


On Fri, May 4, 2018 at 10:26 PM, Andrei Avram 
wrote:

> But I don't think it is because Windows is so much faster than Linux
>>
>
> Yeah... :) I was exploring all cases.
>
>
>  and/or the way the time package implemented is different between Windows
>> and Linux
>
>
> Could this be considered a possible Go bug and would it worth opening an
> issue on Github?
>
>
> On Friday, May 4, 2018 at 10:57:46 PM UTC+3, speter wrote:
>>
>> So on Linux it's working as expected. In the playground time is
>> "virtual"; the start time is fixed and it doesn't progress unless you
>> explicitly Sleep -- because you don't Sleep in your program, time.Now()
>> returns the same time on both invocation.
>>
>> So the only slightly surprising part is that on Windows, time as measured
>> by time.Now() doesn't progress between the two statements. But I don't
>> think it is because Windows is so much faster than Linux. :) I'd guess this
>> is because the way Windows manages time is different from how Linux manages
>> it, and/or the way the time package implemented is different between
>> Windows and Linux. The result of the cross-platform differences seems to be
>> less precision on Windows -- at least in this specific scenario.
>>
>> Peter
>>
>>
>> On Fri, May 4, 2018 at 9:33 PM, Andrei Avram 
>> wrote:
>>
>>> Peter and Ian, you are both wright regarding the printing. Still, on
>>> Linux I have different values than on Go Playground.
>>>
>>> Regarding the speed, Peter, do you think that on Windows the two calls
>>> just run faster every time?
>>>
>>> On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:

 b is slightly less than 3 because there is a bit of time between the
 two calls to time.Now().

 If you substitute this:
 fmt.Printf("input: %20.18f\n", b)

 you get something like
 input: 2.99965553350911

 HTH
 Peter

 On Fri, May 4, 2018 at 7:26 PM, Andrei Avram 
 wrote:

> Hello everyone,
>
> Today I ran into a situation that is strange to me. I ran the
> following code on two Linux machines (go run floor.go), on two Windows
> ones, and on Go Playground.
>
> package main
>
> import (
> "time"
> "math"
> )
>
> func main() {
> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
> a := 29030400
> b := float64(seconds) / float64(a)
>
> println("input:", b)
> println("floor:", math.Floor(b))
> }
>
> On Linux the output is:
>
> input: +3.00e+000
> floor: *+2.00e+000*
>
> On Windows and Playground:
>
> input: +3.00e+000
> floor: *+3.00e+000*
>
> As you can see, on Linux the floor value of float value 3 is rounded
> down to 2, while on Windows/Playground it's 3.
>
> The code was ran with Go 1.10 and 1.10.2.
>
> The system details of one of the Linux machines, as reported by "go
> bug":
>
> go version go1.10.2 linux/amd64
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/msd/.cache/go-build"
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/msd/go/"
> GORACE=""
> GOROOT="/usr/local/go"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build
> -gno-record-gcc-switches"
> GOROOT/bin/go version: go version go1.10.2 linux/amd64
> GOROOT/bin/go tool compile -V: compile version go1.10.2
> uname -sr: Linux 4.13.0-37-generic
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.4 LTS
> Release: 16.04
> Codename: xenial
> /lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC
> 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
> gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
>
>
> Is there something I miss or could this be an issue?
>
> Thanks,
> Andrei
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving 

Re: [go-nuts] Possible issue with math.Floor on Linux

[Andrei Avram]

>
> But I don't think it is because Windows is so much faster than Linux
>
 
Yeah... :) I was exploring all cases.


 and/or the way the time package implemented is different between Windows 
> and Linux


Could this be considered a possible Go bug and would it worth opening an 
issue on Github?


On Friday, May 4, 2018 at 10:57:46 PM UTC+3, speter wrote:
>
> So on Linux it's working as expected. In the playground time is "virtual"; 
> the start time is fixed and it doesn't progress unless you explicitly Sleep 
> -- because you don't Sleep in your program, time.Now() returns the same 
> time on both invocation.
>
> So the only slightly surprising part is that on Windows, time as measured 
> by time.Now() doesn't progress between the two statements. But I don't 
> think it is because Windows is so much faster than Linux. :) I'd guess this 
> is because the way Windows manages time is different from how Linux manages 
> it, and/or the way the time package implemented is different between 
> Windows and Linux. The result of the cross-platform differences seems to be 
> less precision on Windows -- at least in this specific scenario.
>
> Peter
>  
>
> On Fri, May 4, 2018 at 9:33 PM, Andrei Avram  > wrote:
>
>> Peter and Ian, you are both wright regarding the printing. Still, on 
>> Linux I have different values than on Go Playground.
>>
>> Regarding the speed, Peter, do you think that on Windows the two calls 
>> just run faster every time?
>>
>> On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>>>
>>> b is slightly less than 3 because there is a bit of time between the two 
>>> calls to time.Now().
>>>
>>> If you substitute this:
>>> fmt.Printf("input: %20.18f\n", b)
>>>
>>> you get something like
>>> input: 2.99965553350911
>>>
>>> HTH
>>> Peter
>>>
>>> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram  
>>> wrote:
>>>
 Hello everyone,

 Today I ran into a situation that is strange to me. I ran the following 
 code on two Linux machines (go run floor.go), on two Windows ones, and on 
 Go Playground.

 package main

 import (
 "time"
 "math"
 )

 func main() {
 datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
 seconds := -1 * int(time.Now().Sub(datetime).Seconds())
 a := 29030400
 b := float64(seconds) / float64(a)

 println("input:", b)
 println("floor:", math.Floor(b))
 }

 On Linux the output is:

 input: +3.00e+000
 floor: *+2.00e+000*

 On Windows and Playground:

 input: +3.00e+000
 floor: *+3.00e+000*

 As you can see, on Linux the floor value of float value 3 is rounded 
 down to 2, while on Windows/Playground it's 3.

 The code was ran with Go 1.10 and 1.10.2.

 The system details of one of the Linux machines, as reported by "go 
 bug":

 go version go1.10.2 linux/amd64
 GOARCH="amd64"
 GOBIN=""
 GOCACHE="/home/msd/.cache/go-build"
 GOEXE=""
 GOHOSTARCH="amd64"
 GOHOSTOS="linux"
 GOOS="linux"
 GOPATH="/home/msd/go/"
 GORACE=""
 GOROOT="/usr/local/go"
 GOTMPDIR=""
 GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
 GCCGO="gccgo"
 CC="gcc"
 CXX="g++"
 CGO_ENABLED="1"
 CGO_CFLAGS="-g -O2"
 CGO_CPPFLAGS=""
 CGO_CXXFLAGS="-g -O2"
 CGO_FFLAGS="-g -O2"
 CGO_LDFLAGS="-g -O2"
 PKG_CONFIG="pkg-config"
 GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
 -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build 
 -gno-record-gcc-switches"
 GOROOT/bin/go version: go version go1.10.2 linux/amd64
 GOROOT/bin/go tool compile -V: compile version go1.10.2
 uname -sr: Linux 4.13.0-37-generic
 Distributor ID: Ubuntu
 Description: Ubuntu 16.04.4 LTS
 Release: 16.04
 Codename: xenial
 /lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 
 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
 gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1


 Is there something I miss or could this be an issue?

 Thanks,
 Andrei

 -- 
 You received this message because you are subscribed 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 

Re: [go-nuts] Possible issue with math.Floor on Linux

[speter]

So on Linux it's working as expected. In the playground time is "virtual";
the start time is fixed and it doesn't progress unless you explicitly Sleep
-- because you don't Sleep in your program, time.Now() returns the same
time on both invocation.

So the only slightly surprising part is that on Windows, time as measured
by time.Now() doesn't progress between the two statements. But I don't
think it is because Windows is so much faster than Linux. :) I'd guess this
is because the way Windows manages time is different from how Linux manages
it, and/or the way the time package implemented is different between
Windows and Linux. The result of the cross-platform differences seems to be
less precision on Windows -- at least in this specific scenario.

Peter


On Fri, May 4, 2018 at 9:33 PM, Andrei Avram 
wrote:

> Peter and Ian, you are both wright regarding the printing. Still, on Linux
> I have different values than on Go Playground.
>
> Regarding the speed, Peter, do you think that on Windows the two calls
> just run faster every time?
>
> On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>>
>> b is slightly less than 3 because there is a bit of time between the two
>> calls to time.Now().
>>
>> If you substitute this:
>> fmt.Printf("input: %20.18f\n", b)
>>
>> you get something like
>> input: 2.99965553350911
>>
>> HTH
>> Peter
>>
>> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> Today I ran into a situation that is strange to me. I ran the following
>>> code on two Linux machines (go run floor.go), on two Windows ones, and on
>>> Go Playground.
>>>
>>> package main
>>>
>>> import (
>>> "time"
>>> "math"
>>> )
>>>
>>> func main() {
>>> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
>>> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
>>> a := 29030400
>>> b := float64(seconds) / float64(a)
>>>
>>> println("input:", b)
>>> println("floor:", math.Floor(b))
>>> }
>>>
>>> On Linux the output is:
>>>
>>> input: +3.00e+000
>>> floor: *+2.00e+000*
>>>
>>> On Windows and Playground:
>>>
>>> input: +3.00e+000
>>> floor: *+3.00e+000*
>>>
>>> As you can see, on Linux the floor value of float value 3 is rounded
>>> down to 2, while on Windows/Playground it's 3.
>>>
>>> The code was ran with Go 1.10 and 1.10.2.
>>>
>>> The system details of one of the Linux machines, as reported by "go bug":
>>>
>>> go version go1.10.2 linux/amd64
>>> GOARCH="amd64"
>>> GOBIN=""
>>> GOCACHE="/home/msd/.cache/go-build"
>>> GOEXE=""
>>> GOHOSTARCH="amd64"
>>> GOHOSTOS="linux"
>>> GOOS="linux"
>>> GOPATH="/home/msd/go/"
>>> GORACE=""
>>> GOROOT="/usr/local/go"
>>> GOTMPDIR=""
>>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>>> GCCGO="gccgo"
>>> CC="gcc"
>>> CXX="g++"
>>> CGO_ENABLED="1"
>>> CGO_CFLAGS="-g -O2"
>>> CGO_CPPFLAGS=""
>>> CGO_CXXFLAGS="-g -O2"
>>> CGO_FFLAGS="-g -O2"
>>> CGO_LDFLAGS="-g -O2"
>>> PKG_CONFIG="pkg-config"
>>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
>>> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build
>>> -gno-record-gcc-switches"
>>> GOROOT/bin/go version: go version go1.10.2 linux/amd64
>>> GOROOT/bin/go tool compile -V: compile version go1.10.2
>>> uname -sr: Linux 4.13.0-37-generic
>>> Distributor ID: Ubuntu
>>> Description: Ubuntu 16.04.4 LTS
>>> Release: 16.04
>>> Codename: xenial
>>> /lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC
>>> 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
>>> gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
>>>
>>>
>>> Is there something I miss or could this be an issue?
>>>
>>> Thanks,
>>> Andrei
>>>
>>> --
>>> You received this message because you are subscribed 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.

Re: [go-nuts] panic: runtime: unknown pc

[Ian Lance Taylor]

On Fri, May 4, 2018 at 12:12 PM, andrey mirtchovski
 wrote:
> It is unfortunately not reproducible. I got 2 crashes out of 500
> million executions. I've updated to tip and have not seen it since.

It is possible that it has been fixed on tip.  There have been fixes
in the right areas, such as https://golang.org/cl/107778.  With such
rare occurrences I guess it's hard to be sure, though.

Ian

> On Fri, May 4, 2018 at 12:14 PM, Ian Lance Taylor  wrote:
>> On Thu, May 3, 2018 at 11:39 PM, andrey mirtchovski
>>  wrote:
>>>
>>> I believe I've never encountered this nor seen anyone mention this
>>> error before. It occurred while fuzzing a C library that we interface
>>> with:
>>>
>>> PC=0x7fffbafc847c m=0 sigcode=0
>>>
>>> goroutine 0 [idle]:
>>> runtime: unknown pc 0x7fffbafc847c
>>> stack: frame={sp:0x7fff5fbff088, fp:0x0} 
>>> stack=[0x7fff5fb80888,0x7fff5fbff8f0)
>>>
>>> registers:
>>>
>>> rax0x200018d
>>> rbx0x7fffc3d971a8
>>> rcx0x7fff5fbff088
>>> rdx0x4000
>>> rdi0x1
>>> rsi0x4801000
>>> rbp0x7fff5fbff0b0
>>> rsp0x7fff5fbff088
>>> r8 0x6
>>> r9 0x7fffbaf18a50
>>> r100x72
>>> r110x246
>>> r120x0
>>> r130x7
>>> r140x4000
>>> r150x4801000
>>> rip0x7fffbafc847c
>>> rflags 0x246
>>> cs 0x7
>>> fs 0x0
>>> gs 0x0
>>>
>>> [full stack trace available upon request, it starts/ends with "cgocall"]
>>>
>>> i'm not sure even how to approach this. would that be a runtime issue?
>>> if you have any hints i'd be happy to listen :)
>>
>> This is a runtime issue.  Note that there have been some fixes for
>> this on tip.  If you have reproduction instructions, please open an
>> issue.  Thanks.
>>
>> 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] Possible issue with math.Floor on Linux

[Andrei Avram]

Peter and Ian, you are both wright regarding the printing. Still, on Linux 
I have different values than on Go Playground.

Regarding the speed, Peter, do you think that on Windows the two calls just 
run faster every time?

On Friday, May 4, 2018 at 9:07:15 PM UTC+3, speter wrote:
>
> b is slightly less than 3 because there is a bit of time between the two 
> calls to time.Now().
>
> If you substitute this:
> fmt.Printf("input: %20.18f\n", b)
>
> you get something like
> input: 2.99965553350911
>
> HTH
> Peter
>
> On Fri, May 4, 2018 at 7:26 PM, Andrei Avram  > wrote:
>
>> Hello everyone,
>>
>> Today I ran into a situation that is strange to me. I ran the following 
>> code on two Linux machines (go run floor.go), on two Windows ones, and on 
>> Go Playground.
>>
>> package main
>>
>> import (
>> "time"
>> "math"
>> )
>>
>> func main() {
>> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
>> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
>> a := 29030400
>> b := float64(seconds) / float64(a)
>>
>> println("input:", b)
>> println("floor:", math.Floor(b))
>> }
>>
>> On Linux the output is:
>>
>> input: +3.00e+000
>> floor: *+2.00e+000*
>>
>> On Windows and Playground:
>>
>> input: +3.00e+000
>> floor: *+3.00e+000*
>>
>> As you can see, on Linux the floor value of float value 3 is rounded down 
>> to 2, while on Windows/Playground it's 3.
>>
>> The code was ran with Go 1.10 and 1.10.2.
>>
>> The system details of one of the Linux machines, as reported by "go bug":
>>
>> go version go1.10.2 linux/amd64
>> GOARCH="amd64"
>> GOBIN=""
>> GOCACHE="/home/msd/.cache/go-build"
>> GOEXE=""
>> GOHOSTARCH="amd64"
>> GOHOSTOS="linux"
>> GOOS="linux"
>> GOPATH="/home/msd/go/"
>> GORACE=""
>> GOROOT="/usr/local/go"
>> GOTMPDIR=""
>> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
>> GCCGO="gccgo"
>> CC="gcc"
>> CXX="g++"
>> CGO_ENABLED="1"
>> CGO_CFLAGS="-g -O2"
>> CGO_CPPFLAGS=""
>> CGO_CXXFLAGS="-g -O2"
>> CGO_FFLAGS="-g -O2"
>> CGO_LDFLAGS="-g -O2"
>> PKG_CONFIG="pkg-config"
>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build 
>> -gno-record-gcc-switches"
>> GOROOT/bin/go version: go version go1.10.2 linux/amd64
>> GOROOT/bin/go tool compile -V: compile version go1.10.2
>> uname -sr: Linux 4.13.0-37-generic
>> Distributor ID: Ubuntu
>> Description: Ubuntu 16.04.4 LTS
>> Release: 16.04
>> Codename: xenial
>> /lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 
>> 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
>> gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
>>
>>
>> Is there something I miss or could this be an issue?
>>
>> Thanks,
>> Andrei
>>
>> -- 
>> You received this message because you are subscribed 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] panic: runtime: unknown pc

[andrey mirtchovski]

It is unfortunately not reproducible. I got 2 crashes out of 500
million executions. I've updated to tip and have not seen it since.

On Fri, May 4, 2018 at 12:14 PM, Ian Lance Taylor  wrote:
> On Thu, May 3, 2018 at 11:39 PM, andrey mirtchovski
>  wrote:
>>
>> I believe I've never encountered this nor seen anyone mention this
>> error before. It occurred while fuzzing a C library that we interface
>> with:
>>
>> PC=0x7fffbafc847c m=0 sigcode=0
>>
>> goroutine 0 [idle]:
>> runtime: unknown pc 0x7fffbafc847c
>> stack: frame={sp:0x7fff5fbff088, fp:0x0} 
>> stack=[0x7fff5fb80888,0x7fff5fbff8f0)
>>
>> registers:
>>
>> rax0x200018d
>> rbx0x7fffc3d971a8
>> rcx0x7fff5fbff088
>> rdx0x4000
>> rdi0x1
>> rsi0x4801000
>> rbp0x7fff5fbff0b0
>> rsp0x7fff5fbff088
>> r8 0x6
>> r9 0x7fffbaf18a50
>> r100x72
>> r110x246
>> r120x0
>> r130x7
>> r140x4000
>> r150x4801000
>> rip0x7fffbafc847c
>> rflags 0x246
>> cs 0x7
>> fs 0x0
>> gs 0x0
>>
>> [full stack trace available upon request, it starts/ends with "cgocall"]
>>
>> i'm not sure even how to approach this. would that be a runtime issue?
>> if you have any hints i'd be happy to listen :)
>
> This is a runtime issue.  Note that there have been some fixes for
> this on tip.  If you have reproduction instructions, please open an
> issue.  Thanks.
>
> Ian

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

[go-nuts] Is there any #blog which writes about how to succeed as a fresher Go programmer?

[heyimshub]

Is there any blog which writes about how to succeed as a new Go coder?

I mean:

- How should one learn Go and make his/her career?
- What should one do after learning Go?
- How should one get/find job as freshman Go programmer?
- and what skills should one have to land to his first Go programming Job as 
starter?

Please suggest some good blogs if you know, because it will be very helpful to 
me to follow the right way/track.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Implementing method overloading using first class functions

[atomly]

Perhaps try another language like Rust?

atomly

On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> Well after bashing my head against a brick wall I finally understand what
> a mess it is for my specific purpose to work with Go. Nobody really
> specifically said it in any discussions up to now but what my design needs
> is generics. If code generation could be done more transparently I could
> use that but it really kicks interactivity and flow in the nuts. I'm going
> to probably abandon Golang on this basis. I am inclined to go with C but I
> am nervous about  issues relating to pointers and runtime breaks but oh
> well. .
>
> If there was a way to transparently add code generation that would be
> sufficient and remain type safe. *sigh*
>
> The biggest headache I am running up against is that between packages. I
> think that before I throw in the towel I am going to study exactly how the
> sort package is implemented, since in essence my library does the same
> thing, so maybe I just don't understand well enough how to use interfaces,
> embedding and composition.
>
>
> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>>
>> Yep, you are correct, more or less. My code is using interfaces and
>> panicking when it's fed the wrong thing.
>>
>> For example, in my test I had a literal number going into a write
>> function to put a value into a node in the tree. The insert implementation
>> panicked saying it couldn't put an int into a uint32 slot. Eventually I
>> worked out it was the assumed int typing of the literal causing the problem
>> (happens all the time, I should be used to it by now).
>>
>> The thing is, it is intended that the user of the type specific library
>> that imports the tree library will not make a type assumption like the
>> compiler did about a literal. The type specific part has to be written for
>> any given type. There is a little verbosity in the part that wraps the
>> injected functions with syntactic sugar so the base library has the
>> functions to work on the concrete data agnostic of its content and only the
>> return values provided by the functions it gets to do various comparisons
>> and whatnot. It's not excessively wordy for my tastes and I know it's doing
>> it the best way possible.
>>
>> It's just learning how to play with interfaces that I was struggling with
>> and I seem to have pretty much got it all figured out now.  I'm happy with
>> how the code is developing and pretty much joyous that I can do this inside
>> a type safe language. Type safety is a big part of how Go is such a fast
>> compiling language. Implicit casts and inheritance have a massive cost in
>> complexity not just a naive translation to binary code, but also in
>> optimising it. When can it cut out the dereferencing to methods and when
>> not? Since one could be using a method to do a relatively simple thing, in
>> very long, tight loops, if the OOP compiler guesses wrong and puts
>> dereferences in where they are not needed, it's a big cost over 1 million
>> iterations compared to being aware of it, like in my code, and avoiding the
>> need for dereferencing.
>>
>> I firmly believe that Go could replace C as a language to write systems
>> kernels in. I saw an amusing post recently relating to Dan Larimer's work
>> on EOS mentioning an automated code correctness checking application for
>> C++... Having intimately dealt with Dan's C++ source code, I can see why he
>> might be waking up to this, especially with the ether leaks going on, that
>> EOS has inherited (literally, I presume).
>>
>> This would not happen if it were written in Go. Note also that Geth lacks
>> this problem and there was almost going to be a split over code changes
>> from the Go side.
>>
>> Linus Torvalds famously said he wrote the Git CVS in C specifically to
>> exclude C++ programmers. But as any avid gopher would know, C has all kinds
>> of gotchas to do with busting out of stacks, heaps, allocated memory, and
>> forgetting to free memory. This does not happen in Go.
>>
>> So to cut a long story short, this is why I choose to program in Go. I
>> have a background in low level programming, I used to do a bit of M68k
>> assembler on my amiga when I was a teenager. I don't mind verbosity that is
>> necessary due to hardware architectural constraints. And as to the
>> potential users of my code, I am not responsible for them having a lack of
>> awareness of the exposed inner workings and them scratching their head at
>> panics when they try to push the wrong type of value into one of the
>> functions I wrote. They probably need to do some more study.
>>
>> I think of programming a bit like carpentry. Sure, you can just whack
>> together an Ikea table in half an hour, but if you want to make a nice one
>> that will last hundreds of years, you probably will need to at least spend
>> a week or two practicing before you even have something simply crude and
>> functional. C++ 

Re: [go-nuts] An issue with the select statement.

[Ian Lance Taylor]

On Fri, May 4, 2018 at 11:10 AM, Andriy Pylypenko  wrote:
> 2018-05-04 19:32 GMT+03:00 Ian Lance Taylor :
>>
>> On Fri, May 4, 2018 at 2:00 AM,   wrote:
>> >
>> > And I want to modify the worker thread like this:
>> >
>> > for {
>> > select {
>> > case wi := <- work_ch:
>> > self.do_the_work(wi)
>> > case <-self.idle_request:
>> > self.idle_response <- true
>> > }
>> > }
>> >
>> > However this last snippet of code does not work because the cases within
>> > the
>> > select statement are randomly chosen when both channels are ready so I
>> > have
>> > no guarantee that the first case is executed first.
>>
>> You also have no guarantee that a request won't arrive on work_ch a
>> nanosecond after the worker is told to go idle, but presumably that is
>> not a problem.
>
>
> In fact I have that guarantee because the supplier thread is a single
> goroutine and it guarantees that there would be no items on the work_ch
> after the idle state is requested and before the worker responded. Also the
> worker is never requested to stop, it is only requested to report that it
> has completed all the work and it is now idle.

In that case, drain the work channel after receiving the idle request
and before sending the idle response.

I'll note in passing that pools of goroutines are not the best idiom
for Go.  Starting new goroutines is cheap.  It's generally simpler to
spin up goroutines as needed then to keep a pool of goroutines around.
In this model use a separate semaphore, such as a buffered channel, to
limit the number of goroutines doing work concurrently.

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] Implementing method overloading using first class functions

[Louki Sumirniy]

Actually, after having a minor meltdown about the unpossibility of this, I 
realised for my specific case there is a golang compatible way to do this 
instead.

Byte slices.

Since I basically intended that really the nodes in the tree would probably 
be small, more often than not no more than 256 bytes, hash functions 
usually have the option of spitting out and feeding in byte slices. Byte 
slices compare as though they are arbitrarily sized unsigned integers. I 
can create a data construct where I have a key/value pair split at a 
particular byte boundary and parameterise the comparators with a field in 
the data structure that marks the start and end of the comparable segment. 
And voila!

I almost lost the faith, but now I can see clearly how freakin complex code 
gets when you try to do generics and polymorphism. I did a heap of golang 
code previously that used byte slices and I remember now how easily they 
can be used to convert with integers.

YAY!

On Friday, 4 May 2018 20:44:21 UTC+3, Louki Sumirniy wrote:
>
> Well after bashing my head against a brick wall I finally understand what 
> a mess it is for my specific purpose to work with Go. Nobody really 
> specifically said it in any discussions up to now but what my design needs 
> is generics. If code generation could be done more transparently I could 
> use that but it really kicks interactivity and flow in the nuts. I'm going 
> to probably abandon Golang on this basis. I am inclined to go with C but I 
> am nervous about  issues relating to pointers and runtime breaks but oh 
> well. . 
>
> If there was a way to transparently add code generation that would be 
> sufficient and remain type safe. *sigh*
>
> The biggest headache I am running up against is that between packages. I 
> think that before I throw in the towel I am going to study exactly how the 
> sort package is implemented, since in essence my library does the same 
> thing, so maybe I just don't understand well enough how to use interfaces, 
> embedding and composition.
>
> On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>>
>> Yep, you are correct, more or less. My code is using interfaces and 
>> panicking when it's fed the wrong thing.
>>
>> For example, in my test I had a literal number going into a write 
>> function to put a value into a node in the tree. The insert implementation 
>> panicked saying it couldn't put an int into a uint32 slot. Eventually I 
>> worked out it was the assumed int typing of the literal causing the problem 
>> (happens all the time, I should be used to it by now).
>>
>> The thing is, it is intended that the user of the type specific library 
>> that imports the tree library will not make a type assumption like the 
>> compiler did about a literal. The type specific part has to be written for 
>> any given type. There is a little verbosity in the part that wraps the 
>> injected functions with syntactic sugar so the base library has the 
>> functions to work on the concrete data agnostic of its content and only the 
>> return values provided by the functions it gets to do various comparisons 
>> and whatnot. It's not excessively wordy for my tastes and I know it's doing 
>> it the best way possible.
>>
>> It's just learning how to play with interfaces that I was struggling with 
>> and I seem to have pretty much got it all figured out now.  I'm happy with 
>> how the code is developing and pretty much joyous that I can do this inside 
>> a type safe language. Type safety is a big part of how Go is such a fast 
>> compiling language. Implicit casts and inheritance have a massive cost in 
>> complexity not just a naive translation to binary code, but also in 
>> optimising it. When can it cut out the dereferencing to methods and when 
>> not? Since one could be using a method to do a relatively simple thing, in 
>> very long, tight loops, if the OOP compiler guesses wrong and puts 
>> dereferences in where they are not needed, it's a big cost over 1 million 
>> iterations compared to being aware of it, like in my code, and avoiding the 
>> need for dereferencing.
>>
>> I firmly believe that Go could replace C as a language to write systems 
>> kernels in. I saw an amusing post recently relating to Dan Larimer's work 
>> on EOS mentioning an automated code correctness checking application for 
>> C++... Having intimately dealt with Dan's C++ source code, I can see why he 
>> might be waking up to this, especially with the ether leaks going on, that 
>> EOS has inherited (literally, I presume).
>>
>> This would not happen if it were written in Go. Note also that Geth lacks 
>> this problem and there was almost going to be a split over code changes 
>> from the Go side.
>>
>> Linus Torvalds famously said he wrote the Git CVS in C specifically to 
>> exclude C++ programmers. But as any avid gopher would know, C has all kinds 
>> of gotchas to do with busting out of stacks, heaps, allocated memory, and 
>> forgetting to free memory. This 

Re: [go-nuts] panic: runtime: unknown pc

[Ian Lance Taylor]

On Thu, May 3, 2018 at 11:39 PM, andrey mirtchovski
 wrote:
>
> I believe I've never encountered this nor seen anyone mention this
> error before. It occurred while fuzzing a C library that we interface
> with:
>
> PC=0x7fffbafc847c m=0 sigcode=0
>
> goroutine 0 [idle]:
> runtime: unknown pc 0x7fffbafc847c
> stack: frame={sp:0x7fff5fbff088, fp:0x0} stack=[0x7fff5fb80888,0x7fff5fbff8f0)
>
> registers:
>
> rax0x200018d
> rbx0x7fffc3d971a8
> rcx0x7fff5fbff088
> rdx0x4000
> rdi0x1
> rsi0x4801000
> rbp0x7fff5fbff0b0
> rsp0x7fff5fbff088
> r8 0x6
> r9 0x7fffbaf18a50
> r100x72
> r110x246
> r120x0
> r130x7
> r140x4000
> r150x4801000
> rip0x7fffbafc847c
> rflags 0x246
> cs 0x7
> fs 0x0
> gs 0x0
>
> [full stack trace available upon request, it starts/ends with "cgocall"]
>
> i'm not sure even how to approach this. would that be a runtime issue?
> if you have any hints i'd be happy to listen :)

This is a runtime issue.  Note that there have been some fixes for
this on tip.  If you have reproduction instructions, please open an
issue.  Thanks.

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] An issue with the select statement.

[Andriy Pylypenko]

2018-05-04 19:32 GMT+03:00 Ian Lance Taylor :

> On Fri, May 4, 2018 at 2:00 AM,   wrote:
> >
> > And I want to modify the worker thread like this:
> >
> > for {
> > select {
> > case wi := <- work_ch:
> > self.do_the_work(wi)
> > case <-self.idle_request:
> > self.idle_response <- true
> > }
> > }
> >
> > However this last snippet of code does not work because the cases within
> the
> > select statement are randomly chosen when both channels are ready so I
> have
> > no guarantee that the first case is executed first.
>
> You also have no guarantee that a request won't arrive on work_ch a
> nanosecond after the worker is told to go idle, but presumably that is
> not a problem.


In fact I have that guarantee because the supplier thread is a single
goroutine and it guarantees that there would be no items on the work_ch
after the idle state is requested and before the worker responded. Also the
worker is never requested to stop, it is only requested to report that it
has completed all the work and it is now idle.


>   If you need to ensure that some set of requests is
> completed before the workers go idle, then you need some sort of
> timestamp on jobs, and you should tell the worker to go idle as of a
> specific timestamp.  Once you have that, when the worker sees an idle
> request, with an idle timestamp, it can keep accepting work requests
> until it sees one with a later timestamp.  It can then report that it
> is going idle, and sleep until it is woken up, holding onto the next
> job that it will start doing when it wakes up.
>
> Ian
>



-- 
  Andriy

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Possible issue with math.Floor on Linux

[speter]

b is slightly less than 3 because there is a bit of time between the two
calls to time.Now().

If you substitute this:
fmt.Printf("input: %20.18f\n", b)

you get something like
input: 2.99965553350911

HTH
Peter

On Fri, May 4, 2018 at 7:26 PM, Andrei Avram 
wrote:

> Hello everyone,
>
> Today I ran into a situation that is strange to me. I ran the following
> code on two Linux machines (go run floor.go), on two Windows ones, and on
> Go Playground.
>
> package main
>
> import (
> "time"
> "math"
> )
>
> func main() {
> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
> a := 29030400
> b := float64(seconds) / float64(a)
>
> println("input:", b)
> println("floor:", math.Floor(b))
> }
>
> On Linux the output is:
>
> input: +3.00e+000
> floor: *+2.00e+000*
>
> On Windows and Playground:
>
> input: +3.00e+000
> floor: *+3.00e+000*
>
> As you can see, on Linux the floor value of float value 3 is rounded down
> to 2, while on Windows/Playground it's 3.
>
> The code was ran with Go 1.10 and 1.10.2.
>
> The system details of one of the Linux machines, as reported by "go bug":
>
> go version go1.10.2 linux/amd64
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/msd/.cache/go-build"
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/msd/go/"
> GORACE=""
> GOROOT="/usr/local/go"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build
> -gno-record-gcc-switches"
> GOROOT/bin/go version: go version go1.10.2 linux/amd64
> GOROOT/bin/go tool compile -V: compile version go1.10.2
> uname -sr: Linux 4.13.0-37-generic
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.4 LTS
> Release: 16.04
> Codename: xenial
> /lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC
> 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
> gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
>
>
> Is there something I miss or could this be an issue?
>
> Thanks,
> Andrei
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] An issue with the select statement.

[Andriy Pylypenko]

2018-05-04 18:24 GMT+03:00 Bruno Albuquerque :

> Here is an example that came up in the list that might help you:
> https://play.golang.org/p/I8MS0DFgZ2
>

Thank you! This is exactly the code I looked for.

However I should say this approach is not very much elegant because the
select statement randomizes the channels first and then one must fight that
randomness with a separate procedure to drain the hi channel.


> That being said, It looks like you are over engineering. If I really
> understand what you want to accomplish, wouldn't this help?
>
> https://github.com/brunoga/workerpool
>
> You can call Stop()/Start() to stop and resume the workers.
>

I do not want to stop the workers or otherwise I should deal with the items
which remain in the queue in case the application should terminate
immediately. It's much simpler for me to wait until the already queued work
is done.


>
> On Fri, May 4, 2018 at 7:24 AM  wrote:
>
>> Hi,
>>
>> I have a scenario which I haven't found a way to implement with the Go
>> channels and select statement while it's no problem to do it with the
>> select()/poll() functions. The scenario is as follows.
>>
>> Let me use a Go-like pseudo-code to demonstrate the idea. There is a
>> source of a work items which are processed by several goroutines. Here is
>> the source procedure:
>>
>> work_ch := make(chan *WorkItem)
>>
>> for {
>> work_ch <- NewWorkItem()
>> }
>>
>> And here is the worker thread:
>>
>> for {
>> wi := <-work_ch
>> self.do_the_work(wi)
>> }
>>
>> Now I need to suspend the work. I stop supplying the work items and want
>> to make sure the worker goroutines are done with the work. The source
>> procedure becomes something like this:
>>
>> for {
>> if suspend_requested {
>> for _, worker := range workers {
>> worker.idle_request <- true
>> }
>> for _, worker := range workers {
>> <-worker.idle_response
>> }
>> report_suspend_is_success()
>> wait_until_unsuspended()
>> }
>> work_ch <- NewWorkItem()
>> }
>>
>> And I want to modify the worker thread like this:
>>
>> for {
>> select {
>> case wi := <- work_ch:
>> self.do_the_work(wi)
>> case <-self.idle_request:
>> self.idle_response <- true
>> }
>> }
>>
>> However this last snippet of code does not work because the cases within
>> the select statement are randomly chosen when both channels are ready so I
>> have no guarantee that the first case is executed first.
>>
>> Talking about the select() or poll() functions from the C library which
>> evidently were an inspiration for the Go select statement, there is no
>> problem with the described approach. It's because the select() function
>> returns a complete information about the state of all the monitored
>> descriptors and allows the programmer to decide what he wants to read or
>> write and in which order, based on readiness of every descriptor.
>>
>> I think it would be a great idea to have some function similar to
>> select()/poll() but working with the Go channels.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>


-- 
  Andriy Pylypenko
  Development Lead
  Sippy Software, Inc.
  Internet Telephony (VoIP) Experts
  T/F: +1-646-651-1110
  Web: http://www.sippysoft.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] Possible issue with math.Floor on Linux

[Ian Lance Taylor]

On Fri, May 4, 2018 at 10:26 AM, Andrei Avram
 wrote:
>
> Today I ran into a situation that is strange to me. I ran the following code
> on two Linux machines (go run floor.go), on two Windows ones, and on Go
> Playground.
>
> package main
>
> import (
> "time"
> "math"
> )
>
> func main() {
> datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
> seconds := -1 * int(time.Now().Sub(datetime).Seconds())
> a := 29030400
> b := float64(seconds) / float64(a)
>
> println("input:", b)
> println("floor:", math.Floor(b))
> }
>
> On Linux the output is:
>
> input: +3.00e+000
> floor: +2.00e+000
>
> On Windows and Playground:
>
> input: +3.00e+000
> floor: +3.00e+000
>
> As you can see, on Linux the floor value of float value 3 is rounded down to
> 2, while on Windows/Playground it's 3.
>
> The code was ran with Go 1.10 and 1.10.2.

The builtin println function already does rounding, so you are
comparing two rounded results.  Use fmt.Println instead to see the
real values you are working with.

Ian

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

Re: [go-nuts] Re: Go 1.10.2 and Go 1.9.5 are released

[Michel Casabianca]

Hi Gophers,

I have updated my list of Go interfaces for these releases :
http://sweetohm.net/article/go-interfaces.en.html

Enjoy!
--
Michel Casabianca

Le mar. 1 mai 2018 à 19:27, Nathan Kerr  a écrit :

> I updated my release related resources:
>
>- Go Release Timeline 
>- When Should You Upgrade Go?
>
>
> Nathan
>
> On Tuesday, May 1, 2018 at 10:04:38 AM UTC-7, Andrew Bonventre wrote:
>>
>> Hi gophers,
>>
>> We have just released Go versions 1.10.2 and 1.9.6, minor point releases.
>>
>> These releases include fixes to the compiler, linker, and go command.
>>
>> View the release notes for more information:
>> https://golang.org/doc/devel/release.html#go1.10.minor
>>
>> You can download binary and source distributions from the Go web site:
>> https://golang.org/dl/
>>
>> To compile from source using a Git clone, update to the release with
>> "git checkout go1.10.2" and build as usual.
>>
>> Thanks to everyone who contributed to the release.
>>
>> The Go Team
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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: An issue with the select statement.

[as]

>Talking about the select() or poll() functions from the C library which 
evidently were an inspiration for the Go select statement

Go select is more similar to alt() than select() or poll()

On Friday, May 4, 2018 at 7:24:56 AM UTC-7, Andriy Pylypenko wrote:
>
> Hi,
>
> I have a scenario which I haven't found a way to implement with the Go 
> channels and select statement while it's no problem to do it with the 
> select()/poll() functions. The scenario is as follows.
>
> Let me use a Go-like pseudo-code to demonstrate the idea. There is a 
> source of a work items which are processed by several goroutines. Here is 
> the source procedure:
>
> work_ch := make(chan *WorkItem)
>
> for {
> work_ch <- NewWorkItem()
> }
>
> And here is the worker thread:
>
> for {
> wi := <-work_ch
> self.do_the_work(wi)
> }
>
> Now I need to suspend the work. I stop supplying the work items and want 
> to make sure the worker goroutines are done with the work. The source 
> procedure becomes something like this:
>
> for {
> if suspend_requested {
> for _, worker := range workers {
> worker.idle_request <- true
> }
> for _, worker := range workers {
> <-worker.idle_response
> }
> report_suspend_is_success()
> wait_until_unsuspended()
> }
> work_ch <- NewWorkItem()
> }
>
> And I want to modify the worker thread like this:
>
> for {
> select {
> case wi := <- work_ch:
> self.do_the_work(wi)
> case <-self.idle_request:
> self.idle_response <- true
> }
> }
>
> However this last snippet of code does not work because the cases within 
> the select statement are randomly chosen when both channels are ready so I 
> have no guarantee that the first case is executed first.
>
> Talking about the select() or poll() functions from the C library which 
> evidently were an inspiration for the Go select statement, there is no 
> problem with the described approach. It's because the select() function 
> returns a complete information about the state of all the monitored 
> descriptors and allows the programmer to decide what he wants to read or 
> write and in which order, based on readiness of every descriptor.
>
> I think it would be a great idea to have some function similar to 
> select()/poll() but working with the Go channels.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Implementing method overloading using first class functions

[Louki Sumirniy]

Well after bashing my head against a brick wall I finally understand what a 
mess it is for my specific purpose to work with Go. Nobody really 
specifically said it in any discussions up to now but what my design needs 
is generics. If code generation could be done more transparently I could 
use that but it really kicks interactivity and flow in the nuts. I'm going 
to probably abandon Golang on this basis. I am inclined to go with C but I 
am nervous about  issues relating to pointers and runtime breaks but oh 
well. . 

If there was a way to transparently add code generation that would be 
sufficient and remain type safe. *sigh*

The biggest headache I am running up against is that between packages. I 
think that before I throw in the towel I am going to study exactly how the 
sort package is implemented, since in essence my library does the same 
thing, so maybe I just don't understand well enough how to use interfaces, 
embedding and composition.

On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>
> Yep, you are correct, more or less. My code is using interfaces and 
> panicking when it's fed the wrong thing.
>
> For example, in my test I had a literal number going into a write function 
> to put a value into a node in the tree. The insert implementation panicked 
> saying it couldn't put an int into a uint32 slot. Eventually I worked out 
> it was the assumed int typing of the literal causing the problem (happens 
> all the time, I should be used to it by now).
>
> The thing is, it is intended that the user of the type specific library 
> that imports the tree library will not make a type assumption like the 
> compiler did about a literal. The type specific part has to be written for 
> any given type. There is a little verbosity in the part that wraps the 
> injected functions with syntactic sugar so the base library has the 
> functions to work on the concrete data agnostic of its content and only the 
> return values provided by the functions it gets to do various comparisons 
> and whatnot. It's not excessively wordy for my tastes and I know it's doing 
> it the best way possible.
>
> It's just learning how to play with interfaces that I was struggling with 
> and I seem to have pretty much got it all figured out now.  I'm happy with 
> how the code is developing and pretty much joyous that I can do this inside 
> a type safe language. Type safety is a big part of how Go is such a fast 
> compiling language. Implicit casts and inheritance have a massive cost in 
> complexity not just a naive translation to binary code, but also in 
> optimising it. When can it cut out the dereferencing to methods and when 
> not? Since one could be using a method to do a relatively simple thing, in 
> very long, tight loops, if the OOP compiler guesses wrong and puts 
> dereferences in where they are not needed, it's a big cost over 1 million 
> iterations compared to being aware of it, like in my code, and avoiding the 
> need for dereferencing.
>
> I firmly believe that Go could replace C as a language to write systems 
> kernels in. I saw an amusing post recently relating to Dan Larimer's work 
> on EOS mentioning an automated code correctness checking application for 
> C++... Having intimately dealt with Dan's C++ source code, I can see why he 
> might be waking up to this, especially with the ether leaks going on, that 
> EOS has inherited (literally, I presume).
>
> This would not happen if it were written in Go. Note also that Geth lacks 
> this problem and there was almost going to be a split over code changes 
> from the Go side.
>
> Linus Torvalds famously said he wrote the Git CVS in C specifically to 
> exclude C++ programmers. But as any avid gopher would know, C has all kinds 
> of gotchas to do with busting out of stacks, heaps, allocated memory, and 
> forgetting to free memory. This does not happen in Go. 
>
> So to cut a long story short, this is why I choose to program in Go. I 
> have a background in low level programming, I used to do a bit of M68k 
> assembler on my amiga when I was a teenager. I don't mind verbosity that is 
> necessary due to hardware architectural constraints. And as to the 
> potential users of my code, I am not responsible for them having a lack of 
> awareness of the exposed inner workings and them scratching their head at 
> panics when they try to push the wrong type of value into one of the 
> functions I wrote. They probably need to do some more study.
>
> I think of programming a bit like carpentry. Sure, you can just whack 
> together an Ikea table in half an hour, but if you want to make a nice one 
> that will last hundreds of years, you probably will need to at least spend 
> a week or two practicing before you even have something simply crude and 
> functional. C++ and other OOP and interpreted language users are like Ikea 
> customers. Gophers are like people who go to the sawmill and the specialist 
> tool store. Disregarding the zero cost of 

Re: [go-nuts] Re: Upcoming Go protobuf release

['Joe Tsai' via golang-nuts]

The merge has happened on pull request #591
.

JT

On Thu, May 3, 2018 at 4:01 PM Tharaneedharan Vilwanathan <
vdhar...@gmail.com> wrote:

> Hi All,
>
> Can someone share some details on this code merge? Has this happened? How
> can I play with it?
>
> Thanks
> dharani
>
> **
>
> *Hello gophers,*
>
> *This is an announcement that we will be merging the dev branch of
> github.com/golang/protobuf
>  into master on April 30th
> (approximately 3 months from now).*
>
> *This merge will introduce several significant changes:*
>
>- *A new table-driven implementation that is shown to be about 1.3x to
>2.1x faster when tested inside Google.*
>- *The preservation of unknown fields in proto3 messages
>.*
>- *Validation that strings are valid UTF-8 as specified in
>the language guides
>.*
>
> *...*
>
> --
> 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/F5xFHTfwRnY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Possible issue with math.Floor on Linux

[Andrei Avram]

Hello everyone,

Today I ran into a situation that is strange to me. I ran the following 
code on two Linux machines (go run floor.go), on two Windows ones, and on 
Go Playground.

package main

import (
"time"
"math"
)

func main() {
datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
seconds := -1 * int(time.Now().Sub(datetime).Seconds())
a := 29030400
b := float64(seconds) / float64(a)

println("input:", b)
println("floor:", math.Floor(b))
}

On Linux the output is:

input: +3.00e+000
floor: *+2.00e+000*

On Windows and Playground:

input: +3.00e+000
floor: *+3.00e+000*

As you can see, on Linux the floor value of float value 3 is rounded down 
to 2, while on Windows/Playground it's 3.

The code was ran with Go 1.10 and 1.10.2.

The system details of one of the Linux machines, as reported by "go bug":

go version go1.10.2 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/msd/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/msd/go/"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build304261270=/tmp/go-build 
-gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.10.2 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.10.2
uname -sr: Linux 4.13.0-37-generic
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
Release: 16.04
Codename: xenial
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 
2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1


Is there something I miss or could this be an issue?

Thanks,
Andrei

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] bufio usage hurting performance

[Ian Lance Taylor]

On Fri, May 4, 2018 at 7:43 AM, Ankit Gupta  wrote:
>
> I am talking in terms of parsing http request by using
>
> http.ReadRequest method which only accept bufio.Reader
> (https://golang.org/pkg/net/http/#ReadRequest)

Ah.  That may have been a mistake.  It dates back to the initial
implementation of the function, before the first open source release
(https://github.com/golang/go/commit/42b7789a9277e7626e4ddaadcbaefb7689d9d8d4).
If we were to do it today, perhaps we would do it differently.
Unfortunately, we can't change it now without breaking Go 1
compatibility.  I suggest that you add a comment about this to
https://golang.org/issue/5465.  Thanks.

Ian


> On Friday, May 4, 2018 at 8:04:22 PM UTC+5:30, Ian Lance Taylor wrote:
>>
>> On Fri, May 4, 2018 at 5:20 AM, Ankit Gupta  wrote:
>> >
>> > I recently wrote a reverse proxy in Go -
>> > https://github.com/gptankit/serviceq which does load balancing and
>> > queues
>> > failed requests (to dipatch later).
>> > When I compared perf with nginx, I noticed 15-20 ms higher response
>> > times.
>> > So, I timed each function, and got to know that the code spends most
>> > time in
>> > 3 places -
>> >
>> > Read from tcp conn
>> > Save in a buffer
>> > Write to tcp conn
>> >
>> > 'Save' is necessary addition as I need to re-run the requests. For
>> > 'Read'
>> > and 'Write', I use bufio -
>> >
>> > Read:
>> > reader := bufio.NewReader(*httpConn.tcpConn)
>> > req, err := http.ReadRequest(reader)
>> >
>> > Write:
>> > writer := bufio.NewWriter(*httpConn.tcpConn)
>> >
>> > Why does Go impose me to read from bufio.Reader and not directly from
>> > io.Reader? I understand the implication for bigger data but for few
>> > bytes,
>> > managing a buffer seems like an overhead.
>>
>> I'm sorry, I don't understand the question.  Go does not in general
>> require you to use a bufio.Reader.  Where is that requirement coming
>> from?
>>
>>
>> > I am using Go 1.6.
>>
>> That is pretty old now.
>>
>> Ian
>
>
> ::DISCLAIMER::
> 
>
> The contents of this e-mail and any attachments are confidential and
> intended for the named recipient(s) only.E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted,lost, destroyed, arrive late or incomplete, or may contain viruses
> in transmission. The e mail and its contents(with or without referred
> errors) shall therefore not attach any liability on the originator or
> redBus.com. Views or opinions, if any, presented in this email are solely
> those of the author and may not necessarily reflect the views or opinions of
> redBus.com. Any form of reproduction, dissemination, copying, disclosure,
> modification,distribution and / or publication of this message without the
> prior written consent of authorized representative of redbus.com is strictly
> prohibited. If you have received this email in error please delete it and
> notify the sender immediately.Before opening any email and/or attachments,
> please check them for viruses and other defects.
> ::DISCLAIMER::
> 
>
> The contents of this e-mail and any attachments are confidential and
> intended for the named recipient(s) only.E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted,lost, destroyed, arrive late or incomplete, or may contain viruses
> in transmission. The e mail and its contents(with or without referred
> errors) shall therefore not attach any liability on the originator or
> redBus.com. Views or opinions, if any, presented in this email are solely
> those of the author and may not necessarily reflect the views or opinions of
> redBus.com. Any form of reproduction, dissemination, copying, disclosure,
> modification,distribution and / or publication of this message without the
> prior written consent of authorized representative of redbus.com is strictly
> prohibited. If you have received this email in error please delete it and
> notify the sender immediately.Before opening any email and/or attachments,
> please check them for viruses and other defects.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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 

Re: [go-nuts] An issue with the select statement.

[Ian Lance Taylor]

On Fri, May 4, 2018 at 2:00 AM,   wrote:
>
> And I want to modify the worker thread like this:
>
> for {
> select {
> case wi := <- work_ch:
> self.do_the_work(wi)
> case <-self.idle_request:
> self.idle_response <- true
> }
> }
>
> However this last snippet of code does not work because the cases within the
> select statement are randomly chosen when both channels are ready so I have
> no guarantee that the first case is executed first.

You also have no guarantee that a request won't arrive on work_ch a
nanosecond after the worker is told to go idle, but presumably that is
not a problem.  If you need to ensure that some set of requests is
completed before the workers go idle, then you need some sort of
timestamp on jobs, and you should tell the worker to go idle as of a
specific timestamp.  Once you have that, when the worker sees an idle
request, with an idle timestamp, it can keep accepting work requests
until it sees one with a later timestamp.  It can then report that it
is going idle, and sleep until it is woken up, holding onto the next
job that it will start doing when it wakes up.

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] what is the binary code share mechanism of golang ?

[Ian Lance Taylor]

On Thu, May 3, 2018 at 11:37 PM, Jim Yin  wrote:
>
> Right now, go still import 3rd party libraries by source code.
> It is too foolish.
> Java share libraries by jar files, c++ share libraries by dll or so files.
> Even php has a phar file format.
> go need a binary format file share libraries.
> Share libraries by source code is acceptable, but should not download them
> directly.
> Source code can be packed into a compressed file, like phar file.
> It can be called goar file.
> I think this feature should be implemented as soon as possible.

One aspect of the vgo proposal (https://golang.org/issue/24301) is to
define an interchange format for Go packages.  It will still be source
code, but it will be a binary file as you describe.  The current
proposal is to use a zip file.

Ian

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

[go-nuts] Re: Go routines hanging

[Aaron Alpar]

Can you distill the code you've provided into something that demonstrates 
the hangs with the least code possible?

Immediately I see a possible problem on lines 131 and 148 or your code: I 
don't see specification of a timeout for the outgoing connection or sending 
the message on the outgoing connection.  

RedisWriteHandler will stall if either one of these outgoing requests hangs.

While timeouts will not fix your problem, they will allow you to further 
diagnose the problem.

- Aaron

On Friday, May 4, 2018 at 7:24:56 AM UTC-7, s...@whites.team wrote:
>
> Hi all,
>
> I'm having an issue with a messaging server I'm trying to write in Go (my 
> first real Go project). I'm having an issue that I've not come across 
> before in Go - the code executes as expected, then hangs after a second or 
> so indefinitely, no errors, no logs showing it's exited. The code is 
> available here 
> .
>  
> The functions of note are RedisWriteHandler and addRedisSender. In func 
> main I'm seeding a channel with the max amount of items (currently 100k) 
> then starting RedisWriteHandler, this should auto scale up and down 
> according to the length of the channel. However before it gets a chance to 
> scale down it hangs. I've checked with redis-cli and the senders are still 
> connected, but no more messages are coming though. Unfortunately I can't 
> replicate this in the go playground as it's never going to return, and it 
> will take too long and get kicked. I also asked this question here 
>  
> but it seems to have gone quiet.
>
> Based on comments from a couple other questions in this group I've killed 
> the process manually to get the stack trace which I'll attach, hopefully 
> this is helpful.
>
> Any thoughts would be greatly appreciated!
>
> Thanks,
>
> Sam
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] An issue with the select statement.

[Bruno Albuquerque]

Here is an example that came up in the list that might help you:
https://play.golang.org/p/I8MS0DFgZ2

That being said, It looks like you are over engineering. If I really
understand what you want to accomplish, wouldn't this help?

https://github.com/brunoga/workerpool

You can call Stop()/Start() to stop and resume the workers.


On Fri, May 4, 2018 at 7:24 AM  wrote:

> Hi,
>
> I have a scenario which I haven't found a way to implement with the Go
> channels and select statement while it's no problem to do it with the
> select()/poll() functions. The scenario is as follows.
>
> Let me use a Go-like pseudo-code to demonstrate the idea. There is a
> source of a work items which are processed by several goroutines. Here is
> the source procedure:
>
> work_ch := make(chan *WorkItem)
>
> for {
> work_ch <- NewWorkItem()
> }
>
> And here is the worker thread:
>
> for {
> wi := <-work_ch
> self.do_the_work(wi)
> }
>
> Now I need to suspend the work. I stop supplying the work items and want
> to make sure the worker goroutines are done with the work. The source
> procedure becomes something like this:
>
> for {
> if suspend_requested {
> for _, worker := range workers {
> worker.idle_request <- true
> }
> for _, worker := range workers {
> <-worker.idle_response
> }
> report_suspend_is_success()
> wait_until_unsuspended()
> }
> work_ch <- NewWorkItem()
> }
>
> And I want to modify the worker thread like this:
>
> for {
> select {
> case wi := <- work_ch:
> self.do_the_work(wi)
> case <-self.idle_request:
> self.idle_response <- true
> }
> }
>
> However this last snippet of code does not work because the cases within
> the select statement are randomly chosen when both channels are ready so I
> have no guarantee that the first case is executed first.
>
> Talking about the select() or poll() functions from the C library which
> evidently were an inspiration for the Go select statement, there is no
> problem with the described approach. It's because the select() function
> returns a complete information about the state of all the monitored
> descriptors and allows the programmer to decide what he wants to read or
> write and in which order, based on readiness of every descriptor.
>
> I think it would be a great idea to have some function similar to
> select()/poll() but working with the Go channels.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] what is the binary code share mechanism of golang ?

[Michael Jones]

Hello. Trying to understand your question.

JAR files are the result of compiling source to a "ready for execution"
state (using a CPU and OS-specific interpreter).
DLL and SO are the result of compiling source to a specific, "ready for
execution on a particular CPU and with a particular OS."
Go produces binaries "ready for execution on a particular CPU and with a
particular OS."

Now, an archive of source code as a single compressed file, such as
"bundle.a.gzip" is something that would be needed at compile time.
Something that presumably would be fetched automatically, uncompressed and
unarchived to a temporary directory, and then compiled? Is this your
suggestion?

Right now this is done differently. The fetching of the remote code is done
before compilation ("go get") and the fetched code is cached locally. Each
build then finds the code in source or compiled for ready to go. This makes
builds much faster and removed network dependencies on the build phase.

Situations where the programmer wonders, "is my cached view of that remote
code up to date?" or "do i have the right version?" are important in large
projects. There is an effort underway to manage this automatically; search
for "vgo" or "vendoring" in this mailing list. You can try it now.

If you are suggesting the "dynamic fetch of remote code during compilation"
then please share what you see as benefits.

Michael

On Fri, May 4, 2018 at 7:24 AM Jim Yin  wrote:

> Right now, go still import 3rd party libraries by source code.
> It is too foolish.
> Java share libraries by jar files, c++ share libraries by dll or so
> files.
> Even php has a phar file format.
> go need a binary format file share libraries.
> Share libraries by source code is acceptable, but should not download
> them directly.
> Source code can be packed into a compressed file, like phar file.
> It can be called goar file.
> I think this feature should be implemented as soon as possible.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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.

[go-nuts] Re: [ANN] GoKi Trees and GoGi GUI

[matthewjuran]

Hi Randy, here’s a code review.

Thanks for the BSD license.

I prefer the look of a minimized import path, I would have put the title 
library at the top level (github.com/goki/ki).

To me the README doesn’t balance text and code examples well enough, I’d 
like to see more example uses and less text. In package ki I’d hope the 
library does enough work to not require so much README.

I think ki isn’t a bad package name after reading what it means but seeing 
the package used in app code won’t show the point as obviously as an 
English word for some people. tree.New() to me says “new data structure 
var” while ki.New() says “I have to read the docs now”.

(when I say 'app' I mean a program that uses your library or a program 
written to compile with a Go compiler; an application of the library, an 
application of the Go programming language)

The Ki interface is a code smell to me. Usually I interpret library 
interfaces as saying “the app provides an implementation of the interface 
and the library provides shared logic that uses the interface methods” or 
in this case I expect the ki lib will provide varying data structures and 
behaviors that implement the ki var. Just reading down to line 42 of ki.go 
I feel like this isn’t very Go-like.

You’re getting into generics territory with this:

func NewOfType(typ reflect.Type) Ki {

My view is idiomatic Go code tends to avoid this kind of thing due to 
maintenance and readability burden. I haven’t used your lib but I am 
concerned about it not being a big win over a per-app implementation. I can 
see you’ve done a lot of work to make generics work.

In type Node I would consider embedding Props.

I haven’t looked at all of the methods but do the methods on Node need to 
be to a pointer?

func (n *Node) Fields() []uintptr {

Seeing uintptr in a public method is a code smell to me.

In type Deleted consider maybe embedding sync.Mutex.

// fmt.Printf("finding path: %v\n", k.Path)

Instead of comments you may want to consider this pattern:

const debug = false
…
if debug {
fmt.Printf("finding path: %v\n", k.Path)
}

I think this library would be a good study for the Go 2 
(https://blog.golang.org/toward-go2) generics effort, if you have time 
consider writing an experience report and posting it: 
https://github.com/golang/go/issues/15292

Perhaps consider embedding ki.Signal in gi.Action, and MakeMenuFunc, 
ki.Signal, *Icon, and ButtonStates in ButtonBase, some fields in ColorView, 
Dialog, FillStyle, FontStyle, LayoutStyle, LayoutData, Layout, MapView, 
MapViewInline, Node2DBase, Paint, ImagePaintServer, SliceView, 
SliceViewInline, SliderBase, SplitView, StrokeStyle, StructView, 
StructViewInline, BorderStyle, ShadowStyle, Style, TabView, TextStyle, 
TextField, SpinBox, ComboBox, TreeView, ValueViewBase, Viewport2D, Window. 
I like to avoid any unnecessary field symbols.

These kinds of structs are a code smell to me:

type ColorValueView struct {
ValueViewBase
}

Why a Base type? Can your types be simpler?

type Node2D and type ValueView seem like other possible overuses of 
interface to me. The size of type PaintServer is closer to what I’d expect 
with an interface, and Labeler seems idiomatic.

I like the screenshot.

// check for interface implementation
var _ Node2D = {}

I don’t like this pattern.

Given the amount of code and project maturity I wouldn’t expect you to make 
a lot of changes, but I do think it could have been built with a stronger 
resilience to change. Thanks for sharing here.

Matt

On Friday, May 4, 2018 at 5:39:35 AM UTC-5, Randall O'Reilly wrote:
>
> https://github.com/goki/goki — key demo in: 
> https://github.com/goki/goki/tree/master/gi/examples/widgets 
>
> This is the first release of a new Go framework built around the Tree as a 
> core data structure (Ki = Tree in Japanese), which includes as its first 
> application a fully-native Go GUI (built on top of a modified version of 
> the Shiny OS-specific backend drivers, supporting Mac, Linux, and Windows 
> so far). 
>
> Building on the central idea in Go that having a few powerful 
> data-structures is essential for making many problems easier to solve, the 
> GoKi trees are an attempt to provide a powerful tree structure that can 
> support things like scene graphs, DOM’s, parsing trees, etc. 
>
> The GoGi graphical interface system is a kind of “proof is in the pudding” 
> test, which weighs in at under 20k LOC and provides a reasonably 
> full-featured GUI — with a bit more work it should be able to do most of 
> the stuff you can do in Qt, and already includes a (self) reflection-driven 
> GUI designer. 
>
> The overall design is an attempt to integrate existing standards and 
> conventions from widely-used frameworks, including Qt (overall widget 
> design), HTML / CSS (styling), and SVG (rendering). Rendering in SVG is 
> directly supported by the GoGi 2D scenegraph, with enhanced functionality 
> for interactive GUI's. This 2D framework also 

Re: [go-nuts] bufio usage hurting performance

[Ankit Gupta]

I am talking in terms of parsing http request by using

http.ReadRequest method which only accept bufio.Reader 
(https://golang.org/pkg/net/http/#ReadRequest)

On Friday, May 4, 2018 at 8:04:22 PM UTC+5:30, Ian Lance Taylor wrote:
>
> On Fri, May 4, 2018 at 5:20 AM, Ankit Gupta  > wrote: 
> > 
> > I recently wrote a reverse proxy in Go - 
> > https://github.com/gptankit/serviceq which does load balancing and 
> queues 
> > failed requests (to dipatch later). 
> > When I compared perf with nginx, I noticed 15-20 ms higher response 
> times. 
> > So, I timed each function, and got to know that the code spends most 
> time in 
> > 3 places - 
> > 
> > Read from tcp conn 
> > Save in a buffer 
> > Write to tcp conn 
> > 
> > 'Save' is necessary addition as I need to re-run the requests. For 
> 'Read' 
> > and 'Write', I use bufio - 
> > 
> > Read: 
> > reader := bufio.NewReader(*httpConn.tcpConn) 
> > req, err := http.ReadRequest(reader) 
> > 
> > Write: 
> > writer := bufio.NewWriter(*httpConn.tcpConn) 
> > 
> > Why does Go impose me to read from bufio.Reader and not directly from 
> > io.Reader? I understand the implication for bigger data but for few 
> bytes, 
> > managing a buffer seems like an overhead. 
>
> I'm sorry, I don't understand the question.  Go does not in general 
> require you to use a bufio.Reader.  Where is that requirement coming 
> from? 
>
>
> > I am using Go 1.6. 
>
> That is pretty old now. 
>
> Ian 
>

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] bufio usage hurting performance

[Ian Lance Taylor]

On Fri, May 4, 2018 at 5:20 AM, Ankit Gupta  wrote:
>
> I recently wrote a reverse proxy in Go -
> https://github.com/gptankit/serviceq which does load balancing and queues
> failed requests (to dipatch later).
> When I compared perf with nginx, I noticed 15-20 ms higher response times.
> So, I timed each function, and got to know that the code spends most time in
> 3 places -
>
> Read from tcp conn
> Save in a buffer
> Write to tcp conn
>
> 'Save' is necessary addition as I need to re-run the requests. For 'Read'
> and 'Write', I use bufio -
>
> Read:
> reader := bufio.NewReader(*httpConn.tcpConn)
> req, err := http.ReadRequest(reader)
>
> Write:
> writer := bufio.NewWriter(*httpConn.tcpConn)
>
> Why does Go impose me to read from bufio.Reader and not directly from
> io.Reader? I understand the implication for bigger data but for few bytes,
> managing a buffer seems like an overhead.

I'm sorry, I don't understand the question.  Go does not in general
require you to use a bufio.Reader.  Where is that requirement coming
from?


> I am using Go 1.6.

That is pretty old now.

Ian

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

[go-nuts] what is the binary code share mechanism of golang ?

[Jim Yin]

Right now, go still import 3rd party libraries by source code.
It is too foolish.
Java share libraries by jar files, c++ share libraries by dll or so files.
Even php has a phar file format.
go need a binary format file share libraries.
Share libraries by source code is acceptable, but should not download them
directly.
Source code can be packed into a compressed file, like phar file.
It can be called goar file.
I think this feature should be implemented as soon as possible.

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

[go-nuts] The jsgo playground: Edit and run Go in the browser, supporting arbitrary import paths.

[dave]

https://play.jsgo.io/


The jsgo playground is an extension of the jsgo compiler. The compiler 
allows you to easily compile Go to JS using GopherJS, and automatically 
host the results in an aggressively cached CDN. The playground adds an 
online editor and many other features (share, deploy etc.).


The unique feature of the jsgo playground is that it supports arbitrary 
import paths. Other Go playgrounds are limited to just the Go standard 
library.


For more for more info:

   - compiler: https://github.com/dave/jsgo
   - playground: https://github.com/dave/play
   
Take a look at some of these demos:


Here's the simplest demo - it just writes to the console and to the page:

   - https://play.jsgo.io/github.com/dave/jstest
   
Here's a couple of simple demos that accept files by drag and drop. The 
first compresses dropped files to a zip. The second compresses images to 
jpg. They use the Go standard library zip / image libraries, which work 
flawlessly in the browser:

   - https://play.jsgo.io/github.com/dave/zip
   - https://play.jsgo.io/github.com/dave/img
   
The amazing ebiten 2D games library is a perfect example of the power of Go 
in the browser. Here's some demos:

   - https://play.jsgo.io/github.com/hajimehoshi/ebiten/examples/2048
   - https://play.jsgo.io/github.com/hajimehoshi/go-inovation
   - https://play.jsgo.io/github.com/hajimehoshi/ebiten/examples/flappy
   
Check out the help page in the playground or the github page for a full 
explanation of all the features. Let me know if you have any questions, 
bugs or feature suggestions... I really hope you have fun exploring and I 
hope it's useful!


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 routines hanging

[sam]

Hi all,

I'm having an issue with a messaging server I'm trying to write in Go (my 
first real Go project). I'm having an issue that I've not come across 
before in Go - the code executes as expected, then hangs after a second or 
so indefinitely, no errors, no logs showing it's exited. The code is 
available here 
.
 
The functions of note are RedisWriteHandler and addRedisSender. In func 
main I'm seeding a channel with the max amount of items (currently 100k) 
then starting RedisWriteHandler, this should auto scale up and down 
according to the length of the channel. However before it gets a chance to 
scale down it hangs. I've checked with redis-cli and the senders are still 
connected, but no more messages are coming though. Unfortunately I can't 
replicate this in the go playground as it's never going to return, and it 
will take too long and get kicked. I also asked this question here 
 
but it seems to have gone quiet.

Based on comments from a couple other questions in this group I've killed 
the process manually to get the stack trace which I'll attach, hopefully 
this is helpful.

Any thoughts would be greatly appreciated!

Thanks,

Sam

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


stacktrack-go-redis
Description: Binary data

[go-nuts] An issue with the select statement.

[bambyster]

Hi,

I have a scenario which I haven't found a way to implement with the Go 
channels and select statement while it's no problem to do it with the 
select()/poll() functions. The scenario is as follows.

Let me use a Go-like pseudo-code to demonstrate the idea. There is a source 
of a work items which are processed by several goroutines. Here is the 
source procedure:

work_ch := make(chan *WorkItem)

for {
work_ch <- NewWorkItem()
}

And here is the worker thread:

for {
wi := <-work_ch
self.do_the_work(wi)
}

Now I need to suspend the work. I stop supplying the work items and want to 
make sure the worker goroutines are done with the work. The source 
procedure becomes something like this:

for {
if suspend_requested {
for _, worker := range workers {
worker.idle_request <- true
}
for _, worker := range workers {
<-worker.idle_response
}
report_suspend_is_success()
wait_until_unsuspended()
}
work_ch <- NewWorkItem()
}

And I want to modify the worker thread like this:

for {
select {
case wi := <- work_ch:
self.do_the_work(wi)
case <-self.idle_request:
self.idle_response <- true
}
}

However this last snippet of code does not work because the cases within 
the select statement are randomly chosen when both channels are ready so I 
have no guarantee that the first case is executed first.

Talking about the select() or poll() functions from the C library which 
evidently were an inspiration for the Go select statement, there is no 
problem with the described approach. It's because the select() function 
returns a complete information about the state of all the monitored 
descriptors and allows the programmer to decide what he wants to read or 
write and in which order, based on readiness of every descriptor.

I think it would be a great idea to have some function similar to 
select()/poll() but working with the Go channels.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] beginner question about chanels

[sam]

gobyexample.com/channel-buffering explains this really nicely with a runnable 
example showing the difference!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Html is not parsing while parsing a template to send email

[djego . joss]

Hello,

first a small remark on wording: I think you're using the verb "parse" with 
the wrong definition here? You might mean something like "to replace html 
in template tokens" instead of "to parse..." :-).

On Friday, May 4, 2018 at 10:42:57 AM UTC+2, Amandeep Kaur wrote:
>
> Where templateHtml is the email body with tokens and data is the interface 
> holding dynamic values for these tokens. When I use ParseTemplate function 
> to parse tokens as string values then it works fine. But if I have to parse 
> html in one of my tokens then it parses html as string and in email 
> displays html as string.
>

This is actually a "feature" caused by the html/template package security 
model. You can read more on this in the 
documentation: https://golang.org/pkg/html/template/#hdr-Security_Model
What happens is that content of `data interface{}`, typically provided by 
the user and not the programmer, is considered "unsafe". Thus html in there 
will be escaped.
However, if you (the programmer) know that the content of the specific 
token `{{.TOKENNAME}}` is "safe" html, then you can cast it to 
html/template.HTML (see https://golang.org/pkg/html/template/#HTML) before 
Executing the template.
 

> Can anybody tell me what should I do to parse html in ParseTemplate 
> function??
>
>  Hope this clears up your problem,
Diego 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] it's hard to reply to group from gmail, by default

[Jim Mitchell]

  this is how it originally worked.  I have an old group setup years 
ago and that is the way it goes.   I spent an entire day with our new 
group and checked every setting to the old group and everything is the 
same except reply just goes to the poster.   Do the google group admins 
not understand how list servers work?



--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: beginner question about chanels

[k1attila1]

Thank you Sir
now i understand the difference


2018. május 4., péntek 15:21:49 UTC+2 időpontban k1at...@gmail.com a 
következőt írta:
>
> Hi
>
> i dont' understn what is the difference between :
>
> ch := make(chan bool,1)   vs. ch := make(chan bool)
>
> this sample works well :
>
> package main
>
> import (
> "fmt"
> "sync"
> )
>
> var x = 0
>
> func increment(wg *sync.WaitGroup, ch chan bool) {
> ch <- true
> x = x + 1
> <-ch
> wg.Done()
> }
> func main() {
> var w sync.WaitGroup
> ch := make(chan bool,1)   <--it is OK , but if i 
> change to  ch := make(chan bool) - it doesn't work
> for i := 0; i < 1000; i++ {
> w.Add(1)
> go increment(, ch)
> }
> w.Wait()
> fmt.Println("final value of x", x)
> }
>
> Thank you in advance
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: beginner question about chanels

[Ankit Gupta]

ch := make(chan bool) means you want to have an unbufferred channel. Send 
and Receive are block operations. In other words, send will block unless 
there is a receive operation, which is the case in your code. All calls to 
increment are blocked at ch <- true.

When you change it to ch := make(chan bool, 1), you create a bufferred 
chanel, send does not block and program moves on to empty the channel at 
<-ch.

Imp thing to note here is that when you exceed the send operations by 
channel capacity, it starts acting like an unbufferred channel.

On Friday, May 4, 2018 at 6:51:49 PM UTC+5:30, k1at...@gmail.com wrote:
>
> Hi
>
> i dont' understn what is the difference between :
>
> ch := make(chan bool,1)   vs. ch := make(chan bool)
>
> this sample works well :
>
> package main
>
> import (
> "fmt"
> "sync"
> )
>
> var x = 0
>
> func increment(wg *sync.WaitGroup, ch chan bool) {
> ch <- true
> x = x + 1
> <-ch
> wg.Done()
> }
> func main() {
> var w sync.WaitGroup
> ch := make(chan bool,1)   <--it is OK , but if i 
> change to  ch := make(chan bool) - it doesn't work
> for i := 0; i < 1000; i++ {
> w.Add(1)
> go increment(, ch)
> }
> w.Wait()
> fmt.Println("final value of x", x)
> }
>
> Thank you in advance
>

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] beginner question about chanels

[k1attila1]

Hi

i dont' understn what is the difference between :

ch := make(chan bool,1)   vs. ch := make(chan bool)

this sample works well :

package main

import (
"fmt"
"sync"
)

var x = 0

func increment(wg *sync.WaitGroup, ch chan bool) {
ch <- true
x = x + 1
<-ch
wg.Done()
}
func main() {
var w sync.WaitGroup
ch := make(chan bool,1)   <--it is OK , but if i 
change to  ch := make(chan bool) - it doesn't work
for i := 0; i < 1000; i++ {
w.Add(1)
go increment(, ch)
}
w.Wait()
fmt.Println("final value of x", x)
}

Thank you in advance

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Html is not parsing while parsing a template to send email

[Jakob Borg]

Like this;

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

//jb

On 4 May 2018, at 13:32, Amandeep Kaur 
> wrote:


Hi, Jakob Borg

Thanks for ypur reply to the post. The solution you have provided can not be 
implemented on my system. I have provided a small sample of my code structure. 
Please take a look

type EmailTemplate struct{
BookingDetails string
}

type EmailRequest struct{
EmailTo  string
EmailBody  string
}

// get saved html with tokens from database
notificationTemplate, errVal := merchantDb.GetNotificationTemplate()
request := EmailRequest{
"t...@example.com",
notificationTemplate.Content,
}
templateData.BookingDetails += 
"Industry"+industry.IndustryName+""

request.EmailSend(templateData)


func (request *EmailRequest) EmailSend(notificationTemplateData 
interface{}) (bool, error) {
body, errParse := ParseTemplate(request.EmailBody, 
notificationTemplateData)
//email sending code here
}

func ParseTemplate(templateHtml string, data interface{}) (string, error) {
var body string
t, err := template.New("my_template").Parse(templateHtml)
if err != nil {
return body, err
}
buf := new(bytes.Buffer)

if err = t.Execute(buf, data); err != nil {
return body, err
}
body = buf.String()
return body, nil
}

Where templateHtml is the email body with tokens and data is the interface 
holding dynamic values for these tokens.
When I use ParseTemplate function to parse tokens as string values then it 
works fine.
But if I have to parse html in one of my tokens then it parses html as string 
and in email displays html as string.

How ever If I try to make assertion on it from interface to template.HTML, it 
gives me error:
cannot convert notificationTemplateData (type interface {}) to type 
"html/template".HTML: need type assertion
On Friday, May 4, 2018 at 2:18:51 PM UTC+5:30, Jakob Borg wrote:
Hi,

Your post is a bit confusing and I think you may be using the word "parse" in 
the opposite of it its common meaning. However, if you want to pass a HTML 
fragment through a HTML template and have it not be escaped, look at the 
template.HTML type: https://golang.org/pkg/html/template/#HTML

//jb

On 4 May 2018, at 10:42, Amandeep Kaur 
> wrote:

Hello,

I am working on a SAAS based project for which I need to send emails to 
different clients on different events.

I am using email templates which use tokens (in format {{.TOKENNAME}}) that are 
made dynamic while sending emails. Now these token are parsed by using 
"html/template" package.

following is the custom function that I have made to parse these tokens into 
email body.

func ParseTemplate(templateHtml string, data interface{}) (string, error) {
var body string
t, err := template.New("my_template").Parse(templateHtml)
if err != nil {
return body, err
}
buf := new(bytes.Buffer)

if err = t.Execute(buf, data); err != nil {
return body, err
}
body = buf.String()
return body, nil
}

Where templateHtml is the email body with tokens and data is the interface 
holding dynamic values for these tokens. When I use ParseTemplate function to 
parse tokens as string values then it works fine. But if I have to parse html 
in one of my tokens then it parses html as string and in email displays html as 
string.

Can anybody tell me what should I do to parse html in ParseTemplate function??

Thanks!

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] bufio usage hurting performance

[Ankit Gupta]

I recently wrote a reverse proxy in Go 
- https://github.com/gptankit/serviceq which does load balancing and queues 
failed requests (to dipatch later). 
When I compared perf with nginx, I noticed 15-20 ms higher response times. 
So, I timed each function, and got to know that the code spends most time 
in 3 places - 

Read from tcp conn
Save in a buffer
Write to tcp conn

'Save' is necessary addition as I need to re-run the requests. For 'Read' 
and 'Write', I use bufio - 

Read:
reader := bufio.NewReader(*httpConn.tcpConn)
req, err := http.ReadRequest(reader)

Write:
writer := bufio.NewWriter(*httpConn.tcpConn)

Why does Go impose me to read from bufio.Reader and not directly from 
io.Reader? I understand the implication for bigger data but for few bytes, 
managing a buffer seems like an overhead.

I am using Go 1.6.

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
*::DISCLAIMER::




The contents of this e-mail and any attachments are confidential and 
intended for the named recipient(s) only.E-mail transmission is not 
guaranteed to be secure or error-free as information could be intercepted, 
corrupted,lost, destroyed, arrive late or incomplete, or may contain 
viruses in transmission. The e mail and its contents(with or without 
referred errors) shall therefore not attach any liability on the originator 
or redBus.com. Views or opinions, if any, presented in this email are 
solely those of the author and may not necessarily reflect the views or 
opinions of redBus.com. Any form of reproduction, dissemination, copying, 
disclosure, modification,distribution and / or publication of this message 
without the prior written consent of authorized representative of redbus. 
com is strictly prohibited. If you have received this 
email in error please delete it and notify the sender immediately.Before 
opening any email and/or attachments, please check them for viruses and 
other defects.*

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Html is not parsing while parsing a template to send email

[Amandeep Kaur]

Hi, Jakob Borg

Thanks for ypur reply to the post. The solution you have provided can not 
be implemented on my system. I have provided a small sample of my code 
structure. Please take a look

type EmailTemplate struct{
BookingDetails string
}

type EmailRequest struct{
EmailTo  string
EmailBody  string
}

// get saved html with tokens from database
notificationTemplate, errVal := merchantDb.GetNotificationTemplate()
request := EmailRequest{
"t...@example.com", 
notificationTemplate.Content,
}
templateData.BookingDetails += 
"Industry"+industry.IndustryName+""

request.EmailSend(templateData)


func (request *EmailRequest) EmailSend(notificationTemplateData 
interface{}) (bool, error) {
body, errParse := ParseTemplate(request.EmailBody, 
notificationTemplateData)
//email sending code here 
}

func ParseTemplate(templateHtml string, data interface{}) (string, 
error) {
var body string
t, err := template.New("my_template").Parse(templateHtml)
if err != nil {
return body, err
}
buf := new(bytes.Buffer)

if err = t.Execute(buf, data); err != nil {
return body, err
}
body = buf.String()
return body, nil
}

Where templateHtml is the email body with tokens and data is the interface 
holding dynamic values for these tokens.
When I use ParseTemplate function to parse tokens as string values then it 
works fine. 
But if I have to parse html in one of my tokens then it parses html as 
string and in email displays html as string.

How ever If I try to make assertion on it from interface to template.HTML, 
it gives me error: 
cannot convert notificationTemplateData (type interface {}) to type 
"html/template".HTML: need type assertion
On Friday, May 4, 2018 at 2:18:51 PM UTC+5:30, Jakob Borg wrote:
>
> Hi, 
>
> Your post is a bit confusing and I think you may be using the word "parse" 
> in the opposite of it its common meaning. However, if you want to pass a 
> HTML fragment through a HTML template and have it not be escaped, look at 
> the template.HTML type: https://golang.org/pkg/html/template/#HTML
>
> //jb
>
> On 4 May 2018, at 10:42, Amandeep Kaur  > wrote:
>
> Hello,
>
> I am working on a SAAS based project for which I need to send emails to 
> different clients on different events. 
>
> I am using email templates which use tokens (in format {{.TOKENNAME}}) 
> that are made dynamic while sending emails. Now these token are parsed by 
> using "html/template" package. 
>
> following is the custom function that I have made to parse these tokens 
> into email body.
>
> func ParseTemplate(templateHtml string, data interface{}) (string, error) {
> var body string
> t, err := template.New("my_template").Parse(templateHtml)
> if err != nil {
> return body, err
> }
> buf := new(bytes.Buffer)
> 
> if err = t.Execute(buf, data); err != nil {
> return body, err
> }
> body = buf.String()
> return body, nil
> }
>
> Where templateHtml is the email body with tokens and data is the interface 
> holding dynamic values for these tokens. When I use ParseTemplate function 
> to parse tokens as string values then it works fine. But if I have to parse 
> html in one of my tokens then it parses html as string and in email 
> displays html as string.
>
> Can anybody tell me what should I do to parse html in ParseTemplate 
> function??
>
> Thanks!
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

[go-nuts] [ANN] GoKi Trees and GoGi GUI

[Randall O'Reilly]

https://github.com/goki/goki — key demo in: 
https://github.com/goki/goki/tree/master/gi/examples/widgets

This is the first release of a new Go framework built around the Tree as a core 
data structure (Ki = Tree in Japanese), which includes as its first application 
a fully-native Go GUI (built on top of a modified version of the Shiny 
OS-specific backend drivers, supporting Mac, Linux, and Windows so far).

Building on the central idea in Go that having a few powerful data-structures 
is essential for making many problems easier to solve, the GoKi trees are an 
attempt to provide a powerful tree structure that can support things like scene 
graphs, DOM’s, parsing trees, etc.

The GoGi graphical interface system is a kind of “proof is in the pudding” 
test, which weighs in at under 20k LOC and provides a reasonably full-featured 
GUI — with a bit more work it should be able to do most of the stuff you can do 
in Qt, and already includes a (self) reflection-driven GUI designer.

The overall design is an attempt to integrate existing standards and 
conventions from widely-used frameworks, including Qt (overall widget design), 
HTML / CSS (styling), and SVG (rendering). Rendering in SVG is directly 
supported by the GoGi 2D scenegraph, with enhanced functionality for 
interactive GUI's. This 2D framework also integrates with a (planned) 3D 
scenegraph, to support interesting combinations of these frameworks. Currently 
GoGi is focused on desktop systems, but nothing prevents adaptation to mobile.

Right now the rendering is based off of a modified version of 
https://github.com/fogleman/gg, but I’m very interested in integrating the new 
rasterx system that Steven Wiley recently announced.

I’d be very interested in people’s impressions, suggestions, etc, and welcome 
all interested contributors (there’s certainly much more to do) — it would be 
great if this could provide the start for a widely-supported Go-native GUI 
framework!  This was my first Go project after many years in C++ / Qt land, and 
I’m excited to join the community, and have really been impressed with the 
language and ecosystem etc.  The contrast in complexity and build time between 
Qt and GoGi is really striking, and has kept me going despite the huge amount 
of effort it took to get this new project off the ground..  Cheers,

- Randy

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Implementing method overloading using first class functions

[Louki Sumirniy]

Yep, you are correct, more or less. My code is using interfaces and 
panicking when it's fed the wrong thing.

For example, in my test I had a literal number going into a write function 
to put a value into a node in the tree. The insert implementation panicked 
saying it couldn't put an int into a uint32 slot. Eventually I worked out 
it was the assumed int typing of the literal causing the problem (happens 
all the time, I should be used to it by now).

The thing is, it is intended that the user of the type specific library 
that imports the tree library will not make a type assumption like the 
compiler did about a literal. The type specific part has to be written for 
any given type. There is a little verbosity in the part that wraps the 
injected functions with syntactic sugar so the base library has the 
functions to work on the concrete data agnostic of its content and only the 
return values provided by the functions it gets to do various comparisons 
and whatnot. It's not excessively wordy for my tastes and I know it's doing 
it the best way possible.

It's just learning how to play with interfaces that I was struggling with 
and I seem to have pretty much got it all figured out now.  I'm happy with 
how the code is developing and pretty much joyous that I can do this inside 
a type safe language. Type safety is a big part of how Go is such a fast 
compiling language. Implicit casts and inheritance have a massive cost in 
complexity not just a naive translation to binary code, but also in 
optimising it. When can it cut out the dereferencing to methods and when 
not? Since one could be using a method to do a relatively simple thing, in 
very long, tight loops, if the OOP compiler guesses wrong and puts 
dereferences in where they are not needed, it's a big cost over 1 million 
iterations compared to being aware of it, like in my code, and avoiding the 
need for dereferencing.

I firmly believe that Go could replace C as a language to write systems 
kernels in. I saw an amusing post recently relating to Dan Larimer's work 
on EOS mentioning an automated code correctness checking application for 
C++... Having intimately dealt with Dan's C++ source code, I can see why he 
might be waking up to this, especially with the ether leaks going on, that 
EOS has inherited (literally, I presume).

This would not happen if it were written in Go. Note also that Geth lacks 
this problem and there was almost going to be a split over code changes 
from the Go side.

Linus Torvalds famously said he wrote the Git CVS in C specifically to 
exclude C++ programmers. But as any avid gopher would know, C has all kinds 
of gotchas to do with busting out of stacks, heaps, allocated memory, and 
forgetting to free memory. This does not happen in Go. 

So to cut a long story short, this is why I choose to program in Go. I have 
a background in low level programming, I used to do a bit of M68k assembler 
on my amiga when I was a teenager. I don't mind verbosity that is necessary 
due to hardware architectural constraints. And as to the potential users of 
my code, I am not responsible for them having a lack of awareness of the 
exposed inner workings and them scratching their head at panics when they 
try to push the wrong type of value into one of the functions I wrote. They 
probably need to do some more study.

I think of programming a bit like carpentry. Sure, you can just whack 
together an Ikea table in half an hour, but if you want to make a nice one 
that will last hundreds of years, you probably will need to at least spend 
a week or two practicing before you even have something simply crude and 
functional. C++ and other OOP and interpreted language users are like Ikea 
customers. Gophers are like people who go to the sawmill and the specialist 
tool store. Disregarding the zero cost of reproduction of course (that's 
what Ikea does).

On Friday, 4 May 2018 11:36:33 UTC+3, M P r a d e s wrote:
>
> > Eliminating code duplication shrinks the base of code that must be 
> changed
>
> Except go was designed a certain way that will make whatever you are 
> attempting to do here burdensome. We've all been there at first trying to 
> fit a square into a round hole, it doesn't work. Unless you start ignoring 
> Go type system with interface {} everywhere, you're not going to go far 
> trying to emulate method overloading in Go. The price of using Go is 
> absolutely code duplication and a certain amount of verbosity in order to 
> remain type safe. The only real way to achieve method polymorphism in go is 
> to use interfaces, since Go supports neither inheritance nor generic 
> programming. Go does not allow developers to write "clever" code without 
> sacrificing readability or compile time type safety. 
>
> Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit :
>>
>> The specifics of how it is done is not as important as why to do it:
>>
>> I am writing this for a later project. It will need at least 5 

[go-nuts] Re: Windows OneDrive issue ..

[Dave Cheney]

This is issue https://github.com/golang/go/issues/22579

On Tuesday, 1 May 2018 20:38:26 UTC+2, xiof...@gmail.com wrote:
>
> I just discovered a problem running/compiling files that are 
> accessed/backed up by windows OneDrive
>
> (don't know when this started - worked a couple of months ago..)
>
> So I have a simple go file at
>
> C:\Users\xiool\OneDrive\go ie test.go
>
> At the command line all variants of
>
> go run C:/Users/xiool/OneDrive/go/test.go
>
> give the error
>
> package main: cannot find package "." in:
> C:\Users\xiool\OneDrive\go
>
> The files are stored offline on the computer, and simple replacements such 
> as 
>
> notepad.exe C:/Users/xiool/OneDrive/go/test.go
>
> Work as expected
>
>
> Build/install etc also fail. No issues outside the OneDrive directory. And 
> no issues a few months back.
>
> I assume this is a windows problem .. but what ??
>
> Anyone else had this.. and a fix please ??
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Html is not parsing while parsing a template to send email

[Jakob Borg]

Hi,

Your post is a bit confusing and I think you may be using the word "parse" in 
the opposite of it its common meaning. However, if you want to pass a HTML 
fragment through a HTML template and have it not be escaped, look at the 
template.HTML type: https://golang.org/pkg/html/template/#HTML

//jb

On 4 May 2018, at 10:42, Amandeep Kaur 
> wrote:

Hello,

I am working on a SAAS based project for which I need to send emails to 
different clients on different events.

I am using email templates which use tokens (in format {{.TOKENNAME}}) that are 
made dynamic while sending emails. Now these token are parsed by using 
"html/template" package.

following is the custom function that I have made to parse these tokens into 
email body.

func ParseTemplate(templateHtml string, data interface{}) (string, error) {
var body string
t, err := template.New("my_template").Parse(templateHtml)
if err != nil {
return body, err
}
buf := new(bytes.Buffer)

if err = t.Execute(buf, data); err != nil {
return body, err
}
body = buf.String()
return body, nil
}

Where templateHtml is the email body with tokens and data is the interface 
holding dynamic values for these tokens. When I use ParseTemplate function to 
parse tokens as string values then it works fine. But if I have to parse html 
in one of my tokens then it parses html as string and in email displays html as 
string.

Can anybody tell me what should I do to parse html in ParseTemplate function??

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.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Html is not parsing while parsing a template to send email

[Amandeep Kaur]

Hello,

I am working on a SAAS based project for which I need to send emails to 
different clients on different events. 

I am using email templates which use tokens (in format {{.TOKENNAME}}) that 
are made dynamic while sending emails. Now these token are parsed by using 
"html/template" package. 

following is the custom function that I have made to parse these tokens 
into email body.

func ParseTemplate(templateHtml string, data interface{}) (string, error) {
var body string
t, err := template.New("my_template").Parse(templateHtml)
if err != nil {
return body, err
}
buf := new(bytes.Buffer)

if err = t.Execute(buf, data); err != nil {
return body, err
}
body = buf.String()
return body, nil
}

Where templateHtml is the email body with tokens and data is the interface 
holding dynamic values for these tokens. When I use ParseTemplate function 
to parse tokens as string values then it works fine. But if I have to parse 
html in one of my tokens then it parses html as string and in email 
displays html as string.

Can anybody tell me what should I do to parse html in ParseTemplate 
function??

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] Implementing method overloading using first class functions

[prades . marq]

> Eliminating code duplication shrinks the base of code that must be changed

Except go was designed a certain way that will make whatever you are 
attempting to do here burdensome. We've all been there at first trying to 
fit a square into a round hole, it doesn't work. Unless you start ignoring 
Go type system with interface {} everywhere, you're not going to go far 
trying to emulate method overloading in Go. The price of using Go is 
absolutely code duplication and a certain amount of verbosity in order to 
remain type safe. The only real way to achieve method polymorphism in go is 
to use interfaces, since Go supports neither inheritance nor generic 
programming. Go does not allow developers to write "clever" code without 
sacrificing readability or compile time type safety. 

Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit :
>
> The specifics of how it is done is not as important as why to do it:
>
> I am writing this for a later project. It will need at least 5 different, 
> sometimes nearly not very different, short data types. They all have the 
> property of being comparable. The code that keeps them stored and sorted 
> does not need to know anything other than this comparability, and to be 
> able to pass the data back to the caller.
>
> I am not making claims about something, trying to sell some snake oil, I 
> am attempting to solve a problem and make use of low level architecture of 
> the hardware to improve performance. It worked for B-heaps so maybe MAYBE 
> it will also benefit binary trees. The way some people respond you'd think 
> I was running an ICO!
>
> Programming is usually 5% writing and 95% debugging. Eliminating code 
> duplication shrinks the base of code that must be changed, otherwise I have 
> to delve into code generators or macros. If I have an intended use for a 
> library I am writing, that would require 5 different source files for each 
> data type, yet 90% of the code was the same, what happens when I realise I 
> made a mistake in this common code?
>
> I pretty much concluded that it is better to just pass an 8 element 
> function pointer struct as value anyway. Whether the compiler does it 
> differently doesn't really matter since I can't control that. What matters 
> to me is that it's readable so I don't have to spend more time reading than 
> understanding.
>
> On Thursday, 3 May 2018 23:40:07 UTC+3, Jan Mercl wrote:
>>
>> On Thu, May 3, 2018 at 10:14 PM Louki Sumirniy  
>> wrote:
>>
>> > As some here may know, I am implementing a novel binary tree based on 
>> complete trees and using ideas from B-heaps in order to achieve maximum 
>> data cache locality in a search and sort algorithm.
>>
>> ...
>>
>> > Note that this is not really at all an OOP paradigm that I am trying to 
>> ape with this.
>>
>> ...
>>
>> > I have the base type that concerns itself with the walk, search, insert 
>> and delete functions in an interface.
>>
>> 
>>
>> > The b.Overloads - I am not sure, whether it should be pass by value or 
>> pass by reference. I think pass by reference adds an extra resolution step, 
>> but it is probably more expensive as every call of the functions will have 
>> to perform this dereference.
>>
>> ...
>>
>> > Thanks in advance for any feedback on this.
>>
>> - Novelty is only valid when established by peer review. Self-claimed 
>> novelty often means just lack of research. Even if eventually correct, it's 
>> a warning sign for me meanwhile.
>>
>> - Attempts to make non-interface types in Go behave in the OOP-style 
>> inheritance is usually a telling sign of using the wrong language - or 
>> abusing one - to solve the problem.
>>
>> - Pass by reference has not even a well defined meaning in Go.
>>
>> No insult intended, you've explicitly asked for _any_ feedback. My 
>> apologies if you feel offended anyway,
>>
>>
>> -- 
>>
>> -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.