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

[as . utf8]

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

-- 
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: Help with the the Get url: EOF error (http client)

[Constantin Konstantinidis]

I would suggest to first upgrade to 1.6.2 as investigating and support will 
be complicated by all the changes which occured since then.

On Saturday, July 2, 2016 at 11:07:22 AM UTC+2, Pontus Lundin wrote:
>
> Hi,
>
> So i have a client running for months doing re-occuring work against a 
> SOAP web service, suddenly i got the 
> Get url: EOF error and now i am unable to get anything useful back from 
> the server (headers) other than the :EOF
>
> There are various threads on this topic
>
> http://stackoverflow.com/questions/17714494/golang-http-request-results-in-eof-errors-when-making-multiple-requests-successi
>
> That points to if using older Go version (mine being 1.3.3) add
> req.Close = true 
> I can amend this to my application code (or upgrade to a newer Go version) 
> but what can i do to release the TCP connection that seems to halt me from 
> doing more requests? Is there anything i can do client side or do i need to 
> talk to the server-side people to kill (hanged) open connections?
>
> If i try another endpoint (not the SOAP web service) it works (i get the 
> headers response back) so it seems that the server rejects more connection 
> from my client ? Is that right ?
>
> Thanks!
>
>

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

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

[Chad]

You can do that, but for correctness, I am arguing that it's not what you 
should expect for slices by default.

On Sunday, July 3, 2016 at 3:37:15 AM UTC+2, Florin Pățan wrote:
>
> I would also expect to compare values not memory locations, generally 
> that's what I'm interested in comparing.
>
> I never had the need to compare equality for memory locations of anything 
> in Go (especially not for slices / maps oe their elements).
>

-- 
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: files, readers, byte arrays (slices?), byte buffers and http.requests

[Dave Cheney]

The hash is always the same because you ask for the hash value before writing 
any data through it with io.Copy. 

-- 
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: files, readers, byte arrays (slices?), byte buffers and http.requests

[Sri G]

Update:

Adding file.Seek(0,0) does fix the issue in Version 2. The uploaded file is 
the correct size on disk with the correct md5. Without it, the uploaded 
file which is saved is missing the first 1024 bytes. This makes sense.

There is something wrong with the way the md5 is calculated, it keeps 
giving the same hash. Any ideas?

This version, while most likely not idiomatic, works:

mimebuf := make([]byte, 1024)
 _, err = file.Read(mimebuf)


mime := mimemagic.Match("", mimebuf)

file.Seek(0, 0)

checksum := md5.New()

io.Copy(checksum, file)

md5hex := hex.EncodeToString(checksum.Sum(nil))
fmt.Println("md5=", md5hex)

file.Seek(0, 0)
io.Copy(f, file)

It would be much appreciated if someone understands the idiomatic way to do 
this with and can explain it.

On Saturday, July 2, 2016 at 5:48:45 PM UTC-4, Sri G wrote:
>
> Thanks for the pointer. I also found this helpful Asynchronously Split an 
> io.Reader in Go (golang) « Rodaine 
>  but I'm 
> still missing something.
>
> Version 1: the uploaded file is 1024 bytes extra at the end (too big):
>
> mimebuf := make([]byte, 1024)
> _, err = file.Read(mimebuf)
>
> mime := mimemagic.Match("", mimebuf)
>
> fileReader := io.MultiReader(bytes.NewReader(mimebuf), file)
>
> checksum := md5.New()
>
> b := io.TeeReader(fileReader, checksum)
>
> md5hex := hex.EncodeToString(checksum.Sum(nil))
>
> // Save file
> io.Copy(f, b)
>
> Version 2: the uploaded file is truncated by 1024 byte (too small): (this 
> makes sense since the first 1024 bytes of file was consumed)
>
> mimebuf := make([]byte, 1024)
> _, err = file.Read(mimebuf)
>
> mime := mimemagic.Match("", mimebuf)
>
> checksum := md5.New()
>
> // Adding file.Seek(0,0) here does not fix this issue
>
> b := io.TeeReader(file, checksum)
>
> md5hex := hex.EncodeToString(checksum.Sum(nil))
>
> // Save file
> io.Copy(f, b)
>
>
> What is incorrect which is causing this? How do I get the goldilocks 
> version that's just right?
>
> On Saturday, July 2, 2016 at 3:18:51 AM UTC-4, Tamás Gulácsi wrote:
>>
>>
>> 2016. július 2., szombat 8:15:19 UTC+2 időpontban Sri G a következőt írta:
>>>
>>> I'm working on receiving uploads through a form.
>>>
>>> The tricky part is validation.
>>>
>>> I attempt to read the first 1024 bytes to check the mime of the file and 
>>> then if valid read the rest and hash it and also save it to disk. Reading 
>>> the mime type is successful and I've gotten it to work by chaining 
>>> TeeReader but it seems very hackish. Whats the idiomatic way to do this?
>>>
>>> I'm trying something like this: 
>>>
>>>
>>> // Parse my multi part form 
>>> ...
>>> // Get file handle
>>> file, err := fh.Open()
>>>
>>> var a bytes.Buffer
>>>
>>> io.CopyN(, file, 1024)
>>>
>>> mime := mimemagic.Match("", a.Bytes())
>>> // Check mime type (this works fine)
>>>
>>> I'm trying to seek a stream so this should be no-op
>>> file.Seek(0, 0)
>>>
>>> The file stored on disk is 1KB larger than the original so it appears to 
>>> be re-copying the entire file and appending it to bytes.Buffer
>>> io.Copy(, file)
>>>
>>> checksum := md5.New()
>>> b := io.TeeReader(, checksum)
>>>
>>> md5hex := hex.EncodeToString(checksum.Sum(nil))
>>> fmt.Println("md5=", md5hex)
>>>
>>> //Open file f for writing to disk
>>> ...
>>> //Save file
>>> io.Copy(f, b)
>>>
>>>
>>> Checked the md5 of (1KB of orig + orig), and (orginal - first 1 KB), 
>>> neither match the md5 of the file being hashed.
>>>
>>> Why can't I append the rest of the stream to the byte buffer to get the 
>>> complete file in memory and why is the byte buffer being "consumed"? 
>>>
>>> I simply need to read the same array of byte multiple times, I don't 
>>> need to "copy" them. I'm coming from a C background so I'm wondering what 
>>> is going on behind the scenes as well.
>>>
>>
>> If you know you'll have to read the whole file into memory, then do that, 
>> and use bytes.NewReader to create  a reader for that byte slice.
>>
>> If you read partly, to decide whether to go on, then use fh.Read or 
>> io.ReadAtLeast with a byte slice.
>>
>> If you read sth, then want to read the whole from the beginning, 
>> construct a Reader with io.MultiReader(bytes.NewReader(b), fh).
>>
>> You can combine these approaches, but if the while file size is less than 
>> a few KiB, I think it is easier, simpler and more performant (!) to read 
>> the whole file up into memory,
>> into a bytes.Buffer, and construct the needed readers with 
>> bytes.NewReader(buf.Bytes()). 
>>
>

-- 
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: files, readers, byte arrays (slices?), byte buffers and http.requests

[Sri G]

Thanks for the pointer. I also found this helpful Asynchronously Split an 
io.Reader in Go (golang) « Rodaine 
 but I'm still 
missing something.

Version 1: the uploaded file is 1024 bytes extra at the end (too big):

mimebuf := make([]byte, 1024)
_, err = file.Read(mimebuf)

mime := mimemagic.Match("", mimebuf)

fileReader := io.MultiReader(bytes.NewReader(mimebuf), file)

checksum := md5.New()

b := io.TeeReader(fileReader, checksum)

md5hex := hex.EncodeToString(checksum.Sum(nil))

// Save file
io.Copy(f, b)

Version 2: the uploaded file is truncated by 1024 byte (too small): (this 
makes sense since the first 1024 bytes of file was consumed)

mimebuf := make([]byte, 1024)
_, err = file.Read(mimebuf)

mime := mimemagic.Match("", mimebuf)

checksum := md5.New()

// Adding file.Seek(0,0) here does not fix this issue

b := io.TeeReader(file, checksum)

md5hex := hex.EncodeToString(checksum.Sum(nil))

// Save file
io.Copy(f, b)


What is incorrect which is causing this? How do I get the goldilocks 
version that's just right?

On Saturday, July 2, 2016 at 3:18:51 AM UTC-4, Tamás Gulácsi wrote:
>
>
> 2016. július 2., szombat 8:15:19 UTC+2 időpontban Sri G a következőt írta:
>>
>> I'm working on receiving uploads through a form.
>>
>> The tricky part is validation.
>>
>> I attempt to read the first 1024 bytes to check the mime of the file and 
>> then if valid read the rest and hash it and also save it to disk. Reading 
>> the mime type is successful and I've gotten it to work by chaining 
>> TeeReader but it seems very hackish. Whats the idiomatic way to do this?
>>
>> I'm trying something like this: 
>>
>>
>> // Parse my multi part form 
>> ...
>> // Get file handle
>> file, err := fh.Open()
>>
>> var a bytes.Buffer
>>
>> io.CopyN(, file, 1024)
>>
>> mime := mimemagic.Match("", a.Bytes())
>> // Check mime type (this works fine)
>>
>> I'm trying to seek a stream so this should be no-op
>> file.Seek(0, 0)
>>
>> The file stored on disk is 1KB larger than the original so it appears to 
>> be re-copying the entire file and appending it to bytes.Buffer
>> io.Copy(, file)
>>
>> checksum := md5.New()
>> b := io.TeeReader(, checksum)
>>
>> md5hex := hex.EncodeToString(checksum.Sum(nil))
>> fmt.Println("md5=", md5hex)
>>
>> //Open file f for writing to disk
>> ...
>> //Save file
>> io.Copy(f, b)
>>
>>
>> Checked the md5 of (1KB of orig + orig), and (orginal - first 1 KB), 
>> neither match the md5 of the file being hashed.
>>
>> Why can't I append the rest of the stream to the byte buffer to get the 
>> complete file in memory and why is the byte buffer being "consumed"? 
>>
>> I simply need to read the same array of byte multiple times, I don't need 
>> to "copy" them. I'm coming from a C background so I'm wondering what is 
>> going on behind the scenes as well.
>>
>
> If you know you'll have to read the whole file into memory, then do that, 
> and use bytes.NewReader to create  a reader for that byte slice.
>
> If you read partly, to decide whether to go on, then use fh.Read or 
> io.ReadAtLeast with a byte slice.
>
> If you read sth, then want to read the whole from the beginning, construct 
> a Reader with io.MultiReader(bytes.NewReader(b), fh).
>
> You can combine these approaches, but if the while file size is less than 
> a few KiB, I think it is easier, simpler and more performant (!) to read 
> the whole file up into memory,
> into a bytes.Buffer, and construct the needed readers with 
> bytes.NewReader(buf.Bytes()). 
>

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

[go-nuts] Re: Go-worker or goworker?

[pjmuller]

Hi Charl,

I need to make the same decision now. What path did you take?

On Wednesday, October 30, 2013 at 10:02:28 AM UTC+1, Charl Matthee wrote:
>
> Hi,
>
> I am in the process of selecting a resque/sidekiq replacement for a 
> project and go-workers  and 
> goworker  seem to be the contenders.
>
> Do any of you have any recommendations having worked with either/both?
>
> Is there some other project I should be looking at?
>
>
> Ciao
>
> Charl
>

-- 
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: A proposal for generic in go

[Chad]

What's generic programming?

 An implementation of overloading for datastructures and function/methods.
The compiler is left in charge of going through the code and specifying 
which types should actually be used.

Go restricts the overloading of function/methods.
So we are left with the specification of new datastructures.

To be fair, unless in very specific cases, datastructures specifically 
created to be safe for concurrent use are not too useful.
The reason being that their content is not deterministic. It is tied to the 
scheduler.
Write-only datastructures are probably the only interesting case that is 
interesting.
I mean, for instance, concurrent writes to a map while no reads occurs.
The only interesting case otherwise would be the concurrent reading/writing 
of an append only datastructure, but that would probably be a very specific 
tuning for speed.

So the only very interesting datastructures that would be remaining are 
datastructures that are fast to read from concurrently (maps are quite fast 
in Go)
Or fast to write to concurrently.

I wonder which kind of datastructures people may want to write.
But I have the impression that what people truly want is being able to 
overload functions. That's complicated. Multiple dispatch may be slow, 
perhaps unresolvable.. there are issues on that side. Besides introducing 
unwarranted implicitness.

The appeal of generics is probably a false appeal.

On Wednesday, June 15, 2016 at 3:04:05 AM UTC+2, xingtao zhao wrote:
>
> Here is my proposal for generic in go: 
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>
> Many parts has not been finished, and just initial thoughts. In the 
> proposal, I want to keep back compatibility. And I try to add the 
> orthogonal feature only and keep the language still simple enough. 
>
> Please add your comments on it. Hope it is useful and could inspire some 
> new features in go 2.0
>
> Thanks!
>

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

[go-nuts] Re: can't install gomobile

[Elias Naur]

This is my fault, sorry. Please try

https://go-review.googlesource.com/#/c/24720/

then reinstall the gomobile tool and see if that fixes the problem.

 - elias

On Saturday, July 2, 2016 at 4:56:58 AM UTC+2, JM wrote:
>
> windows pro on 64x.  Anyone know what's going on here? Im using the 
> following reference. https://github.com/golang/go/wiki/Mobile
>
> C:\WINDOWS\system32>go get golang.org/x/mobile/cmd/gomobile
>
> C:\WINDOWS\system32>gomobile init
> gomobile: rename 
> C:\GoPath\pkg\gomobile\work-399306583\android-ndk-r12\toolchains\llvm\prebuilt\windows-x86_64\bin\clang
>  
> C:\GoPath\pkg\gomobile\android-ndk-r12\llvm\bin\clang: The system cannot 
> find the file specified.
>
> C:\WINDOWS\system32>
>

-- 
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] Prevent RTS from creating an OS thread

[Alex Bligh]

On 2 Jul 2016, at 05:23, Matt Harden  wrote:

> Forking is not safe in Go either.

Why? Let's assume one knows what one is doing and doesn't try to use channels 
etc.

-- 
Alex Bligh




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

[gordon . klaus]

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
}

?


On Sunday, June 26, 2016 at 9:55:13 PM UTC+2, Ian Lance Taylor wrote:
>
> On Sat, Jun 25, 2016 at 12:34 PM, Val  
> wrote: 
> > Hello 
> > It seems that this code doesn't compile : 
> > 
> > func main() { 
> > var err error 
> > err = f() 
> > } 
> > 
> > prog.go:8: err declared and not used 
> > 
> > 
> > but this one does : 
> > 
> > func main() { 
> > var err error 
> > g := func() { 
> > err = f() 
> > } 
> > g() 
> > } 
> > 
> > Is the function binding regarded as a "use"?  Or does escape analysis 
> decide 
> > to not check too deep about never-read variables? 
> > 
> > Whether expected or not, I supposed this compiler behavior won't change, 
> > because of the Go1 compatibility promise. 
>
> While the rest of this thread gives something of an explanation, I 
> think this is a bug, and I think it could be fixed in a future 
> release.  This is https://golang.org/issue/3059. 
>
> The gccgo compiler does give an error for this code. 
>
> 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: can't install gomobile

[Constantin Konstantinidis]

It seems tha the Android SDK cannot be found. If installed, it should be in 
your PATH variable.




On Saturday, July 2, 2016 at 4:56:58 AM UTC+2, JM wrote:
>
> windows pro on 64x.  Anyone know what's going on here? Im using the 
> following reference. https://github.com/golang/go/wiki/Mobile
>
> C:\WINDOWS\system32>go get golang.org/x/mobile/cmd/gomobile
>
> C:\WINDOWS\system32>gomobile init
> gomobile: rename 
> C:\GoPath\pkg\gomobile\work-399306583\android-ndk-r12\toolchains\llvm\prebuilt\windows-x86_64\bin\clang
>  
> C:\GoPath\pkg\gomobile\android-ndk-r12\llvm\bin\clang: The system cannot 
> find the file specified.
>
> C:\WINDOWS\system32>
>

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

[go-nuts] Help with the the Get url: EOF error (http client)

[Pontus Lundin]

Hi,

So i have a client running for months doing re-occuring work against a SOAP 
web service, suddenly i got the 
Get url: EOF error and now i am unable to get anything useful back from the 
server (headers) other than the :EOF

There are various threads on this topic
http://stackoverflow.com/questions/17714494/golang-http-request-results-in-eof-errors-when-making-multiple-requests-successi

That points to if using older Go version (mine being 1.3.3) add
req.Close = true 
I can amend this to my application code (or upgrade to a newer Go version) 
but what can i do to release the TCP connection that seems to halt me from 
doing more requests? Is there anything i can do client side or do i need to 
talk to the server-side people to kill (hanged) open connections?

If i try another endpoint (not the SOAP web service) it works (i get the 
headers response back) so it seems that the server rejects more connection 
from my client ? Is that right ?

Thanks!

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

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

[Chad]

On Saturday, July 2, 2016 at 6:19:56 AM UTC+2, Matt Harden wrote:
>
> Conceptually, the value of a string is the sequence of bytes it contains, 
> just like an array of bytes. It doesn't matter that the implementation of 
> strings looks more like a slice internally. On the other hand the value of 
> a slice is a reference to (part of) an underlying array, together with a 
> length. In all cases == should compare values. 
>

It does(*). But for a slice, it "also" compares the location of those 
values. That's the difference between a slice and an array. 

(*) : well, or rather, it probably should .
 

> I agree that it would be confusing to make == work for slices, because 
> many people, myself included would intuitively want that to compare the 
> contents of the slice (values from the underlying array) rather than the 
> value of the slice itself which is essentially 3 pointers.
>
> That's just a matter of realizing what a slice really is. I think It's 
more of a documentation issue to clear up the misconception. That should 
not impede the language from being improved.
 

> One nice feature of the current gc compiler AIUI is that it will avoid a 
> copy in some circumstances when you convert a byte slice to a string and 
> immediately use it as a map key. This helps with using []byte values to 
> index into maps, but doesn't help when the []byte is part of a larger 
> structure you want to use as a key. 
>

> On Fri, Jul 1, 2016 at 7:05 AM Chad  
> wrote:
>
>>
>>
>> On Friday, July 1, 2016 at 4:01:54 PM UTC+2, Chad wrote:
>>
>>>
>>>
>>> On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote:

 On Fri, Jul 1, 2016 at 12:52 PM, Chad  wrote: 
 > However, that it's a valid point you raise (re strings) 
 > But that's exactly the reason for which, someone would probably ask 
 whether 
 > a string is a reference type or a value type. 
 > 
 > This could probably made clearer in the documentation. 

 I keep seeing references (hah!) to this concept of a "reference type" 
 :-) However, I just tried searching the language spec and Effective Go 
 and there doesn't seem to be such a concept defined in those 
 documents. 
>>>
>>>
>>> I think it should. It is mentioned here however 
>>> https://blog.golang.org/go-maps-in-action
>>>
>>> Without that, one of the first instinct of beginning programmers is 
>>> often to create pointers to slices ** *or maps ***
>>>
>>  
>> (And I should know, I did 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...@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?

[Chad]

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: 
> >> 
> >> On Fri, Jul 1, 2016 at 12:52 PM, Chad  wrote: 
> >> > However, that it's a valid point you raise (re strings) 
> >> > But that's exactly the reason for which, someone would probably ask 
> >> > whether 
> >> > a string is a reference type or a value type. 
> >> > 
> >> > This could probably made clearer in the documentation. 
> >> 
> >> I keep seeing references (hah!) to this concept of a "reference type" 
> >> :-) However, I just tried searching the language spec and Effective Go 
> >> and there doesn't seem to be such a concept defined in those 
> >> documents. 
> > 
> > 
> > I think it should. It is mentioned here however 
> > https://blog.golang.org/go-maps-in-action 
>
> You're right, that article calls maps, slices and pointers "reference 
> types". 
>
> I feel that is a little unfortunate since it muddles the picture and 
> makes the implementation more obscure. I would have been happy to have 
> been told right from the start that a slice is a small struct, small 
> enough that you can pass it by value instead of with a pointer. That 
> allows me to build a mental model in terms of other Go constructs. 
>

A struct is considered a reference type if at least one of the field 
*points* to another object. (i.e. holds a reference to another object).
https://en.wikipedia.org/wiki/Reference_type

It's clearer. "small struct" would not be explicit enough nor true.
I think that slices require typically more documentation effort to clarify 
what they are. Then, the issue of comparability will be obvious.

There are user-defined reference types too.

type Foo struct{
   name string
   data *[192]byte
}

That would be a reference type. This one is comparable.

 

>
> It might very well be that a slice isn't implemented *exactly* like a 
> struct, but if the mental picture of a struct explains the behavior 
> and performance characteristics, then it doesn't matter if the 
> compiler somehow cheats here and there when implementing the type. 
>
> > Without that, one of the first instinct of beginning programmers is 
> often to 
> > create pointers to slices. 
> > I feel that, more clarifications about this area of the language would 
> help 
> > a lot instead. 
> > 
> > This is also a terminology of PLT that exists in other languages but as 
> > usual, one has to be careful about the implementation false friends. 
>
> I agree, "reference type" is a widely used term. I think I prefer to 
> use it only for pointer types such as *int, *byte and so on. 
> Everything else would be value types, including string, map[int]int, 
> []float and other special builtin types. 
>
> When talking about equality, the language defines some of these types 
> as comparable, with per-type rules for how == is implemented. Relaxing 
> the rules to allow comparing slices (by pair-wise comparison of the 
> values in the slices) seems like a natural thing to do for me. It 
> would make slice comparison work like string comparison works 
> currently. So the rule for comparison would not even be new or strange 
> -- just a natural extension of what is already there. 
>
> You could probably also make slices (and arrays) ordered, provides the 
> elements themselves are ordered. That would work the same way strings 
> work today: lexicographic ordering based on the elements. 
>
> -- 
> Martin Geisler 
>

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

[Martin Geisler]

On Sat, Jul 2, 2016 at 6:19 AM, Matt Harden  wrote:
> Conceptually, the value of a string is the sequence of bytes it contains,
> just like an array of bytes. It doesn't matter that the implementation of
> strings looks more like a slice internally. On the other hand the value of a
> slice is a reference to (part of) an underlying array, together with a
> length. In all cases == should compare values. I agree that it would be
> confusing to make == work for slices, because many people, myself included
> would intuitively want that to compare the contents of the slice (values
> from the underlying array) rather than the value of the slice itself which
> is essentially 3 pointers.

But what if you define slice comparison to be by value of the underlying array?

That would make []int{1} == []int{1} be true, despite the slices
pointing to different arrays.

It would probably also mean that

  a := make([]int, 0, 5)
  b := make([]int, 0, 7)

are equal since the two slices have equal elements, despite having
different capacities.

Defining slice comparison to be comparison on the values would mean
that you cannot tell if the slices refer to different underlying
arrays. Maybe you can use the reflect package to get hold of it
somehow and compare the pointers yourself.

Speaking of reflect, I just realized that what I'm proposing is to
define == as reflect.DeepEqual for slices. It seems to do everything
I'm talking about: slices from different arrays can compare equal, it
short-circuits in clever ways by looking at the length and noticing
when the slices refer to the same point in the same array.

> One nice feature of the current gc compiler AIUI is that it will avoid a
> copy in some circumstances when you convert a byte slice to a string and
> immediately use it as a map key. This helps with using []byte values to
> index into maps, but doesn't help when the []byte is part of a larger
> structure you want to use as a key.

Yes, I read about this optimization. In my opinion that is a great
optimization -- and the kind of optimization the compiler can do when
it knows the implementation of map and string. However, it shouldn't
be part of the language specification.

-- 
Martin Geisler

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

[Martin Geisler]

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:
>>
>> On Fri, Jul 1, 2016 at 12:52 PM, Chad  wrote:
>> > However, that it's a valid point you raise (re strings)
>> > But that's exactly the reason for which, someone would probably ask
>> > whether
>> > a string is a reference type or a value type.
>> >
>> > This could probably made clearer in the documentation.
>>
>> I keep seeing references (hah!) to this concept of a "reference type"
>> :-) However, I just tried searching the language spec and Effective Go
>> and there doesn't seem to be such a concept defined in those
>> documents.
>
>
> I think it should. It is mentioned here however
> https://blog.golang.org/go-maps-in-action

You're right, that article calls maps, slices and pointers "reference types".

I feel that is a little unfortunate since it muddles the picture and
makes the implementation more obscure. I would have been happy to have
been told right from the start that a slice is a small struct, small
enough that you can pass it by value instead of with a pointer. That
allows me to build a mental model in terms of other Go constructs.

It might very well be that a slice isn't implemented *exactly* like a
struct, but if the mental picture of a struct explains the behavior
and performance characteristics, then it doesn't matter if the
compiler somehow cheats here and there when implementing the type.

> Without that, one of the first instinct of beginning programmers is often to
> create pointers to slices.
> I feel that, more clarifications about this area of the language would help
> a lot instead.
>
> This is also a terminology of PLT that exists in other languages but as
> usual, one has to be careful about the implementation false friends.

I agree, "reference type" is a widely used term. I think I prefer to
use it only for pointer types such as *int, *byte and so on.
Everything else would be value types, including string, map[int]int,
[]float and other special builtin types.

When talking about equality, the language defines some of these types
as comparable, with per-type rules for how == is implemented. Relaxing
the rules to allow comparing slices (by pair-wise comparison of the
values in the slices) seems like a natural thing to do for me. It
would make slice comparison work like string comparison works
currently. So the rule for comparison would not even be new or strange
-- just a natural extension of what is already there.

You could probably also make slices (and arrays) ordered, provides the
elements themselves are ordered. That would work the same way strings
work today: lexicographic ordering based on the elements.

-- 
Martin Geisler

-- 
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: files, readers, byte arrays (slices?), byte buffers and http.requests

[Tamás Gulácsi]

2016. július 2., szombat 8:15:19 UTC+2 időpontban Sri G a következőt írta:
>
> I'm working on receiving uploads through a form.
>
> The tricky part is validation.
>
> I attempt to read the first 1024 bytes to check the mime of the file and 
> then if valid read the rest and hash it and also save it to disk. Reading 
> the mime type is successful and I've gotten it to work by chaining 
> TeeReader but it seems very hackish. Whats the idiomatic way to do this?
>
> I'm trying something like this: 
>
>
> // Parse my multi part form 
> ...
> // Get file handle
> file, err := fh.Open()
>
> var a bytes.Buffer
>
> io.CopyN(, file, 1024)
>
> mime := mimemagic.Match("", a.Bytes())
> // Check mime type (this works fine)
>
> I'm trying to seek a stream so this should be no-op
> file.Seek(0, 0)
>
> The file stored on disk is 1KB larger than the original so it appears to 
> be re-copying the entire file and appending it to bytes.Buffer
> io.Copy(, file)
>
> checksum := md5.New()
> b := io.TeeReader(, checksum)
>
> md5hex := hex.EncodeToString(checksum.Sum(nil))
> fmt.Println("md5=", md5hex)
>
> //Open file f for writing to disk
> ...
> //Save file
> io.Copy(f, b)
>
>
> Checked the md5 of (1KB of orig + orig), and (orginal - first 1 KB), 
> neither match the md5 of the file being hashed.
>
> Why can't I append the rest of the stream to the byte buffer to get the 
> complete file in memory and why is the byte buffer being "consumed"? 
>
> I simply need to read the same array of byte multiple times, I don't need 
> to "copy" them. I'm coming from a C background so I'm wondering what is 
> going on behind the scenes as well.
>

If you know you'll have to read the whole file into memory, then do that, 
and use bytes.NewReader to create  a reader for that byte slice.

If you read partly, to decide whether to go on, then use fh.Read or 
io.ReadAtLeast with a byte slice.

If you read sth, then want to read the whole from the beginning, construct 
a Reader with io.MultiReader(bytes.NewReader(b), fh).

You can combine these approaches, but if the while file size is less than a 
few KiB, I think it is easier, simpler and more performant (!) to read the 
whole file up into memory,
into a bytes.Buffer, and construct the needed readers with 
bytes.NewReader(buf.Bytes()). 

-- 
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] Prevent RTS from creating an OS thread

[Tamás Gulácsi]

What about os/exec with a C shim to setup what needs to be done and start the 
Go program, passing on given FDs for IPC?

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