Re: [go-nuts] Re: What happens when appending to a slice exceeds the backing capacity?

[Jan Mercl]

What is a reference to the array? To access the array use the slice itself
as usual, no reflect needed.

On Mon, Mar 13, 2017, 01:37 st ov  wrote:

> Thanks!
> anyway to get a reference to that new array without using reflect?
>
>
>
>
> On Sunday, March 12, 2017 at 12:13:03 PM UTC-7, Jan Mercl wrote:
>
> On Sunday, March 12, 2017 at 11:49:33 AM UTC-7, st ov wrote:
>
> > What happens when appending to a slice exceeds the backing capacity?
>
> If the capacity of s is not large enough to fit the additional values,
> append allocates a new, sufficiently large underlying array that fits both
> the existing slice elements and the additional values. Otherwise, append
> re-uses the underlying array.
>
> src: https://golang.org/ref/spec#Appending_and_copying_slices
>
> --
>
> -j
>
> --
> 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.
>
-- 

-j

-- 
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 send women to Gophercon this year!

[sadams . codes]

Hey all,

I've started a crowdfunding campaign to send women to Gophercon 
(gophercon.com) who can't afford to go.

Please consider donating! Any amount appreciated. 
Please also forward to your employers.

https://igg.me/at/Ei-kyYFu77k

Women Who Go is part of a 501c3, so your employer may be able to match your 
$$, and donations are tax-deductible in the USA.

Feel free to email me if you have questions - he...@womenwhogo.org.

Cheers,
Sarah

-- 
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] Call for Proposals: GORUCO 2017, NYC, June 24th

[Mike Dalessio]

Hey there,

I'd like to ask y'all to consider submitting talk proposals to GORUCO 2017, 
which is a terrific regional software conference that I co-organize here in 
NYC. It may not be what you'd consider an obvious fit for gophers, but I 
assure you that talks about Go would be well received.

More details are below.

Thanks for your consideration,
-mike


---

*# GORUCO 2017 is now accepting talk proposals!*

On Saturday, June 24th, [GORUCO][] is celebrating its 11th convocation as 
NYC's premier regional software conference. It's a one-day, single-track 
event geared toward highly motivated and experienced developers that's been 
celebrated for its warm, personal spirit and strong sense of community.

  [GORUCO]: http://goruco.com

You can start submitting your proposals at http://cfp.goruco.com/. If you 
have questions, please email propos...@goruco.com.


*## “Why should I speak at GORUCO?”*

GORUCO is a perfect forum to introduce Go and Go libraries and frameworks 
to a cohort of strong engineers who love to learn, who appreciate the craft 
of software, and who share a joy in building amazing things. Historically 
focused on Ruby, the conference has evolved over the years to include a 
broad set of technologies to match and to expand the community's technical 
and practical interests.

In the past two years, speakers have presented on diverse topics like Go, 
Crystal, Elixir, NoSQL, BigQuery, distributed systems, AI, reverse 
engineering hardware, and static code analysis.

We've also had many talks about the human side of software, as you might 
expect from a community that values developer creativity and happiness. 
Speakers have presented on code hospitality, refactoring, readability, 
culture, dogma, mentoring, and learning.

You can view videos of our past speakers for inspiration at 
http://videos.goruco.com/.

Though we tend to gear our program toward more experienced developers, we 
will consider talks intended for all skill levels and would appreciate if 
you'd tag your proposal appropriately to tell us the who the target 
audience is.


*## Format*

This year we'll again be scheduling two talk formats:

* full length talk (30-40 minutes)
* micro-talk (10 minutes)

Please tag your proposal if you have a preference for one or the other (or 
both if either would be appropriate!).

We will be recording all the talks and making the videos freely available 
online under a Creative Commons license. If your talk is accepted, you'll 
be asked to sign a consent form.


*## Speaker Benefits*

All speakers will receive free attendance to the event. In addition, 
speakers accepted for a talk will receive a $1200 travel reimbursement if 
you live outside the tri-state region. (Local speakers will instead receive 
a $300 honorarium.)


*## Diversity and Inclusion*

GORUCO speakers have been extraordinarily diverse, with 46% of the speakers 
in 2015 and 2016 identifying as female, and many identifying as 
non-Caucasian.

The GORUCO organizers, ourselves a diverse group, are dedicated to continue 
this tradition, and strongly encourage members of under-represented groups 
to submit proposals.

Our first round of reviews this year, as last year, will be completely 
anonymous. Our goal is to have a diverse panel, with at least 50% of 
reviewers identifying as a member of an under-represented group.


*## Code of Conduct*

The GORUCO organizers strive for the safety and comfort of everyone at our 
event. We have a [Code of Conduct][] that will be strictly enforced, and 
that we expect all speakers and attendees to follow. Please review it 
before submitting your proposals.

  [Code of Conduct]: http://2016.goruco.com/code-of-conduct/


*## Local Speaker Slots*

GORUCO believes in highlighting local talent. We reserve at least two slots 
for local speakers. (Individual talks and panels will be considered "local" 
if at least half of the participants are from the tri-state region - that 
is, within typical commuting distance of Manhattan.)

In the past, these slots have been less competitive than the other talk 
slots, so if you live in the tri-state region we strongly urge you to 
submit a proposal.


*## Timeline*

The CFP closes at midnight on Tuesday, March 28th.

Early submissions are likely to get a level of attention that later 
submissions may not receive, including questions and feedback from 
reviewers. Our advice is to submit early if you can!

We're planning speaker selection to be complete by Saturday, April 1st, and 
over the week of April 2nd we'll seek to get confirmation from speakers and 
lock in the schedule.

You can start submitting your proposals at http://cfp.goruco.com/. If you 
have questions, please email propos...@goruco.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 

[go-nuts] json.Unmarshal and modifications to copies of structs

[george.robinson via golang-nuts]

Hello,

Can someone explain to me how this prints "test world" twice? I had 
expected to see "test hello" and "test world".

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

Kind regards,


-- 
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: [ANN] fsq 1.4.0 released

[rupcraft]

Thanks for the input! By 'checking', I assume you mean check y.go into the git 
repository. I realize the motivation for this (go get), but since parser.y 
contains the actual change history (while y.go is generated), I tend to lean in 
favor of only versioning the yacc source. If fsq was meant to be used as a 
library, I could see a reasonably compelling case for this, however. 

-- 
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 test` does not honor -ldflags

[marcus.low via golang-nuts]

My apologies, I did not realise my work signature would automatically be 
added.

-- 
 


-- 
*Grab is hiring. Learn more at **https://grab.careers 
*

By communicating with Grab Inc and/or its subsidiaries, associate companies 
and jointly controlled entities (“Grab Group”), you are deemed to have 
consented to processing of your personal data as set out in the Privacy 
Notice which can be viewed at https://grab.com/privacy/

This email contains confidential information and is only for the intended 
recipient(s). If you are not the intended recipient(s), please do not 
disseminate, distribute or copy this email and notify Grab Group 
immediately if you have received this by mistake and delete this email from 
your system. Email transmission cannot be guaranteed to be secure or 
error-free as any information therein could be intercepted, corrupted, 
lost, destroyed, delayed or incomplete, or contain viruses. Grab Group do 
not accept liability for any errors or omissions in the contents of this 
email arises as a result of email transmission. All intellectual property 
rights in this email and attachments therein shall remain vested in Grab 
Group, unless otherwise provided by law.

-- 
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: fixed precision formatting of floating point

['simon place' via golang-nuts]

thinking about it another way, its noise, no human reading the output would 
even need to know if the value were effectively zero from underneath or 
from above.

-- 
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: fixed precision formatting of floating point

['simon place' via golang-nuts]

this isn't a signed zero, this is a very small negative float rounded off 
by fmt.

it has as little actual different to zero as is possible to get (in float64 
in this case) so will make as little difference to further calculation as 
it is possible to get.

so either "-0.00" or " 0.00" are produced depending on an 
impossible to predict rounding difference, ie are randomly produced. this 
happens no where else but when a calculation would have been zero with 
unlimited storage for the float.

-- 
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: What happens when appending to a slice exceeds the backing capacity?

[st ov]

Thanks!
anyway to get a reference to that new array without using reflect?



On Sunday, March 12, 2017 at 12:13:03 PM UTC-7, Jan Mercl wrote:
>
> On Sunday, March 12, 2017 at 11:49:33 AM UTC-7, st ov wrote:
>
> > What happens when appending to a slice exceeds the backing capacity?
>
> If the capacity of s is not large enough to fit the additional values, 
> append allocates a new, sufficiently large underlying array that fits both 
> the existing slice elements and the additional values. Otherwise, append 
> re-uses the underlying array.
>
> src: https://golang.org/ref/spec#Appending_and_copying_slices
>
> -- 
>
> -j
>

-- 
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: fixed precision formatting of floating point

[peterGo]

simon,

The IEEE Standard for Floating-Point Arithmetic (IEEE 754) defines sets of 
binary and decimal floating-point data, which consist of finite numbers 
(including signed zeros and subnormal numbers), infinities, and special 
"not a number" values (NaNs).

Signed Zero: https://en.wikipedia.org/wiki/Signed_zero

Peter

On Sunday, March 12, 2017 at 2:10:30 PM UTC-4, simon place wrote:
>
> when trying to compare two floats, for testing, i ran into the usual 
> problems with rounding.
>
> so, i thought, a nice way out would be to compare their fixed precision 
> formatted strings.
>
> which works except, fmt "%f" fixed precision still contains an unnecessary 
> rounding issue;
>
> when the float is very near zero, (it can be slightly above or below 
> depending on rounding), fmt adds a '-' or it doesn't, meaning you get for 
> example "-0.0"
>
> why have just one value, zero, at which two floats, which are the same to 
> the precision, print differently?
>  
> this doesn't seem to be 'human readable' output, no human would add the 
> unnecessary '-'.
>

-- 
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: [ANN] G3N - Go 3D Game Engine

['simon place' via golang-nuts]

thanks for confirming that, i was guessing you had done that for x-platform 
support anyway.

i started making a 3d viewer myself with glfw last year, its as much shader 
as possible, not worked on it recently, apart from looking at non-x 
solutions.

On Sunday, 12 March 2017 19:16:58 UTC, leonsal wrote:
>
> The dependencies on the X server are needed by the GLFW window manager 
> (*http://www.glfw.org 
> *).
> We tried to abstract the window manager in the "window" package.
> So it would be theoretically possible to build another window manager using
> a Go binding for an EGL library and use it with the engine.
>
>
> On Sunday, March 12, 2017 at 3:47:13 PM UTC-3, simon place wrote:
>>
>> OK, i see X server in there, unfortunately the target system i was 
>> currently looking at doesn't have x support, just egl.
>>
>>

-- 
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: [ANN] G3N - Go 3D Game Engine

[leonsal]

The dependencies on the X server are needed by the GLFW window manager (
*http://www.glfw.org*).
We tried to abstract the window manager in the "window" package.
So it would be theoretically possible to build another window manager using
a Go binding for an EGL library and use it with the engine.


On Sunday, March 12, 2017 at 3:47:13 PM UTC-3, simon place wrote:
>
> OK, i see X server in there, unfortunately the target system i was 
> currently looking at doesn't have x support, just egl.
>
>

-- 
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: What happens when appending to a slice exceeds the backing capacity?

[Jan Mercl]

On Sunday, March 12, 2017 at 11:49:33 AM UTC-7, st ov wrote:

> What happens when appending to a slice exceeds the backing capacity?

If the capacity of s is not large enough to fit the additional values,
append allocates a new, sufficiently large underlying array that fits both
the existing slice elements and the additional values. Otherwise, append
re-uses the underlying array.

src: https://golang.org/ref/spec#Appending_and_copying_slices

-- 

-j

-- 
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: What happens when appending to a slice exceeds the backing capacity?

[st ov]

pasting code for convenience

func main() {

// create backing array
arr := [5]int {0,1,2,3,4}
fmt.Println(arr)

// take a slice of backing array
s1 := arr[:3]
fmt.Println(s1)
fmt.Println(arr)
fmt.Println(cap(s1))

// append to slice, replaces backing array?
s1 = append(s1, 7)
fmt.Println(s1)
fmt.Println(arr)

// append to slice, doesn't replace backing array?
// whats backing the slice?
s1 = append(s1,8,9,10)
fmt.Println(s1)
fmt.Println(arr)
fmt.Println(cap(s1))
}




On Sunday, March 12, 2017 at 11:49:33 AM UTC-7, st ov wrote:
>
> What happens when appending to a slice exceeds the backing capacity?
>
> https://play.golang.org/p/mVezWL4Cbe
>
> In the example given, appending within capacity on line 20 modifies the 
> backing array at the successive index.
> But on line 26, when appending exceeds the capacity, the backing array is 
> no longer modified. So where are those additional elements stored?
>
> Also the capacity for this new backing store is 12, this is to amortize 
> performance correct?
>

-- 
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] What happens when appending to a slice exceeds the backing capacity?

[st ov]

What happens when appending to a slice exceeds the backing capacity?

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

In the example given, appending within capacity on line 20 modifies the 
backing array at the successive index.
But on line 26, when appending exceeds the capacity, the backing array is 
no longer modified. So where are those additional elements stored?

Also the capacity for this new backing store is 12, this is to amortize 
performance correct?

-- 
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: [ANN] G3N - Go 3D Game Engine

['simon place' via golang-nuts]

OK, i see X server in there, unfortunately the target system i was 
currently looking at doesn't have x support, just egl.

-- 
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: [ANN] G3N - Go 3D Game Engine

[leonsal]

Output of *ldd* of the G3N demo (G3ND) in my Linux box:

linux-vdso.so.1 =>  (0x7ffebade6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9b136e7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f9b134ca000)
libGL.so.1 => /usr/lib/nvidia-367/libGL.so.1 (0x7f9b1323a000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7f9b12f0)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 
(0x7f9b12cf5000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 
(0x7f9b12aea000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9b127e1000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 
(0x7f9b125de000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9b123d5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9b1200c000)
/lib64/ld-linux-x86-64.so.2 (0x55713f649000)
libGLX.so.0 => /usr/lib/nvidia-367/libGLX.so.0 (0x7f9b11ddb000)
libGLdispatch.so.0 => /usr/lib/nvidia-367/libGLdispatch.so.0 
(0x7f9b11af1000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7f9b118cf000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7f9b116bd000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 
(0x7f9b114b2000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7f9b112ac000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7f9b110a7000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 
(0x7f9b10ea1000)

On Sunday, March 12, 2017 at 2:54:34 PM UTC-3, simon place wrote:
>
> interesting, something i'm active around.
>
> just checking, the only dependency for the compiled result is opengl?
>
>
> On Sunday, 12 March 2017 14:52:51 UTC, leonsal wrote:
>>
>> Hi All,
>>
>> G3N is an OpenGL 3D Game Engine written in Go: 
>> https://github.com/g3n/engine
>> Try out the game engine demo at: https://github.com/g3n/g3nd
>>
>> Regards.
>>
>>
>>
>>
>>
>>

-- 
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] fixed precision formatting of floating point

['simon place' via golang-nuts]

when trying to compare two floats, for testing, i ran into the usual 
problems with rounding.

so, i thought, a nice way out would be to compare their fixed precision 
formatted strings.

which works except, fmt "%f" fixed precision still contains an unnecessary 
rounding issue;

when the float is very near zero, (it can be slightly above or below 
depending on rounding), fmt adds a '-' or it doesn't, meaning you get for 
example "-0.0"

why have just one value, zero, at which two floats, which are the same to 
the precision, print differently?
 
this doesn't seem to be 'human readable' output, no human would add the 
unnecessary '-'.

-- 
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: [ANN] G3N - Go 3D Game Engine

['simon place' via golang-nuts]

interesting, something i'm active around.

just checking, the only dependency for the compiled result is opengl?


On Sunday, 12 March 2017 14:52:51 UTC, leonsal wrote:
>
> Hi All,
>
> G3N is an OpenGL 3D Game Engine written in Go: 
> https://github.com/g3n/engine
> Try out the game engine demo at: https://github.com/g3n/g3nd
>
> Regards.
>
>
>
>
>
>

-- 
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] [ANN] G3N - Go 3D Game Engine

[David Peacock]

On Sat, Mar 11, 2017 at 5:14 PM, leonsal  wrote:

> G3N is an OpenGL 3D Game Engine written in Go: https://github.com/g3n/
> engine
> Try out the game engine demo at: https://github.com/g3n/g3nd
>
> This is very welcome indeed.  Massive kudos!

Thank you!

David 

-- 
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] [ANN] G3N - Go 3D Game Engine

[leonsal]

Hi All,

G3N is an OpenGL 3D Game Engine written in Go: https://github.com/g3n/engine
Try out the game engine demo at: https://github.com/g3n/g3nd

Regards.





-- 
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: Simple design question: method or function?

[shahamit2]

Please check 
https://grisha.org/blog/2016/09/22/golang-receiver-vs-function/ 

On Wednesday, March 2, 2016 at 1:04:55 AM UTC+5:30, Julio Guerra wrote:
>
> After all these years, this excellent question is still not clearly 
> answered... This point of the language makes this design decision really 
> unclear when beginning. Because method calls on method receivers are 
> statically resolved, while method calls on arguments whose types are 
> interfaces are dynamically dispatched and statically checked (compile-time 
> error when the expected interface is not implemented). So this question 
> really needs more attention and a more straightforward design rule. Mix in 
> type embedding and you end up with a mental node ><
>

-- 
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: No Allman-Style, No go!

[xiiophen]

Duh .. Apologies for the previous post - I only read the first page of 
responses - didn't realise this discussion had extended to several pages .. 
it probably repeats stuff that had been said several times before.

-- 
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: No Allman-Style, No go!

[xiiophen]

 
Attempt to clarify the behaviour - your problem is happening because of the 
line in the specification in https://golang.org/ref/spec#Semicolons which 
states 

*When the input is broken into tokens, a semicolon is automatically 
inserted into the token stream immediately after a line's final token if 
that token is ... one of the operators and delimiters ++, --, ), ], or }*


so this is fine 

package main; 

 

import "fmt";

 

func main() {

fmt.Printf("hello, world!\n");

}

and this is not :


package main; 

 

import "fmt";

 

func main() 

{

fmt.Printf("hello, world!\n");

}


because the second case is converted to  :

package main; 

 

import "fmt";

 

func main();

{

fmt.Printf("hello, world!\n");

}


because of the rule given above in the spec - that is there's an insertion 
of a semicolon after the () in the func ...


You probably already got that - the question is "why is it such a sissy" 
and I think the short answer is - because *the spec is aiming to create a 
syntax/grammar that is parsable one line at a line without reading forward*

Go not only borrows obviously from C, but also maybe less obviously from 
Pascal (and those ETH Zuritch / Nicolas Wurth family of languages) - one 
thing that is influenced by this is the form of some variable declarations 
.. I think(opinion) another influence is the original Pascal compiler 
design that the compiler could produce output from a single pass of a 
program. One of the design goals of Go was for quick compilation - so maybe 
we can see the thought process here.. It's not unreasonable to say it's 
gone too far.

So as a consequence of the aim to make the compiler "simple" Allman style 
is *essentially illegal -* but not by choice - it's just a consequence of 
streamlined parser design - not because we don't like Allman style.

Go also enforces a single style - as other's have said that's unlikely to 
change - a lot of use don't like/have complaints about the chosen style but 
accept it because it enables a consistent formatting style no matter who 
wrote the code - so accepting that - even if the compiler accepted the 
second form of the simple program (it doesn't) - it would still gofmt it to 
the other style..


So it's a trade off - a single style (that is a lot like K) so that all 
programs are formatted the same and to ease compilation.

  

  

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

[James Pettyjohn]

I tried this once and I don't know that I effectively decoupled the direct 
cgo dependency. Any pointers on effectively doing this?

On Saturday, March 11, 2017 at 11:22:03 PM UTC-8, Tamás Gulácsi wrote:
>
> Factor out the cgo related part into a wrapper package (subdir), that will 
> help with the compile times.

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

[James Pettyjohn]

Aye, this is some ways down the road now - quite a few projects on this 
base template. Only real complaint is:

- Submodules get out of date where data is concerned
- Some submodules contain a lot of data and so bloat deployment (e.g. 
maxmind)
- cgo dependency leading to: can't use a blank docker container, slower to 
compile and local installation dependencies
- something like site indexing for search does not share data so every 
concurrent instance builds at runtime after a deploy
- upgraded submodules may take a while to get to all the projects, leaving 
project feature inconsistent

I'm inclined to move out anything which has changing/largish data sets and 
centralize search (though during a rolling deploy this could be an 
interesting disaster).


On Saturday, March 11, 2017 at 10:05:49 PM UTC-8, Matt Ho wrote:
>
> If you're just starting out the project, by all means start with the 
> monolith where everything is together.  If you decide it's necessary, over 
> time you can split out the project into what you've discovered you need.  
>
> Trying to abstract the components you think you'll need too early is a 
> good recipe for heartache.  
>
> M
>
>
> On Saturday, March 11, 2017 at 9:00:43 PM UTC-8, James Pettyjohn wrote:
>>
>> I'm looking at the pros and cons of how to architect a web project.
>>
>> 1) One is a single go project for a site. No service dependencies for the 
>> backend at all. Certain aspects of this means a cgo dependency which is not 
>> ideal as it complicates containerization and slows build time. One plus to 
>> this is the simplicity in development - the entire project is self 
>> sufficient and tests are easily checking everything - thought compilation 
>> and startup suffer.
>>
>> 2) Another means would be to split out portions of the project. This adds 
>> dev complexity as it requires more services to enable parts of the server, 
>> or run at all. Coordination of service versions becomes an issue. But the 
>> services, now being centrally located, can be deployed and result in 
>> updates to all services using it. I think from the ops perspective this 
>> could be more efficient as you don't inherit the overhead in all projects.
>>
>>
>> Opinions on the above? Another approach entirely?
>>
>>
>>

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