Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

[Kaveh Shahbazian]

Thank you Paul,

On Tuesday, May 26, 2020 at 7:37:34 AM UTC+2, Paul Jolly wrote:
>
> > Why the output of this code is nondeterministic? 
>
> See https://golang.org/ref/spec#For_statements, specifically the "For 
> statements with range clause" subheading, specifically this bullet: 
>
> > 3. The iteration order over maps is not specified and is not guaranteed 
> to be the same from one iteration to the next. If a map entry that has not 
> yet been reached is removed during iteration, the corresponding iteration 
> value will not be produced. If a map entry is created during iteration, 
> that entry may be produced during the iteration or may be skipped. The 
> choice may vary for each entry created and from one iteration to the next. 
> If the map is nil, the number of iterations is 0. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d000-d86f-45b1-b765-2a9915fe8741%40googlegroups.com.

Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

[Paul Jolly]

> Why the output of this code is nondeterministic?

See https://golang.org/ref/spec#For_statements, specifically the "For
statements with range clause" subheading, specifically this bullet:

> 3. The iteration order over maps is not specified and is not guaranteed to be 
> the same from one iteration to the next. If a map entry that has not yet been 
> reached is removed during iteration, the corresponding iteration value will 
> not be produced. If a map entry is created during iteration, that entry may 
> be produced during the iteration or may be skipped. The choice may vary for 
> each entry created and from one iteration to the next. If the map is nil, the 
> number of iterations is 0.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACoUkn6NkFid3tVxUdy2bC0-2D7kh96Ab66DQcEeVOJEWedhsA%40mail.gmail.com.

[go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

[Kaveh Shahbazian]

Why the output of this code is nondeterministic?

Go Playground 

package main

import (
"fmt"
)

func main() {
series := make(map[int]int)

series[0] = 0

i := 1
for k, v := range series {
fmt.Println(k, v)
if i < 10 {
series[i] = i
}
i++
}
}

(There is no implication in this question, regarding how maps, or for loops 
ranging over them, should behave. I'm just trying to understand)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8f0752c4-bdb5-4b71-895b-a0ed56d89596%40googlegroups.com.

[go-nuts] Failed to build gollvm in a docker container

[Yuan Ting]

I tried to build gollvm in a docker container (the image is based on ubuntu 
20.04, and the host OS is MacOS catalina). I configured llvm by

SHELL=/bin/sh cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 
-DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G 
Ninja ../llvm

and then build and install gollvm by 

ninja gollvm && ninja install-gollvm

after a while, I encountered

...

error: At most two relocations per offset are supported

error: At most two relocations per offset are supported

error: At most two relocations per offset are supported

[212/1279] Creating 
/root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go

FAILED: tools/gollvm/libgo/tmp-sigtab.go

cd /root/llvm-project/build-debug/tools/gollvm/libgo && GOARCH=amd64 
GOOS=linux /bin/sh 
/root/llvm-project/llvm/tools/gollvm/libgo/capturescript.sh 
/root/llvm-project/llvm/tools/gollvm/gofrontend/libgo/mksigtab.sh 
/root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sigtab.go

error: no SHELL setting

[214/1279] Creating 
/root/llvm-project/build-debug/tools/gollvm/libgo/tmp-sysinfo.go

ninja: build stopped: subcommand failed.


By add SHELL=/bin/sh, the errors above seems to be skipped but another 
period of time: 


...

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
 
failed to match split-stack sequence at section 4 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/errno.c.o:
 
failed to match split-stack sequence at section 6 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libgo_c_piclib.dir/__/gofrontend/libgo/go/syscall/signame.c.o:
 
failed to match split-stack sequence at section 5 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/backtrace.c.o:
 
failed to match split-stack sequence at section 4 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/backtrace.c.o:
 
failed to match split-stack sequence at section 6 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/dwarf.c.o: 
failed to match split-stack sequence at section 18 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libbacktrace_piclib.dir/libbacktrace/dwarf.c.o: 
failed to match split-stack sequence at section 79 offset 0

...

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffi64.c.o: 
failed to match split-stack sequence at section 22 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffi64.c.o: 
failed to match split-stack sequence at section 26 offset 0

/usr/bin/ld.gold: error: 
tools/gollvm/libgo/CMakeFiles/libffi_piclib.dir/libffi/src/x86/ffiw64.c.o: 
failed to match split-stack sequence at section 16 offset 0

collect2: error: ld returned 1 exit status

[901/1066] Linking C static library tools/gollvm/libgo/libgo.a

ninja: build stopped: subcommand failed.


I'm not sure the error is caused by the container environment or my 
configurations/other prerequisites.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/23309451-cb0a-4f7b-93a1-27038187302a%40googlegroups.com.

Re: [go-nuts] Re: Best practices for file scoping

[Davis Ford]

Use Ginkgo -- great test runner and the Gomega test matcher is awesome
too.  Works out of the box also with straight up go test.

That was my solution back in 2015, and is still my solution todaystill
writing golang.

On Mon, May 25, 2020 at 1:52 PM  wrote:

> Me too. Running into the same exact situation.
>
> On Saturday, May 9, 2015 at 9:44:06 PM UTC-7, Davis Ford wrote:
>>
>> I know this is an ancient thread, but I thought I'd see if anyone has any
>> clever tricks for getting around this with unit tests.
>>
>> I have a package that has a handful of files.  In other languages,
>> file-scope variables are very useful for tests, as I often declare a list
>> of of variables at the top of the test (e.g. the entity under test, as well
>> as several other dependencies it needs that I can inject into it to mock
>> its behavior, etc.)  This is becoming problematic in golang.  Many times
>> the list of these variables across files is similar -- similar
>> dependencies, etc., and I need to new them up for the test, but now they
>> collide across test files.
>>
>> I'm looking at the following possibilities:
>>
>> * Move the declaration into every test function so they scoped at the
>> function, but this just repeats code and becomes very verbose.
>> * Put them all in a struct and reference them as fields hanging off the
>> global test struct declared in each test file but this is tedious and makes
>> the code less clear (IMO)
>> * Just rename them to similar but different names in each test file,
>> (this is what the OP was talking about doing)
>> * Refactor all the code to try to work around this -- untenable
>>
>> On Thursday, November 18, 2010 at 11:56:38 AM UTC-5, Russ Cox wrote:
>>>
>>> We spent a long time on this and decided that in Go
>>> file boundaries are never relevant, nor is the order of
>>> top-level declarations.  This makes it nearly trivial to
>>> move code between files as makes sense for organization.
>>> (The one exception is imports, but making imports work
>>> "at a distance" seemed even worse.)
>>>
>>> I have found myself in the situation you are in on
>>> occasion, and I always end up doing one of these:
>>>
>>> 1. Use a per-package logger variable.
>>>If this is just for debugging, that's often fine.
>>>
>>> 2. Identify what the semantic split of the logging
>>>is, and use that in the name.  For example, if
>>>your package is readers and writers and that's
>>>how the logging breaks down, then readLogger
>>>and writeLogger seem reasonable.
>>>
>>> Russ
>>>
>> --
> 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/s9ShMsCLuXI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHyzJDPM7AF1pao%2BfhUJahWDzQz2%3Djgbt_2yRrGn_MCPZnz6CQ%40mail.gmail.com.

Re: [go-nuts] url.QueryEscape unexpectedly slow

[robert engels]

This is an infinite loop:

  for b := byte(0); b <= 255; b++ {
 _ = url.QueryEscape(string([]byte{a,b}))
  }

b will always be <= 255 because it is a byte.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87FBE123-74DB-4C6A-B662-D9944D888B0F%40ix.netcom.com.

Re: [go-nuts] url.QueryEscape unexpectedly slow

[Ian Davis]

Don't use a byte for your loops, use an int.

When your loop reaches 255 it is incremented to 0 which is still <= 255 so your 
loop never terminates.

On Mon, 25 May 2020, at 10:54 PM, Liam wrote:
> I would expect this to complete pretty quickly, but after 40 minutes (on 
> 1.13, linux/amd64), it hasn't printed a thing.
> 
> I'm following up a report of panic in QueryEscape: 
> https://github.com/golang/go/issues/38643
> 
> package main
> 
> import (
>  "net/url"
>  "fmt"
> )
> 
> func main() {
>  for a := byte(0); a <= 255; a++ {
>  if (a+1) % 8 == 0 { fmt.Println(a) }
>  for b := byte(0); b <= 255; b++ {
>  _ = url.QueryEscape(string([]byte{a,b}))
>  }
>  }
> }
> 

> --
>  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.
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/17295814-834f-47a2-b6fb-76bbf4f5f95b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ba3881c4-30dd-4d64-b268-86176e4c02f7%40www.fastmail.com.

[go-nuts] url.QueryEscape unexpectedly slow

[Liam]

I would expect this to complete pretty quickly, but after 40 minutes (on 
1.13, linux/amd64), it hasn't printed a thing.

I'm following up a report of panic in QueryEscape: 
https://github.com/golang/go/issues/38643

package main

import (
   "net/url"
   "fmt"
)

func main() {
   for a := byte(0); a <= 255; a++ {
  if (a+1) % 8 == 0 { fmt.Println(a) }
  for b := byte(0); b <= 255; b++ {
 _ = url.QueryEscape(string([]byte{a,b}))
  }
   }
}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/17295814-834f-47a2-b6fb-76bbf4f5f95b%40googlegroups.com.

Re: [go-nuts] Re: Tracking down RSS growth in cgo library

[Ian Lance Taylor]

On Sun, May 24, 2020 at 12:50 PM Justin Israel  wrote:
>
> About the frequency of finalizers, can you confirm my question about whether 
> the finalizers run during the GC run each time, regardless of when that GC 
> run decides to happen? Or can a GC start to run but decide not to process the 
> finalizers yet in that cycle?

The question doesn't have a simple answer.  The garbage collector runs
concurrently with the program.  The exact details aren't too important
(and I'm not sure I fully understand them) but the collector will
periodically identify blocks of memory that have been fully marked,
such that any unmarked object in that block is definitely free.  If
one of those unmarked objects has a finalizer, the collector will mark
the object so that it will not be freed after all, will remove the
finalizer from the object, and will queue the finalizer to be run.
The finalizer queue will hold a reference to the object, so it won't
be freed while the finalizer is queued.  There is a separate goroutine
that runs finalizers, and queuing a finalizer wakes up that goroutine.
When that goroutine is scheduled, it will get the finalizer off the
queue and run it.

I'm not sure how to take that process and turn it into an answer to
your question.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXu-vxk1cLFSzVi%2BjS3CTrNsqqRH46ypzZhFC5Ua75sgQ%40mail.gmail.com.

Re: [go-nuts] Build fails when using gollvm toolchain instead of go

[Ian Lance Taylor]

On Mon, May 25, 2020 at 8:54 AM  wrote:
>
> I've been trying to make this project https://github.com/intel-go/nff-go 
> using a freshly built gollvm to get the code compiled into LLVM IR. The 
> project builds fine when using the regular go toolchain, but when trying to 
> build with gollvm, I get errors such as below:
>
> ../../asm/asm.s: Assembler messages:
> ../../asm/asm.s:6: Error: no such instruction: `text 
> ·RteCompilerRmb(SB),NOSPLIT,$0-0'
> ../../asm/asm.s:9: Error: no such instruction: `text 
> ·RteCompilerWmb(SB),NOSPLIT,$0-0'
> ../../asm/asm.s:12: Error: no such instruction: `text 
> ·Prefetcht0(SB),NOSPLIT,$0-8'
> ../../asm/asm.s:13: Error: junk `(FP)' after expression
> ../../asm/asm.s:13: Error: too many memory references for `movq'
> ../../asm/asm.s:16: Error: no such instruction: `text 
> ·GenerateMask(SB),NOSPLIT,$0-33'
> ../../asm/asm.s:17: Error: junk `(FP)' after expression
> ../../asm/asm.s:17: Error: too many memory references for `movq'
> ../../asm/asm.s:18: Error: junk `(FP)' after expression
> ../../asm/asm.s:18: Error: too many memory references for `movq'
> ../../asm/asm.s:19: Error: junk `(FP)' after expression
> ../../asm/asm.s:19: Error: too many memory references for `movq'
> ../../asm/asm.s:20: Error: junk `(FP)' after expression
> ../../asm/asm.s:20: Error: too many memory references for `movq'
> ../../asm/asm.s:21: Error: too many memory references for `vmovdqu'
> ../../asm/asm.s:22: Error: too many memory references for `vmovdqu'
> ../../asm/asm.s:23: Error: too many memory references for `vmovdqu'
> ../../asm/asm.s:24: Error: too many memory references for `vpcmpeqb'
> ../../asm/asm.s:25: Error: too many memory references for `vpand'
> ../../asm/asm.s:26: Error: too many memory references for `vptest'
> ../../asm/asm.s:27: Error: junk `(FP)' after expression
> ../../asm/asm.s:27: Error: invalid instruction suffix for `sete'
> ../../asm/asm.s:28: Error: too many memory references for `vmovdqu'

The assembler syntax used by the gc toolchain and the assembler syntax
used by GoLLVM are not compatible.  Here you are trying to assemble
code written for the gc assembler with the GoLLVM assembler.  That
won't work.

While the syntax differences are in some ways annoying, in other ways
they are good, because gc and GoLLVM use different calling
conventions.  That means that assembler code written for gc and GoLLVM
are not compatible (except for functions that take no arguments and
return no results).

What this means for your code is that you need to rewrite this code
into GoLLVM assembler (changing the calling convention as you go) or
you need to rewrite it into Go.  You can use build tags to select the
version to use for each compiler.

Sorry for these difficulties.  They are hard to avoid.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVavB-C2k%2BBk7KcsDhcKGNJyVPQAssD74wV5PzFRpWKdw%40mail.gmail.com.

Re: [go-nuts] Re: Is it acceptable to make the optional parameter as varargs

[Robert Engels]

You can use builder to build options or the server. It is a much cleaner and 
self documenting method. 

> On May 25, 2020, at 12:51 PM, sergey@netdata.cloud wrote:
> 
> 
> Hello Amarjeet,
> 
> You can actually don't check if len(options) is greater than one – if your 
> package provides only single implementation of Option, than there is no way 
> to pass something different than that backoffOption. But it also brings an 
> ability to extend your constructor later. There is a great article about 
> optional arguments: 
> https://sagikazarmark.hu/blog/functional-options-on-steroids/
> 
> I'd rather prefer optional arguments to builder.
> 
> -- 
> Regards,
> Sergey.
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/1e07b530-7805-4221-a6a0-61de6ca219cb%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5DA103CD-C522-4883-A946-D0B32286A8AF%40ix.netcom.com.

[go-nuts] I made History + Diff command to test automation tool by golang. Are you interesting this tool?

[katoh . yasuta]

Hi. i'm engeneer in japan. I write any programs as a hobby each days. 
But, I don't have a mate around for golang. and haven't use  programing in 
my company.

Everyone, please this tool can be evaluated?

https://github.com/yasutakatou/hiffer

This tool wrap cmd.exe (when Windows),or unix shell, and feature is  
HISTORY command mix DIFF command. You can do operation on this tool like 
normal shell.
But, When you complete server and want to test setting, this tool do your 
operation again and diff output. so, you notice different value on setting. 
Never seen and interesting tool?
I want your evaluate, and enjoy golang programing with me!

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/06f70243-0bc5-4de5-8155-31ff6a467c91%40googlegroups.com.

[go-nuts] Re: Best practices for file scoping

[dnj0496]

Me too. Running into the same exact situation.

On Saturday, May 9, 2015 at 9:44:06 PM UTC-7, Davis Ford wrote:
>
> I know this is an ancient thread, but I thought I'd see if anyone has any 
> clever tricks for getting around this with unit tests.
>
> I have a package that has a handful of files.  In other languages, 
> file-scope variables are very useful for tests, as I often declare a list 
> of of variables at the top of the test (e.g. the entity under test, as well 
> as several other dependencies it needs that I can inject into it to mock 
> its behavior, etc.)  This is becoming problematic in golang.  Many times 
> the list of these variables across files is similar -- similar 
> dependencies, etc., and I need to new them up for the test, but now they 
> collide across test files.
>
> I'm looking at the following possibilities:
>
> * Move the declaration into every test function so they scoped at the 
> function, but this just repeats code and becomes very verbose. 
> * Put them all in a struct and reference them as fields hanging off the 
> global test struct declared in each test file but this is tedious and makes 
> the code less clear (IMO)
> * Just rename them to similar but different names in each test file, (this 
> is what the OP was talking about doing)
> * Refactor all the code to try to work around this -- untenable
>
> On Thursday, November 18, 2010 at 11:56:38 AM UTC-5, Russ Cox wrote:
>>
>> We spent a long time on this and decided that in Go
>> file boundaries are never relevant, nor is the order of
>> top-level declarations.  This makes it nearly trivial to
>> move code between files as makes sense for organization.
>> (The one exception is imports, but making imports work
>> "at a distance" seemed even worse.)
>>
>> I have found myself in the situation you are in on
>> occasion, and I always end up doing one of these:
>>
>> 1. Use a per-package logger variable.
>>If this is just for debugging, that's often fine.
>>
>> 2. Identify what the semantic split of the logging
>>is, and use that in the name.  For example, if
>>your package is readers and writers and that's
>>how the logging breaks down, then readLogger
>>and writeLogger seem reasonable.
>>
>> Russ
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a90b8b93-b9d8-4fc1-a666-63b355ebdef0%40googlegroups.com.

[go-nuts] Re: Is it acceptable to make the optional parameter as varargs

[sergey]

Hello Amarjeet,

You can actually don't check if len(options) is greater than one – if your 
package provides only single implementation of Option, than there is no way 
to pass something different than that backoffOption. But it also brings an 
ability to extend your constructor later. There is a great article about 
optional arguments: 
https://sagikazarmark.hu/blog/functional-options-on-steroids/

I'd rather prefer optional arguments to builder.

-- 
Regards,
Sergey.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1e07b530-7805-4221-a6a0-61de6ca219cb%40googlegroups.com.

[go-nuts] Re: Is there a way to create a global variable inside go routine stack? so that i can access any time, without passing around between methods/functions. Crazy thought !!!..

[Jake Montgomery]

On Sunday, May 24, 2020 at 3:46:54 PM UTC-4, adithya...@gmail.com wrote:
>
> if i am not wrong, Even the main itself is a go routine, which have global 
> variables?
>

Perhaps you should describe a bit more what you mean? People seem to be 
making assumptions that you meant something different that what you 
actually said. Assuming you are referring to the main() function, then, no 
it is not a goroutine, but it does run in a goroutine. However, main() doe 
not "have" global variables. Can you give an exmaple of what you mean by 
this?

Global variables belong to the package, and are accessible from *any *goroutine 
in the package, if they are private, and from any goroutine anywhere if 
they are public. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/749251f0-513f-4e6b-9636-b1e596daadbb%40googlegroups.com.

Re: [go-nuts] Re: Is there a way to create a global variable inside go routine stack? so that i can access any time, without passing around between methods/functions. Crazy thought !!!..

[Michael Jones]

Variables are names associated with values, values that can *vary*, that
is, can be changed. (Unlike constants, which are *constant* values.)

In the beginning, all variables were global, and this was not good.


Then came local variables, ones *local* to a function, which came and went
as functions executed, and then block-scoped variables, ones local to a
particular begin...end or {...} block of code. This was seen as good, and
the people were urged to avoid global variables (and *goto* and other ways
of the past).

Now, every combination of ways has a home in some language's culture:
*static* in C is a function-local global variable, Go style embraces global
variables for flag values, and there are local variables in sophisticated
assembly languages that never go to memory.

Now, what problem is it exactly that you want to solve?

On Sun, May 24, 2020 at 11:06 PM  wrote:

> Yeah this works, but you can say this as workaround, what i really want
> is, does native go support? if not why?
>
> On Monday, May 25, 2020 at 7:57:17 AM UTC+5:30, tokers wrote:
>>
>> You may try to inspect this go package: https://github.com/jtolio/gls
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3e71bdf8-3b99-4f47-9412-68cc50f69e84%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQzv8DpS%3DBG-peZj3%3D2oht%2BD%3DOoipyiK3gDGo7gaswQPDA%40mail.gmail.com.

[go-nuts] Build fails when using gollvm toolchain instead of go

[sitilge]

Hi,

I've been trying to make this project https://github.com/intel-go/nff-go using 
a freshly built gollvm to get the code compiled into LLVM IR. The project 
builds fine when using the regular go toolchain, but when trying to build 
with gollvm, I get errors such as below:

../../asm/asm.s: Assembler messages:
../../asm/asm.s:6: Error: no such instruction: `text 
·RteCompilerRmb(SB),NOSPLIT,$0-0'
../../asm/asm.s:9: Error: no such instruction: `text 
·RteCompilerWmb(SB),NOSPLIT,$0-0'
../../asm/asm.s:12: Error: no such instruction: `text 
·Prefetcht0(SB),NOSPLIT,$0-8'
../../asm/asm.s:13: Error: junk `(FP)' after expression
../../asm/asm.s:13: Error: too many memory references for `movq'
../../asm/asm.s:16: Error: no such instruction: `text 
·GenerateMask(SB),NOSPLIT,$0-33'
../../asm/asm.s:17: Error: junk `(FP)' after expression
../../asm/asm.s:17: Error: too many memory references for `movq'
../../asm/asm.s:18: Error: junk `(FP)' after expression
../../asm/asm.s:18: Error: too many memory references for `movq'
../../asm/asm.s:19: Error: junk `(FP)' after expression
../../asm/asm.s:19: Error: too many memory references for `movq'
../../asm/asm.s:20: Error: junk `(FP)' after expression
../../asm/asm.s:20: Error: too many memory references for `movq'
../../asm/asm.s:21: Error: too many memory references for `vmovdqu'
../../asm/asm.s:22: Error: too many memory references for `vmovdqu'
../../asm/asm.s:23: Error: too many memory references for `vmovdqu'
../../asm/asm.s:24: Error: too many memory references for `vpcmpeqb'
../../asm/asm.s:25: Error: too many memory references for `vpand'
../../asm/asm.s:26: Error: too many memory references for `vptest'
../../asm/asm.s:27: Error: junk `(FP)' after expression
../../asm/asm.s:27: Error: invalid instruction suffix for `sete'
../../asm/asm.s:28: Error: too many memory references for `vmovdqu'



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ca63d57c-671f-48df-8dc8-c219293a31c1%40googlegroups.com.

[go-nuts] Re: time.Ticker's behavior

[Jake Montgomery]

I'll take a crack at it. The behavior you see is one tick about 100ms after 
start, a second one marked as 200ms after start, then one 1200ms, one at 
2200, and another at 3200ms after start.

The key is in the documentation for NewTicke 
r: "It adjusts the intervals or 
drops ticks to make up for slow receivers."
If you add a bit more info to your app it becomes clearer: 
https://play.golang.org/p/gHZXgyIuYw7
Here is what is happening:

100ms - The ticker fires and sends a tick timestamped 100ms.
100ms - Your goroutine wakes, receives the tick timestamped 100ms.
100+ms - Your goroutine goes to sleep at line 30 (for one second).
200ms - The ticker fires again, but your goroutine is asleep.
300ms - Since the last tick has not been processed, the ticker waits, as 
described in the docs: "It adjusts the intervals or drops ticks to make up 
for slow receivers."
1100ms - Your goroutine wakes, receives the tick timestamped 200ms.
1100+ms Your goroutine goes to sleep at line 30 (for one second).
1200ms - Since the tick was processed the ticker sends its next tick.
1300ms - Since the last tick has not been processed, the ticker waits, as 
described in the docs: "It adjusts the intervals or drops ticks to make up 
for slow receivers."
2100ms - Your goroutine wakes, receives the tick timestamped 1200ms
2100ms - Your goroutine goes to sleep at line 30 (for one second).
2200ms - Since the tick was processed the ticker sends its next tick.
2300ms - Since the last tick has not been processed, the ticker waits, as 
described in the docs: "It adjusts the intervals or drops ticks to make up 
for slow receivers."

It continues on like that until the program exits after 3600ms. 

Hope this helps.

On Monday, May 25, 2020 at 12:14:24 AM UTC-4, Kai Zhang wrote:
>
> Hello,
>   I'm using ticker to do some batch works.But I found why tickers runs 
> not as expect.why the second ticker is 100 Millisecond.code is here 
> 
> thanks,
> zhangkai
> 2020-05-25
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cd72e6fd-b673-4573-bf12-4171359bbff6%40googlegroups.com.

[go-nuts] Re: time.Ticker's behavior

[Brian Candler]

You asked for ticks at 100ms intervals, but your receiver has a 
time.Sleep(1*time.Second).

See https://golang.org/pkg/time/#NewTicker
"It adjusts the intervals or drops ticks to make up for slow receivers."

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bae3f0d6-becc-4ad3-88e1-86f204a85b72%40googlegroups.com.

Re: [go-nuts] Maddy - composable all-in-one mail server

[Kevin Chadwick]

Looks quite good, but when did security become interchangeable with encryption 
support.

"Single process model allows more efficient implementation."

Why does security so often take a back seat to security. Also I doubt the qmail 
or OpenSMTPD priv sep models would slow it down. It might, if tcp or the fs was 
used for better cross platform support 樂

Qmail used fs in places to try to guarantee, no loss of messages, once accepted.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/DFA5ACC0-873B-47A6-B00C-0F4B64F4A59B%40gmail.com.

Re: [go-nuts] Is it acceptable to make the optional parameter as varargs

[Amarjeet Anand]

Thanks Robert for the nice idea.
Using builder pattern to set options didn't come to my mind. Looks really
clean.

On Mon, 25 May, 2020, 10:55 AM robert engels,  wrote:

> I think the Builder pattern is easier than this, and it retains the
> property of both ‘config struct’ and ‘multiple args’ versions that the
> implementation can re-order and validate option in aggregate easier - but
> most of all is doesn’t pollute that package with top-level public
> functions. The builder pattern uses instance methods to tie the function to
> the configuration structure,
>
> On May 24, 2020, at 11:36 PM, Amarjeet Anand 
> wrote:
>
> Thanks James for your response and the amazing posts.
>
> On Mon, May 25, 2020 at 9:01 AM James  wrote:
>
>> This reminds me of functional options which I think are used quite widely
>> for this purpose.
>>
>> See
>> https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
>>  and
>> https://github.com/tmrts/go-patterns/blob/master/idiom/functional-options.md
>>
>> On Mon, 25 May 2020 at 14:57, Amarjeet Anand <
>> amarjeetanandsi...@gmail.com> wrote:
>>
>>> Is it acceptable to make the optional parameter as varargs?
>>> I wrote code in my package like ...
>>>
>>>
>>> package backoff
>>>
>>> func New(options ...Options) *backOff {
>>>backOff := defaultBackOff()
>>>if len(options) == 0 {
>>>   return backOff
>>>}
>>>
>>>// override default values
>>>if len(options) > 1 {
>>>   panic("only 1 backOffOption allowed")
>>>}
>>>optn := options[0]
>>>backOff.options = 
>>>
>>>if optn.Delay_ms > 0 {
>>>   backOff.delay_ms = optn.Delay_ms
>>>}
>>>return backOff
>>> }
>>>
>>>
>>>
>>> So that in other package, it can be used as *backoff.New()* when option
>>> is not needed(*which will be the case most of the time*).
>>>
>>> Is using varargs for optional parameter is ok? Or am I abusing the
>>> Variadic Functions feature?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CANFuhy8nhhbBDWb0%3D7SLvq1aictC9GVG%3D9zpfpJ1gevDdRmd6A%40mail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANFuhy9Aj%2Bo7M-%3Dstro5aXbjPTnCZ0y_4vYE3CAjDiBpCUhjpw%40mail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/67D5D073-044A-4274-9DF4-EE786F08AD65%40ix.netcom.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAORUUQVVMu7XgKMkouq2dRCjQjnLbT5qx9Q7zKnG7tTj35Uz_w%40mail.gmail.com.

[go-nuts] Re: Is there a way to create a global variable inside go routine stack? so that i can access any time, without passing around between methods/functions. Crazy thought !!!..

[adithyasashasai]

Yeah this works, but you can say this as workaround, what i really want is, 
does native go support? if not why?

On Monday, May 25, 2020 at 7:57:17 AM UTC+5:30, tokers wrote:
>
> You may try to inspect this go package: https://github.com/jtolio/gls
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3e71bdf8-3b99-4f47-9412-68cc50f69e84%40googlegroups.com.