Re: [go-nuts] How to constrain an integral type's values

['Thomas Bushnell BSG' via golang-nuts]

I recommend using strings as the base type for things like this, rather
than ints. There is no need to use ints, just because that's what C uses.

Thomas

On Fri, Sep 8, 2023 at 3:24 AM 'Mark' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I often create small multi-value flag types, e.g.
> ```go
> type mode uint8
>
> const (
> argMode mode = iota
> baseMode
> cmdMode
> )
> ```
> The problem is that if I write, say,  `m := baseMode`, although `m` has
> the correct type (`mode`), there is no way to constrain its values to the
> consts I've declared.
> In theory I could create a `NewMode(int) mode` function and have it panic
> if the given int isn't valid; but that won't prevent, say, `m += 99`. The
> next step would be to define a full type, e.g., something like:
> ```go
> type mode struct {
> m int
> }
> ```
> This would prevent `m++` and similar since all accesses would have to go
> through the public functions. However, this would still do all its checking
> at _runtime_; whereas for this kind of use it should surely be possible to
> check at compile time.
>
> In Pascal it is easy to declare a "subrange" type which might look like
> this in Go-like syntax:
>
> `type mode uint8 0..2`
>
> Is there a compile-time solution for this that I've missed?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8ba9ef87-984c-4b14-a760-343d2731e91dn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxunOzRKt2vB9u8QtOmP%2Bwqavn7Yjky9jz4-C3b0%2BkAWRg%40mail.gmail.com.

Re: [go-nuts] Re: From which programming language did the idea for Golang's interface mechanism design originate?

['Thomas Bushnell BSG' via golang-nuts]

Another precedent for the idea was the use of a "behavior" to specify the
methods which a Smalltalk object can receive. Basically, it was realized
that the question of the class hierarchy for an object was an
implementation concern which the users of an object should not care about.
So early Smalltalk books started using the word "behavior" to refer roughly
to something like a Go "method set". When Smalltalk standardization
happened, the class hierarchy was almost entirely left out of the standard,
instead relying on these behaviors to say what methods an object would
support. Implementations could then make their own decisions about how to
factor those into classes for implementation.

The main difference between these behaviors and Go's interfaces is that a
behavior in Smalltalk is only a way to talk *about *the language; there is
no such thing as a behavior datatype in Smalltalk, no syntax for specifying
them, etc. It's a way to document what things do, but not something checked
by the compiler. However, as soon as you have typed variables, and you
would be deciding whether the types should be classes or behaviors, you
would certainly pick behaviors (and thus something like Go's interfaces) as
superior to classes (like Java or Python typically use).

Thomas

On Fri, Aug 25, 2023 at 12:27 AM Rob Pike  wrote:

> It was dreamed up independently at the whiteboard on the first day of
> design discussions. We did not know Emerald at the time; the similarity was
> discovered later.
>
> This is not to claim the idea is original, just that we discovered it
> independently.
>
> -rob
>
>
> On Fri, Aug 25, 2023 at 1:57 PM Andrew Harris 
> wrote:
>
>> The comments on Go Data Structures: Interfaces
>>  mention Emerald
>> , maybe this is what you were
>> thinking of?
>>
>> On Thursday, August 24, 2023 at 8:42:43 PM UTC-7 xie cui wrote:
>>
>>> I remembe someone in a video in youtube explain the design of interface.
>>> But I cann't find it now.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e873392b-47fe-4fa9-b465-efadcde0bfd8n%40googlegroups.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOXNBZQ8D5f2uLb1%3D8ttmnwzo7WY3vYqKu7W3Sz%3DqyQ3OmjfTA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtGcGxW_yWqot%2BeF%2BSVZyY%3DrSTXRKFp8FVh%3DezQ48WH9A%40mail.gmail.com.

Re: [go-nuts] Please consider voting to reopen Golang subreddit

['Thomas Bushnell BSG' via golang-nuts]

I mean, this is mostly true, except that the protesters do have the right
to administer the subreddit in the way they choose, as long as they are the
admins.

As you said, if you don't like that, you are of course free to use a
different site. But it seems a bit off-kilter to say "if you don't like it,
vote with your feet", while complaining about the actions some other users
of the site have taken, and not voting with your feet.

Thomas


On Fri, Jun 23, 2023 at 4:29 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Fri, Jun 23, 2023 at 10:18 AM Axel Wagner
>  wrote:
>
> > Just for context, as not everyone seems to be aware: I was, in that
> sentence you quoted, referring to examples like this
> >
> https://www.reddit.com/r/ModCoord/comments/14eq8ip/the_entire_rmildlyinteresting_mod_team_has_just/
> > This demonstrates that even with overwhelming support from the community
> (and yes, in this example the modifier applies), the company overwrites
> those wishes to shut down protest. There are a couple of other subreddits
> with similar stories.
> >
> > So I was making the case to *provide* overwhelming support for the mods
> of /r/golang, referring to precedent of other subreddits where that is
> happening. Not claiming that they already have it.
>
> Thanks for the added conext.
>
> Anyone not liking Reddit is free to not visit the site. Anyone not
> accepting the price for the API access is free to not buy it. It's
> fine to vote by your visits and by your wallet. That's how the free
> market works and it works well unless there's some monopoly. But
> Reddit has no monopoly.
>
> Protesters are free to protest. That's their respected right.
> Protesters have no right to deny access to other users. That's my
> right and I expect it to be equally respected.
>
> PS: I'm paying $7/month to Reddit to have r/golang ad-free. May I ask
> you for a refund? Thanks for your consideration.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-UU-fvBis8XZuOobK_6wW44iOddAzni1KRF9udHH-ELtg%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxsAktj0Pk2odDnxMUArcaeLYzCvtmS09ZdJdL27p9eN4Q%40mail.gmail.com.

Re: [go-nuts] Re: Why not tuples?

['Thomas Bushnell BSG' via golang-nuts]

Use the json package to parse the incoming data. Transform it as you
please. Use the json package to format the output.

I'm not sure I see the problem.

On Sat, Dec 3, 2022, 10:47 PM Diogo Baeder  wrote:

> Hi there, sorry for weighting in so late in the game, but I just started
> again to learn Go and was thinking why the language still doesn't have a
> tuple type.
>
> Now, imagine this scenario: I have a web application which has to access a
> webservice that responds with JSON payloads; These payloads are a list of
> values, where each value is a smaller list like '[20220101, 1.234, "New
> York"]'. And these smaller lists follow the same type sequence: int64,
> float64, string. Suppose that I want to filter those values and send a
> response to the client, with the data structure unchanged (same format and
> types). Today, it doesn't seem to be possible to do that in Go, unless I do
> some dirty hack like decoding to '[]any' and then cast to the other types,
> and then hack again to put these values in the response to the client.
>
> I totally understand the reasoning for preferring the usage of structs for
> heterogeneous data (and I myself do prefer them, they're much more powerful
> in general), but there's real world data that's available like in the
> example above, and we just can't go on changing them at their sources. I
> might be mistaken (please let me know if it's the case), but it seems like
> Go is missing an opportunity to interoperate with what's a fundamental data
> structure in many other languages (Python, Rust etc). I'm having a lot of
> fun learning to use the language, and would be happy to see this feature
> being implemented at the core.
>
> (Maybe what I said above is total BS, I acknowledge that since I'm an
> almost complete ignorant in the language)
>
> Cheers!
>
> On Thursday, April 19, 2018 at 1:03:55 PM UTC-3 Louki Sumirniy wrote:
>
>> Multiple return values. They do kinda exist in a declarative form of
>> sorts, in the type signature, this sets the number and sequence and types
>> of return values. You could even make functions accept them as also input
>> values, I think, but I don't think it works exactly like this. I'm not a
>> fan of these things because of how you have to nominate variables or _ and
>> type inference will make these new variables, if you  := into whatever the
>> return was.
>>
>> I'm not sure what the correct word is for them. Untyped in the same way
>> that literals can be multiple types (especially integers) but singular in
>> their literal form.
>>
>>
>> On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>>>
>>> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy 
>>> wrote:
>>>
>>> > Sorry for the self-promotion but it was relevant in that I was working
>>> on how to tidy up the readability of my code and needed multiple returns
>>> and simple untyped tuples were really not nearly as convenient as using a
>>> type struct.
>>>
>>> I have no idea what you mean by 'untyped tuples' because Go does not
>>> have tuples, or at least not as a well defined thing. I can only guess if
>>> you're trying to implement tuples in Go with an array, slice or a struct,
>>> ...? To add to my confusion, Go functions can have as many return values as
>>> one wishes just fine, ie. I obviously do not even understand what problem
>>> you're trying to solve. Sorry.
>>>
>>>
>>> --
>>>
>>> -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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8e728e0f-341d-4340-a868-aac028dfc443n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxt_bR0wOxkiTp7pYNp-%3DiyzE_KTS-Rk1oRW1wpCv09CUA%40mail.gmail.com.

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

['Thomas Bushnell BSG' via golang-nuts]

Late binding means you don't need to know the types of your parameters *at
all* when you write a method call. If the language supported late binding,
then you would be able to define all your variables as Object and
*everything would continue to work*.

In Go you could define everything as interface{} and then use small
interfaces around every call:

foo.(interface{ Method() string}).Method()

In Java, you can use the reflection interface. In this sense, it is
available "on demand", but that's not the same thing at all.

Both Java and C++ made the mistake of confusing a class with a behavior,
and then using classes as names for behaviors.



On Tue, Nov 22, 2022 at 11:46 AM Robert Engels 
wrote:

> What would be the purpose of writing B calling a method on A that doesn’t
> exist?
>
> On Nov 22, 2022, at 10:36 AM, 'Thomas Bushnell BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> Both Java and Go require that a method be instantiated in the declared
> interface of the type at compile time. This is contrary to the point of
> late binding.
>
> In the case of Go, this cannot be detected, because everything is built
> together. But with Java, you cannot call a method on an object unless that
> method has *already *been defined. In other words, late binding supports
> the following order of things:
>
> 1) Write class A, with method X and only X. Compile it.
> 2) Write class B, which instantiates class A and calls method Y (which
> does not exist yet). Compile it.
> 3) Extend class A to add method Y. Compile it.
> 4) Execute class B.
>
> Late binding says this should work, but the Java compiler will throw an
> error at step two. Go never throws that error, because Go only builds the
> whole program at once, so the partial compilations don't make sense.
>
> In addition, any method marked final does not support late binding -
> indeed, this is the point of the keyword, and is why I remarked that this
> is because they couldn't figure out how to do it efficiently.
>
> Thomas
>
> On Tue, Nov 22, 2022 at 11:25 AM Robert Engels 
> wrote:
>
>> Why do you say that Java does not have late binding. It 100% does. In
>> fact the JVM supports dynamic dispatch to make this as efficient as
>> possible. Then the JIT optimizes it even more based on runtime behavior.
>>
>> On Nov 22, 2022, at 10:18 AM, Matt KØDVB  wrote:
>>
>> 
>> But see https://en.wikipedia.org/wiki/Self_(programming_language)
>>
>> Self was considered an OO language back when I was a grad student and is
>> still listed that way today, even though it has neither classes nor
>> inheritance.
>>
>> Anyway, my point would be that the term OO originates with Alan Kay and
>> the team at Xerox PARC; Kay’s response to the OO flame wars was to
>> de-emphasize classes and inheritance.
>>
>> Of course, using his definition, neither Java nor Go would be “truly” OO
>> since not all things use late binding :-)
>>
>> Perhaps we can talk about class-based and non-class based OO languages?
>>
>> On Tue, Nov 22, 2022 at 10:07 AM Robert Engels 
>> wrote:
>>
>>> The wiki OO page lists classes as a requirement - but not necessarily
>>> inheritance. Class variables require classes.
>>>
>>> Also, your link does not work.
>>>
>>> > On Nov 22, 2022, at 9:56 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>> >
>>> > On Tue, Nov 22, 2022 at 4:43 PM Robert Engels 
>>> wrote:
>>> >
>>> >> Go is not listed as an OO language on Wikipedia.
>>> >
>>> > Check https://en.wikipedia.org/wiki/Go_(programming_language):
>>> > "ParadigmMulti-paradigm: concurrent imperative, object-oriented[1][2]"
>>> >
>>> >> Personally I think it is OO-like. OO typically has inheritance.
>>> >
>>> > Typically they may, but that's not the same as what a requirement
>>> > would be, right?
>>> >
>>> >> There are also no “class variables” - only package level - which
>>> makes some encapsulation patterns harder (every class has to become a
>>> package).
>>> >
>>> > No class has to become a package because Go has no classes. You may
>>> > think of what a "class" in Go means, but you have not defined that
>>> > idea and the language specification is somehow silent about Go
>>> > classes.
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> > To unsubscri

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

['Thomas Bushnell BSG' via golang-nuts]

Both Java and Go require that a method be instantiated in the declared
interface of the type at compile time. This is contrary to the point of
late binding.

In the case of Go, this cannot be detected, because everything is built
together. But with Java, you cannot call a method on an object unless that
method has *already *been defined. In other words, late binding supports
the following order of things:

1) Write class A, with method X and only X. Compile it.
2) Write class B, which instantiates class A and calls method Y (which does
not exist yet). Compile it.
3) Extend class A to add method Y. Compile it.
4) Execute class B.

Late binding says this should work, but the Java compiler will throw an
error at step two. Go never throws that error, because Go only builds the
whole program at once, so the partial compilations don't make sense.

In addition, any method marked final does not support late binding -
indeed, this is the point of the keyword, and is why I remarked that this
is because they couldn't figure out how to do it efficiently.

Thomas

On Tue, Nov 22, 2022 at 11:25 AM Robert Engels 
wrote:

> Why do you say that Java does not have late binding. It 100% does. In fact
> the JVM supports dynamic dispatch to make this as efficient as possible.
> Then the JIT optimizes it even more based on runtime behavior.
>
> On Nov 22, 2022, at 10:18 AM, Matt KØDVB  wrote:
>
> 
> But see https://en.wikipedia.org/wiki/Self_(programming_language)
>
> Self was considered an OO language back when I was a grad student and is
> still listed that way today, even though it has neither classes nor
> inheritance.
>
> Anyway, my point would be that the term OO originates with Alan Kay and
> the team at Xerox PARC; Kay’s response to the OO flame wars was to
> de-emphasize classes and inheritance.
>
> Of course, using his definition, neither Java nor Go would be “truly” OO
> since not all things use late binding :-)
>
> Perhaps we can talk about class-based and non-class based OO languages?
>
> On Tue, Nov 22, 2022 at 10:07 AM Robert Engels 
> wrote:
>
>> The wiki OO page lists classes as a requirement - but not necessarily
>> inheritance. Class variables require classes.
>>
>> Also, your link does not work.
>>
>> > On Nov 22, 2022, at 9:56 AM, Jan Mercl <0xj...@gmail.com> wrote:
>> >
>> > On Tue, Nov 22, 2022 at 4:43 PM Robert Engels 
>> wrote:
>> >
>> >> Go is not listed as an OO language on Wikipedia.
>> >
>> > Check https://en.wikipedia.org/wiki/Go_(programming_language):
>> > "ParadigmMulti-paradigm: concurrent imperative, object-oriented[1][2]"
>> >
>> >> Personally I think it is OO-like. OO typically has inheritance.
>> >
>> > Typically they may, but that's not the same as what a requirement
>> > would be, right?
>> >
>> >> There are also no “class variables” - only package level - which makes
>> some encapsulation patterns harder (every class has to become a package).
>> >
>> > No class has to become a package because Go has no classes. You may
>> > think of what a "class" in Go means, but you have not defined that
>> > idea and the language specification is somehow silent about Go
>> > classes.
>> >
>> > --
>> > 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.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAA40n-U%3DG8gqAZEHrnLUxbg5vsAcRkNV35c86c79xcrhSzLSWw%40mail.gmail.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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/A1F03B77-7CDC-46CC-B2E0-2C3C1B7DC966%40ix.netcom.com
>> .
>>
>
>
> --
>
> Matt
> K0DVB
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANRS-2%2Bre6WUFT6tE8QinUZ-ipqLvwNTr2hoHNiD4H%3DwQ8T7HA%40mail.gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/A5532469-6B1D-4C18-8DBE-F03FD56E8830%40ix.netcom.com
> 

Re: [go-nuts] clarifying Go FAQ: Is Go an object-oriented language?

['Thomas Bushnell BSG' via golang-nuts]

Asking "the definition of object oriented programming" seems a bad idea to
me. Alan Kay invented the term, and he was pretty clear that C++ was not
anything like what he had in mind, and yet, a lot of people think C++ is an
object oriented language. I don't, as it happens.

Inheritance used to be thought of as quite fundamental, but not so much any
more. I think that's probably right.

But here are some other things: object oriented languages are supposed to
have object ubiquity. I think Stroustrup probably did not understand the
point, and the designers of Java couldn't figure out how to make it
efficient. So much for them. C++ gets so much wrong it hardly matters. But
Java doesn't; it more or less regrets that it has non-object types. Go is
very different however: Go does not regard interfaces as something that
should be ubiquitous or feel bad when they aren't used. In fact, they are
discouraged except when actually required.

Late binding is another key feature, one which again C++ mostly didn't
understand the point of, and Java couldn't figure out how to implement
efficiently, so everyone does "final" instead. Go does have late binding
for interface method calls, but only on-demand.

Object oriented languages are generally either class-based or
prototype-based. Go is neither, having nothing like classes and nothing
like prototypes. For me, this is the most salient thing to keep in mind.

On Tue, Nov 22, 2022 at 10:56 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Nov 22, 2022 at 4:43 PM Robert Engels 
> wrote:
>
> > Go is not listed as an OO language on Wikipedia.
>
> Check https://en.wikipedia.org/wiki/Go_(programming_language):
> "ParadigmMulti-paradigm: concurrent imperative, object-oriented[1][2]"
>
> > Personally I think it is OO-like. OO typically has inheritance.
>
> Typically they may, but that's not the same as what a requirement
> would be, right?
>
> > There are also no “class variables” - only package level - which makes
> some encapsulation patterns harder (every class has to become a package).
>
> No class has to become a package because Go has no classes. You may
> think of what a "class" in Go means, but you have not defined that
> idea and the language specification is somehow silent about Go
> classes.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-U%3DG8gqAZEHrnLUxbg5vsAcRkNV35c86c79xcrhSzLSWw%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxt7BVNP22hy%2Bd9AoE56qssrhxUdu%2BSs9EwiqS7m8LGHCQ%40mail.gmail.com.

Re: [go-nuts] Race detector question

['Thomas Bushnell BSG' via golang-nuts]

Well, what the Go memory model says is this:

"The memory operations in each goroutine must correspond to a correct
sequential execution of that goroutine, given the values read from and
written to memory. That execution must be consistent with the sequenced
before relation, defined as the partial order requirements set out by the
Go language specification for Go's control flow constructs as well as the
order of evaluation for expressions."

What that means is, you follow the semantics of the language to determine
what a sequential "everything in order" execution would do, and you keep
track of the reads and writes which that does. The compiler can meet
Requirement One provided the "values read from and written to memory" by
"that goroutine" are the same, and they must be consistent with the
"sequenced before" relation that is described in the following sections of
the memory model.

The sequenced before relation established by atomics is this:

"The APIs in the sync/atomic package are collectively “atomic operations”
that can be used to synchronize the execution of different goroutines. If
the effect of an atomic operation A is observed by atomic operation B, then
A is synchronized before B. All the atomic operations executed in a program
behave as though executed in some sequentially consistent order."

This only applies if *both *A and B are atomic operations.

On Thu, Sep 15, 2022 at 11:10 AM robert engels 
wrote:

> Please see the “sequentially consistent” here
> https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync
>
> This is what most references to “happens before” imply. (and their example
> is my exact example).
>
> On Sep 15, 2022, at 10:08 AM, robert engels  wrote:
>
> This is not what “happens before” means - at least not in any other
> accepted concurrency designs.
>
> See my second example as to why.
>
> On Sep 15, 2022, at 10:02 AM, Thomas Bushnell BSG 
> wrote:
>
> Happens before works just fine with atomics. But in your example, x is not
> an atomic.
>
> Thomas
>
> On Thu, Sep 15, 2022 at 10:51 AM robert engels 
> wrote:
>
>> Yea, the race detector is broken… it fails on the following code:
>>
>> package main
>>
>> import (
>>"sync"
>>"sync/atomic"
>> )
>>
>> func main() {
>>
>>var x int32
>>var y int32
>>
>>w := sync.WaitGroup{}
>>w.Add(2)
>>
>>go func() {
>>   for {
>>  x = 1
>>  atomic.StoreInt32(, 1)
>>   }
>>   w.Done()
>>}()
>>go func() {
>>   for {
>>  if atomic.LoadInt32() == 1 {
>> if x != 1 {
>>panic("should not happen")
>> }
>>  }
>>   }
>>   w.Done()
>>}()
>>w.Wait()
>>
>> }
>>
>> The above code does not have a race, or Go doesn’t have “happens before”
>> semantics with its atomics.
>>
>>
>> On Sep 15, 2022, at 9:41 AM, Robert Engels  wrote:
>>
>> To clarify, if the atomic read of Y sees the updated Y then a subsequent
>> non-atomic read of X must see the updated X. This is a happens before
>> relationship.
>>
>> The question was if the race detector understands this - I know - why not
>> try it out…
>>
>> On Sep 15, 2022, at 9:39 AM, Robert Engels  wrote:
>>
>> 
>> I think it needs to see the updated X - which agrees with burak.
>>
>> Reading Z is race.
>>
>> On Sep 15, 2022, at 9:24 AM, burak serdar  wrote:
>>
>> 
>>
>> On Thu, Sep 15, 2022 at 8:03 AM 'Thomas Bushnell BSG' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> You cannot make that assumption. It's not about what the race detector
>>> can detect.
>>>
>>> Goroutine one:
>>>   Writes non-synchronized X
>>>   Writes atomic Y
>>>   Writes non-synchronized Z with the value of X+Y
>>>
>>> Goroutine two
>>>   Reads atomic Y and sees the new value
>>>
>>
>> The way I read the Go memory model, if Goroutine two sees the new value
>> of Y, non-synchronizes writes to X by Goroutine 2 happened before Y, and
>> thus, anything that happens after Y. This is based on:
>>
>> "If a synchronizing read-like memory operation r observes a synchronizing
>> write-like memory operation w (that is, if W(r) = w), then w is
>> synchronized before r."
>>
>> And:
>>
>> "The happens before relation is defined as the transitive closure of the
>> union of the se

Re: [go-nuts] Race detector question

['Thomas Bushnell BSG' via golang-nuts]

I cannot speak to "other accepted concurrency designs" here. Simply that Go
does not guarantee the operation you want it to, the memory model does not
actually imply that it does, and the last sentence of the memory model is
the most important one here: don't be clever.

On Thu, Sep 15, 2022 at 11:08 AM robert engels 
wrote:

> This is not what “happens before” means - at least not in any other
> accepted concurrency designs.
>
> See my second example as to why.
>
> On Sep 15, 2022, at 10:02 AM, Thomas Bushnell BSG 
> wrote:
>
> Happens before works just fine with atomics. But in your example, x is not
> an atomic.
>
> Thomas
>
> On Thu, Sep 15, 2022 at 10:51 AM robert engels 
> wrote:
>
>> Yea, the race detector is broken… it fails on the following code:
>>
>> package main
>>
>> import (
>>"sync"
>>"sync/atomic"
>> )
>>
>> func main() {
>>
>>var x int32
>>var y int32
>>
>>w := sync.WaitGroup{}
>>w.Add(2)
>>
>>go func() {
>>   for {
>>  x = 1
>>  atomic.StoreInt32(, 1)
>>   }
>>   w.Done()
>>}()
>>go func() {
>>   for {
>>  if atomic.LoadInt32() == 1 {
>> if x != 1 {
>>panic("should not happen")
>> }
>>  }
>>   }
>>   w.Done()
>>}()
>>w.Wait()
>>
>> }
>>
>> The above code does not have a race, or Go doesn’t have “happens before”
>> semantics with its atomics.
>>
>>
>> On Sep 15, 2022, at 9:41 AM, Robert Engels  wrote:
>>
>> To clarify, if the atomic read of Y sees the updated Y then a subsequent
>> non-atomic read of X must see the updated X. This is a happens before
>> relationship.
>>
>> The question was if the race detector understands this - I know - why not
>> try it out…
>>
>> On Sep 15, 2022, at 9:39 AM, Robert Engels  wrote:
>>
>> 
>> I think it needs to see the updated X - which agrees with burak.
>>
>> Reading Z is race.
>>
>> On Sep 15, 2022, at 9:24 AM, burak serdar  wrote:
>>
>> 
>>
>> On Thu, Sep 15, 2022 at 8:03 AM 'Thomas Bushnell BSG' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> You cannot make that assumption. It's not about what the race detector
>>> can detect.
>>>
>>> Goroutine one:
>>>   Writes non-synchronized X
>>>   Writes atomic Y
>>>   Writes non-synchronized Z with the value of X+Y
>>>
>>> Goroutine two
>>>   Reads atomic Y and sees the new value
>>>
>>
>> The way I read the Go memory model, if Goroutine two sees the new value
>> of Y, non-synchronizes writes to X by Goroutine 2 happened before Y, and
>> thus, anything that happens after Y. This is based on:
>>
>> "If a synchronizing read-like memory operation r observes a synchronizing
>> write-like memory operation w (that is, if W(r) = w), then w is
>> synchronized before r."
>>
>> And:
>>
>> "The happens before relation is defined as the transitive closure of the
>> union of the sequenced before and synchronized before relations."
>>
>> Because:
>>   * The writes to non-synchronized X are sequenced before the atomic
>> write to Y
>>   * The atomic read Y happened after atomic write to Y if it sees the new
>> value
>>   * non-synchronized reads from X happen after that
>>
>> So that should not be a race.
>>
>> Am I reading this correctly?
>>
>>
>>
>>>
>>> Can goroutine two now read non-synchronized X and assume it sees the new
>>> value written by one? No, it cannot. There is no "happens before" relation
>>> connecting the two writes performed by goroutine one. Requirement one does
>>> not establish such a relationship. It only establishes that Z will be
>>> written with the correct sum of X and Y. There must be *some *sequential
>>> order within the context of goroutine one that sees the correct value; the
>>> compiler is free to swap the order of the writes X and Y.
>>>
>>> If X were an atomic, then Requirement two would come into play. But
>>> because X and Z are not atomic, they play no role in Requirement two. Note
>>> that the description of atomic in the model says that writes to *atomic
>>> *values have the property you want. And since there is no before
>>> relationship 

Re: [go-nuts] Race detector question

['Thomas Bushnell BSG' via golang-nuts]

Happens before works just fine with atomics. But in your example, x is not
an atomic.

Thomas

On Thu, Sep 15, 2022 at 10:51 AM robert engels 
wrote:

> Yea, the race detector is broken… it fails on the following code:
>
> package main
>
> import (
>"sync"
>"sync/atomic"
> )
>
> func main() {
>
>var x int32
>var y int32
>
>w := sync.WaitGroup{}
>w.Add(2)
>
>go func() {
>   for {
>  x = 1
>  atomic.StoreInt32(, 1)
>   }
>   w.Done()
>}()
>go func() {
>   for {
>  if atomic.LoadInt32() == 1 {
> if x != 1 {
>panic("should not happen")
> }
>  }
>   }
>   w.Done()
>}()
>w.Wait()
>
> }
>
> The above code does not have a race, or Go doesn’t have “happens before”
> semantics with its atomics.
>
>
> On Sep 15, 2022, at 9:41 AM, Robert Engels  wrote:
>
> To clarify, if the atomic read of Y sees the updated Y then a subsequent
> non-atomic read of X must see the updated X. This is a happens before
> relationship.
>
> The question was if the race detector understands this - I know - why not
> try it out…
>
> On Sep 15, 2022, at 9:39 AM, Robert Engels  wrote:
>
> 
> I think it needs to see the updated X - which agrees with burak.
>
> Reading Z is race.
>
> On Sep 15, 2022, at 9:24 AM, burak serdar  wrote:
>
> 
>
> On Thu, Sep 15, 2022 at 8:03 AM 'Thomas Bushnell BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> You cannot make that assumption. It's not about what the race detector
>> can detect.
>>
>> Goroutine one:
>>   Writes non-synchronized X
>>   Writes atomic Y
>>   Writes non-synchronized Z with the value of X+Y
>>
>> Goroutine two
>>   Reads atomic Y and sees the new value
>>
>
> The way I read the Go memory model, if Goroutine two sees the new value of
> Y, non-synchronizes writes to X by Goroutine 2 happened before Y, and thus,
> anything that happens after Y. This is based on:
>
> "If a synchronizing read-like memory operation r observes a synchronizing
> write-like memory operation w (that is, if W(r) = w), then w is
> synchronized before r."
>
> And:
>
> "The happens before relation is defined as the transitive closure of the
> union of the sequenced before and synchronized before relations."
>
> Because:
>   * The writes to non-synchronized X are sequenced before the atomic write
> to Y
>   * The atomic read Y happened after atomic write to Y if it sees the new
> value
>   * non-synchronized reads from X happen after that
>
> So that should not be a race.
>
> Am I reading this correctly?
>
>
>
>>
>> Can goroutine two now read non-synchronized X and assume it sees the new
>> value written by one? No, it cannot. There is no "happens before" relation
>> connecting the two writes performed by goroutine one. Requirement one does
>> not establish such a relationship. It only establishes that Z will be
>> written with the correct sum of X and Y. There must be *some *sequential
>> order within the context of goroutine one that sees the correct value; the
>> compiler is free to swap the order of the writes X and Y.
>>
>> If X were an atomic, then Requirement two would come into play. But
>> because X and Z are not atomic, they play no role in Requirement two. Note
>> that the description of atomic in the model says that writes to *atomic 
>> *values
>> have the property you want. And since there is no before relationship
>> established by any of the following text, this synchronization cannot be
>> relied on.
>>
>> Now you're asking whether the race detector ensures the synchronization
>> property you're suggesting? The race detector doesn't ensure any
>> synchronization properties; it detects bugs.
>>
>> I think it is capable of detecting this one.
>>
>> Thomas
>>
>>
>>
>>
>> On Wed, Sep 14, 2022 at 11:01 PM robert engels 
>> wrote:
>>
>>> Hi,
>>>
>>> I am working on a new project, and the race detector is reporting a race.
>>>
>>> Essentially, the code is
>>>
>>> var S []int
>>>
>>> several go routines write new S values using a mutex
>>>
>>> go routine Y reads S without grabbing a lock (it reads it initially
>>> under lock)
>>>
>>> The semantics are such that Y can operate successfully with any valid
>>> value of S (e.g. could be stal

Re: [go-nuts] Race detector question

['Thomas Bushnell BSG' via golang-nuts]

You cannot make that assumption. It's not about what the race detector can
detect.

Goroutine one:
  Writes non-synchronized X
  Writes atomic Y
  Writes non-synchronized Z with the value of X+Y

Goroutine two
  Reads atomic Y and sees the new value

Can goroutine two now read non-synchronized X and assume it sees the new
value written by one? No, it cannot. There is no "happens before" relation
connecting the two writes performed by goroutine one. Requirement one does
not establish such a relationship. It only establishes that Z will be
written with the correct sum of X and Y. There must be *some *sequential
order within the context of goroutine one that sees the correct value; the
compiler is free to swap the order of the writes X and Y.

If X were an atomic, then Requirement two would come into play. But because
X and Z are not atomic, they play no role in Requirement two. Note that the
description of atomic in the model says that writes to *atomic *values have
the property you want. And since there is no before relationship
established by any of the following text, this synchronization cannot be
relied on.

Now you're asking whether the race detector ensures the synchronization
property you're suggesting? The race detector doesn't ensure any
synchronization properties; it detects bugs.

I think it is capable of detecting this one.

Thomas




On Wed, Sep 14, 2022 at 11:01 PM robert engels 
wrote:

> Hi,
>
> I am working on a new project, and the race detector is reporting a race.
>
> Essentially, the code is
>
> var S []int
>
> several go routines write new S values using a mutex
>
> go routine Y reads S without grabbing a lock (it reads it initially under
> lock)
>
> The semantics are such that Y can operate successfully with any valid
> value of S (e.g. could be stale). (essentially S is used with copy on write
> semantics)
>
> The race detector reports this as a race.
>
> I could change all reads of Y to use an atomic load, but I don’t think it
> should be necessary.
>
> Is there any way to perform “lazy loads” in Go?
>
> And a follow-up:
>
> Is the race detector smart enough so that if a routines write to several
> vars (v1…n)  and performs an atomic store to X, and another routine
> atomically reads X it can also non atomically read v1…n and it will see the
> stored values?
>
> This has been the long standing issue with the Go memory model and
> “happens before”… but how does the race detector report this?
>
> (Some background, the library functions fine under heavy concurrent stress
> tests - but the race detector says it is broken).
>
>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8EC74417-C4AD-4490-9231-6E869EE72D93%40ix.netcom.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtd%2BpaU_BNxXDrMAN9v71r-Qhm9LcXcN2fTtjD_6oWw-Q%40mail.gmail.com.

Re: [go-nuts] Is Go a security malware risk?

['Thomas Bushnell BSG' via golang-nuts]

This is not a problem that arises from *you *using Go; it's a problem
arising from the fact that *other *people are using Go to write malware,
and bad security techniques are unable to deal with it.

You could stop using Go entirely and it wouldn't change the dynamic. The
better course is not to rely on scanners of the sort the article describes.
Anti-virus was never a good strategy anyhow, and is in my opinion
dangerous. Tavis Ormandy has enjoyed a constant stream of cases where
running antivirus "protections" was actually the gateway to serious
exploits.

Behavior-based detection is a good technique to use.

On Mon, Aug 22, 2022 at 9:30 AM 'Gopher-Insane' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi
>
> So our security team has raised a concern with Go and malware. The link
> that was sent to me was
> https://securityboulevard.com/2021/09/behavior-based-detection-can-stop-exotic-malware/
> .
> I reached out to Bill Kennedy on Twitter who disagreed that Go was a
> problem. Said it was worth posting here to hear people's thoughts.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ed1966c2-675b-4030-911b-7fa618291985n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuvWNOvhBnQJc3Z5sNAwN9XF-KiLZO%2B6FSsvcFkDXqSig%40mail.gmail.com.

Re: [go-nuts] Go Mod SSH doesn't work

['Thomas Bushnell BSG' via golang-nuts]

I'm confused; while I haven't used that sort of setup, the documentation
does seem to address the case.

https://go.dev/ref/mod#module-proxy
https://go.dev/ref/mod#vcs
https://go.dev/ref/mod#private-modules

I can't tell from what you're saying whether you're using those facilities
or not, but that's where I'd look.

On Fri, Aug 5, 2022 at 9:22 AM Rich  wrote:

> Go modules have been frustrating working with internal sites that use
> ssh.  There is NO option to use HTTP. THere is no option to use a proxy. So
> I set up my go mod to contain
>
> go.mod file:
> require
> codecloud.web.mycompany.com/devgroup/mypackage.git v1.0.0
>
> .gitconfig file:
>  [url "ssh://g...@codecloud.web.mycompany.com/"]
> *insteadOf* = https://codecloud.web.mycompany.com/
>
> go env:
> go env -w GOPRIVATE=codecloud.web.att.com/*
> (I've tried the full path here and I get the same error)
>
> ERROR:
> go mod download codecloud.web.att.com/devgroup/mypackage
> go: codecloud.web.att.com/devgroup/mypackage.git@v1.0.0: reading
> codecloud.web.att.com/devgroup/mypackage.git/go.mod at revision v1.0.0:
> unknown revision v1.0.0
>
> I really don't get why this is so $#@! hard and not some simple setting in
> go.mod like this:
>
> require
> private git@ssh://codecloud.web.mycompany.com/devgroup/mypackage
> v1.0.0
>
> -- but it's broken, it doesn't work, and I am out of what to google next.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cf2ef966-3bc5-4e81-89be-c130c624786fn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtgZTS0KA_7wwq-ZQwVruN3202yRdtfHQ5BBp2ur93bKA%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Thomas Bushnell BSG' via golang-nuts]

Yes indeed! These constructions all give us *expressions *with many
consecutive stars. But they don't give us *types *with that. (and you can't
assign a *Number to a **Number, for example)

On Tue, Mar 15, 2022 at 11:50 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Tue, Mar 15, 2022 at 4:41 PM Thomas Bushnell BSG
>  wrote:
>
> > Not in the normal implementation it doesn't. Typically it might be:
> >
> > type element struct {
> >   value int
> >   next *element
> > }
> >
> > next is a pointer to an element, not a pointer to a pointer. That
> element contains within it a pointer, but next is not a pointer to a
> pointer. If it were, it would be declared with two stars.
>
> Although linked lists usually do contain a payload, as you note, I
> consider `type peano *peano` a payload-less linked list. Or a linked
> list with zero sized payload one could also say. And once a node
> contains zero bits of a payload, it contains only the link field. And
> a struct with a single field is another interesting case that can be
> abstracted out. Numbers 0 and 1 make many things much more interesting
> ;-)
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuzz1tMi2vT0oUmyyE8YA9Q31x054pXf_zY0XHRsLjQsw%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Thomas Bushnell BSG' via golang-nuts]

On Thu, Mar 10, 2022 at 4:31 AM Rob Pike  wrote:

> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com 
> wrote:
> >
> > Is this really how you want to be known?
>
> Sure, why not? It's a more interesting program than one might think.
>
> For a richer example of the foundational idea here, see the peano.go
> program in the test directory in the repo.
>

This is lovely. I'm thinking about the relation to other ways of defining
models of numerals.

For example, Church numerals are much more annoying (if logically simpler
in some sense); peano.go offers a trivial predecessor function which is
famously annoying for Church numerals.

Finite Von Neumann ordinals are very similar - we interpret  a Number as a
set of all the things which can be reached from it by applying *, and then
each number is the set of all smaller numerals in the right way. And
infinite chains of pointers map to ordinals exactly as we might want.
However this doesn't encode general sets; by definition it can only define
transitive sets, so it gets you ordinals, but only ordinals and not in the
larger universe.

The name "peano.go" also suggests to me that it's not quite PA that we're
modeling here so much as PA numerals what happens if we are working in
a space where the Numbers might be non-standard? The functions now don't
terminate, but because of Tennenbaum's Theorem, there might be very little
we can do to improve on that.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtXQoPbia9FK-0O5z7xP0McBYCodAaPPXcuSw9REL64aQ%40mail.gmail.com.

Re: [go-nuts] Pointer to a pointer

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 9, 2022 at 11:38 PM Jan Mercl <0xj...@gmail.com> wrote:

> A linked list, for example, consists of pointers to pointers to pointers...
>

Not in the normal implementation it doesn't. Typically it might be:

type element struct {
  value int
  next *element
}

next is a pointer to an element, not a pointer to a pointer. That element
contains *within it *a pointer, but next is not a pointer to a pointer. If
it were, it would be declared with two stars.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxv%2Bpk-KuxOJ-P%2BeVaDUCO1rj%3DwtXQAB%3DQHAU3twFc9mNQ%40mail.gmail.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

['Thomas Bushnell BSG' via golang-nuts]

On Fri, Jan 28, 2022 at 1:12 PM Rudolf Martincsek  wrote:

> > 2) Long variable names.
>
> Where I work (not in Go), writing comments is frowned upon. That includes
> "docblock" style comments. If a function needs to be documented, it means
> the implementation is too complex and must be broken apart to reduce
> cyclomatic or whatever perceived complexity. Also uncle bob told us that
> functions should never be longer than 2-3 lines of code, so it should be
> enough to look at the source code to see what it does. That's the general
> sentiment in my team.
> Comments are considered sign of "un"clean code.
>

I agree with the sentiment.

So we use long variable and function names to make the code self
> documenting. (Hint: it doesn't)
> Points 3,4,5 have similar roots, because in dynamic languages it was a
> trend many years ago. (ie: hungarian notation)
>

If you use a long variable name for every variable then you haven't helped
anything. You need to use long variable names for some variables and not
others.

Using a short variable name gives the subtext "this variable is
boiler-plate or not very important". This is good for method receivers,
loop indexes, and so forth. Almost always a single word will do. For
example:

for _, otter := ListRiverOtters("europe")

Calling this variable "otter" is great. Calling it "europeanRiverOtter" is
absurd - that's already there, obviously in the code. (And if the loop is
fifty lines long, then the problem isn't that the reader has forgotten what
kind of otter it is - the problem is that a loop of fifty lines long is too
long.)

Exported function and method names should generally read "completely", but
even then, they shouldn't go repeating type names and all the rest. The
standard library, as always, is a great guide.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuZe56ewuU7TjJj%3D4VS6YkyPeK1HE1wQdtsv3YJ4xiCfQ%40mail.gmail.com.

Re: [go-nuts] go text://protocol client?

['Thomas Bushnell BSG' via golang-nuts]

In *Ash Wednesday, *T. S. Eliot wrote the line "Lady, three white leopards
sat under a juniper tree in the cool of the day" When he was asked what
it meant, he aisd "It means, 'Lady, three white leopards sat under a
juniper tree in the cool of the day'"

I suspect if there were a better way to express what Eliot meant, he would
have chosen it.


On Sun, Apr 11, 2021 at 8:19 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I don't understand what you are trying to say. And I feel the fact that
> everyone talking about is either confused, or speaking in riddles instead
> of just plainly explaining what they are trying to say, speaks for itself.
>
> On Sun, Apr 11, 2021 at 1:55 PM Petite Abeille 
> wrote:
>
>>
>>
>> > On Apr 11, 2021, at 12:22, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>> >
>> > Everything around it certainly emits the air of pretentiousness that
>> the fine art market is famous for.
>>
>> There is a method to it:
>>
>>
>> https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Ftextprotocol.org%2Fcontact
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/3CE49F13-0142-4172-B967-1CC189354524%40gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH%2BQkdwicL3g_pHFz4Ncv_q-JdFEDsYWxczUBtUFHyr-w%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvLRPZ96FKoUj3kkJAtVhnG-7oCAqGaF5aR1-BN%3DukHdA%40mail.gmail.com.

Re: [go-nuts] text/template: Can't call method/function with 0 results.

['Thomas Bushnell BSG' via golang-nuts]

I find the current behavior clearer. What would you like a no-valued
function to insert in the template? Even if it was the zero value, that
could be the string-typed zero value, or the int-typed zero value, and so
forth.

It could be defined, but why not make it explicit if you want it to insert
nothing, and return the empty string?

On Fri, Apr 9, 2021 at 2:05 PM 'Johnny Jacobs' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hello all,
>
> Is there any reason you can't use a custom function with no return value
> in Go templates?
>
> You get a "Can't call method/function with 0 results." if you try to call
> such a function. FuncMap  
> requires
> functions to either return a value, or a value plus an error.
>
> Is there any reason, technical or otherwise, for these restrictions?
> Variables assignment and many Action clauses don't give back values, so it
> doesn't seem like it breaks convention.
>
> I might file an issue for this if nothing meaningful is brought up here.
>
> Best,
> Johnny
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/fdb52e84-0cea-4269-9016-cc1d5064cc5bn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvQrf4zbvuDih3_QHHXHnC9f2CuuyY%3DKPfjKOOkT6y8dQ%40mail.gmail.com.

Re: [go-nuts] Re: Update to generics proposal

['Thomas Bushnell BSG' via golang-nuts]

On Mon, Apr 5, 2021 at 9:04 PM yiyus  wrote:

> >  then I guess you mean that interface { MyInt } will accept any type
> > argument whose underlying type is the same as the underlying type of
> > MyInt. But that seems strange. There is no connection between MyInt
> > and MyInt2, except that they happen to be defined in terms of the same
> > underlying type.
>
> This is an excellent example. Indeed, I think that MyInt and MyInt2 should
> satisfy the same constraints (because they support exactly the same
> operations). Just like MyString and MyString2 will implement the Stringer
> interface if they happen to have a String method, and there is no way to
> constrain the types which can implement Stringer, I think that any type
> that can be used in a generic function like an int should satisfy
> interface{int} (and therefore also interface{MyInt} and interface{MyInt2}).
>

But they don't necessarily support exactly the same operations if they have
different methods. So maybe you mean that MyInt and MyInt2 should satisfy
the same constraints if they have the same underlying type and happen to
support the same method sets.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxsXpMcQTGVbSFvmS%2BhSsot8BT7_RVx1Pf_euhtdRuZSbw%40mail.gmail.com.

Re: [go-nuts] Re: A message from the CoC committee

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 24, 2021 at 3:18 PM ben...@gmail.com  wrote:

> I'm comparing to various legal systems, in which there is almost always
> the possibility of appeal, even for heinous crimes.
>

Not forever; and especially not in cases of abuse of process. For example,
the United States Supreme Court has an "in forma pauperis" procedure, where
you don't have to pay normal filing fees and the clerks will be very
lenient in whether a petition is in proper form etc. This provides access
to people with worthy cases and no representation. (If the case might be
accepted, the court makes sure to appoint representation, of course.) But
some people will abuse this, and after there have been too many groundless
petitions, the court will order that no further petitions are to be
accepted from that party (in civil cases) without being in correct form
with the filing fee paid. This basically puts a stop to it, because people
repeatedly filing groundless petitions generally don't care to pay $300 for
each one, together with the expense of duplicating forty bound copies of
the petition in the exacting format required.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvXYEorS-SQNQpUfQLft3UHFFZ2Hq7hqz-LNdsfLEAHRQ%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 17, 2021 at 8:33 AM mortdeus  wrote:

> Are you absolutely SURE you want to keep up the "your not welcome here"
> sign to people who literally find the message to be dangerous to the very
> people they claim to want to protect. Do we really want to encourage an
> opensource culture, where people will literally fork a language just
> because they don't like the political grandstanding going on because the
> people who are supposed to be the smartest people in the world are stupid
> enough to abandon liberal principles for wokeism?
>

I cannot speak for the Go authors, and I certainly cannot speak for Google,
but I can say for my part that I want a very clear and very bright sign
that racists are not welcome here, no matter how brilliantly they can write
computer programs.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxskL_ypkm7rthr1374dXBOFQDoG3Y2e3pdivz748sK2iw%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 17, 2021 at 8:22 AM mortdeus  wrote:

> Why do black lives matter more than Syrian lives?


Nobody said they do. The banner does not make any comparisons.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxv69ce9_wvX_1ZHqSU7dijYw1sbNNQnhyhfg%2BzCEs6oNw%40mail.gmail.com.

Re: [go-nuts] now that the election is over can we please remove the political ad for golang.org

['Thomas Bushnell BSG' via golang-nuts]

On Wed, Mar 17, 2021 at 8:22 AM mortdeus  wrote:

> The problem is that this inspires a political discussion that obviously
> should happen with your city council or your therapist. Not with gophers.
>

If you don't believe the political discussion should happen, then I would
recommend you resist the impulse to keep starting one.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxs-Zqamgx3E_py4LFwEktO%3D%2B-GyRiz_HR33T89cpv1emQ%40mail.gmail.com.

Re: [go-nuts] Code coverage in error cases when compared to other languages

['Thomas Bushnell BSG' via golang-nuts]

On Thu, Feb 4, 2021 at 4:35 PM Charles Hathaway 
wrote:

> Hey all,
>
> Thomas, I agree that the code you provide would benefit from unit tests,
> but I would like to focus my question on the very common case which simply
> throws the error without additional edge cases, such as the example given
> in the first email.
>

How do you know the code throws an error without testing to see that it
does, in fact, throw the error?

>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxu1_mfntShaN%2BduZJkQJ2ZWp3S8OKc_cs1K5ZUP1KQYbg%40mail.gmail.com.

Re: [go-nuts] Code coverage in error cases when compared to other languages

['Thomas Bushnell BSG' via golang-nuts]

IMO:

To give these things names, you have:

func Foo(...) ..., error {
  do things here...
  err := makeASubroutineCall(...)
  if err != nil {
return ..., err
  }
  do more things
}

And we suppose that makeASubroutineCall is already will tested and you know
it returns errors correctly. What is the point of a separate test of Foo
that makes sure that it returns the errors in the same cases?

Suppose Foo had a bug, and *stopped* returning that error. Wouldn't you
want to know? Especially since in many cases, not returning that error can
cause the rest to subtly seem right (perhaps makeASubroutineCall syncs
something to disk or kicks off some secondary process)...

Someone comes along, see, and your function becomes this:

func Foo(...) ..., error {
  do things here...
  if moonIsGreenCheese() {
err := makeASubroutineCall(...)
if err == nil && someCondition {
  err = someOtherError
}
if err != nil {
  return ..., err
}
  }
  do more things
}

And then another person comes along, and now it's this:

func Foo(...) ..., error {
  do things here...
  if moonIsGreenCheese() {
err := makeASubroutineCall(...)
if err == nil && someCondition {
  err = someOtherError
}
  } else if moonIsRedCheese() {
err := makeDifferentCall(...)
if err == nil && someOtherCondition {
  err = yetAnotherError
}
  }
  if err != nil {
return ..., err
  }
  do more things
}

Do you see the bug? Wouldn't you be glad if you had a test hanging around
to catch it?

On Thu, Jan 28, 2021 at 12:22 PM Szczepan Faber  wrote:

> Good question and useful discussion!
>
> What is Go community guidance on the _value_ of unit testing the `if err
> i= nil { return err }` idiom?
>
> To make the question a little more precise, let's consider the code
> snippet in the first email in this thread. Let's assume that I already have
> coverage for Foo() function happy path. Does it make sense to increase the
> code complexity (adding mocks) in order to achieve a higher test coverage
> (covering 'return err' line)? Would that additional coverage be useful
> given that 'return err' has no complexity and Go has the compiler/linter?
>
> Full disclosure: I'm biased to avoid unit testing those idioms by default.
> However, I'm very curious what's the community guidance, any
> documents/links I can read, any reference codebases?
>
> Thank you all!
>
> On Tuesday, December 8, 2020 at 4:39:05 AM UTC-6 axel.wa...@googlemail.com
> wrote:
>
>> Hi,
>>
>> On Tue, Dec 8, 2020 at 1:19 AM 'Charles Hathaway' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm looking for a good study/quantitative measure of how well-written Go
>>> code looks compared to other languages, such as Java, when it comes to test
>>> coverage. In particular, how handling errors may reduce the percentage of
>>> code covered by tests in Go relative to other languages.
>>>
>>> For example, in this code snippet:
>>>
>>> func Foo() error {
>>>   // do some stuff that actually adds value
>>>   if err := somelib.Bar(); err != nil {
>>> // triggering the error case in Bar is hard, i.e. requires
>>> simulating network troubles
>>> // or causing a file write to fail, but we don't do anything with
>>> result besides
>>> // return it. Testing it by adding an interface or wrapper isn't
>>> worth the effort
>>> // and the only impact is really reported test coverage.
>>> return err
>>>   }
>>>   // do more stuff
>>>   return nil
>>> }
>>>
>>> In Java, you would just add 'throws SomeException' to your method
>>> declaration. The effect is that we have one line in the Go code which is
>>> not easily covered by a test, whereas Java does not report that untested
>>> case because the return path is not visible in the code.
>>>
>>> The result is that otherwise equivalent code, we will report different
>>> code coverage values, with Go being slightly lower. I'm just looking for
>>> something written on that topic that can give us a notion of how much of a
>>> difference we might expect.
>>>
>>
>> I don't think there is as much of a difference as you think.
>>
>> You seem to be considering the `throws SomeException` to not impact
>> coverage - but that's not true. It's code you add for error handling and
>> that code is not hit, unless your test actually triggers that exception -
>> just as the code you add for error handling in Go isn't hit. So if you
>> don't count `throws SomeException` as code to be covered in java, you also
>> shouldn't count `if err i= nil { return err }` as code to be covered in Go.
>> So the semantic difference really comes down to a single `throws
>> SomeException` line being able to cover *multiple* branches with the same
>> exception type. It's a difference, but it should be small in practice.
>>
>> But really, I think what this comes down to is that line-coverage - or,
>> what's actually measured and then projected down to lines,
>> "instruction-coverage" - just isn't a super 

Re: [go-nuts] chan chan question

['Thomas Bushnell, BSG' via golang-nuts]

You can send any object you like across a channel of the appropriate type.
It sends the actual object (in this case, the channel) just as for an
integer, it sends the value, or for a map, the whole map.

errChan in the snippet you quote is an ordinary variable, and this is its
declaration (like any := case).

The type of requestChan is "<-chan chan error", so the thing you read off
it is "chan error", which means the type of errChan is a "chan error". (If
you read from errChan, you get an "error".)

On Mon, Jun 22, 2020 at 3:51 PM joe mcguckin 
wrote:

> I've been playing with this example code on the playground:
> https://play.golang.org/p/4l57Hqw9CLJ
>
> In func  'goroutine':
>
>select {
> case errChan := <-requestChan:
>
> How does this work? Does a channel send its name? Is 'errChan' some sort
> of special symbol?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/47d6fc3a-3f94-4661-b111-7c8fecb791d8o%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxsDkr0z1yUOSTLUXa8fN-8b4CD7YbYa7T3ChBMBT6PRqQ%40mail.gmail.com.

Re: [go-nuts] [generics] replace ()/(type ) with :[]

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo  wrote:

> Personally () parentheses seems like to be harder to read, too similar
> with function calls.
>
This is exactly why I like it. These are parameters, and should be thought
of just like other parameters in a function call.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxse-3Y1J201bTDS%3DGq33bqKKzdJ4AHABrqM5PDgrLwKcg%40mail.gmail.com.

Re: [go-nuts] Re: political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

On Tue, Jun 16, 2020 at 11:51 AM 'K Richard Pixley' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I do not agree with the Rust team.  I would prefer to make my technology
> decisions based on technological criterion.  But if you force me to make
> that decision based on your religion, on your specific brand of racism,
> then I will.
>

How does seeing the banner force you to stop using Go, even if you disagree
with its message?

> The only other alternative keeping with the code of conduct requires many
> other viewpoints and opinions to be expressed and that process alone would
> kill the utility of these forums turning them into yet another cesspool of
> religious disagreement.  We're not going to agree on these social issues.
> Agreement with any particular religion should not be required to
> participate nor should we be required to endure social abuse to do so
>
I don't see how that follows at all. First of all, I reject the notion that
an anti-racism banner creates a "cesspool" or even moves toward that even a
hair's breadth. But I don't understand why you think that if one cause is
advertised, all should be, or that if a non-abusive banner is present, then
abusive ones must be allowed too.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvcCKFi6_vRTkb6NNuv%3DQHvrNnMVEGMGfGox_PV04OXCw%40mail.gmail.com.

Re: [go-nuts] Re: political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

On Tue, Jun 16, 2020 at 10:41 AM Space A.  wrote:

>
> Are you saying you don't care about the rest of the World? This
> "situation" does not affect in any way many many gophers which have to deal
> with much more serious problems than you could imagine, on a daily basis.
> There are a lot of projects originating not from US, who are not trying to
> get you attention (and money) by putting on top political topics which they
> think are important and "affecting" everyone.
>
> That's pretty much easy to make this banner appear based on location. But
> if you insist, I can for sure update ABP filters with a couple of clicks.
> Never though I would have to do this on programming language main page.
>

I'm a bit confused.  You're correct that there are many worthy causes. I'm
confused about why that means this one shouldn't be supported, or that you
need to filter the notice out. How does that help the other worthy causes
you mention?

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxt5vSBwo6P2j5QvoVrxe30jUwpBqRDj1yGXMUEp2iYPLA%40mail.gmail.com.

Re: [go-nuts] political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

On Mon, Jun 15, 2020 at 9:27 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Mon, Jun 15, 2020 at 1:04 PM Jon Reiter  wrote:
>
>> Ok.  I live in Singapore.  Here is a statement from the Singapore Police
>> Force directly telling foreigners not to advocate for political causes or
>> risk being deported:
>> https://www.facebook.com/singaporepoliceforce/posts/10157358158324408
>> Is that concrete enough?
>>
>
You should probably take that into account when deciding on your actions. I
don't see how it means you have acquired a right to control other people's
actions, including those who run golang.org.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxsM3pPM4uAVugeNojLH_TkVbsOvz6q_qFZY%3D16a%2BuoG_Q%40mail.gmail.com.

Re: [go-nuts] political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

On Mon, Jun 15, 2020 at 12:30 PM Jon Reiter  wrote:

> It's not difficult to imagine banners like "free (some geographic place)"
> or "remember (someone or some date)" causing severe problems.   This banner
> differs only in degree of risk.  It increases the risk of a problem by some
> non-0 amount.
>
> This isn't about agreeing or disagreeing with the sentiments.  It's about
> not wanting to think about it when consulting technical documentation.
>

I don't want to think about people objecting to anti-racist fundraising,
and yet, here we are.

We all sometimes have to think about things we would rather not think about.

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuz4K_quHvkwBT0AcoouQkwBbLmUde_jqGrfRKC6m4XFw%40mail.gmail.com.

Re: [go-nuts] political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

The Equal Justice Initiative is not "a white person shouting from their
ivory tower".

On Mon, Jun 15, 2020 at 11:08 AM Robert Engels 
wrote:

> Maybe I am confusing the lower case black lives matter with the BLM org
> and platform - the former I agree with wholeheartedly. I can assure you
> that elements of the BLM platform are very fringe with little support in
> the minority community- specifically the defund the police - so having a
> white person shouting from their ivory tower about what’s right for these
> communities is laughable.
>
> On Jun 15, 2020, at 10:00 AM, 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> I'm saddened by all the snowflakes who can't handle a message they
> disagree with for a second, which is literally costing them exactly nothing.
>
> I'm also saddened by anyone who thinks the message itself is somehow
> objectionable. But I won't stop being an anti-racist just because some
> people are made uncomfortable by the fairly plain message that black lives
> matter.
>
> I'm disgusted by the dog whistles already blown on this thread.
>
> On Mon, Jun 15, 2020 at 10:27 AM Marvin Renich  wrote:
>
>> [Note To and CC]
>>
>> Please consider this a formal request for the Go Project Stewards to
>> review the website banners being discussed in this thread and to make a
>> determination that these banners are causing divisiveness in the Go
>> Community and have offended some, and that the banners' content is
>> inappropriate in this context.
>>
>> ...Marvin
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/20200615142640.2p37xxlnammendrr%40basil.wdw
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxu%3DYzT6mWA1EtThjf8rTjMfefGmfuzYw__0LwMou4W2wQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxu%3DYzT6mWA1EtThjf8rTjMfefGmfuzYw__0LwMou4W2wQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvyoxkt_WuXUncvq5FZeQp_61bMA85%3Dr%2BhNMumPqrzqcw%40mail.gmail.com.

Re: [go-nuts] political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

It might be helpful to know that the Equal Justice Initiative is strongly
supported by the Google.org foundation (
https://www.google.org/our-work/inclusion/equal-justice-initiative/) and
Google itself (
https://about.google/main/google-supports-equal-justice-initiative/), and
has been for years. Moreover, golang.org is itself supported by Google.

I would encourage those posting here to reflect on what their message might
say to African American contributors, in particular. Are they saying, "you
and your contributions are welcome", or are they saying something more
guarded and hesitant? And if so, why?

This is not a request for you to answer these questions here, but a request
for you to consider them yourself, and place their needs and interests
ahead of your own for a moment.

Thomas

On Mon, Jun 15, 2020 at 11:01 AM Thomas Bushnell, BSG 
wrote:

> Eric: It's not your list. You don't get to decide the policies of the list.
>
> On Sun, Jun 14, 2020 at 4:44 PM Eric S. Raymond  wrote:
>
>> Sam Whited :
>> > This is not a simple political issue, it is a personal human issue. It
>> > is a social issue. It is a justice issue.
>>
>> It is the injection of politics into a list where politics does not
>> belong.
>>
>> Kindly perform your virtue signalling elsewhere.
>> --
>> http://www.catb.org/~esr/;>Eric S. Raymond
>>
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/20200614204443.GE38032%40thyrsus.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxv9i7PRNYEyeijoQUfxFpm-LD%3DuYOShOHJHorj%3DaQg02Q%40mail.gmail.com.

Re: [go-nuts] political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

Eric: It's not your list. You don't get to decide the policies of the list.

On Sun, Jun 14, 2020 at 4:44 PM Eric S. Raymond  wrote:

> Sam Whited :
> > This is not a simple political issue, it is a personal human issue. It
> > is a social issue. It is a justice issue.
>
> It is the injection of politics into a list where politics does not belong.
>
> Kindly perform your virtue signalling elsewhere.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20200614204443.GE38032%40thyrsus.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvEkFhGU1g3oVxWO%2B5OmFJJebDNxzpJtwV3V4xwA3GURg%40mail.gmail.com.

Re: [go-nuts] political fundraising on golang.org!

['Thomas Bushnell, BSG' via golang-nuts]

I'm saddened by all the snowflakes who can't handle a message they disagree
with for a second, which is literally costing them exactly nothing.

I'm also saddened by anyone who thinks the message itself is somehow
objectionable. But I won't stop being an anti-racist just because some
people are made uncomfortable by the fairly plain message that black lives
matter.

I'm disgusted by the dog whistles already blown on this thread.

On Mon, Jun 15, 2020 at 10:27 AM Marvin Renich  wrote:

> [Note To and CC]
>
> Please consider this a formal request for the Go Project Stewards to
> review the website banners being discussed in this thread and to make a
> determination that these banners are causing divisiveness in the Go
> Community and have offended some, and that the banners' content is
> inappropriate in this context.
>
> ...Marvin
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20200615142640.2p37xxlnammendrr%40basil.wdw
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxu%3DYzT6mWA1EtThjf8rTjMfefGmfuzYw__0LwMou4W2wQ%40mail.gmail.com.

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

['Thomas Bushnell, BSG' via golang-nuts]

On Tue, Jun 9, 2020 at 11:23 AM Axel Wagner 
wrote:

> If you actually read OPs second E-Mail, they did and they didn't find it
> very clear. With that in mind, your message isn't very nice.
> (Also, not to be repetitive or anything: ~80% of the messages in this
> thread aren't actually concerned with what the complexity class *is*, but
> whether it matters)
>

The OP stopped participating in this exciting thread a long time ago. I
went and read through the code, and it seems pretty clear to me that it's
linear.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvQgnTKMM4FF4%3D4pspM-2nBJScNfCNinDv-2cNA09N%3DaQ%40mail.gmail.com.

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

['Thomas Bushnell, BSG' via golang-nuts]

I'm surprised none of you have taken all this time to just go read the
code, where it is clearly linear.

On Mon, Jun 8, 2020 at 9:12 PM Robert Engels  wrote:

> The OP specifically asked about compilation - in fact it’s in the title.
> You stated the compilation complexity is a DoS attack vector. I argued that
> it is not. That is all.
>
> On Jun 8, 2020, at 6:39 PM, Michael Jones  wrote:
>
> 
> Ray, only the discussion is exponential.
>
> On Mon, Jun 8, 2020 at 4:23 PM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> On Tue, Jun 9, 2020 at 12:48 AM Kurtis Rader 
>> wrote:
>>
>>> You're talking past each other. Robert is talking about limiting the
>>> length of the regex, not the string(s) evaluated by the regex.
>>>
>>
>> So am I. Note that e.g. a Code Search based on PCRE would break, even if
>> you limit *both* (or rather, any limit causing it to not break would result
>> in a completely useless piece of software).
>>
>> It should be possible to compile any regex of a reasonable length in a
>>> matter of microseconds. Regardless of whether the application of the regex
>>> to a given input is near linear (as in the case of the Go RE
>>> implementation) or exponential (as in the case of PCRE).
>>>
>>
>> This might be, where we talk past each other. I am using application as
>> an example for concrete numbers on how quickly exponential growth can
>> devolve. Of course, compilation of a regexp is fast - I am aware of that.
>> As it turns out, so is application of a regexp, if you use RE2 (or Go's
>> regexp package).
>>
>> What I take issue with are the statements that a) the question about the
>> complexity of compiling a regexp is irrelevant, because b) limiting the
>> algorithmic complexity of a function to counteract resource exhaustion
>> attacks "never works". RE2 is an excellent example to show that it does
>> work; it is carefully designed for linear complexity of the combined
>> compilation+matching of a regular expression.
>>
>> I'm not saying compiling a regular expression is an
>> exponential operation. I'm saying *if it was*, you could never reasonably
>> build something like Code Search. And we can use the fact that
>> *application* indeed is (in most engines) exponential in the combined input
>> length of expression+search text as a good basis to make that case.
>>
>> Of course we don't even need this fantasy world to make the case - after
>> all, saying "you can't build Code Search on PCRE, but you can on RE2" is
>> just as effective to prove the effectiveness of lowering algorithmic
>> complexity. It's just that OP's question was about compilation, so to talk
>> about why OP's question *is* relevant, we need to talk about what would
>> happen if the answer *wasn't* "it's linear".
>>
>> (I also genuinely don't understand the instinct to tell someone "why
>> would you care?" instead of telling them the answer, FWIW. Especially in a
>> case like this, where the answer is pretty simple)
>>
>> I'm pretty sure Robert is not arguing that the scaling problems of the
>>> regex implementation used by Perl, and too many others, can be mitigated
>>> simply by limiting the size of the string to be matched by the regex. If
>>> compiling a regex of reasonable length takes a non-negligible amount of
>>> time something is wrong.
>>>
>>> On Mon, Jun 8, 2020 at 3:22 PM Wojciech S. Czarnecki 
>>> wrote:
>>>
 Dnia 2020-06-08, o godz. 16:22:24
 Robert Engels  napisał(a):

 > it is trivial to limit the input size to something a user could input.

 With exponential complexity simple regex /(x+x+)+y/ blows up at input
 of 20 to 30 x-es.
 See: https://www.regular-expressions.info/catastrophic.html

 [Cut long explanations... Axel just posted most of what I was writing
 regarding trade-offs).

 Hope this helps,

 --
 Wojciech S. Czarnecki
  << ^oo^ >> OHIR-RIPE

 --
 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.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/golang-nuts/20200609002207.0a161adf%40xmint
 .

>>>
>>>
>>> --
>>> Kurtis Rader
>>> Caretaker of the exceptional canines Junior and Hank
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD9sKeHnqUAqB61y5Ts-U_f%2BctVAuS4BC0ae8phhhcp1iw%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> You 

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

['Thomas Bushnell, BSG' via golang-nuts]

On Mon, Jun 8, 2020 at 12:02 PM Axel Wagner 
wrote:

> On Mon, Jun 8, 2020 at 5:41 PM Thomas Bushnell, BSG 
> wrote:
>
>> The OP was about MustCompile, so I think it's clear they are not using
>> patterns passed in by external requests.
>>
>
> I don't think that's clear at all. How do you assume patterns from
> external sources can be matched, if not by compiling them?
>

"MustCompile is like Compile but panics if the expression cannot be parsed."

Thomas

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxufXoJsPGGXNFRZE0u3BdK4fQE%3DUXaJ11LRKqR7yoHQPA%40mail.gmail.com.

Re: [go-nuts] Re: what is the complexity of regexp.MustCompile()?

['Thomas Bushnell, BSG' via golang-nuts]

The OP was about MustCompile, so I think it's clear they are not using
patterns passed in by external requests.

On Mon, Jun 8, 2020 at 9:39 AM Robert Engels  wrote:

> I will claim it also doesn’t matter because you need external bounding
> anyway. Take a simple recursive directory listing. It is linear time
> bounded. Perform it on the top level on a sufficiently large directory and
> it might run for days consuming TBs of memory - easily becoming a DOS
> attack point. So regardless of the complexity you need other constraints
> anyway. Build those in at the request handling level to avoid DOS and UX
> issues.
>
> On Jun 8, 2020, at 8:27 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
>
>
> On Mon, Jun 8, 2020 at 3:19 PM Robert Engels 
> wrote:
>
>> I don’t see anything in the blog post referring to compilation time -
>> only runtime.
>>
>
> Sure. It's more a general point about you saying algorithmic complexity
> doesn't matter.
>
>
>> That being said I couldn’t review the graphs on my phone.
>>
>> Even still, to prevent DOS you can bound the compilation time as easily
>> as the runtime. If the lib doesn’t support it a simple fork to add an emit
>> with cancel out stage is all that is required.
>>
>
> Or, you know, make sure that it just has a guaranteed linear complexity.
> Then you don't even need "an emit with a cancel out stage".
>
> FTR, the whole issue here is a) someone asked about the algorithmic
> complexity of a stdlib function and b) people told them off saying the
> question isn't relevant. It is. You might not care (you should, IMO. But if
> you don't, that's on you). But it's definitely a relevant question to ask.
>
>
>>
>> On Jun 8, 2020, at 8:04 AM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> 
>> On Mon, Jun 8, 2020 at 2:53 PM Robert Engels 
>> wrote:
>>
>>> Attempting to prevent DOS attacks through algorithm efficiency never
>>> works
>>>
>>
>> Uhm, no, it totally does. Code Search is a real-world example of it
>> working at least once.
>>
>>
>>> you have to have resource throttling.
>>>
>>
>> Well, yes. But reigning in algorithmic complexity makes that far easier
>> and . If the cost of a query is proportional to its length, you can just
>> limit the length of queries to some gratuitous upper bound of reasonable.
>> But if it's quadratic or even exponential, that no longer works; if the
>> cost can be doubled just by adding a character to the query, you have to
>> restrict query length to a restrictive *lower* bound on reasonable - which
>> is inherently user-unfriendly.
>>
>> Really, I'd argue that algorithmic efficiency is the *only* real
>> effective measure against a cost DoS.
>>
>> I’m guessing the IO cost of pulling the text in this case has a better
>>> chance of creating a DOS than the regex compile.
>>>
>>
>> You might guess that, but you'd be wrong. Again, just look at the graph
>> on top of this blog post .
>> You get *minutes* of match-times for queries and corpus of a couple hundred
>> characters.
>>
>> Regexp-based code search couldn't exist without carefully designing
>> around algorithmic complexity.
>>
>>
>>>
>>> On Jun 8, 2020, at 7:40 AM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>> 
>>> Hi Amnon,
>>>
>>> if you read the blog posts I linked above, you'll find examples of where
>>> we care very much. RE2 was developed for enabling regular expression search
>>> in a large source code corpus. In that scenario, the attacker controls both
>>> the regular expression and (to a degree) the text to be searched. If they
>>> could craft expression/text pairs that are costly to compile and/or match,
>>> then this could enable a denial of service attack.
>>>
>>> So, guaranteeing linear compile- *and* match-times is actually pretty
>>> relevant for some real-world use-cases.
>>>
>>> Best,
>>>
>>> Axel
>>>
>>> On Mon, Jun 8, 2020 at 10:16 AM Amnon Baron Cohen 
>>> wrote:
>>>
 Should we care?

 Regular expressions are generally small.
 So the asymptotic complexity is not particularly important.

 But regular expressions are often used to search large amounts of input.

 regexp gives us fast, guaranteed linear search times.
 But we pay for this with slower compilation times.

 In my opinion, this is a good tradeoff.



 On Wednesday, 3 June 2020 18:07:12 UTC+1, Ray Pereda wrote:
>
> I believe that the complexity of regexp.MustCompile()
>  is linear based on this
> comment in the regexp package overview.
> 
>
> "The regexp implementation provided by this package is guaranteed to
> run in time linear in the size of the input"
>
>
> What is the complexity of regexp.MustCompile()
> ? Is it linear in the

Re: [go-nuts] Is this a safe way to block main thread but not main goroutine?

['Thomas Bushnell, BSG' via golang-nuts]

That seems needlessly complex. Why not just skip the weird init, and just
have main do a go to the thing you want to be not on the main thread, and
let the main thread do its thing?

On Wed, Apr 29, 2020 at 4:19 PM Akhil Indurti  wrote:

> I want to run the main goroutine on another thread besides the main
> thread, so that the main thread can block in darwin UI code. Is this a safe
> way to do it?
>
> package main
>
> /*
> #include 
> #include 
>
> void block() {
>   printf("Blocking main thread? %d\n", pthread_main_np());
>   while(1);
> }
> */
> import "C"
> import (
>   "fmt"
>   "runtime"
> )
>
> func init() {
>   runtime.LockOSThread()
>   go main()
>   C.block()
> }
>
> func main() {
>   fmt.Println("Blocking main goroutine?", C.pthread_main_np())
> }
>
>
> This prints out the following:
>
> $ go run threadtrick.go
> Blocking main thread? 1
> Blocking main goroutine? 0
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6b476ab1-c6b6-4f77-91d8-aba2dfbcc314%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuwEFCox%2B-dkYWL2oKsD%3D38OxRFNM%3DC%2B%2B7HHgGty2kGPw%40mail.gmail.com.

Re: [go-nuts] An important proposal will fail without your support

['Thomas Bushnell, BSG' via golang-nuts]

In C it's called _.

While it's not normally considered good Go style, you could use a "."
import of the package, and call the function G.

Then: "fmt.Println(G("message text at %t with %n bytes"), time, number)

Notice that (following C) the gettext lookup function is called with the
string, and not with extra arguments.

Seems fine to me. Needs no language changes.

On Tue, Mar 10, 2020 at 1:31 PM Jon Perryman  wrote:

> If proposal https://github.com/golang/go/issues/37292 fails, everyone
> will lose out on a great opportunity. API's can be greatly simplified.
> Writing pre-processors and GO generate don't completely meet our truly
> meeting our needs. Is the extra implementation work worth the effort? Do we
> live with mediocre solutions to avoid repetition? Why do we live with
> mediocre solutions because we don't have compile time logic? Please
> consider "like" of this proposal otherwise we will miss this great
> opportunity.
>
> There are many examples where compile time flexibility is important.
> Consider the adverse effect of GO limitations has had on the very important
> GNU GETTEXT( ) - native language support (multi-lingual messages and
> localization):
>
>- Documentation is 17 chapters ->
>https://www.gnu.org/software/gettext/manual/gettext.html
>- Big-o complexity o(n^2)!!!
>- It has several important utilities for maintaining translation
>catalogs.
>- Hundreds of developer's were involved in its design and
>Implementation. They came up with the best implementation considering they
>don't have a compile time language.
>- Use and maintenance is labor intensive and time consuming .
>
> fmt.Println( gettext( fmt.Sprintf("message text at %v with %v bytes", time
> .format( ), number) ) )
>
> When to implement Gettext( ) is a difficult decision and lots of work
> early in your project. As you can see, gettext( ) is a function call with
> the message to be translated. The message must contain everything to be
> translated. After determining the language and localization, gettext
> searches for a matching message translation rule in the language specific
> catalog. The rule is applied to the message and data needing localization
> is converted (e.g. dates, numbers, currency).
>
> fmt.Println( #gettext( "message text at %t with %n bytes", time, number )
> )
> or
> fmt.Println( #gettext( msgid="jon001", time, number ))
>
> Isn't this cleaner and easier to code. Just as important,  the big-o
> complexity goes to  o(n)!!! We could make this even easier by creating a
> #gettext.println( )
>
> You won't see the #gettext() function unless you are the maintainer of
> this functionality. Function #gettext( ) is small and easy to maintain. One
> possible implementation for #gettext( ) with this proposal gives you lots
> of flexibility and eliminates 90% of the code in the real GNU gettext( ).
>
> func #gettext( args Args ) {
> src := "gettext(" // call real gettext function
> current_positional_arg := 1
> if args.msgid != nil {// keyword argument "msgid" not specified
> src += args.msgid + " ,nil"
> } else {
> src += "nil, " + args.positional[1]
> current_positional_arg := 2
> }
> for ; current_positional_arg <= args.positional.length;
> current_positional_arg {
> arg = args.positional[current_positional_arg]
> if reflect.TypeOf(arg) == "time.Time" {
> src += ",gettext.TimeLocal(" + arg + ")"
> } else if reflect.TypeOf(arg) == "int" {
> src += ",gettext.Number(" + arg + ")"
> } else {
> src += "," + arg
> }
> }
> compiler.AddStatement(*,src)   // replaces the #gettext( ) with real
> code
> }
>
> This compiler called function replaces the #gettext( ... ) as follows:
>
> #gettext(msgid="jon001", number, time)
> would be replaced with
> gettext("jon001", nil, gettext.Number(number), gettext.TimeLocal(time) )
>
> The new gettext( ) is greatly simplified. Messages are now in a easily
> accessible GO module. There arel language specific message modules that are
> dynamically loaded as needed. E.g. en_jon.go where en is an English message
> module and jon is the first part of the message id (e.g. jon001). Gettext(
> ) gets the message rule 001 from en_jon.go and applies the rule to the
> message.
>
> It's important that the language specific message modules are simple to
> edit by language translators. It also needs to be as similar as possible to
> the GNU standard while having GO syntax.
>
> #msg( language=en, prefix=jon )   // english messages jon###
>
> //  translator-comments
> //  extracted-comments
> // reference…
> // flag…
> #msg(
> id=001,   // msg id jon001
> msgstr[0]="message text at %t with %n bytes",
> ...
> msgstr[N]="message text at %t with %n bytes"
> )
>
>
> //  translator-comments
> //  extracted-comments
> // reference…
> // flag…
> #msg(
> id=002, // message id jon002

Re: [go-nuts] Difference with function returning struct and function returning pointer to struct

['Thomas Bushnell, BSG' via golang-nuts]

You can only assign to something which is addressable in the sense of
https://golang.org/ref/spec#Address_operators.

That is: "either a variable, pointer indirection, or slice indexing
operation; or a field selector of an addressable struct operand; or an
array indexing operation of an addressable array."

You want "a field selector of an addressable struct operand", but the
return value of a function is not addressable (it's not a variable,
pointer, etc etc).

By contrast, in the case where your function returns a pointer, then the
struct is the result of a pointer indirection (so it's addressable) and the
field selection is thus addressable too.

Thomas




On Wed, Nov 20, 2019 at 5:41 PM Orson Cart 
wrote:

>
> I'm a newbie to Go having used C and C++ in the past and I'm puzzled about
> something I've just seen.
>
> In the following code getEmployee returns a pointer to a struct. The
> return value is then dereferenced. This code compiles and runs fine:
>
> package main
>
> type employee struct {
> ID   int
> name string
> }
>
> var dilbert employee
>
> func main() {
>
> getEmployee().name = "dilbert"
> }
>
> func getEmployee() *employee {
> return 
> }
>
> However if I modify getEmployee as follows, I get a compilation error:
>
> func getEmployee() employee {
> return dilbert
> }
>
> The error is: cannot assign to getEmployee().name
>
> I assume that it revolves around "assignability" but I'm struggling to
> understand why.
>
> Can anyone tell me why this is?
>
> TIA,
> Orson
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/aaead2ec-b5b8-48d0-80e5-5275eeb583c2%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxtP_WBOULA2VTb_-2QJn9YDYrX%2BWZpsZPzMndgsGy%3DaAQ%40mail.gmail.com.

Re: [go-nuts] Existing production-ready libraries for parallelizing HTTP requests?

['Thomas Bushnell, BSG' via golang-nuts]

I am of the opinion that a case like this is best handled by simply writing
the thing you want.

Concurrency limits are easily managed by using tokens to gate fetches. One
simple technique is to make a channel of struct{} with capacity equal to
the maximum number of concurrent connections you are allowed. You can
either fill it with things at startup, and then read from it before a
request and send back to the channel when done, or start with it empty and
send to it before a request and read back after. Either is equivalent.

I'm not sure the point of overall concurrency limits in general, but the
same thing works. It's unlikely to be a problem IMO for the size of job you
describe.

Retries are best done inside each fetch; wrap http.Get with the logic you
want. There is no one-size-fits all here. There is a public backoff library
available, but it's a bit complex and the code could easily be simpler if
you address exactly what you want directly.

For contexts, just use the http package's (*Request).WithContext method.
That accomplishes timeouts too.

On Mon, Aug 19, 2019 at 12:20 PM tom via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> tl;dr Do you of any libraries for parallelizing HTTP requests with
> per-server concurrency control and handling of retries?
>
> I'm writing a service that fetches many independent small binary blobs
> (map tiles) over HTTP from a several upstream servers and package them
> together in to a single archive. I want to parallelize the fetching of the
> small binary blobs. Currently there are O(10) upstream servers and O(1000)
> small binary blobs fetched from each.
>
> Making parallel HTTP requests in Go is trivially easy and is demonstrated
> in many Go tutorials and blog posts. However, I'm looking for a "production
> ready" library that supports:
> * Per upstream server concurrency limits.
> * Overall (across all upstream servers) concurrency limits.
> * Controllable retries with exponential backoff in the case of upstream
> server errors.
> * Timeouts for upstream requests.
> * context.Context support.
>
> This would seem to be a common enough task that I would expect to find an
> existing library that does all of the above. Existing Go web scrapers, e.g.
> colly , likely have this functionality internally
> but do not expose it in their API and are instead focused on crawling web
> pages.
>
> Do you know of any such library?
>
> Many thanks,
> Tom
>
> Confidentiality Notice:
> This electronic message and any attached documents contain confidential
> and privileged information and is for the sole use of the individual or
> entity to whom it is addressed. If you are not the addressee of this email,
> or the employee or agent responsible for delivering it to the addressee,
> you are hereby notified that any dissemination, distribution or copying of
> this transmission is strictly prohibited. If you receive this message in
> error, please notify the sender immediately by return e-mail or telephone
> and destroy the attached message (and all attached documents) immediately.
> Thank you for your cooperation.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/cfb138b2-88d4-46ee-9315-996389718bad%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxvjvAQU-R7PAeocEJ%3Dp9-k0MSqRL%2BtcL4XhXaXjV%3DUepw%40mail.gmail.com.

Re: [go-nuts] Re: Adding a timeout to a script interpreter (without leaking a goroutine)

['Thomas Bushnell, BSG' via golang-nuts]

plus you'd lose the ability to compute ackerman's function, which i'm doing
all the time

On Wed, May 29, 2019 at 7:35 AM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Tuesday, 21 May 2019 01:18:34 UTC-4, Ben Hoyt wrote:
>>
>> I'm looking at adding a timeout option to my GoAWK script interpreter...
>> Are there better / more performant ways to handle this?
>>
>
>
> Hi Ben, imposing resource bounds is a tricky problem. It's possible to do
> it in an interpreter implemented in C++, but it requires careful discipline
> throughout the implementation. It is essentially impossible to do in a
> target language whose variables are recycled by the garbage collector of
> the host language. Turing incompleteness of the target language (bounded
> recursion only) seems like it ought to help but in fact does not; a bounded
> program can still use all your memory and take ~forever.
>
> The only reliable way to impose bounds is to use the operating system. Put
> the untrusted code in a different process, impose a limit on its maximum
> memory size, and kill it if it hasn't finished by your deadline.
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b4182f6d-8a3c-41a2-9cb0-e9d3c7fb1780%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxuCGVtH3xBt6u4QZQc2YYOvU4d90bqRXdyxjYSoiF%3DttA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go if else syntax .. suggested replacement

['Thomas Bushnell, BSG' via golang-nuts]

I'm a big fan of the ternary operator in general. Maybe this is because I'm
an old timey Lisper. A lot of the things people see as "abuse" or "too
complex" are equally problems with || and &&.

This is also true for Jan's point: that ?: affects control flow by omitting
execution sometimes. It would be lovely to say that in an expression, the
subexpressions are always evaluated. But Go did the usual thing, declaring
that && and || proceed conditionally.

If x and y are booleans, in fact, then "a ? x : y" is identical to "(a &&
x) || (!a && y)". We have all see boolean spaghetti. At the same time, I
get sad whenever I see things like "if a { return x == y; } else { return
false; }".

I don't mind Go's choice, however. It's a pragmatic and sensible choice: a
bunch of people, for whatever reason, find && and || easy to reason about,
and ?: annoying. Making code transparent is an important goal, so if you
want to target those readers, avoid ?:. And a language like Go, designed to
facilitate making things easy to understand over maximum economy of
characters, sensibly omits ?:.

This fits with good Go style, which tends to avoid "else" more than a lot
of other languages, making ?: standout all the more, with it's mandatory
"else" clause. And, unlike && and ||, ?: works with all types, thus making
it more pervasive when used.

Frankly, I would have preferred the Pascal approach here, which is more in
line with what Jan says: decouple entirely control flow from syntax of
expressions, and stop the experiment of having expression syntax imply
control flow. That means that && and || might "short circuit" but also
might not, and you would not be able to assume anything about the order of
subexpression execution. But, at the same time, I have no quarrel with the
pragmatic decision for Go to define those exactly instead.




On Thu, Apr 25, 2019 at 3:15 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Thu, Apr 25, 2019 at 8:58 PM  wrote:
> >
> > Rob : how can it be abused if the compiler wont allow nested ? operators
> ??
>
> Rather easily. Just by fuzzilly mixing the otherwise purposely
> distinct syntax of expressions and control flow.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] What does "identifier...type" mean in a function definition?

['Thomas Bushnell, BSG' via golang-nuts]

"..." is called an ellipsis (plural ellipses).

The presence or absence of the space is unimportant; you're seeing the way
gofmt formats it, but the parser doesn't care.  Since period is not a
legitimate constituent of an identifier name, they scan in separate tokens
either way.

On Thu, Apr 25, 2019 at 3:35 PM Andrew Price  wrote:

> Hey folks,
>
> A colleague wrote this:
>
> func (l *Logger) log2StdFormatted(level string, msgOrFormatOrArg
>> interface{}, args... interface{}) (formatted string) {
>
>
> Note the position of the space *between* the ... and interface{}, not
> before the ...
>
> [btw does "..." have an easy-to-search-for name?]
>
> It compiles, I think, but what what does it mean? My braincell hurts.
>
> I 'corrected' this and now my colleague is complaining :(
>
> Andy
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Question regarding gob

['Thomas Bushnell, BSG' via golang-nuts]

I mean, everything except the things that are not pointers.

On Tue, Mar 26, 2019 at 2:45 PM Robert Engels  wrote:

> This is not really true. In Java everything is a pointer (reference) and
> has no problem with the semantics of passing a reference, it is built into
> the serialization. They may be in fact passed as a pointer (local rpc) or
> passed as a copy of the object graph, or something in between (custom).
>
> There is no reason Go can not achieve use the same paradigm.
>
> On Mar 26, 2019, at 11:48 AM, Michael Jones 
> wrote:
>
> To be clear here as educators, it is important to point out that exporting
> / persisting / sending a pointer is an awkward concept.
>
> The normal meanings of sending data beyond an executing program have no
> direct use for the pointer’s literal value; “the thing at location 12345 in
> the memory of a program that ran last year” is not much help.
>
> On the other hand, one might imagine pointers being like file names and
> then recreate both content and references during reading. The export format
> could persist all the typed, pointed to values in tables, and then for each
> pointer variable exported send instead advice like “put the address of the
> 456th element of the table for type C things in this pointer slot.”
>
> A persistent format supporting this way of recreating the semantics of
> pointers is very much like an archive format (Zip) with support for
> symbolic links. It is not particularly hard to implement, but it is a
> “heavyweight” approach. My sense is that the common desire in export tools
> is high speed and byte efficiency so it is natural that Gob and other
> mechanisms adopt the “pointers don’t make sense for export” argument.
>
> Michael
>
> On Tue, Mar 26, 2019 at 6:01 AM roger peppe  wrote:
>
>>
>>
>> On Mon, 25 Mar 2019 at 14:45, Glen Huang  wrote:
>>
>>> Thanks for the reply, Sameer.
>>>
>>> Being able to directly send go types is a really big plus for me, I
>>> wonder if I really want to use gob, are there any recommended rpc choices?
>>>
>>
>> Note that gob has at least one significant limitation when encoding Go
>> types - it doesn't know about pointers - in general it encodes a pointer by
>> omitting a field. So if you want to send a slice of a pointer type where
>> some elements can be nil, you're out of luck:
>> https://play.golang.org/p/ThVUT_M0hjR
>>
>> --
>> 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.
>>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] bytes.Buffer.ReadAt?

['Thomas Bushnell, BSG' via golang-nuts]

Notice the logic in (*bytes.Buffer).grow which will throw away already read
data, specifically in the case n <= c/2--m.

On Mon, Mar 25, 2019 at 9:57 AM fREW Schmidt  wrote:

> Oh thanks, I'll switch my code to reader, though as far as I can tell,
> bytes.Buffer doesn't discard already read data, it merely sets the
> (private) offset.  Maybe I just got luck though.
>
> Thanks again!
>
> On Mon, Mar 25, 2019 at 08:54:43AM +, roger peppe wrote:
> > The reason bytes.Buffer doesn't implement io.ReaderAt is that it doesn't
> > keep bytes in the buffer that have been read, so it's not possible to
> > implement that method.
> >
> > You can use bytes.Reader instead, which does implement io.ReaderAt and
> > io.Seeker.
> > To make a bytes.Reader from a bytes.Buffer, you can do
> > `bytes.NewReader(buf.Bytes())`.
> >
> >   hope this helps,
> > rog.
> >
> > On Mon, 25 Mar 2019 at 06:06,  wrote:
> >
> > > Is there a reason I shouldn't submit a PR for bytes.Buffer.ReadAt?  It
> > > would at least help for some in memory tests.
> > >
> > > --
> > > Thanks,
> > > fREW
> > >
> > > --
> > > 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.
> > >
>
> --
> fREW Schmidt
> https://blog.afoolishmanifesto.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Fri, Jan 11, 2019 at 9:33 AM Eric S. Raymond  wrote:

> Thomas Bushnell, BSG :
> > Suppose it has a way, however. Now you have Go code which will have a
> > bounds fault instead of a data leak. That's better, I suppose - the
> > resulting bug is now "the server crashes" instead of "the server maybe
> > leaks a key". This is an improvement, but a packet-of-death across a
> widely
> > used library this puts the world in a not dissimilar position in terms of
> > the level of panic and rapid response everybody needs.
>
> The difference is trhat an overt bug will elicit a fast fix.
>

Was the Heartbleed fix particularly delayed? It seemed to be to be
all-hands-on-deck.

Also, this isn't part of your argument in the past; I would encourage you
to make it explicitly, rather than treating it as a matter of "by
transpiling we'll eliminate this category of security flaw". If the story
is actually "we'll make the bugs more visible and people will panic sooner,
resulting in a faster fix", that's a different argument, and I'd encourage
making it explicitly instead of implicitly.

Thomas
-- 

memegen delenda est

-- 
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: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jan 10, 2019 at 10:49 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Thu, Jan 10, 2019 at 7:39 PM Thomas Bushnell, BSG 
> wrote:
>
>>
>>> The server crashes - that's how we handle "any other exception", as a
>> rule.
>>
>>
> I write Erlang for a living. We don't crash a server, ever, on a failure.
> Unless the failure is persistent :)
>

Sorry, Eric was talking about Go, not just "something". There may be other
choices that would solve the problem where Go would not.

I think the paper you linked is exciting, and actually suggests that the
hard work which needs to be done will solve the problem without a change of
language. This fits my intuition: the things necessary to take advantage of
type safety can only be automatically used with the same kind of proof work
you need to do to establish the code was fine to begin with.

Thomas
-- 

memegen delenda est

-- 
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: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

>
>
> * Even if we did this, the bug only turns into a packet of death. A packet
>> of death on this scale is of almost the same level of annoyance and chaos.
>> (Witness this week's firestorm about an email packet of death on some Cisco
>> something or other.)
>>
>>
> I did address this. If each request is bounds checked and memory isolated,
> then a failure is just an exception of some kind and we handle this as we
> would any other exception. You could also just fork the process for each
> incoming request and obtain the same semantics.
>

The server crashes - that's how we handle "any other exception", as a rule.

That's a lot of work to convert "leaking session keys" into "crashes the
server".

Especially since you turn "maybe leaks a session key on repeated tries"
into "crashes the server immediately with a single packet". Maybe the
result actually makes things worse. :)

I don't know what you mean by "just fork the process". First, if you're
transpiling into Go, that's not a good strategy. Second, are you suggesting
the transpiler would automatically rewrite the request handling loop to
avoid the harm of crashes?

Thomas
-- 

memegen delenda est

-- 
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: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Thu, Jan 10, 2019 at 8:50 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>>
>> I'm curious about why transpilation would have significantly mitigated
>> the Heartbleed bug.
>>
>>
> Heartbleed is a bug which relies on two things:
>
> - Failure to do proper bounds checking
> - Allocation of a buffer which is not initialized to some zero-value, and
> which straddles memory it shouldn't.
>
> Many programming languages are constructed such that they address both of
> the above problems at the semantics level, and thus they avoid the really
> dangerous part of the bug, which is the leak of information, downgrading
> the bug to a denial of service attack, or even also mitigating that part of
> the bug. Array access is checked against the arrays bounds, and buffer
> allocated memory is properly 0-initialized before use.
>

I'm not sure the second one here is right. Heartbleed does not depend on
unitialized memory as far as I can tell. It works to copy whatever lies
after the incoming request buffer back to the attacker. It happens that in
the actual openssl code the thing it's copying is a reused buffer that
might have stuff in it (IIRC), but that's not essential to the operation of
the bug. If it were an exactly sized buffer the same shape of problem would
occur.

I don't think you responded to my email very successfully.

You left unaddressed:
* How would this magical translation going to occur, given the actual code
of openssl? The obvious *human *translation is to allocate a request
buffer, and then use the encoding/binary package to pull values. The
attempt to read indexes greater than the size of the buffer would fault.
But I don't see a way to take code like openssl and automatically make it
use encoding/binary. The only clear way I can see to do it *automatically *is
to use unsafe.Pointer, which simply turns off all the bounds checking you
wanted.

* Even if we did this, the bug only turns into a packet of death. A packet
of death on this scale is of almost the same level of annoyance and chaos.
(Witness this week's firestorm about an email packet of death on some Cisco
something or other.)

Thomas

-- 

memegen delenda est

-- 
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: Wuffs: a new, memory-safe programming language

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Jan 9, 2019 at 10:07 AM Eric S. Raymond  wrote:

> > Reasonable people can disagree, but I favor rewriting over
> > transpilation, for draining that swamp.
>
> The problem is that in general nobody *does* rewrite old
> infrastructure code.  It tends to work just well enough to fester in
> place for a long time, and then you get shocks like the Heartbleed
> bug.  It is my aim to head off that sort of thing in the future.
>

I'm curious about why transpilation would have significantly mitigated the
Heartbleed bug.

It sounds as though the idea is a mass transpilation of old libraries, but
that's going to require more than just a library. Suppose openssl had been
transpiled into Go well in advance of the attack. This isn't going to stop
old C code from linking against the old library, and it's all going to stay
there. So you'd need to transpile all the programs which use the library
too, it seems to me, and release them into all the distros, and have them
all agree. That seems a rather high hurdle. You could, of course, just
release a transpiled version of a bunch of libraries, but now my guess is
there's two things to maintain instead of one, and nothing ever makes the
old one go away.

But suppose that hurdle is fixed, and think about the specific Heartbleed
bug. The bug involved a mistake in unmarshalling a particular type of SSL
packet, trusting a length field from an inbound packet; the fix was to see
the length and discard the incoming packet if it was bogusly long.

The specific problem was that if the length field was bogusly big, the code
would do the echo reply with the next N bytes after the incoming packet in
memory, which could include whatever was in memory after the packet.

The transpiler is going to be amazing clever to even get this code right.
It's code which bounces around *char manually unmarshalling a piece of
structured data. Consider this: hbtype = *p++.

What's that going to be? Is it going to be turned into pointer arithmetic
using the unsafe package? Now you'll just get the same bug again. Obviously
new Go code would stick the packet in a []byte, and then use the facilities
of the binary package to read the bits, and the attempt to read past the
end of the slice will fail. But how is a transpiler going to automatically
take the C code of openssl and do that?

Suppose it has a way, however. Now you have Go code which will have a
bounds fault instead of a data leak. That's better, I suppose - the
resulting bug is now "the server crashes" instead of "the server maybe
leaks a key". This is an improvement, but a packet-of-death across a widely
used library this puts the world in a not dissimilar position in terms of
the level of panic and rapid response everybody needs.

So I'm not quite seeing it. It seems like a great idea from the outside
("hey, we could turn all these programs into memory-safe Go programs,
automatically, what a win!") but in practice, I'm not sure I see such a
transpiler actually working in a way that would achieve the result - and
the end is to preserve a profound denial of service attack anyway.

Thomas

-- 

memegen delenda est

-- 
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: why does go reverse the order of name and type? "i int" vs "int i"

['Thomas Bushnell, BSG' via golang-nuts]

On Fri, Sep 21, 2018 at 11:07 AM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> in programming languages putting the type first basically only appears in
> C and its (ill-born) children.
>

Like that's literally wrong. I prefer Go's order, which borrows from Pascal.

But C's order is the same as Algol's, which is the same as FORTRAN's.

Go's and Pascal's order is, however, the same as COBOL.

Thomas

-- 
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: I am not in favor of generics.

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Sep 19, 2018 at 4:04 PM robert engels  wrote:

>
> The opinion that well, since there is no implements I can define my own
> interface, and pass some stdlib struct that I can’t control as an
> “implementor” is hogwash. Because you also don’t control this code, the API
> is free to change - breaking your code. This is why the “backwards
> implements” is a bad idea.
>

I have experience in a millions-of-lines connected code base which uses
exactly the strategy that you say can't work. I can confirm that it does
work if you use it correctly.

-- 
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: I am not in favor of generics.

['Thomas Bushnell, BSG' via golang-nuts]

That's a different case than one which "implements" addresses. You don't
need "implements" to address that problem, if you think it's a problem.

Adding "implements" doesn't help. I understand there are people who think
adding generics might help, but that's a different thing.

On Wed, Sep 19, 2018 at 4:04 PM robert engels  wrote:

> That is not true. Often, due to lack of generics things are passed as
> interface{} or a sub interface, and then type checked/casted in the method.
> When you refactor you will get no warnings that X no longer meets the
> contract. You have no obvious way either by looking at the code to know
> which interfaces a developer needs (or wants it) to implement. Things will
> fail at runtime,
>
> People state this is a plus - yes it is - for small easily
> contained/understood systems. As the application grows larger, this is a
> real bottleneck to productivity.
>
> Having ‘implements’ does nothing to harm the productivity - not having it
> hurts.
>
> The opinion that well, since there is no implements I can define my own
> interface, and pass some stdlib struct that I can’t control as an
> “implementor” is hogwash. Because you also don’t control this code, the API
> is free to change - breaking your code. This is why the “backwards
> implements” is a bad idea.
>
> Having implements is the easiest to understand large systems - if you use
> interface based design, you can get a full mental picture of the system,
> then by looking at implementors you can determine the concrete options
> (performance, capabilities, etc.)
>
> Try working with any dynamic language that has duck typing - it is
> impossible to refactor. Don’t take my word for it, just read any of the
> thousands of blog posts covering it.
>
> Go is no different.
>
> Go was designed to replace scripting tools, and C tools (usually systems
> level). It was not designed for large enterprise applications, and that is
> why it falls down in many places. It doesn’t mean it isn’t GREAT for what
> it was designed to do, and better than Java in many (most) of these cases.
> Large enterprise apps, no way.
>
>
> On Sep 19, 2018, at 8:39 AM, Thomas Bushnell, BSG 
> wrote:
>
> Huh? Type safety is still checked by the compiler. Implements does nothing
> except put a road-block in the way and prohibit you from making an
> interface that some other package happens to implement.
>
> On Wed, Sep 19, 2018 at 1:40 PM Robert Engels 
> wrote:
>
>> Go not having implements is a big problem when refactoring large Go
>> systems especially because it doesn’t have generics - all type safety is
>> gone and you fly by the seat of your pants.
>>
>> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki 
>> wrote:
>>
>> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
>> >
>> > The **stated** goal for adding some kind of generics to Go is
>> > and always was "how to not repeat writing same code just for a type".
>> >
>> > Now above practical goal, in minds of many, somewhat morphed
>> > to "Yeah, lets have real true generics so we can write/reuse
>> > smart and clever code we once upon a time wrote for c++/java".
>> > "So we need a way of expressing generic data in terms of other
>> > generic data then use abstract alghoritm on that".
>> > (Yep, team's proposal use: "in terms of operations")
>> >
>> > It now poisons all the proposals I've seen with syntax that
>> > forces **user** of the code to **repeat** at the **call site**
>> > type identifier for the sake of "code instantiation".
>> >
>> > Why? I think that's a mark of "one proper way for doing generics" burnt
>> > on the popular mindset. As hard to overcome as notion that one needs
>> > 'implements/implementing' to use interfaces.
>> >
>> > Does Go2 should have "implements" keyword added too?
>> > `type mytype struct{...} : implements io.Writer, ..., ...`
>> >
>> > What?! "Compiler knows whether your type satisfies an interface"
>> >
>> > Yeah, and at the call site compiler **does know** the parameter
>> > type too. This is the CGG basis.
>> >
>> >
>> > 1. Find a way to write "some Go code" that is suitable for set of
>> > types that have "something" in common.
>> >
>> > 2. Find a way to describe the set via the "something common"
>> > that implementation for said set will use on objects of matching types.
>> >
>> > 3. It **MUST** read as Go: no instantiation at call site.
>> >
>> >
>> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
>> > mhhc...@gmail.com wrote:
>> >
>> >> I was referring to this code
>> >>
>> >> func (x type []K) Sum() (r type K) {
>> >> }
>> >>
>> >
>> >> I did not understand how "// For var x []AnyType. ANY. " relates to
>> >> previous code.
>> >
>> > Previous code example was specific to `big.Int` type. Next I gave
>> > a really generic usage example via the constraint that already is
>> > described in CGG proposal: "type with given method implemented".
>> >
>> > With that constraint func Sum can be called on _any_ type that has
>> > a method (*T) Add(T,T). And 

Re: [go-nuts] Re: I am not in favor of generics.

['Thomas Bushnell, BSG' via golang-nuts]

Huh? Type safety is still checked by the compiler. Implements does nothing
except put a road-block in the way and prohibit you from making an
interface that some other package happens to implement.

On Wed, Sep 19, 2018 at 1:40 PM Robert Engels  wrote:

> Go not having implements is a big problem when refactoring large Go
> systems especially because it doesn’t have generics - all type safety is
> gone and you fly by the seat of your pants.
>
> On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki 
> wrote:
>
> >> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
> >
> > The **stated** goal for adding some kind of generics to Go is
> > and always was "how to not repeat writing same code just for a type".
> >
> > Now above practical goal, in minds of many, somewhat morphed
> > to "Yeah, lets have real true generics so we can write/reuse
> > smart and clever code we once upon a time wrote for c++/java".
> > "So we need a way of expressing generic data in terms of other
> > generic data then use abstract alghoritm on that".
> > (Yep, team's proposal use: "in terms of operations")
> >
> > It now poisons all the proposals I've seen with syntax that
> > forces **user** of the code to **repeat** at the **call site**
> > type identifier for the sake of "code instantiation".
> >
> > Why? I think that's a mark of "one proper way for doing generics" burnt
> > on the popular mindset. As hard to overcome as notion that one needs
> > 'implements/implementing' to use interfaces.
> >
> > Does Go2 should have "implements" keyword added too?
> > `type mytype struct{...} : implements io.Writer, ..., ...`
> >
> > What?! "Compiler knows whether your type satisfies an interface"
> >
> > Yeah, and at the call site compiler **does know** the parameter
> > type too. This is the CGG basis.
> >
> >
> > 1. Find a way to write "some Go code" that is suitable for set of
> > types that have "something" in common.
> >
> > 2. Find a way to describe the set via the "something common"
> > that implementation for said set will use on objects of matching types.
> >
> > 3. It **MUST** read as Go: no instantiation at call site.
> >
> >
> > On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> > mhhc...@gmail.com wrote:
> >
> >> I was referring to this code
> >>
> >> func (x type []K) Sum() (r type K) {
> >> }
> >>
> >
> >> I did not understand how "// For var x []AnyType. ANY. " relates to
> >> previous code.
> >
> > Previous code example was specific to `big.Int` type. Next I gave
> > a really generic usage example via the constraint that already is
> > described in CGG proposal: "type with given method implemented".
> >
> > With that constraint func Sum can be called on _any_ type that has
> > a method (*T) Add(T,T). And someone writing new code needs not to
> > change generic lib (as imputed), but she needs to provide for her
> > non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
> >
> >> for your question about the rune, i guess it d be like this
> > [...]
> >> Consider Z,K as virtual types to be inferred from the call site.
> > Progress! As to inferred :)
> >
> > But I wanted return to be a string with sum of runes from all
> > input strings :) Leave it.
> >
> > In CGG such specialization takes place in a single to find and simple
> > to **read** 'case' code. The proposal's example Sum already has a single
> > piece of code that will be **reused** for all numerical types that user
> > **might** declare off builtin. With only two for type cases CGG's generic
> > Sum spans all types with numerical base and all types that provide their
> own
> > "me plus operator". With one case more it allows for set of types that
> have
> > "plus me operator". Code that can and will run for multitude of user
> types.
> >
> > Yet I still hear stubborn "not reusable!, not reusable! not generic!".
> >
> >> In regards to Russ Cox proposal this code is missing
> >> their explicitly declared contracts and the function instances
> declaration.
> >> On the other hand, this is so much more readable *to me*.
> >
> > The "real true generics" proposals are readable to people who took the
> > time and the training to accommodate to such List>
> > syntactical mess. But it is **against** Go philosophy of "readability
> first".
> > It excludes the legion who finds mental instantiations cumbersome at
> > reading time. It shifts their thought from "what this will do" to "in
> what
> > shape it will be".
> >
> >
> >> maybe it looks likes c++, i did not think it was a concern
> >> as long as it respected desired behaviors of good error reporting,
> >
> > It IS a MAIN concern. In fact it is a concern that the Go
> > team explicitly stated as a reason why Go1 is generics free.
> >
> >> good readability,
> > It has **no** readability for all but c++/java conditioned
> > and is an inexhaustible source of confusion in other languages
> >
> >> ease of usage.
> > leading to ubiquitous C in java/c++ application of generic libs.
> >
> >> speed of compilation,
> > 

Re: [go-nuts] Re: I am not in favor of generics.

['Thomas Bushnell, BSG' via golang-nuts]

On Tue, Sep 18, 2018 at 1:04 PM  wrote:

> It would be nice, for example, to have a full range of collection types in
> the standard library without the need to use interface{}, type assertions
> and the performance overhead of 'boxing'.
>

>From the earliest days of Object Oriented Programming, the idea of abstract
data types and generic implementations of container classes has stood out
as the one (and virtually only) win for this strategy.

So let's first notice the failure: numeric types. It seems like numbers,
which fit nicely into set-theoretic classes, should be a great use of
Object Oriented structure, but as soon as you realize that the addition
operation needs to inherit from *two *separate classes a problem happens.
Smalltalk coped by having a global namespace of "priorities" for numbers,
and each numeric operation promoted the receiver or the argument as
necessary, with all kinds of really annoying manual work of just the sort
that dynamic dispatch was supposed to make unnecessary.

So Lisp had generic functions which could genuinely parameterize on the
types of more than one argument, but that still produces a disaster; to
implement addition when you have N different types requires writing
N-squared little functions. This leads to the code bloat we are familiar
with in C++ - but quadratically worse.

So numbers fail. Nobody's got a way that *actually *works. What about
containers? Also a fail. Why? Because *the implementation depends on the
use.*

A brilliant example of this was a proposed spreadsheet design. Having
noticed that X provides output windows, which can be independently moved
and updated, we'll just implement a spreadsheet by creating ten thousand
little X windows, each backed by a separate Unix process, and responsible
for displaying their value and communicating across the X server to find
the values of cells they depend on. And the server's refresh logic will
prevent unnecessary computation! Brilliant! And nothing in the
documentation of the X protocol says, "oh, by the way, that would be an
idiotic strategy".

This happens *everywhere. *We have experience that very simple types don't
require more: hash tables, arrays, pairs. But for fancy container classes?
If you want a "set" type and hash tables aren't for you, that's because
hash tables don't support operations like union and intersection. But guess
what: every implementation of union and intersection makes assumptions
about the expected use, such that misuse will result in something which is
mathematically appropriate, but a computational disaster. *There is no
generic implementation of set theoretic union and intersection which works
for all users as well as hash tables currently work for all users.*

So yes, you can implement collection classes with generics. But so what?
You don't ever want to use them. Either performance matters, and the
generic implementation will be unacceptable to anyone who isn't lucky, or
performance doesn't matter and you don't need a sophisticated collection
class at all. (Or you're in the small well-known set of data types that we
are confident *can *be implemented generically - but this is a small and
static set, and does not require general generics as part of the language.)

Thomas

-- 
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] Reference to type satisfying a specified interface

['Thomas Bushnell, BSG' via golang-nuts]

Basically you almost never want pointer-to-interface in practice.

The temptation is to have a struct which satisfies your interface, and then
you end up with thinking you want pointer-to-interface.

Instead, make pointer-to-struct satisfy the interface, and then you don't
need pointer-to-interface any more.

On Thu, Aug 30, 2018 at 10:34 AM Eric Raymond  wrote:

>
>
> On Thursday, August 30, 2018 at 1:14:25 PM UTC-4, Jan Mercl wrote:
>
>> On Thu, Aug 30, 2018, 18:57 Eric Raymond  wrote:
>>
>>> I'm trying to translate this to Go in a type-safe way. To do this, I
>>> need to be able to write two declarations: "Slice of pointers to objects
>>> satisfying the Event interface"
>>>
>>
>> []*Event, but quite probably []Event is what is really needed.
>>
>> and "map of string keys to pointers to objects satisfying the Event
>>> interface".
>>>
>>
>> map[string]*Event, but once again, my bet is on map[string]Event.
>>
>> My attempts so far have yielded very cryptic error messages and no
>>> success.
>>>
>>
>> It would probably help your case if you could provide some self-contained
>> example reproducing the errors and post a link to the Go Playground.
>>
>
> That's hard.  The structures are intertwingled parts of ab only partly
> translated 14KLOC program  But I can isolate some key declarations.  If
> Event is my interface type, and I write
>
> events []Event
> _mark_to_object  map[string]*Event
>
> as member declarations in the Repository class, and b is a pointer to a
> just-allocated instance of a Blob object satisfying the Event interface,
> and  I write this
>
>  b.repo._mark_to_object[mark] = b
>
> I get this message:
>
> cannot use b (type *Blob) as type *Event in assignment:
> *Event is pointer to interface, not interface
>
> Note that the map values really do need to be pointers, because I need the
> map to refer to the mutable data in the event list, not a local copy of it
> in the map.  What's stumping me is how to communicate this to the compiler.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Global variable initialized in init() not working in main()

['Thomas Bushnell, BSG' via golang-nuts]

Your init is closing the file before returning, so at that point all the
writes are failing. If you check the error you receive from logger.Print
you should see something to that effect.

Thomas


On Mon, Feb 5, 2018 at 1:39 PM  wrote:

> I'm initializing a Logger variable in an init() function and then
> attempting to use in the main() function. However, I'm able to Printf from
> the Logger in the init() function but not inside the main() function. Any
> help would be appreciated.
>
> package main
>
> import (
>
> "fmt"
> "log"
> "io"
>
> "os"
>
> }
>
> var (
>
> logFile *os.File
> logger *log.Logger
> multiWriter io.Writer
>
> )
>
> func init() {
>
> fmt.Println("init() function")
>
> var logFileError error
> logFile, logFileError = os.Create("gopoc.log")
> if logFileError != nil {
> panic(logFileError)
> }
> defer logFile.Close()
>
> fmt.Println("Creating log file")
>
> multiWriter = io.MultiWriter(logFile, os.Stdout)
>
> logger = log.New(multiWriter, gopocLogPrefix, log.Ldate | log.Ltime |
> log.Lshortfile)
> logger.SetOutput(multiWriter)
>
> fmt.Println("Created logger")
>
> logger.Printf("Using logger")  // prints to console and logFile as expected
>
> }
>
> func main() {
>
> fmt.Println("main() function ") // prints to console
>
> fmt.Println(logger) // I can see the object pointer
>
> logger.Print("hello") // This does not print to logFile nor
> os.Stdout !!!
>
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Why doesn't sync.Cond embed sync.Locker?

['Thomas Bushnell, BSG' via golang-nuts]

Sometimes you want multiple Conds which share the same Locker. When you
want it, it's frequently essential and very annoying if you can't have it.

On Sun, Nov 12, 2017 at 7:02 PM T L  wrote:

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

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

Re: [go-nuts] nil maps

['Thomas Bushnell, BSG' via golang-nuts]

Here's a case that comes up for me:

type table map[string]map[string]string

func (t table) add(x, y, z string) {
  if t[x] == nil {
t[x] = make(map[string]string)
  }
  t[x][y] = z
}

func (t table) get(x, y string) string {
  return t[x][y]
}

The fact that t[x] can be indexed even if it hasn't been created makes this
much simpler.

On Tue, Oct 17, 2017 at 12:52 AM Alex Dvoretskiy 
wrote:

> Hello, Golang Nuts!
>
> I have an interesting question about maps. What is the possible usage of
> nil maps, which can be declared like "var m map[string]int"? You can't
> write to nil map but have an option to create it.
>
> Perhaps there is no use at all and this is just language specific feature?
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

['Thomas Bushnell, BSG' via golang-nuts]

On Sat, Jul 29, 2017 at 10:36 AM  wrote:

>
> But as Gofmt can ALREADY enforces this common coding style, and can be run
> at any time, including before committing code on the depots, why should it
> be enforced by the COMPILER too ?
>

The compiler does not enforce the use of gofmt.

What you're complaining about is that the syntax of the language does not
permit a particular thing which the syntax of C does. It also doesn't
permit "a = b++" and many other things which C does.

Thomas

-- 
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: pet peeve: it's Go not golang

['Thomas Bushnell, BSG' via golang-nuts]

Google Search is weird. I searched for "game of life in go" and all ten
links were great hits for just that. When I search for "go game life", the
implementation of Conway's game is the fifth link; still not so bad.

Thomas

On Tue, Jul 25, 2017 at 2:47 PM  wrote:

> Yes, the language name is Go, but sometimes real life matters.
>
> Imagine I want to search for a Go implementation of Conway's Game of Life,
> but I don't quite remember the game name, so I search for:
>
> go game life
>
> Nothing. Otherwise, if I search for
>
> golang game life
>
> I get plenty of entries directly related to what I was looking for. Ditto
> for Google, Bing and Yahoo.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] pet peeve: it's Go not golang

['Thomas Bushnell, BSG' via golang-nuts]

And when there is confusion, "Go language" is much nicer to read than
"golang".

On Tue, Jul 25, 2017 at 11:16 AM Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> Although "go" is a verb, an adjective and a noun (including the game),
> there shouldn't be any confusion in what Go is, when posting to a list
> dedicated to the language.
>
> Thanks,
> -Skip
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Uncontrolled map access can crash the program --- how?

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Jul 5, 2017 at 12:29 PM Peter Kleiweg  wrote:

> From the faq: https://golang.org/doc/faq#atomic_maps
>
>  ... uncontrolled map access can crash the program.
>
> In what situations does this apply?
>
> Can I have two goroutines reading a single map at the same time?
>

Yes.


> Can I have one goroutine putting something in a map while at the same time
> another goroutine is reading the map?
>

This has a risk of crashes or arbitrary data corruption.


> Does it depend on the type of the key or the type of the value?
>

No.

Thomas

-- 
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] Curious about this snippet in /src/runtime/proc.go

['Thomas Bushnell, BSG' via golang-nuts]

Something similar at
https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=19882f3e3dc1ab830431506329c94dcf1d7cc252;hb=HEAD#l138
in
the GNU C library. Sometimes you just need to be absolutely certain that a
function doesn't return.

On Thu, Jun 15, 2017 at 2:16 PM Rob Pike  wrote:

> Code comments can be helpful with unusual situations like this.
>
> -rob
>
>
> On Fri, Jun 16, 2017 at 4:25 AM, Goodwin Lawlor 
> wrote:
>
>> Thanks for the explanation.
>>
>> My random guess was that it's the compiler version of deleting your
>> browser cache... If exit fails, blank as much memory as we can get our
>> hands on. 
>>
>> On 15 Jun 2017 6:34 pm, "Ian Lance Taylor"  wrote:
>>
>>> On Thu, Jun 15, 2017 at 10:28 AM, Tyler Compton 
>>> wrote:
>>> > Why not just panic, though? And why the infinite loop, I wonder?
>>>
>>> The runtime is a special case in many ways, and this is among the more
>>> special parts.  This loop exists to catch problems while testing new
>>> ports.  If that loop is ever reached, something has gone badly wrong:
>>> the exit call should have caused the program to exit.  We can't assume
>>> that panic is working.  We can't really assume that anything is
>>> working.  What we want to do is stop the program.  Since exit failed,
>>> it's possible that a nil dereference will succeed.  If that fails too,
>>> we still have to do something, so we just loop.  We can't return
>>> because this is the main function that started the program; there is
>>> nothing to return to.
>>>
>>> Ian
>>>
>>> > On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal 
>>> wrote:
>>> >>
>>> >> Force a panic in case exit fails?
>>> >>
>>> >> --
>>> >> -- Aldrin Leal,  / http://about.me/aldrinleal
>>> >>
>>> >> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
>>> >>>
>>> >>> Hey,
>>> >>>
>>> >>> Learning golang at the moment and came across this at the end of func
>>> >>> main() in proc.go in the golang source tree.
>>> >>>
>>> >>> exit(0)
>>> >>> for {
>>> >>> var x *int32
>>> >>> *x = 0
>>> >>> }
>>> >>>
>>> >>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>>> >>>
>>> >>> How is the for loop ever reached and what's the purpose of the
>>> infinite
>>> >>> loop, zeroing memory?
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Goodwin
>>> >>>
>>> >>> --
>>> >>> You received this message because you are subscribed to the Google
>>> Groups
>>> >>> "golang-nuts" group.
>>> >>> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> >>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> >>> For more options, visit https://groups.google.com/d/optout.
>>> >>
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> Groups
>>> >> "golang-nuts" group.
>>> >> To unsubscribe from this group and stop receiving emails from it,
>>> send an
>>> >> email to golang-nuts+unsubscr...@googlegroups.com.
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >
>>> > --
>>> > Tyler Compton
>>> > Software Engineering
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> > email to golang-nuts+unsubscr...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Is it safe to invoke len(channel) on multi-gorountine

['Thomas Bushnell, BSG' via golang-nuts]

As you discovered, it is perfectly *safe *to call len on a channel in use
by multiple goroutines: you'll get a correct answer and you won't provoke a
crash or anything. But you can't use it as a signal that a following
receive will work if another goroutine might have received in the interim.

On Sat, Jun 17, 2017 at 6:58 AM  wrote:

> I almost got into the trap with this, trying to prioritize selected
> channel...
> https://play.golang.org/p/VOrPwx7HC_
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Fast string sorting

['Thomas Bushnell, BSG' via golang-nuts]

That's really nice!

Consider a case where I am sorting a slice of structs, but the underlying
sort is based on a string within the structs. Or, with some other radixable
datatype besides strings.

Can we figure out an interface (similar to sort.Interface) which would
permit a solution for either or both of these cases? The former should be
fairly simple to do without sacrificing the speedup; the latter might be
trickier.

Thomas


On Tue, Jun 13, 2017 at 6:20 AM Stefan Nilsson 
wrote:

> It's well known that radix sort can be faster than comparison-based
> methods for string sorting. With that in mind, I wrote this optimized
> version of MSD radix sort:
>
> https://github.com/yourbasic/radix
>
> It's equivalent to sort.Strings in the standard library and on my machine
> it's twice as fast as when sorting King James Bible and four times as fast
> for the 1k benchmark in the sort package. Of course I can't promise similar
> performance in other settings, but Go get it if you like.
>
> Stefan
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Expected declaration, found 'package'

['Thomas Bushnell, BSG' via golang-nuts]

A single Go source file is not allowed to be in more than one package.

On Wed, Apr 26, 2017 at 8:52 AM Tong Sun  wrote:

> Hi,
>
> I'm trying to put different code collection into the same Go source file,
> (from here
> , if
> you want to know), because the knowledge is related thus better keep in one
> demo file instead of several. However, the challenge to me is that, it
> keeps reusing the same variable name for different purposes (which I think
> IS good practice). E.g.,
>
> In one section the type A is defined as
>
> type A struct {
> }
>
> In another section the type A is defined as
>
> type A struct {
> name string
> }
>
>
> In C#, this is not a problem at all, as I can just put different cases
> into different namespaces.
>
> How to do it (putting different code collection into the same Go source
> file) in Go?
>
> I tried to separate different sections with
>
> package next_section
>
> but got the error
>
> expected declaration, found 'package'
>
> What's the easiest way to do it? please help.
>
> 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.
>

-- 
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] Change imaginary part of a complex

['Thomas Bushnell, BSG' via golang-nuts]

The other way is to add the c to its conjugate and then add the imaginary
part, using cmplx.Conj. But that really amounts to what you're doing
already.

On Thu, Apr 20, 2017 at 3:20 AM Val  wrote:

> Hello folks
> To keep real part of a complex, and set its imag part, I'm doing
>   c = complex(real(c), -5.0)
>
> Is there a more concise way, something like   c.imag = -5.0  ? I know
> this one doesn't compile, but I may be missing something obvious.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] encoding an integral float like 1.0 as "1.0" in JSON (not "1"), and other JSON questions

['Thomas Bushnell, BSG' via golang-nuts]

There is no such distinction in json as a float vs. an int; they are just
numbers. This is essentially a consequence of the javascript underpinnings
of json.

Thomas

On Thu, Mar 2, 2017 at 2:29 AM Basile Starynkevitch <
bas...@starynkevitch.net> wrote:

> Hello All,
>
> This could be related to issue #6384
> 
>
> I want to JSON encode a float64 point number always as a JSON float, so
> 1.0 should be encoded as 1.0 not as 1 because at decoding time I want to
> distinguish them.
> Conceptually, I am persisting in JSON format something which is somehow
> close to some AST, or even to S-expressions (see below for details). So I
> want a float 1.0 to be different of the integer 1.
>
> If you are curious, my exact code is commit 096ec00f53011b2a1b05ce
> 
> on github, and when running go test -v objvalmo with my monimelt project
> being last in my GOPATH I'm getting as output (amongst many other lines)
>
> json_emit v=-1.00 of type objvalmo.FloatV
> json_emit buf: -1
>
> and I would like that second line to be at least json_emit buf: -1.0
> because I need to separate objvalmo.FloatV from objvalmo.IntV types
>
> I played with the following json/encoding example
>  and
> changed it (by adding some mass being 1.0) to
>
> package main
>
> import (
> "encoding/json"
> "fmt"
> "os"
> )
>
> func main() {
> h := json.RawMessage(`{"precomputed": true}`)
>
> c := struct {
> Header *json.RawMessage `json:"header"`
> Body   string   `json:"body"`
> Mass   float64`json:"mass"`
> }{Header: , Body: "Hello Gophers!", Mass: 1.0}
>
> b, err := json.MarshalIndent(, "", "\t")
> if err != nil {
> fmt.Println("error:", err)
> }
> os.Stdout.Write(b)
>
> }
>
>
>
>
> and expected the output to contain "mass" : 1.0 but it still gives a line
> with only  "mass": 1 without any decimal point. Is there any way to
> change that and get that decimal point?
>
>
> More generally, I don't understand well how should I use JSON facilities
> in Go. IMHO, there are two approaches: one is using go reflection
> facilities, and claim to be able to serialize most arbitrary values.
> another is not using them at all (and this is what I would prefer) by
> constructing some explicit data in memory mimicking JSON format. FWIW, I
> care a bit about performance.
>
> To explain my issues, let us imagine that I want to serialize (and
> unserialize) in JSON format some s-expressions
>  (or some program of a micro
> Scheme or micro Lisp interpreter), with both lists and vectors as composite
> types, with the additional constraint that some symbols should not be
> serialized (and we'll output the null JSON value for them instead) For
> simplicity assume that we have only alphabetical symbols like xy foo bar
> efg Let us suppose that we want to ignore all symbols starting with a
> vowel  (so we ignore efg here). so (foo 1 #(2 xy)  (bar "ab" efg -1.0
> "cd")) is an example of such s-expr.. It is a list of 4 elements. The
> third element is a vector #(2 xy) of 2 components. The 4th and last
> element is a list (bar "ab" efg -1.0 "cd") of 5 elements whose 3rd
> element is the symbol efg which, since starting with a vowel, should be
> ignored and serialized as null and whose 4th element is the floating
> point -1.0 (not the integer -1). I would like to serialize that S-expr
> value as e.g.
> { "list" : [ { "symb" : "foo" }, 1, { "vect" : [ 2, { "symb" : "xy" } ] },
> { "list" : [ { "symb" : "bar" }, null, -1.0, "cd" ] } ] }
>
>
> Actually, I am not exacty coding a microScheme. I haved shared objects (of
> *ObjectMo type) and values (of ValueMo type) inside objects (every object
> has a map and a slice of values). I want to persist them in JSON inside an
> Sqlite database, but some objects are transient and non-persistent (so I
> would encode them as null). All objects have a *unique* id like
> _0ECuE7b9XhQ_3HvWl3RGhD6
>
> Any advices are welcome. In particular, I am a bit afraid of the
> reflection approach (because I want serialization & deserialization to not
> be too slow, and I really need to master the JSON representation).
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Trying to understand := and named return values

['Thomas Bushnell, BSG' via golang-nuts]

Function parameters are not a good place (in general - there are
exceptions) to document arguments.

// Frob the outer otter.
FrobOuterOtter(otter Otter)

is not better than

// Frob the outer otter
FrobOuterOtter(Otter)

from the standpoint of external documentation.

But if you want the function to have access to the parameters, you need to
name them. The same is not true for return values.

// Add two numbers
Add(x, y int) int

is fine. This is silly:

// Add two numbers
Add(x, y int) (sum int)

Since the comment already says in English what is returned, there isn't any
value to repeating it again in the return value. *Except *when there are
multiple ones and the order matters:

// Lookup returns the name and email address of the user.
Lookup(id Identity) (name, email string)


On Tue, Feb 21, 2017 at 6:46 PM John Souvestre  wrote:

> I feel the opposite.  I view named returns as documentation of a
> function's parameters.  I'm constantly amazed by the (correct) emphasis
> placed on using appropriate names for calling parameters, but not for the
> return parameters.  The goal is that I shouldn't have to read a function's
> code to use the function, right?
>
> So how can the disparity be justified?  Oh, and the longer the function is
> the more benefit there is to using them.
>
> John
>
> John Souvestre - New Orleans LA
>
>
> -Original Message-
> From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com]
> On Behalf Of Ian Lance Taylor
> Sent: 2017 February 21, Tue 16:13
> To: andrew.penneba...@gmail.com
> Cc: golang-nuts
> Subject: Re: [go-nuts] Re: Trying to understand := and named return values
>
> On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
> > Seems like named returns + if/for/switch initializers = a shadowing
> > nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> > this is a dangerously subtle problem out there.
>
> Yes, named returns may have been a mistake.  Only use them in very
> very short functions.
>
> 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.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] How do you implement and use Context.Done?

['Thomas Bushnell, BSG' via golang-nuts]

Oops! ::blush::

On Tue, Feb 21, 2017 at 11:39 AM Axel Wagner <axel.wagner...@googlemail.com>
wrote:

> Wrong list :) You meant to link here:
> https://godoc.org/context#Context.Err
>
> On Tue, Feb 21, 2017 at 8:15 PM, 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor <i...@golang.org> wrote:
>
> On Sun, Feb 19, 2017 at 2:57 PM,  <so.qu...@gmail.com> wrote:
> > Thanks, I see you build it up with decorators on a standard prototype.
> > For example: https://play.golang.org/p/PJy5lE9QqF
> >
> > So context.Done is a convenience function for those that require it?
> > Otherwise a context will expire after it leaves scope, so Done does not
> need
> > to be called?
>
> Cancelling the context just marks the context as cancelled.  It does
> not actually stop any goroutines using the context.  Those goroutines
> must themselves periodically check the context to see whether it has
> been cancelled, and, if so, stop working.  They do that by calling
> either the Done or Err method; it's much more common to call the Done
> method (and check whether the channel is closed).
>
>
> Calling the Err() method to see if the context has been cancelled is
> incorrect.  See
> https://godoc.corp.google.com/pkg/google3/go/context/context#Context.Err:
> "Err's return value is unspecified before Done is closed."
>
> Thomas
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

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

Re: [go-nuts] How do you implement and use Context.Done?

['Thomas Bushnell, BSG' via golang-nuts]

On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor  wrote:

> On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
> > Thanks, I see you build it up with decorators on a standard prototype.
> > For example: https://play.golang.org/p/PJy5lE9QqF
> >
> > So context.Done is a convenience function for those that require it?
> > Otherwise a context will expire after it leaves scope, so Done does not
> need
> > to be called?
>
> Cancelling the context just marks the context as cancelled.  It does
> not actually stop any goroutines using the context.  Those goroutines
> must themselves periodically check the context to see whether it has
> been cancelled, and, if so, stop working.  They do that by calling
> either the Done or Err method; it's much more common to call the Done
> method (and check whether the channel is closed).
>

Calling the Err() method to see if the context has been cancelled is
incorrect.  See
https://godoc.corp.google.com/pkg/google3/go/context/context#Context.Err:
"Err's return value is unspecified before Done is closed."

Thomas

-- 
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] about sorting array

['Thomas Bushnell, BSG' via golang-nuts]

Not quite. The slice shares storage with the array, so changing an element
of the slice is the same as changing an element of the array. Slicing in Go
(unlike some other languages) does not copy the elements.

Thomas


On Wed, Feb 1, 2017 at 4:56 PM Néstor Flórez  wrote:

> OK, thanks for the clarification on the size being immutable.(I am trying
> to teach myself Go)
>
> Still I want to know what happens when this statement is executed
> sort.Ints(scores[:])
>
>- Sort creates a slice
>   - The slice is sorted
>   - Sort copies the slice into the array
>
> Is this what is happening?
>
> Thanks
>
> On Wednesday, February 1, 2017 at 4:30:37 PM UTC-8, Michael Jones wrote:
>
> array contents are not immutable, just their size.
>
> On Wed, Feb 1, 2017 at 4:13 PM, Néstor Flórez  wrote:
>
> The below code sorts an array but it does it  an by creating a slice,
> correct?
> What happened to the original array?
> Arrays are inmutable
>
>
> --
> package main
> import ("fmt"
>"sort")
>
> func main(){
>   var scores [10]int   // creates array scores
>   scores[0]= 99// sets 1st element to 99
>   fmt.Println("SCORES \n", scores)   //print the unsorted array
>
>   sort.Ints(scores[:]) //creates a slice "scores"
>   fmt.Println("\n", scores)  //print the slice "scores"
> } //what happened to
> the array scores?
>
> 
>  [99 0 0 0 0 0 0 0 0 0]
>
>  [0 0 0 0 0 0 0 0 0 99]
>
> -
> 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...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Michael T. Jones
> michae...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: Best practice when creating temporary files

['Thomas Bushnell, BSG' via golang-nuts]

It's fine to try, but you should design your entire system with the
assumption that your program may crash at any moment and leave something
around. This is why the OS cleans up /tmp.

Thomas

On Mon, Nov 21, 2016 at 9:01 AM Steven Hartland 
wrote:

> That's a bad assumption, you should always clean up after yourself.
>
>
> On 21/11/2016 16:57, Val wrote:
>
> OK, I had overlooked the fact that cleanup is important to you, which
> makes sense for security and to save disk space early.
> TempFile, TempDir don't do the cleanup, but the OS will sooner or later.
> Here is my new suggestion for a file
> 
> and for a dir
> 
> :
>
> tmpfile, err := ioutil.TempFile("", "")
> checkerr(err)
> defer os.Remove(tmpfile.Name())
>
>
> dir, err := ioutil.TempDir("", "")
> checkerr(err)
> defer os.RemoveAll(dir)
>
>
>
>
>
> On Monday, November 21, 2016 at 4:19:26 PM UTC+1, Ondrej wrote:
>
> That's my current code, I just wanted to double check that it's the proper
> one (ie that the cleanup actually happens), since some of my temp files can
> be fairly large.
>
> On Friday, 18 November 2016 15:54:36 UTC, Val wrote:
>
> Obtain a new temp file :
>   tmpfile, err := ioutil.TempFile("", "")
>
> Obtain a new temp dir :
>   dir, err := ioutil.TempDir("", "")
>
> I suggest you don't bother with cleanup.  It should work on any OS.
>
> On Friday, November 18, 2016 at 11:21:23 AM UTC+1, Ondrej wrote:
>
> I have a tool that generates some HTML and launches a web browser to
> display it. For this to work, I need to save the HTML some place and I also
> need to handle the file afterwards. The app itself doesn't persist - it
> generates the content and exits. There are thus two issues I'm struggling
> with:
>
> 1. What is the best place for this? Do I create a folder in
> usr.HomeDir()/.appname/ and place HTML files there? Or do I just create
> tempfiles in os.TempDir? Does it make a difference?
> 2. How do I clean up? As I said, the app does not persist (so I can't
> defer os.Remove), so either I scan the folder in question (before my HTML
> generation) and remove all files older than, say, a day. Or is that done
> for me by the operating system if I use os.TempDir?
>
> I thought I'd just use os.TempDir and let the OS handle it, but I'm not
> 100% sure the OS does clean this up on its own. (This will be used on
> Windows and Macs, maybe Linux.) Any insight on any of these would be
> greatly appreciated.
>
> 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.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

['Thomas Bushnell, BSG' via golang-nuts]

If you believe there is an issue which is not being addressed properly,
please use the procedure at https://golang.org/conduct#reporting.

Thomas

On Fri, Nov 4, 2016 at 12:22 PM  wrote:

> All I see here is nothing is done to moderate /r/golang despite threads
> being reported for harassment. What good is a code of conduct if it isn't
> enforced ? and when enforced , moderators have to come here to apologize
> for doing their jobs, like Sarah ? If you don't want me to bring /r/golang
> here, then do something about /r/golang because what is happening there is
> an embarrassment to the go community.
>
>
> Le vendredi 4 novembre 2016 14:21:24 UTC+1, Thomas Bushnell, BSG a écrit :
>
> This list doesn't need to be a place to copy /r/ to. Please refrain from
> public denunciations and speak privately with those you wish, and... Follow
> the code of conduct if you believe a more formal response is called for.
>
> Thomas
>
> On Fri, Nov 4, 2016, 6:17 AM  wrote:
>
> >  then labeling someone's thread as "bullying" (a pretty serious charge
> in todays climate).
>
> Well now the target of the latest witch-hunt /u/gernest_ has responded on
> /r/golang, the previous thread that I linked I quote "broke his heart" , so
> you can't deny something is definitely wrong here :
>
> https://www.reddit.com/r/golang/comments/5b2j38/what_is_idiomatic_go/
>
> > After the WTF moment. I calmed down and just realized what few innocent
> words can do. They broke my heart.
>
> > I'm confused, and definitely heart broken.
>
> AFAIK the original thread is still up on /r/golang , how long is the go
> community going to allow this kind of things ?
>
>
>
> Le vendredi 4 novembre 2016 06:49:07 UTC+1, andrewc...@gmail.com a écrit :
>
> I would also like to point out the extreme hypocrisy of saying Aram's
> comment is  "unnecessary and insensitive" then labeling someone's thread as
> "bullying" (a pretty serious charge in todays climate). Both of which I
> would consider worse insults than saying someone has bad English. If i was
> on the censorship panel I would almost certainly issue you a warning for
> those.
>
> On Friday, November 4, 2016 at 6:03:53 PM UTC+13, prade...@gmail.com
> wrote:
>
> That's not up to you to judge if some comment is "harmless" or not.
> Because you're not the person the comment has been directed at. Something
> that might seem "harmless" to you might be perceived as insulting to
> someone else. Aram's comment was unnecessary and insensitive to say the
> least, it doesn't matter if he is an important contributor to Go or not. If
> they are rules they apply to everybody equally or they don't, that's what
> rules are for. Frankly Sarah shouldn't have apologized for anything, she
> did exactly what she was supposed to do in this case. It doesn't matter how
> sizable Aram's contribution is, it doesn't preclude him from showing a
> little bit of respect.
>
> Right now /r/golang is engaged in yet another bullying campaign against
> another individual on this thread :
>
>
> https://www.reddit.com/r/golang/comments/5ayvws/github_stars_are_no_more_a_valid_metric_for/
> 
>
> (archived here : http://archive.is/znqJg )
>
> Just because that person has written "a non idiomatic framework" .?
>
> Someone is being labelled at "a marketer with a crappy product" . Is it
> what moderators here call "a respectful environment" ? the thread is still
> up as we speak. This has happened before with Martini, then Iris , now
> utron. That's how the go community wants to grow ?
>
>
>
>
> Le jeudi 3 novembre 2016 01:38:43 UTC+1, Paul a écrit :
>
> I just discovered this thread. I used to be an avid reader of Golang-nuts
> mailing list, also of Golang-dev and I am in disbelief at what it has come
> to recently.
>
> Aram Hăvărneanu is a very important contributor to the Go Language
> Project, I feel embarrased on behalf of the of the Go Language Project
> about how he has been treated. This is not OK, and this needs to be very
> clearly stated.
>
> This overreaction of your "code of conduct" moderator is beyond
> rediculous, to Arams very harmless statement about someones english
> language skills. I mean come on ...  Arams sentence is so non-lethal and
> tame that it is mind boggling that he should find such alienating
> reproachment to me. Especially after all of his valuable contributions.
> That it happened because of something he said on Redit just makes it so
> much worse.
>
> If you should loose (and it looks like you have) such an important
> contributor because of your nonsensical and rediculous  COC moderation
> system, then  this system of yours has just completely and utterly failed
> and it should be abandoned immediately till a more suitable solution can be
> found.  It will not do that someone who is obviously 

Re: [go-nuts] Working with characters in strings

['Thomas Bushnell, BSG' via golang-nuts]

Sorry, I did not mean to say they are restricted to UTF8. I was answering
the question "what is the relation between a rune and its byte
representation", by saying that the []byte cast of a string (assuming the
string only holds legitimate runes) is the UTF8 of the runes making it up.

The original question was confounded by asking about "characters" which is
a term that is pretty much only used by the reference in speaking of
program text; the only exception I could find is speaking of Unicode
replacement characters in talking about range iteration of strings.

My point is that the relation between a rune and its byte representation is
"UTF-8". I don't know whether the original question was using "character"
to mean "byte" (the curse of C!) or something else.

Thomas


On Mon, Oct 31, 2016 at 5:13 PM Lars Seipel <lars.sei...@gmail.com> wrote:

> On Mon, Oct 31, 2016 at 06:06:23PM +, 'Thomas Bushnell, BSG' via
> golang-nuts wrote:
> > Strings are specified to be UTF8, so if you cast a string to []byte you
> > will see its UTF8 representation.
>
> They are not. A Go string may contain arbitrary bytes. Features like
> for..range or conversions to rune slices won't be very useful then
> (though still well-defined) but that's about it.
>
> Go source text and thus string literals are UTF-8. You might be thinking
> of those?
>
> -ls
>

-- 
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] Working with characters in strings

['Thomas Bushnell, BSG' via golang-nuts]

I don't know what you mean by "characters", since you're distinguishing
them from runes. Do you mean bytes?

Strings are specified to be UTF8, so if you cast a string to []byte you
will see its UTF8 representation.

Thomas

On Sat, Oct 29, 2016 at 4:42 AM  wrote:

>
> I understand that strings are immutable sequences of bytes and wanted to
> know how to idiomatically work with the "characters" within a string.
>
> For example how should I approach the following operations
>
>
>- Convert a string to a []string (slice or array). eg. "foobar" to
>["f" "o" "o" "b" "a" "r"]
>
>
>- Iterate through a string by "character" strings instead of runes,
>for example:
>
> str := "foo"
> for _,char := range "bar" {
> str += char // is a cast string(char) required?
> }
> fmt.Println(str) // print "foobar"
>
>
>
> Also what is the relationship between a rune and it's byte representation?
>
> Any additional advice for working with characters of strings would be
> appreciated as well.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] the defer list

['Thomas Bushnell, BSG' via golang-nuts]

Ah, yes, that's true indeed.

On Wed, Oct 19, 2016 at 2:33 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wednesday, 19 October 2016 16:50:55 UTC-4, Thomas Bushnell, BSG wrote:
>
> On Wed, Oct 19, 2016 at 1:47 PM Pietro Gagliardi 
> wrote:
>
> Manual memory management is a part of life in the C world. defer is the
> solution that Go comes up with to situations where explicit cleanup is
> necessary, and it's a powerful tool that I'm pretty sure *is* an innovation
> Go did first.
>
>
> Oh my, no. It's a wonderful thing, but it's essentially equivalent to
> Lisp's UNWIND-PROTECT or (in the outward case) Scheme's dynamic-wind.
>
>
> Unwind-protect and the better known but equivalent try/finally both
> operate at the level of balanced lexical blocks: expressions in Lisp,
> statement blocks in Java or C++.  In contrast, defer operates at the
> function level and requires a dynamic stack, and in that sense it is novel,
> but I can't think of a single time I've actually wanted to defer an action
> beyond the point when try/finally would have executed 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.
>

-- 
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] the defer list

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Oct 19, 2016 at 1:47 PM Pietro Gagliardi 
wrote:

> Manual memory management is a part of life in the C world. defer is the
> solution that Go comes up with to situations where explicit cleanup is
> necessary, and it's a powerful tool that I'm pretty sure *is* an innovation
> Go did first.
>

Oh my, no. It's a wonderful thing, but it's essentially equivalent to
Lisp's UNWIND-PROTECT or (in the outward case) Scheme's dynamic-wind.

Thomas




> If you just follow the idiom
>
> cstr := C.CString(str)
> defer C.free(unsafe.Pointer(cstr))
>
> with nothing in between those two lines, then you won't have to worry
> about whether something gets cleaned up every time, because the answer is
> yes, it *will* get cleaned up every time! It's not like C anymore where you
> have to worry about making sure every code path frees only what is
> allocated on that code path, which means either juggling gotos or
> infinitely nesting ifs and possibly NULL checks everywhere.
>
> Stop trying to fight the language; start using it.
>
> If you are really prone to forgetting to free something somewhere, write a
> program using the go/... packages to do static analysis and evaluate the
> lifetime of C objects for yourself.
>
> On Oct 19, 2016, at 4:22 PM, andrew.sm...@miracl.com wrote:
>
> I thought someone might ask! Im writing many wrapper functions to C
> functions that take multiple C.char* arguments. All of these require a call
> to C.free() before the wrapper function terminates. I can do this with
> defer but Im absolutely sure Im going to miss one or more of these out. So
> I was wondering, if I could get hold of the defer list, then I could
> encapsulate the construction together with the defer in a function.
>
> e.g. roughly :
>
> func NewCString(s string, deferList List) *C.char {
>cs := C.CString(s)
>deferList.PushBack(func() { C.free(cs) }
>return cs
> }
>
> Then in an *imagined world* I could write my wrapper simply as :
>
> func wrapper(s1 string, s2 string, s3 string) {
>   deferList := runtime.DeferList()
>   return C.inner(NewCString(s1,deferList), NewCString(s2,deferList),
> NewCString(s2,deferList))
> }
>
> Basically, I cant seem to find a clean solution to ensure all these
> C.char* are 100% freed... swig allows me to wrap the C.char* with string,
> but swig is pretty awkward to use especially when wrapping the libraries I
> have. Im currently preferring cgo which seems much simpler and cleaner, but
> I dont have the equivalent of swigs typemaps to ensure all allocs are
> correctly freed... :o(
>
>
>
> On Wednesday, October 19, 2016 at 8:41:25 PM UTC+1, Pietro Gagliardi
> (andlabs) wrote:
>
> What do you want to do with it?
>
> On Oct 19, 2016, at 3:31 PM, andrew...@miracl.com wrote:
>
> Hi,
>
> This is probably a long shot, but is it possible to get a reference to the
> list of functions that the 'defer' statement populates? Is it exposed
> and/or is it specific?
>
> Andy
>
> --
> 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.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: Why + and += operators for string but not slices?

['Thomas Bushnell, BSG' via golang-nuts]

The thread already shows several alternative interpretations which are
different from that. Go tries to avoid constructions that require careful
specification of that sort. Append already causes enough confusion, but
that's important enough that dropping it would be a loss. + for slices is
only syntactic sugar.

Thomas

On Fri, Sep 16, 2016 at 3:09 PM  wrote:

> The semantics of + and append() preclude a "data aliasing" ambiguity.
> Consider:
>
> c = a + b
>
> and
>
> c = append(a, b...)
>
>
>
> On Friday, September 16, 2016 at 9:14:45 PM UTC+1, Thomas Bushnell, BSG
> wrote:
>
> The values of the summation are indeed unambiguous, but the data aliasing
> properties are not.
>
> On Fri, Sep 16, 2016, 12:58 PM  wrote:
>
> Thank you both.
>
> To Ian: but a slice is not a matrix or a list.
>
> To Axel: append() and copy() compliment indexing and slicing well enough.
>
> It would be a shame if ambiguity is indeed the reason. We've accepted 1 +
> 1 as numeric addition and "a" + "b" as string concatenation. For a slice,
> perceived as a window on a string of elements, concatenation is
> unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z]
>
>
>
>
>
>
>
> On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote:
>
> I have not been able to find an explanation. Does anyone care to explain
> or point to relevant documentation?
>
> --
> 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.
>

-- 
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: Why + and += operators for string but not slices?

['Thomas Bushnell, BSG' via golang-nuts]

The values of the summation are indeed unambiguous, but the data aliasing
properties are not.

On Fri, Sep 16, 2016, 12:58 PM  wrote:

> Thank you both.
>
> To Ian: but a slice is not a matrix or a list.
>
> To Axel: append() and copy() compliment indexing and slicing well enough.
>
> It would be a shame if ambiguity is indeed the reason. We've accepted 1 +
> 1 as numeric addition and "a" + "b" as string concatenation. For a slice,
> perceived as a window on a string of elements, concatenation is
> unambiguous. [a, b, c] + [x, y, z] = [a, b, y, z]
>
>
>
>
>
>
>
> On Friday, September 16, 2016 at 6:11:17 PM UTC+1, oyi...@gmail.com wrote:
>
> I have not been able to find an explanation. Does anyone care to explain
> or point to relevant documentation?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Unary +

['Thomas Bushnell, BSG' via golang-nuts]

eanings.
>
>
>
> There is a Wikipedia article about this but its scholarship is, well, more
> about usage than history. They talk about the raised minus as an elementary
> school teaching tool (which it may be) but they leave it there with little
> suggestion of its illustrious past. Yet, to their credit there is a handy
> example:
>
>
>
> ⁺3 − ⁻5 becomes ⁺3 + ⁺5 = ⁺8
>
>
>
> where you might imagine a teacher saying “positive three minus negative
> five becomes…” which is nice. (A sophisticated college CS teacher or parser
> coder might instead say “plus 3 minus minus 5 becomes…” ;-) We don’t have
> the raised minus to say “here is a negative number” so we make use of the
> unary rather than binary minus to suggest negative. You use what you have.
>
>
>
> Now, on to the original question:
>
>
>
> Standard floating point output since the 1950’s has allowed printing of
> either blank or “+” as the prefix for positive floating point values and,
> necessarily, the lowered minus “-“ for negative values; we get the ‘+’ with
> a printf format like “%+10.4f”.
>
>
>
> It is handy to be able to parse what is output, such as numerical
> approximations and weights in formula source code, so the parsing of
> “3.1415” was made to accept “+3.1415” for the same meaning, and of course
> “-3.1415” since we lack the raised minus.
>
>
>
> Since floating point values accept the stylistic ‘+’ prefix, so do integer
> values.
>
>
>
> ..and here we are today, some 50 years later.
>
>
>
> P.S. If you visited Thomas Payne’s bookshop in London (in the 1750s) you
> could have bought your own copy of Francis Maseres’ *“A dissertation on
> the use of the negative sign in algebra: containing a demonstration of the
> rules usually given concerning it; and shewing how quadratic and cubic
> equations may be explained, without the consideration of negative roots. To
> which is added, as an appendix, Mr. Machin's quadrature of the circle.”*
> You could have enjoyed much discussion of the new style of writing and its
> advantages.
>
>
>
>
>
> *From: *"'Thomas Bushnell, BSG' via golang-nuts" <
> golang-nuts@googlegroups.com>
> *Reply-To: *"Thomas Bushnell, BSG" <tbushn...@google.com>
> *Date: *Friday, August 19, 2016 at 1:36 PM
> *To: *Axel Wagner <axel.wagner...@googlemail.com>, Rob Thornton <
> rthornton...@gmail.com>
> *Cc: *golang-nuts <golang-nuts@googlegroups.com>
> *Subject: *Re: [go-nuts] Unary +
>
>
>
> In C, the type is promoted. But this ain't C. No clue what the point is in
> Go. It would function as a compile-time type-check for "numeric" I guess,
> but what would be the point?
>
>
>
>
>
> On Fri, Aug 19, 2016 at 1:32 PM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> x would already be signed during implicit type inference. The inferred
> type is either the one specified in an argument or declaration, or it's the
> default type (which is int, thus signed).
>
>
>
> I don't know the answer to your question though. I didn't even know this
> existed…
>
>
>
> On Fri, Aug 19, 2016 at 9:54 PM, Rob Thornton <rthornton...@gmail.com>
> wrote:
>
> What is the purpose of the unary '+' operator? In both C and Go they are
> syntactically correct but neither generate instructions to modify the
> expression.
>
> The '-' operator obviously generates a neg or sub from 0 instruction to
> negate the result by inverting the expression with an add with carry.
>
> I know of no single instruction or pair of instructions to reliably ensure
> any value or expression is always positive so why include this unary
> operator at all? Is there a purpose I'm missing? Or is it just for clarity
> or force an implicit variable to be signed?
>
> As in:
>
> x := +5
>
> Would this ensure that x must be signed during impicit type inference?
>
> If I read the specification correctly, this would also affect the
> resolution of untyped constants. Is this 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.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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] Is there a function in standard lib to convert []T to a []interface{}?

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Aug 3, 2016 at 7:36 AM T L  wrote:

> Often, I need converting a []T to []interface{} to use the []interface as
> a variable length parameter.
> But converting a []T for []interface{} in a for loop is neither clean nor
> efficient.
>

If there was a builtin that did it, it would simply need to do the same
loop. The memory representation is not the same.

Thomas

-- 
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] Is there a function in standard lib to convert []T to a []interface{}?

['Thomas Bushnell, BSG' via golang-nuts]

Don't confuse variadic arguments with slice arguments, by the way.

On Wed, Aug 3, 2016 at 8:20 AM T L  wrote:

>
>
> On Wednesday, August 3, 2016 at 10:53:34 PM UTC+8, Jessta wrote:
>
>> On 4 Aug 2016 12:36 a.m., "T L"  wrote:
>> >
>> > Often, I need converting a []T to []interface{} to use the []interface
>> as a variable length parameter.
>> > But converting a []T for []interface{} in a for loop is neither clean
>> nor efficient.
>> >
>> > So is there a function in standard lib to convert []T to a
>> []interface{}?
>> >
>>
>> There is no function and it's not possible to define one in Go.
>>
>> Define your own function for your specific type or avoid []interface{} if
>> you can. Usually what you want is to put a []T in an interface{} and use
>> reflect instead.
>>
>
> fmt.Println needs a []interface{} parameter.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Plurality of package naming

['Thomas Bushnell, BSG' via golang-nuts]

That's advice for a very different style of language than Go.

Go does not have "objects" in the sense of that post. A Go interface, for
example, does not "have lots of instance variables, lots of arguments, and
pass lots of data around probably."

A class is not a struct is not a Go interface.

Thomas

On Tue, Jul 12, 2016 at 4:23 PM Nathan Fisher 
wrote:

> There's a good oop blog article on the caveats of naming classes (struct)
> ending in -er.
>
> http://objology.blogspot.co.uk/2011/09/one-of-best-bits-of-programming-advice.html?m=1
>
> I know the reader/writer interface kind of flies in the face of this but I
> think that's partly associated with it being an interface and its focus on
> one method.
>
> Personally if it's RESTy I'd opt for BlahResource where Blah is the
> resource that it manages which will probably map to an underlying
> serialisable struct with additional REST elements (eg next, self, etc).
>
> On Tue, 12 Jul 2016 at 17:41, Sam Whited  wrote:
>
>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland  wrote:
>> > When does it make sense for a package to be named in plural? For
>> example,
>> > I'm currently working on a MVC framework and for me it makes sense to
>> have a
>> > "controller" package as opposed to "controllers", but I saw that Beego
>> > prefers plural for the same case.
>>
>> Generally speaking, try to consider how your users will write things
>> that use your package and not what's actually in it. For instance,
>> which makes the better API:
>>
>> controller.New()
>>
>> or:
>>
>> controllers.NewController()
>>
>> The second is redundant, so I'd argue that the first one will look
>> better in your users code. However, given the example:
>>
>> byte.Split(b []byte)
>>
>> vs.
>>
>> bytes.Split(b []byte)
>>
>> the second may be more expected because you're operating on a collection.
>>
>> Of course, both of these are just my opinion, but it's just to
>> illustrate how I generally think about picking a name. Instead of
>> "what will my code in the package look like" think "what will my users
>> write using this package?"
>>
>> —Sam
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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] Interface{} constrains on specific types

['Thomas Bushnell, BSG' via golang-nuts]

The trick is to do this:

Decl special_interface

and then special_interface requires an unexported interface which you
implement in the specific (new) types that you can store in the thing.

On Fri, Jun 24, 2016 at 3:10 PM 'Mihai B' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>  I'm developing a json schema generator (json schema from Go ast and the
> other way around). There is a keyword "oneOf" which requires  exactly one
> schema to be valid in this keyword's value. In Go I translate it by using
> an empty interface{}. The issue is that when I convert the interface{} to
> json schema I can only say that the object can be of any type even if I
> know that it can hold only a small subset.
>  Therefore I'm wondering if placing some constrains on the types that
> could be implemented by the interface would be a good idea. For example
> instead of `type interface{}` which implements any type we could define the
> types it can implement (e.g.  type  X interface{T1, T2, T3} ). This way we
> don't have a totally black box so it improves the documentation/semantics
> and we avoid specific bugs using static analysis. Currently the practice
> seems to be documenting the types in pure comments[0] which cannot be
> analysed statically. Another option that I'm considering now is to use the
> empty interface but with specific tags [1] and use an external tool. This
> might have been proposed before but I can't find it on the mailing list.
> What do you think?
>
> [0]  https://golang.org/pkg/go/ast/#Object
> [1]
>
> type Object struct {
> Name string   // declared 
> name
> Decl interface{} 
> `interface:"Field,FuncDecl,LabeledStmt,external.Scope" //
>
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: A proposal for generic in go

['Thomas Bushnell, BSG' via golang-nuts]

Really? How would you implement math.Max with generics?

Thomas

On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov 
wrote:

> https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are
> just two stdlib packages that would greatly benefit from some kind of
> generics. I'm pretty sure there are more packages in the stdlib that would
> be greatly improved. And that's just the standard library.
>
>
> On Tuesday, June 21, 2016 at 5:29:37 PM UTC+3, Henry wrote:
>>
>> You still haven't provided any argument why generics is indispensable.
>>
>> The reason why I am no longer sure about my position in this issue is
>> because -while I agree that generics is useful- I don't think that generics
>> is essential. In fact, all of C++ features are useful and implemented in a
>> very efficient manner, but take a look what happened when you slab that
>> many features together. If you can do away with less, I think you should go
>> for less. The trouble is deprecating language features is a lot harder than
>> deprecating APIs in the standard library, while programming fads come and
>> go.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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