Re: [go-nuts] Is there some kind of memory write protection mechanism?

[Andy Balholm]

There is no guarantee that the unsafe package even exists in every 
implementation of Go. For example, I really doubt that GopherJS has it. But 
that keep GopherJS from being compliant with the Go spec and the Go 1 
compatibility guarantee. (I’m not sure whether GopherJS is to the point of full 
compliance yet, but my point here is that it doesn’t need “unsafe” in order to 
reach that point.)

Andy

> On Feb 26, 2018, at 7:38 AM, d...@veryhaha.com wrote:
> 
> Will the 3 APIs and the unsafe.Pointer be always there?
> Will the "sync/atomic" package get broken?
> This atomic package imports unsafe.

-- 
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 some kind of memory write protection mechanism?

[Andy Balholm]

Oops. I left out a couple words. I meant “does not keep”.

Andy

> On Feb 26, 2018, at 9:23 AM, Andy Balholm  wrote:
> 
> There is no guarantee that the unsafe package even exists in every 
> implementation of Go. For example, I really doubt that GopherJS has it. But 
> that keep GopherJS from being compliant with the Go spec and the Go 1 
> compatibility guarantee. (I’m not sure whether GopherJS is to the point of 
> full compliance yet, but my point here is that it doesn’t need “unsafe” in 
> order to reach that point.)
> 
> Andy
> 
>> On Feb 26, 2018, at 7:38 AM, d...@veryhaha.com wrote:
>> 
>> Will the 3 APIs and the unsafe.Pointer be always there?
>> Will the "sync/atomic" package get broken?
>> This atomic package imports unsafe.
> 

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

Re: [go-nuts] [ANN] oksvg and rasterx; SVG 2.0 path compliant renderer and rasterizer

[Andy Balholm]

So it sounds like the AGPL is a good license to choose if you want to keep your 
code from being used by big companies… ;-)

> On Apr 25, 2018, at 8:48 AM, 'David Chase' via golang-nuts 
>  wrote:
> 
> 
> 
> On Tuesday, April 24, 2018 at 10:45:35 AM UTC-4, matthe...@gmail.com wrote:
> I’m curious if some companies juggle the GPL. I guess if the app is used 
> internally only then there’s no problem with accidentally requiring a 
> proprietary program to be released as source code to the world. I’d have 
> thought the case would be the same with the AGPL. Do people count as 
> individuals in a corporate license with the ability to freely redistribute?
> 
> I can understand completely avoiding the issue. Language is interpretable and 
> only a court or whatever would decide what was really agreed to. The FSF 
> seems to put a lot of work into building up their licenses with legal 
> precedence.
> 
> I have never worked anywhere that could touch AGPL code.
> It was at the level of "just don't, and don't waste anyone's time asking.  
> Don't."
> This is not legal advice, I am just telling you what the policy is/was at all 
> these companies.
> 
> 
> 
> -- 
> 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 does go reverse the order of name and type? "i int" vs "int i"

[Andy Balholm]

It made sense to Ken and Dennis back when C’s type system was a lot simpler 
than it is now, anyway. 

> On Sep 20, 2018, at 7:40 AM, Michael Jones  wrote:
> 
> the other answer is: "for c it made sense to ken and dennis, alas, we are not 
> them"
> 
> On Thu, Sep 20, 2018 at 1:32 AM Eric S. Raymond  > wrote:
> Dan Kortschak  >:
> > To avoid having to have something like this:
> > 
> > http://c-faq.com/decl/spiral.anderson.html 
> > 
> 
> OK, we now have another candidate for the topic of the Mysterious Stranger's
> thumb drive.  A tortuous spiral, drawing the minds of unwary programmers
> into nighted depths of abyssal madness.  I'm really glad I never summoned
> up the nerve to mount the thing.
> -- 
> http://www.catb.org/~esr/ 
> ">Eric S. Raymond
> 
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org 
> Please visit their site and donate: the civilization you save might be your 
> own.
> 
> 
> -- 
> 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. Jones
> michael.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.

[go-nuts] Operators in interfaces

[Andy Balholm]

Warning: yet another generics-related idea ahead. :-)

The motivation for using contracts instead of interfaces as the type 
constraints in the Go 2 generics proposal is the fact that interfaces only 
allow one type of operation: method calls. And we’d like to be able to use 
other operations, such as addition and comparison, in our generic functions. So 
maybe we could extend interfaces to support other operations as well. 

This would be an interesting and useful feature even without generics, though 
probably not worth the cost in complexity by itself. For example, here is a Min 
function written with operator interfaces, but not generics:

type Ordered interface {
<
}

func Min(a, b Ordered) Ordered {
if a < b {
return a
}
return b
}

The presence of an operator in an interface definition would mean that to 
implement the interface, the type must be usable with that operator. The vtable 
for the interface would include an entry for the function that implements that 
operator for the concrete type stored in the interface. When the interface is 
used with that operator, there would first be a check to ensure that the values 
on both sides are the same concrete type; if this fails, there would be a 
panic. Then the function is called much like an ordinary interface method call. 
(== and != would be exceptions, since they already have a defined meaning for 
interfaces. interface { == } would be implemented only by types that can be 
compared for equality, but it should not change the meaning of the == operator.)

The syntax for declaring operator interfaces is a bit of a question; the most 
obvious syntax, as I used in my example, would not interact very well with 
automatic semicolon insertion.

The principle could be extended to other operations beyond the arithmetic and 
comparison operators, perhaps something like this:

interface stringish {
len
[int]byte
}

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.

Re: [go-nuts] Regarding contracts

[Andy Balholm]

That’s a very interesting idea. It would probably need to be extended to allow 
specifying that a type is like multiple types. Then the effective “contract” 
would be the intersection of the operations provided by those types. For 
example, we would want to be able to specify a type that is like both string 
and []byte; it would support len, range, and indexing, but not + or mutation.

Combining this concept with the function syntax from the standard proposal, 
here is what the classic Min function would look like:

func Min(type T like(int, float64))(a, b T) T {
if a < b {
return a
}
return b
}

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.

Re: [go-nuts] Regarding contracts

[Andy Balholm]

I think there are serious issues with your syntax for functions and 
“templates.” For example, there doesn’t seem to be a way to specify that two 
parameters to a function need to be the same type, or that the return type will 
be the same as the parameter. The syntax from the official proposal is superior 
in that regard.

But replacing contracts with “like” definitely sounds like something worth 
investigating.

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.

Re: [go-nuts] Regarding contracts

[Andy Balholm]

I don’t think that generic functions should have access to private fields of 
their type parameters, regardless of what package they are in. 

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.

Re: [go-nuts] Regarding contracts

[Andy Balholm]

That would also be a weakness of most of the other proposals, including my own 
to add operators to interfaces. Contracts are more powerful, at the expense of 
extra complexity.

Andy

> On Oct 18, 2018, at 10:34 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar  wrote:
>> 
>> Instead of specifying the minimal set of operations a type should
>> satisfy, why not describe what the type should look like:
>> 
>> func f(in like T)
> 
> I don't see how this approach can handle multiple types that need to
> work together in some known way, like the Graph/Node/Edge case in the
> design draft.
> 
> 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.

Re: [go-nuts] Avoiding overloading

[Andy Balholm]

It seems to me that what you are proposing with “implements” is not really a 
replacement for contracts. It would do something that contracts don’t (unify 
operators and methods), and it wouldn’t do nearly all of what contracts do 
(clearly define what is expected of type parameters across a wide range of 
possible operations).

As I understand it, the most important function of contracts is to produce 
sensible error messages (as opposed to the ones that C++ templates have become 
infamous for). If it weren’t for that, we could just leave type parameters 
unconstrained, and let the generic function’s body be its own contract. If the 
function uses <, the types passed to it must support <…

Andy

> On Oct 19, 2018, at 1:15 PM, Eric S. Raymond  wrote:
> 
> Ian Denhardt :
>> What would code making use of a `Sortable` type look like? If you can't
>> actually use "implements <" to overload `<`, it's not clear to me what
>> it would actually do?
> 
> Be available to a Sort function.  That is, the requirement "Have a Less()"
> would be replaced by "Have an implements-< method".
> 
> How this is specified at the callsite is a separate question.  I can't
> see any simpler way to do it than writing '<', but if anyone hates
> overloading enough to invent a syntax they can do it ab nd
> I won't complain.
> 
> I'm saying I'd prefer that future to heavyweight contracts.  Surface
> overloading is *not* the important thing about "implements"; having a
> lightweight way to refer to typeclasses like "Sortable" is.
> -- 
>   http://www.catb.org/~esr/";>Eric S. Raymond
> 
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
> 
> 
> -- 
> 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] Avoiding overloading

[Andy Balholm]

There are some contracts in the draft design that can’t be expressed with the 
“implements” syntax as it stands. Some would be fairly simple syntax 
extensions, but others describe the relationship between two types rather than 
just the operations on a single type. No extension of interfaces (except 
perhaps generic interfaces with mutually-referential type parameters) can 
handle those.

The one called convertible is an example of one that would require a fairly 
trivial extension: adding a way to declare that a method implements a type 
conversion. 

For an example of the other kind, take G from the graph example. I don’t think 
any of the alternate proposals can handle that situation (at least not nearly 
as succinctly):

contract G(n Node, e Edge) {
var _ []Edge = n.Edges()
var from, to Node = e.Nodes()
}

Even if we give up on the ability to define relationships between types, adding 
extensions for all the other operations that people will want support for will 
likely take away much of the initial simplicity that makes the “implements” 
syntax attractive—one trivial extension at a time. The “contract” proposal, on 
the other hand, is actually a simple, powerful idea; it's working out the 
implications that ties people’s brains in knots.

Andy


> On Oct 19, 2018, at 9:18 PM, Eric S. Raymond  wrote:
> 
> Andy Balholm :
>> It seems to me that what you are proposing with “implements” is not really a 
>> replacement for contracts. It would do something that contracts don’t (unify 
>> operators and methods), and it wouldn’t do nearly all of what contracts do 
>> (clearly define what is expected of type parameters across a wide range of 
>> possible operations).
> 
> I don't understand the the grounds of this objection.  Can you pose some cases
> you think implements couldn't cover?
> -- 
>   http://www.catb.org/~esr/";>Eric S. Raymond
> 
> My work is funded by the Internet Civil Engineering Institute: 
> https://icei.org
> Please visit their site and donate: the civilization you save might be your 
> own.
> 
> 

-- 
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] Regarding contracts

[Andy Balholm]

Here’s my attempt at streamlining it, as well as adding a way to deal with the 
operator/method dichotomy: 
https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2 


Andy

> On Oct 23, 2018, at 9:37 AM, Burak Serdar  wrote:
> 
> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar  wrote:
>> 
>> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich  wrote:
>>> 
>>> * Burak Serdar  [181018 15:08]:
 tbh, I am not trying to avoid operator overloading, I am trying to
 avoid the contracts. With operator overloading, you can write:
 
 func F(a,b type T like(int,X)) {
   if a>>> ...
   }
 }
 
 provided X is a type that supports <.
>>> 
>>> Are you trying to avoid the concept of contracts or the specific syntax
>>> proposed in the design draft?
>> 
>> 
>> My intent was to use existing types as contracts instead of an
>> abstract contract specification. In this scenario, a contract is a
>> more abstract concept that an interface. Above, type T like(int,X)
>> would mean:
>>  - func F compiles for T=int and T=X
>>  - F can be instantiated for any type derived from int or X
>> So instead of specifying the precise type semantics required by F,
>> you'd approximate the intent and declare that F would work for types
>> that look like int, and X.
>> 
>> When you apply the same idea to structs:
>> 
>> type T like struct {a, b, int}
>> 
>> would mean that T can be substituted by any struct containing two int
>> fields called a and b.
>> 
>> This idea ran into problems later on: I cannot explain simple
>> contracts such as "type T must support ==".
> 
> 
> I typed this up in a more organized way, and it turned out to be an
> alternative declaration for contracts without touching the generics
> parts of the proposal.
> 
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
> 
> -- 
> 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] Regarding contracts

[Andy Balholm]

What I’m doing with structural contracts is basically the same as what you’re 
doing with struct and interface types as contracts, except that (I hope) the 
syntax is a little clearer. 

I added the support for operators basically to avoid having the supportsEqual 
contract as a special case that needs to be built in. Most other operators 
could be handled just as well with an enumerated contract, so maybe it would be 
better to just have supportsEqual or comparable as a built-in contract.

The equivalent to your StrNum example in my syntax would be:

contract num int, int8, int16…

contract StrNum {
num
String() string
}

I was envisioning the type switches being evaluated at compile time if the 
compiler was producing a type-specialized version of the generic function. 
Min(int) would probably produce exactly the same machine code as

func MinInt(a, b int) int {
if a < b {
return a
}
return b
}

Andy

> On Oct 24, 2018, at 9:47 AM, Burak Serdar  wrote:
> 
> On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm  wrote:
>> 
>> Here’s my attempt at streamlining it, as well as adding a way to deal with 
>> the operator/method dichotomy: 
>> https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2
> 
> Thanks!
> 
> However,  I think yours is a somewhat different approach altogether.
> The main idea I have is that existing types should be used as
> contracts.  That means no operators in contracts.
> 
> Also: when you list types in a contract:
> 
> contract X {
>  T1
>  T2
> }
> 
> I defined it to mean that any type satisfying X must satisfy both T1 and T2.
> 
> And with "like" type contract specifications (enumerated contracts)
> 
> contract X like(int,int8,int16...)
> 
> A type satisfying X is a derivative of any one of the types listed. So
> it is possible to write:
> 
> contract StrNum {
>   like(int, int8, int16,...)
>   interface {
>  String() string
>   }
> }
> 
> meaning StrNum must be an integer that implements String()
> 
> The "type switch" for contracts imply that contracts are a runtime
> construct. In my case, contracts are purely compile time.
> 
> 
>> 
>> Andy
>> 
>> On Oct 23, 2018, at 9:37 AM, Burak Serdar  wrote:
>> 
>> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar  wrote:
>> 
>> 
>> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich  wrote:
>> 
>> 
>> * Burak Serdar  [181018 15:08]:
>> 
>> tbh, I am not trying to avoid operator overloading, I am trying to
>> avoid the contracts. With operator overloading, you can write:
>> 
>> func F(a,b type T like(int,X)) {
>>  if a>...
>>  }
>> }
>> 
>> provided X is a type that supports <.
>> 
>> 
>> Are you trying to avoid the concept of contracts or the specific syntax
>> proposed in the design draft?
>> 
>> 
>> 
>> My intent was to use existing types as contracts instead of an
>> abstract contract specification. In this scenario, a contract is a
>> more abstract concept that an interface. Above, type T like(int,X)
>> would mean:
>> - func F compiles for T=int and T=X
>> - F can be instantiated for any type derived from int or X
>> So instead of specifying the precise type semantics required by F,
>> you'd approximate the intent and declare that F would work for types
>> that look like int, and X.
>> 
>> When you apply the same idea to structs:
>> 
>> type T like struct {a, b, int}
>> 
>> would mean that T can be substituted by any struct containing two int
>> fields called a and b.
>> 
>> This idea ran into problems later on: I cannot explain simple
>> contracts such as "type T must support ==".
>> 
>> 
>> 
>> I typed this up in a more organized way, and it turned out to be an
>> alternative declaration for contracts without touching the generics
>> parts of the proposal.
>> 
>> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
>> 
>> --
>> 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] Regarding contracts

[Andy Balholm]

> On Oct 25, 2018, at 6:45 AM, Marvin Renich  wrote:
> 
> The most powerful feature of the contracts described in the original
> design draft is the ability to describe interactions between two types
> in a type specification.  Your proposal doesn't seem to allow this.

See the section of my gist about Contracts on Multiple Types. 
The contract G there is exactly equivalent to the one in the design draft.

> Also, you seem to be trying to use "familiar" Go constructs for your
> contract body, but you mix types, fields, and operators at the same
> syntactical level.  This is bound to be a source of significant
> cognitive load both when writing and reading contracts.

I’ve decided to drop operators from my syntax for structural contracts.
The only one that was really needed was ==, and it would have to be a little 
magic 
in order to allow using the type as a map key as well. 
So now I just have a built-in contract `comparable`.

The only type names that are used in structural contracts are interfaces,
and they are used in the same way as in an interface that embeds another 
interface.
So that should limit the cognitive load somewhat.

> Andy, if your proposal is just taking the design draft and replacing the
> contract syntax, then I like it, but I believe my syntax is
> significantly better.

Yes, that’s my intention.
I personally like how much my proposal can accomplish with so little new syntax.
(Though it’s actually more new syntax than the design draft…
but I expect it’s quite a bit easier to read and write.)

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.

Re: [go-nuts] Regarding contracts

[Andy Balholm]

After giving this some more thought, i’ve changed my syntax for complex 
relationships between types. Now it looks like this:

contract Node {
Edges() []Edge
}

contract Edge {
Nodes() (from, to Node)
}

func ShortestPath(type N Node, E Edge)(src, dst N) []E
Andy

> On Oct 25, 2018, at 9:41 AM, Burak Serdar  wrote:
> 
> On Thu, Oct 25, 2018 at 10:32 AM Andy Balholm  <mailto:andybalh...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Oct 25, 2018, at 6:45 AM, Marvin Renich > <mailto:m...@renich.org>> wrote:
>> 
>> The most powerful feature of the contracts described in the original
>> design draft is the ability to describe interactions between two types
>> in a type specification.  Your proposal doesn't seem to allow this.
>> 
>> 
>> See the section of my gist about Contracts on Multiple Types.
>> The contract G there is exactly equivalent to the one in the design draft.
> 
> I find the idea of defining contracts on multiple types as defined in
> the proposal confusing and counterintuitive.
> 
> As an extension of defining contracts as existing types, you can
> define individual types in terms of existing data structures, and
> define another structure to define the relationship between them:
> 
> contract Node interface(type E Edge) {...}
> contract Edge interface(type N Node) {...}
> type Graph(type N Node, type E Edge) struct {...}
> 
> See the "Mutually referential type parameter..." section in
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3 
> <https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3>
> 
>> 
>> Also, you seem to be trying to use "familiar" Go constructs for your
>> contract body, but you mix types, fields, and operators at the same
>> syntactical level.  This is bound to be a source of significant
>> cognitive load both when writing and reading contracts.
>> 
>> 
>> I’ve decided to drop operators from my syntax for structural contracts.
>> The only one that was really needed was ==, and it would have to be a little 
>> magic
>> in order to allow using the type as a map key as well.
>> So now I just have a built-in contract `comparable`.
>> 
>> The only type names that are used in structural contracts are interfaces,
>> and they are used in the same way as in an interface that embeds another 
>> interface.
>> So that should limit the cognitive load somewhat.
>> 
>> Andy, if your proposal is just taking the design draft and replacing the
>> contract syntax, then I like it, but I believe my syntax is
>> significantly better.
>> 
>> 
>> Yes, that’s my intention.
>> I personally like how much my proposal can accomplish with so little new 
>> syntax.
>> (Though it’s actually more new syntax than the design draft…
>> but I expect it’s quite a bit easier to read and write.)
>> 
>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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] Generics: an unwelcome conclusion and a proposal

[Andy Balholm]

I thought of a way to do something similar to the “implements” proposal without 
introducing operator overloading: turn it around. Instead of letting methods 
implement operators, we could let operators implement methods.

type Lesser(type T) interface {
Less(b T) bool for(<)
}

This interface would be implemented by any type that has an appropriate Less 
method, and by any type that works with the < operator. For example int would 
implement Lesser(int).

It would be nice if we could get rid of the type parameter. One way would be to 
adopt the Self type from Rust:

type Lesser interface {
Less(b Self) bool for (<)
}

For types implementing the interface, Self would be replaced by the 
implementing type:

type vehicle struct {
weight float64
horsepower float64
}

func (v vehicle) Less(b vehicle) bool {
return v.weight < b.weight
}

For code using the interface, Self would be replaced by the interface type; it 
would be as though Lesser had been declared as

type Lesser interface {
Less(b Lesser) bool
}

But if a mis-matched type was passed to Less, it would need to panic. So this 
option (using the Self type) would somewhat reduce compile-time type safety.

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.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Andy Balholm]

The concept of using operators to implement methods cross-pollinated in my mind 
with Patrick’s “Go Generics with Adaptors” thought experiment and produced 
this: https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 


Here is the core of the proposal (the gist of the gist?):

Contracts

In this proposal, a contract is a list of type-specific functions that are 
needed to implement a generic algorithm. Generally, it will contain default 
implementations for these functions, but these are optional. (If default 
implementations are not included, an adapter will always be necessary.) The 
default implementations are unconstrained generic code; if they compile 
successfully with a given set of type parameters, those parameters fulfill the 
contract.

contract Adder(T) {
Zero() T {
return 0
}
Add(a, b T) T {
return a + b
}
}
A generic function that uses a contract calls the functions in the contract to 
perform operations on generic values:

func SumSlice(type T Adder)(s []T) T {
sum := Zero()
for _, t := range s {
sum = Add(sum, t)
}
return sum
}
 
Adaptors

A type that doesn't work with a contract's default implementation can still 
fulfill the contract by means of an adaptor. An adaptor is a type that fulfills 
the interface defined by a contract. When an adaptor is being used, calls to 
the contract’s functions are implemented by calls to the corresponding methods 
of the adaptor’s zero value.

type BigIntAdder struct {}
func (BigIntAdder) Zero() *big.Int { return new(big.Int) }
func (BigIntAdder) Add(a, b *big.Int) *big.Int { return new(big.Int).Add(a, b) }
The adaptor is specified along with the type parameters when instantiating a 
generic function or type:

var bigints []*big.Int
fmt.Println(SumSlice(*big.Int, BigIntAdder)(bigints))
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.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

[Andy Balholm]

It is implicit: the functions defined in the contract are available (in scope) 
in generic functions that use the contract.

I’m thinking about revising how the adaptors work. I might let contracts act as 
adaptors. But I don’t have time to work on it any more today.

Andy 

> On Nov 5, 2018, at 7:59 PM, Lucio  wrote:
> 
> The word "elegant" comes to mind... Comments below.
> 
> On Monday, 5 November 2018 21:47:46 UTC+2, Andy Balholm wrote:
> The concept of using operators to implement methods cross-pollinated in my 
> mind with Patrick’s “Go Generics with Adaptors” thought experiment and 
> produced this: 
> https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 
> <https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890>
> 
> Here is the core of the proposal (the gist of the gist?):
> 
> Contracts
> 
> In this proposal, a contract is a list of type-specific functions that are 
> needed to implement a generic algorithm. Generally, it will contain default 
> implementations for these functions, but these are optional. (If default 
> implementations are not included, an adapter will always be necessary.) The 
> default implementations are unconstrained generic code; if they compile 
> successfully with a given set of type parameters, those parameters fulfill 
> the contract.
> 
> contract Adder(T) {
>   Zero() T {
>   return 0
>   }
>   Add(a, b T) T {
>   return a + b
>   }
> }
> A generic function that uses a contract calls the functions in the contract 
> to perform operations on generic values:
> 
> func SumSlice(type T Adder)(s []T) T {
>   sum := Zero()
>   for _, t := range s {
>   sum = Add(sum, t)
>   }
>   return sum
> }
> I see that in the proposal (nice and short) you imply a relationship between 
> the function invocation and the contract. Is it really implicit (it isn't to 
> my sleep-addled brain) that Zero within SumSlice is restricted by contract 
> Adder, simply because its argument is of type "type T Adder"? I would think 
> that invoking Adder.Zero() or even T.Zero() would be necessary or at least 
> more explicit?
> 
> In other respects, I doff my hat to you, Andy :-).
> 
> The rest of your document (the crucial "adaptors") I still need to assimilate.
> 
> Lucio.
> 
> -- 
> 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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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] Generics: an unwelcome conclusion and a proposal

[Andy Balholm]

I’ve updated my gist at 
https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 
<https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890> to use 
contracts as adaptors.

Andy

> On Nov 6, 2018, at 8:27 PM, Andy Balholm  wrote:
> 
> It is implicit: the functions defined in the contract are available (in 
> scope) in generic functions that use the contract.
> 
> I’m thinking about revising how the adaptors work. I might let contracts act 
> as adaptors. But I don’t have time to work on it any more today.
> 
> Andy 
> 
>> On Nov 5, 2018, at 7:59 PM, Lucio > <mailto:lucio.d...@gmail.com>> wrote:
>> 
>> The word "elegant" comes to mind... Comments below.
>> 
>> On Monday, 5 November 2018 21:47:46 UTC+2, Andy Balholm wrote:
>> The concept of using operators to implement methods cross-pollinated in my 
>> mind with Patrick’s “Go Generics with Adaptors” thought experiment and 
>> produced this: 
>> https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890 
>> <https://gist.github.com/andybalholm/acecba3acf57bf1254142dadce928890>
>> 
>> Here is the core of the proposal (the gist of the gist?):
>> 
>> Contracts
>> 
>> In this proposal, a contract is a list of type-specific functions that are 
>> needed to implement a generic algorithm. Generally, it will contain default 
>> implementations for these functions, but these are optional. (If default 
>> implementations are not included, an adapter will always be necessary.) The 
>> default implementations are unconstrained generic code; if they compile 
>> successfully with a given set of type parameters, those parameters fulfill 
>> the contract.
>> 
>> contract Adder(T) {
>>  Zero() T {
>>  return 0
>>  }
>>  Add(a, b T) T {
>>  return a + b
>>  }
>> }
>> A generic function that uses a contract calls the functions in the contract 
>> to perform operations on generic values:
>> 
>> func SumSlice(type T Adder)(s []T) T {
>>  sum := Zero()
>>  for _, t := range s {
>>  sum = Add(sum, t)
>>  }
>>  return sum
>> }
>> I see that in the proposal (nice and short) you imply a relationship between 
>> the function invocation and the contract. Is it really implicit (it isn't to 
>> my sleep-addled brain) that Zero within SumSlice is restricted by contract 
>> Adder, simply because its argument is of type "type T Adder"? I would think 
>> that invoking Adder.Zero() or even T.Zero() would be necessary or at least 
>> more explicit?
>> 
>> In other respects, I doff my hat to you, Andy :-).
>> 
>> The rest of your document (the crucial "adaptors") I still need to 
>> assimilate.
>> 
>> Lucio.
>> 
>> -- 
>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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 conversion between int and uint a no-op i.e. is it free

[Andy Balholm]

There is nothing in the language spec that guarantees anything about 
performance. But if logic tells you that it should be a no-op, and examination 
of the generated code shows you that it is a no-op in the cases you tested, you 
can safely assume that it is not going to be an issue for your program’s 
performance.

Andy

> On Nov 24, 2018, at 8:45 AM, Ugorji Nwoke  wrote:
> 
> Thanks so much Silviu. I love this tool - I had seen it before, but didn't 
> realize it also supported go language. Thanks so much for bringing it up - it 
> should help me do more investigation on my own faster.
> 
> I used it to compare the asm output, and I got the same thing as when I did 
> go build -gcflags "-S" num_conversion.go
> 
> i.e. it leads me to conclude, as I suspected, that conversion from int to 
> uint is free (no-op at runtime). 
> 
> However, I get concerned that my proof may be insufficient, or there may be 
> other reason why the asm looks same, and that is why I wanted a definitive 
> answer from someone familiar with the internals.
> 
> 
> On Saturday, November 24, 2018 at 11:28:43 AM UTC-5, Silviu Capota Mera wrote:
> A very nice tool from Matt Godbolt (and team of volunteers): 
> https://godbolt.org/z/4nt5cJ 
> 
> You can switch compiler version (e.g. Go 1.4, 1.7, 1.9, 1.11, tip, etc) 
> and/or gccgo, take a look at variations, etc
> 
> On Saturday, 24 November 2018 11:07:51 UTC-5, Jan Mercl wrote:
> On Sat, Nov 24, 2018 at 4:31 PM Ugorji Nwoke > wrote:
> 
> > Jan, you and I have the same understanding i.e. float <-> int is obviously 
> > non-free, but I can't think of why int <-> uint will not be free. However, 
> > I want someone with knowledge of the 
>  > compiler/runtime/codegeneration/SSA internals that can give me a 
> definitive answer. 
> 
> Any correct compiler is an implementation of the language specification. 
> >From the language specification it follows that the compiler _may_ check 
> that - for example - 42 != 314 or 278 == 278 while performing the 'uint' <-> 
> 'int" conversion. It may also try to factor M4170639287. The question is why 
> to do so when nothing of that is mandated by the language specification for a 
> correct implementation?
> 
> The next reasonable step is to assume Occam's razor is a thing.
> 
> -- 
> -j
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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] Strange behaviour of left shift

[Andy Balholm]

Apparently in your code the value is being assigned to an int. But it’s too 
large for an int; it needs a uint64 to hold it.

Andy

> On Dec 5, 2018, at 8:35 AM, Michel Levieux  wrote:
> 
> Hi guys,
> 
> With a colleague of mine, we've run into a strange issue today. When we look 
> at package math, in const.go, we can see this line :
> 
> MaxUint64 = 1<<64 - 1
> 
> which I assume works pretty well. But if I do the same in a test main and try 
> to 'go run' it, with this line :
> 
> const v = 1 << 64 - 1
> 
> I get the following error :
> 
> ./testmain.go:8:13: constant 18446744073709551615 overflows int
> 
> I think this is not a bug and we're just missing something here. Could anyone 
> explain this behaviour / point me to a documentation that explains it?
> 
> Thank you guys
> 
> -- 
> 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] Strange behaviour of left shift

[Andy Balholm]

When an untyped integer constant is converted to a typed value, it always 
becomes int. I suppose the rules could be made more complicated to handle 
values that won’t fit in an int. But what if the value is too big to fit in a 
uint64? Should it be a float64 then?

Andy

> On Dec 5, 2018, at 8:54 AM, Michel Levieux  wrote:
> 
> Well the only thing I do in the main is :
> 
> fmt.Println(v)
> 
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
> 
> Le mer. 5 déc. 2018 à 17:45, Andy Balholm  <mailto:andybalh...@gmail.com>> a écrit :
> Apparently in your code the value is being assigned to an int. But it’s too 
> large for an int; it needs a uint64 to hold it.
> 
> Andy
> 
>> On Dec 5, 2018, at 8:35 AM, Michel Levieux > <mailto:m.levi...@capitaldata.fr>> wrote:
>> 
>> Hi guys,
>> 
>> With a colleague of mine, we've run into a strange issue today. When we look 
>> at package math, in const.go, we can see this line :
>> 
>> MaxUint64 = 1<<64 - 1
>> 
>> which I assume works pretty well. But if I do the same in a test main and 
>> try to 'go run' it, with this line :
>> 
>> const v = 1 << 64 - 1
>> 
>> I get the following error :
>> 
>> ./testmain.go:8:13: constant 18446744073709551615 overflows int
>> 
>> I think this is not a bug and we're just missing something here. Could 
>> anyone explain this behaviour / point me to a documentation that explains it?
>> 
>> Thank you guys
>> 
>> -- 
>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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] Strange behaviour of left shift

[Andy Balholm]

That would definitely be possible. But it isn’t likely to happen. It would make 
the rule several times more complicated that it currently is, to fix something 
that only happens occasionally, is caught at compile time, and is easily taken 
care of with an explicit type conversion. That doesn’t sound like the kind of 
tradeoff that would be accepted in Go.

One issue is that the type of the expression would change depending on what CPU 
the program is being compiled for. I don’t think that happens anywhere else in 
Go, except when using build tags.

Andy

> On Dec 6, 2018, at 8:45 AM, Michel Levieux  wrote:
> 
> Would it be possible in the future that the compiler holds a set of the 
> possible types for a given untyped value, and assigns it the "minimum" type 
> if int does not belong to the possible ones? this holds only for integer 
> types of course. In the current example we'd have :
> 
> 1 << 64 - 1 is integer so it should be int
> 1 << 64 - 1 has possible types uint (on a 64 bits machine) and uint64 - 
> therefore int does not belong to the set of possible types, uint is the 
> "minimum" type it can take
> --> when used, 1 << 64 - 1 takes type uint by default (on a 64 bits machine - 
> otherwise it would take uint64)
> 
> Le jeu. 6 déc. 2018 à 03:15, Louki Sumirniy  > a écrit :
> The implicit type inferred from an integer is always 'int'. This is a 64 bit 
> signed integer and thus has a maximum width of 63 bits. In Go, you should not 
> assume sign or width of an untyped implicit conversion, as the 'int' and 
> 'uint' types default to the size of processor registers, which are 64 bits. 
> Making this assumption will have undefined results depending on the platform.
> 
> I'm not sure why it works now but I encountered this problem with 
> cross-compilation, as the program had an `int` that was assumed to be over 32 
> bits long and it refused to compile. It appears to me that there must have 
> been a recent change to implement 64 bit integers on 32 bit platforms.
> 
> I have a general policy with integers and Go, if I know it might be bigger 
> than 32 bits, I specify the type. If it's a simple counter and unlikely to 
> get anywhere near this, I can leave out the type spec. Also, to reduce 
> confusion and ambiguity, if I am using shift operators I also specify 
> unsigned. On the hardware level, most platforms are implementing bitshifts 
> with multiplication. But sometimes not, also. The reason to use >> and << 
> should be to use, if available, the hardware's shift operator, as it 
> otherwise falls back to multiplication.
> 
> On Wednesday, 5 December 2018 17:36:32 UTC+1, Michel Levieux wrote:
> Hi guys,
> 
> With a colleague of mine, we've run into a strange issue today. When we look 
> at package math, in const.go, we can see this line :
> 
> MaxUint64 = 1<<64 - 1
> 
> which I assume works pretty well. But if I do the same in a test main and try 
> to 'go run' it, with this line :
> 
> const v = 1 << 64 - 1
> 
> I get the following error :
> 
> ./testmain.go:8:13: constant 18446744073709551615 overflows int
> 
> I think this is not a bug and we're just missing something here. Could anyone 
> explain this behaviour / point me to a documentation that explains it?
> 
> Thank you guys
> 
> -- 
> 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] What are the reasonable reasons to use pointers?

[Andy Balholm]

Some languages, like Java, don’t have explicit pointer types. But they do it by 
making almost everything an implicit pointer.

Andy

> On Jan 1, 2019, at 9:13 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> 
> On Tue, Jan 1, 2019 at 12:34 PM 伊藤和也  > wrote:
> 
> > What are the reasonable reasons to use pointers? Are pointers neseccary?
> 
> Yes, they're necessary in non-trivial programs. Without pointers any program 
> can use only (named) variables declared in the program. Pointers allow 
> creating (anonymous) variables at run time accessed via the pointer. Many 
> useful data structures rely on variables dynamically allocated at run time.
> -- 
> -j
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 are the reasonable reasons to use pointers?

[Andy Balholm]

And yet Knuth wrote TeX with virtually no pointers, because he didn’t trust the 
dynamic memory allocators in many Pascal implementations (probably from bitter 
experience). So he used array indices as s substitute for pointers.

Andy

> On Jan 2, 2019, at 3:13 AM, Chris FractalBach  wrote:
> 
> "I do consider assignment statements and pointer variables to be among 
> computer science's "most valuable treasures.""
> Donald Knuth, Structured Programming with go to Statements
> 
> -- 
> 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] C++ 11 to Golang convertor

[Andy Balholm]

I’ve been working on a tool (called leaven) to convert LLVM IR (intermediate 
representation) to Go. So you can compile C to LLVM with clang, and then 
convert the result to Go. It’s actually pretty easy, because LLVM instructions 
are such simple operations. But it’s not very readable; given this:

int strcmp(const char *l, const char *r)
{
for (; *l==*r && *l; l++, r++);
return *(unsigned char *)l - *(unsigned char *)r;
}

It produces this:

func strcmp(v0 *byte, v1 *byte) int32 {
var v10, v11, v12, v13 *byte
var v5, v6, v7, v16, v17, v18 bool
var v3, v4, v14, v15, v21, v22 byte
var v23, v24, v25 int32

_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ = v3, v4, v5, 
v6, v7, v10, v11, v12, v13, v14, v15, v16, v17, v18, v21, v22, v23, v24, v25

v3 = *v0
v4 = *v1
v5 = v3 != v4
v6 = v3 == 0
v7 = v6 || v5
if v7 {
v21, v22 = v3, v4
goto block20
} else {
goto block8
}

block8:
v10, v11 = v1, v0
goto block9

block9:
v12 = (*byte)(unsafe.Pointer(uintptr(unsafe.Pointer(v11)) + 
1*unsafe.Sizeof(*(*byte)(nil
v13 = (*byte)(unsafe.Pointer(uintptr(unsafe.Pointer(v10)) + 
1*unsafe.Sizeof(*(*byte)(nil
v14 = *v12
v15 = *v13
v16 = v14 != v15
v17 = v14 == 0
v18 = v17 || v16
if v18 {
goto block19
} else {
v10, v11 = v13, v12
goto block9
}

block19:
v21, v22 = v14, v15
goto block20

block20:
v23 = int32(uint32(v21))
v24 = int32(uint32(v22))
v25 = v23 - v24
return v25
}

But it works! 

I’ve never tried it with a C++ program, but once it’s compiled down to LLVM, 
there shouldn’t be much difference.

Whether it is anything like what you are looking for depends on your goals for 
the translation. (Though it’s almost certainly not complete enough yet.)

If your goal is to produce maintainable Go source that maintains the general 
appearance of the C++ original, you will need to build a custom tool that 
recognizes the idioms of your codebase and converts them to equivalent Go 
idioms, like Russ Cox did for translating the Go compiler. But keep in mind 
that he had the unfair advantage that he was translating C written by Go 
programmers.

I don’t think a general-purpose tool to convert C or C++ into maintainable Go 
is possible. As you handle more of the odd corner cases of C, the output looks 
more and more like machine code. Leaven skips that painful journey and produces 
asm.go (by analogy with asm.js) from day 1.

Leaven isn’t really ready for general use, but I decided to throw it on GitHub 
in response to your question. It’s at https://github.com/andybalholm/leaven 
, for whatever it’s worth. I haven’t 
gotten around to adding a README or a license, but I’m planning to use the MIT 
license.

Andy

> On Jan 2, 2019, at 8:03 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Jan 2, 2019 at 7:37 PM  wrote:
>> 
>> I have C++ 11 source files which I need to convert to Go language code
>> Is there any converter  tool for this.
>> I google quite a few tools, none seems powerful and complete enough to do 
>> the job.for me.
> 
> C++ 11 is a much more complex language than Go.  I think that if you
> want to support all the features of C++11 this would essentially
> require writing a C++11 compiler that generates Go code as its output.
> I don't know of any such tool.
> 
> 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.

Re: [go-nuts] C++ 11 to Golang convertor

[Andy Balholm]

You don’t use CGo; you just translate all the libraries you depend on as well. 
:-P

But you’re definitely right about pthreads; that would be a nightmare.

Andy

> On Jan 3, 2019, at 10:01 AM, Robert Engels  wrote:
> 
> I am pretty sure the other task is impossible, unless the generated code used 
> CGo for all of its work. 
> 
> It gets really difficult for multithreaded apps, pthread does not translate 
> to Go routines, no TLS, etc.
> 
> I think correcting the converted Go would be more daunting that just 
> rewriting it in Go to begin with. 
> 
> On Jan 3, 2019, at 11:33 AM, Andy Balholm  <mailto:andybalh...@gmail.com>> wrote:
> 
>> I’ve been working on a tool (called leaven) to convert LLVM IR (intermediate 
>> representation) to Go. So you can compile C to LLVM with clang, and then 
>> convert the result to Go. It’s actually pretty easy, because LLVM 
>> instructions are such simple operations. But it’s not very readable; given 
>> this:
>> 
>> int strcmp(const char *l, const char *r)
>> {
>>  for (; *l==*r && *l; l++, r++);
>>  return *(unsigned char *)l - *(unsigned char *)r;
>> }
>> 
>> It produces this:
>> 
>> func strcmp(v0 *byte, v1 *byte) int32 {
>>  var v10, v11, v12, v13 *byte
>>  var v5, v6, v7, v16, v17, v18 bool
>>  var v3, v4, v14, v15, v21, v22 byte
>>  var v23, v24, v25 int32
>> 
>>  _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ = v3, v4, v5, 
>> v6, v7, v10, v11, v12, v13, v14, v15, v16, v17, v18, v21, v22, v23, v24, v25
>> 
>>  v3 = *v0
>>  v4 = *v1
>>  v5 = v3 != v4
>>  v6 = v3 == 0
>>  v7 = v6 || v5
>>  if v7 {
>>  v21, v22 = v3, v4
>>  goto block20
>>  } else {
>>  goto block8
>>  }
>> 
>> block8:
>>  v10, v11 = v1, v0
>>  goto block9
>> 
>> block9:
>>  v12 = (*byte)(unsafe.Pointer(uintptr(unsafe.Pointer(v11)) + 
>> 1*unsafe.Sizeof(*(*byte)(nil
>>  v13 = (*byte)(unsafe.Pointer(uintptr(unsafe.Pointer(v10)) + 
>> 1*unsafe.Sizeof(*(*byte)(nil
>>  v14 = *v12
>>  v15 = *v13
>>  v16 = v14 != v15
>>  v17 = v14 == 0
>>  v18 = v17 || v16
>>  if v18 {
>>  goto block19
>>  } else {
>>  v10, v11 = v13, v12
>>  goto block9
>>  }
>> 
>> block19:
>>  v21, v22 = v14, v15
>>  goto block20
>> 
>> block20:
>>  v23 = int32(uint32(v21))
>>  v24 = int32(uint32(v22))
>>  v25 = v23 - v24
>>  return v25
>> }
>> 
>> But it works! 
>> 
>> I’ve never tried it with a C++ program, but once it’s compiled down to LLVM, 
>> there shouldn’t be much difference.
>> 
>> Whether it is anything like what you are looking for depends on your goals 
>> for the translation. (Though it’s almost certainly not complete enough yet.)
>> 
>> If your goal is to produce maintainable Go source that maintains the general 
>> appearance of the C++ original, you will need to build a custom tool that 
>> recognizes the idioms of your codebase and converts them to equivalent Go 
>> idioms, like Russ Cox did for translating the Go compiler. But keep in mind 
>> that he had the unfair advantage that he was translating C written by Go 
>> programmers.
>> 
>> I don’t think a general-purpose tool to convert C or C++ into maintainable 
>> Go is possible. As you handle more of the odd corner cases of C, the output 
>> looks more and more like machine code. Leaven skips that painful journey and 
>> produces asm.go (by analogy with asm.js) from day 1.
>> 
>> Leaven isn’t really ready for general use, but I decided to throw it on 
>> GitHub in response to your question. It’s at 
>> https://github.com/andybalholm/leaven 
>> <https://github.com/andybalholm/leaven>, for whatever it’s worth. I haven’t 
>> gotten around to adding a README or a license, but I’m planning to use the 
>> MIT license.
>> 
>> Andy
>> 
>>> On Jan 2, 2019, at 8:03 PM, Ian Lance Taylor >> <mailto:i...@golang.org>> wrote:
>>> 
>>> On Wed, Jan 2, 2019 at 7:37 PM >> <mailto:aureallm2...@gmail.com>> wrote:
>>>> 
>>>> I have C++ 11 source files which I need to convert to Go language code
>>>> Is there any converter  tool for this.
>>>> I google quite a few tools, none seems powerful and complete enough to do 
>>>> th

Re: [go-nuts] C++ 11 to Golang convertor

[Andy Balholm]

It’s at https://github.com/rsc/c2go . It might be 
a good starting place, but there is one significant difference in approach from 
what Eric is proposing. Russ incorporated all of the manual cleanup into the 
tool (or config files) as special cases, rather than leaving it as manual 
cleanup.

Andy

> On Jan 3, 2019, at 3:14 PM, Valentin Vidic  wrote:
> 
> On Thu, Jan 03, 2019 at 02:46:39PM -0800, Eric Raymond wrote:
>> On the other hand, I believe graceful, comment-preserving C to idiomatic-Go 
>> transpilation is almost possible.  By 'almost' I mean that the tool would 
>> pass through a small enough percentage of untranslated residuals for 
>> corrections to be around a 5% job for a human expert. 
>> 
>> I've had a lot of incentive to think about this because my concerns center 
>> around vast masses of C infrastructure code in critical network services 
>> like NTP, DNS, etc.  The security and reliability consequences of unsafe 
>> code in that swamp are serious and it needs to be drained.  Transpilation 
>> to golang is, I think, the first realistic hope we've  had of doing that 
>> without a prohibitively high labor input. 
>> 
>> By possible I do not mean easy.  I've scoped the job and done a design 
>> sketch. I think my qualifications for writing such a transpiler are 
>> exceptionally good, but it would nevertheless take me a minimum of two 
>> years of hard work to get there.   I have put put some feelers for 
>> funding;  if I get to choose my next major project after NTPsec, this would 
>> be it.
> 
> Golang compiler was converted from C to Go in some version, but I don't know
> if the tool used there is available somewhere.
> 
> -- 
> Valentin
> 
> -- 
> 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] C++ 11 to Golang convertor

[Andy Balholm]

Yes, the preprocessor…

The preprocessor is one of the biggest obstacles to readable C-to-Go 
translation. rsc/c2go largely ignores preprocessor directives other than 
#include—and it doesn’t include a translation of the headers at the top of 
every output file. But most C programs are a lot more dependent on the 
preprocessor than gc was. So every other C-to-Go tool I’ve seen works from 
preprocessed source. So they tend to dump a translation of most of /usr/include 
at the top of the file. (Leaven doesn’t, though, because clang optimizes most 
of that stuff back out.) And some functions are halfway to machine code by the 
time all the macros are expanded.

A good translation from C to Go needs to look as much like the original, 
un-preprocessed C source as possible. But a powerful translation tool will 
probably need to preprocess, parse, and typecheck the code, while keeping track 
of the source location that everything corresponds to—and then use that 
information to guide the translation.

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.

Re: [go-nuts] Using "er" and "able" for interfaces

[Andy Balholm]

The -er suffix makes sense when you think of a method invocation as a command, 
telling an object to do something. This was definitely the model in Smalltalk, 
where people called them “messages.” In Go, methods are more like functions 
than in Smalltalk, but some of the idea remains in the naming convention.

Andy

> On Jan 18, 2019, at 9:28 AM, robert engels  wrote:
> 
> Yes, the method should be called read() - the debate is if it should be 
> Reader or Readable. I prefer the able because it says to me, if something 
> implements Readable, then any methods defined by Readable I can call - 
> regardless of the method name.
> 
> It gets more important for interfaces like Partionable, because typically the 
> methods implemented do not do the partitioning (that would be a Partitioner) 
> - they instead return the metadata that allows a “Partitioner” to partition 
> and Partitionable structure.
> 
> To me, this is a better design in most cases - you don’t want the object 
> doing the actual partitioning. So in Go parlance, the interface would 
> probably be called PartitionMetaDataProvider.
> 
> 
> 
>> On Jan 18, 2019, at 10:43 AM, Robert Johnstone > > wrote:
>> 
>> Hello,
>> 
>> Just to paint the bikeshed...  
>> 
>> The -er suffix makes sense for methods that follow the convention of naming 
>> methods after verbs.  Forget io.Reader for a moment, and think of os.File.  
>> When you call the method Read, you are asking the instance to read from the 
>> file on disk.  myvar.Read can be understood as subject/verb.  In this case, 
>> myvar is the reader, but it is passing the data back to you.  
>> 
>> Robert
>> 
>> 
>> 
>> On Thursday, 17 January 2019 14:48:30 UTC-5, Jakob Borg wrote:
>> On 16 Jan 2019, at 15:42, Victor Giordano > wrote:
>>> 
>>> As far i can get to understand the english language (i'm not a native 
>>> speaker), the "er" seems to denotes or describe things in a more "active 
>>> way" (the thing that they actually do by itself), and the "able" describes 
>>> things in a more "passive way"  (the thing that you can "ask it/his/her" to 
>>> do). Do you find this appreciation correct?
>> 
>> This was a mental stumbling block for me for a long time when I started out 
>> with Go. For me, the "Reader" is the one who calls Read(), so an io.Reader 
>> seemed like the opposite of what I wanted. I would have better understood it 
>> as io.Readee. It works out better if I see the Reader as some sort of 
>> intermediate entity that affects reads on whatever the underlying thing is 
>> you want to read from… Or if I see it as just an interface-indicating 
>> nonsense suffix, like a capital-I prefix…
>> 
>> //jb
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> 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.

[go-nuts] brotli: my c2go experience

[Andy Balholm]

Over the last few months, I’ve been working (on and off) at translating the 
Brotli compression library into Go. (The result is at 
github.com/andybalholm/brotli.) I’d like to share what I’ve learned.

I tried various tools: rsc/c2go, elliotchance/c2go, Konstantin8105/c4go, and a 
tool that I developed myself (leaven). I kept coming back to rsc/c2go because 
it produces the cleanest, most readable output. But I was frustrated by its 
limitations; there are so many C constructs that it can’t handle.

Finally I realized that the only way a C-to-Go transpiler can produce readable 
output is to limit itself to the subset of C that maps to Go fairly cleanly. 
And the way to deal with that is to progressively refactor the C project into 
that subset of C.

In practice, it turned out to be a two-sided process. I worked on c2go to make 
it handle more of the constructs used in brotli, and I refactored the brotli 
codebase to get rid of things c2go couldn’t handle, until the two converged.

My fork of rsc/c2go is at github.com/andybalholm/c2go; the README contains some 
more of my thoughts on the transpilation process, and a general summary of how 
to go about translating a C project.

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.

[go-nuts] Re: brotli: my c2go experience

[Andy Balholm]

Now for some benchmarks. I wrote a simple benchmark program that compares my 
pure Go brotli package with cbrotli (the cgo wrapper in the standard brotli 
repo) and with compress/gzip. Here are the results for compressing Newton’s 
Opticks (from the testdata directory of the Go source tree):

brotli-037.9%   10.611264ms 51.0 MB/s
brotli-133.9%   12.440498ms 43.5 MB/s
brotli-232.2%   32.232898ms 16.8 MB/s
brotli-331.8%   32.788896ms 16.5 MB/s
brotli-431.0%   41.686392ms 13.0 MB/s
brotli-529.0%   52.108321ms 10.4 MB/s
brotli-628.4%   61.75893ms  8.8 MB/s
brotli-727.9%   77.842721ms 6.9 MB/s
brotli-827.7%   101.626643ms5.3 MB/s
brotli-927.5%   118.482597ms4.6 MB/s
brotli-10   25.6%   897.835046ms0.6 MB/s
brotli-11   25.0%   2.13944223s 0.3 MB/s

cbrotli-0   37.9%   9.664506ms  56.0 MB/s
cbrotli-1   33.9%   11.348875ms 47.7 MB/s
cbrotli-2   32.2%   29.9876ms   18.0 MB/s
cbrotli-3   31.8%   36.219238ms 14.9 MB/s
cbrotli-4   31.0%   44.791383ms 12.1 MB/s
cbrotli-5   29.0%   57.329373ms 9.4 MB/s
cbrotli-6   28.4%   58.928917ms 9.2 MB/s
cbrotli-7   27.9%   76.804601ms 7.0 MB/s
cbrotli-8   27.7%   100.928546ms5.4 MB/s
cbrotli-9   27.5%   122.621637ms4.4 MB/s
cbrotli-10  25.6%   916.783042ms0.6 MB/s
cbrotli-11  25.0%   2.091093825s0.3 MB/s

gzip-1  38.5%   9.548712ms  56.6 MB/s
gzip-2  34.9%   11.672584ms 46.3 MB/s
gzip-3  34.1%   14.940402ms 36.2 MB/s
gzip-4  31.9%   15.40793ms  35.1 MB/s
gzip-5  30.9%   25.36402ms  21.3 MB/s
gzip-6  30.7%   31.563463ms 17.1 MB/s
gzip-7  30.6%   37.404353ms 14.5 MB/s
gzip-8  30.6%   45.647576ms 11.8 MB/s
gzip-9  30.6%   47.600027ms 11.4 MB/s
 

> On Mar 16, 2019, at 3:55 PM, Andy Balholm  wrote:
> 
> Over the last few months, I’ve been working (on and off) at translating the 
> Brotli compression library into Go. (The result is at 
> github.com/andybalholm/brotli.) I’d like to share what I’ve learned.
> 
> I tried various tools: rsc/c2go, elliotchance/c2go, Konstantin8105/c4go, and 
> a tool that I developed myself (leaven). I kept coming back to rsc/c2go 
> because it produces the cleanest, most readable output. But I was frustrated 
> by its limitations; there are so many C constructs that it can’t handle.
> 
> Finally I realized that the only way a C-to-Go transpiler can produce 
> readable output is to limit itself to the subset of C that maps to Go fairly 
> cleanly. And the way to deal with that is to progressively refactor the C 
> project into that subset of C.
> 
> In practice, it turned out to be a two-sided process. I worked on c2go to 
> make it handle more of the constructs used in brotli, and I refactored the 
> brotli codebase to get rid of things c2go couldn’t handle, until the two 
> converged.
> 
> My fork of rsc/c2go is at github.com/andybalholm/c2go; the README contains 
> some more of my thoughts on the transpilation process, and a general summary 
> of how to go about translating a C project.
> 
> 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.

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

[Andy Balholm]

Even “go game of life” works. Some search engines may treat “of” as a stopword, 
but Google gives it some weight.

Andy

> On Jul 25, 2017, at 4:18 PM, Skip Tavakkolian  
> wrote:
> 
> I was specifically referring to things posted to this list to avoid the old 
> chestnut about search.
> 
> For what it's worth, I don't buy that argument either. Searching for "game of 
> life in go language" works just as well. Correctness matters even when nobody 
> is looking.
> 
> On Tue, Jul 25, 2017, 2:47 PM mailto:oju...@gmail.com>> 
> 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 
> .

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

[Andy Balholm]

It’s not quite true that the compiler doesn’t care about white space. The lexer 
is part of the compiler, and it does care about white space. The semicolon 
insertion rule, in particular, pays attention to newlines. So, while the 
compiler doesn’t care about indentation at all, there are some 
brace/indentation styles that it will not accept. One of those is Allman style.

> On Jul 29, 2017, at 1:13 PM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Sat, Jul 29, 2017 at 7:36 PM  > 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 ?
> 
> Let me pick just one misconception. The compiler does not care about 
> formatting style at all - because it cannot see it! Token sequences have no 
> style as they contain no white space or any other kind of token separators. 
> It's just tokens. All the way down.
> 
> The specification prescribes how the source code text is transformed into the 
> token sequence the compiler only cares about. It's different in details, but 
> conceptually it's just a transformation stage in the sense of what the 
> specification of the, for example, C language prescribes.
> 
> You may dislike the specification, but you can hardly argue it's not well 
> thought out and reasonable as a trade-off between mandatory semicolons (pre 
> Go 1 had them) and almost no need to write them in exchange for adjusting to 
> the implications and/or costs of that comfort.
> 
> If Go changed its specification such that the left brace of a statement block 
> must be on its own line, it'll take me probably just a few minutes to adapt 
> and forget about it completely, because it's such an unimportant detail 
> compared to what I love about Go. Why some others cannot do the same is 
> beyond my comprehension, but that's by definition my fault, admitted.
> 
> -- 
> -j
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

[Andy Balholm]

I’ve always considered the lexer to be part of the compiler, and apparently 
Ecstatic Coder does too, considering his complaint.

Andy

> On Jul 29, 2017, at 2:58 PM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Sat, Jul 29, 2017 at 10:43 PM Andy Balholm  <mailto:andybalh...@gmail.com>> wrote:
> 
> > It’s not quite true that the compiler doesn’t care about white space. The 
> > lexer is part of the compiler, and it does care about white space. The 
> > semicolon insertion rule, in particular, pays attention to newlines. So, 
> > while the compiler doesn’t care about indentation at all, there are some 
> > brace/indentation styles that it will not accept. One of those is Allman 
> > style.
> 
> That's why it was compared to the processing according to the C 
> specification. Only at phase 7 is "The resulting tokens are syntactically and 
> semantically analyzed and translated as a translation unit." performed. The 
> previous 6 phases used to be actually a separate program/programs running 
> before the compiler (phase 7) was invoked. Putting it all in one black box 
> does not necessarily blur the conceptual separation. Most compilers _can_ 
> work without a lexer, they could directly consume token sequences just 
> happily. It's just no more practical to separate the pieces.
> 
> -- 
> -j
> 

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

Re: [go-nuts] Storing uint64 values in DB

[Andy Balholm]

var i uint64
var j int64
…
j = int64(i)

This performs the same conversion that C would do automatically when assigning 
i to j, but Go requires you to be a little more explicit.

> On Jul 29, 2017, at 6:54 PM, Tong Sun  wrote:
> 
> Neither PostgreSQL[1] nor SQLite[2] support unsigned 64-bit integers at the 
> SQL level. 
> However, I do need to save those unsigned 64-bit integers as-is into 
> database, as they are not numbers but hash values. 
> 
> What's the proper way to cast my uint64 as database signed integer and back 
> safely in Go? 
> 
> Let's use 8-bit variable as example, in C, I just assign the unsigned 8-bit 
> variable to a signed 8-bit variable, so 255 will "looks like" -1 when in 
> latter form. However, no info is lost, and when I assign it back from signed 
> 8-bit variable, I'm still getting 255. How to do the same thing in Go? 
> 
> Thanks
> 
> [1] 
> https://stackoverflow.com/questions/21909027/postgres-data-types-how-to-store-uint64-in-postresql
> [2] https://sqlite.org/datatype3.html
> 
> 
> -- 
> 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] Do you guys use ORMs when working with SQL?

[Andy Balholm]

> Why would someone want to switch from PostgreSQL to MySQL?

I recently switched a project from PostgreSQL to MySQL. But I sure can’t say I 
*wanted* to. We were integrating a dependency that only supports MS SQL Server 
and MySQL.

-- 
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] "html/dom" alternative to html/template for true separation of concerns?

[Andy Balholm]

It sounds like what you’re wanting to do is basically what is called Template 
Animation at 
http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you
 


You might be interested in goquery (github.com/PuerkitoBio/goquery 
), which provides jQuery-like syntactic 
sugar over x/net/html.

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.

Re: [go-nuts] "html/dom" alternative to html/template for true separation of concerns?

[Andy Balholm]

You may not be aware that the html/template package does automatic escaping. So 
if a template has {{.Blogpost}} and 
Blogpost contains alert(“Pwned”), the result will be something 
like 

Assigning to the div’s innerHTML would be bad in this case, but appending a 
text node to the div would be safe.

Andy

> On Sep 13, 2017, at 2:10 PM, karv.pr...@gmail.com 
>  wrote:
> 
> I don't know why it's unclear, what I'm proposing, but I'll try a 2nd time:
> 
> Something similar to: http://php.net/manual/en/book.dom.php 
> 
> 
> Or, even simpler:
> - Find Tags, IDs, Classes, etc. in an HTML document.
> - Something similar to Element.innerHTML to put content into these tags 
> (https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML 
> )
> - Something similar to Element.setAttribute to change attributes of DOM 
> elements 
> (https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute 
> )
> - Maybe some validation if the HTML DOM is correct
> - Possibly some sanitation to check if there are any empty tags or empty tag 
> attributes (i.E. empty content on some meta tag)
> 
> In short: Load some HTML code, and manipulate the HTML Document Object Model 
> instead of being dependent on placeholders.
> 
> Yes, a standard library shouldn't do everything. But same goes with 
> templating, so that isn't really an argument against implementing it into the 
> codebase if one of the main foci of Golang is the Web.
> 
> I wasn't ignoring the Security Model. If someone uses Golang to create a 
> comment section in the web, the same could happen with Templates, if the 
> developer isn't aware of possible security issues. There is no difference if 
> some unchecked user content is injected into  id="not-so-secure-blogpost>{{blogpost}} or  id="not-so-secure-blogpost>. So I really don't see where 
> "html/template" avoids this issue if some coder doesn't watch out how user 
> content is handled. Escaping the user content (or other security features) 
> can be implemented too, yes - but that should be some other package imho.
> 
> Kind regards
> Karv
> 
> Am Mittwoch, 13. September 2017 21:58:47 UTC+2 schrieb Egon:
> If you want to manipulate HTML files then there is 
> https://godoc.org/golang.org/x/net/html 
> ,
> but it comes with all the dangers of potential injection attacks and so on... 
> which "html/template" avoids.
> Writing something that injects into the specific nodes and afterwards encodes 
> shouldn't be a big problem.
> 
> If you want to write HTML directly from code then writing a simple html 
> encoder with the necessary models
> isn't too complicated 
> (https://github.com/egonelbre/exp/blob/master/htmlrender/main.go 
> )
> 
> But the huge con you are ignoring is the Security Model. 
> (https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition
>  
> )
> 
> Anyways it's unclear what you are proposing or needing: in general standard 
> libraries shouldn't do everything
> and probably this, whatever it is, should belong to a 3-rd party package.
> 
> + Egon
> 
> On Wednesday, 13 September 2017 22:02:02 UTC+3, Karv Prime wrote:
> Hello,
> 
> I only recently found my way to go. I'm a (former?) fullstack web-dev and as 
> I ran into a PHP related problem (DOMDocument not working with HTML5 tags, 
> I'd choose another solution stack if the language wouldn't be a fixed point 
> in history) I was looking if Go already has a good way to manipulate HTML 
> files. The templating is fine, but in my humble opinion there's a problem...
> 
> Problem: IMHO templating in the current form is flawed. To insert 
> placeholders (i.E. "{{.nav}}") probably isn't an optimal solution as it just 
> tells the code "hey, act upon me". It seems to be a shallow solution to 
> prevent code-mixins, but fails to really separate the concerns.
> 
> Solution: If there would be a Go package to directly manipulate the DOM it 
> would be very helpful to separate Markup and Code. The code would act onto 
> the markup file (*.html) to create the page/site/module/... (whatever is 
> needed).
> 
> Pros:
> - Frontend devs could create their own pages, modules, etc. without thinking 
> about any special tags they'd need.
> -> '' instead of '{{.content}}'
> -> '' instead of ' name="description" content="{{.description}}">'
> - Error/Exception if some tag/id/class/... has not been found instead of 
> admins possibly not knowing about it.
> -> You can act upon it and tell the users "Oops, something went wrong, we're 
> looking into it." so they know that the curre

Re: [go-nuts] "html/dom" alternative to html/template for true separation of concerns?

[Andy Balholm]

Why does automatic escaping make html/template completely impractical? (Or did 
I guess the antecedent of “it” incorrectly?)

Andy

> On Sep 13, 2017, at 4:30 PM, Karv Prime  wrote:
> 
> Thank you for the heads up. So it is completely impractical for the needed 
> purpose.
> 
> In that case it would be truly bad. That's why user input should always be 
> checked. Such a blogpost shouldn't even come that far. ^^ Either it's escaped 
> before it gets to the database (not truly necessary due to prepared 
> statements etc., but depends on the use case scenario), but at least it 
> should be escaped before it hits the visual representation.
> 
> Let's stay with the blogpost example to give some further insight and assume 
> the following [folder]/file structure:
> [site]
> - site.html (the full site, but without nav, and main, as well as data that 
> depends on which page is shown, language, etc. (html lang, title, keywords, 
> etc.)
> - nav.html (only the navigation, which isn't depending on anything, but 
> exists as its own module)
> - main.html (main content - in our case the blog - that has different 
> blogposts)
> [modules]
> - blogpost.html (a singular blogpost and how it should look like)
> 
> So the application should at first stick together site, nav, and main. If 
> that happens at runtime or if it creates a template beforehand is a matter of 
> optimization, but doesn't really matter in our example. As the user requested 
> the page in Latin, lang, title, keywords, etc. are filled in accordingly. Up 
> to that point any code injection could be possible but then there are other 
> security concerns as until then no user data has been used. We have 5 
> blogposts as our blog came to live a day ago and up to now only spambots were 
> here. But user entries are user entries, so let's parse them. Take the 
> blogpost.html file and fill  as well as  class="userpost"> with their content: Escape the content, then fill it 
> in the same way as innerHTML from JS works. Put these 5 blogposts into main 
> and send it to the user.
> Another user clicks "blog" in the navigation but has JS activated - so it 
> only loads the main content. Again the 5 blogposts, but not the full site.
> Some other user is active on the blog, but gets updates every 10 minutes or 
> due to server side events - as the previous user complained about the 
> botposts he now only gets a representation of blogpost.html sent with the 
> content to be prepended before the other posts.
> 
> Yes, one could realize that solely with templates. But everytime just a 
> little thing has to be changed (i.E. another navigation link added) someone 
> has to touch the whole site.html file (GIT be praised, but nonetheless it's 
> not that good for really big sites, so a separation is at least sometimes 
> practical). The downside is that every HTML guy needs to learn the "how to 
> templating in language X", be it Golang, Twig, Smarty, ... instead of just 
> creating plain simple HTML which can be manipulated by the code via the HTML 
> DOM. And if there's something missing it creates a warning which is practical 
> too (as, if the full site without the dynamic stuff gets stitched together 
> beforehand from some kind of easy maintainable [meta] page, it could stay 
> with the previous version until the oversight is solved, or whatever one 
> wants to do with that information). And the problem "some coders could 
> actually forget to check user input" can be solved with taint checking (if 
> the content comes from a "secure" source (i.E. a .html file) there is no need 
> for a warning, but if it's from a database all hell should break loose) - but 
> as files could under certain circumstances also be user-created (i.E. some 
> esoteric database where every blog entry is a file) there's a problem here. 
> One can't prevent coders from making mistakes. PHP tried, it failed. ^^ Java 
> has no taint checking if user data is injected into a SQL query, Perl and 
> Ruby have it. Maybe the solution would be to allow a coder to choose between 
> an unescaped innerHTML and an escaped one.
> 
> Am Donnerstag, 14. September 2017 00:43:10 UTC+2 schrieb Andy Balholm:
> You may not be aware that the html/template package does automatic escaping. 
> So if a template has {{.Blogpost}} and 
> Blogpost contains alert(“Pwned”), the result will be 
> something like  id=not-so-secure-blogpost><script>alert("Pwned")</script>
> 
> Assigning to the div’s innerHTML would be bad in this case, but appending a 
> text node to the div would be safe.
> 
> Andy
> 
>> On Sep 13, 2017, at 2:10 PM, karv@ <>gmail.

Re: [go-nuts] "html/dom" alternative to html/template for true separation of concerns?

[Andy Balholm]

I still don’t understand why automatic escaping makes html/template impractical 
for the purpose you were describing. Is it because the blog post would be HTML 
rather than plain text? In that case, you would need to convert it to the 
template.HTML type before passing it to the template, and it would be rendered 
without escaping. (Then sanitizing the HTML to prevent XSS would be up to you, 
of course.) The html/template escapes content by default, but there are ways to 
get around it if you tell it you know what you are doing.

Andy

> On Sep 13, 2017, at 7:01 PM, Karv Prime  wrote:
> 
> It = html/template
> "The purpose" = the one I thought I could use it for and described above.
> 
> Am Donnerstag, 14. September 2017 03:58:02 UTC+2 schrieb Andy Balholm:
> Why does automatic escaping make html/template completely impractical? (Or 
> did I guess the antecedent of “it” incorrectly?)
> 
> Andy
> 
>> On Sep 13, 2017, at 4:30 PM, Karv Prime gmail.com 
>> <http://gmail.com/>> wrote:
>> 
>> Thank you for the heads up. So it is completely impractical for the needed 
>> purpose.
>> 
>> In that case it would be truly bad. That's why user input should always be 
>> checked. Such a blogpost shouldn't even come that far. ^^ Either it's 
>> escaped before it gets to the database (not truly necessary due to prepared 
>> statements etc., but depends on the use case scenario), but at least it 
>> should be escaped before it hits the visual representation.
>> 
>> Let's stay with the blogpost example to give some further insight and assume 
>> the following [folder]/file structure:
>> [site]
>> - site.html (the full site, but without nav, and main, as well as data that 
>> depends on which page is shown, language, etc. (html lang, title, keywords, 
>> etc.)
>> - nav.html (only the navigation, which isn't depending on anything, but 
>> exists as its own module)
>> - main.html (main content - in our case the blog - that has different 
>> blogposts)
>> [modules]
>> - blogpost.html (a singular blogpost and how it should look like)
>> 
>> So the application should at first stick together site, nav, and main. If 
>> that happens at runtime or if it creates a template beforehand is a matter 
>> of optimization, but doesn't really matter in our example. As the user 
>> requested the page in Latin, lang, title, keywords, etc. are filled in 
>> accordingly. Up to that point any code injection could be possible but then 
>> there are other security concerns as until then no user data has been used. 
>> We have 5 blogposts as our blog came to live a day ago and up to now only 
>> spambots were here. But user entries are user entries, so let's parse them. 
>> Take the blogpost.html file and fill  as well as 
>>  with their content: Escape the content, then 
>> fill it in the same way as innerHTML from JS works. Put these 5 blogposts 
>> into main and send it to the user.
>> Another user clicks "blog" in the navigation but has JS activated - so it 
>> only loads the main content. Again the 5 blogposts, but not the full site.
>> Some other user is active on the blog, but gets updates every 10 minutes or 
>> due to server side events - as the previous user complained about the 
>> botposts he now only gets a representation of blogpost.html sent with the 
>> content to be prepended before the other posts.
>> 
>> Yes, one could realize that solely with templates. But everytime just a 
>> little thing has to be changed (i.E. another navigation link added) someone 
>> has to touch the whole site.html file (GIT be praised, but nonetheless it's 
>> not that good for really big sites, so a separation is at least sometimes 
>> practical). The downside is that every HTML guy needs to learn the "how to 
>> templating in language X", be it Golang, Twig, Smarty, ... instead of just 
>> creating plain simple HTML which can be manipulated by the code via the HTML 
>> DOM. And if there's something missing it creates a warning which is 
>> practical too (as, if the full site without the dynamic stuff gets stitched 
>> together beforehand from some kind of easy maintainable [meta] page, it 
>> could stay with the previous version until the oversight is solved, or 
>> whatever one wants to do with that information). And the problem "some 
>> coders could actually forget to check user input" can be solved with taint 
>> checking (if the content comes from a "secure" source (i.E. a .html file) 
>> there is no need for a warning, but if it's from a database all hell 

Re: [go-nuts] "html/dom" alternative to html/template for true separation of concerns?

[Andy Balholm]

The placeholders never show up in template output. If the data is missing, the 
placeholders normally just disappear; in some cases there might be an error, 
depending on exactly what type of “missing.”

Andy

> On Sep 14, 2017, at 8:14 AM, Karv Prime  wrote:
> 
> As it would get a little bit confusing if I'd reply to everyone with a single 
> post, I'll answer in a single post. I hope you don't mind. At least now it's 
> past 16:00 and not past 04:00 and I have a clearer mind. ^^
> 
> @Egon: I've read the whole article - yes, many coders sadly do forget about 
> proper sanitization of user-input. As I'm pretty focused on security, I know 
> about the implications of many design-approaches. Easy-to-use approaches are 
> neat and in that certain case super useful - but sadly not for my use-case. ^^
> 
> @Andy Balholm: No, the "blog posts" are not HTML. Again: There is a reusable 
> HTML snippet. That snippet can be filled with user content - which truly 
> needs to be sanitized due to security concerns. If the snippet gets sent to 
> the user via asynchronous request there's nothing more to do as JS takes the 
> part with putting it into its place. But if the whole page has to be 
> rendered, that snippet needs to be put into the page, before the whole page 
> gets sent to the user. The other way would be to leave the complete rendering 
> to the user browser which comes with its very own disadvantages (i.E. no 
> scripting available, etc.).
> I thought that the whole package auto-sanitizes the content as you've stated 
> before. Now, okay, it's usable for that use case. It's not perfect with all 
> the artifacts one needs to put into the HTML code, but if necessary I can 
> work with that. ^^
> 
> @Marvin Renich: Thank you for this information. I'm new to Golang and I 
> probably misunderstood one comment here for "the (whole) template package 
> does automatic escaping), so I didn't look further - my mistake. So it would 
> be possible to implement everything via the template package - yet there's 
> the disadvantage of the need to put artifacts into the markup which then get 
> replaced by the wanted content (I have to look into it further - if there's 
> an error if there is no data for some template code it's perfectly fine... 
> otherwise it will look like some websites where the artifacts are visible to 
> the user if they didn't get replaced).
> 
> -- 
> 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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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] Golang, Google App Engine, Windows 10

[Andy Balholm]

One reason might be if you’re using a server version of Windows. For some 
reason, the Linux subsystem is only for consumer versions.

Andy

> On Sep 21, 2017, at 5:50 AM, Rob Shelby  wrote:
> 
> Why would I use Cygwin over Bash For  Windows?
> 
> On Thursday, September 21, 2017 at 8:17:04 AM UTC-4, Rich wrote:
> As a Linux guy myself...  Jet Brains makes an IDE for Windows, Linux and Mac 
> called Gogland that I find to be a very good IDE.  If forced to use Windows, 
> I would install Cygwin which will give you a Linux shell environment.  As for 
> compiling, I run a mac and build binaries for Linux / Windows all the time.   
> What I do is create a simple Makefile like this:
> 
> all: runcmd
> 
> runcmd: runcmd.go
> GOOS=linux GOARCH=amd64 go build  -o binaries/linux64/runcmd runcmd.go
> GOOS=linux GOARCH=386   go build  -o binaries/linux32/runcmd runcmd.go
> GOOS=windows GOARCH=amd64 go build  -o binaries/win64/runcmd.exe 
> runcmd.go
> GOOS=windows GOARCH=386 go build  -o binaries/win32/runcmd.exe 
> runcmd.go
> GOOS=darwin GOARCH=amd64 go build  -o binaries/mac/runcmd runcmd.go
> 
> Just type 'Make' and it will build for all platforms   
> 
> On Wednesday, September 20, 2017 at 4:31:04 PM UTC-5, Rob Shelby wrote:
> Hi all.
> 
> I'm having to make 2 transitions in my coding life. 
> 
> From PHP to Go, which I'm happy about.
> 
> From Linux desktop to Windows 10, which I'm not as happy about.
> 
> I love using Google's App Engine so I don't need to worry about servers etc. 
> (Not Compute Engine)
> 
> Anyways, any steps, advice, etc to easily code in Go and deploy to GAE.
> 
> So far, I've figured that installing and running Go in Bash On Linux, but 
> coding in an IDE in Windows, is the easiest. Then deploy from Bash On Windows.
> 
> Does anyone else have a better way?
> 
> 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] Handling dynamic and unknown number of wait groups?

[Andy Balholm]

You can add goroutines to a WaitGroup as you create them. There is nothing that 
keeps you from calling Add more than once.

Andy

> On Nov 1, 2017, at 11:10 PM, kanth...@gmail.com wrote:
> 
> I am new to Go and I had read numerous times in various articles that one can 
> technically create any number of Go routines and the runtime takes care of 
> them mapping to kernel threads. If so, why does waitGroup designed in a way 
> such that one has to specify how many go routines one need to create ahead of 
> time ? why can't waitGroup be more dynamic such that I can add a Goroutine to 
> waitgroup once I create it ? To put the question in another way why are 
> people even thinking about pool of go routines in the first place given that 
> goroutines are user level threads? If someone talks about pool of goroutines 
> I feel like I am back to C++ or any other language that creates pool of 
> kernel threads. Does Go runtimes doesn't keep its promise? Again, I am new so 
> please enlighten me.
> 
> On Wednesday, June 29, 2016 at 3:35:31 PM UTC-7, Inspectre Gadget wrote:
> Hey everyone,
> 
> Here’s my issue, I will try to keep this short and concise:
> 
> I have written a program that will accept a URL, spider that URL’s domain and 
> scheme (http/https), and return back all input fields found throughout to the 
> console. The purpose is largely for web application security testing, as 
> input fields are the most common vulnerability entry points (sinks), and this 
> program automates that part of the reconnaissance phase.
> 
> Here is the problematic code: 
> https://github.com/insp3ctre/input-field-finder/blob/ce7983bd336ad59b2e2b613868e49dfb44110d09/main.go
>  
> 
> 
> The issue lies in the last for loop in the main() function. If you were to 
> run this program, it would check the queue and workers so frequently that it 
> is bound to find a point where there are both no workers working, and no URLs 
> in the queue (as proved by the console output statements before it exits). 
> Nevermind that the problem is exacerbated by network latency. The number of 
> URLs actually checked varies on every run, which causes some serious 
> inconsistencies, and prevents the program from being at all reliable.
> 
> The issue was fixed here: 
> https://github.com/insp3ctre/input-field-finder/blob/f0032bb550ced0b323e63be9c4f40d644257abcd/main.go
>  
> 
> 
> I fixed it by removing all concurrency from network requests, leaving it only 
> in the internal HTML processing functions.
> 
> So, the question is- how does one run efficient concurrent code when the 
> number of wait groups is dynamic, and unknown at program initialization?
> 
> I have tried:
> Using “worker pools”, which consist of channels of workers. The for loop 
> checks the length of the URL queue and the number of workers available. If 
> the URL queue is empty and all the workers are available, then it exits the 
> loop.
> Dynamically adding wait groups (wg.Add(1)) every time I pull a URL from the 
> URL queue. I can’t set the wait group numbers before the loop, because I can 
> never know how many URLs are going to be checked.
> 
> So I have tried using both channels and wait groups to check alongside the 
> URL queue length to determine whether more concurrent network requests are 
> needed. In both cases, the for loop checks the values so fast that it 
> eventually stumbles upon a non-satisfied loop condition, and exits. This 
> usually results in either the program hanging as it waits for wait groups to 
> exit that never do, or it simply exits prematurely, as more URLs are added to 
> the queue after the fact. 
> 
> I would really like to know if there is a way to actually do this well in Go.
> 
> Cheers,
> 
> Inspectre 
> 
> -- 
> 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] cgo style question

[Andy Balholm]

Use the arr1 style when the length of the C array is known at compile time, and 
the arr2 style when it’s not known till runtime.

Andy

> On Nov 3, 2017, at 9:18 AM, DV  wrote:
> 
> Which "style" of wrapping a C array in a Go slice is more idiomatic in this 
> code - https://play.golang.org/p/6EbKl22MPQ - "arr1" or "arr2"? They both 
> seem to produce the exact same result.
> 
> I've seen the "arr2" style more often, but I don't understand why. The way I 
> wrapped "arr1" seems more clear to me - you have to know the length of the C 
> array, so why not just declare the pointer to the array with the correct 
> length to begin with? Why is the 1<<30 bit the more accepted style, e.g. here 
> - cgo 
> .  It 
> seems a bit noisy, especially with having to remember to put the length *and* 
> capacity when slicing the array.
> 
> I have a feeling I'm missing something important but I don't understand 
> what...
> 
> -- 
> 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] Go Compiler How Work?!

[Andy Balholm]

No, the Go compiler doesn’t actually generate ASM. It generates machine code. 
So it doesn’t need the help of another compiler or assembler.

Andy

> On Dec 13, 2017, at 9:00 AM, Compiler  wrote:
> 
> i am undrestand compiler steps.
> only have problem in code generation step.
> so best way is this then compiler generate code is ASM.
> GOLANG also generate ASM.
> 
> yeah?
> 
> On Wednesday, December 13, 2017 at 8:27:41 PM UTC+3:30, Bruno Albuquerque 
> wrote:
> It directly generates a binary suitable for the target platform, yes. Again, 
> you do not need a C compiler to compile a Go program unless you are using CGO.
> 
> -- 
> 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] Go Compiler How Work?!

[Andy Balholm]

By “Machine Code” I mean that “go build” or “go install” generates an 
executable file that is ready for the target operating system and CPU to run 
directly. On Windows, it generates a .EXE file. On Unix-like operating systems 
it generates a “binary executable” file (which is basically the same thing, but 
it doesn’t have a suffix to identify the file type like Windows uses). 

(Internally, this process is divided into two steps, called “compile” and 
“link.” The compile step generates the machine code needed by the target CPU; 
the link step arranges this machine code into the file format that the target 
operating system expects.)

Andy

> On Dec 13, 2017, at 9:31 AM, Compiler  wrote:
> 
> Machine Code?!
> 
> please show me github link source file then at they is generate sample 
> binary... at GOLANG sources.
> 
> On Wednesday, December 13, 2017 at 8:48:30 PM UTC+3:30, Andy Balholm wrote:
> No, the Go compiler doesn’t actually generate ASM. It generates machine code. 
> So it doesn’t need the help of another compiler or assembler.
> 
> Andy
> 
>> On Dec 13, 2017, at 9:00 AM, Compiler > wrote:
>> 
>> i am undrestand compiler steps.
>> only have problem in code generation step.
>> so best way is this then compiler generate code is ASM.
>> GOLANG also generate ASM.
>> 
>> yeah?
>> 
>> On Wednesday, December 13, 2017 at 8:27:41 PM UTC+3:30, Bruno Albuquerque 
>> wrote:
>> It directly generates a binary suitable for the target platform, yes. Again, 
>> you do not need a C compiler to compile a Go program unless you are using 
>> CGO.
>> 
>> -- 
>> 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 
>> <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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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] database/sql : i have a need to use postgresql numeric column data type for currency / money value processing

[Andy Balholm]

If all the calculations are going to be in the database, you can just use 
strings on the Go side.

Andy

> On Jan 7, 2018, at 6:44 AM, evan  wrote:
> 
> c# has a decimal type that i can map my numeric(12,2) column data type to, 
> but golang doesnt have a decimal type.
> 
> i'm trying to avoid storing money values as cents then converting them to 
> dollar values when needed, and
> also would like to stay close to using database/sql's standard API as much as 
> possible.
> 
> would i be able to meet these needs  by maybe using 
> https://godoc.org/github.com/lib/pq for most of my needs, 
> and then maybe using pgx's custom Decimal / Numeric type 
> (https://godoc.org/github.com/jackc/pgx/pgtype)
> to facilitate currency value processing?  
> 
> could anybody with experience doing something like this share their 
> experience(s) and suggestion(s) with me? 
> 
> thank you for helping!
> 
> -- 
> 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] http.FileServer: how to serve static files requested from different domains?

[Andy Balholm]

Try:

http.Handle(“domain1.com/assets/", http.StripPrefix("/", 
http.FileServer(http.Dir(*webrootdomain1
http.Handle(“domain2.com/assets/", http.StripPrefix("/", 
http.FileServer(http.Dir(*webrootdomain2

-- 
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] Difficulties Using golang.org/x/net/html

[Andy Balholm]

The prescription is correct; the diagnosis is close but not exactly right.

The html package actually doesn’t pay any attention to the XML-style 
self-closing tag syntax. It accepts it, in accordance with the HTML5 spec, as 
an alternate style of opening tag, but it never closes an element just because 
of the final slash. The only elements that are automatically closed are those 
that are always automatically closed, like .

Andy

> On Jan 25, 2018, at 11:05 PM, dc0d  wrote:
> 
> Solved: problem is component is not a standard html tag. That's why the 
> parser does not respect the self closing version. So if instead of  context="{ctx}" /> a properly closed one like  context="{ctx}"> is used, it will work properly.
> 
> (Help from gophers slack)
> 
> On Thursday, January 25, 2018 at 12:48:26 PM UTC+3:30, dc0d wrote:
> How to parse custom (nested) elements using golang.org/x/net/html 
> ?
> 
> It parses the custom element correctly but if there are nested custom 
> elements, the next siblings are parsed as children of the parent custom 
> element.
> 
> https://play.golang.org/p/Iu4RP6qp60p 
> 
> the closing tag for another () should be before span.
> 
> -- 
> 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 possible to simplify this snippet?

[Andy Balholm]

You could have a cleaner switch statement if you had a list of the keys that 
were pressed, instead of needing to check each one individually:

func whichKeys(keysToCheck ...keyID) []keyID {
var result []keyID
for _, k := range keysToCheck {
if rl.IsKeyDown(k) {
result = append(result, k)
}
}

return result
}

for _, k := range whichKeys(rl.KeyA, rl.KeyD, rl.KeyW, rl.KeyS) {
switch k {
case rl.KeyA:
p.Rect.X -= 1
case rl.KeyD:
p.Rect.X += 1
case rl.KeyW:
p.Rect.Y -= 1
case rl.KeyS:
p.Rect.Y += 1
}
}

Andy


> On May 1, 2019, at 2:51 PM, Burak Serdar  wrote:
> 
> On Wed, May 1, 2019 at 2:31 PM mailto:lgod...@gmail.com>> 
> wrote:
>> 
>> Great example of why future Go updates should include the ternary operator.
>> Your code is mess-ey when written using keywords 'if' or 'switch'
>> but  using '?' it becomes much cleaner
>> 
>> p.Rect.X +=  rl.IsKeyDown(rl.KeyA) ? -1:0   +  (rl.IsKeyDown(rl.KeyD) ? 1 : 
>> 0 )
>> p.Rect.Y +=  rl.IsKeyDown(rl.KeyW) ? -1:0   +  (rl.IsKeyDown(rl.KeyS) ? 1 : 
>> 0 )
> 
> I don't think this is readable at all. I think the cascading-ifs
> version is much easier to read.
> 
> You could do something like the following, but I think pointless
> unless there's more to the original snippet:
> 
> checkKey:=func(k, v int) int {
>  if rl.IsKeyDown(k) {
>return v
>  }
> return 0
> }
> p.Rect.X+=checkKey(rl.KeyA,-1)+checkKey(rl.KeyD,1)
> p.Rect.Y+=checkKey(rl.KeyW,-1)+checkKey(,rl.KeyS,1)
> 
>> 
>> On Wednesday, May 1, 2019 at 8:38:10 AM UTC-4, гусь wrote:
>>> 
>>> if rl.IsKeyDown(rl.KeyA) {
>>> p.Rect.X -= 1
>>> }
>>> if rl.IsKeyDown(rl.KeyD) {
>>> p.Rect.X += 1
>>> }
>>> if rl.IsKeyDown(rl.KeyW) {
>>> p.Rect.Y -= 1
>>> }
>>> if rl.IsKeyDown(rl.KeyS) {
>>> p.Rect.Y += 1
>>> }
>> 
>> --
>> 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] What happens to global vars when main() ends ?

[Andy Balholm]

When the program exits, the operating system releases all the memory allocated 
to it. So the GC doesn’t need to bother with freeing the memory.

Andy

> On May 3, 2019, at 5:49 PM, Matt Harden  wrote:
> 
> On Fri, May 3, 2019, 17:28 mailto:lgod...@gmail.com>> 
> wrote:
> Does Go GC  destroy all global vars prior to the end of main() ? 
> 
> What do you mean by "destroy"? Go is not an object oriented language and 
> doesn't have the concept of a destructor. So no, it doesn't, but it also 
> doesn't need to.
> 
> May I ask, what led you to ask this question?
> 
> -- 
> 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 Dominance of English in Programming Languages

[Andy Balholm]

That’s probably true of the spoken language; American spelling, on the other 
hand, has changed more than British spelling. This is mostly a result of Noah 
Webster’s attempts to simplify it.

King James Version Bibles generally follow the spelling of the 1769 Oxford 
printing, and the spelling is definitely closer to current British English than 
to American.

Andy

> On May 17, 2019, at 1:26 PM, Michael Jones  wrote:
> 
> I know that you joke here, but I had an interesting dinner conversation in 
> London last year with erudite, scholarly friends who shared with me that 
> recent research supports a different view of the "barbaric Americanised false 
> English" that is the prevailing sentiment you share. 
> 
> According to the scholars they mentioned, "American English" is indeed a 
> true, pure, "real" English; just one from a time-capsule, an English from 
> 1776 that did not advance significantly since American independence. This 
> view suggests that were a BBC presenter and an American to travel back to 
> meet with King George, it would be the American who sounded "right" and not 
> the other way around.
> 
> This time-capsule argument is not an argument against modern evolved English, 
> but it is an interesting notion of a living language in the homeland might 
> become a historical artifact through cargo culting in the breakaway colony. 
> Insightful as to human psychology and something to remember amongst the 
> lessons of wisdom.
> 
> Michael
> (a barbaric American-English 1776 throwback ;-)
> 
> On Fri, May 17, 2019 at 9:41 AM mailto:ma...@madra.net>> 
> wrote:
> Spare a thought for those of us who actually speak and write 'proper' English 
> and not that American version used in all programming languages.
> 
> We get to write in our own language but have to remember to spell half the 
> words wrong!
> 
> 
> 
> -- 
> 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/1e22042e-9ac0-404f-be30-eaa495ae11dd%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> Michael T. Jones
> michael.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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQxZ9FukdODzXUfas4%2BqyC3csGW4voN4fZ4QVX37EYAcgw%40mail.gmail.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/3DB72A38-0530-459C-A1DD-59F88BA2A0E7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] the Dominance of English in Programming Languages

[Andy Balholm]

Just be glad that the American date format caters to (or for!) those Americans 
who say “January two”, not those who (like me) say “January second.” Imagine 
what date-formatting code would look like if ordinal suffixes were required! 
(Jan 1st, Jan 2nd, etc.)

Andy

> On May 18, 2019, at 2:59 AM, ma...@madra.net wrote:
> 
> Tune in same time next week when the topic for discussion will be "Why is the 
> American date format so illogical?"  Although I suspect that, on a mailing 
> list comprised of coders, that one will be less controversial.

-- 
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/AADF3BFB-5836-4996-A121-655C14165DA2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] In module mode, where does "go install" install executables

[Andy Balholm]

When GOPATH is set, “go install” installs executables to $GOPATH/bin (assuming 
there is just one path in GOPATH). When GOPATH is not set, where do the 
executables go? I haven’t been able to find them. 

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/A85618AF-E0E1-4F24-B9EC-B1D75E9221D8%40balholm.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] In module mode, where does "go install" install executables

[Andy Balholm]

Yes, it looks like that is right.

Andy

> On Jun 25, 2019, at 9:25 AM, Wagner Riffel  wrote:
> 
> I'd bet the default GOPATH, that is $HOME/go
> BR.

-- 
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/38B459BA-8738-40EA-956C-1EBAB96B53CF%40balholm.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Announcing gg ("gigi") your new friend

[Andy Balholm]

I recently ran across https://github.com/mvdan/gogrep 
. It does some of that.

Andy

> On Jul 4, 2019, at 5:30 PM, Bakul Shah  wrote:
> 
> Very nice!
> 
> A natural great extension[1] would be language aware grep/sed/awk:
> - return an enclosing parse construct after matching something
> - match on a construct with some pieces wildcarded
> - replace one structure with another (but based on the match)
> 
> Possible uses:
> - when you change an API of a package, fix up its users
> - rename variables
> - replace Go1 constructs with simpler/more efficient Go2 ones.
> - write generic code and replace with type specific code
> - program construction (ala Beta language's fragment system)
> - literate programming (tangle/weave)
> - optimize code
> - program analysis
> - structured diff/merge
> 
> The tough part would be coming up with a simple but flexible
> structured regular expression language. [Initially I had thought
> this is what Rob was writing about in his "Structured Regular
> Expressions" paper! So the idea is very old.] 
> 
> [1] No good deed goes unpunished :-)
> 
> 
>> On Jul 4, 2019, at 9:10 AM, Michael Jones > > wrote:
>> 
>> Recently I shared my Survey  
>> program, saying that it was a sidestep from what I was working on but 
>> interesting and hopefully useful to others. Here is the real thing, named 
>> gg, that Survey was a test for. GG combines lexical analysis and Go-native 
>> pattern matching to extend grep(1) for Go developers
>> 
>> GG is smart; the search is restricted, seeking matches only in chosen token 
>> classes.  A search in number literals can match values in addition to 
>> patterns: "v 255" matches the numeric value 255 in source code as 
>> 0b_, 0377, 0o377, 255, 0xff, etc.  Go's linear-time regular 
>> expression engine is Unicode-aware and supports many extensions: numbers in 
>> identifiers are found with "gg i [0-9]" or "gg i [\d]", find comments with 
>> math symbols using "gg c \p{Sm}", and Greek in strings via "gg s \p{Greek}".
>> 
>> GG is fast, uses all cores, understands filesystem hierarchies, archives, 
>> and compression schemes, and is general like grep while focused in a new 
>> way: find within package names, identifiers, types, strings, comments, and 
>> more.
>> 
>> Source code:
>> https://github.com/MichaelTJones/gg 
>> 
>> Man page (all is explained here):
>> https://github.com/MichaelTJones/gg/blob/master/gg.pdf 
>> 
>> 
>> Examples: 
>> 
>> Search the Go 1.13 source code for strings containing Megalosaurus, but not 
>> comments:
>> 
>> $ gg -r s Megalosaurus ~/go
>> /Users/mtj/go/src/cmd/link/link_test.go:`text:"London. Michaelmas term 
>> lately over, and the Lord Chancellor sitting in Lincoln’s Inn Hall. 
>> Implacable November weather. As much mud in the streets as if the waters had 
>> but newly retired from the face of the earth, and it would not be wonderful 
>> to meet a Megalosaurus, forty feet long or so, waddling like an elephantine 
>> lizard up Holborn Hill. ...
>> 
>> Search the Go 1.13 source code for identifiers with greek letters (but not 
>> strings or comments):
>> 
>> $ gg -r i '\p{Greek}' ~/go
>> /Users/mtj/go/src/encoding/json/encode_test.go:  A0, À, Aβ int
>> /Users/mtj/go/src/math/cmplx/polar.go:func Polar(x complex128) (r, θ 
>> float64) {
>> /Users/mtj/go/src/math/cmplx/rect.go:func Rect(r, θ float64) complex128 {
>> /Users/mtj/go/src/math/cmplx/rect.go:s, c := math.Sincos(θ)
>> /Users/mtj/go/src/math/rand/rand_test.go:var χ2 float64
>> :
>> 
>> Best to all,
>> Michael
>> 
>> -- 
>> Michael T. Jones
>> michael.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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CALoEmQz-KdFaWjS%2Bfyd-QQS4LEgYmnofiZNmugnoQ7sNaG0HEA%40mail.gmail.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/18AEB87E-E8A1-40BB-A63C-1DA84A607AF7%40bitblocks.com
>  

Re: [go-nuts] possible to set tls.Config.Servername with http.client.Do

[Andy Balholm]

If you leave the Servername blank, http.Transport will get it from the HTTP 
request. 

Andy

> On Jul 15, 2019, at 12:27 PM, efah...@gmail.com wrote:
> 
> Hi,
> 
> I was wondering how one can do concurrent tls requests with one single 
> http.Client where all the servers serving the request have their certificates 
> from the same root CA but require different tls.Config.Servername.
> 
> Would be nice to have a function like http.client.DoWithServername(req, 
> servername)
> 
> Regards
> Fahad
> 
> -- 
> 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/4fd8afd1-533d-4d34-8be3-039238eea2b4%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/A088D100-E248-426A-BB95-1B34496BF415%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] ls: unsupported SSLv2 handshake received

[Andy Balholm]

As I understand it, the issue isn’t actually about SSLv2 itself. It’s that 
clients that support SSLv2 use an old handshake format. In that handshake, they 
can advertise support for SSLv3 and maybe even TLS 1. So if crypto/tls added 
support for the handshake but not the rest of SSLv2, they could successfully 
negotiate an SSLv3 connection.

Of course, now that SSLv3 is deprecated, it’s not very likely that support for 
these old handshakes will be added.

Andy

> On Sep 18, 2019, at 1:41 AM, Anthony Martin  wrote:
> 
> Prabhash Rathore  once said:
>> Looking at comment, it seems Golang does not support SSLv2 and SSLV3.
> 
> The crypto/tls package can support SSLv3 if you set tls.Config.MinVersion
> to tls.VersionSSL30, but only as a server.
> 
>> I am reaching out to see if there is anyway possible to add support for 
>> older SSL versions or if there are any workarounds. In SMTP world, there 
>> are lots of clients who still use old SSL builds and we would like to be 
>> able to support them on our MTA servers.
> 
> I think it's unlikely that SSLv2 will be supported. There is a very
> old discussion about this at https://github.com/golang/go/issues/3930
> that you might want to check out.
> 
> Cheers,
>  Anthony
> 
> -- 
> 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/20190918084123.GA4577%40alice.

-- 
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/489171A3-403D-43C6-B28C-5B29E1BEB61B%40gmail.com.

Re: [go-nuts] early close of http.Client's Response.Body

[Andy Balholm]

> On Nov 25, 2019, at 9:54 AM, Liam  wrote:
> 
> - does the read-to-EOF stipulation also apply to Client.Get/Post() ?

Yes. Those methods are fairly simple wrappers around Do.

> - why does Response.Body.Close() before io.EOF not release unread buffers or 
> otherwise prepare it for persistence?

The connection can’t be reused for another request before all the data from the 
first request is read. The server is sending those bytes over the wire, and 
they need to go somewhere before another response can be read. So there were 
two options for how to implement Close when the whole body hasn’t been read:

1. Copy the rest of the body to /dev/null (or equivalent), and reuse the 
connection like normal.
2. Close the connection, thus communicating to the server that we don’t need 
that data after all.

Option 1 would generally be preferable for short responses, and option 2 for 
long ones. For consistency, and because we don’t always know the response 
length in advance (e.g. if it is chunked), it always does option 2.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/228DAB0B-E2AB-4A5E-BBC5-76D611ED11F9%40gmail.com.

Re: [go-nuts] early close of http.Client's Response.Body

[Andy Balholm]

Read-to-EOF is one of several conditions for connection reuse:

- Was the response body fully read (to EOF)?
- Does the server support HTTP keep-alives?
- Is DisableKeepAlives set to false (the default) on the http.Transport that 
the client uses?

A connection will only be reused if all of these are met. Otherwise Close will 
close the connection.

There is no need to discard a Client after an early Close. A Client is not tied 
to a single connection.

Andy

> On Nov 25, 2019, at 11:10 AM, Liam Breck  wrote:
> 
> 
> 
> On Mon, Nov 25, 2019, 10:32 AM Andy Balholm  <mailto:andybalh...@gmail.com>> wrote:
> 
> 
> > On Nov 25, 2019, at 9:54 AM, Liam  > <mailto:networkimp...@gmail.com>> wrote:
> > 
> > - does the read-to-EOF stipulation also apply to Client.Get/Post() ?
> 
> Yes. Those methods are fairly simple wrappers around Do.
> 
> > - why does Response.Body.Close() before io.EOF not release unread buffers 
> > or otherwise prepare it for persistence?
> 
> The connection can’t be reused for another request before all the data from 
> the first request is read. The server is sending those bytes over the wire, 
> and they need to go somewhere before another response can be read. So there 
> were two options for how to implement Close when the whole body hasn’t been 
> read:
> 
> 1. Copy the rest of the body to /dev/null (or equivalent), and reuse the 
> connection like normal.
> 2. Close the connection, thus communicating to the server that we don’t need 
> that data after all.
> 
> Option 1 would generally be preferable for short responses, and option 2 for 
> long ones. For consistency, and because we don’t always know the response 
> length in advance (e.g. if it is chunked), it always does option 2.
> 
> So after read-to-EOF, Close() behaves differently, i.e. it does reset for 
> next request?
> 
> In the event of early Close(), should I discard that Client instance? Or will 
> it work for subsequent requests?

-- 
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/5DB3F0EE-D976-412C-860F-C4468AF99B1F%40gmail.com.

Re: [go-nuts] Looking for an app w/ mult. versions of a dependency

[Andy Balholm]

I’m pretty sure there is no “otherwise simple” example, because depending on 
two versions of the same library isn’t usually something a project does 
deliberately (except as a last resort). It’s normally the consequence of an 
extremely complex forest of dependencies.

Andy

> On Dec 5, 2019, at 5:52 PM, George Hartzell  wrote:
> 
> 
> Hi All,
> 
> I'm working on improving the Spack (https://spack.io) package managers
> support for Go-based application
> (https://github.com/spack/spack/issues/13023).
> 
> I'm trying to wrap my head around what Go's support for simultaneously
> using multiple major versions of a dependency means to Spack.
> 
> To that end, I'm looking for an otherwise simple application that uses
> Go modules and depends on multiple versions of some library.  I've
> done a bit of searching but have come up dry.
> 
> I'm wondering if any of you other nuts can point out examples?
> 
> Thanks,
> 
> g.
> 
> -- 
> 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/24041.46159.307729.108343%40alice.local.

-- 
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/E809B0DE-82E7-4C0B-A3D0-572EB3FAA7FE%40gmail.com.

Re: [go-nuts] Win xp

[Andy Balholm]

https://golang.org/doc/install  says that 
Windows XP is supported. Maybe your Windows 10 machine is 64-bit and your 
Windows XP machine is 32-bit. Try setting the GOARCH environment variable to 
386 before you compile to generate 32-bit EXE files.

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.

Re: [go-nuts] Go string to uintptr

[Andy Balholm]

If you use cgo, there is a helper function C.CString to do this.

You can convert the string to a []byte, append 0 (for a null-terminated 
string), and take the address of the first byte.

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.

Re: [go-nuts] Adding YAML to the stdlib

[Andy Balholm]

What do you mean by “community”? Is it those of us who aren’t employed by 
Google?

Is it any more unfair for the Go team at Google to expect Gustavo (or others) 
to maintain his YAML package than for some in the community to expect the Go 
team to take it over?

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.

Re: [go-nuts] TimeZone Query: Time Difference between EST and UTC

[Andy Balholm]

Right now there is a 4-hour difference between Eastern (Daylight) Time and UTC. 
But you asked for “EST”, and that is what you got: Eastern *Standard* Time. If 
you want a Location that automatically switches between EST and EDT, ask for 
“America/New_York”.

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.

Re: [go-nuts] Reading http.Request.Body...

[Andy Balholm]

I think what you need is io.ReadFull.

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.

Re: [go-nuts] Deleting the /r/golang subreddit

[Andy Balholm]

I took the usage of “men” in that comment to be gender-neutral. I read it as 
“Are you rankist?", not as “Are you sexist or rankist?”

(I don’t know if rankist is a word, but I mean someone who discriminates on the 
basis of rank.)

Andy

> On Nov 27, 2016, at 6:43 PM, vac...@gmail.com wrote:
> 
> 
> I would just like to point out what a genuinely vile response this is. Your 
> vague and menacing implication is that Florian is somehow a sexist because he 
> disagrees with you is beneath you, Dave, and you should apologise. 
> 
> 
> On Friday, November 25, 2016 at 6:26:40 PM UTC+13, Dave Cheney wrote:
> On Fri, Nov 25, 2016 at 4:24 PM, Florian Weimer  > wrote: 
> > * Brad Fitzpatrick: 
> > 
> >> In light of the CEO of Reddit admitting to editing user comments (see 
> >> dozen news stories today), I propose we delete the /r/golang subreddit. 
> >> 
> >> That is so beyond unethical and immature, 
> > 
> > Was it immature because they didn't make any money out of it, at least 
> > not directly?  Modifying user-generated content without informed 
> > consent is standard business practice.  You must be aware of that. 
> > (Many people who read this will see totally misleading ads next to 
> > this post, for instance, and I obviously never agreed to that.) 
> > 
> > It was a bad prank for sure.  But it was just a prank. 
> 
> Do you normalise the behaviour of all men, or only those at the C level? 
> 
> > 
> > -- 
> > You received this message because you are subscribed to a topic in the 
> > Google Groups "golang-nuts" group. 
> > To unsubscribe from this topic, visit 
> > https://groups.google.com/d/topic/golang-nuts/XoOhzUClDPs/unsubscribe 
> > . 
> > To unsubscribe from this group and all its topics, 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] validating self-signed certs

[Andy Balholm]

Why not make a tls.Config that trusts all the self-signed certs for all the 
different devices, and make one Transport with that config?

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.

Re: [go-nuts] validating self-signed certs

[Andy Balholm]

So the set of devices keeps changing. 

I think you can make an http.Transport with a custom DialTLS function that 
always uses an up-to-date TLS config.

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.

Re: [go-nuts] How to speed up execution time for a set of regular expressions

[Andy Balholm]

If it’s actually just a list of keywords (no wildcards, character ranges, 
etc.), I would recommend using Aho-Corasick string matching rather than regular 
expressions.

Andy

> On Dec 13, 2016, at 7:53 AM, David Sofo  wrote:
> 
>  Hi,
> 
> For a set of rules expressed in regular expression (around 1000 rules 
> expected) to find some keywords in a text file (~50Ko each file), how to 
> speed up the execution time. Currently I compile the regex rule at 
> initialization time with init function at put them in a map at package level 
> then run the regex rules with a loop. The regex have this form:
> 
> \b(?:( (A1|A2|A3) | (B1|B2|B3) ) )\b
> 
> spaces are put for readability. A and B are classes of keywords.
> 
> How to speed up the execution: at regular expression level or others levels 
> (such execution priority). I am using Ubuntu 14.04. Any suggestion is 
> welcome.  Thank you.
> 
> Here a code
> 
> Regards
> David
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 to speed up execution time for a set of regular expressions

[Andy Balholm]

Right. Aho-Corasick can’t be used directly in that case.

But it might still be a major performance win to use Aho-Corasick for the first 
pass, and then confirm with regexes. In other words, if the Aho-Corasick stage 
finds “associate,” then check whether /associate.*with/ matches.

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.

Re: [go-nuts] howto: compile template against well-known structure ?

[Andy Balholm]

I don’t know if this will be helpful to you or not, but I’ve made a package 
that is basically a copy/paste of the autoescaping logic from html/template, 
but modified to work at runtime instead of when compiling a template: 
github.com/andybalholm/escaper 

It lets you write your “template” logic in plain Go instead of the special 
template language, without needing to spend a lot of extra effort on escaping. 
The runtime impact would be mixed: you would lose the overhead of reflection, 
but gain the overhead of figuring out HTML contexts at runtime. I don’t know if 
it would be a net performance gain or not.

Anyway, your RenderComponent method would look something like this:

func (b *ButtonRenderer) RenderComponent(wr io.Writer, view 
mgc.ViewComponentRenderer, args ...interface{}) (string, error) {
if button, ok := view.(*components.Button); !ok {
return "", errors.New("wrong type expected components.Button")
} else {
e := escaper.New(w)

tag := "button"
if button.Attr.Has("href") {
if button.Attr.Has("disabled") {
tag = "span"
} else {
tag = "a"
}
}

e.Literal("<"+tag+" ")

for _, v := range button.Attr {
e.Print(v.Name+"='", v.Value, "' ")
}

e.Print("class='", button.Classes.Render(), "' ")

if button.GetValue() != "" {
e.Print("value='", button.GetValue(), "'")
}

e.Print(">", button.GetLabel(),  "")
}
return "", nil
}

The only real thinking about escaping you need to do is deciding whether to use 
a plus or a comma between strings you want to join, to preserve the proper 
alternation between literals and values in the arguments to e.Print.

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.

Re: [go-nuts] Do you guys use ORMs when working with SQL?

[Andy Balholm]

On Dec 30, 2016, at 4:43 AM, paraiso.m...@gmail.com wrote:
> 
> Ultimately even if you stick to SQL you are just also writing your own ORM , 
> you just can't generalize code because of Go type system.

There are really two separate (but related) issues in the ORM debate: the ORM 
design pattern, and ORM libraries. 

By “the ORM design pattern,” I mean the concept that there should be a direct 
mapping between the objects in your program and the tables in your database. In 
other words, that each table in the database should correspond to a type or 
class, and that each row of that table corresponds (at least potentially) to an 
instance of that type.

ORM libraries, of course, are abstractions created to make it easier to write 
code that follows the ORM design pattern.

Many people seem to take the ORM design pattern for granted, and just debate 
whether it’s better to do the mapping manually or to use an ORM library. But I 
am skeptical of the design pattern itself. I seldom create a type that 
corresponds exactly to one of my database tables. Most often I use a struct or 
slice of structs that corresponds to the data I want from a particular database 
query; usually it is an anonymous type, declared directly in my HTTP handler 
function. Then I have some helper functions (most notably one called queryInto) 
that fill in the data with the results of the query.

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.

Re: [go-nuts] Google Grumpy (Python->Go)

[Andy Balholm]

Finally, a way to deploy a Python program as a statically-linked binary!

The Go code this produces looks awful. It’s more like threaded code in Go 
syntax than like real Go. It translated my toy benchmark function

def count(x):
i = 1
while i <= x:
i += 1

into

// line 12: def count(x):
πF.SetLineno(12)
πTemp003 = make([]πg.FunctionArg, 1)
πTemp003[0] = πg.FunctionArg{Name: "x", Def: nil}
πTemp001 = πg.NewFunction(πg.NewCode("count", "count.py", 
πTemp003, 0, func(πF *πg.Frame, πArgs []*πg.Object) (*πg.Object, 
*πg.BaseException) {
var µx *πg.Object = πArgs[0]; _ = µx
var µi *πg.Object = πg.UnboundLocal; _ = µi
var πTemp001 *πg.Object
_ = πTemp001
var πTemp002 bool
_ = πTemp002
var πTemp003 *πg.Object
_ = πTemp003
var πE *πg.BaseException; _ = πE
for ; πF.State() >= 0; πF.PopCheckpoint() {
switch πF.State() {
case 0:
default: panic("unexpected function state")
}
// line 13: i = 1
πF.SetLineno(13)
µi = πg.NewInt(1).ToObject()
// line 14: while i <= x:
πF.SetLineno(14)
Label1:
if raised := πg.CheckLocal(πF, µi, "i"); raised 
!= nil {
continue
}
if raised := πg.CheckLocal(πF, µx, "x"); raised 
!= nil {
continue
}
if πTemp001, πE = πg.LE(πF, µi, µx); πE != nil {
continue
}
if πTemp002, πE = πg.IsTrue(πF, πTemp001); πE 
!= nil {
continue
}
if !πTemp002 {
goto Label2
}
// line 15: i += 1
πF.SetLineno(15)
if raised := πg.CheckLocal(πF, µi, "i"); raised 
!= nil {
continue
}
if πTemp003, πE = πg.IAdd(πF, µi, 
πg.NewInt(1).ToObject()); πE != nil {
continue
}
µi = πTemp003
goto Label1
goto Label2
Label2:
return nil, nil
}
return nil, πE
}), πF.Globals()).ToObject()

It’s also about 2x slower than the original Python. All of this indirection is 
necessary to preserve the dynamic semantics of Python. Basically it’s taking 
the calls into the runtime that a Python interpreter would make, and writing 
them out one after another.

So don’t expect it to be a way to magically migrate your old Python project to 
idiomatic Go.

But what it does provide is Python with goroutines instead of the GIL, and with 
extension modules written in Go instead of C.

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.

Re: [go-nuts] should every .gz file be served with content-encoding gzip?

[Andy Balholm]

It all depends on what the user wants to have when they are done downloading. 
In the case of HTML, CSS, and JS, they want an uncompressed file that is ready 
for their browser to use. So you should use Content-Encoding: gzip and 
Content-Type: text/html or whatever. In the case of a .tar.gz, they may be 
expecting to find a tar.gz file in their downloads folder, so you should use 
Content-Type: application/gzip (not just gzip).

But rather than trying to guess what the user wants, you can go by the filename 
in the request. If the request specifies a filename ending in .gz, use 
Content-Type: application/gzip; if your server is adding the .gz, use 
Content-Encoding: gzip. (And check the Accept-Encoding header too.)

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.

Re: [go-nuts] should every .gz file be served with content-encoding gzip?

[Andy Balholm]

1. It is unexpected. When I click a link that ends with .tar.gz, I expect to 
get a .tar.gz file.
2. It is a waste of disk space. Sure, as soon as they download the tarball, 
they will extract it. But they still need the space for both the tarball and 
the contents at the same time. So we might as well let them conserve space if 
they want to.
3. Some programs don’t accept uncompressed .tar files; they require .tar.gz.

> On Jan 14, 2017, at 10:57 AM, Anmol Sethi  wrote:
> 
> While it is unexpected, what is wrong with just serving a tar file and 
> redirecting a foo.gz request to a foo request? Why should a user want to have 
> a .gz file after downloading?
> 
> On Sat, Jan 14, 2017 at 1:31 PM Andy Balholm  <mailto:andybalh...@gmail.com>> wrote:
> It all depends on what the user wants to have when they are done downloading. 
> In the case of HTML, CSS, and JS, they want an uncompressed file that is 
> ready for their browser to use. So you should use Content-Encoding: gzip and 
> Content-Type: text/html or whatever. In the case of a .tar.gz, they may be 
> expecting to find a tar.gz file in their downloads folder, so you should use 
> Content-Type: application/gzip (not just gzip).
> 
> But rather than trying to guess what the user wants, you can go by the 
> filename in the request. If the request specifies a filename ending in .gz, 
> use Content-Type: application/gzip; if your server is adding the .gz, use 
> Content-Encoding: gzip. (And check the Accept-Encoding header too.)
> 
> 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.

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Andy Balholm]

Actually, the mention of gofmt brings up the issue of consistent formatting. If 
underscores in numbers were allowed, gofmt should automatically insert them for 
all numbers over a given length, and remove them for shorter numbers. Otherwise 
it would just be another opportunity for inconsistency, like indentation.

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.

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Andy Balholm]

The same is true of brace styles :-P.

But my point is that by not allowing digit grouping, Go avoids style debates on 
that issue. The grouping could have been standardized with gofmt, but as it is, 
it is standardized by the compiler to a format that is universally understood 
(no grouping).

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.

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

[Andy Balholm]

When a function is used incorrectly, a panic is appropriate. If the count comes 
from an untrusted source, the caller should check that it is non-negative (and 
not too large) before calling Repeat, rather than checking an error afterward. 

Using a uint would actually be worse, since uint(int(-1)) is an extremely large 
number.

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.

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

[Andy Balholm]

Yes, panic would probably have been a better choice there. In the API cleanups 
leading up to Go 1, the team removed some of the error returns from the 
NewWriter functions in the compress/* packages 
(https://codereview.appspot.com/5639057), but maybe it would have been good to 
go farther.

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.

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

[Andy Balholm]

In this particular case, the only possible error is that the compression level 
is invalid. The documentation says that the error will be nil if the level is 
valid.

-- 
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] Speeding up multiple regexp matches

[Andy Balholm]

in github.com/andybalholm/redwood , one 
thing I do is to check each URL against a (potentially very large) set of 
regular expressions. Since these regular expressions generally contain fairly 
significant amounts of literal text, I analyze each regular expression to see 
if I can find a set of strings such that every URL that matches that regular 
expression must contain at least one of those strings. (This is done in the 
file restring.go.) I combine the sets of strings from all the regular 
expressions, and do an Aho-Corasick string search based on that list of 
strings. From the results of the string search, I know which regexps are 
possible matches, and I test those against the URL.

This is all wrapped up in the regexMap type in url.go.

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.

Re: [go-nuts] Initialize Variables in case clause of a switch

[Andy Balholm]

I’ve wished for it too, but I just use an else/if chain in that case.

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.

Re: [go-nuts] Getting root file path of USB pen drive

[Andy Balholm]

On Mac, you can get a listing of /Volumes, and ignore whichever entry is a 
symlink to / (since that is the boot drive). This will give you both external 
drives and network shares; I’m not sure if there is an easy way to distinguish 
the two; one possibility is that physical drives seem to be owned by root, and 
network shares are owned by the user that connected to them.

A potential cross-platform option would be to parse the output of the mount 
command (with no arguments, it prints a list of mounted volumes). But the 
filtering could be a challenge.

The Linux-specific solution is probably somewhere in /proc, but I don’t know 
where.

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.

Re: [go-nuts] Migrating from a classic OO pattern

[Andy Balholm]

The second thing you tried is usually the best way to do this in Go: define an 
interface with the methods that vary by type, and then make a function with the 
type-independent logic. It’s actually cleaner in many cases than the classic OO 
way with overriding methods, but a direct translation from the OO way can be 
messy. 

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.

Re: [go-nuts] What is use for [:] of a slice?

[Andy Balholm]

Most likely they originally used an array, and changed it to a slice later. 
Since that line still compiled, it didn’t get changed. Or else they are just 
confused.

Anyway, I can’t think of any reason to use [:] on a slice either.

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.

Re: [go-nuts] Help - main.go:15: undefined: say

[Andy Balholm]

You defined say inside main, but Super is defined outside main, so say is not 
in scope there. Move the definition of say outside of main, so that it is a 
top-level (global) declaration.

Andy

PS Even after you do that, your program will print 9000 rather than 19000, 
because Super is modifying a copy of goku. If you want to modify goku itself, 
you need to pass a pointer to Super.

-- 
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] Appending a path to an URL

[Andy Balholm]

The part being added is treated as an absolute path, because it starts with a 
slash, so it replaces the existing path.

Andy

> On Jan 31, 2017, at 2:09 PM, Manlio Perillo  wrote:
> 
> Il giorno martedì 31 gennaio 2017 18:35:02 UTC+1, Manlio Perillo ha scritto:
> Thanks, I was not aware of this behavior.
> 
> The documentation says:
> "Parse parses a URL in the context of the receiver. The provided URL may be 
> relative or absolute."
> 
> Probably an example should be added?
> 
> Manlio
> 
> Il giorno martedì 31 gennaio 2017 13:07:48 UTC+1, Martin Gallagher ha scritto:
> Is this what you want: https://play.golang.org/p/BW96Bk_sqJ 
> 
> 
> Unfortunately it does not work:
> https://play.golang.org/p/P0hNqnE9Ol
> 
> I'm not even sure to understand *why* it does not work for this case.
> 
> Manlio 
> 
> -- 
> 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] VERY weird timezone behavior

[Andy Balholm]

Note the date that is printed with the times. Since Jan. 1 of year zero (1 BC?) 
predates the establishment of standard time zones, Go converting from 1:00 PM 
mean solar time at Stockholm to 12:53 PM mean solar time at Berlin. (Or is the 
time used at Stockholm something different? It doesn’t seem quite right for 
Stockholm’s longitude… But I doubt many people at Stockholm were using clocks 
that long ago anyway!)

The time zones in the time zone database that Go uses are far more than just a 
list of static offsets from UTC.  Mr. Olson (and others) have attempted to 
collect the entire history of standard time at each location. 

Anyway, time zone conversions with a time and no date don’t work, even if you 
restrict them to the modern era. When it’s noon at Phoenix, what time is it at 
Los Angeles? Maybe noon, maybe 11 AM. It depends on the time of year (and the 
year; Arizona observed Daylight Saving Time in 1967).

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.

Re: [go-nuts] The feature I want most, weak *

[Andy Balholm]

Maybe you could use “notwithstanding". It’s an ignored token in the default Go 
compiler, and a weak pointer is one that allows an object to be freed 
notwithstanding any weak references to it…

It’s not in the spec, though, so it might cause problems with other Go 
implementations such as gccgo. I think gofmt has problems with it too.

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.

Re: [go-nuts] The feature I want most, weak *

[Andy Balholm]

I expect you’re just left with the option of magic comments then, since there’s 
not going to be much enthusiasm for adding a new do-nothing keyword to the 
language.

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.

Re: [go-nuts] Go -> C++ transpiler idea: Miracle child or horrible abomination?

[Andy Balholm]

If global ownership inference, with enough flexibility to replace a garbage 
collector, were practical, I suppose the Rust compiler would have it already. 
But if you want to prove the Rust developers wrong, go ahead and do it in a 
transpiler.

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.

Re: [go-nuts] [ANN] sqlite

[Andy Balholm]

As near as I can tell, this is an intermediate step in a project whose ultimate 
goal is to compile sqlite into Go—asm.go (a style like asm.js), apparently.

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.

Re: [go-nuts] [ANN] sqlite

[Andy Balholm]

This discussion piqued my interest, and I decided to see what I could do to 
make rsc.io/c2go  more general-purpose. My fork is at 
github.com/andybalholm/c2go . I think that, 
with appropriate .h and .cfg files, it can now handle the tests from 
elliotchance/c2go.

Some thoughts on how the projects compare:

Jan’s project is clearly intended for cases where the C source will always be 
the canonical representation of the project, since the Go code he plans to 
produce will be unreadable and unmaintainable. But it is the most universal. In 
theory at least, the approach would be able to handle any C source, no matter 
how obfuscated, and produce a Go package out of it.

The other two projects produce Go code that, while not idiomatic, is fairly 
readable. One of the biggest differences is that Elliot’s runs the code through 
a real C preprocessor (in clang), and Russ’s doesn’t. (It supports #include, 
and I’ve added simple #defines for constants.) Using a real preprocessor 
definitely increases universality, and allows using system headers instead of 
the custom, stripped-down headers that Russ’s works best with. On the other 
hand, a preprocessed file tends to contain extra cruft.

One plus for readability for Russ’s is that it preserves comments. Russ’s is, 
of course, the most mature, since it has been used on a large real-world 
codebase.

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.

Re: [go-nuts] understanding utf-8 for a newbie

[Andy Balholm]

Hexdump shows the actual bytes in the file—the UTF-8 encoding of the runes 
(Unicode code points). Apparently you are reading them with utf8.DecodeRune or 
something like that; those return the code points, without the UTF-8 encoding.

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.

Re: [go-nuts] letsencrypt, localhost and autocert

[Andy Balholm]

What it boils down to is that your server tries to get a certificate for 
whatever name is in the URL. But Let’s Encrypt won’t issue a certificate for 
localhost, for various reasons—not the least of which is that a certificate for 
localhost makes as much sense as having a photo ID that says “Me” for the name.

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.

[go-nuts] http2.Transport connections seem to occasionally get "stuck"

[Andy Balholm]

Users of github.com/andybalholm/redwood (an HTTP proxy) are running into an 
intermittent problem that I suspect is an HTTP/2 bug. But it is very difficult 
to pin down.

The symptom reported by the customers is that, for an hour or two, all 
connections to Google servers through the proxy time out. If the proxy is 
restarted, they work fine. My suspicion is that the proxy is multiplexing all 
the connections to Google servers on a single HTTP/2 connection, and somehow 
that connection is getting into an unusable state but not closing or returning 
an error.

The user that has this problem most frequently is using a 4G cellular 
connection, so network flakiness could definitely be a factor in triggering 
this situation.

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.

Re: [go-nuts] slow Mod function in math/big, a better way?

[Andy Balholm]

That’s normal for languages like Python. The code that is actually running in 
Python is slow, but library functions are fast, because they are written in C.

Andy

> On Jul 7, 2017, at 4:51 AM, jeff.templon.nik...@gmail.com wrote:
> 
> Hi
> 
> Exploring Go, 1st project is to port over my favourite playground (prime 
> number factorisation) from Python to Go.
> 
> Aside: I was a big Oberon-2 fan back in the day, so I'm pretty excited about 
> Go making possible what never was in Oberon.  
> 
> Back to business: I was disappointed that Go is only a factor of 3 or so 
> faster than Python.  The numbers I'm dealing with are big enough that they 
> don't fit into a uint64 so I'm using math/big ... turns out that about 70% of 
> the runtime is spent in the Mod function of math/big, and mostly this is 
> inside the underlying function divLarge. See profile info below.   
> 
> The naive explanation would be that Mod in Go math/big is about just as fast 
> as the % primitive in python (Python has big integers automatically where 
> needed) but the rest of the program is a factor of 10 or so faster in Go than 
> Python.  I wonder though, especially if there is a better way to take a Mod.  
> The numbers are not THAT large (less than 100 decimal digits in most cases) 
> ...
> 
> (pprof) top10 -cum
> 13.01s of 41.11s total (31.65%)
> Dropped 86 nodes (cum <= 0.21s)
> Showing top 10 nodes out of 74 (cum >= 6.66s)
>   flat  flat%   sum%cum   cum%
>  0 0% 0% 40.45s 98.39%  runtime.goexit
>  0 0% 0% 40.20s 97.79%  main.main
>  0 0% 0% 40.20s 97.79%  runtime.main
>  0.28s  0.68%  0.68% 40.19s 97.76%  
> _/Users/templon/gofact/factoring.Mybrent
>  0 0%  0.68% 40.19s 97.76%  
> _/Users/templon/gofact/factoring.Trial_n_X
>  0.44s  1.07%  1.75% 29.42s 71.56%  math/big.(*Int).Mod
>  0.77s  1.87%  3.62% 28.98s 70.49%  math/big.(*Int).QuoRem
>  0.51s  1.24%  4.86% 28.18s 68.55%  math/big.nat.div
> 10.39s 25.27% 30.14% 27.47s 66.82%  math/big.nat.divLarge
>  0.62s  1.51% 31.65%  6.66s 16.20%  runtime.makeslice
> 
> 
> -- 
> 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] slow Mod function in math/big, a better way?

[Andy Balholm]

I noticed your “naive explanation” after I sent my message. But I think it is 
the real explanation.

Is there a better way to do it in Go? Probably not. The math/big library isn’t 
quite as fast as gmp, but it’s probably faster than anything you’d write 
yourself. If the numbers were really huge, you’d probably gain some by calling 
gmp with cgo. But for moderate-sized numbers, the cgo overhead would probably 
cancel out your gains.

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.