Re: [go-nuts] Go 1.8 released. What's new?

[Konstantin Khomoutov]

On Mon, 20 Feb 2017 22:32:06 -0800 (PST)
pltvs  wrote:

> What's new in Go 1.8 

We gather what's new in the new releases via the officially published
release notes.  For Go 1.8 that's [1].

1. https://golang.org/doc/go1.8

-- 
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 Build and Install Go 1.7.4 in OpenBSD 5.9

[Dave Cheney]

It looks like one test in the os/exec package failed during the tests which 
are run during ./all.bash

--- FAIL: TestStdinCloseRace (0.04s)
exec_test.go:267: Kill: os: process already finished
FAIL
FAILos/exec 0.371s

At this point Go is fully built, so you may wish to ignore this error, 
however it would be good if you would raise a bug report, 
https://golang.org/issue/new.

Thanks

Dave

On Tuesday, 21 February 2017 17:33:56 UTC+11, Srikanth Chandika wrote:
>
> I tried installing go1.8 from source(https://golang.org/doc/install/source) 
> but I am getting error saying that "2017/02/21 17:05:18 Failed: exit status 
> 1"
>
> Attached a file(output of ./all.bash)
>
>
> On Tuesday, February 21, 2017 at 1:13:53 AM UTC+5:30, Ian Lance Taylor 
> wrote:
>>
>> On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika 
>>  wrote: 
>> > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9. 
>>
>> It's no different from building Go from source on any other system. 
>>
>> https://golang.org/doc/install/source 
>>
>> Note that the current release is now 1.8, but the procedure hasn't 
>> changed since 1.7. 
>>
>> 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] How to Build and Install Go 1.7.4 in OpenBSD 5.9

[Srikanth Chandika]

I tried installing go1.8 from source(https://golang.org/doc/install/source) 
but I am getting error saying that "2017/02/21 17:05:18 Failed: exit status 
1"

Attached a file(output of ./all.bash)


On Tuesday, February 21, 2017 at 1:13:53 AM UTC+5:30, Ian Lance Taylor 
wrote:
>
> On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika 
>  wrote: 
> > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9. 
>
> It's no different from building Go from source on any other system. 
>
> https://golang.org/doc/install/source 
>
> Note that the current release is now 1.8, but the procedure hasn't 
> changed since 1.7. 
>
> 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.


all.bash(go src)
Description: Binary data

[go-nuts] Go 1.8 released. What's new?

[pltvs]

What's new in Go 1.8 

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

Re: [go-nuts] is this race condition normal?

[Michael Jones]

no. not only is there no guarantee, there is in fact a promise that you are
mistaken to count on any order between the two.

also, in an extreme case where func1 and func2 did not produce output (like
a channel) consumed by someone who waits for them...in which case neither
of them may run at all!

On Tue, Feb 21, 2017 at 12:41 AM, Marwan abdel moneim 
wrote:

> even if i wrote
>
>> go func1
>
> go func2
>
>
> is there any guarantee that func1 will run first? even just the first
> instruction?
>
> On Sunday, February 19, 2017 at 11:25:34 PM UTC+2, Jesper Louis Andersen
> wrote:
>>
>> On Sun, Feb 19, 2017 at 9:41 AM Marwan abdel moneim 
>> wrote:
>>
>>> i wanted to do it without a Mutex
>>> but there still something not clear to me, but i don't know what it is
>>> and i don't understand what "trigger" synchronization means
>>>
>>>
>> Modern CPUs achieve much of their speed by running instructions
>> out-of-order and completing them out of order as well. The CPU operates on
>> multiple instructions at the same time, and 50 instructions is not unheard
>> of. They also write data back to caches and memory in the background while
>> doing other things. This means that your memory is "eventually consistent"
>> in the sense that eventually data will be written back. But there is no
>> guarantee when that is, and "never" is a valid option in some extreme cases.
>>
>> In a system with multiple physical cores, different cores may see wildly
>> different data in memory because of the above optimizations. As a result,
>> any unsynchronized operation is undefined behavior: it may read anything or
>> never store data correctly.
>>
>> Go, and most other languages, provide some kind of guaranteed memory
>> model which explains exactly when the system makes sure that data written
>> back to memory is consistent, so other processor cores (and thus
>> goroutines) can safely read the data. In Go, the memory model concerns
>> itself about Mutex'es and channel's specifically.
>>
>> The Go compiler is then responsible for taking a particular processor
>> architecture, x86-64, AArch64, ..., and map its specific internal data
>> coherency model onto the Go memory model, so you get the same guarantees,
>> irrespective of what architecture your program is running on.
>>
>> This also holds true for a C program, and in particular for C programs:
>> The C compilers are often very aggressive in their optimizations and as a
>> result they have a penchant for optimizing away operations if they can.
>> Without proper synchronization, this may wreak havoc on your programs.
>>
>> It must also be said that many programs look correct, but are actually
>> faulty w.r.t to synchronization safety. It is common, for instance, that
>> the problems only start showing once you start loading your program with
>> more work. That is, the program tests correct, but fails in a load
>> benchmark or production, whichever happens first.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: [go-nuts] How to Build and Install Go 1.7.4 in OpenBSD 5.9

[Srikanth Chandika]

openbsd/ports(https://github.com/openbsd/ports/tree/master/lang/go) is a
repository for openbsd linux.

Now, I am trying as per the instructions in https://golang.org/doc/
install/source

I am trying to upgrade go version from 1.5.3 to 1.7+ version because I need
to build a filebeat from source code which is in go lang.
Filebeat source code build pre-requisite is minimum go 1.7 version.


On Tue, Feb 21, 2017 at 11:09 AM, Ian Lance Taylor  wrote:

> On Mon, Feb 20, 2017 at 9:36 PM, Srikanth Chandika
>  wrote:
> > Ya I have compiled go from https://github.com/openbsd/ports
> > Successfully compiled go 1.7 but when I run go it gives the following
> error.
> >
> > go package: unsupported TLS program header
>
> What precisely do you do?  What precisely happens?
>
> Note that I don't know anything about what is in openbsd/ports.  I
> don't see that string anywhere in the standard Go source code.
>
> Ian
>
> > On Tue, Feb 21, 2017 at 1:13 AM, Ian Lance Taylor 
> wrote:
> >>
> >> On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika
> >>  wrote:
> >> > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9.
> >>
> >> It's no different from building Go from source on any other system.
> >>
> >> https://golang.org/doc/install/source
> >>
> >> Note that the current release is now 1.8, but the procedure hasn't
> >> changed since 1.7.
> >>
> >> 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] is this race condition normal?

[Marwan abdel moneim]

even if i wrote  

> go func1

go func2


is there any guarantee that func1 will run first? even just the first 
instruction? 

On Sunday, February 19, 2017 at 11:25:34 PM UTC+2, Jesper Louis Andersen 
wrote:
>
> On Sun, Feb 19, 2017 at 9:41 AM Marwan abdel moneim  > wrote:
>
>> i wanted to do it without a Mutex
>> but there still something not clear to me, but i don't know what it is
>> and i don't understand what "trigger" synchronization means
>>
>>
> Modern CPUs achieve much of their speed by running instructions 
> out-of-order and completing them out of order as well. The CPU operates on 
> multiple instructions at the same time, and 50 instructions is not unheard 
> of. They also write data back to caches and memory in the background while 
> doing other things. This means that your memory is "eventually consistent" 
> in the sense that eventually data will be written back. But there is no 
> guarantee when that is, and "never" is a valid option in some extreme cases.
>
> In a system with multiple physical cores, different cores may see wildly 
> different data in memory because of the above optimizations. As a result, 
> any unsynchronized operation is undefined behavior: it may read anything or 
> never store data correctly.
>
> Go, and most other languages, provide some kind of guaranteed memory model 
> which explains exactly when the system makes sure that data written back to 
> memory is consistent, so other processor cores (and thus goroutines) can 
> safely read the data. In Go, the memory model concerns itself about 
> Mutex'es and channel's specifically.
>
> The Go compiler is then responsible for taking a particular processor 
> architecture, x86-64, AArch64, ..., and map its specific internal data 
> coherency model onto the Go memory model, so you get the same guarantees, 
> irrespective of what architecture your program is running on.
>
> This also holds true for a C program, and in particular for C programs: 
> The C compilers are often very aggressive in their optimizations and as a 
> result they have a penchant for optimizing away operations if they can. 
> Without proper synchronization, this may wreak havoc on your programs.
>
> It must also be said that many programs look correct, but are actually 
> faulty w.r.t to synchronization safety. It is common, for instance, that 
> the problems only start showing once you start loading your program with 
> more work. That is, the program tests correct, but fails in a load 
> benchmark or production, whichever happens first.
>  
>

-- 
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 Build and Install Go 1.7.4 in OpenBSD 5.9

[Ian Lance Taylor]

On Mon, Feb 20, 2017 at 9:36 PM, Srikanth Chandika
 wrote:
> Ya I have compiled go from https://github.com/openbsd/ports
> Successfully compiled go 1.7 but when I run go it gives the following error.
>
> go package: unsupported TLS program header

What precisely do you do?  What precisely happens?

Note that I don't know anything about what is in openbsd/ports.  I
don't see that string anywhere in the standard Go source code.

Ian

> On Tue, Feb 21, 2017 at 1:13 AM, Ian Lance Taylor  wrote:
>>
>> On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika
>>  wrote:
>> > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9.
>>
>> It's no different from building Go from source on any other system.
>>
>> https://golang.org/doc/install/source
>>
>> Note that the current release is now 1.8, but the procedure hasn't
>> changed since 1.7.
>>
>> 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] How to Build and Install Go 1.7.4 in OpenBSD 5.9

[Srikanth Chandika]

Ya I have compiled go from https://github.com/openbsd/ports
Successfully compiled go 1.7 but when I run go it gives the following error.

*go package: unsupported TLS program header*

On Tue, Feb 21, 2017 at 1:13 AM, Ian Lance Taylor  wrote:

> On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika
>  wrote:
> > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9.
>
> It's no different from building Go from source on any other system.
>
> https://golang.org/doc/install/source
>
> Note that the current release is now 1.8, but the procedure hasn't
> changed since 1.7.
>
> 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] unexpected end of JSON input while unmarshal to struct

[diogo . engsoftware]

Could you help me to understand why I'm always getting the error unexpected 
end of JSON input while trying to unmarshal the following json to the 
LimitOrder struct? It works if I use golang playground 
https://play.golang.org/p/udPQ_TayXG but not locally running tests.


P.S.: if I use map[string]json.RawMessage instead of LimitOrder struct I'm 
able to execute the unmarshal.


{
  "response_data": {
"order": {
  "order_id": 3,
  "coin_pair": "BRLBTC",
  "order_type": 1,
  "status": 4,
  "has_fills": true,
  "quantity": "1.",
  "limit_price": "900.0",
  "executed_quantity": "1.",
  "executed_price_avg": "900.0",
  "fee": "0.0030",
  "created_timestamp": "1453835329",
  "updated_timestamp": "1453835329",
  "operations": [
{
  "operation_id": 1,
  "quantity": "1.",
  "price": "900.0",
  "fee_rate": "0.30",
  "executed_timestamp": "1453835329"
}
  ]
}
  },
  "status_code": 100,
  "server_unix_timestamp": "1453835329"}

*LimitOrder struct*


type LimitOrder struct {
  OrderId int `json:"order_id"`
  CoinPair string `json:"coin_pair"`
  OrderType int `json:"order_type"`
  Status int `json:"status"`
  HasFills bool `json:"has_fills"`
  Quantity float64 `json:"quantity,string"`
  LimitPrice float64 `json:"limit_price,string"`
  ExecutedQuantity float64 `json:"executed_quantity,string"`
  ExecutedPriceAvg float64 `json:"executed_price_avg,string"`
  Fee float64 `json:"fee,string"`
  Operations []*Operation `json:"operations"`
  CreatedTimestamp string `json:"created_timestamp"`
  UpdatedTimestamp string `json:"updated_timestamp"`}


and this is how I'm trying to unmarshal it


func (limitOrder *LimitOrder) UnmarshalJSON(buf []byte) error {

  tmp := make(map[string]json.RawMessage)
  if err := json.Unmarshal(buf, ); err != nil {
return err
  }

  tmp2 := make(map[string]json.RawMessage)

  if err := json.Unmarshal(tmp["response_data"], ); err != nil {
return err
  }

  if err := json.Unmarshal(tmp2["order"], limitOrder); err != nil {
return err
  }

  return nil}

-- 
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: Issue with Goroutine and http.RedirectHandler

[Rejoy]

Hi,

Yes it helps!.

This is the output I get from curl -v

***output

Trying 127.0.0.1...
* connected
* Connected to 127.0.0.1 (127.0.0.1) port 8000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: 127.0.0.1:8000
> Accept: */*
> 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 301 Moved Permanently
< Location: https://127.0.0.1:8001
< Date: Tue, 21 Feb 2017 04:11:08 GMT
< Content-Length: 57
< Content-Type: text/html; charset=utf-8
< 
https://127.0.0.1:8001;>Moved Permanently.

* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0

> ***
>
the url is correct is the output from curl. However what I saw in the 
browser is the first time was the incorrect url. I then cleared the browser 
cache and subsequently the redirect worked. Didn't have to change a thing 
in the code. 

Thanks
Rejoy

-- 
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 UDP performance

[Rich]

I would wireshark the data coming in to both sides so that you can see when 
the packet was transmitted, and when it was received by the other side. 
That way you can isolate if it's network or Go.

On Monday, February 20, 2017 at 4:02:28 PM UTC-5, Tharaneedharan 
Vilwanathan wrote:
>
> Hi All,
>
> I am trying to send a lot of UDP packets from Go code but I realized UDP 
> performance is too low. The max I was able to do is about 160Mbps. This is 
> in Ubuntu 16.10 on x86_64 (i7-6700HQ).
>
> I tried to google on this and it looks like this is about the performance 
> we can get. I am a bit surprised.
>
> Am I missing something? Any suggestions on how to improve the performance?
>
> Thanks
> dharani
>
>

-- 
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] Import path search order?

[so . query]

What is the search order for the import path?
for example, relative then vendor then workspace?


-- 
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 do you implement and use Context.Done?

[so . query]

I see thanks for the additional detail.



On Monday, February 20, 2017 at 11:42:48 AM UTC-8, Ian Lance Taylor wrote:
>
> On Sun, Feb 19, 2017 at 2:57 PM,   
> wrote: 
> > Thanks, I see you build it up with decorators on a standard prototype. 
> > For example: https://play.golang.org/p/PJy5lE9QqF 
> > 
> > So context.Done is a convenience function for those that require it? 
> > Otherwise a context will expire after it leaves scope, so Done does not 
> need 
> > to be called? 
>
> Cancelling the context just marks the context as cancelled.  It does 
> not actually stop any goroutines using the context.  Those goroutines 
> must themselves periodically check the context to see whether it has 
> been cancelled, and, if so, stop working.  They do that by calling 
> either the Done or Err method; it's much more common to call the Done 
> method (and check whether the channel is closed). 
>
> 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] Question about net/http package implementation

[Dan Kortschak]

Yep. I was lazy though - I should have read the example and I could
have made a more careful parse of the text to see a lone *or" that
might have prompted further investigation.

Historical note: /, * and _ were used in text only mail and on usenet
prior to html markup contaminating email. Variously, /text/ -> italic,
*text* -> bold and _text_ -> underline (though not uniform/universal).

On Mon, 2017-02-20 at 14:25 +, Matt Harden wrote:
> Oh, interesting. The code inline to his sentences is italicized like
> *this*.
> It looks like that gets surrounded by asterisks in the text-only
> version,
> leading to confusion in this case.



-- 
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: Sensu Client - in Go!

[george . bolo]

Nice, good work. I wish that the Sensu people would consider maintaining a 
client written in go which didn't require ruby. Seems like a no brainer for 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: redeclaration in runtime/utf8.go after installing Go 1.8 on Windows

[Sjon Kosse]

I did the same thing and got this error as well. I upgraded from what I 
think was a 1.8 beta build to 1.8 release on Windows using the MSI 
installer. I thought it might have been something in the %GOPATH%\pkg 
directory so I removed that, didn't fix it. I'll do what you wrote worked 
in your post instead.

On Saturday, February 18, 2017 at 6:42:12 PM UTC+1, Vincent Rischmann wrote:
>
> Hi,
>
> I'm on Windows, I had Go 1.7.4 installed from the MSI installer. Today I 
> decided to upgrade to Go 1.8, so I downloaded the new MSI, ran it and that 
> was it.
>
> However, first package I tried to install I got the following errors:
>
> G:\Gopath\src\github.com\google> go get -u -v 
> github.com/vrischmann/ghclone 
> github.com/vrischmann/ghclone (download)
> github.com/google/go-github (download)
> github.com/google/go-querystring (download)
> runtime/internal/atomic
> runtime
> # runtime
> C:\Go\src\runtime\utf8.go:16: surrogateMin redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:49
> C:\Go\src\runtime\utf8.go:17: surrogateMax redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:50
> C:\Go\src\runtime\utf8.go:21: t1 redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:31
> C:\Go\src\runtime\utf8.go:22: tx redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:32
> C:\Go\src\runtime\utf8.go:23: t2 redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:33
> C:\Go\src\runtime\utf8.go:24: t3 redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:34
> C:\Go\src\runtime\utf8.go:25: t4 redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:35
> C:\Go\src\runtime\utf8.go:26: t5 redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:36
> C:\Go\src\runtime\utf8.go:28: maskx redeclared in this block
> previous declaration at C:\Go\src\runtime\rune.go:43 
>
> I got it working by uninstalling Go, removing the directory completely in 
> the explorer, and reinstalled Go.
>
> Shouldn't the MSI installer remove the previous Go installation before 
> installing the new files ? Not sure if I did 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] Re: Go UDP performance

[Dave Cheney]

Can you share some more details

1. which version of Go
2. which operating system
3. where are you sending from / to, is it over localhost, does the other 
side care about acknowledging receipt
4. can you show your code
5. have you profiled your code? What resource is limiting the throughput of 
your application? CPU, Operating system, network driver?

On Tuesday, 21 February 2017 08:02:28 UTC+11, Tharaneedharan Vilwanathan 
wrote:
>
> Hi All,
>
> I am trying to send a lot of UDP packets from Go code but I realized UDP 
> performance is too low. The max I was able to do is about 160Mbps. This is 
> in Ubuntu 16.10 on x86_64 (i7-6700HQ).
>
> I tried to google on this and it looks like this is about the performance 
> we can get. I am a bit surprised.
>
> Am I missing something? Any suggestions on how to improve the performance?
>
> Thanks
> dharani
>
>

-- 
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 test -race much slower in 1.8 (was Re: [go-nuts] Go 1.8 is released)

[Caleb Spare]

Hey Will, it might help to get timings for just -race and
-coverprofile (not both) to try to isolate timing increase a bit.

On Mon, Feb 20, 2017 at 12:23 PM, Ian Lance Taylor  wrote:
> On Mon, Feb 20, 2017 at 12:06 PM, Will Newton  wrote:
>> On Thu, Feb 16, 2017 at 9:01 PM, Chris Broadfoot  wrote:
>>> Hello gophers,
>>>
>>> We just released Go 1.8.
>>>
>>> You can read the announcement blog post here:
>>>   https://blog.golang.org/go1.8
>>>
>>> You can download binary and source distributions from our download page:
>>>   https://golang.org/dl/
>>>
>>> To compile from source using a Git checkout, update to the release with "git
>>> checkout go1.8" and build as usual.
>>>
>>> To find out what has changed, read the release notes:
>>>   https://golang.org/doc/go1.8
>>>
>>> Thanks to everyone who contributed to the release.
>>
>> After upgrading to Go 1.8 from Go 1.7 our testsuite runtime has gone
>> up from ~4 minutes to ~20 minutes. We run it with "go test -race
>> -covermode=atomic -coverprofile=coverage.tmp" and it seems like one or
>> other of coverage or race detector is implicated. Is anything like
>> this expected?
>
> This could possibly be related to https://golang.org/issue/19133
> and/or https://golang.org/issue/19151.
>
> Ian
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Go UDP performance

[Tharaneedharan Vilwanathan]

Hi All,

I am trying to send a lot of UDP packets from Go code but I realized UDP
performance is too low. The max I was able to do is about 160Mbps. This is
in Ubuntu 16.10 on x86_64 (i7-6700HQ).

I tried to google on this and it looks like this is about the performance
we can get. I am a bit surprised.

Am I missing something? Any suggestions on how to improve the performance?

Thanks
dharani

-- 
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: ActiveState seeking Go community feedback

[Kevin Powick]

On Wednesday, 2 November 2016 12:53:23 UTC-4, je...@activestate.com wrote:
 

> respond to this thread, email me, or you can sign up to our mail list (
> http://www.activestate.com/go)
>

My favourite lines from that website.

_COMING SOON: ACTIVEGO - THE WORLD'S BEST GO DISTRIBUTION_

 Maybe it should read "...The World's Best Commercial Support of a Go 
Distribution"

_Why take risks with open source Go and community support?_ 

 LoL.  "Hey guys, could you help us build our for-profit business so 
that we can reinforce the idea that open source and its community sucks?"


Actually, I see nothing wrong with offering commercial support for open 
source software. It's often the right choice for business entities to have 
readily available support with SLAs in place.  I just think it's 
hypocritical to be selling support for Go to your customers, while looking 
for support from they very community that your marketing claims is risky.

I'm not really up on Activestate's involvement with Go, but have they 
contributed to the development or promotion of Go in any significant way?

--
Kevin Powick 

-- 
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] Building a simple timesheet app with SlashDB, Go and Vue

[Victor Olex]

"Building a simple timesheet app with SlashDB, Go and Vue"
Complete tutorial with full code on GitHub

https://www.slashdb.com/2017/02/20/building-a-simple-timesheet-app-with-slashdb-go-and-vue/

-- 
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 test -race much slower in 1.8 (was Re: [go-nuts] Go 1.8 is released)

[Ian Lance Taylor]

On Mon, Feb 20, 2017 at 12:06 PM, Will Newton  wrote:
> On Thu, Feb 16, 2017 at 9:01 PM, Chris Broadfoot  wrote:
>> Hello gophers,
>>
>> We just released Go 1.8.
>>
>> You can read the announcement blog post here:
>>   https://blog.golang.org/go1.8
>>
>> You can download binary and source distributions from our download page:
>>   https://golang.org/dl/
>>
>> To compile from source using a Git checkout, update to the release with "git
>> checkout go1.8" and build as usual.
>>
>> To find out what has changed, read the release notes:
>>   https://golang.org/doc/go1.8
>>
>> Thanks to everyone who contributed to the release.
>
> After upgrading to Go 1.8 from Go 1.7 our testsuite runtime has gone
> up from ~4 minutes to ~20 minutes. We run it with "go test -race
> -covermode=atomic -coverprofile=coverage.tmp" and it seems like one or
> other of coverage or race detector is implicated. Is anything like
> this expected?

This could possibly be related to https://golang.org/issue/19133
and/or https://golang.org/issue/19151.

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] Arguments for writing fast, high-load servers in Go instead of Scala?

[Kevin Powick]

You may have come across this already, but here is another example of a 
team moving from Scala to Go

https://movio.co/blog/migrate-Scala-to-Go/

Though not a move from Scala, Uber has also published some articles on how 
they've built high-speed services with Go.

https://eng.uber.com/go-geofence/

--
Kevin Powick

On Monday, 20 February 2017 07:26:46 UTC-5, Konstantin Khomoutov wrote:
>
>
> The post is kind of old but I'm not sure the situation could have 
> changed drastically during a single year. 
>
> 1. http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/ 
> 2. http://codahale.com/downloads/email-to-donald.txt 
>

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

Re: [go-nuts] Go 1.8 is released

[Will Newton]

On Thu, Feb 16, 2017 at 9:01 PM, Chris Broadfoot  wrote:
> Hello gophers,
>
> We just released Go 1.8.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.8
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with "git
> checkout go1.8" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.8
>
> Thanks to everyone who contributed to the release.

After upgrading to Go 1.8 from Go 1.7 our testsuite runtime has gone
up from ~4 minutes to ~20 minutes. We run it with "go test -race
-covermode=atomic -coverprofile=coverage.tmp" and it seems like one or
other of coverage or race detector is implicated. Is anything like
this expected?

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] How to Build and Install Go 1.7.4 in OpenBSD 5.9

[Ian Lance Taylor]

On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika
 wrote:
> How to Build and Install Go 1.7 from go src code in OpenBSD 5.9.

It's no different from building Go from source on any other system.

https://golang.org/doc/install/source

Note that the current release is now 1.8, but the procedure hasn't
changed since 1.7.

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] How do you implement and use Context.Done?

[Ian Lance Taylor]

On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
> Thanks, I see you build it up with decorators on a standard prototype.
> For example: https://play.golang.org/p/PJy5lE9QqF
>
> So context.Done is a convenience function for those that require it?
> Otherwise a context will expire after it leaves scope, so Done does not need
> to be called?

Cancelling the context just marks the context as cancelled.  It does
not actually stop any goroutines using the context.  Those goroutines
must themselves periodically check the context to see whether it has
been cancelled, and, if so, stop working.  They do that by calling
either the Done or Err method; it's much more common to call the Done
method (and check whether the channel is closed).

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 Concurrency Patterns: Pipelines

[Marco Ippolito]

- What would be your rule of thumb regarding how many goroutines to start, 
considering to the parameters of the original question?

- How would you generally go about deciding on a convenient fan-out level?

On Monday, 20 February 2017 09:26:44 UTC+1, Tamás Gulácsi wrote:
>
> The general optimization problem is the packing problem, NP-complete. So 
> no fast optimal solution exists.
> But fast-enough, suboptimal does. Search for a sat-solver.
>
> Btw time of computing md5 is size-dependent, so sort by size in descending 
> order, and use a buffered channel as token bucket, with a predefined token 
> "size".
> For example if you measure that a 1Mb file needs 128k memory, then use a 
> token for each mb of file, and limit bucket size by memory limit in 128k 
> units.
>
> If bucket is not big enough for the file, try the next (smaller).
> But if you start a goroutine for each file, and the bucket uses channels, 
> eventually reducing the selection to a "select", you'll get a suboptimal 
> but easy and reasonable solution.
>
>

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

Re: [go-nuts] Argument types of: anonymous function literals used as arguments of other function calls

[Ian Lance Taylor]

On Mon, Feb 20, 2017 at 6:44 AM, Marco Ippolito  wrote:
>> Are you asking for the language to be changed to allow it?
>
> Yes.

Some previous discussion in this thread:
https://groups.google.com/d/msg/golang-nuts/Kfm4t3TShTY/9mH173ZiReIJ .

The way to pursue this would be to write up a full proposal.  But my
sense right now is that it is unlikely to be adopted.  The benefits
seem small compared to the additional complexity.

Ian


> On 20/02/17 15:19, Matt Harden wrote:
>> It looks like you're asking if you can leave out the parameter types in
>> a function literal, and have them automatically derived from context.
>> You can't currently. Are you asking for the language to be changed to
>> allow it?
>>
>> On Sun, Feb 19, 2017 at 11:12 PM Marco Ippolito > > wrote:
>>
>> Consider:
>>
>> func HandleFunc(pattern string, handler func(ResponseWriter,
>> *Request))
>>
>> and:
>>
>> http.HandleFunc("/", func(w http.ResponseWriter, r
>> *http.Request) { ...
>>
>> Could this be made to work?
>>
>> http.HandleFunc("/", func(w, r) { ...
>>
>> in an "auto" kind of way?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Re: How to dllexport a value symbol within a windows binary executable with Go?

[Hakan Guleryuz]

I found a much simpler and cleaner solution without involving any ldflags 
and without using 

--export-all-symbols


In my main.go (or whatever main package that contains the main func):

/*
#cgo LDFLAGS: ${SRCDIR}/main.def
__declspec(dllexport) unsigned long NvOptimusEnablement = 0x0001;
__declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
*/
import "C"


and main.def contents are:

EXPORTS
   NvOptimusEnablement @1 DATA
   AmdPowerXpressRequestHighPerformance @2 DATA


I can verify that I have only these exports using either this build option:

go install -x -ldflags "-v -extldflags -Wl,--output-def,exports.def"


or using dumpin tool:
dumpbin /exports engine-conversion.exe
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file engine-conversion.exe

File Type: EXECUTABLE IMAGE

  Section contains the following exports for a.out.exe

 characteristics
58AB2A03 time date stamp Mon Feb 20 20:40:19 2017
0.00 version
   1 ordinal base
   2 number of functions
   2 number of names

ordinal hint RVA  name

  20 00189220 AmdPowerXpressRequestHighPerformance
  11 00189224 NvOptimusEnablement
...
...

On Monday, January 30, 2017 at 5:47:51 PM UTC+3, Hakan Guleryuz wrote:
>
> For anyone who wants to build a windows .exe with go-sdl2 and opengl, and 
> has an optimus driver, and wants to ensure that 
> the high performance gpu is selected by default for their final product, I 
> will document my findings here
>
> I found the followingsolution, which can be proven that it works by having 
> this line in the go-sdl2 code:
>
> var vendorString string = gl.GoStringUb(gl.GetString(gl.VENDOR))
> fmt.Printf("Vendor String is %v \n", vendorString)
>
>
> which outputs:
> Vendor String is NVIDIA Corporation
> instead of
> Vendor String is Intel
>
> Also process explorer shows that the gpu memory usage is only on the 
> dedicated memory usage, 
> and also the opengl performance is much higher.
>
> The first thing to do is to have an export on the created object file. 
> I did this by putting this in my main .go file
>
> //__declspec(dllexport) unsigned long NvOptimusEnablement = 0x0001;
> import "C"
>
>
> The corresponding object file now has this symbol but the linker removes 
> it, since it is building an .exe on windows,
> and I guess GNU GCC tool chain by default removes all symbols (I did not 
> try to switch the toolchain to Microsoft link.exe at this point)
>
> Then to have this symbols (and unfortunately all other symbols) get 
> exported in the final .exe I added this to the build options:
>
> go install -ldflags "-v -extldflags -Wl,--export-all-symbols" 
> pkgdnm/opengl3perftest
>
>
> now dumpbin /export shows a huge number of exported symbols on the .exe 
> and NvOptimusEnablement is one of them
> This works, and optimus driver automatically selects the dedicated GPU 
> when the executable is run, 
> but the down side is there are many more exported symbols.
> There is another option which is 
>
> --dynamic-list=dynamic_symbol_table.txt
>
>
> I put the contents of dynamic_symbol_table as just this
>
> {
>   extern "C"
>   {
> "NvOptimusEnablement";
>   };
> };
>
>
> but this did not work, meaning nothing was exported. The GNU GCC 
> documentation is somewhat unclear 
> (https://sourceware.org/binutils/docs/ld/Options.html)
> "This option is only meaningful on ELF platforms "
>
> I could not find any option on gcc ld doc in section: " Options Specific 
> to i386 PE Targets" to limit the exported symbols to only what needed, 
> but as far as automatically selecting the dedicated GPU goal, goes, this 
> works.
>
> If anyone know a better/simpler way to export a symbol from .go file to 
> the object file to be linked
> or maybe know how to limit the exported symbols in the final executable 
> using gnu ld PE target options
> please comment.
>
> First in my main package I have these lines
> On Monday, January 23, 2017 at 7:13:30 PM UTC+3, Hakan Guleryuz wrote:
>>
>> In normal C/C++ SDL2 related app I write, adding the following code
>>
>> extern "C" {
>>_declspec(dllexport) DWORD NvOptimusEnablement = 0x0001;
>> }
>>
>> causes the driver system with integrated and dedicated nvidia gpu, to 
>> auto select the dedicated nvidia gpu. 
>>
>> See here for some explanation of the mechanism->
>> https://github.com/urho3d/Urho3D/issues/139
>>
>> http://stackoverflow.com/questions/16823372/forcing-machine-to-use-dedicated-graphics-card
>>
>>
>>
>> 
>>
>> I can view the exports of the final executable with "dumpbin /exports 
>> "
>>
>> [dumpbin is a tool installed with visual studio C++ tools]
>>
>>
>> How can I make my go executable export this value symbol?
>>
>> I searched go link documentation but could not find something useful to 
>> achieve this.

[go-nuts] Re: Registering a Go app as a protocol handler under Mac OS X

[Nathan Kerr]

I managed to get this working.

https://gist.github.com/nathankerr/38d8b0d45590741b57f5f79be336f07c

I don't know what sort of app you are making, so I made a simple gui that 
displays the url received, with some filler text before any are. I think 
the non-ui parts should transfer to whatever you are doing.

A few notes:

- main.go lines 3-8 (cgo and import C) are important. They tell go how to 
build the c and obj-c parts.
- after C.StartURLHandler is called, HandlerURL will be called. HandleURL 
needs to be non-blocking as it seems to block the whole UI, so put 
long-running stuff in another go routine. I had to buffer labelText so the 
a url received at the same time the app starts will not hang the program.
- I had to put C.StartURLHandler before the ui.Main stuff so the first url 
would not be lost when the app is opened with `open myapp://whatever` and 
the app was not already running.
- running `make` will setup the app, including building it. You will need 
to `go get -u github.com/andlabs/ui` before doing so.
- You might need to change the url scheme to something else because you 
(presumably) already have an app that registers myapp. I didn't think of 
this earlier as I was trying to follow your question.
- Before trying to open the url, open the app itself. This will register 
the url scheme with macOS. After doing so, the app will work if it is 
already running or not.
- I was not able to get cmd-Q to close the app. Just click the close (red) 
button on the window. This seems to be a limit of the ui package.

This worked for me using go1.8 on macOS 10.12.3 and the latest version of 
the ui package.

Hope it helps you out.

Nathan

On Wednesday, July 6, 2016 at 11:50:02 PM UTC+2, chris...@gmail.com wrote:
>
> Hi,
>
> I'm trying to hook up a Go application to a URL protocol handler in Mac OS 
> X.  I want a user to be able to click on a link such as myapp://foo/bar and 
> have that launch myapp and be able to access the full query parameters. 
>  I've made it as far as getting the OS to register the handler and launch 
> the app.  That's done by bundling the Go binary into a OS X-style .app 
> package with a Info.plist file like this:  
> https://gist.github.com/chrissnell/db95a3c5ad6ceca4c673e96cca0f7548
>
> The challenge now is to figure out how to reference the query parameters 
> within Go.  I've determined that they're not passed as command-line 
> arguments.   From what I can tell, you have to use Cocoa libraries to get 
> at them  [1].  I don't know Objective-C or Swift, though, so that's where 
> I'm stumbling.
>
> There are cheap hacks to do this with AppleScript [2] but I wanted 
> something more native. 
>
> Has anybody done this?
>
> Chris
>
>
> [1] 
> http://fredandrandall.com/blog/2011/07/30/how-to-launch-your-macios-app-with-a-custom-url/
>
> [2] 
> https://support.shotgunsoftware.com/hc/en-us/community/posts/209485898-Launching-External-Applications-using-Custom-Protocols-under-OSX
>
>

-- 
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] Does Go spec assure that a substring shares the underlying bytes with the original string?

[Ian Lance Taylor]

On Mon, Feb 20, 2017 at 9:12 AM, T L  wrote:
>
> I know gc assures this, but I don't know if it is compiler specified or a
> spec rule.

I can't think of any way that a Go program that does not unsafe could
detect whether a string slice uses the same memory as the string being
sliced.  Also, I can easily imagine that in some cases it would be
desirable to make a copy, as when writing s[i:i+1] when len(s) > 4096
and there are no other references to s.  So I don't think this should
be written down in the spec.  I think Go programs should trust that
the implementation will make the right choice, which will of course be
to normally not copy the string.

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: Does Go spec assure that a substring shares the underlying bytes with the original string?

[T L]

On Tuesday, February 21, 2017 at 1:12:37 AM UTC+8, T L wrote:
>
> I know gc assures this, but I don't know if it is compiler specified or a 
> spec rule.
>
> It looks that the function "Index(s, sep string) int" in strings package 
> has not a fromIndex parameter.
> So I must use strings.Index(s[fromIndex:], sep) to search a substr from a 
> specified index.
> This implies the cost of the operation s[fromIndex:] would be small.
>
> But I can't Go spec make the guarantee that a substring shares the 
> underlying bytes with the original string.
>
sorry, lost a "find" after "can't".
 

> Or I missed 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] Re: IBM WebSphere MQ

[rudra . sparky]

Hai,

can you just upload MQcontext.jar file. I couldn't find it

On Wednesday, January 27, 2016 at 9:41:43 PM UTC+5:30, Jérôme LAFORGE wrote:
>
> Hello all,
> Do you know a library for IBM WebSphere MQ in "pure" go? (without cgo)
>
> Thx in adv
> Jérô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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Does Go spec assure that a substring shares the underlying bytes with the original string?

[T L]

I know gc assures this, but I don't know if it is compiler specified or a 
spec rule.

It looks that the function "Index(s, sep string) int" in strings package 
has not a fromIndex parameter.
So I must use strings.Index(s[fromIndex:], sep) to search a substr from a 
specified index.
This implies the cost of the operation s[fromIndex:] would be small.

But I can't Go spec make the guarantee that a substring shares the 
underlying bytes with the original string.
Or I missed 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.

Re: [go-nuts] Argument types of: anonymous function literals used as arguments of other function calls

[Marco Ippolito]

> Are you asking for the language to be changed to allow it?

Yes.


On 20/02/17 15:19, Matt Harden wrote:
> It looks like you're asking if you can leave out the parameter types in
> a function literal, and have them automatically derived from context.
> You can't currently. Are you asking for the language to be changed to
> allow it?
> 
> On Sun, Feb 19, 2017 at 11:12 PM Marco Ippolito  > wrote:
> 
> Consider:
> 
> func HandleFunc(pattern string, handler func(ResponseWriter,
> *Request))
> 
> and:
> 
> http.HandleFunc("/", func(w http.ResponseWriter, r
> *http.Request) { ...
> 
> Could this be made to work?
> 
> http.HandleFunc("/", func(w, r) { ...
> 
> in an "auto" kind of way?

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

Re: [go-nuts] Question about net/http package implementation

[Matt Harden]

Oh, interesting. The code inline to his sentences is italicized like *this*.
It looks like that gets surrounded by asterisks in the text-only version,
leading to confusion in this case.

On Sun, Feb 19, 2017 at 6:44 PM Dan Kortschak 
wrote:

> On Sat, 2017-02-18 at 23:15 +, Matt Harden wrote:
> > They didn't say ; they said r2 := *r. Also read the example.
> > They
> > returned  instead of r2. The code is equivalent to but shorter
> > than the
> > original.
>
>
> After I read the example I realised that. However the text shows up on
> a text-only mail browser as "*r2 := *r". I use a text-only mail
> browser.
>

-- 
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] Argument types of: anonymous function literals used as arguments of other function calls

[Matt Harden]

It looks like you're asking if you can leave out the parameter types in a
function literal, and have them automatically derived from context. You
can't currently. Are you asking for the language to be changed to allow it?

On Sun, Feb 19, 2017 at 11:12 PM Marco Ippolito 
wrote:

> Consider:
>
> func HandleFunc(pattern string, handler func(ResponseWriter, *Request))
>
> and:
>
> http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { ...
>
> Could this be made to work?
>
> http.HandleFunc("/", func(w, r) { ...
>
> in an "auto" kind of way?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[go-nuts] Re: [Gobot v1.2] - I2C PiGlow [SN3218] driver help

[Owen Waller]

Done. The new issue is:
https://github.com/hybridgroup/gobot/issues/372

I have also updated my sample code after spotting a stupid mistake. The
result is exactly the same however.The code shows no errors and there
are no lights n the PiGlow.

The updated code is here:
https://play.golang.org/p/Xma_6zBtT2

Owen

On Mon, 2017-02-20 at 02:37 -0800, Ron Evans wrote:
> Hi, Owen
> 
> Thanks for doing some work on this, it look cool.
> 
> > > The current set of Gobot i2c drivers all use the sysfs Read() and
Write() interface. The new SMBLOCK based interface is an experimental
interface, and seems like it seems some additional work on Raspi.
> 
> > > I will take a look into it, if you don't mind entering an issue on
our GH tracker it would be appreciated: https://github.com/hybridgrou
p/gobot/issues
> 
> Thanks!
> 
> Regards,
> Ron
> 
> > Hi Everyone,
> > > > With the release of GoBot 1.2 I thought I would try and put
together a "metal bot" for the PiGlow on a Raspberry Pi 1. 
> > 
> > > > The PiGlow is based around a SN3218 IC that drives the 18 leds on
the board. The SN3218 communication with the Pi is via 12c.
> > > > GoBot 1.2 rewrote the i2c subsystem, but I can't get it to drive
the PiGlow at all.
> > 
> > My stab at getting this to work is here:
> > https://play.golang.org/p/_DDEiwZqt1
> > 
> > > > The code is in the style of a "metal bot" as I want to reuse this
code as part of a small project to replace some python code.
> > > > > > The code should turn on LED zero. But when the code runs nothing
happens. There's no terminal output indicating a non-nil error and
there are lights on the PiGlow.
> > 
> > > > > > > > The code is based on the existing PiGlow library, by Toon
Schoenmakers[1] - which does not use GoBots i2c subsystem. That
libraries test code runs fine on the board, so the PiGlow itself is
working ok. My initialisation code is based on Toon's.  
> > 
> > > > Can a friendly Gopher who has more experience of GoBot and a
similar hardware set-up, spot what I might be doing wrong?
> > 
> > Thanks
> > 
> > Owen
> > 
> > [1]https://github.com/schoentoon/piglow
> > 
> > 

-- 
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: Issue with Goroutine and http.RedirectHandler

[Diego Medina]

Most likely this is your browser that "remembers" that going to one url was 
redirecting to the "incorrect" url, and it doesn't even hit your local 
server any more. To make sure this is the case, use curl from the command 
line with the -v paarameter to see all the headers:


curl -v http://127.0.0.1:8000

and see if the redirect shows the right url there.

Hope it helps.

Diego

On Monday, February 20, 2017 at 7:45:40 AM UTC-5, Rejoy wrote:
>
> Hi,
>
> I am trying to create a go routine to direct the request to another url:
>
> go http.ListenAndServe(":8000", http.RedirectHandler("
> https://127.0.0.1:8001",301))
>
> I had earler made a mistake and had typed in "https://127.0.0.1/:8001; 
> for the url string.  But now after rectifying the mistake to the above, I 
> am still being redirected to the incorrect url.
>
> When I type in the url  ""https://127.0.0.1:8001;, the page is rendered 
> correctly.
>
> Is there a need to explicitly stop go routines. Strangely even after 
> restarting the m/c, the request is being redirected incorrectly. 
>
> Thanks
> Rejoy
>
>
>

-- 
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] Issue with Goroutine and http.RedirectHandler

[Rejoy]

Hi,

I am trying to create a go routine to direct the request to another url:

go http.ListenAndServe(":8000", 
http.RedirectHandler("https://127.0.0.1:8001",301))

I had earler made a mistake and had typed in "https://127.0.0.1/:8001; for 
the url string.  But now after rectifying the mistake to the above, I am 
still being redirected to the incorrect url.

When I type in the url  ""https://127.0.0.1:8001;, the page is rendered 
correctly.

Is there a need to explicitly stop go routines. Strangely even after 
restarting the m/c, the request is being redirected incorrectly. 

Thanks
Rejoy


-- 
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] Arguments for writing fast, high-load servers in Go instead of Scala?

[Konstantin Khomoutov]

On Fri, 17 Feb 2017 22:55:37 -0800 (PST)
Will Faught  wrote:

> I want to make the case to a software architect where I work that we
> should write some fast, high-load servers we need in Go rather than
> Scala. What pragmatic arguments should I use?

I do not do Scala but since I'm trying to keep tabs on what happens in
my industry so I'm used to read success/failure stories when I happen to
come across one.  I find [1] to be of interest to your case, and it
refers to [2] which is an in-depth report of someone made huge use of
Scala and finally decided to move to plain Java.

The post is kind of old but I'm not sure the situation could have
changed drastically during a single year.

1. http://jimplush.com/talk/2015/12/19/moving-a-team-from-scala-to-golang/
2. http://codahale.com/downloads/email-to-donald.txt

-- 
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] How to Build and Install Go 1.7 in OpenBSD 5.9

[Srikanth Chandika]

How to Build and Install Go 1.7 from go source code in OpenBSD 5.9.

-- 
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] How to Build and Install Go 1.7.4 in OpenBSD 5.9

[Srikanth Chandika]

How to Build and Install Go 1.7 from go src code in OpenBSD 5.9.

-- 
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: Re[2]: Golang server background notofication process

[egortictac3]

Thank you a lot, Diego! 
I decided to implement this exatctly as you said (one goroutine for list of 
pairs user:location), and this is much more correct. 

понедельник, 20 февраля 2017 г., 4:27:10 UTC+3 пользователь Diego Medina 
написал:
>
> Hi,
>
> Instead of starting them from an http handler, I would store in the 
> database the locations and their users. Then, from main() I would start 
> just one go routine that will check the db for any pending location that 
> needs to be fetched, if found, then go do work, sleep for x seconds, then 
> check the database again.
>
> That way, when a user no longer wants to be notified about location Z, you 
> just remove their user from the database and then go routine will not find 
> it any more.
>
> Thanks
>
>
>
>
> -- 
> Diego Medina
> Lift/Scala Consultant
> di...@fmpwizard.com 
> https://blog.fmpwizard.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: [Gobot v1.2] - I2C PiGlow [SN3218] driver help

[Ron Evans]

Hi, Owen

Thanks for doing some work on this, it look cool.

The current set of Gobot i2c drivers all use the sysfs Read() and Write() 
interface. The new SMBLOCK based interface is an experimental interface, 
and seems like it seems some additional work on Raspi.

I will take a look into it, if you don't mind entering an issue on our GH 
tracker it would be appreciated: https://github.com/hybridgroup/gobot/issues

Thanks!

Regards,
Ron

On Sunday, February 19, 2017 at 8:01:32 PM UTC+1, Owen Waller wrote:
>
> Hi Everyone,
>
> With the release of GoBot 1.2 I thought I would try and put together a 
> "metal bot" for the PiGlow on a Raspberry Pi 1. 
>
> The PiGlow  is based around a 
> SN3218 IC that drives the 18 leds on the board. The SN3218 communication 
> with the Pi is via 12c.
> GoBot 1.2 rewrote the i2c subsystem, but I can't get it to drive the 
> PiGlow at all.
>
> My stab at getting this to work is here:
> https://play.golang.org/p/_DDEiwZqt1
>
> The code is in the style of a "metal bot" as I want to reuse this code as 
> part of a small project to replace some python code.
> The code should turn on LED zero. But when the code runs nothing happens. 
> There's no terminal output indicating a non-nil error and there are lights 
> on the PiGlow.
>
> The code is based on the existing PiGlow library, by Toon Schoenmakers[1] 
> - which does not use GoBots i2c subsystem. That libraries test code runs 
> fine on the board, so the PiGlow itself is working ok. My initialisation 
> code is based on Toon's.  
>
> Can a friendly Gopher who has more experience of GoBot and a similar 
> hardware set-up, spot what I might be doing wrong?
>
> Thanks
>
> Owen
>
> [1]https://github.com/schoentoon/piglow
>

-- 
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: Arguments for writing fast, high-load servers in Go instead of Scala?

[Haddock]

I would say that CSP in Go using channels and goroutines make concurrent 
programming a lot easier than with actors in Scala (Akka). Reason is that 
it is easier to detect races and deadlocks in Go at development time (code 
using CSP easier to understand than code using asynchronous calls) and at 
runtime (again, asynchronous calls are the problem and actors in Akka make 
life easier but do not address the issue at a fundamental level as CSP).

One advantage of Scala/Akka is distributed programming. The concept of 
supervision  
in Akka makes distributed programming much more reliable. IMHO, Go is 
lacking as what distributed programming is concerned, e.g. there is nothing 
with the safety of supervision in NATS and other Go libraries for 
distributed programming. But if you don't need distributed programming, Go 
may just be fine.

Am Samstag, 18. Februar 2017 07:55:37 UTC+1 schrieb Will Faught:
>
> I want to make the case to a software architect where I work that we 
> should write some fast, high-load servers we need in Go rather than Scala. 
> What pragmatic arguments should I use?
>
> Note that the architect isn't against ever using Go; the question is 
> whether to use Go now, for these servers in particular. Not much detail has 
> been hashed out yet about them, aside from general speed and load 
> requirements.
>
> As a general example of a pragmatic reason one might choose Go over Scala, 
> the architect said Scala would be bad for making a standalone program that 
> checks gRPC health endpoints because the binary would be large and the 
> start-up time would be long.
>

-- 
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 Concurrency Patterns: Pipelines

[Tamás Gulácsi]

The general optimization problem is the packing problem, NP-complete. So no 
fast optimal solution exists.
But fast-enough, suboptimal does. Search for a sat-solver.

Btw time of computing md5 is size-dependent, so sort by size in descending 
order, and use a buffered channel as token bucket, with a predefined token 
"size".
For example if you measure that a 1Mb file needs 128k memory, then use a token 
for each mb of file, and limit bucket size by memory limit in 128k units.

If bucket is not big enough for the file, try the next (smaller).
But if you start a goroutine for each file, and the bucket uses channels, 
eventually reducing the selection to a "select", you'll get a suboptimal but 
easy and reasonable solution.

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