date:20160703

Thanks  Matt.

After your advice (and some reflection) - i decided to refactor all my code
and keep the matrix in colour.Colour values rather than uint32's.

Am actually happier i did it, as it provides for more neater / more concise
code with better readability.

Interestingly though, when i do a colour swap (without any type casting
happening now) - the colour problem is still there.

In the images below, the letter "RGB" in their respective colours should
have purely swapped colours - but as you can see from the image below, just
reading and writing the same colours produces a visibly different hue on
the red (which has become a pink on the letter G now). There was absolutely
no manipulation of the values that happened, only a swapping... i guess
i'll try to dig into the source for Decode/Reader function (i think that's
where it's happening as when i write the image as a jpg/gif/png - they all
have the colour issue).

Image from:
https://github.com/simran91/monkeysee/blob/master/samples/rgb.png

 [image: rgb.png]

Image from:
https://github.com/simran91/monkeysee/blob/master/samples/rgb-png-to-png-mod-SwapRGBtoGBR-autogenerated.png

[image: rgb-png-to-png-mod-SwapRGBtoGBR-autogenerated.png]

thanks for your help though... have really appreciated it.

cheers,

simran.

On Mon, Jul 4, 2016 at 12:26 PM, Matt Harden  wrote:

> I think you're best off not taking the RGBA values and then building a
> color from them. Just take the color you're given and use m.Set(x, y, c) on
> the target image. If you need to modify the color, one way to do that would
> be to create your own object that implements the color.Color interface (the
> RGBA() method) and returns int32 values based on the source color's values.
> For example swapping red & green. Maybe this example will help:
> https://play.golang.org/p/vD1YBLR7nn
>
> On Sun, Jul 3, 2016 at 7:09 PM simran  wrote:
>
>> Hi Dan,
>>
>> I get a "page not found" on all those four links...
>>
>> cheers,
>>
>> simran.
>>
>> On Mon, Jul 4, 2016 at 10:22 AM, Dan Kortschak <
>> dan.kortsc...@adelaide.edu.au> wrote:
>>
>>> github.com/gonum/matrix/mat64 (soonish to be gonum.org/pkg/matrix/mat64)
>>> is a general purpose matrix library.
>>>
>>> A more specific image maths package is available at
>>> github.com/go-gl/mathgl/mgl{32,64}
>>> .
>>>
>>> On Mon, 2016-07-04 at 10:07 +1000, simran wrote:
>>> > Hi Dan,
>>> >
>>> > I am hoping to find a general matrix library as i want to write my own
>>> > rotation, translation, reflection methods; however, if you do know a
>>> > good
>>> > image library doing these, i'd appreciate it as a reference anyway.
>>> >
>>> > cheers,
>>> >
>>> > simran.
>>>
>>>
>>>
>> --
>> 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.

Re: [go-nuts] Matrix Library && colour uint32's vs uint8's

:) Thanks Dan... my mental blank moment (which lasted an hour!) got me! :)
i definitely look a giraffe staring at the headlights now! :)



On Mon, Jul 4, 2016 at 12:27 PM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:

> They're packages, not links.
>
> https://github.com/gonum/matrix
> - docs: https://godoc.org/github.com/gonum/matrix/mat64
>
> https://github.com/go-gl/mathgl
> - docs: https://godoc.org/github.com/go-gl/mathgl/mgl64
>
> On Mon, 2016-07-04 at 12:08 +1000, simran wrote:
> > Hi Dan,
> >
> > I get a "page not found" on all those four links...
> >
> > cheers,
> >
> > simran.
>
>
>

-- 
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] why is my program retaining memory when len([]byte)>16384 ?

2016-07-03 Thread Jesse McNelis

On Mon, Jul 4, 2016 at 3:35 AM, mhhcbon  wrote:
> Hi,
>
> I have this program which reads file, flate encode then flate decode the
> data.
>
> I noticed that when i used different size for the slice of []byte to read
> data, the program will retain memory when the size is > 16384.
> When its lower than this value everything is fine, but 16385 breaks.
>
> I don t quite understand the reason of this behavior, can someone help me to
> understand what s going on there ?

I can't see anywhere that this program could be holding on to extra
memory it's not using.
But the problem might just be that you're writing many more bytes to
your encoder than you're reading from the file.

_, err := src.Read(b); // read from file

Read() isn't required to fill the whole buffer it's given. It can read
a single byte and return.
Because you're ignoring the value telling you how many bytes it read
you're passing the whole 16385 slice to your encoder even though you
might have read much less than 16385 bytes.

This means the size of buf2 could be much larger than the original
file and also full of junk data from previous reads and zeroed bytes.

Read() is a low level call that you should avoid calling directly
because it's tricky to get right.

For an example of how to properly call a Read() see the implementation
of io.Copy()
https://golang.org/src/io/io.go?#L366

-- 
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] Meet runtime.typedslicecopy: nosplit stack overflow error when cross platform compiling.

On Sun, Jul 3, 2016 at 8:07 PM,   wrote:
> Build Env:
>
>  Build tool: GoClipse
>  Windows(7):
>  Go Installation: go1.6.2 windows/amd64
>
>  Under default build environment, every thing goes well. I could find the
> .exe file in bin folder. But if I try to build target for linux with setting
> environment:
>  GOOS=linux
>  GOARCH=amd64
>
>  I will get the following error: (Copy from goclispe console)
>
>   Building Go project: personal.study  
>   with GOPATH: E:\go_ws
>>> Running: C:\Go\bin\go.exe install -v -gcflags "-N -l" personal.study/...
> personal.study/go/main
> # personal.study/go/main
> runtime.typedslicecopy: nosplit stack overflow
> 584 assumed on entry to runtime.typedslicecopy (nosplit)
> 448 after runtime.typedslicecopy (nosplit) uses 136
> 440 on entry to runtime.cgoCheckSliceCopy (nosplit)
> 376 after runtime.cgoCheckSliceCopy (nosplit) uses 64
> 368 on entry to runtime.cgoCheckTypedBlock (nosplit)
> 168 after runtime.cgoCheckTypedBlock (nosplit) uses 200
> 160 on entry to runtime.cgoCheckBits (nosplit)
> 24 after runtime.cgoCheckBits (nosplit) uses 136
> 16 on entry to runtime.cgoIsGoPointer (nosplit)
> -32 after runtime.cgoIsGoPointer (nosplit) uses 48
> runtime.sigtrampgo: nosplit stack overflow
> 584 assumed on entry to runtime.sigtrampgo (nosplit)
> 392 after runtime.sigtrampgo (nosplit) uses 192
> 384 on entry to runtime.sigfwdgo (nosplit)
> 288 after runtime.sigfwdgo (nosplit) uses 96
> 280 on entry to runtime.dieFromSignal (nosplit)
> 240 after runtime.dieFromSignal (nosplit) uses 40
> 232 on entry to runtime.setsig (nosplit)
> 40 after runtime.setsig (nosplit) uses 192
> 32 on entry to runtime.funcPC (nosplit)
> 0 after runtime.funcPC (nosplit) uses 32
> -8 on entry to runtime.add (nosplit)
> runtime.cgocallback_gofunc: nosplit stack overflow
> 584 assumed on entry to runtime.cgocallback_gofunc (nosplit)
> 576 after runtime.cgocallback_gofunc (nosplit) uses 8
> 568 on entry to runtime.cgocallbackg (nosplit)
> 480 after runtime.cgocallbackg (nosplit) uses 88
> 472 on entry to runtime.exitsyscall (nosplit)
> 352 after runtime.exitsyscall (nosplit) uses 120
> 344 on entry to runtime.exitsyscallfast (nosplit)
> 184 after runtime.exitsyscallfast (nosplit) uses 160
> 176 on entry to runtime.writebarrierptr (nosplit)
> 128 after runtime.writebarrierptr (nosplit) uses 48
> 120 on entry to runtime.cgoCheckWriteBarrier (nosplit)
> 56 after runtime.cgoCheckWriteBarrier (nosplit) uses 64
> 48 on entry to runtime.cgoIsGoPointer (nosplit)
> 0 after runtime.cgoIsGoPointer (nosplit) uses 48
> -8 on entry to runtime.cgoInRange (nosplit)
>^^^ Terminated, exit code: 2 ^^^
>   Build terminated.  
>
> What's wrong with me? Any warier could help me ~ Thank you!

It's arguably a bug, but not a very important one.  The workaround is
to not use "-N -l" for the runtime package.

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] Meet runtime.typedslicecopy: nosplit stack overflow error when cross platform compiling.

2016-07-03 Thread velly . zhou

Build Env:

 Build tool: GoClipse
 Windows(7):
 Go Installation: go1.6.2 windows/amd64

 Under default build environment, every thing goes well. I could find the 
.exe file in bin folder. But if I try to build target for linux with 
setting environment:
 GOOS=linux
 GOARCH=amd64

 I will get the following error: (Copy from goclispe console)

  Building Go project: personal.study  
  with GOPATH: E:\go_ws
>> Running: C:\Go\bin\go.exe install -v -gcflags "-N -l" personal.study/...
personal.study/go/main
# personal.study/go/main
runtime.typedslicecopy: nosplit stack overflow
584 assumed on entry to runtime.typedslicecopy (nosplit)
448 after runtime.typedslicecopy (nosplit) uses 136
440 on entry to runtime.cgoCheckSliceCopy (nosplit)
376 after runtime.cgoCheckSliceCopy (nosplit) uses 64
368 on entry to runtime.cgoCheckTypedBlock (nosplit)
168 after runtime.cgoCheckTypedBlock (nosplit) uses 200
160 on entry to runtime.cgoCheckBits (nosplit)
24 after runtime.cgoCheckBits (nosplit) uses 136
16 on entry to runtime.cgoIsGoPointer (nosplit)
-32 after runtime.cgoIsGoPointer (nosplit) uses 48
runtime.sigtrampgo: nosplit stack overflow
584 assumed on entry to runtime.sigtrampgo (nosplit)
392 after runtime.sigtrampgo (nosplit) uses 192
384 on entry to runtime.sigfwdgo (nosplit)
288 after runtime.sigfwdgo (nosplit) uses 96
280 on entry to runtime.dieFromSignal (nosplit)
240 after runtime.dieFromSignal (nosplit) uses 40
232 on entry to runtime.setsig (nosplit)
40 after runtime.setsig (nosplit) uses 192
32 on entry to runtime.funcPC (nosplit)
0 after runtime.funcPC (nosplit) uses 32
-8 on entry to runtime.add (nosplit)
runtime.cgocallback_gofunc: nosplit stack overflow
584 assumed on entry to runtime.cgocallback_gofunc (nosplit)
576 after runtime.cgocallback_gofunc (nosplit) uses 8
568 on entry to runtime.cgocallbackg (nosplit)
480 after runtime.cgocallbackg (nosplit) uses 88
472 on entry to runtime.exitsyscall (nosplit)
352 after runtime.exitsyscall (nosplit) uses 120
344 on entry to runtime.exitsyscallfast (nosplit)
184 after runtime.exitsyscallfast (nosplit) uses 160
176 on entry to runtime.writebarrierptr (nosplit)
128 after runtime.writebarrierptr (nosplit) uses 48
120 on entry to runtime.cgoCheckWriteBarrier (nosplit)
56 after runtime.cgoCheckWriteBarrier (nosplit) uses 64
48 on entry to runtime.cgoIsGoPointer (nosplit)
0 after runtime.cgoIsGoPointer (nosplit) uses 48
-8 on entry to runtime.cgoInRange (nosplit)
   ^^^ Terminated, exit code: 2 ^^^
  Build terminated.  

What's wrong with me? Any warier could help me ~ Thank you! 

-- 
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] Unsure when two interfaces are considered identical

On Sun, Jul 3, 2016 at 12:27 PM, Jon Bodner  wrote:
>
> I'm working on a DAO adapter layer helper called Proteus
> (https://github.com/jonbodner/proteus), and ran into an interesting quirk in
> what Go considers equivalent interfaces. I recreated a simplified version of
> the issue is at https://play.golang.org/p/BS3-bUKtO9 .
>
> The code that I linked does not compile, with the error:
>
> V does not implement CalcB (wrong type for Calculate method)
> have Calculate(int) ResultA
> want Calculate(int) ResultB
>
>
> ResultA and ResultB are identical interfaces; both define a single method
> Result that takes in no parameters and return an int.
>
> However, if I put in a wrapper around V, I can get it to work:
> https://play.golang.org/p/XUoZwsBaFn
>
> What I don't understand is that the wrapper doesn't do any casting of
> ResultA to ResultB, and that's OK in this situation. But the Go compiler
> can't figure out that ResultA and ResultB are identical without that
> wrapper. Why is that? Why does the compiler fail the first case and pass the
> second one?

ResultA and ResultB are assignable but not identical.

https://golang.org/ref/spec#Type_identity
https://golang.org/ref/spec#Assignability

For the specific case of interface types, you may be interested in
https://golang.org/issue/16209 .

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] Unused var written in closure

On Sat, Jul 2, 2016 at 2:20 AM,   wrote:
> More generally, this is https://github.com/golang/go/issues/10989.
>
> Such ineffectual assignments can be detected using
> https://github.com/gordonklaus/ineffassign.
>
> An analysis showed that only a small fraction of such were bugs, making the
> backwards-incompatible language change not worthwhile.
>
> @ianlancetaylor: It's interesting that gccgo gives an error for the case
> given in this thread.  Does it also flag other "assigned and not used", like
>
> func main() {
> x := 0
> _ = x
> x = 1
> }
>
> ?

gccgo does not warn about that.

The warning issued by gc and gccgo is described by this implementation
restriction in the spec: "A compiler may make it illegal to declare a
variable inside a function body if the variable is never used"
(https://golang.org/ref/spec#Variable_declarations).  In the above
function, the variable is used, so an error is not permitted by the
spec.

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 does iota affect the types of the subsequent constants in a constant declaration?

2016-07-03 Thread Jingguo Yao

Matt:

Thanks for you confirmation.

--
Jingguo

-- 
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: http/2 with go version 1.6.2 not working under iOS 9 mobile Safari

2016-07-03 Thread constantine

Also I am using LetsEncrypt

On Saturday, July 2, 2016 at 5:21:40 PM UTC-7, Constantine Vassilev wrote:
>
> I am using go version 1.6.2 to set up a web page to work with
> http/2.
>
> It is working on desktop but in iOS 9 mobile Safari the site does not 
> loads.
>
> Here is my setup:
>
> OS El Capitan
> Version 10.11.5
>
> ===
> s := http.Server{Addr: addr + ":443"}
> http2.ConfigureServer(, nil)
> err := s.ListenAndServeTLS(certpem, keypad)
> ===
>
> http/2 test:
> ===
> curl -I --http2 https://www.MyDomain.com
> *HTTP/2 200*
> content-type: text; charset=utf-8
> content-length: 39
> ===
>
> What is 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] Unsure when two interfaces are considered identical

2016-07-03 Thread Jon Bodner

Hello,

I'm working on a DAO adapter layer helper called Proteus 
(https://github.com/jonbodner/proteus), and ran into an interesting quirk 
in what Go considers equivalent interfaces. I recreated a simplified 
version of the issue is at https://play.golang.org/p/BS3-bUKtO9 .

The code that I linked does not compile, with the error:

V does not implement CalcB (wrong type for Calculate method)
have Calculate(int) ResultA
want Calculate(int) ResultB


ResultA and ResultB are identical interfaces; both define a single method 
Result that takes in no parameters and return an int.

However, if I put in a wrapper around V, I can get it to 
work: https://play.golang.org/p/XUoZwsBaFn

What I don't understand is that the wrapper doesn't do any casting of 
ResultA to ResultB, and that's OK in this situation. But the Go compiler 
can't figure out that ResultA and ResultB are identical without that 
wrapper. Why is that? Why does the compiler fail the first case and pass 
the second one?

Thanks, 

Jon

-- 
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] Matrix Library && colour uint32's vs uint8's

My previous example didn't compile because I made a change right before
hitting share. Here's a working version.
https://play.golang.org/p/E3dPLRjFvW

On Sun, Jul 3, 2016 at 7:27 PM Dan Kortschak 
wrote:

> They're packages, not links.
>
> https://github.com/gonum/matrix
> - docs: https://godoc.org/github.com/gonum/matrix/mat64
>
> https://github.com/go-gl/mathgl
> - docs: https://godoc.org/github.com/go-gl/mathgl/mgl64
>
> On Mon, 2016-07-04 at 12:08 +1000, simran wrote:
> > Hi Dan,
> >
> > I get a "page not found" on all those four links...
> >
> > cheers,
> >
> > simran.
>
>
> --
> 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.

Re: [go-nuts] Matrix Library && colour uint32's vs uint8's

They're packages, not links.

https://github.com/gonum/matrix
- docs: https://godoc.org/github.com/gonum/matrix/mat64

https://github.com/go-gl/mathgl
- docs: https://godoc.org/github.com/go-gl/mathgl/mgl64

On Mon, 2016-07-04 at 12:08 +1000, simran wrote:
> Hi Dan,
> 
> I get a "page not found" on all those four links...
> 
> cheers,
> 
> simran.


-- 
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] Matrix Library && colour uint32's vs uint8's

I think you're best off not taking the RGBA values and then building a
color from them. Just take the color you're given and use m.Set(x, y, c) on
the target image. If you need to modify the color, one way to do that would
be to create your own object that implements the color.Color interface (the
RGBA() method) and returns int32 values based on the source color's values.
For example swapping red & green. Maybe this example will help:
https://play.golang.org/p/vD1YBLR7nn

On Sun, Jul 3, 2016 at 7:09 PM simran  wrote:

> Hi Dan,
>
> I get a "page not found" on all those four links...
>
> cheers,
>
> simran.
>
> On Mon, Jul 4, 2016 at 10:22 AM, Dan Kortschak <
> dan.kortsc...@adelaide.edu.au> wrote:
>
>> github.com/gonum/matrix/mat64 (soonish to be gonum.org/pkg/matrix/mat64)
>> is a general purpose matrix library.
>>
>> A more specific image maths package is available at
>> github.com/go-gl/mathgl/mgl{32,64}
>> .
>>
>> On Mon, 2016-07-04 at 10:07 +1000, simran wrote:
>> > Hi Dan,
>> >
>> > I am hoping to find a general matrix library as i want to write my own
>> > rotation, translation, reflection methods; however, if you do know a
>> > good
>> > image library doing these, i'd appreciate it as a reference anyway.
>> >
>> > cheers,
>> >
>> > simran.
>>
>>
>>
> --
> 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] How does iota affect the types of the subsequent constants in a constant declaration?

2016-07-03 Thread Jingguo Yao

Take the following code as an example:


package main
import (
  "fmt"
)
const (
  First int64 = iota
  Second
)
const (
  One int64 = 1
  Two = 2
)
func main() {
  fmt.Printf("First type: %T, Second type: %T\n", First, Second)
  fmt.Printf("One type: %T, Two type: %T\n", One, Two)
}


Running the above code produces:


First type: int64, Second type: int64
One type: int64, Two type: int


Why is Second's type int64 instead of the default type int like Two? I think
that it is decided by the following rule from 
https://golang.org/ref/spec#Constant_declarations. Is my understanding
correct?


> Within a parenthesized const declaration list the expression list
> may be omitted from any but the first declaration. Such an empty
> list is equivalent to the textual substitution of the first
> preceding non-empty expression list and its type if any. Omitting
> the list of expressions is therefore equivalent to repeating the
> previous list. The number of identifiers must be equal to the number
> of expressions in the previous list.


-- 
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] Matrix Library && colour uint32's vs uint8's

Hi Dan,

I get a "page not found" on all those four links...

cheers,

simran.

On Mon, Jul 4, 2016 at 10:22 AM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:

> github.com/gonum/matrix/mat64 (soonish to be gonum.org/pkg/matrix/mat64)
> is a general purpose matrix library.
>
> A more specific image maths package is available at
> github.com/go-gl/mathgl/mgl{32,64}.
>
> On Mon, 2016-07-04 at 10:07 +1000, simran wrote:
> > Hi Dan,
> >
> > I am hoping to find a general matrix library as i want to write my own
> > rotation, translation, reflection methods; however, if you do know a
> > good
> > image library doing these, i'd appreciate it as a reference anyway.
> >
> > cheers,
> >
> > simran.
>
>
>

-- 
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] Matrix Library && colour uint32's vs uint8's

I'm still getting the red's turning to pinks...

You make an interesting point about the format of the source image... i was
assuming that the image/{png,jpeg,gif} packages can read in a file and
whatever the colour profiles were, i could get the equivalent RGBA values
for them (this does appear to be the case given the available methods), and
the values are given to me in uint32's (most of the images i have seem to
have more than 8-bit colour in them).

The issue seems to be that (even if it's internal to the package) that
information is getting lost when i can get the values in uint32's (for any
image read from file; rather than created inline) for the original colour
depth, but when setting them, i have to cast them to a more basic uint8's
and then write the images back to the filesystem.

Perhaps i need to dig into https://golang.org/src/image/png
/{reader,writer}.go
to understand what is going on and how the core image/png package decodes
and encodes stuff...

On Mon, Jul 4, 2016 at 10:13 AM, Matt Harden  wrote:

> This one avoids the type assertion: https://play.golang.org/p/vDB9RboNZj
>
> On Sun, Jul 3, 2016 at 5:11 PM Matt Harden  wrote:
>
>> If the source image is an image.RGBA, then the colors are already int8s;
>> there's no additional information to lose. Here's an example that swaps the
>> green and red channels of the pixel at (0,0):
>> https://play.golang.org/p/i6F29OsdgD
>>
>> On Sun, Jul 3, 2016 at 5:08 PM simran  wrote:
>>
>>> Hi Dan,
>>>
>>> I am hoping to find a general matrix library as i want to write my own
>>> rotation, translation, reflection methods; however, if you do know a good
>>> image library doing these, i'd appreciate it as a reference anyway.
>>>
>>> cheers,
>>>
>>> simran.
>>>
>>> On Mon, Jul 4, 2016 at 10:00 AM, Dan Kortschak <
>>> dan.kortsc...@adelaide.edu.au> wrote:
>>>
 Are you looking for generalised matrices or simply image
 rotation/translation?

 On Mon, 2016-07-04 at 02:06 +1000, simran wrote:
 >
 > Could someone please point me to a good matrix library for Go (i'm
 > sure
 > something exists, although i can't seem to find it!).
 >
 > Am hoping to do some image manipulation for which being able to work
 > with
 > matrices would be great.

>>> --
>>> 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] liteide x30 released

2016-07-03 Thread vfc

Hi, all
liteide x30 released!
This version bug fix, support go1.7, add fakevim mode (thanks jsuppe
https://github.com/jsuppe) , add quick open files (ctrl+p) and quick open
editor (ctrl+alt+p) actions.

LiteIDE Source code : https://github.com/visualfc/liteide
Gotools Source code : https://github.com/visualfc/gotools
Binary downloads : http://sourceforge.net/projects/liteide/files
Latest downloads : http://git.oschina.net/visualfc/liteide/attach_files

### 2016.7.2 Ver X30
* LiteIDE
* add new QuickOpen plugin
* add new FakeVim plugin, thanks for [jsuppe](https://github.com/jsuppe)
* add custom env LITEIDE_TOOL_PATH/LITEIDE_PLUGIN_PATH/LITEIDE_RES_PATH
* LiteApp
* action tooltip shortcut show native text
* option keyboard map show native text
* QuickOpen
* quick open files action CTRL+P
* quick open editor action CTRL+ALT+P
* quick go to line action CTRL+L
* quick open help
* FakeVim
* editor add vim style mode editing
* LiteEditor
* add goto line start/end action
* add goto doc start/end action
* add goto previous/next line action
* add goto previous/next charater action
* add goto previous/next word action
* change '' braces only go source
* fix codecompleter number first
* MacOS fix move line up/down shortcut command+shift+up/down
* GolangEdit
* CTRL+mouse navigate preview source info
* LiteFind
* MacOS fix edit replace shortcut command+shift+F
* Welcome
* fix doc css style
* gotools
* types fix limit parser
* types simple field info

-- 
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] Matrix Library && colour uint32's vs uint8's

github.com/gonum/matrix/mat64 (soonish to be gonum.org/pkg/matrix/mat64)
is a general purpose matrix library.

A more specific image maths package is available at
github.com/go-gl/mathgl/mgl{32,64}.

On Mon, 2016-07-04 at 10:07 +1000, simran wrote:
> Hi Dan,
> 
> I am hoping to find a general matrix library as i want to write my own
> rotation, translation, reflection methods; however, if you do know a
> good
> image library doing these, i'd appreciate it as a reference anyway.
> 
> cheers,
> 
> simran.


-- 
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] Matrix Library && colour uint32's vs uint8's

This one avoids the type assertion: https://play.golang.org/p/vDB9RboNZj

On Sun, Jul 3, 2016 at 5:11 PM Matt Harden  wrote:

> If the source image is an image.RGBA, then the colors are already int8s;
> there's no additional information to lose. Here's an example that swaps the
> green and red channels of the pixel at (0,0):
> https://play.golang.org/p/i6F29OsdgD
>
> On Sun, Jul 3, 2016 at 5:08 PM simran  wrote:
>
>> Hi Dan,
>>
>> I am hoping to find a general matrix library as i want to write my own
>> rotation, translation, reflection methods; however, if you do know a good
>> image library doing these, i'd appreciate it as a reference anyway.
>>
>> cheers,
>>
>> simran.
>>
>> On Mon, Jul 4, 2016 at 10:00 AM, Dan Kortschak <
>> dan.kortsc...@adelaide.edu.au> wrote:
>>
>>> Are you looking for generalised matrices or simply image
>>> rotation/translation?
>>>
>>> On Mon, 2016-07-04 at 02:06 +1000, simran wrote:
>>> >
>>> > Could someone please point me to a good matrix library for Go (i'm
>>> > sure
>>> > something exists, although i can't seem to find it!).
>>> >
>>> > Am hoping to do some image manipulation for which being able to work
>>> > with
>>> > matrices would be great.
>>>
>>>
>>>
>> --
>> 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.

Re: [go-nuts] Matrix Library && colour uint32's vs uint8's

If the source image is an image.RGBA, then the colors are already int8s;
there's no additional information to lose. Here's an example that swaps the
green and red channels of the pixel at (0,0):
https://play.golang.org/p/i6F29OsdgD

On Sun, Jul 3, 2016 at 5:08 PM simran  wrote:

> Hi Dan,
>
> I am hoping to find a general matrix library as i want to write my own
> rotation, translation, reflection methods; however, if you do know a good
> image library doing these, i'd appreciate it as a reference anyway.
>
> cheers,
>
> simran.
>
> On Mon, Jul 4, 2016 at 10:00 AM, Dan Kortschak <
> dan.kortsc...@adelaide.edu.au> wrote:
>
>> Are you looking for generalised matrices or simply image
>> rotation/translation?
>>
>> On Mon, 2016-07-04 at 02:06 +1000, simran wrote:
>> >
>> > Could someone please point me to a good matrix library for Go (i'm
>> > sure
>> > something exists, although i can't seem to find it!).
>> >
>> > Am hoping to do some image manipulation for which being able to work
>> > with
>> > matrices would be great.
>>
>>
>>
> --
> 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.

Re: [go-nuts] Matrix Library && colour uint32's vs uint8's

Hi Dan,

I am hoping to find a general matrix library as i want to write my own
rotation, translation, reflection methods; however, if you do know a good
image library doing these, i'd appreciate it as a reference anyway.

cheers,

simran.

On Mon, Jul 4, 2016 at 10:00 AM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:

> Are you looking for generalised matrices or simply image
> rotation/translation?
>
> On Mon, 2016-07-04 at 02:06 +1000, simran wrote:
> >
> > Could someone please point me to a good matrix library for Go (i'm
> > sure
> > something exists, although i can't seem to find it!).
> >
> > Am hoping to do some image manipulation for which being able to work
> > with
> > matrices would be great.
>
>
>

-- 
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] Matrix Library && colour uint32's vs uint8's

Are you looking for generalised matrices or simply image
rotation/translation/transformation?

On Mon, 2016-07-04 at 02:06 +1000, simran wrote:
> 
> Could someone please point me to a good matrix library for Go (i'm
> sure
> something exists, although i can't seem to find it!).
> 
> Am hoping to do some image manipulation for which being able to work
> with
> matrices would be great.


-- 
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] Matrix Library && colour uint32's vs uint8's

Are you looking for generalised matrices or simply image
rotation/translation?

On Mon, 2016-07-04 at 02:06 +1000, simran wrote:
> 
> Could someone please point me to a good matrix library for Go (i'm
> sure
> something exists, although i can't seem to find it!).
> 
> Am hoping to do some image manipulation for which being able to work
> with
> matrices would be great.


-- 
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: Matrix Library && colour uint32's vs uint8's

Hi Constantin,

Where i seen the uint8 being defined is at:
https://golang.org/pkg/image/color/#RGBA

Although the there is a method RGBA() which returns r,g,b,a in uint32 the
struct is only uint8's and so i suspect has to be initialised as such.

What i'm finding annoying is that the following fails:

*package main*

*import "image"*
*import "image/color"*

*func main() {*
* m := image.NewRGBA(image.Rect(0, 0, 1, 1))*
* x, y := 0, 0*
* colour := m.At(x, y)*
* r, g, b, a := colour.RGBA()*

* newColour := color.RGBA{r, g, b, a}*
* m.SetRGBA(x, y, newColour)*
*}*

*prog.go:12: cannot use r (type uint32) as type uint8 in field value
prog.go:12: cannot use g (type uint32) as type uint8 in field value
prog.go:12: cannot use b (type uint32) as type uint8 in field value
prog.go:12: cannot use a (type uint32) as type uint8 in field value*


Link to go playground for the above: https://play.golang.org/p/ToV1TH1NAr

Really want to this colour problem, any help appreciated :)

cheers,

simran.

On Mon, Jul 4, 2016 at 2:30 AM, Constantin Konstantinidis <
constantinkonstantini...@gmail.com> wrote:

> I cannot answer about the matrix library but the package is consistently
> talking about int and not uint8
> If you look at the specification
> https://golang.org/pkg/image/#RGBA.SetRGBA
> You can impose 64bit which is not your pupose but apparently truncating
> int is not mandatory.
> Can you indicate where you found it ?
>
> Thanks
>
>
> On Sunday, July 3, 2016 at 6:07:34 PM UTC+2, simran g wrote:
>>
>> Hi All,
>>
>> Could someone please point me to a good matrix library for Go (i'm sure
>> something exists, although i can't seem to find it!).
>>
>> Am hoping to do some image manipulation for which being able to work with
>> matrices would be great.
>>
>> Have written simple helper stuff for images (i used to find myself doing
>> the same a few time, so just put it in a library) (
>> https://github.com/simran91/monkeysee ).
>>
>> On another note, if you do look at the library above, you'll notice that
>> my source image at (
>> https://github.com/simran91/monkeysee/blob/master/samples/rgb.png) and
>> destination image at (
>> https://github.com/simran91/monkeysee/blob/master/samples/rgb-png-to-png-mod-SwapRGBtoGBR-autogenerated.png)
>> have colours messed up.
>>
>> The colours were meant to have swapped, but the Red has gone into being
>> an Pink.
>>
>> This i suspect is because when we call colour.RGBA() we get uint32's,
>> but when we set the colour using color.RGBA{r, g, b, a} they r,g,b,a have
>> to be uint8's
>> (File where i have to do the conversion:
>> https://github.com/simran91/monkeysee/blob/master/mimage/rgba-matrix-to-raw-data.go
>> )
>>
>> Has anyone else come across this? I suspect there is a way to load up
>> color.RGBA and give it uint32's? Would appreciate any pointers in that
>> regard as well.
>>
>> thanks,
>>
>> simran.
>>
> --
> 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Actually that's my mistake. It is spec'ed but not in the bullet points.
https://golang.org/ref/spec#Comparison_operators

Still, I find this hairy.

On Monday, July 4, 2016 at 12:52:11 AM UTC+2, Chad wrote:
>
> To illustrate.
> I think that an issue should be raised.
>
> https://play.golang.org/p/eiwG-4vsnJ
>
>
>
>

-- 
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: Relaxing rules on slice comparison: would it make sense?

To illustrate.
I think that an issue should be raised.

https://play.golang.org/p/eiwG-4vsnJ



-- 
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: Relaxing rules on slice comparison: would it make sense?



On Monday, July 4, 2016 at 12:09:57 AM UTC+2, as@gmail.com wrote:
>
> I wish I could be pointed to such discussion.
>>
>
> It was briefly discussed in *The Go Programming Language *book by Donovan 
> & Kernighan (p 132)
>
> *:*
>
>> An analogous “shallow” equality test for slices could be useful, and it 
>> would solve the problem with maps, but the inconsistent treatment of slices 
>> and arrays by the == operator would be confusing. The safest choice is to 
>> disallow slice comparisons altogether. 
>
>
A claim I find safe to be in disagreement with.
 

>
> Given this program, how would you modify it to include interfaces?
>
> https://play.golang.org/p/9-rhDCZol_
>

Starbytes is a pointer to a slice. It does not make a lot of sense to begin 
with.
I am pointing out the fact that if you have interfaces holding a slice, the 
current behaviour is not specified. (as in the Go's spec). That's a bug.

-- 
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: Relaxing rules on slice comparison: would it make sense?

I wish I could be pointed to such discussion.

> The language authors omitted this functionality for a reason. One of the 
> reasons is that arrays and slices are similar, and changing their 
> comparison semantics seemed confusing.
>

 https://blog.golang.org/slices specifically mentions that arrays and 
slices are not similar. The spec does as well. Currently, slices do NOT 
compare. I am simply arguing that they could very logically.

The "==" operator is only overloaded in the case of strings currently but 
that's truly an implementation detail. Strings are values but their 
implementation is of a reference type. To get the value behaviour back, the 
comparison is weakened to only take into account the underlying array 
values and not where they are located. This probably for optimisation 
purposes. 

Other than that, there is a whole consistency to the language and how it 
works. I simply would like that consistency extended.

My main argument is that without specifying the logical "comparison" 
behaviour for all reference types,* interface comparisons become unsafe*. 
It's perhaps even a *bug*.

N.B. I gave my definition of a reference type which is the definition I 
would choose for Go. It does not have to be identical to what is found in 
other languages. In any case, there probably needs to be a way to 
distinguish between types that hold a reference to another datastructure 
from those that don't.

-- 
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: Relaxing rules on slice comparison: would it make sense?

2016-07-03 Thread as . utf8

I was being facetious. You have the right to opine, but elevating opinions 
to that of proofs doesn't give the discussion any utility. I think you 
should consider the underlying assumptions in some of your points: 

1. A slice is a descriptor of an aggregate
2. A struct can resemble a descriptor of an aggregate.
3. A struct can resemble a slice
4. If a slice can be compared as a struct holding a descriptor, then maps 
can have slices as keys
5. Because it benefits this use case, it is a good feature to add to the 
language

Enumerating the drawbacks of this feature is more useful than trying to 
justify its existence. The language authors omitted this functionality for 
a reason. One of the reasons is that arrays and slices are similar, and 
changing their comparison semantics seemed confusing.  

On Sunday, July 3, 2016 at 11:32:39 AM UTC-7, Chad wrote:
>
> Pardon?
>
> On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as@gmail.com wrote:
>>
>> Hardcoded proofs should be assigned well-named identifiers. If you ever 
>> have to alter them, you don't want to be rummaging around your lemmas and 
>> corollaries.
>>
>> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>>>
>>> Ok. That "haha" was merely to show that no animosity was borne. And also 
>>> because you didn't really answer the question as I asked (by quoting the 
>>> spec) which I found funny.
>>>
>>> Alas, I guess we couldn't see eye to eye.
>>>
>>> But chill a little bit. I have given all the hardcoded proofs and people 
>>> have just given me *feelings* about what they thought should be right. 
>>> I think I have the right to disagree.
>>>
>>> Anyway, I can only wish you good continuation. :)
>>>
>>>
>>> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:

 I'm sorry but your attitude is counterproductive to the discussion.
 "haha" what? I told you I see your point, I think I know the specs very 
 well, thank you for the link.
 However, you seem incapable of accepting, despite an number of others 
 saying the contrary, despite, given a reasonable example where even the 
 standard library gets this "wrong" (according to you, according to me it's 
 exactly as it should be).
 You've been explained several times that both point of views hold valid 
 arguments so why do you insist your point of view is the only correct one 
 and everyone else is wrong?
 The authors of the language which have far more experience that me (I 
 can't speak for your experience or others), couldn't get to an agreement 
 on 
 how this should work so they took the best decision, let the user deal 
 with 
 this according to their individual needs.
 I'll stop following this thread / replying as it's pointless to do so 
 at this point.
 Good luck proving everyone else is wrong and you know better.

 On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>
> Ok, Let me help you out haha :)
>
> Here is the definition of a slice. It is not a container.
> https://golang.org/ref/spec#Slice_types
>
> I am not inventing things.
>
> I know what people on this thread said, but that's their misconception.
>
> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>
>> As you pointed out, Printf() should follow the ref spec but that 
>> doesn't happen because some humans don't perceive this accuracy as 
>> necessary or maybe because the way to resonate about slices / arrays is 
>> as 
>> containers for the actual values.
>> Thus we have Printf working as it does (and %p will indeed print the 
>> memory address of the slice type).
>>
>> I would definitely want to be able to compare []int{1, 2, 3} with 
>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for 
>> example 
>> purposes but think of them as coming from different sources)
>> Apparently you don't, and that's fine.
>>
>> That's exactly why the compiler only allows comparison with nil, to 
>> force the user to think about that should be compared, not do it by 
>> default 
>> and have potential hidden issues that might be uncovered too late in the 
>> process.
>>
>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>>
>>> In fact, that is somewhat my fault.
>>>
>>> I should ask:
>>>
>>> What is a slice?
>>> What is an array?
>>>
>>> Spoiler: a slice is a reference type in its "wikipedia-ish" 
>>> definition (auto-dereferencing) which is the reason you observe such a 
>>> result in the playground.
>>>
>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:

 No. You should not get it from here. You should get the answer from 
 the spec. Let alone the fact that the implementation should ideally 
 follow 
 the spec and not the reverse.

 On Sunday, July

Re: [go-nuts] why is my program retaining memory when len([]byte)>16384 ?

2016-07-03 Thread mhhcbon

Sorry for my explanations.

I wanted to mean that when i use a len([]byte) <=16384 
the program can read lots of megabytes and remains 
at a stable state of memory usage, 5 mb.

When i use higher values, the memory grows and keep growing.
by higher value i mean anything > 16384


The slice is valid for use only until the next buffer 
> modification (that is, only until the next call to a method like Read, 
> Write, Reset, or Truncate). The slice aliases the buffer content at 
> least until the next buffer modification, so immediate changes to the 
> slice will affect the result of future reads. 
>

Indeed, if i write some data on buf, i see the changes in r.

r := buf.Bytes() // read from encoder
fmt.Println(r)
buf.Truncate(0)
buf.Write([]byte("aaa"))
fmt.Println("___")
fmt.Println(r)

I thought it was a copy.

But now i don't understand why Truncate(0) does not erase r, 
as in https://golang.org/src/bytes/buffer.go?s=2594:2626#L57 
there is this 

b.buf = b.buf[0 : b.off+n]

Which resolves to b.buf = b.buf[0:0]


:x

Le dimanche 3 juillet 2016 21:08:01 UTC+2, Janne Snabb a écrit :
>
> On 2016-07-03 20:35, mhhcbon wrote: 
>
> > r :=buf.Bytes()// read from encoder 
> > buf.Truncate(0) 
>
>
> I did not understand your explanation of the problem, but surely there 
> is a bug in the code quoted above. 
>
> Read bytes.Buffer Bytes() function documentation: 
>
> func (b *Buffer) Bytes() []byte 
>
> Bytes returns a slice of length b.Len() holding the unread portion of 
> the buffer. The slice is valid for use only until the next buffer 
> modification (that is, only until the next call to a method like Read, 
> Write, Reset, or Truncate). The slice aliases the buffer content at 
> least until the next buffer modification, so immediate changes to the 
> slice will affect the result of future reads. 
>
>
> Janne Snabb 
> sn...@epipe.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] Re: os.exec.Command and non-nil return status

2016-07-03 Thread jimmy frasche

Sorry for bumping an oldish thread, but I just ran into this trying to
propagate an exit code.

I didn't find anything searching that was sufficiently
platform-independent, but a little spelunking into the stdlib source
bore fruit, so I thought I'd share my solution.

If you have an *exec.ExitError it embeds an *os.ProcessState.

*os.ProcessState's Sys method returns an interface{} containing the a
platform specific type from the syscall package.

But all the platform specific types have a method ExitStatus() int.
(Even nacl and Plan 9, which fake it).

So, given an *exec.ExitError x, to get the exit code you just need to do:

exitCode := x.Sys().(interface{
  ExitStatus() int
}).ExitStatus()

I suppose it wouldn't hurt to check that type assertion and return -1
if it fails, though I imagine if that ever happened it would be a bug
in a new port.


On Thu, Jun 2, 2016 at 4:14 AM, Konstantin Khomoutov
 wrote:
> On Wed, 1 Jun 2016 23:56:43 +0300
> Janne Snabb  wrote:
>
>> You should check if the type of err is *exec.ExitError and in that
>> case consider it just as non-zero exit value from the process.
>>
>> The following snippet from
>> https://golang.org/src/os/exec/exec_test.go#L123 clarifies it:
>>
>> func TestExitStatus(t *testing.T) {
>>   // Test that exit values are returned correctly
>>   cmd := helperCommand(t, "exit", "42")
>>   err := cmd.Run()
>>   want := "exit status 42"
>>
>>   if werr, ok := err.(*exec.ExitError); ok {
>>   if s := werr.Error(); s != want {
>>   t.Errorf("from exit 42 got exit %q, want %q",
>> s, want) }
>>   } else {
>>   t.Fatalf("expected *exec.ExitError from exit 42; got %
>> T: %v", err, err) }
>> }
>
> I'd warn the OP to take this snippet with a hefty grain of salt: while
> it's perfectly reasonable for the test suite of an stdlib package to
> test the output of os/exec.ExitError.Error(), 3rd-party code must not
> rely on the output of the Error() methods of error values of any type to
> be predictable and stable -- at least until there's absolutely no
> other way to get onto error's details.
>
> That is, the OP should consider writing a helper function to test the
> error returned by os/exec.Cmd.Run() et al to check whether the exit
> status is non-zero and discard the error value if so.
>
> An example:
>
> 8<
> package main
>
> import (
> "os/exec"
> "testing"
> )
>
> func maybeIgnore(err error) error {
> if _, ok := err.(*exec.ExitError); ok {
> return nil
> }
> return err
> }
>
> func TestExitCode(t *testing.T) {
> cmd := exec.Command("/bin/sh", "-c", "exit 42")
> err := maybeIgnore(cmd.Run())
> if err != nil {
> t.Error("Expected nil error, got: %#v", err)
> }
> cmd = exec.Command("./does not exist, really")
> err = maybeIgnore(cmd.Run())
> if err == nil {
> t.Error("Expected non-nil error, got nil")
> }
> }
> 8<
>
> (Save as  "whatever_test.go" and run `go test`.)
>
> --
> 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.

Re: [go-nuts] Announce hugot - a chat bot package

2016-07-03 Thread Derrick Schneider

Still t

On Sunday, July 3, 2016, Tristan Colgate 
wrote:

> Hi All,
>   I'd like to announce hugot. An (hopefully) idiomatic library for
> building chat bots.
>   It is inspired by net/http, and hopefully let's you build bots up how
> you want to.
>   I'm particularly interested in feedback on the API. (...and test
> coverage is next on my list, promise!)
>   Hopefully I'll have a few chat ops focused handlers releasable soon.
>   See the godocs http://godoc.org/github.com/tcolgate/hugot .I'll be
> adding some proper examples in there soon. For the moment, examples are in
> the report.
>
> --
> 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.
>


-- 
Writer. Programmer. Puzzle Designer.
http://programmingobsession.blogspot.com
http://github.com/derricks
http://geekdad.com/author/derrickschneider/

-- 
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] why is my program retaining memory when len([]byte)>16384 ?

2016-07-03 Thread Janne Snabb

On 2016-07-03 20:35, mhhcbon wrote:

> r :=buf.Bytes()// read from encoder
> buf.Truncate(0)

I did not understand your explanation of the problem, but surely there
is a bug in the code quoted above.

Read bytes.Buffer Bytes() function documentation:

func (b *Buffer) Bytes() []byte

Bytes returns a slice of length b.Len() holding the unread portion of
the buffer. The slice is valid for use only until the next buffer
modification (that is, only until the next call to a method like Read,
Write, Reset, or Truncate). The slice aliases the buffer content at
least until the next buffer modification, so immediate changes to the
slice will affect the result of future reads.

Janne Snabb
sn...@epipe.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] Re: Relaxing rules on slice comparison: would it make sense?

Pardon?

On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as@gmail.com wrote:
>
> Hardcoded proofs should be assigned well-named identifiers. If you ever 
> have to alter them, you don't want to be rummaging around your lemmas and 
> corollaries.
>
> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>>
>> Ok. That "haha" was merely to show that no animosity was borne. And also 
>> because you didn't really answer the question as I asked (by quoting the 
>> spec) which I found funny.
>>
>> Alas, I guess we couldn't see eye to eye.
>>
>> But chill a little bit. I have given all the hardcoded proofs and people 
>> have just given me *feelings* about what they thought should be right. I 
>> think I have the right to disagree.
>>
>> Anyway, I can only wish you good continuation. :)
>>
>>
>> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>>>
>>> I'm sorry but your attitude is counterproductive to the discussion.
>>> "haha" what? I told you I see your point, I think I know the specs very 
>>> well, thank you for the link.
>>> However, you seem incapable of accepting, despite an number of others 
>>> saying the contrary, despite, given a reasonable example where even the 
>>> standard library gets this "wrong" (according to you, according to me it's 
>>> exactly as it should be).
>>> You've been explained several times that both point of views hold valid 
>>> arguments so why do you insist your point of view is the only correct one 
>>> and everyone else is wrong?
>>> The authors of the language which have far more experience that me (I 
>>> can't speak for your experience or others), couldn't get to an agreement on 
>>> how this should work so they took the best decision, let the user deal with 
>>> this according to their individual needs.
>>> I'll stop following this thread / replying as it's pointless to do so at 
>>> this point.
>>> Good luck proving everyone else is wrong and you know better.
>>>
>>> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:

 Ok, Let me help you out haha :)

 Here is the definition of a slice. It is not a container.
 https://golang.org/ref/spec#Slice_types

 I am not inventing things.

 I know what people on this thread said, but that's their misconception.

 On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>
> As you pointed out, Printf() should follow the ref spec but that 
> doesn't happen because some humans don't perceive this accuracy as 
> necessary or maybe because the way to resonate about slices / arrays is 
> as 
> containers for the actual values.
> Thus we have Printf working as it does (and %p will indeed print the 
> memory address of the slice type).
>
> I would definitely want to be able to compare []int{1, 2, 3} with 
> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
> purposes but think of them as coming from different sources)
> Apparently you don't, and that's fine.
>
> That's exactly why the compiler only allows comparison with nil, to 
> force the user to think about that should be compared, not do it by 
> default 
> and have potential hidden issues that might be uncovered too late in the 
> process.
>
> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>
>> In fact, that is somewhat my fault.
>>
>> I should ask:
>>
>> What is a slice?
>> What is an array?
>>
>> Spoiler: a slice is a reference type in its "wikipedia-ish" 
>> definition (auto-dereferencing) which is the reason you observe such a 
>> result in the playground.
>>
>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>>
>>> No. You should not get it from here. You should get the answer from 
>>> the spec. Let alone the fact that the implementation should ideally 
>>> follow 
>>> the spec and not the reverse.
>>>
>>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:

 If I look at what %v means, print out the values of various types 
 in Go, according to https://golang.org/pkg/fmt/ then I believe 
 that this holds the answer: https://play.golang.org/p/GiLckoBDxa

 On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>
> Not for comparison.
>
> I am just asking what is the value of a slice and what is the 
> value of an array.
>
> Remember that there is no slice comparison that has been spec'ed 
> so far.
>
> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>>
>> For []T the value of a slice for the purpose of comparison would 
>> be each individual value compared against each-other (ofc maybe 
>> comparing 
>> the length first as an optimization).
>> Same goes for an array.
>>

[go-nuts] Announce hugot - a chat bot package

2016-07-03 Thread Tristan Colgate

Hi All,
  I'd like to announce hugot. An (hopefully) idiomatic library for building
chat bots.
  It is inspired by net/http, and hopefully let's you build bots up how you
want to.
  I'm particularly interested in feedback on the API. (...and test coverage
is next on my list, promise!)
  Hopefully I'll have a few chat ops focused handlers releasable soon.
  See the godocs http://godoc.org/github.com/tcolgate/hugot .I'll be adding
some proper examples in there soon. For the moment, examples are in the
report.

-- 
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: Relaxing rules on slice comparison: would it make sense?

2016-07-03 Thread as . utf8

Hardcoded proofs should be assigned well-named identifiers. If you ever 
have to alter them, you don't want to be rummaging around your lemmas and 
corollaries.

On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>
> Ok. That "haha" was merely to show that no animosity was borne. And also 
> because you didn't really answer the question as I asked (by quoting the 
> spec) which I found funny.
>
> Alas, I guess we couldn't see eye to eye.
>
> But chill a little bit. I have given all the hardcoded proofs and people 
> have just given me *feelings* about what they thought should be right. I 
> think I have the right to disagree.
>
> Anyway, I can only wish you good continuation. :)
>
>
> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>>
>> I'm sorry but your attitude is counterproductive to the discussion.
>> "haha" what? I told you I see your point, I think I know the specs very 
>> well, thank you for the link.
>> However, you seem incapable of accepting, despite an number of others 
>> saying the contrary, despite, given a reasonable example where even the 
>> standard library gets this "wrong" (according to you, according to me it's 
>> exactly as it should be).
>> You've been explained several times that both point of views hold valid 
>> arguments so why do you insist your point of view is the only correct one 
>> and everyone else is wrong?
>> The authors of the language which have far more experience that me (I 
>> can't speak for your experience or others), couldn't get to an agreement on 
>> how this should work so they took the best decision, let the user deal with 
>> this according to their individual needs.
>> I'll stop following this thread / replying as it's pointless to do so at 
>> this point.
>> Good luck proving everyone else is wrong and you know better.
>>
>> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>>>
>>> Ok, Let me help you out haha :)
>>>
>>> Here is the definition of a slice. It is not a container.
>>> https://golang.org/ref/spec#Slice_types
>>>
>>> I am not inventing things.
>>>
>>> I know what people on this thread said, but that's their misconception.
>>>
>>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:

 As you pointed out, Printf() should follow the ref spec but that 
 doesn't happen because some humans don't perceive this accuracy as 
 necessary or maybe because the way to resonate about slices / arrays is as 
 containers for the actual values.
 Thus we have Printf working as it does (and %p will indeed print the 
 memory address of the slice type).

 I would definitely want to be able to compare []int{1, 2, 3} with 
 ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
 purposes but think of them as coming from different sources)
 Apparently you don't, and that's fine.

 That's exactly why the compiler only allows comparison with nil, to 
 force the user to think about that should be compared, not do it by 
 default 
 and have potential hidden issues that might be uncovered too late in the 
 process.

 On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>
> In fact, that is somewhat my fault.
>
> I should ask:
>
> What is a slice?
> What is an array?
>
> Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
> (auto-dereferencing) which is the reason you observe such a result in the 
> playground.
>
> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>
>> No. You should not get it from here. You should get the answer from 
>> the spec. Let alone the fact that the implementation should ideally 
>> follow 
>> the spec and not the reverse.
>>
>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>>
>>> If I look at what %v means, print out the values of various types in 
>>> Go, according to https://golang.org/pkg/fmt/ then I believe that 
>>> this holds the answer: https://play.golang.org/p/GiLckoBDxa
>>>
>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:

 Not for comparison.

 I am just asking what is the value of a slice and what is the value 
 of an array.

 Remember that there is no slice comparison that has been spec'ed so 
 far.

 On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>
> For []T the value of a slice for the purpose of comparison would 
> be each individual value compared against each-other (ofc maybe 
> comparing 
> the length first as an optimization).
> Same goes for an array.
>
> And again, you are missing the whole point. Both me and you are 
> wrong in each-others points of view.
> Just accept this.
>
> On Sunday, July 3, 2016 at 11:19:48 AM

[go-nuts] why is my program retaining memory when len([]byte)>16384 ?

2016-07-03 Thread mhhcbon

Hi,

I have this program which reads file, flate encode then flate decode the 
data.

I noticed that when i used different size for the slice of []byte to read 
data, the program will retain memory when the size is > 16384.
When its lower than this value everything is fine, but 16385 breaks.

I don t quite understand the reason of this behavior, can someone help me 
to understand what s going on there ?

package main

import (
  "fmt"
  "os"
  "bytes"
  // "encoding/base64"
  "compress/flate"
  "io"
)

func main () {
  // okSize := 16384
  // koSize := 64384
  // koSize := 16385 // yes 1 more and it breaks :s

  // change read size to 16384 and everything is ok
  fReadSize := 16385
  dReadSize := 64384 // dread seems not impacting

  src, _ := os.Open("big.file 1gb")
  b := make([]byte, fReadSize)

  buf := new(bytes.Buffer)
  encoder, _ := flate.NewWriter(buf, 9)

  buf2 := new(bytes.Buffer)
  var decoder io.ReadCloser
  for {
fmt.Println("---")
_, err := src.Read(b); // read from file
if err!= nil {
  break
}
// fmt.Println(b)
_, err = encoder.Write(b) // write to encoder
fmt.Println(err)
err = encoder.Flush()
fmt.Println(err)
r := buf.Bytes() // read from encoder
buf.Truncate(0)
// fmt.Println(r)
_, err = buf2.Write(r) // write to decoder
fmt.Println(err)
if decoder==nil {
  decoder = flate.NewReader(buf2)
}
r2 := make([]byte, dReadSize*2)
_, err = decoder.Read(r2) // read from decoder
fmt.Println(err)
  }
}



Does this helps ?

$ uname -a
Linux pc15-home 4.6.3-300.fc24.x86_64 #1 SMP Fri Jun 24 20:52:41 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux


thanks!



PS: no i m not interested into that version

package main

import (
  "os"
  "io"
  "compress/gzip"
)

func main () {
  pr, pw := io.Pipe()
  go func () {
decoder, _ := gzip.NewReader(pr)
io.Copy(os.Stdout, decoder)
  }()
  archiver := gzip.NewWriter(pw)
  defer archiver.Close()
  io.Copy(archiver, os.Stdin)
}

-- 
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: Matrix Library && colour uint32's vs uint8's

2016-07-03 Thread Constantin Konstantinidis

I cannot answer about the matrix library but the package is consistently 
talking about int and not uint8
If you look at the specification https://golang.org/pkg/image/#RGBA.SetRGBA
You can impose 64bit which is not your pupose but apparently truncating int 
is not mandatory.
Can you indicate where you found it ?

Thanks

On Sunday, July 3, 2016 at 6:07:34 PM UTC+2, simran g wrote:
>
> Hi All, 
>
> Could someone please point me to a good matrix library for Go (i'm sure 
> something exists, although i can't seem to find it!). 
>
> Am hoping to do some image manipulation for which being able to work with 
> matrices would be great.  
>
> Have written simple helper stuff for images (i used to find myself doing 
> the same a few time, so just put it in a library) ( 
> https://github.com/simran91/monkeysee ). 
>
> On another note, if you do look at the library above, you'll notice that 
> my source image at (
> https://github.com/simran91/monkeysee/blob/master/samples/rgb.png) and 
> destination image at (
> https://github.com/simran91/monkeysee/blob/master/samples/rgb-png-to-png-mod-SwapRGBtoGBR-autogenerated.png)
>  
> have colours messed up. 
>
> The colours were meant to have swapped, but the Red has gone into being an 
> Pink. 
>
> This i suspect is because when we call colour.RGBA() we get uint32's, but 
> when we set the colour using color.RGBA{r, g, b, a} they r,g,b,a have to be 
> uint8's 
> (File where i have to do the conversion: 
> https://github.com/simran91/monkeysee/blob/master/mimage/rgba-matrix-to-raw-data.go
> )
>
> Has anyone else come across this? I suspect there is a way to load up 
> color.RGBA and give it uint32's? Would appreciate any pointers in that 
> regard as well. 
>
> thanks,
>
> simran.
>

-- 
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] Matrix Library && colour uint32's vs uint8's

Hi All,

Could someone please point me to a good matrix library for Go (i'm sure
something exists, although i can't seem to find it!).

Am hoping to do some image manipulation for which being able to work with
matrices would be great.

Have written simple helper stuff for images (i used to find myself doing
the same a few time, so just put it in a library) (
https://github.com/simran91/monkeysee ).

On another note, if you do look at the library above, you'll notice that my
source image at (
https://github.com/simran91/monkeysee/blob/master/samples/rgb.png) and
destination image at (
https://github.com/simran91/monkeysee/blob/master/samples/rgb-png-to-png-mod-SwapRGBtoGBR-autogenerated.png)
have colours messed up.

The colours were meant to have swapped, but the Red has gone into being an
Pink.

This i suspect is because when we call colour.RGBA() we get uint32's, but
when we set the colour using color.RGBA{r, g, b, a} they r,g,b,a have to be
uint8's
(File where i have to do the conversion:
https://github.com/simran91/monkeysee/blob/master/mimage/rgba-matrix-to-raw-data.go
)

Has anyone else come across this? I suspect there is a way to load up
color.RGBA and give it uint32's? Would appreciate any pointers in that
regard as well.

thanks,

simran.

--
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 build gomobile from source

2016-07-03 Thread Constantin Konstantinidis

Upgrade to 1.6.2 would be a good idea.
Similar post is advising to 
use https://go-review.googlesource.com/#/c/24720/ to fix similar issues.




On Sunday, July 3, 2016 at 3:57:54 PM UTC+2, power...@163.com wrote:
>
> I failed to build gomobile, here are my steps,
>
> 1. git clone https://go.googlesource.com/mobile/
> 2. cd mobile\cmd\gomobile
> 3. go build
>
> I got error like
>
> package .
> imports golang.org/x/mobile/internal/binres: use of internal package 
> not allowed
>
>
> What should I do?
>
> My platform: win10 / amd64 / go 1.5.4 in c:\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.

Re: [go-nuts] Re: Append to slice... what happens?

On Sun, Jul 3, 2016 at 4:27 AM,   wrote:
> Can anyone ELI5 it to me, please ? Why if we remove cap result is different
> ? I don't understand that.

https://blog.golang.org/slices

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: Append to slice... what happens?

2016-07-03 Thread rog1ue1

Can anyone ELI5 it to me, please ? Why if we remove cap result is different 
? I don't understand that. 

-- 
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 gomobile from source

2016-07-03 Thread powerman1st

I failed to build gomobile, here are my steps,

1. git clone https://go.googlesource.com/mobile/
2. cd mobile\cmd\gomobile
3. go build

I got error like

package .
imports golang.org/x/mobile/internal/binres: use of internal package 
not allowed


What should I do?

My platform: win10 / amd64 / go 1.5.4 in c:\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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Ok. That "haha" was merely to show that no animosity was borne. And also 
because you didn't really answer the question as I asked (by quoting the 
spec) which I found funny.

Alas, I guess we couldn't see eye to eye.

But chill a little bit. I have given all the hardcoded proofs and people 
have just given me *feelings* about what they thought should be right. I 
think I have the right to disagree.

Anyway, I can only wish you good continuation. :)


On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>
> I'm sorry but your attitude is counterproductive to the discussion.
> "haha" what? I told you I see your point, I think I know the specs very 
> well, thank you for the link.
> However, you seem incapable of accepting, despite an number of others 
> saying the contrary, despite, given a reasonable example where even the 
> standard library gets this "wrong" (according to you, according to me it's 
> exactly as it should be).
> You've been explained several times that both point of views hold valid 
> arguments so why do you insist your point of view is the only correct one 
> and everyone else is wrong?
> The authors of the language which have far more experience that me (I 
> can't speak for your experience or others), couldn't get to an agreement on 
> how this should work so they took the best decision, let the user deal with 
> this according to their individual needs.
> I'll stop following this thread / replying as it's pointless to do so at 
> this point.
> Good luck proving everyone else is wrong and you know better.
>
> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>>
>> Ok, Let me help you out haha :)
>>
>> Here is the definition of a slice. It is not a container.
>> https://golang.org/ref/spec#Slice_types
>>
>> I am not inventing things.
>>
>> I know what people on this thread said, but that's their misconception.
>>
>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>>
>>> As you pointed out, Printf() should follow the ref spec but that doesn't 
>>> happen because some humans don't perceive this accuracy as necessary or 
>>> maybe because the way to resonate about slices / arrays is as containers 
>>> for the actual values.
>>> Thus we have Printf working as it does (and %p will indeed print the 
>>> memory address of the slice type).
>>>
>>> I would definitely want to be able to compare []int{1, 2, 3} with 
>>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
>>> purposes but think of them as coming from different sources)
>>> Apparently you don't, and that's fine.
>>>
>>> That's exactly why the compiler only allows comparison with nil, to 
>>> force the user to think about that should be compared, not do it by default 
>>> and have potential hidden issues that might be uncovered too late in the 
>>> process.
>>>
>>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:

 In fact, that is somewhat my fault.

 I should ask:

 What is a slice?
 What is an array?

 Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
 (auto-dereferencing) which is the reason you observe such a result in the 
 playground.

 On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>
> No. You should not get it from here. You should get the answer from 
> the spec. Let alone the fact that the implementation should ideally 
> follow 
> the spec and not the reverse.
>
> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>
>> If I look at what %v means, print out the values of various types in 
>> Go, according to https://golang.org/pkg/fmt/ then I believe that 
>> this holds the answer: https://play.golang.org/p/GiLckoBDxa
>>
>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>>>
>>> Not for comparison.
>>>
>>> I am just asking what is the value of a slice and what is the value 
>>> of an array.
>>>
>>> Remember that there is no slice comparison that has been spec'ed so 
>>> far.
>>>
>>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:

 For []T the value of a slice for the purpose of comparison would be 
 each individual value compared against each-other (ofc maybe comparing 
 the 
 length first as an optimization).
 Same goes for an array.

 And again, you are missing the whole point. Both me and you are 
 wrong in each-others points of view.
 Just accept this.

 On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>
> What's the value of a slice?
>
> What's the value of an array?
>
> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>>
>> If the type is *[]T then comparing memory addresses make sense to 
>> see if both terms point to the same memory

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

I'm sorry but your attitude is counterproductive to the discussion.
"haha" what? I told you I see your point, I think I know the specs very 
well, thank you for the link.
However, you seem incapable of accepting, despite an number of others 
saying the contrary, despite, given a reasonable example where even the 
standard library gets this "wrong" (according to you, according to me it's 
exactly as it should be).
You've been explained several times that both point of views hold valid 
arguments so why do you insist your point of view is the only correct one 
and everyone else is wrong?
The authors of the language which have far more experience that me (I can't 
speak for your experience or others), couldn't get to an agreement on how 
this should work so they took the best decision, let the user deal with 
this according to their individual needs.
I'll stop following this thread / replying as it's pointless to do so at 
this point.
Good luck proving everyone else is wrong and you know better.

On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>
> Ok, Let me help you out haha :)
>
> Here is the definition of a slice. It is not a container.
> https://golang.org/ref/spec#Slice_types
>
> I am not inventing things.
>
> I know what people on this thread said, but that's their misconception.
>
> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>
>> As you pointed out, Printf() should follow the ref spec but that doesn't 
>> happen because some humans don't perceive this accuracy as necessary or 
>> maybe because the way to resonate about slices / arrays is as containers 
>> for the actual values.
>> Thus we have Printf working as it does (and %p will indeed print the 
>> memory address of the slice type).
>>
>> I would definitely want to be able to compare []int{1, 2, 3} with 
>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
>> purposes but think of them as coming from different sources)
>> Apparently you don't, and that's fine.
>>
>> That's exactly why the compiler only allows comparison with nil, to force 
>> the user to think about that should be compared, not do it by default and 
>> have potential hidden issues that might be uncovered too late in the 
>> process.
>>
>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>>
>>> In fact, that is somewhat my fault.
>>>
>>> I should ask:
>>>
>>> What is a slice?
>>> What is an array?
>>>
>>> Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
>>> (auto-dereferencing) which is the reason you observe such a result in the 
>>> playground.
>>>
>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:

 No. You should not get it from here. You should get the answer from the 
 spec. Let alone the fact that the implementation should ideally follow the 
 spec and not the reverse.

 On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>
> If I look at what %v means, print out the values of various types in 
> Go, according to https://golang.org/pkg/fmt/ then I believe that this 
> holds the answer: https://play.golang.org/p/GiLckoBDxa
>
> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>>
>> Not for comparison.
>>
>> I am just asking what is the value of a slice and what is the value 
>> of an array.
>>
>> Remember that there is no slice comparison that has been spec'ed so 
>> far.
>>
>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>>>
>>> For []T the value of a slice for the purpose of comparison would be 
>>> each individual value compared against each-other (ofc maybe comparing 
>>> the 
>>> length first as an optimization).
>>> Same goes for an array.
>>>
>>> And again, you are missing the whole point. Both me and you are 
>>> wrong in each-others points of view.
>>> Just accept this.
>>>
>>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:

 What's the value of a slice?

 What's the value of an array?

 On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>
> If the type is *[]T then comparing memory addresses make sense to 
> see if both terms point to the same memory address.
> If the type is []T then comparing memory addresses doesn't make 
> sense as I'd expect to compare values.
> Finally, if the type is []*T then I'd still expect to compare 
> values (even if this is inconsistent with the above two rules), 
> mainly 
> because I'm usually interested in the values a slice holds.
>
> And that's exactly why Ian and others said this is complicated to 
> define as different users expect different outcomes.
> So rather than deal with this, in an auto-magic way, better let 
> the users deal with it as they see fit from case to

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Ok, Let me help you out haha :)

Here is the definition of a slice. It is not a container.
https://golang.org/ref/spec#Slice_types

I am not inventing things.

I know what people on this thread said, but that's their misconception.

On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>
> As you pointed out, Printf() should follow the ref spec but that doesn't 
> happen because some humans don't perceive this accuracy as necessary or 
> maybe because the way to resonate about slices / arrays is as containers 
> for the actual values.
> Thus we have Printf working as it does (and %p will indeed print the 
> memory address of the slice type).
>
> I would definitely want to be able to compare []int{1, 2, 3} with 
> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
> purposes but think of them as coming from different sources)
> Apparently you don't, and that's fine.
>
> That's exactly why the compiler only allows comparison with nil, to force 
> the user to think about that should be compared, not do it by default and 
> have potential hidden issues that might be uncovered too late in the 
> process.
>
> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>
>> In fact, that is somewhat my fault.
>>
>> I should ask:
>>
>> What is a slice?
>> What is an array?
>>
>> Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
>> (auto-dereferencing) which is the reason you observe such a result in the 
>> playground.
>>
>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>>
>>> No. You should not get it from here. You should get the answer from the 
>>> spec. Let alone the fact that the implementation should ideally follow the 
>>> spec and not the reverse.
>>>
>>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:

 If I look at what %v means, print out the values of various types in 
 Go, according to https://golang.org/pkg/fmt/ then I believe that this 
 holds the answer: https://play.golang.org/p/GiLckoBDxa

 On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>
> Not for comparison.
>
> I am just asking what is the value of a slice and what is the value of 
> an array.
>
> Remember that there is no slice comparison that has been spec'ed so 
> far.
>
> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>>
>> For []T the value of a slice for the purpose of comparison would be 
>> each individual value compared against each-other (ofc maybe comparing 
>> the 
>> length first as an optimization).
>> Same goes for an array.
>>
>> And again, you are missing the whole point. Both me and you are wrong 
>> in each-others points of view.
>> Just accept this.
>>
>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>>>
>>> What's the value of a slice?
>>>
>>> What's the value of an array?
>>>
>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:

 If the type is *[]T then comparing memory addresses make sense to 
 see if both terms point to the same memory address.
 If the type is []T then comparing memory addresses doesn't make 
 sense as I'd expect to compare values.
 Finally, if the type is []*T then I'd still expect to compare 
 values (even if this is inconsistent with the above two rules), mainly 
 because I'm usually interested in the values a slice holds.

 And that's exactly why Ian and others said this is complicated to 
 define as different users expect different outcomes.
 So rather than deal with this, in an auto-magic way, better let the 
 users deal with it as they see fit from case to case.

 On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>
> Which is why it should be formalized.
>
> Where is the inconsistency between slices and arrays?
> Why do people even think that a slice need to behave like an array 
> wrt equality, were it introduced?
>
> A slice is not an array!
>
>
>
>
> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com 
> wrote:
>>
>> Relaxing unformalized behavior makes little sense to me. 
>> Explaining why equality is inconsistent between slices and arrays is 
>> not 
>> something I want to do either.
>>
>>
>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>>>
>>> Rob and Robert actually wrote that this area of the spec needs 
>>> more work...
>>> Otherwise, the behaviour of maps, slices and funcs cannot be 
>>> fully explained.
>>>
>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com 
>>> wrote:

 Go does not

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

As you pointed out, Printf() should follow the ref spec but that doesn't 
happen because some humans don't perceive this accuracy as necessary or 
maybe because the way to resonate about slices / arrays is as containers 
for the actual values.
Thus we have Printf working as it does (and %p will indeed print the memory 
address of the slice type).

I would definitely want to be able to compare []int{1, 2, 3} with ([]int{1, 
2, 3, 4, 5})[:3] and result in equality (given here for example purposes 
but think of them as coming from different sources)
Apparently you don't, and that's fine.

That's exactly why the compiler only allows comparison with nil, to force 
the user to think about that should be compared, not do it by default and 
have potential hidden issues that might be uncovered too late in the 
process.

On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>
> In fact, that is somewhat my fault.
>
> I should ask:
>
> What is a slice?
> What is an array?
>
> Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
> (auto-dereferencing) which is the reason you observe such a result in the 
> playground.
>
> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>
>> No. You should not get it from here. You should get the answer from the 
>> spec. Let alone the fact that the implementation should ideally follow the 
>> spec and not the reverse.
>>
>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>>
>>> If I look at what %v means, print out the values of various types in Go, 
>>> according to https://golang.org/pkg/fmt/ then I believe that this holds 
>>> the answer: https://play.golang.org/p/GiLckoBDxa
>>>
>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:

 Not for comparison.

 I am just asking what is the value of a slice and what is the value of 
 an array.

 Remember that there is no slice comparison that has been spec'ed so far.

 On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>
> For []T the value of a slice for the purpose of comparison would be 
> each individual value compared against each-other (ofc maybe comparing 
> the 
> length first as an optimization).
> Same goes for an array.
>
> And again, you are missing the whole point. Both me and you are wrong 
> in each-others points of view.
> Just accept this.
>
> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>>
>> What's the value of a slice?
>>
>> What's the value of an array?
>>
>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>>>
>>> If the type is *[]T then comparing memory addresses make sense to 
>>> see if both terms point to the same memory address.
>>> If the type is []T then comparing memory addresses doesn't make 
>>> sense as I'd expect to compare values.
>>> Finally, if the type is []*T then I'd still expect to compare values 
>>> (even if this is inconsistent with the above two rules), mainly because 
>>> I'm 
>>> usually interested in the values a slice holds.
>>>
>>> And that's exactly why Ian and others said this is complicated to 
>>> define as different users expect different outcomes.
>>> So rather than deal with this, in an auto-magic way, better let the 
>>> users deal with it as they see fit from case to case.
>>>
>>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:

 Which is why it should be formalized.

 Where is the inconsistency between slices and arrays?
 Why do people even think that a slice need to behave like an array 
 wrt equality, were it introduced?

 A slice is not an array!




 On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com 
 wrote:
>
> Relaxing unformalized behavior makes little sense to me. 
> Explaining why equality is inconsistent between slices and arrays is 
> not 
> something I want to do either.
>
>
> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>>
>> Rob and Robert actually wrote that this area of the spec needs 
>> more work...
>> Otherwise, the behaviour of maps, slices and funcs cannot be 
>> fully explained.
>>
>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com 
>> wrote:
>>>
>>> Go does not have reference types. As far as I know, the word was 
>>> purposefully removed from the spec to remove the ambiguity 
>>> surrounding the 
>>> word. 
>>>
>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>>
>>
>>
>> @Martin
>>
>> As I've mentioned earlier, one ought to be careful about  false 
>> friends from other

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

In fact, that is somewhat my fault.

I should ask:

What is a slice?
What is an array?

Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
(auto-dereferencing) which is the reason you observe such a result in the 
playground.

On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>
> No. You should not get it from here. You should get the answer from the 
> spec. Let alone the fact that the implementation should ideally follow the 
> spec and not the reverse.
>
> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>
>> If I look at what %v means, print out the values of various types in Go, 
>> according to https://golang.org/pkg/fmt/ then I believe that this holds 
>> the answer: https://play.golang.org/p/GiLckoBDxa
>>
>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>>>
>>> Not for comparison.
>>>
>>> I am just asking what is the value of a slice and what is the value of 
>>> an array.
>>>
>>> Remember that there is no slice comparison that has been spec'ed so far.
>>>
>>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:

 For []T the value of a slice for the purpose of comparison would be 
 each individual value compared against each-other (ofc maybe comparing the 
 length first as an optimization).
 Same goes for an array.

 And again, you are missing the whole point. Both me and you are wrong 
 in each-others points of view.
 Just accept this.

 On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>
> What's the value of a slice?
>
> What's the value of an array?
>
> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>>
>> If the type is *[]T then comparing memory addresses make sense to see 
>> if both terms point to the same memory address.
>> If the type is []T then comparing memory addresses doesn't make sense 
>> as I'd expect to compare values.
>> Finally, if the type is []*T then I'd still expect to compare values 
>> (even if this is inconsistent with the above two rules), mainly because 
>> I'm 
>> usually interested in the values a slice holds.
>>
>> And that's exactly why Ian and others said this is complicated to 
>> define as different users expect different outcomes.
>> So rather than deal with this, in an auto-magic way, better let the 
>> users deal with it as they see fit from case to case.
>>
>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>>>
>>> Which is why it should be formalized.
>>>
>>> Where is the inconsistency between slices and arrays?
>>> Why do people even think that a slice need to behave like an array 
>>> wrt equality, were it introduced?
>>>
>>> A slice is not an array!
>>>
>>>
>>>
>>>
>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com 
>>> wrote:

 Relaxing unformalized behavior makes little sense to me. Explaining 
 why equality is inconsistent between slices and arrays is not 
 something I 
 want to do either.


 On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>
> Rob and Robert actually wrote that this area of the spec needs 
> more work...
> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
> explained.
>
> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com 
> wrote:
>>
>> Go does not have reference types. As far as I know, the word was 
>> purposefully removed from the spec to remove the ambiguity 
>> surrounding the 
>> word. 
>>
>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>
>
>
> @Martin
>
> As I've mentioned earlier, one ought to be careful about  false 
> friends from other languages. 
> I am not sure I understand what you mean by:
>
> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

No. You should not get it from here. You should get the answer from the 
spec. Let alone the fact that the implementation should ideally follow the 
spec and not the reverse.

On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>
> If I look at what %v means, print out the values of various types in Go, 
> according to https://golang.org/pkg/fmt/ then I believe that this holds 
> the answer: https://play.golang.org/p/GiLckoBDxa
>
> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>>
>> Not for comparison.
>>
>> I am just asking what is the value of a slice and what is the value of an 
>> array.
>>
>> Remember that there is no slice comparison that has been spec'ed so far.
>>
>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>>>
>>> For []T the value of a slice for the purpose of comparison would be each 
>>> individual value compared against each-other (ofc maybe comparing the 
>>> length first as an optimization).
>>> Same goes for an array.
>>>
>>> And again, you are missing the whole point. Both me and you are wrong in 
>>> each-others points of view.
>>> Just accept this.
>>>
>>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:

 What's the value of a slice?

 What's the value of an array?

 On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>
> If the type is *[]T then comparing memory addresses make sense to see 
> if both terms point to the same memory address.
> If the type is []T then comparing memory addresses doesn't make sense 
> as I'd expect to compare values.
> Finally, if the type is []*T then I'd still expect to compare values 
> (even if this is inconsistent with the above two rules), mainly because 
> I'm 
> usually interested in the values a slice holds.
>
> And that's exactly why Ian and others said this is complicated to 
> define as different users expect different outcomes.
> So rather than deal with this, in an auto-magic way, better let the 
> users deal with it as they see fit from case to case.
>
> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>>
>> Which is why it should be formalized.
>>
>> Where is the inconsistency between slices and arrays?
>> Why do people even think that a slice need to behave like an array 
>> wrt equality, were it introduced?
>>
>> A slice is not an array!
>>
>>
>>
>>
>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>>>
>>> Relaxing unformalized behavior makes little sense to me. Explaining 
>>> why equality is inconsistent between slices and arrays is not something 
>>> I 
>>> want to do either.
>>>
>>>
>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:

 Rob and Robert actually wrote that this area of the spec needs more 
 work...
 Otherwise, the behaviour of maps, slices and funcs cannot be fully 
 explained.

 On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com 
 wrote:
>
> Go does not have reference types. As far as I know, the word was 
> purposefully removed from the spec to remove the ambiguity 
> surrounding the 
> word. 
>
> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA



 @Martin

 As I've mentioned earlier, one ought to be careful about  false 
 friends from other languages. 
 I am not sure I understand what you mean by:

 if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

If I look at what %v means, print out the values of various types in Go, 
according to https://golang.org/pkg/fmt/ then I believe that this holds the 
answer: https://play.golang.org/p/GiLckoBDxa

On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:
>
> Not for comparison.
>
> I am just asking what is the value of a slice and what is the value of an 
> array.
>
> Remember that there is no slice comparison that has been spec'ed so far.
>
> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>>
>> For []T the value of a slice for the purpose of comparison would be each 
>> individual value compared against each-other (ofc maybe comparing the 
>> length first as an optimization).
>> Same goes for an array.
>>
>> And again, you are missing the whole point. Both me and you are wrong in 
>> each-others points of view.
>> Just accept this.
>>
>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>>>
>>> What's the value of a slice?
>>>
>>> What's the value of an array?
>>>
>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:

 If the type is *[]T then comparing memory addresses make sense to see 
 if both terms point to the same memory address.
 If the type is []T then comparing memory addresses doesn't make sense 
 as I'd expect to compare values.
 Finally, if the type is []*T then I'd still expect to compare values 
 (even if this is inconsistent with the above two rules), mainly because 
 I'm 
 usually interested in the values a slice holds.

 And that's exactly why Ian and others said this is complicated to 
 define as different users expect different outcomes.
 So rather than deal with this, in an auto-magic way, better let the 
 users deal with it as they see fit from case to case.

 On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>
> Which is why it should be formalized.
>
> Where is the inconsistency between slices and arrays?
> Why do people even think that a slice need to behave like an array wrt 
> equality, were it introduced?
>
> A slice is not an array!
>
>
>
>
> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>>
>> Relaxing unformalized behavior makes little sense to me. Explaining 
>> why equality is inconsistent between slices and arrays is not something 
>> I 
>> want to do either.
>>
>>
>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>>>
>>> Rob and Robert actually wrote that this area of the spec needs more 
>>> work...
>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
>>> explained.
>>>
>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:

 Go does not have reference types. As far as I know, the word was 
 purposefully removed from the spec to remove the ambiguity surrounding 
 the 
 word. 

 https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>>>
>>>
>>>
>>> @Martin
>>>
>>> As I've mentioned earlier, one ought to be careful about  false 
>>> friends from other languages. 
>>> I am not sure I understand what you mean by:
>>>
>>> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Not for comparison.

I am just asking what is the value of a slice and what is the value of an 
array.

Remember that there is no slice comparison that has been spec'ed so far.

On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>
> For []T the value of a slice for the purpose of comparison would be each 
> individual value compared against each-other (ofc maybe comparing the 
> length first as an optimization).
> Same goes for an array.
>
> And again, you are missing the whole point. Both me and you are wrong in 
> each-others points of view.
> Just accept this.
>
> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>>
>> What's the value of a slice?
>>
>> What's the value of an array?
>>
>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>>>
>>> If the type is *[]T then comparing memory addresses make sense to see if 
>>> both terms point to the same memory address.
>>> If the type is []T then comparing memory addresses doesn't make sense as 
>>> I'd expect to compare values.
>>> Finally, if the type is []*T then I'd still expect to compare values 
>>> (even if this is inconsistent with the above two rules), mainly because I'm 
>>> usually interested in the values a slice holds.
>>>
>>> And that's exactly why Ian and others said this is complicated to define 
>>> as different users expect different outcomes.
>>> So rather than deal with this, in an auto-magic way, better let the 
>>> users deal with it as they see fit from case to case.
>>>
>>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:

 Which is why it should be formalized.

 Where is the inconsistency between slices and arrays?
 Why do people even think that a slice need to behave like an array wrt 
 equality, were it introduced?

 A slice is not an array!




 On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>
> Relaxing unformalized behavior makes little sense to me. Explaining 
> why equality is inconsistent between slices and arrays is not something I 
> want to do either.
>
>
> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>>
>> Rob and Robert actually wrote that this area of the spec needs more 
>> work...
>> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
>> explained.
>>
>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>>>
>>> Go does not have reference types. As far as I know, the word was 
>>> purposefully removed from the spec to remove the ambiguity surrounding 
>>> the 
>>> word. 
>>>
>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>>
>>
>>
>> @Martin
>>
>> As I've mentioned earlier, one ought to be careful about  false 
>> friends from other languages. 
>> I am not sure I understand what you mean by:
>>
>> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

For []T the value of a slice for the purpose of comparison would be each 
individual value compared against each-other (ofc maybe comparing the 
length first as an optimization).
Same goes for an array.

And again, you are missing the whole point. Both me and you are wrong in 
each-others points of view.
Just accept this.

On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote:
>
> What's the value of a slice?
>
> What's the value of an array?
>
> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>>
>> If the type is *[]T then comparing memory addresses make sense to see if 
>> both terms point to the same memory address.
>> If the type is []T then comparing memory addresses doesn't make sense as 
>> I'd expect to compare values.
>> Finally, if the type is []*T then I'd still expect to compare values 
>> (even if this is inconsistent with the above two rules), mainly because I'm 
>> usually interested in the values a slice holds.
>>
>> And that's exactly why Ian and others said this is complicated to define 
>> as different users expect different outcomes.
>> So rather than deal with this, in an auto-magic way, better let the users 
>> deal with it as they see fit from case to case.
>>
>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>>>
>>> Which is why it should be formalized.
>>>
>>> Where is the inconsistency between slices and arrays?
>>> Why do people even think that a slice need to behave like an array wrt 
>>> equality, were it introduced?
>>>
>>> A slice is not an array!
>>>
>>>
>>>
>>>
>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:

 Relaxing unformalized behavior makes little sense to me. Explaining why 
 equality is inconsistent between slices and arrays is not something I want 
 to do either.


 On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>
> Rob and Robert actually wrote that this area of the spec needs more 
> work...
> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
> explained.
>
> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>>
>> Go does not have reference types. As far as I know, the word was 
>> purposefully removed from the spec to remove the ambiguity surrounding 
>> the 
>> word. 
>>
>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>
>
>
> @Martin
>
> As I've mentioned earlier, one ought to be careful about  false 
> friends from other languages. 
> I am not sure I understand what you mean by:
>
> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

What's the value of a slice?

What's the value of an array?

On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote:
>
> If the type is *[]T then comparing memory addresses make sense to see if 
> both terms point to the same memory address.
> If the type is []T then comparing memory addresses doesn't make sense as 
> I'd expect to compare values.
> Finally, if the type is []*T then I'd still expect to compare values (even 
> if this is inconsistent with the above two rules), mainly because I'm 
> usually interested in the values a slice holds.
>
> And that's exactly why Ian and others said this is complicated to define 
> as different users expect different outcomes.
> So rather than deal with this, in an auto-magic way, better let the users 
> deal with it as they see fit from case to case.
>
> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>>
>> Which is why it should be formalized.
>>
>> Where is the inconsistency between slices and arrays?
>> Why do people even think that a slice need to behave like an array wrt 
>> equality, were it introduced?
>>
>> A slice is not an array!
>>
>>
>>
>>
>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>>>
>>> Relaxing unformalized behavior makes little sense to me. Explaining why 
>>> equality is inconsistent between slices and arrays is not something I want 
>>> to do either.
>>>
>>>
>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:

 Rob and Robert actually wrote that this area of the spec needs more 
 work...
 Otherwise, the behaviour of maps, slices and funcs cannot be fully 
 explained.

 On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>
> Go does not have reference types. As far as I know, the word was 
> purposefully removed from the spec to remove the ambiguity surrounding 
> the 
> word. 
>
> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA



 @Martin

 As I've mentioned earlier, one ought to be careful about  false friends 
 from other languages. 
 I am not sure I understand what you mean by:

 if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

If the type is *[]T then comparing memory addresses make sense to see if 
both terms point to the same memory address.
If the type is []T then comparing memory addresses doesn't make sense as 
I'd expect to compare values.
Finally, if the type is []*T then I'd still expect to compare values (even 
if this is inconsistent with the above two rules), mainly because I'm 
usually interested in the values a slice holds.

And that's exactly why Ian and others said this is complicated to define as 
different users expect different outcomes.
So rather than deal with this, in an auto-magic way, better let the users 
deal with it as they see fit from case to case.

On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote:
>
> Which is why it should be formalized.
>
> Where is the inconsistency between slices and arrays?
> Why do people even think that a slice need to behave like an array wrt 
> equality, were it introduced?
>
> A slice is not an array!
>
>
>
>
> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>>
>> Relaxing unformalized behavior makes little sense to me. Explaining why 
>> equality is inconsistent between slices and arrays is not something I want 
>> to do either.
>>
>>
>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>>>
>>> Rob and Robert actually wrote that this area of the spec needs more 
>>> work...
>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
>>> explained.
>>>
>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:

 Go does not have reference types. As far as I know, the word was 
 purposefully removed from the spec to remove the ambiguity surrounding the 
 word. 

 https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>>>
>>>
>>>
>>> @Martin
>>>
>>> As I've mentioned earlier, one ought to be careful about  false friends 
>>> from other languages. 
>>> I am not sure I understand what you mean by:
>>>
>>> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

Which is why it should be formalized.

Where is the inconsistency between slices and arrays?
Why do people even think that a slice need to behave like an array wrt 
equality, were it introduced?

A slice is not an array!




On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as@gmail.com wrote:
>
> Relaxing unformalized behavior makes little sense to me. Explaining why 
> equality is inconsistent between slices and arrays is not something I want 
> to do either.
>
>
> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>>
>> Rob and Robert actually wrote that this area of the spec needs more 
>> work...
>> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
>> explained.
>>
>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>>>
>>> Go does not have reference types. As far as I know, the word was 
>>> purposefully removed from the spec to remove the ambiguity surrounding the 
>>> word. 
>>>
>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>>
>>
>>
>> @Martin
>>
>> As I've mentioned earlier, one ought to be careful about  false friends 
>> from other languages. 
>> I am not sure I understand what you mean by:
>>
>> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

2016-07-03 Thread as . utf8

Relaxing unformalized behavior makes little sense to me. Explaining why 
equality is inconsistent between slices and arrays is not something I want 
to do either.


On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>
> Rob and Robert actually wrote that this area of the spec needs more work...
> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
> explained.
>
> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>>
>> Go does not have reference types. As far as I know, the word was 
>> purposefully removed from the spec to remove the ambiguity surrounding the 
>> word. 
>>
>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>
>
>
> @Martin
>
> As I've mentioned earlier, one ought to be careful about  false friends 
> from other languages. 
> I am not sure I understand what you mean by:
>
> if the name field is changed after the 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.

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?