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

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

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

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

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

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

[go-nuts] Meet runtime.typedslicecopy: nosplit stack overflow error when cross platform compiling.

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

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 >

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

Re: [go-nuts] How does iota affect the types of the subsequent constants in a constant declaration?

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

[go-nuts] Re: http/2 with go version 1.6.2 not working under iOS 9 mobile Safari

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

[go-nuts] Unsure when two interfaces are considered identical

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

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

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"

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

[go-nuts] How does iota affect the types of the subsequent constants in a constant declaration?

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

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

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

[go-nuts] liteide x30 released

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 :

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

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

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

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 <

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

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

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

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

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

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

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

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

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

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

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

Re: [go-nuts] Re: os.exec.Command and non-nil return status

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

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

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

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

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

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,

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

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

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

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 >

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

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

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

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

[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

[go-nuts] Re: How to build gomobile from source

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

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"

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

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

[go-nuts] How to build gomobile from source

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

Hi Chad, On Sat, Jul 2, 2016 at 10:43 AM, Chad wrote: > > On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote: >> >> On Fri, Jul 1, 2016 at 4:01 PM, Chad wrote: >>> >>> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote: