[go-nuts] Re: Unexpected lack of parallel speedup

[Clark Wierda]

I don't have specific answers, but I do have some thoughts.

First, the externally parallel has no overhead related to coordination.  I 
would expect you to get the result you have of full core utilization and 
nearly perfect scaling.

As soon as you have a common resource, you will have the related overhead 
due to management of the concurrent actions.  The actual cost will be 
determined by how much contention you have for that resource.

Have you looked at your program using the Go Profiler?  I found the output 
quite useful in determining where my program was spending its time. 
 Another thing to check is CPU load.  Are you saturating the CPU with 6 
threads.  If not, you are likely waiting somewhere.

There are good resources online about using the Profiler to debug 
performance issues.  I apologize for not including them here.

On Saturday, October 29, 2016 at 3:42:02 PM UTC-4, Florian Weimer wrote:
>
> I'm trying to parse OpenPGP key server dumps.  Throughput is not too 
> bad so far, but I'd like to speed things up by introducing 
> parallelism. 
>
> The dumps are split into several files (each about 40 MB large, with a 
> few thousand keys).  The toy version I have so far does not need any 
> coordination between the processing of individual files 
>
> This works quite well when running the sequential version in parallel, 
> using GNU parallel.  With GOMAXPROCS=1, serial execution time is 
> reduced from 141 seconds to 31 seconds.  This is roughly what I would 
> expect from six cores with hyperthreading and use of GNU parallel 
> (which has some overhead of its own in this scenario). 
>
> However, the version with built-in parallelism runs in 55 seconds, so 
> only half as fast as the GNU parallel approach.  I would have expect 
> it to fare better compared to that.  The parallel version is my second 
> one which has decent performance.  I also tried a variant which has a 
> per-thread buffer which is occasionally written to standard output, 
> synchronized by a sync.Mutex.  (It would likely have benefited from a 
> sync.Mutex.TryLock() function, delaying the buffer flush if there was 
> contention.)  This was still significantly slower than the external 
> parallelization, but perhaps a little faster than parallel version 
> attached below.  I think both parallel approaches produce more garbage 
> than the sequential version, but likely not as much to explain the 
> speed difference compared to the sequential version with external 
> parallelization. 
>
> “perf top” suggests that a lot of time is spent in GC-related Go 
> functions (which is expected, considering what the program does).  But 
> vmstat shows a large number of context switches, which I find 
> surprising.  It is much higher than the number of context switching 
> during a GNU parallel run. 
>
> Most tests were run with the current master branch. 
>
> Is there anything else I could try to make the internally parallized 
> version as fast the externally parallized one? 
>
>
>

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

Re: [go-nuts] How to deal with "Expect: 100-continue" *without* sending a 100 status

[jrwren]

Sorry to resurrect a month old thread, but I just implemented bullet #2 
with this patch.

I need to disable the automatic 100-continue behavior so that my handler 
can reply with a 40X status before the client read the 100-contine and 
starts sending data.



On Saturday, September 17, 2016 at 12:08:29 AM UTC-4, David Anderson wrote:
>
> Tricky one. A couple of options spring to mind, none of them amazingly 
> good:
>
>- Use a GCE Network LB instead of HTTP LB. You can bring the TCP 
>sessions straight to your web servers, with load-balancing done 
>per-TCP-session rather than per-HTTP-request.
>- Build your web server using a modified Go stdlib codebase that 
>removes this conditional block: 
>https://golang.org/src/net/http/server.go#L1562 . If you do this, I 
>suggest also filing a bug against Go to evaluate whether "don't do 
>automatic Continue support" should be added as a Server knob.
>- Stick the Go web servers behind a non-Go proxy layer (e.g. nginx) 
>that strips out the "Expect: 100-continue" header before forwarding to the 
>Go server. Run one nginx per Go server, on the same machines (or in the 
>same Kubernetes pods if using GKE), so that the system properties look the 
>same from the POV of the upstream load-balancer (same number of backends, 
>same arrangement...).
>- Wait for GCE to support 100-Continue. Given that 100-Continue is 
>almost non-existent on the web, personally I wouldn't hold my breath, I 
>suspect it's a low-priority item.
>- You say your clients can't be modified... Can't they? I've never 
>heard of browsers using 100-Continue unprompted, so if it is just 
>chrome/firefox/IE, what are you doing that's causing them to use 
>100-Continue? Or are they some other client software like Mercurial?
>
> - Dave
>
> On Fri, Sep 16, 2016 at 10:00 AM, Ian Rose  > wrote:
>
>> Howdy,
>>
>> I'm currently running a group of Go web servers behind an HTTP(s) load 
>> balancer on Google Compute Engine.  Unfortunately I have learned that GCE 
>> load balancers do not support the "Expect: 100-continue" header [1].  From 
>> my experiments, it appears that it isn't actually the request header that 
>> causes the problem, but instead is the server's "100 Continue" response 
>> that the load balancer dies on.  Specifically, the load balancer responds 
>> with a 502 to the client.
>>
>> Any suggestions on how to deal with this?  We don't control our clients 
>> (they are just "browsers across the internet") so solving things on that 
>> side isn't possible.  After digging through the net/http code a bit, my 
>> best thought is to hijack the connection, which (I think) will prevent a 
>> "100 Continue" status from being sent.  I'm concerned, however, that this 
>> won't work in all cases - for example http2 connections are not hijackable (
>> https://github.com/golang/go/issues/15312).
>>
>> Is there a better path forward?
>>
>> Thanks,
>> Ian
>>
>> [1] https://code.google.com/p/google-compute-engine/issues/detail?id=298 
>>   (also see "notes and restrictions" here: 
>> https://cloud.google.com/compute/docs/load-balancing/http/)
>>
>> -- 
>> 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.
diff --git a/src/net/http/server.go b/src/net/http/server.go
index 51a66c3..6c01228 100644
--- a/src/net/http/server.go
+++ b/src/net/http/server.go
@@ -1679,14 +1679,16 @@ func (c *conn) serve(ctx context.Context) {
 
 		// Expect 100 Continue support
 		req := w.req
-		if req.expectsContinue() {
-			if req.ProtoAtLeast(1, 1) && req.ContentLength != 0 {
-// Wrap the Body reader with one that replies on the connection
-req.Body = {readCloser: req.Body, resp: w}
+		if !c.server.NoAuto100Continue {
+			if req.expectsContinue() {
+if req.ProtoAtLeast(1, 1) && req.ContentLength != 0 {
+	// Wrap the Body reader with one that replies on the connection
+	req.Body = {readCloser: req.Body, resp: w}
+}
+			} else if req.Header.get("Expect") != "" {
+w.sendExpectationFailed()
+return
 			}
-		} else if req.Header.get("Expect") != "" {
-			w.sendExpectationFailed()
-			return
 		}
 
 		c.curReq.Store(w)
@@ -2246,6 +2248,11 @@ type Server struct {
 	// standard logger.
 	ErrorLog *log.Logger
 
+	// NoAuto100Continue disabled the default behavior of the
+	// server to automatically reply with a 100-continue response
+	// before invoking a handler.
+	NoAuto100Continue 

Re: [go-nuts] Re: Working with "characters" in strings

[Rob Pike]

Please read blog.golang.org/strings.

-rob


On Sat, Oct 29, 2016 at 12:08 PM,  wrote:

> thanks! whats the "a:b" in this instance? did you mean s[i:i+1]? wouldn't
> that return a slice?
>
> so when iterating I'm comparing/using runes but what is the best way to
> refer to the ASCII values?
>
>
>
> On Saturday, October 29, 2016 at 9:36:57 AM UTC-7, Tamás Gulácsi wrote:
>>
>> 1. create the slice  (ss := make([]string, n)) and fill up (ss[i] =
>> s[a:b]), this will reuse the s's backing array, so use only the pointer to
>> the backing array and a length.
>> 2. rune is a unicode code point, an alias for int32. A string is an utf-8
>> encoded representation of a slice of runes: rr := []rune(s). `for _, r :=
>> range s` will range through the runes in the string. That utf-8 encoding
>> may use at most 4 bytes for a code point, but uses exactly 1 byte per ASCII
>> character.
>
> --
> 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] Unexpected lack of parallel speedup

[Florian Weimer]

I'm trying to parse OpenPGP key server dumps.  Throughput is not too
bad so far, but I'd like to speed things up by introducing
parallelism.

The dumps are split into several files (each about 40 MB large, with a
few thousand keys).  The toy version I have so far does not need any
coordination between the processing of individual files

This works quite well when running the sequential version in parallel,
using GNU parallel.  With GOMAXPROCS=1, serial execution time is
reduced from 141 seconds to 31 seconds.  This is roughly what I would
expect from six cores with hyperthreading and use of GNU parallel
(which has some overhead of its own in this scenario).

However, the version with built-in parallelism runs in 55 seconds, so
only half as fast as the GNU parallel approach.  I would have expect
it to fare better compared to that.  The parallel version is my second
one which has decent performance.  I also tried a variant which has a
per-thread buffer which is occasionally written to standard output,
synchronized by a sync.Mutex.  (It would likely have benefited from a
sync.Mutex.TryLock() function, delaying the buffer flush if there was
contention.)  This was still significantly slower than the external
parallelization, but perhaps a little faster than parallel version
attached below.  I think both parallel approaches produce more garbage
than the sequential version, but likely not as much to explain the
speed difference compared to the sequential version with external
parallelization.

“perf top” suggests that a lot of time is spent in GC-related Go
functions (which is expected, considering what the program does).  But
vmstat shows a large number of context switches, which I find
surprising.  It is much higher than the number of context switching
during a GNU parallel run.

Most tests were run with the current master branch.

Is there anything else I could try to make the internally parallized
version as fast the externally parallized one?

package main

import (
"bytes"
"bufio"
"flag"
"fmt"
"io"
openpgp "golang.org/x/crypto/openpgp/packet"
"os"
"reflect"
"runtime"
"sync"
)

var verbose bool

var outputLock sync.Mutex

// Print the string to standard output, with optional synchronization.
type Output interface {
Print(format string, args ...interface{})
}

func packetError(path string, packet openpgp.OpaquePacket, err error) {
outputLock.Lock()
defer outputLock.Unlock()
}

func printPacketType(packet openpgp.Packet) {
outputLock.Lock()
defer outputLock.Unlock()
}

// A printer for OpenPGP user IDs which writes multiple key IDs en
// bloc, to avoid lock contention.
type uidPrinter struct {
buffer bytes.Buffer
count int
}

// Print one user ID.  The user ID might not be printed until Flush()
// is called.
func (p *uidPrinter) Print(uid *openpgp.UserId) {
fmt.Fprintf(, "uid: %#v\n", uid.Id)
p.count++
// Prevent the buffer from becoming too large.
if p.count > 1000 {
p.Flush()
}
}

// Print all the staged key IDs.
func (p *uidPrinter) Flush() {
outputLock.Lock()
defer outputLock.Unlock()
os.Stdout.Write(p.buffer.Bytes())
p.buffer.Truncate(0)
p.count = 0
}

func printError(format string, args ...interface{}) {
outputLock.Lock()
defer outputLock.Unlock()
fmt.Fprintf(os.Stderr, format, args...)
}

func readFile(path string, output Output) error {
file, err := os.Open(path)
if err != nil {
return err
}
defer file.Close()
buf := bufio.NewReader(file)
packets := openpgp.NewOpaqueReader(buf)
for {
op, err := packets.Next()
if err != nil {
if (err == io.EOF) {
break
}
return err
}
p, err := op.Parse()
if err != nil {
continue
}
if verbose {
output.Print("%s\n", reflect.TypeOf(p).String())
}
if uid, ok := p.(*openpgp.UserId); ok {
output.Print("uid: %#v\n", uid.Id)
}
}
return nil
}

// Buffered output to standard output, without synchronization.
type sequentialOutput struct {
buffer *bufio.Writer
}

func newSequentialOutput() *sequentialOutput {
return {bufio.NewWriter(os.Stdout)}
}

func (p *sequentialOutput) Print(format string, args ...interface{}) {
fmt.Fprintf(p.buffer, format, args...)
}

func (p *sequentialOutput) Stop() {
p.buffer.Flush()
}

func processSequential(files []string) {
output := newSequentialOutput()
for _, path := range files {
err := readFile(path, output)
 

[go-nuts] golang.org/x/crypto/openpgp RSA public exponent size limit

[Florian Weimer]

PublicKey.parseRSA() has this check:

if len(pk.e.bytes) > 3 {
err = errors.UnsupportedError("large public exponent")
return
}

I get that it is valuable to limit the exponent size, but this limit
is too low: quite a few RSA keys in a dump from the public key server
network cannot be parsed as a result.

Is there are reason for this really low limit?

-- 
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: [golang-dev] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Russ Cox]

+golang-nuts bcc golang-dev

On Fri, Oct 28, 2016 at 11:26 PM  wrote:

> If you don't like the framework just don't use it.
> I'm using this framework in production for a long time and the author
> makes his best to solve any incoming issue.
>
> He, literally, gave his personal time and money to see that project
> growning up.
>
> You seem a low person, mentally,  who calls another person, who is unknown
> to you, a 'thief' and that's a crime by your side, the whole post contains
> moral characterizations and I am wondering why the forum moderators let
> your post to be published.
>
> Τη Πέμπτη, 27 Οκτωβρίου 2016 - 2:35:43 μ.μ. UTC+3, ο χρήστης Aram
> Hăvărneanu έγραψε:
>
> I have received a very insulting and distressing e-mail from Sarah
> Adams, who claims to represent the The Go Code of Conduct Team, an
> illicit bully organization who claims authority about what Go
> contributors think and say outside the Go mailing lists. I do not
> recognize this group's legitimacy in these matters.
>
> The e-mail says:
>
> We received a report about your comment on this thread
>
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
> :
> "Their English was so bad I couldn't understand what was
> going on".
>
> This comment goes against our community Code of Conduct,
> https://golang.org/conduct. The comment is not respectful,
> and would have been more productive just as, "I couldn't
> understand what was going on".
>
> Please consider this a warning from the Code of Conduct
> working group.
>
> Some more context is necessary. There is someone in the Go community
> who literally steals other people's code, receives money for it,
> and actively tries to covers his tracks.
>
> A person named Florin Pățan provided an overview:
>
> [1]
> http://www.florinpatan.ro/2016/10/why-you-should-not-use-iris-for-your-go.html
>
> which has been discussed on reddit:
>
> [2]
> https://www.reddit.com/r/golang/comments/57tmp1/why_you_should_not_use_iris_for_your_go_projects
> .
>
> Reddit also discussed this thief's action in another thread:
>
> [3]
> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/
>
> I have archived these documents here:
>
> [1] http://archive.is/9oN1A
> [2] http://archive.is/Q36G5
> [3] http://archive.is/aSFUg
>
> The comment in question refers to this GitHub issue, also archived:
>
> [4] https://github.com/avelino/awesome-go/pull/1137
> [4] http://archive.is/7xgc7
>
> Now take a look at what I said, and what Sarah Adams in her
> infinite arrogance suggests I should have said:
>
> Aram: Their English was so bad I couldn't understand what
>  was going on
>
> Sarah: I couldn't understand what was going on
>
> If you compare these two phrases: you can see that the problem Sarah
> Adams has is with "their English was so bad".
>
> In other words, Sarah's problem is with speaking the objective
> *TRUTH*.
>
> Whether someone speaks good or bad English is an objective fact
> easily determined by anyone who speaks English at some level of
> proficiency. I encourage all English speakers to take a look at [4]
> and do an individual assessment of the level of proficiency in English
> those sock puppets possess.
>
> I will not be policed around for telling the *TRUTH*. I will not
> be silenced into political compliance. I will not tolerate other
> people who tell me what is acceptable to say, especially when these
> people only want to hide the *OBJECTIVE TRUTH*.
>
> The comment is not respectful
>
> Damn right it wasn't. You or your organization has no authority
> mandating how respectful my speech is. What level of arrogance.
>
> However, it was not disrespectful. It was an objective assessment
> of an *infractor's* level of English competence.
>
> I owe nobody respect. Certainly not someone who breaks the law and
> steals other people's intellectual property. Respect is earned.
>
> and would have been more productive just as
>
> Ah, yes, here you can see in action the new-age practice of corporate
> double speak applied to open source projects. This is not Google.
> You are not fooling me or anyone else who still has a grain of
> independent thought left.
>
> This is a pathetic and disgusting attempt of silencing independent
> contributors who still refuse to kneel after your coup d'état in
> which you managed to replace the Go technical governance with a
> thought police political organization vassal to Google.
>
> In some sense, you have succeeded. I will never yield to you, you
> can never silence me, but you certainly made me realise that my
> association with the Go project is a mistake and a liability. I do
> not want to be associated with your organization, even accidentally.
> When I contribute to Go, I only make you people stronger. In fact,
> this is your modus operandi; you rely on people who do the actual
> technical work (either as part of the Go team, or as contributors)
> in order to gain more support 

[go-nuts] Global logger not concurrent safe ?

[Tamás Gulácsi]

First try to run with the race detector - compile with "-race" flag, and fix 
EVERY race!

You may coordinate the mutators and readers by using channels or mutexes.

-- 
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] Global logger not concurrent safe ?

[Tamás Gulácsi]

First try to run with the race detector - compile with "-race" flag, and fix 
EVERY race!

You may coordinate the mutators and readers by using channels or mutexes.

-- 
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: CGO: How to link static library across dependent packages?

[kumargv]

Hi Mate,

why Don't you try to make a static binary 

go build --ldflags ' -extldflags "-static"' filename.go

On Thursday, October 27, 2016 at 8:10:55 PM UTC+5:30, pat.s...@gmail.com 
wrote:
>
> Folks,
>
> Two of my packages have dependency on the same C library. I have linked 
> them successfully using the LDFLAGS directives. 
>
> But I'm facing a multiple definitions error when linking my project 
> executable
>
>
> Here is an overview of my project structure:
>
> Pkg A -> depends on LIBA
>
> Pkg B (imports Pkg A) -> and also depends on LIBA
>
> Pkg Main imports B
>
>
> Commands used to build: In Pkg Main directory: go build
>
>
>
> Appreciate any thoughts on this issue
>
>
> 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] Logging concurrent safe ?

[Peter Mogensen]

On 2016-10-29 13:37, Łukasz Kostka wrote:

Hi.

In docs  I can see that logger can
be safely used in multiple coroutines. I've implemented
 this,
but my program seems to freeze at random. Am I doing something wrong ?


It's most likely not your use of logging which makes it freeze.

Try run it with -race ...

If that doesn't panic, then just try to send the process a signal 6 
(SIGABRT) ... and look at the stack-trace output to see where each 
go-routine is when it's frozen.


/Peter

--
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]: httptp - http(s) proxy and load balancer that saves network bandwidth

[Aliaksandr Valialkin]

Hi all,

I'd like to announce httptp 
 - http(s) 
proxy and load balancer that saves network bandwidth. It is built on top of 
httpteleport 
package .

Any highly loaded http-based API service and microservice may benefit from 
httptp usage. Here are a few buzzwords related to such services:

   - RTB 
   - REST 
   - JSON-RPC 
   - XML-RPC 
   

*Features*

   - Easy to use and configure - just run a single httptp binary with 
   required command-line options.
   - Fast. It is based on fasthttp . 
   Easily handles more than 100K qps.
   - May reduce required network bandwidth between servers by up to 10x
   - Supports encrypted connections on both -in and -out ends.
   - HTTP keep-alive connections 
    are used by 
   default on both -in and -out ends. httptp easily handles more than 100K of 
   incoming concurrent keep-alive connections.
   - May substitute nginx in reverse proxy 
    mode, load balancer 
    mode and TLS 
   offloading  mode.
   - Automatically adjusts load to upstream servers:
  - Faster servers receive more requests.
  - Slower and unhealthy servers receive less requests.
   - May limit the maximum number of open connections per upstream host.
   - May accept and/or forward http requests from/to unix sockets.
   - Collects and exports various stats at /expvar page.
   - Easy to extend and customize. httptp is open source software written 
   in Go . It is released under MIT license 
   , 
   so it may be easily customized and extended.
   

-- 
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] CGO: How to link static library across dependent packages?

[Ian Lance Taylor]

On Fri, Oct 28, 2016 at 9:36 PM,   wrote:
>
>>go build
> # agent
> //goLang/go/pkg/tool/linux_amd64/link: running gcc failed: exit status
> 1
> //tmp/go-link-022070709/01.o: In function `putStringToBuffer':
> //goLang/goCode/src/eventbridge/EventBridge.c:31: multiple definition
> of `putStringToBuffer'
> //tmp/go-link-022070709/00.o://goLang/goCode/src/eventbridge/EventBridge.c:31:
> first defined here
> //tmp/go-link-022070709/01.o: In function `ReceiveEventBuffer':
> //goLang/goCode/src/eventbridge/EventBridge.c:446: multiple definition
> of `ReceiveEventBuffer'
> //tmp/go-link-022070709/00.o://goLang/goCode/src/eventbridge/EventBridge.c:446:
> first defined here
> //tmp/go-link-022070709/01.o: In function `getStringFromBuffer':
> //goLang/goCode/src/eventbridge/EventBridge.c:37: multiple definition
> of `getStringFromBuffer'
> //tmp/go-link-022070709/00.o://goLang/goCode/src/eventbridge/EventBridge.c:37:
> first defined here

This looks like your cgo comment, before the import "C", is actually
defining functions rather than simply declaring them.  What does the
cgo comment look like?

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] Global logger not concurrent safe ?

[ukasz83]

Hi.

I'd like to have some easy logging/debugging mechanism for my program 
. In log 
documentation  I can see that logger is 
guaranteed to be thread safe and can be used in multiple goroutines. I've 
implemented a simple debug logger and upload process freezes from time to 
time. Also random freeze occur. Am I doing something wrong ? 

-- 
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] Working with "characters" in strings

[so . query]

I know that strings are an immutable sequence of bytes, so what would be 
the most idiomatic way to handle the following operations.


   - Convert a string to []string (slice) or [n]string (array). Eg. 
   "foobar" to ["f" "o" "o" "b" "a" "r"]


   - Iterate through a string and evaluate the rune directly as a string
   
str := "foo"

for _,char := range "bar" {

 // should concatenate a character at a time

  str += char // requires cast string(char) correct?

}


Also what is the relationship between a "rune" and the "byte" that a string 
is composed of?

If you have other advice for working with individual string "character" of 
a string for other scenarios I'd appreciate 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.

[go-nuts] Working with characters in strings

[so . query]

I understand that strings are immutable sequences of bytes and wanted to 
know how to idiomatically work with the "characters" within a string.

For example how should I approach the following operations


   - Convert a string to a []string (slice or array). eg. "foobar" to ["f" 
   "o" "o" "b" "a" "r"]


   - Iterate through a string by "character" strings instead of runes, for 
   example:

str := "foo"
for _,char := range "bar" {
str += char // is a cast string(char) required?
}
fmt.Println(str) // print "foobar"



Also what is the relationship between a rune and it's byte representation?

Any additional advice for working with characters of strings would be 
appreciated as well.

-- 
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] Logging concurrent safe ?

[Łukasz Kostka]

Hi.

In docs  I can see that logger can be 
safely used in multiple coroutines. I've implemented 
 this, but 
my program seems to freeze at random. Am I doing something wrong ?

-- 
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: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[Sokolov Yura]

I don't like CoC.
But I like wise moderation.
I may to be toxic sometimes. I think, it is inevitable human nature (although 
some tries to look like sweet candies).
But I don't want to be extremly toxic. I do not want to offend without reason.

I've been contacted privately by Andrew Gerrand two times last month. Both time 
i was a bit toxic. First time I really didn't want to offend a man, I just want 
to stimulate him. Second time I was angry on other man, cause he was annoying 
and not attentive to discussions, and I used light curse.
Both times I described my position without try to make it public.

Third time I was warned in public.

I think Andrew Gerrand is adequate and correct moderator.
I do not bind his actions with CoC, cause I don't like CoC.
But I like wise moderation.

This discussion is hysterical. It smell like spew.
Instead of private dialog with moderator, Aram hurried up to make public holy 
war.

Although I agree that "their english was so bad" is just subjective impression 
and not offence, I could not understand: why Aram didn't try explain it to 
Sarah?

Holy war could be started at any point of time.
But war is just destruction.
And discussion is creation.
And court is regulation.

What is this discussion? It doesn't smell like a creation or regulation. It 
smells like destruction.

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