[go-nuts] Re: Go 1.10 is released

[Dmitriy Cherchenko]

I like how the Go team isn't trying to support very old operating systems. 
We should focus on modern systems and expect people to try to stay up to 
date. Thank you!


On Friday, February 16, 2018 at 11:36:22 AM UTC-8, Andrew Bonventre wrote:
>
> Hello gophers,
>
> We just released Go 1.10.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.10
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.10" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.10
>
> Thanks to everyone who contributed to the release.
>
> Andy on behalf of the Go Team
>

-- 
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] Guarantees about evaluation order but not slice indexing

[Dmitriy Cherchenko]

The second possibility you described is exactly what I’m worried about. But I 
have several places where I’m doing something like b.data[b.grow()] = bt and 
wouldn’t want to break that up into two lines everywhere. I was wondering if 
you could find anything else in the spec to guarantee that the index (b.grow()) 
is evaluated first, before the slice is identified.

-- 
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] Guarantees about evaluation order but not slice indexing

[Dmitriy Cherchenko]

It looks like the language spec is a little imprecise in the Order of 
evaluation  section about 
if any function evaluating an index of a slice will always be invoked 
before anything is done to the slice at that index. That is, if you have 
something like:
mySlice[someFunc()] = 45
is someFunc() guaranteed to be called before the value at the int it 
returns is set to 45?

I created a sample test and ran it on 32 different kinds of machines (using 
Travis CI), including 8 different versions of Go, two different 
architectures, and two operating systems.

Here is the code: https://github.com/dchenk/go-eval-order

And here are the test results: 
https://travis-ci.org/dchenk/go-eval-order/builds/335042572

So what are the guarantees, if there are any, about the evaluation order of 
the inner function verses the slice indexing operation? I want to make sure 
invalid indexing isn't possible in the kind of code on line 10 in the 
main.go file in the repo linked to above.

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] Returning a JSON object saved as a string in a database

[Dmitriy Cherchenko]

Wow that appears to be exactly the answer I'm looking for! Thank you.

Just to make sure: When marshalling a struct, will fields of 
type json.RawMessage be ignored (simply inserted into the JSON object 
without further processing)?


On Thursday, August 10, 2017 at 7:27:17 PM UTC-7, Jakob Borg wrote:
>
> On 10 Aug 2017, at 22:11, Dmitriy Cherchenko <dcher...@gmail.com 
> > wrote:
>
> What is the best way to send the stringified JSON object from the database 
> as JSON and not as a string-type value of a property in the bigger JSON 
> object the server is responding with?
>
>
> Do you mean like this?
>
> https://play.golang.org/p/wUFYoKvDRm
>
> //jb
>

-- 
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] Returning a JSON object saved as a string in a database

[Dmitriy Cherchenko]

But then if the JSON is sent as a string property of a bigger object, it'll 
have to be parsed by JavaScript on the browser side. That is undesirable.

On Thursday, August 10, 2017 at 1:21:54 PM UTC-7, Shawn Milochik wrote:
>
> On Thu, Aug 10, 2017 at 4:20 PM, Dmitriy Cherchenko <dcher...@gmail.com 
> > wrote:
>
>> Hi Shawn,
>>
>> Thank you for your quick reply!
>>
>> I’m not having any issues retrieving data from the database. I’m only 
>> concerned that the unmarshalling and marshalling processes seem needless 
>> and a little risky especially on big JSON objects.
>>
>
> Sure. If you just want to pull it out of the DB and return it as a string, 
> there's no reason to use the encoding/json package.
>

-- 
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] Returning a JSON object saved as a string in a database

[Dmitriy Cherchenko]

Hi Shawn,

Thank you for your quick reply!

I’m not having any issues retrieving data from the database. I’m only 
concerned that the unmarshalling and marshalling processes seem needless 
and a little risky especially on big JSON objects.


On Thursday, August 10, 2017 at 1:17:02 PM UTC-7, Shawn Milochik wrote:
>
> Seems like something that should "just work." Are you having a problem 
> with this? If so, please show some code.
>
> A string is a string -- if you insert a base64-encoded value (or JSON, or 
> YAML) into a database varchar or text field, you should get the identical 
> string back out, character for character. The fact that it happens to be 
> base64 (or JSON, or YAML), shouldn't matter.
>
> If it comes out as invalid JSON, I'd bet it's being modified by your code 
> before insertion or after retrieval. Either way, show some code and I'll be 
> happy to look at it.
>
>
>

-- 
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: Named or unnamed struct initialisation? What is best practice?

[Dmitriy Cherchenko]

Can you do a test to see if there's a performance difference?

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