Thanks, snmed,
I was looking at LoadOrStore, but I was assuming that any func would be
executed in any case.
A more illustrative running sample of your first example:
https://play.golang.org/p/vjlVu1GnUQ
Thanks again!
bep
fredag 1. september 2017 08.24.10 UTC+2 skrev snmed følgende:
>
> Hi
Hi
Here are two examples how to achieve it:
https://play.golang.org/p/wAtyGMSw6g or https://play.golang.org/p/EZWZUOpuwb
First example: In best cases it executes the creator function once and
returns always the stored item, in bad cases it executes the creator
function multiple times but retu
If you absolutely must make sure you ever create 2 instances of any value
in the map then I guess you have to lock.
Otherwise you can maybe use map.LoadOrStore?
fre 1 sep. 2017 kl 00:18 skrev bep :
> sync.Map in Go 1.9 is a little low on examples/doc in the wild, so I
> thought I should ask here.
After I upgraded my Go from 1.8.1 I noticed several test failures. I zeroed
down on the root cause for these failures and it appears that now
pem.Decode behaves differently
In tests that fail PEM encoded certificate is copied to another
preallocated byte array using copy function and then pem.D
Thanks. I actually moved it to /etc/environment... reboot... and it picked
it up. Appreciate the help, guys.
On Thursday, August 31, 2017 at 8:50:22 PM UTC-5, James Bardin wrote:
>
>
>
> On Thursday, August 31, 2017 at 9:46:11 PM UTC-4, burpswangy wrote:
>>
>> Wow, actually... that did work. I
On Thursday, August 31, 2017 at 9:46:11 PM UTC-4, burpswangy wrote:
>
> Wow, actually... that did work. I was using 'set GOPATH' and not 'export
> GOPATH'. I have GOPATH defined in my /etc/bash.bashrc... is there anywhere
> else I should be putting it?
>
>>
>>>
You should be using a profile f
Once something is buffered, it can not be unbuffered. That is, the latency
of the I/O operations permanently increase with respect to the properties
of the buffering done underneath. Go does not buffer things by default
because not everyone wants to buffer things by default. This is also why
Na
Wow, actually... that did work. I was using 'set GOPATH' and not 'export
GOPATH'. I have GOPATH defined in my /etc/bash.bashrc... is there anywhere
else I should be putting it?
On Thursday, August 31, 2017 at 8:44:33 PM UTC-5, burpswangy wrote:
>
> I did... to no avail. I'm so confused right
I did... to no avail. I'm so confused right now, lol. I even su root and
tried doing things under there, just in case it was something user-specific
causing it. Nothing I do changes it.
On Thursday, August 31, 2017 at 8:40:07 PM UTC-5, Ayan George wrote:
>
>
>
> On 08/31/2017 09:38 PM, burpsw
Optimizations were really great.
Can somebody tell me, why isn't buffered i/o isn't used by default.
>It's true that fmt.Scanf works on the unbuffered os.Stdin. That is
the correct choice when os.Stdin is used for different things.
Ian Lance Taylor, have mentioned it, but it is too short for
On 08/31/2017 09:38 PM, burpswangy wrote:
> Debian 9.1 Stretch... using Go 1.9, go env shows GOPATH=/home/dev/go
> while echo $GOPATH=/home/dev/devSync/workspace.
>
> No matter what I do, I can't get Go 1.9 to find my workspace! What is
> goin' on!?
>
have you tried:
export GOPATH=/home/dev/
Debian 9.1 Stretch... using Go 1.9, go env shows GOPATH=/home/dev/go while
echo $GOPATH=/home/dev/devSync/workspace.
No matter what I do, I can't get Go 1.9 to find my workspace! What is
goin' on!?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" gro
On 08/31/2017 08:41 PM, djl...@gmail.com wrote:
> I am pretty new it GoLang but I am trying to read file directorys and
> assign the directory name to array list.
>
> Exampe I have been working with this
>
> funccaptureDir() {
>files, err:=ioutil.ReadDir("./")
>iferr !=nil{
>log
I am pretty new it GoLang but I am trying to read file directorys and
assign the directory name to array list.
Exampe I have been working with this
func captureDir() {
files, err := ioutil.ReadDir("./")
if err != nil {
log.Fatal(err)
}
for _, f := range files {
dirlis
On Thu, Aug 31, 2017 at 12:51 PM, abriese wrote:
> ~/Download/ $ go build github.com/AndreasBriese/breeze
> # runtime
> /usr/local/go/src/runtime/mstkbar.go:151:10: debug.gcstackbarrieroff
> undefined (type struct { allocfreetrace int32; cgocheck int32; efence int32;
> gccheckmark int32; gcpacertr
On Thu, Aug 31, 2017 at 2:05 PM, wrote:
>
> On Thursday, August 31, 2017 at 12:45:25 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 31, 2017 at 11:50 AM, wrote:
>>
>> > 1. method/function parameters are not coerced by the compiler. If a
>> > parameter calls for a pointer, it must be a poin
Red Hat is currently looking to hire an engineer in the Golang space.
Information on the position and application link can be found here:
https://careers-redhat.icims.com/jobs/59029/senior-software-engineer---golang/job
If after reviewing that page you have questions, you can certainly
contact
On Thursday, August 31, 2017 at 3:23:02 PM UTC-5, Ian Lance Taylor wrote:
>
> On Thu, Aug 31, 2017 at 7:45 AM, Jason E. Aten > wrote:
> > On Thursday, August 31, 2017 at 9:23:58 AM UTC-5, Konstantin Khomoutov
> > wrote:
> >>
> >> Still, I don't see any specific wording regarding this in the
sync.Map in Go 1.9 is a little low on examples/doc in the wild, so I
thought I should ask here.
The new type is promoted as a replacement for RWMutex in mostly read use
cases with stable keys. I assume that a typical in memory cache would fit
that description.
With RWMutex, if the cost of cre
On Thursday, August 31, 2017 at 12:45:25 PM UTC-7, Ian Lance Taylor wrote:
>
> On Thu, Aug 31, 2017 at 11:50 AM, >
> wrote:
>
> > 1. method/function parameters are not coerced by the compiler. If a
> > parameter calls for a pointer, it must be a pointer at the call site.
> > 2. method receiv
can this thread helps ?
https://groups.google.com/forum/#!topic/golang-nuts/wAYxijyyL5U
On Thursday, August 31, 2017 at 10:23:07 PM UTC+2, abriese wrote:
>
> ~/Download/ $ go build github.com/AndreasBriese/breeze
> # runtime
> /usr/local/go/src/runtime/mstkbar.go:151:10: debug.gcstackbarrieroff
On Thu, Aug 31, 2017 at 7:45 AM, Jason E. Aten wrote:
> On Thursday, August 31, 2017 at 9:23:58 AM UTC-5, Konstantin Khomoutov
> wrote:
>>
>> Still, I don't see any specific wording regarding this in the spec --
>> neither in its section on channels nor in its section on the close()
>> function.
>
~/Download/ $ go build github.com/AndreasBriese/breeze
# runtime
/usr/local/go/src/runtime/mstkbar.go:151:10: debug.gcstackbarrieroff
undefined (type struct { allocfreetrace int32; cgocheck int32; efence
int32; gccheckmark int32; gcpacertrace int32; gcshrinkstackoff int32;
gcrescanstacks int32;
All,
Thanks for all the suggestions.
I cleaned out everything with: go clean -r -i …
installed go 1.9 and created a file new test file of:
package main
import (
"fmt"
"os"
"github.com/plandem/xlsx"
)
func checkErr(err error) {
if err != nil {
fmt.Println(err)
os.
As a short rule: if sth needs to be modified, a pointer is needed. If only some
result of computation, a value is enough.
--
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 e
On Thu, Aug 31, 2017 at 11:50 AM, wrote:
>
> I was bitten this week by not understanding how interfaces in method
> parameters interacted with pointers. After playing around I finally figured
> out these rules
>
> 1. method/function parameters are not coerced by the compiler. If a
> parameter cal
I was bitten this week by not understanding how interfaces in method
parameters interacted with pointers. After playing around I finally figured
out these rules
1. method/function parameters are not coerced by the compiler. If a
parameter calls for a pointer, it must be a pointer at the call si
By the way, if we're willing to do it all...we can take it down a little
more:
https://play.golang.org/p/DNxQT01vy9
read 100 26.174853ms
sort 100 180.17782ms
On Thu, Aug 31, 2017 at 11:28 AM, Michael Jones
wrote:
> Nice! Is "bytconv" shared somewhere?
>
> On Thu, Aug 31, 2017 at 10:53 A
Nice! Is "bytconv" shared somewhere?
On Thu, Aug 31, 2017 at 10:53 AM, peterGo wrote:
> Michael,
>
> n your code, you have :
>
> const n = 1000 * 1000
>
> for i := 0; i < n && scan.Scan(); i++ {
> d, _ := strconv.Atoi(scan.Text())
> array[i] = int64(d)
> }
>
> https://play.golang.org/p/S
Michael,
n your code, you have :
const n = 1000 * 1000
for i := 0; i < n && scan.Scan(); i++ {
d, _ := strconv.Atoi(scan.Text())
array[i] = int64(d)
}
https://play.golang.org/p/SgpAXyvsGs
Here's a benchmark that demonstrates the fundamental issue, unnecessary
string conversions.
,
Ben
Michael,
Your read times look slow to me. I used bytconv instead of strconv.
bytconv:
read 100 98.517584ms
sort 100 481.994354ms
strconv:
read 100 174.720883ms
sort 100 479.437831ms
bytconv is the missing Go standard library package. bytconv is the byte
input analog of string i
Try it out! It would be great if the scheduler and garbage collector could
be so good as to making such tricks unnecessary.
On Thu, 31 Aug 2017, 15:59 wrote:
> Hi Guys,
>
> So, we wrote a Go service which does some heavy network IO over ZMQ (using
> cgo calls).
>
> Now, we have to put this servi
On Thursday, August 31, 2017 at 9:23:58 AM UTC-5, Konstantin Khomoutov
wrote:
>
> Still, I don't see any specific wording regarding this in the spec --
> neither in its section on channels nor in its section on the close()
> function.
>
Looks like it. So relying on this behavior could result i
[...]
> > AFAIK, all operations on a channel happen in-order and are fully
> > serialized. That is, close() will wait until the currently active
> > operation
> > is active, if any.
> >
> > In other words, close() on a channel is not like closing an OS file
> > descriptor -- even though the o
Hi Guys,
So, we wrote a Go service which does some heavy network IO over ZMQ (using
cgo calls).
Now, we have to put this service on a VM in private cloud which has 56
cores and 256GB of physical memory.
I am guessing it is mostly a dual core NUMA Intel Xeon machine with Xen
installed on it.
On Thursday, August 31, 2017 at 7:40:23 AM UTC-5, Konstantin Khomoutov
wrote:
>
> On Thu, Aug 31, 2017 at 05:08:23AM -0700, Jason E. Aten wrote:
>
> > A question for those familiar with the runtime internals of channel
> close
> > and channel receive:
> [...]
> > Will closing a channel in t
I think it's ok to ask in Russian on this group, too.
On Wednesday, August 30, 2017 at 4:34:19 PM UTC+2, Oleg Puchinin wrote:
>
> ОНО
> Спасибо !
>
> 2017-08-30 20:30 GMT+06:00 Konstantin Khomoutov >:
>
>> On Wed, Aug 30, 2017 at 07:17:26PM +0600, Oleg Puchinin wrote:
>>
>> > Hello !
>> > Anybody
On Thu, Aug 31, 2017 at 05:08:23AM -0700, Jason E. Aten wrote:
> A question for those familiar with the runtime internals of channel close
> and channel receive:
[...]
> Will closing a channel in the middle of a send introduce the possibility of
> data corruption? The language spec guarantees a
A question for those familiar with the runtime internals of channel close
and channel receive:
In trying to get channels to match the superior performance of sync.Cond,
I have come across one potentially viable strategy: using close to
interrupt an otherwise
blocked send. For example:
ch := ma
I fixed my previous error w/ Ian's help. Now I'm getting this error
when I type go get github.com/nsf/termbox-go
package github.com/nsf/termbox-go: directory
"/home/rob/gocode/src/github.com/nsf/termbox-go" is not using a known
version control system
I have initialized git on this computer
I think this question is a protocol problem more than anything.
A quick bit of searching "http server abort upload" reveals what to do:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.14
https://groups.google.com/forum/#!topic/golang-nuts/agB-n6V7UsQ
There is also this informativ
> > See github.com/rjeczalik/gobin for updating, but a simple
> > "go install $GOPATH/src/..." may be enough.
>
> The URL appears to 404. There are multiple projects called "gobin" on
> Github but neither appear to be concerned with the task we're
> discussing, unfortunately.
Citing the answer T
Well that's dumb of me - too busy thinking about other details and
forgetting the language I was speaking. Thanks.
On Thu, 2017-08-31 at 01:24 -0700, moehrmann via golang-nuts wrote:
> m is an unexported Field. fmt can not use interface() on the reflect
> values
> to then call String on them on a
m is an unexported Field. fmt can not use interface() on the reflect values
to then call String on them on anything unexported or below.
This also happens if m is just interface{} and not a map:
https://play.golang.org/p/ODrjW3Fslf
If m is made an exported field by naming it M it works:
https:/
Thanks a lot for that, simplifies my code massively :-)
--
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
On Wed, Aug 30, 2017 at 10:35:46PM -0700, Tamás Gulácsi wrote:
> See github.com/rjeczalik/gobin for updating, but a simple
> "go install $GOPATH/src/..." may be enough.
The URL appears to 404. There are multiple projects called "gobin" on
Github but neither appear to be concerned with the task w
On 31 Aug 2017, at 09:30, Jeffrey Smith wrote:
>
> I'm trying to Unmarshal multiple XML files that have differing top level
> elements but the rest of the document is identical.
You can use the XMLName attribute for this:
https://play.golang.org/p/4nIrfbaC37
//jb
--
You received this messag
I'm trying to Unmarshal multiple XML files that have differing top level
elements but the rest of the document is identical.
...
...
I have tried adding multiple tags in the struct but it only ever uses the
first one.
type EspFlowCodeOperation struct {
XMLName xml.Name `xml
48 matches
Mail list logo
