[go-nuts] [ANN] aah web framework for Go, v0.8 Released

[Jeevanandam M.]

*Website:* https://aahframework.org
*Documentation:* https://docs.aahframework.org

*Release Notes:* https://docs.aahframework.org/v0.8/release-notes.html

Please give it a try aah web framework and share your inputs. Your feedback 
is very valuable. Thanks.

Cheers,
Jeeva

-- 
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] new project: pixels to svg

[Nigel Tao]

On Sat, Sep 2, 2017 at 12:50 AM,   wrote:
> Feel free to give me feedback on how I can improve the code or the project
> setup, etc.

I had a quick look. Some thoughts on style, in no particular order:

0. Run gofmt. Your code mixes tabs and spaces, amongst other issues.
Gofmt will fix that.

1. Run "gofmt -s" to simplify your code. For example, the inner "[2]int" in
outlinePoints := [][2]int{[2]int{colX, rowY}}
is redundant.

2. In methods like GetSVGText, string concatenation inside a loop,
"nextSVG += fmt.Sprintf(etc)", has quadratic complexity. Better is to
use a bytes.Buffer and fmt.Fprintf (with a F, not a S).

3. Some of your backslash-rich string literals, the format arguments
to fmt.Sprintf, might be better as backtick strings: `x1="%d"` instead
of "x1=\"%d\"".

4. If Uint8ToHex is an internal function, not supposed to be used by
code that imports that package, then don't export it: change the
leading U to u. This makes it easier to see what API actually matters
in the package's godoc output.

5. The same applies to other helper functions like Split2Int.

6. But you don't need the Uint8ToHex function at all. Instead,
GetHexColor can return fmt.Sprintf("#%02X%02X%02X", etc, etc, etc).

7. Don't panic on errors. Delete your check function. The
WriteSVGToFile method should return an error instead. Callers, instead
of callees, usually have more context on e.g. whether an error is
fatal or recoverable.

8. Lines like "return [][2]int{}" can probably be the simpler "return
nil". A nil slice is a valid (empty) slice: it has 0 length, you can
range over it (0 times), you can append to it, etc.

9. The [4]uint8 type could probably be replaced by either the
color.RGBA or color.NRGBA type from the standard library's image/color
package. It shouldn't matter much in terms of the actual code
generated, but it might make it clearer what the semantics of those 4
uint8s are. It would also clarify whether your [4]uint8 is
alpha-premultiplied or non-alpha-premultiplied.

10. In getNeighborEvaluator, you have:
neighborEvaluators := map[int]func(int, int, [4]uint8) bool{
0: etc,
1: etc,
etc,
}
return neighborEvaluators[direction]
Using a map[int]etc here is overkill, as the keys are just a dense
range of natural numbers. An [8]etc would be more efficient. You could
also make that array a global instead of having to build it up on
every method call.

-- 
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: Bytconv where art thou

[Michael Jones]

Great! Very kind of you

On Fri, Sep 1, 2017 at 11:01 AM, peterGo  wrote:

> Michael and Sebastien,
>
> Since my bytconv package is currently private, I'm fixing it up for
> publication. I hope to make bytconv available in go get'able form within a
> week. I'll let you know when it' is avalable.
>
> Peter
>
> On Friday, September 1, 2017 at 3:50:29 AM UTC-4, Sebastien Binet wrote:
>>
>> Hi,
>>
>> I'd also be very interested in looking at 'bytconv'. And most probably
>> should use it in anger :)
>>
>> -s
>>
>> sent from my droid
>>
>> On Aug 31, 2017 8:28 PM, "Michael Jones"  wrote:
>>
>>> 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/SgpAXyvsGs

 Here's a benchmark that demonstrates the fundamental issue, unnecessary
 string conversions.
 ,
 BenchmarkAtoiBytconv-4   5000 30.4 ns/op0 B/op0
 allocs/op
 BenchmarkAtoiStrconv-4   2000102 ns/op  8 B/op1
 allocs/op

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

 Peter


 On Thursday, August 31, 2017 at 12:24:20 PM UTC-4, peterGo wrote:
>
> 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 input strconv.
>
> Peter
>
> On Wednesday, August 30, 2017 at 7:43:49 PM UTC-4, Michael Jones wrote:
>>
>> good point. I was trying to show that the buffered stdin was "just
>> like" normal scanning but the performance was less compared to the 
>> updated
>> scanning code.
>>
>> here is another version, this time with a data generator and since
>> the input is line oriented, the default split function is fine.
>>
>> https://play.golang.org/p/SgpAXyvsGs
>> read 100 65.362993ms
>> sort 100 187.092493ms
>>
>>
>> On Wed, Aug 30, 2017 at 2:56 PM, Patrick Smith 
>> wrote:
>>
>>> That is simpler, but slower. Not nearly as slow as using unbuffered
>>> io though. Timings on my machine, reading 1e6 integers chosen randomly 
>>> from
>>> the range [0,1e18):
>>>
>>> Original code https://play.golang.org/p/grB-muK7hw
>>> 5.626974435s
>>> 155.367779ms
>>>
>>> Original poster's optimized code https://play.golang.org/p
>>> /1Aoxwwv-zo
>>> 168.638597ms
>>> 150.923225ms
>>>
>>> Michael's simpler code https://play.golang.org/p/tMyipz6sYU
>>> 954.543351ms
>>> 166.710399ms
>>>
>>> So this is about 6 times slower. My guess is this is due to the use
>>> of reflection in fmt.Fscanf. But that is just a guess; I don't really 
>>> have
>>> any evidence to back it up.
>>>
>>> On Wed, Aug 30, 2017 at 1:33 PM, Michael Jones 
>>> wrote:
>>>
 This can be much simpler...
 https://play.golang.org/p/tMyipz6sYU

 On Wed, Aug 30, 2017 at 7:55 AM, Nilsocket 
 wrote:

>
> Can you provide example code for how you read the input?
>>
>
> Both of them were given same input size is:100, (i.e., 1
> million)
>
> https://play.golang.org/p/grB-muK7hw
> // Time taken to read input : 9.840256889s
> // Time taken to sort: 731.469604ms
>
> I have implemented the same using bufio:
>
> https://play.golang.org/p/1Aoxwwv-zo
> // Time taken to read input : 377.038152ms
> // Time taken to sort: 688.20638ms
>
> --
> 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.
>



 --
 Michael T. Jones
 michae...@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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>
>>
>> --
>> Michael 

Re: [go-nuts] go1.9: problem with go get

[Andreas Briese]

Thx

i uninstalled 1.9, reinstalled 1.8.3 and the error persisted.
In the turned out, chromeos needed a bootstrap installation (using crew
install).

all the best
Andreas



On 1 September 2017 at 02:34, Ian Lance Taylor  wrote:

> 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; gcpacertrace int32; gcshrinkstackoff int32;
> > gcrescanstacks int32; gcstoptheworld int32; gctrace int32; invalidptr
> int32;
> > sbrk int32; scavenge int32; scheddetail int32; schedtrace int32 } has no
> > field or method gcstackbarrieroff)
> > /usr/local/go/src/runtime/mstkbar.go:162:24: division by zero
> > /usr/local/go/src/runtime/mstkbar.go:162:43: invalid expression
> > unsafe.Sizeof(composite literal)
> > /usr/local/go/src/runtime/mstkbar.go:162:44: undefined: stkbar
> > /usr/local/go/src/runtime/mstkbar.go:212:4: gp.stkbar undefined (type
> *g has
> > no field or method stkbar)
> > /usr/local/go/src/runtime/mstkbar.go:213:15: gp.stkbar undefined (type
> *g
> > has no field or method stkbar)
> > /usr/local/go/src/runtime/mstkbar.go:216:23: undefined: stackBarrierPC
> > /usr/local/go/src/runtime/mstkbar.go:226:28: gp.stkbarPos undefined
> (type *g
> > has no field or method stkbarPos)
> > /usr/local/go/src/runtime/mstkbar.go:227:19: gp.stkbarPos undefined
> (type *g
> > has no field or method stkbarPos)
> > /usr/local/go/src/runtime/mstkbar.go:248:41: undefined: stkbar
> > /usr/local/go/src/runtime/mstkbar.go:227:19: too many errors
> >
> > Did not really know, what's going wrong here. Never got build errors with
> > this package before.
>
> mstkbar.go does not exist in Go 1.9, so something has gone wrong with
> your upgrade from Go 1.8.  You can't simply unpack 1.9 over 1.8, so
> you must unpack 1.9 in an empty directory.
>
> 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: Struct overloading method issue

[pierre . curto]

Maybe I misunderstood your need, but I would just call the A method 
directly like below.


type A struct{}

func (a *A) private() {}
func (a *A) Public() {
   a.private()
}

type B struct {A}

func (b *B) private() {
   b.A.private()
}

bi := B{}
b.Public() //calls the A.Private



Le vendredi 1 septembre 2017 16:50:52 UTC+2, BeaT Adrian a écrit :
>
> Hello, I ran into a strange scenario and I wanted to know if there is a 
> better solution for it
>
> type A struct{}
>
> func (a *A) private() {}
> func (a *A) Public() {
>a.private()
> }
>
> type B struct {A}
>
> func (b *B) private() {}
>
> bi := B{}
> b.Public() //calls the A.Private
>
>
>
> I just want to rewrite a small part of the algorithm.
> As a workaround I used composition, but in a weird way
> type A struct {
>  private
> }
>
> func (a *A) Public() {
>if a.private == nil {
>  //set private for A
>}
>a.private
> }
> type B struct {A}
> func (b *B) Public() {
>  if b.private == nil {
>   //set private for B
>  }
> }
>
>  
>
> Other solutions I tried were not effective (how to detect in inner A 
> function that it's a B now, and should use other algorithm).
>
> 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.

[go-nuts] Re: Struct overloading method issue

[BeaT Adrian]

I solved it for now using composition and Constructors

func NewA() {
  r := A{}
  r.private = privateForA
} 

func NewB(){
  r := B{}
  r.private = privateForB
}

I saw using constructors in a few builtin packages so I guess is ok.



On Friday, September 1, 2017 at 5:50:52 PM UTC+3, BeaT Adrian wrote:
>
> Hello, I ran into a strange scenario and I wanted to know if there is a 
> better solution for it
>
> type A struct{}
>
> func (a *A) private() {}
> func (a *A) Public() {
>a.private()
> }
>
> type B struct {A}
>
> func (b *B) private() {}
>
> bi := B{}
> b.Public() //calls the A.Private
>
>
>
> I just want to rewrite a small part of the algorithm.
> As a workaround I used composition, but in a weird way
> type A struct {
>  private
> }
>
> func (a *A) Public() {
>if a.private == nil {
>  //set private for A
>}
>a.private
> }
> type B struct {A}
> func (b *B) Public() {
>  if b.private == nil {
>   //set private for B
>  }
> }
>
>  
>
> Other solutions I tried were not effective (how to detect in inner A 
> function that it's a B now, and should use other algorithm).
>
> 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] Re: "for ... range" over array of structs copies values

[Wojciech S. Czarnecki]

On Fri, 1 Sep 2017 07:32:34 -0700 (PDT)
mspre...@us.ibm.com wrote:

> that a variable is considered _addressable_ and that's all there is to it.  
> Now, in C and other such languages, there is a critical distinction about 
> addresses that is relevant: is the address on the stack or on the heap?  

"Anytime a value is shared outside the scope of a function’s stack frame, it
will be placed (or allocated) on the heap. It’s the job of the escape
analysis algorithms to find these situations and maintain a level of
integrity in the program." [from: 
https://www.goinggo.net/2017/05/language-mechanics-on-escape-analysis.html]

[Or look at an old presentation of Dave Cheney:
https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast]

Hope this helps :)

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

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

Re: [go-nuts] Re: "for ... range" over array of structs copies values

[Ian Lance Taylor]

On Fri, Sep 1, 2017 at 7:32 AM,   wrote:
>
> This just bit me.  I wonder if the discussion above missed the critical
> point.  Looking at https://golang.org/ref/spec#Address_operators, I see that
> a variable is considered _addressable_ and that's all there is to it.  Now,
> in C and other such languages, there is a critical distinction about
> addresses that is relevant: is the address on the stack or on the heap?
> Since the Go doc does not mention this distinction, I wonder if all
> variables are on the heap.  That would explain why all variables are
> addressable.  In the example that started this thread, there is only one
> loop iteration variable; supposing it is on the heap, `&` extracts a pointer
> to it, and the loop leaves the last value in that variable.
>
> The mental model I had when I wrote my code was something like the
> following.  I supposed that Go keeps local (to a block in a function)
> variables on the stack, and the compiler knows this.  A statement like `x =
> ` is equivalent to something like
> ```
> x = new()
> *x = localVar
> ```
>
> (which still seems (to me) to be the right model if we are talking about
>  instead of  --- which is what led me to think this
> way.)

When writing Go you can imagine that all variables are on the heap.

The compiler implements escape analysis optimizations that allocate
variables on the stack when it can be proven to be safe.

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] new project: pixels to svg

[baggerone]

Based on the feedback I received, I've started a new little go project on 
Github - https://github.com/Baggerone/gopixels2svg

Feel free to give me feedback on how I can improve the code or the project 
setup, etc.

To get a quick idea of how to use it, look at *TestWriteSVGToFile *in 
*pixels2svg_test.go*

-- 
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: newbie with go 1.9 troubles

[visaxin]

actually, you just remove all old version golang directory and download 1.9 
&& tar will work for me

On Thursday, August 31, 2017 at 6:47:37 AM UTC+8, rob wrote:
>
> Ubuntu 16.04 amd64 
>
> I d/l the tar.gz file and followed the instructions to install it to 
> /usr/local/go and set $PATH, $GOPATH, $GOBIN and $GOROOT. 
>
> When I do go version, I get 1.9.  But I cannot compile anything, not 
> even hello.go 
>
> The error is: 
>
> # 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; gcstoptheworld int32; gctrace int32; invalidptr 
> int32; sbrk int32; scavenge int32; scheddetail int32; schedtrace int32 } 
> has no field or method gcstackbarrieroff) 
> /usr/local/go/src/runtime/mstkbar.go:162:24: division by zero 
> /usr/local/go/src/runtime/mstkbar.go:162:43: invalid expression 
> unsafe.Sizeof(composite literal) 
> /usr/local/go/src/runtime/mstkbar.go:162:44: undefined: stkbar 
> /usr/local/go/src/runtime/mstkbar.go:212:4: gp.stkbar undefined (type *g 
> has no field or method stkbar) 
> /usr/local/go/src/runtime/mstkbar.go:213:15: gp.stkbar undefined (type 
> *g has no field or method stkbar) 
> /usr/local/go/src/runtime/mstkbar.go:216:23: undefined: stackBarrierPC 
> /usr/local/go/src/runtime/mstkbar.go:226:28: gp.stkbarPos undefined 
> (type *g has no field or method stkbarPos) 
> /usr/local/go/src/runtime/mstkbar.go:227:19: gp.stkbarPos undefined 
> (type *g has no field or method stkbarPos) 
> /usr/local/go/src/runtime/mstkbar.go:248:41: undefined: stkbar 
> /usr/local/go/src/runtime/mstkbar.go:227:19: too many errors 
>
>
> Compiling my code on windows 10 works fine with go 1.9, and it also 
> works fine on a different Ubuntu 16.04 amd64 machine on which I 
> installed go thru synaptic and have not modified that from 1.6.2 
>
>
> What am I missing? 
>
> Thanks, 
>
> Rob Solomon 
>
>

-- 
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: "for ... range" over array of structs copies values

[mspreitz]

This just bit me.  I wonder if the discussion above missed the critical 
point.  Looking at https://golang.org/ref/spec#Address_operators, I see 
that a variable is considered _addressable_ and that's all there is to it.  
Now, in C and other such languages, there is a critical distinction about 
addresses that is relevant: is the address on the stack or on the heap?  
Since the Go doc does not mention this distinction, I wonder if all 
variables are on the heap.  That would explain why all variables are 
addressable.  In the example that started this thread, there is only one 
loop iteration variable; supposing it is on the heap, `&` extracts a 
pointer to it, and the loop leaves the last value in that variable.

The mental model I had when I wrote my code was something like the 
following.  I supposed that Go keeps local (to a block in a function) 
variables on the stack, and the compiler knows this.  A statement like `x = 
` is equivalent to something like
```
x = new()
*x = localVar
```

(which still seems (to me) to be the right model if we are talking about 
 instead of  --- which is what led me to think this 
way.)

Mike

-- 
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] Help, using fmt.Sprint

[Sam Whited]

On Fri, Sep 1, 2017, at 10:00, Tong Sun wrote:
> For normal Go way, should I name the string function `*String*()` or `
> *ToString*()`? 

If you want your type to satisfy the `fmt.Stringer' interface
(https://godoc.org/fmt#Stringer) the method should be named `String'.

—Sam

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

Re: [go-nuts] Help, using fmt.Sprint

[Shawn Milochik]

fmt.Sprint returns a string. You're not assigning it to a variable, so it's
"lost."

-- 
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] Help, using fmt.Sprint

[Tong Sun]

Hi, 

What's wrong with my usage of `fmt.Sprint` in this code:

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

BTW, 

For normal Go way, should I name the string function `*String*()` or `
*ToString*()`? 

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.

[go-nuts] Struct overloading method issue

[BeaT Adrian]

Hello, I ran into a strange scenario and I wanted to know if there is a 
better solution for it

type A struct{}

func (a *A) private() {}
func (a *A) Public() {
   a.private()
}

type B struct {A}

func (b *B) private() {}

bi := B{}
b.Public() //calls the A.Private



I just want to rewrite a small part of the algorithm.
As a workaround I used composition, but in a weird way
type A struct {
 private
}

func (a *A) Public() {
   if a.private == nil {
 //set private for A
   }
   a.private
}
type B struct {A}
func (b *B) Public() {
 if b.private == nil {
  //set private for B
 }
}

 

Other solutions I tried were not effective (how to detect in inner A 
function that it's a B now, and should use other algorithm).

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] english language help

[Wojciech S. Czarnecki]

On Thu, 31 Aug 2017 05:49:57 -0700 (PDT)
"'Niko Schwarz' via golang-nuts"  wrote:

> I think it's ok to ask in Russian on this group, too.

Бусад хэл дээр дэлгэрэнгүй техникийн яриа хэлэлцээ хийх боломжтой юу? Энэ нь
хүлээн зөвшөөрөгдсөн үү? OP төгс богино асуултыг бичсэн: "Би өөрийн хэлээр
ярьдаг хүмүүсийг хайж байна". Тэр үүнийг өөрийнхөө хэлээр асууж болох байсан.
Энэ бол зүгээр юм. Гэхдээ энэ нь англиар ярьдаг газар юм. Энд ядуу англи
хэлээр ярих нь зүгээр л зөв.

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

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

Re: [go-nuts] Bytconv where art thou

[Peter Waller]

On 1 September 2017 at 08:49, Sebastien Binet  wrote:
>
> I'd also be very interested in looking at 'bytconv'. And most probably
> should use it in anger :)
>

I've written my own bytconv.Atoi in two projects where it gave a nice
speedup, so +1 to this.

-- 
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: sync.Map for caching

[bep]

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 
>
> 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 returns always the first
> stored item. 
>
> Second example uses a lock to create and store the item.
>
> If the creator function is expensive, then I would use the latter example 
> otherwise the first.
>
> Cheers snmed
>
>
> Am Freitag, 1. September 2017 00:18:35 UTC+2 schrieb bep:
>>
>> 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 creating the cache item is high, I would 
>> maybe do something ala:
>>
>> mu.RLock()
>> // Check cache
>> mu.RUnclock()
>>
>> // Return if found
>>
>> // If Not found:
>> mu.Lock()
>> defer mu.Unlock()
>> // Double check cache, return if found
>> // Create item and put in cache
>>
>>
>>
>>
>> I don't see how the above can be written with a sync.Map without adding a 
>> mutex.
>>
>> bep
>>
>

-- 
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: sync.Map for caching

[snmed]

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 returns always the first
stored item. 

Second example uses a lock to create and store the item.

If the creator function is expensive, then I would use the latter example 
otherwise the first.

Cheers snmed


Am Freitag, 1. September 2017 00:18:35 UTC+2 schrieb bep:
>
> 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 creating the cache item is high, I would 
> maybe do something ala:
>
> mu.RLock()
> // Check cache
> mu.RUnclock()
>
> // Return if found
>
> // If Not found:
> mu.Lock()
> defer mu.Unlock()
> // Double check cache, return if found
> // Create item and put in cache
>
>
>
>
> I don't see how the above can be written with a sync.Map without adding a 
> mutex.
>
> bep
>

-- 
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] sync.Map for caching

[Henrik Johansson]

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.
>
> 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 creating the cache item is high, I would
> maybe do something ala:
>
> mu.RLock()
> // Check cache
> mu.RUnclock()
>
> // Return if found
>
> // If Not found:
> mu.Lock()
> defer mu.Unlock()
> // Double check cache, return if found
> // Create item and put in cache
>
>
>
>
> I don't see how the above can be written with a sync.Map without adding a
> mutex.
>
> bep
>
> --
> 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.