[go-nuts] Remind me, please, about "taking over" a socket

[David Collier-Brown]

My leaky brain has lost an old technique...

Once upon a time, I would send an old copy of a program a SIGHUP, and it 
would shut down a socket listening on, for example, port 25 (SMTP). A newer 
release of the program would succeeding in binding to port 25, taking over 
any new connection requests. When the old program closed it's last email 
transfer, it would then exit.

The idea was to update a (mail-)server implementation without losing 
transactions.

I can no longer find the code I once used, nor other people's examples, 
much less modern Golang examples!

Please tell me we haven't lost this technique (:-()

--dave

-- 
You received this message because you are subscribed to the Google 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/36fabc29-6ccc-45f6-99bb-f728710c6e18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Deferring a close that can fail

[David Collier-Brown]

Hmmn, Donald Knuth would not have liked this (;-))

Knuthput, if I remember correctly, didn't have "fail on close()" semantics.
>
>
--dave

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

Re: [go-nuts] Re: Deferring a close that can fail

[David Collier-Brown]

Looks as if "Close()-like things" all fall into two categories

   - the usual horrid one, in which you can discover too late something 
   didn't complete, or
   - the trivial case, in which the pre-close operations are transactional 
   and xxx.Close() only ever returns nil

Which means I have to make my work transactional. In this case I did, but 
I'm lazy and would really really prefer Tony Hoare to have done that. 

As usual, I ended up drawing DFAs and boring my colleagues to tears 
reviewing the correctness of the code that wrote output (to influx) and got 
a nil error back before it marked the input (from Kafka) as having been 
read.

That and a bunch of code-reading allows me to treat this (one! singular! 
individual!) case of a failed close as a harmless horrible thing. A thing 
that requires me to rerun the program, so that it can re-read anything that 
I haven't marked as committed.

Sigh. 

Safety-critical system development is cool, but it's not *fun* unless you 
like brain pain. Or writing proofs in prolo(n)g.
 
--dave (admitted nerd, but not masochist) c-b

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Deferring a close that can fail

[David Collier-Brown]

>
> On Wednesday, March 20, 2019 at 1:44:23 AM UTC-4, Shulhan wrote:

Any Close on file or connection should be called only if only the 
> call to Open function or method success. 
>
> You have two options here: either you remove the panic when Close is 
> error (only logging it) or call Close only if Open is success.  I 
> usually prefer the latter. 
>
> -- 
> { "github":"github.com/shuLhan", "site":"kilabit.info" } 
>

You and I agree: my code snippit will panic if the open fails,  or if (the 
open suceeds && the close fails)

--dave 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Deferring a close that can fail

[David Collier-Brown]

4:12 PM (less than a minute ago)

> Any Close on file or connection should be called only if only the 
> call to Open function or method success. 
>
> You have two options here: either you remove the panic when Close is 
> error (only logging it) or call Close only if Open is success.  I 
> usually prefer the latter. 
>
 
You and I agree: my code snippit will panic if the open fails,  or if (the 
open suceeds && the close fails)

--dave

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Deferring a close that can fail

[David Collier-Brown]

>
> Any Close on file or connection should be called only if only the 
> call to Open function or method success. 
>
> You have two options here: either you remove the panic when Close is 
> error (only logging it) or call Close only if Open is success.  I 
> usually prefer the latter. 
>
 
You and I agree: my code snippit will panic if the open fails,  or if (the 
open suceeds && the close fails)

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Deferring a close that can fail

[David Collier-Brown]

It's a known bad thing to defer a close for anything buffered, as discussed 
at https://www.joeshaw.org/dont-defer-close-on-writable-files/
but some constructs lack a Sync() call.

For example, I have code like
ifDB, message, err := OpenInflux(server, debug)
if err != nil {
// If this fails, fail fast so we notice
panic(fmt.Errorf("failed to open and ping influxDB, %s %v",
message, err))
}
defer func() {
err = ifDB.Close()
if err != nil {
// This may be a harmless, very bad thing
panic(fmt.Errorf("failure closing connection to 
influxDB, %v", err))
}
}()


which closes an influxDB database, but will panic if the close fails.

Separate logic makes sure I have passed the point at which the data is 
committed before I commit my reading of input, so eventually the data will 
be reread and rewritten. Nevertheless, this is exceedingly complex, and the 
comment sums it up: "a harmless, very bad thing".

Is there an idiomatic way to address this? I ended up reading influxDB code 
and doing all sorts of deranged safety-critical-system DFAs to reassure 
myself this will actually work, but every time I do that, my brain hurts!

--dave


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Dependency hell with Go modules

[David Collier-Brown]

You're playing in a space where there are NP-complete problems, as 
described in part 
by 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/

Run screaming from the building (;-))

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Suggestions for layout/structure/coding-patterns for GUI applications in Go?

[David Collier-Brown]

I'm pleasantly mature (born in 1644), but I still don't understand 
javascript GUIs (;-))

--dave
 
On Friday, January 11, 2019 at 11:53:03 PM UTC-5, Lucio wrote:
>
>
>> I think it's a maturity thing, with the added complexity that the need 
> for an immediate solution prevents any study of possible generic (not as in 
> "generics", though) solutions.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: if/switch statements as expressions

[David Collier-Brown]

Very *very* regular languages like lisp barely made a distinction between 
expressions and statements, so if was an expression.  I'm not sure how well 
that would work in a c-like language like Go: the debate about that in 
algol68 was about 8 years before I became interested in computers.

Anyone here remember how algol68 addressed that, or what the hollering was 
about?

--dave 
 
On Wednesday, December 19, 2018 at 3:09:35 PM UTC-5, Viktor Kojouharov 
wrote:
>
> I'm interested to know whether it was considered (I can't imagine that it 
> wasn't) for if and switch statements to be expressions instead, and if so, 
> why were they ultimately left as 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.

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

[David Collier-Brown]

Mr. Tiwari: 

Major ports are rather like major rewrites, in that if you think of the 
program as a tree, the parts that stay the same are the trunk and branches, 
and the parts that change are the leaves.  

If you draw a picture of the old program on a whiteboard, you have an 
(initial) design for the new program. If the calls and parameters look like 
a reasonably good API, you can start by writing *mock leaves*, which will 
help you understand both the program and the new language. it should pass 
your integration tests, albeit with fake data.

Then start filling in the low-level details, starting with the *last* step 
and working backwards. Each time you break something, your tests will tell 
you, and you can fix it quickly.

In a previous life, this and some elegant tooling allowed my employer to 
make a profit off doing fixed-price ports. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Closure, recursion and higher-order functions

[David Collier-Brown]

Recursion often, iteration *very* often, closure with care and conscious 
effort.
Higher order functions? Generate and execute all the time, passing and 
using functions a bit less. 

R, I and H are easy to reason about, you see. C takes due care.

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Rethink possibility to make circular imports

[David Collier-Brown]

I find the same, but eventually I come up with a way to clarify. Just *Not 
Real Soon* (;-))


>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Static assert at compile time

[David Collier-Brown]

In the special case of versioning, think about implementing "updaters" or 
"downdaters" on receipt of a versioned object/struct, as 
in 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/

For other uses, if you describe them here, we might be able to make a 
useful suggestion or two.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Rule-swarm attacks can outdo deep reasoning

[David Collier-Brown]

In a previous life, two co-op students did the B-to-C conversion suite for 
Honeywell as a suite of transformations for use by developers. Ten years 
later, my team and I did porting tools that provided humans with advice, 
some of which was trivially sufficient, others were merely advisory.  

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

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

[David Collier-Brown]

Not a problem! 



On Thursday, September 20, 2018 at 11:55:04 AM UTC-4, Michael Jones wrote:
>
> [Apologies to Dave Cheney, timely pushback for David Collier-Brown]
>
> David, I disagree and suggest your remark is not well considered. Three 
> replies, one per sentence.
>

Not a problem! Indeed, thanks for the response.
 

>
> *"Right now, this looks like the third draft of an academic project."*
> Not to me. This reads like years of thought and discussion among qualified 
> researchers and skilled implementers. Not to boast unduly, but if you look 
> at the history of Ian, Robert, and Russ, you'll see intimate responsibility 
> not only in Go but in Gnu C/C++, Modula, and more. What I see in the 
> proposal is informed wisdom. This is engineering so there is always a 
> better way, but this may be the best that can be seen before implementation 
> and experience.
>
>
I've indeed worked with generics in other languages, and always considered 
that Go, which says it doesn't have generics, has the best set. 

Mind you, the notation is opaque. It says "create me a bunch of X", for a 
couple of heavily-used meanings of "bunch".  You have to read an article on 
how it does it to understand the what. 

My usage of generics over the years has tended to collapse from many types 
originally to just sequences and hash tables. I literally don't remember 
the last time I did anything more complex in C++ or Java. Maybe a table of 
sequences, for a library for Steam games.

I don't mean it as an insult to the skills of the community, but I don't 
see it as an advance, but rather as another experiment *in search of *an 
advance.  To restate your "there is always a better way, but this may be 
the best that can be seen before implementation and experience",  I think 
it could be the best way before implementation and experience, but I really 
wish to see more implementations, inclusive of this one, as conscious 
experiments.  

And I should say that the title doesn't characterize my thoughts (;-)). I 
am in favor of generics, but I'm cautious in my enthisiasm.

 

> *"It suffers badly by comparison to make(), the existing mechanism."*
> Yes, inherently so. The existing mechanism uses magic in parsing and 
> implementation—details known in the compiler but not exposed in the Go 
> language generally, to make things as easy as possible. It is nice. But 
> from before the launch of Go users asked "how can I do such things 
> generally, in my code, and not by extending the language or the compiler." 
> The answer was "use interfaces now and we'll think about generics later." 
> Later is now and indeed exposing aspects of behind the scenes compiler 
> magic is more complicated, that's inherent. The decision to be made is how 
> powerful vs how complicated.
>

I find the idea of make to be a simple API, just like a library. You ask it 
for a map of structs indexed by an int, and it gives you one.  The 
overloading of m = make(map[string]int) versus a = make([]int, 5) makes me 
wonder what's happening. That, IMHO, is something that needs a better 
notation, where different parameter lists have differentiable names.

Using an old *butt-ugly* notation, I would like distinguishable forms like 
a:= []int.New(5) and m := [int]string.New() 

At that point, the opacity is the same as with an API: it says to create a 
slice of int of size 5, implemented on an array, or a map of strings 
indexed by int, implemented as a thing in itself.  If I need more context, 
I read the code and/or the blogs.



> "Can we see some more alternatives, please?"
> They are legion. Existing generics approaches in various languages are 
> more than ideas, they are living examples of design, ecosystem, and 
> behavior. Several proposals have been offered by the Go team and 
> collaborators here. The Go 2 design site lists many specific comments and 
> alternatives. Extensive thoughts have been shared, with *responsa sunt, 
> novi in via*.
>

Yes, I agree.  Perhaps "ex Africa semper aliquid novi*" *will be our saving 
grace, or as the cavalry says, "keep on hacking, Algy" (;-))

Limited objectives, tight control is never fun, but we have 
something surprisingly good with the magic make() incantation. I'd love to 
see something that's a single step more general and a bit less like formal 
magic.

--dave
  

>
> Not a personal attack. Trying to inform these statements and encourage 
> review and consideration.
>
> Michael
>
> On Thu, Sep 20, 2018 at 5:04 AM David Collier-Brown  > wrote:
>
>> Right now, this looks like the third draft of an academic project.  It 
>> suffers badly by comparison to make(), the existing mechanism.
>>
>> Can we see some more alternatives, please?
>>
>> --da

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

[David Collier-Brown]

Right now, this looks like the third draft of an academic project.  It 
suffers badly by comparison to make(), the existing mechanism.

Can we see some more alternatives, please?

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] gofmt formats different than goimports in go1.11

[David Collier-Brown]

>
>
> It was funnier inside my head. 
>
>
Sounded grumpy from out here. 

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

Re: [go-nuts] Re: Busted auth providers

[David Collier-Brown]

On 09/05/18 11:30 AM, jwint...@pivotal.io wrote:


We're innocent victims (;-)) and need to decide if we're
supporting the spec or the customers.  Right now we're supporting
the spec.


I mean you've already decided to support a specific list of customers 
who don't adhere to the spec. So you're kind of already supporting 
both. Why not just make it easier?


I read the existence of a list as a warning to people who attempt to 
follow the spec that they will needed a workaround for a particular 
group.  If we were supporting the "won't do" customers, we would 
presumably have changed our defaults instead.


--dave

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

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

Re: [go-nuts] Re: Busted auth providers

[David Collier-Brown]

That's really a question for the oauth principals: if they say "don't do 
that" and the customers don't listen, they have a problem to either fix 
or add to the spec as supported.


We're innocent victims (;-)) and need to decide if we're supporting the 
spec or the customers.  Right now we're supporting the spec.


--dave

On 09/05/18 10:17 AM, jwint...@pivotal.io wrote:
Is there an expectation that all of these providers would/should 
change their implementation? It seems like there are enough reputable 
implementations that maybe the "broken" case should be better 
supported, even if the spec discourages it.


I known there's been a long discussion about this already 
<https://code.google.com/archive/p/goauth2/issues/31>. But it seems 
like that was all decided a while ago and wondering if things have 
changed given how long that list of busted auth providers is getting.



On Wednesday, May 9, 2018 at 8:43:56 AM UTC-4, David Collier-Brown wrote:



On Tuesday, May 8, 2018 at 12:22:39 PM UTC-4, Joshua Winters wrote:

It seems like `https://www.gitlab.com` needs to be added to
the list of busted auth providers in golang/oauth2.

Instead of maintaining a list of these providers, can we just
send the `client_id` and `client_secret` in both the auth
header and the body with every request?


That does encourage them to leave it broken...
Can we perhaps detect the problem and refer the developer to

  * the public list of bad actors
  * the workaround

--
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/iYrYz8YZuPM/unsubscribe.
To unsubscribe from this group and all its topics, 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.



--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Busted auth providers

[David Collier-Brown]

On Tuesday, May 8, 2018 at 12:22:39 PM UTC-4, Joshua Winters wrote:
>
> It seems like `https://www.gitlab.com` needs to be added to the list of 
> busted auth providers in golang/oauth2.
>
> Instead of maintaining a list of these providers, can we just send the 
> `client_id` and `client_secret` in both the auth header and the body with 
> every request?
>

That does encourage them to leave it broken...
Can we perhaps detect the problem and refer the developer to

   - the public list of bad actors
   - the workaround 
   

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[David Collier-Brown]

I also ran into a race diagnostic  when I did an "Add" after my main 
programs started "Wait"ing: I moved the add to the main program and cured 
it.

I read this as the WaitGroup being careful and efficient about use of 
locking primitives, and not liking the expensive operation of incrementing 
a semaphore-like construct while someone is waiting for it to change 
towards zero. 

Logically, it's easy to prove correctness of a counter that increments to a 
value and then decrements to zero, and less easy to deal with one that 
jumps up and down (and maybe waves its arms in time with the music (;-))

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Calling sync.WaitGroup.Add() while a sync.WaitGroup.Wait() is waiting

[David Collier-Brown]

I also ran into a race diagnostic  when I did and Add after my main 
programs started Waiting: I move the add to the main program and cured it.

I read this as the WaitGroup being careful and efficient about use of 
locking primitives, and not liking the expensive operation of incrementing 
a semaphore-like construct while someone is waiting for it to change 
towards zero. 

Logically, it's easy to prove correctness of a counter that increments to a 
value and then decrements to zero, and less easy to deal with one that 
jumps up and down (and maybe waves its arms in time with the music (;-))


>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: How to reuse go fix tool code

[David Collier-Brown]

A minor side comment: 

On Sunday, March 18, 2018 at 12:47:11 PM UTC-4, thepud...@gmail.com wrote:
>
>
> from golang/tools eg help via 
> https://github.com/golang/tools/blob/release-branch.go1.10/refactor/eg/eg.go#L20
>
> Only refactorings that replace one expression with another, regardless
> of the expression's context, may be expressed.  Refactoring arbitrary
> statements (or sequences of statements) is a less well-defined problem
> and is less amenable to this approach.
>

The latter used to be my life, and we adressed it with tools to make 
applying human judgement easy. Eg,  "port -- a program to strength-reduce 
the task of porting from *defusing live bombs* to something much more like 
*fixing 
compilation errors*", at https://github.com/davecb/port

The same can be applied to Go, as you'd guess, but is a much different 
problem than we have here.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 the reflect docs explain what do the Data fields mean in SliceHeader and StringHeader?

[David Collier-Brown]

In the Multics tradition, I think you should say "Hic erit dracones" ("here 
there be dragons", in Latin (;-))

--dave

On Thursday, March 1, 2018 at 1:19:03 PM UTC-5, Ian Lance Taylor wrote:
>
> The docs already say that the each type "cannot be used safely or 
> portably and its representation may change in a later release."  I 
> don't think we need to say anything else. 
>
> Ian 
>

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

[go-nuts] Re: Go += Package Versioning

[David Collier-Brown]

And I later found https://godoc.org/golang.org/x/vgo/vendor/cmd/go, which 
looks like where you'll be developing
new material from the old docs.

--dave

On Sunday, February 25, 2018 at 11:00:54 AM UTC-5, David Collier-Brown 
wrote:
>
> I'm following the discussion and using the blog descriptions, but where 
> are the "man pages"?
> A search at golang.org for vgo only points me to 
> /src/crypto/x509/root_darwin_armx.go (:-))
>
> Seriously, though, I'll happily help develop and/or edit reference 
> material: I was an O'Reilly author in a previous life.
>
> --dave
>

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

[go-nuts] Re: Go += Package Versioning

[David Collier-Brown]

I'm following the discussion and using the blog descriptions, but where are 
the "man pages"?
A search at golang.org for vgo only points me to 
/src/crypto/x509/root_darwin_armx.go (:-))

Seriously, though, I'll happily help develop and/or edit reference 
material: I was an O'Reilly author in a previous life.

--dave

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

Re: [go-nuts] Re: Go += Package Versioning

[David Collier-Brown]

On 24/02/18 04:05 PM, Maxim Ivanov wrote:

I am replying mostly to https://resea rch.swtch.com/vgo-import article.
...
IMHO right solution vgo should promote is to apply semver trick 
described here: 
https://github.com/dtolnay/semver-trick/blob/master/README.md . In a 
nutshell it suggests that "oauth/v1" imports "oauth/v2" and type 
aliases all common types visible in API. Then "moauth" doesn't need a 
new semver release at all, it stops being viral and whole dependency 
chain becomes much much simpler.
This is one of the two approaches that the Multics folks used when they 
ran into the version-skew problem in a heavily versioned collection of 
shared libraries.


They wrote "updaters" and "downdaters", that respectively took an old 
call and called the new code, or took a new call and mapped it into old 
code.


Also used in Solaris and inside Linux glibc, so we've independently 
re-invented it at least four times (;-))


Go community is going to to do pretty much whatever Russ tells them 
with imminent vgo release, if smever trick indeed solves this viral 
problem, it should be encouraged from day 0.


I think the mechanics of doing multiple versions deserves a blog 
article, as it's been touched on in the group a couple of times.


--dave
[I also think Russ was just using Mo writing extra libraries as an 
illustration]
[see also "Dependency hell is NP-complete" at 
https://research.swtch.com/version-sat and
“DLL Hell”, and avoiding an NP-complete problem, at 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/ 
]


--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

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

[go-nuts] Re: Go += Package Versioning

[David Collier-Brown]

>
> Some forms of attempted versioning don't do well with vgo (:-))
>

I tried a main named "consumer" that imported "gopkg.in/Shopify/sarama.v1", 
> and got
>
``` 

> [davecb@miles consumer]$ vgo build
> can't load package: import cycle not allowed
> package gopkg.in/Shopify/sarama.v1
> imports gopkg.in/Shopify/sarama.v1
> import cycle not allowed
> package gopkg.in/Shopify/sarama.v1
> imports gopkg.in/Shopify/sarama.v1
>
 

> [davecb@miles consumer]$ cat go.mod 
> module "gopkg.in/Shopify/sarama.v1"
>
```

The main.go started with 
```
package main 

import (
samara "gopkg.in/Shopify/sarama.v1"
"os"
"log"
"os/signal"
)

func main() {
consumer, err := samara.NewConsumer([]string{"10.5.70.111:9092"}, nil)
if err != nil {
panic(err)
}
```

I didn't expect it to work, but the nature of the error might be 
interesting 

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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's the best way to maintain a package repository that have the major version in the import path?

[David Collier-Brown]

On Thursday, February 22, 2018 at 6:43:07 AM UTC-5, alex@gmail.com 
wrote:
>
> Yup, the package I'm working on really cannot have 2 instances even in 
> different import paths as it deals with a shared resource and code that 
> must be run on the main thread.
> So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a 
> central v0 where all the v1, v2, etc.. packages import.
>
> Daisy chaining would mean I would only have to code API translations for 
> the latest API but then it's debug hell and if one version in the chain 
> breaks, 
> it means fixing all the newer versions. Also there's a performance hit 
> going through many translations.
>

If I understand you correctly, v2's foo() has to call v1's foo() in the 
daisy-chain case.   This was one of the two common cases in Multics (and 
Solaris, and Linux glibc).  The other case was v1's foo() calling a wrapper 
around v2's foo().

We called these "updaters" and "downdaters", and implemented them in the 
same library, under the covers.

Feel free to drop me a line if you are interested, and see 
also 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/
 
fore some of the background.

--dave
dav...@spamcop.net

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 know if interface{} data is nil w/o reflecting?

[David Collier-Brown]

I was responding to the case where one is passed an interface, expects 
it to contain a typed value, and

it does not.

--dave

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 know if interface{} data is nil w/o reflecting?

[David Collier-Brown]

Drifting back toward the original subject, I'm reminded of the non-bsd-c 
idiom of

char *foo(char *p) {
if (p != NULL && *p != NULL) {
return some string operation...
}
...

It seems logical to check the type of the contents of an interface
type, and its presence in a function that can take nil types and
nil contents, much as in the C idiom. 

Mind you, I do find type assertions a bit clunky. 

--dave

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

Re: [go-nuts] Re: dep and versioning : how are conflicts dealt with ?

[David Collier-Brown]

I'd try to do the same thing, just at the interface level, like the 
kernel does. Eg, preadv2 as  described at https://lwn.net/Articles/670231/


--dave


On 26/12/17 11:42 AM, Fabien wrote:
Thank you, lots of food for thought. For the go package-writer, now, I 
guess the best practice so as not to be part of the problem is to


1- in minor revisions, of course, keep backward-compatibility.
2- in major revisions, either:
    - make a new project, for instance, if my first project was 
github.com/foo/bar, make a new one called github.com/foo/bar2 for 
version 2,
    - if applicable, keep the old directory structure as is for 
backward compatibility, and make a new one for the new version, for 
instance, if in github.com/foo/bar I used to define the packages 
github.com/foo/bar/baz and github.com/foo/bar/foobar, keep them but 
now recommend the use of packages github.com/foo/bar/version2/baz and 
github.com/foo/bar/version2/foobar,




--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

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

Re: [go-nuts] Re: dep and versioning : how are conflicts dealt with ?

[David Collier-Brown]

I'd try to do the same thing, just at the interface level, like the 
kernel does. Eg, preadv2 as  described at https://lwn.net/Articles/670231/


--dave

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: dep and versioning : how are conflicts dealt with ?

[David Collier-Brown]

Lots of in-line reply-bits (;-))

On Tuesday, December 26, 2017 at 8:58:47 AM UTC-5, Fabien wrote:
>
> Thank you, that's a very interesting read.
>
> TLDR: If I understood everything, NP-complete != DLL hell, but anyway, go 
> is vulnerable to DLL hell, so we're screwed.
>
> I'm not sure I understand everything, though. Both your article and Russ 
> Cox' you mention seem to confuse NP-completeness and the concept of DLL 
> hell. I thought DLL hell was the inability, plain and simple, to install 
> two versions of the same DLL (and, AFAIK, two different versions of a go 
> package). The problem of whether you need two incompatible versions or not 
> happens to be NP-complete, but that's not the problem per se, is it ?
>

I view the inability to have two versions of the same thing as the cause, 
and DLL hell the effect, with finding a solution to DLL Hell NP-hard. 

There is a weaker sense of DLL hell too, that of having to find all the 
different dependancies. We started out with things like "rpm search", but 
folks quickly automated. I stil lremember trying to find all the 
dependancies for a copy of  MythTV. Erk! You also see people adressing that 
weaker case via flatpacks, docker images and the like, and it somewhat 
mitigates the harder case.


> If I understood correctly your article and Russ Cox', the proposed 
> solution is either to offer, in each subsequent version of a package / 
> shared library / DLL, both the old and the new API, or to allow the 
> installation of several packages. However this leads to problems, as you 
> now tend to have bloated binaries that contain old compatibility code you 
> don't necessarily need. If version 1 and 2 of package C are incompatible, 
> I'm expecting the latest binary version of package C to contain both 
> version 1 and version 2.
>

Yes: we're trading space for time. In Multics there were a number of things 
you could do with the binder to keep the RSS small, at the cost of a larger 
on-dicklibrary image.
 

>
> However that's good for DLLs and other shared objects, but that seems 
> overkill in the case of go, since each executable includes all the library 
> code it uses. 
>

In a static-linking environment like Go or Linux, you can drop all the dead 
code when you create the final executable. There is a recent article at LWN 
about doing so for Linux at  
https://lwn.net/SubscriberLink/741494/2efc53db170f03c5/

 

> If I need package A and package B, and both those packages only use the 
> version 2 of C, I don't wan't to include the version 1 of C, too, in my 
> executable: it is already big enough. If you want to avoid it, you need to 
> be able to specify specific versions of packages, and you're almost back to 
> square one, with an NP-hard problem. 
> But this is not DLL hell anymore: first, you know your program can be 
> installed, not matter what. You might need to duplicate lots of code, have 
> several different versions of your packages, but at least there's a 
> possible solution. Secondly, this is no more a decision problem (is there a 
> solution at all), but an optimization problem (what is the best possible 
> solution): the initial, suboptimal solution (just install the last version 
> of each package, recursively) is found in linear time and the optimization 
> process can be interrupted at any moment if it takes too long, leaving you 
> with a suboptimal but workable solution.
>
> So, for instance :
>
> let's say I want to install package p, that requires both packages a and b.
>
> Here are package a's versions, and their dependencies :
>
> a:
> v1: c >=1
> v2: c = 2
>
> And package b:
>
> b:
>v1: c >= 2, d >= 1
>v2: c >= 3, d >= 1
>
> There are two more dependencies, c and d, here are their own versions and 
> dependencies:
>
> c:
> v1: nothing
> v2: nothing
> v3: nothing
>
> d:
> v1: c = 1
>
> If I can't have two versions of the same package installed, I have to go 
> through a NP-complete problem (and use a SAT solver or equivalent) to find 
> I'm actually out of luck: there is now way to install p while having at 
> most one version of each package. That is DLL hell.
>
> But if I can have several versions installed, a first reasonable option is 
> to propose to install the latest version of a and b, and then the latest 
> versions of each of their dependencies, recursively. If incompatible 
> versions are needed, duplicate them. So, here, that initial solution would 
> be a2, b2, c1, c2, c3, d1. Good, and found in linear time, but not perfect, 
> since there are duplicate packages. I can now try to find an optimal 
> solution, optimal being defined as "the newer versions the better, the 
> least installed packages the better". Here, the optimal solution is a1, b2, 
> c1, c3, d1 which is only 4 packages, the trick being to downgrade to 
> version 1 of package a. Still NP-complete (NP hard, actually), but no DLL 
> hell, and I already had a workable solution in linear time.
>

There is a longish 

[go-nuts] Re: dep and versioning : how are conflicts dealt with ?

[David Collier-Brown]

>
>
> A bit of an unresolved problem in several universes, one of which contains 
Go (;-)) 

I have some definite opinions: I grew up in a universe where it was 
resoilved in Multics, rediscoverd in Solaris and independantly rediscovered 
in Linux glibc. Way more information that you want in 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/

The best advice I can give in the current context is to chose an A-B pair 
with a common C, even if it causes you to go back to an undesirably early 
release of either A or B. 

It is, after all, an NP-complete problem: there is no guarantee that there 
is a good answer, save to *not have* the problem, as the Multicians found.

--dave

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

Re: [go-nuts] Re: select multiple expressions per case

[David Collier-Brown]

Oh foo, if we only need a common behavior, we can call a function instead 
of inlined code.  


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: f*ck you, golang

[David Collier-Brown]

The PHBs always want FORTRAN IV programmers, in any language. Just lie and 
say Go was written by FORTRAN experts. Lik Kernighan and Pike, for example.

--dave
 

> On Friday, July 24, 2015 at 12:19:29 AM UTC+2, Roberto Zanotto wrote:
>>
>> I have to work on a project for an university exam and the professor 
>> highly recommends doing it in C++ with (his) FastFlow library. Now, because 
>> of Go, I can't stand looking at object oriented code anymore. The way the 
>> code is structured... class hierarchies... you can't even tell what the 
>> program _does_. My eyes cross and I feel like crying.
>>
>> I was meant to be a successful C++/Java programmer, now that is ruined 
>> forever. And nobody listens to me! A friend of mine recently graduated, we 
>> bought him "*Design Patterns: Elements of Reusable Object-Oriented 
>> Software"* and "*Effective Modern C++: 42 Specific Ways to Improve Your 
>> Use of C++11 and C++14".* He wanted those books and said that they are 
>> what he needs to learn for job interviews. And everybody agreed.
>>
>> My life is ruined and it's on you.
>>
>

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

[go-nuts] Re: Handling dynamic and unknown number of wait groups?

[David Collier-Brown]

You don't even need to do waitgroups if the main() function is the one that 
is last in the pipeline: cf 
https://leaflessca.wordpress.com/2017/01/04/forwards-and-backwords-pipes-in-go/

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

[go-nuts] Re: Handling dynamic and unknown number of wait groups?

[David Collier-Brown]

You don't even mneed to do weaitgroups if the main() function is the one 
that is last in the pipeline : 
cf 
https://leaflessca.wordpress.com/2017/01/04/forwards-and-backwords-pipes-in-go/

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

[go-nuts] Re: concurrent write-only to map ok?

[David Collier-Brown]

Like Mr Pryczek, I'd be concerned that
- the performance will be pessimized for this case, and
- the approach is un-go-ish.

Share memory by communicating is a Go idiom: send updates to a goroutine 
via a pipe, and by construction let the map never be written by others. 

It's more work to think about, but less to actually do (:-)) and a good 
introduction to the class of gopherish approaches.

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Are all running goroutines killed when main ends?

[David Collier-Brown]

On Friday, October 6, 2017 at 9:49:18 AM UTC-4, Michael Jones wrote:
>
> Imagine the slightly stronger notion of a "will" as in a person's last 
> will and testament. Actions in your will are steps to be carried out in the 
> event of your death. Presumably if an action has already been done during 
> your lifetime, then that part of the will is mooted.
> 
>

Hmmn: a "will" library might create a list of steps to be done by a call to 
defer 
will.executor() in main().
I'd be interested in how many variables have to moved to the heap from the 
stack in such cases.

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[David Collier-Brown]

Indeed: a monotonic increasing number is a good thing, but I wouldn't try 
to make it an actual time, just a relative time-like-thingie  that _you_ 
define with the properties you need and that you can implement.

--dave

On Wednesday, September 27, 2017 at 6:55:37 AM UTC-4, Dave Cheney wrote:
>
> Using monotonic time for implementing a distributed locking system 
> seems fraught with difficulties. 
>  supported kernels. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: `ltrace` yields "Couldn't find .dynsym or .dynstr in "/proc/*/exe" with binaries generated by "go build *.go"

[David Collier-Brown]

You may need to look and see what __vdso_clock_gettime_sym calls at the 
system-call level, and compare that with the system calls reported by 
strace from your executable. 

I assume you want some particular thing that __vdso_clock_gettime_sym does: 
try asking the folks about *that*, as they may already know.

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

Re: [go-nuts] Re: Generics and readability

[David Collier-Brown]

Someone who can summarize the lisp experience woud be usefull here: 
generate-and-execute is that language's equivalent of preprocessors and 
code generators, and has been around the beginning of the language.

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

Re: [go-nuts] Re: Generics are overrated.

[David Collier-Brown]

On 10/08/17 09:09 AM, roger peppe wrote:

On 10 August 2017 at 13:39, David Collier-Brown <davecb...@gmail.com> wrote:

On 10/08/17 02:47 AM, Henrik Johansson wrote:

I beg to differ. Most Java apps I have seen over many years almost
unanimously suffer from over-modeling.


A former customer did a deep, thoughtful, *thorough* model of bracket
tournaments, without any attempt to abstract the salient features. Java
represented it beautifully, in complete detail...

So it's now impossible for a single person to keep it in their brain, and
every attempt to change it introduces new, surprising "features".

In effect, the ability to represent anything easily led to our error: we
represented _everything_.

I remember something similar happening with some Haskell I wrote.
Because the type system was so powerful, it felt wrong not use it to
represent everything, which ended up problematic. Frivolous thought:
I wonder if there's an (far-fetched) analogy to be made between this
and dropout techniques in neural networks - if our type system is really
powerful, it's easy for our type structures to "overfit" to the current
problem being solved, making it less adaptable and maintainable when
the problem changes.

I quite agree: I suspect it a tradeoff, in which the more you can easily 
represent, the more you need to carefully architect exactly *what* you 
represent.


--dave

--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

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

Re: [go-nuts] Re: Generics are overrated.

[David Collier-Brown]

On 10/08/17 02:47 AM, Henrik Johansson wrote:
I beg to differ. Most Java apps I have seen over many years almost 
unanimously suffer from over-modeling. 


A former customer did a deep, thoughtful, *thorough* model of bracket 
tournaments, without any attempt to abstract the salient features. Java 
represented it beautifully, in complete detail...


So it's now impossible for a single person to keep it in their brain, 
and every attempt to change it introduces new, surprising "features".


In effect, the ability to represent anything easily led to our error: we 
represented _everything_.


Go (or C) doesn't actually address over-modeling: it's merely harder to 
do, and we're less likely to make that error, just as a side-effect (;-))


--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net   |  -- Mark Twain

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Generics are overrated.

[David Collier-Brown]

Ah well, one can always go back to

COPY PAYLIB REPLACING A BY PAYROLL
  B BY PAY-CODE
  C BY GROSS-PAY
  D BY HOURS.


(Courtesy of 
https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_9.1.1/com.ibm.etools.cbl.win.doc/topics/rlcdscop.htm)

--dave (:-)) c-b

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Language muration (was: No Allman-Style, No go)

[David Collier-Brown]

On Tuesday, August 1, 2017 at 10:18:21 AM UTC+1, Russel Winder wrote

Once a programming language goes into production and invokes "backward
compatibility" it rarely improves by evolution. cf. Fortran, Java.


In principle, a language can improve, if the replacement is
- distinguishable from it's predecessor, and
- there is a correctness-preserving transform.

When I was doing porting ("competitive migration"),
- we didn't have  sets of refactorings, which are defined as 
correctness-preserving, and
- we had a bit of a kludge for distinguishing dialects. The latter was 
"came from AIX 0.9, going to SunOS 5.2"


Now we have versioned dialects, and a class of useful refactorings, so 
some changes are possible.


Not trivial, but if they're mechanizable, hardness doesn't matter.

--dave

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Generics are overrated.

[David Collier-Brown]

I came to Go from languages that had generics, but in practice I find that 
I predominantly used list-of and  set-of.  And I spent a dispropriate 
amount of time with valgrind making sure my C++ list didn't have leaks (:-()

A question to people who use Java/C++ and friends: what generics do you 
find you use in *production* programs?

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 the default format for nil slice and map is not nil?

[David Collier-Brown]

Hmmn: David J. Brown (my evil twin) was exceedingly good at unpainting 
himself from corners, did you know him? He as a Sun and SGI guy...
Methinks merging two formats into (one better) one were amoung the things 
we did...

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] time/format: how to add custom formats (24-hour without 0 padding)

[David Collier-Brown]

This looks good:  if there is a mechanism to align times with language, it 
should be the implementation of Canadian French (along with things like 
circiumflex-E)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Set LD_LIBRARY_PATH while executing go test

[David Collier-Brown]

I used to write tons of interposers, what is it you are trying to do in Go?

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

[go-nuts] Re: Runtime code generation?

[David Collier-Brown]

I've doen generate-and-execute in C that way, at the cost of using 
LD_PRELOAD and having to restart the program.  Go plugins should be better, 
as long as you don't have to drop one. Can you supercede one? It sort of 
looks like you could...  If so, Go could do theequivalent of unload.

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 sort.IsSorted implemented with decrement?

[David Collier-Brown]

Some compilers know that and create a hidden variable (B and C on GCOS, if 
memory serves)

On Thursday, April 20, 2017 at 11:50:39 PM UTC-4, andrey mirtchovski wrote:
>
> >  297 for i := n - 1; i > 0; i-- { 
>
> "i > 0" is cheaper than "i < n" on some processors :) 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Vendoring nested dependencies

[David Collier-Brown]

As Russ Cox, a somewhat famous Gopher, noted, that's an NP-complete 
problem.  You can pay in effort (several different interpretations of 
"flattening"), in compile speed(running a SAT solver) or you can fail (;-))

This won't help you, but the last three times we ran into this, we changed 
the problem definition so we could achieve it. See “DLL Hell”, and avoiding 
an NP-complete problem 

 and 
especially David J Brown's paper, referred to there.

--dave
[I used to work for David J, my "evil twin".  My notably smarter twin, too]

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 harmful to always return invalid values on a non-nil-error?

[David Collier-Brown]

A former customer made it a practice to always return properly initialized 
objects where others would return nul/null.  Instead of exploding in dev, 
the programs merely behaved mysteriously at run-time.  In a libray which 
called it, had to check everything I was passed for *meaningfullness*, 
which is wildly harder than nullness.

I regard it as a failed experiment.

--dave

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 harmful to always return invalid values on a non-nil-error?

[David Collier-Brown]

A former customer made it a practice to always return properly initialized 
objects where others would return nul/null.  Instead of exploding in dev, 
the programs merely behaved mysteriously at run-time.  In a libray which 
called it, had to check everything I was passed for *meaningfullness*, 
which is wildly harder than nullness.

I regard it as a failed experiment.

--dave




On Monday, April 3, 2017 at 1:02:24 PM UTC-4, Eric Johnson wrote:
>
> My 2 cents:
>
> On Saturday, April 1, 2017 at 4:26:20 AM UTC-7, Axel Wagner wrote:
>>
>> Ian:
>> Re your question: See my example given above (or the one below, which is 
>> probably more authentic). For example, you might be allocating the returned 
>> struct, and piece by piece filling in the fields. If there can be errors, 
>> the natural expression might be, to just return the allocated struct, 
>> whereas to then return nil, you need to explicitly branch. For example, say 
>> I'd want to have a type which operates on some file:
>>
>> type Foo struct {
>> file *os.File
>> }
>>
>> func NewFoo(fname string) (*Foo, error) {
>> f, err := os.Open(fname)
>> return {
>> file: f,
>> }, err
>> }
>>
>> vs.
>>
>> func NewFoo(fname string) (*Foo, error) {
>> f, err := os.Open(fname)
>> if err != nil {
>> return nil, err
>> }
>> return {
>> file: f,
>> }, nil
>> }
>>
>> I would usually write the latter version, even if the former is shorter 
>> and the extra branch isn't necessary, because people shouldn't rely on the 
>> first return if there's an error anyway.
>> Because I do feel like people might not be so careful and then 
>> dereferencing a nil *Foo will be a clearer symptom to debug, than debugging 
>> whatever weird value Open might theoretically return being used 
>> accidentally.
>>
>
> I have chased enough evil uninitialized variable bugs in my time to come 
> down strongly on the side of, when there's an error, return unusable data. 
> It need not be nil, but it needs to fail immediately upon use. In the file 
> case above, the "file" member may be unusable, but the instance of the Foo 
> object may work just fine for some number of methods.Without seeing your 
> whole implementation of "Foo", it is impossible to tell whether returning 
> non-nil value here is a problem. If there are a bunch of methods that can 
> work if the "file" member is broken, then returning "nil" is a courtesy to 
> future users of your API. However, you can start painting yourself into a 
> corner quickly. You don't have a guarantee that Open will return "nil" in 
> case of error, so how can the other methods of your structure tell whether 
> the object is improperly initialized? The only way you get there is by 
> having a specific "if" statement that checks the error, and sets the "file" 
> member to an explicit value. Or you could just return "nil" for *Foo.
>
> It is worth keeping in mind that:
>
> func (f *Foo) doSomething() {
>// ...
> }
>
> ... it is perfectly valid for "f" to be nil. So be careful out there.
>
> Others have also noted partial read scenarios, where returning some data 
> makes sense. Those should be commented specifically. In other cases, 
> though, your documentation could at most state the return an unusable value 
> in cases of error, without specifying whether it is nil or not.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Algorithm Club

[David Collier-Brown]

That's an interesting thought: one can generate a generic from a type 
which has an ordering, and identity and perhaps a few other functions as 
its interface.


That eliminates the "grad student slave writing tests" from the 
algorithm (;-)) and makes it, in principle, computable in a Go kind of way.


--dave



On 31/03/17 04:55 PM, Bakul Shah wrote:

IMHO sort() is best thought of as a higher order function (one taking a
functional argument, the comparison function). It would be perfectly
fine to use a > b  as this comparison function or a < b or any other
compare function a given type (e.g. case ignoring compare function on
strings).  Some confusion may be due to the way Go sort package
shoehorns a generic function into Go's existing machinery. Ideally I’d
want something like

func sort(vector []T, func compare(a, b T)bool)

with T to be specified at the call site.

You can achieve this with a parametric package extension (the only new
syntax is in package header and package import. So it is limited but
simple to understand).

What you are asking for (flagging a “semantic fail” at compile time) is
perhaps way beyond what a generics package in a language like Go can do.


On Mar 31, 2017, at 9:19 AM, Michael Jones > wrote:

There is part of the topic that has always been slightly beyond my
grasp. (Maybe I do understand...but just lack absolute certainty.)
Maybe others know the answer...

In a template system (which is what I prefer but that's not the point
of this email) we have the notion of the TYPE(s) being a formal
argument. We presume that the code will compile or fail based on the
suitability of the instantiated type. That is, a templated Min would
fail on the comparison "<" if the TYPE was "Map[something]something."
Call that a lexical fail.

My question is, what about a semantic fail. Say, "<" for floating
point. In the sort package the Less function does
!Less(a,b)&&!Less(b,a) to figure out Equal(a,b). That works for ints
and strings, but when I templated sort I found that it failed in tests
with float32 and float64 because of NaN values, which are
!Less(a,b)&&!Less(b,a) yet !Equal(a,b). I had to make two templates,
one for floating point values and one for integral/string values.

My uncertainty is in the fact that I only discovered the problem
through testing--i had failed to anticipate it. It was easy to fix,
but only after the fact. That makes me wonder about the truly perfect
generality of templated reusable software, which would be most perfect
if it failed to compile rather than fail in some rare edge condition
under use or testing.

The closest solution I have known about this was IBM Research's AXIOM
symbolic mathematical system, which had a robust and mathematically
pure concept of types and operators and commutativity and inverses and
the like. It was possible to make a function for "two arguments that
were elements of a ring with property A and B." That made sense to me,
but was off-putting to some users.

I recalled it i the sort case because I wanted to kinds of typed
clients for "<", the kind where !Less(a,b)&&!Less(b,a) === Equal(a,b),
and the kind where that is not the case--and ideally--a way to have
instantiation for the first kind use path A and the second kind use
path B. That would have made the code truly general.

I fear this pedantry will make Russ suspicious of slowing compilation
AND programmers. :-)

Michael

On Fri, Mar 31, 2017 at 2:46 AM, Egon > wrote:

On Friday, 31 March 2017 09:02:09 UTC+3, Will Faught wrote:

>Because it can also be implemented in other ways.

Do you mean interface{} can be implemented in other ways? I
couldn't make out your meaning.


There are multiple ways of implementing "boxing generics" and
"interface{}". Implying it has same perf. characteristics as
interface{}, implies the same implementation as interface{}.



>As said... there is a performance upside for some other approaches.

The other approaches have downsides, or at least generation
does. Compared to using interface{} as is done now, boxing
generics improves type safety and expressiveness and has no
performance regression. That's a clear net win.


I meant other generics approaches (not alternatives).

Boxing generics adds complexity to the compiler, without solving
some of the problems that generics intends to solve.
Mainly, implementing highly performant data-structures would still
require code-generation/copy-paste.
And that is a pretty big downside.



On Wednesday, March 29, 2017 at 9:18:01 PM UTC-7, Egon wrote:

On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote:

Egon:

>See 
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9

Re: [go-nuts] Re: Algorithm Club

[David Collier-Brown]

In a previous life, this was one of the problems we had with 
generate-and-execute. 

In lisp, you could almost always create correct code and run it.  With C, I 
could generate library interposers by the ton, but they only *usually* 
worked, so I had to generate unit tests, too. Fortunately I had a mad 
colleague who loved generating tests (;-))

I wonder how many corner cases there are in C++/Java/Rust/whatever generics 
of exactly this sort?

--dave

On Friday, March 31, 2017 at 1:21:02 PM UTC-4, Michael Jones wrote:
>
> yes
>
> On Fri, Mar 31, 2017 at 12:30 PM, Ian Davis  > wrote:
>
>> On Fri, 31 Mar 2017, at 05:19 PM, Michael Jones wrote:
>>
>> There is part of the topic that has always been slightly beyond my grasp. 
>> (Maybe I do understand...but just lack absolute certainty.) Maybe others 
>> know the answer...
>>
>> In a template system (which is what I prefer but that's not the point of 
>> this email) we have the notion of the TYPE(s) being a formal argument. We 
>> presume that the code will compile or fail based on the suitability of the 
>> instantiated type. That is, a templated Min would fail on the comparison 
>> "<" if the TYPE was "Map[something]something." Call that a lexical fail. 
>>
>> My question is, what about a semantic fail. Say, "<" for floating point. 
>> In the sort package the Less function does !Less(a,b)&&!Less(b,a) to figure 
>> out Equal(a,b). That works for ints and strings, but when I templated sort 
>> I found that it failed in tests with float32 and float64 because of NaN 
>> values, which are !Less(a,b)&&!Less(b,a) yet !Equal(a,b). I had to make two 
>> templates, one for floating point values and one for integral/string values.
>>
>>
>> Is this because sort.Less requires total ordering and, because of NaN, < 
>> for floats only offers partial ordering?
>>
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Michael T. Jones
> michae...@gmail.com 
>

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

Re: [go-nuts] time: error prone implementation of Time.Format

[David Collier-Brown]

I think he said "02/02/2006", and got two day-numbers instead of a day and 
a month.

--dave

On Thursday, March 30, 2017 at 10:49:29 AM UTC-4, Manlio Perillo wrote:
>
> Il giorno giovedì 30 marzo 2017 01:21:14 UTC+2, Ian Lance Taylor ha 
> scritto:
>>
>> On Wed, Mar 29, 2017 at 2:29 PM, Manlio Perillo 
>>  wrote: 
>> > Il giorno mercoledì 29 marzo 2017 23:18:09 UTC+2, Ian Lance Taylor ha 
>> > scritto: 
>> >> 
>> >> On Wed, Mar 29, 2017 at 2:03 PM, Manlio Perillo 
>> >>  wrote: 
>> >> > In a program I have a function that formats the time in Italian date 
>> >> > format: 
>> >> > dd/mm/, but, due to an oversight, I wrote the layout string as 
>> >> > "02/02/2006", instead of "02/01/2006". 
>> >> > This caused all the dates to be incorrectly formatted. 
>> >> > 
>> >> > IMHO, this is a nasty behavior.  The layout is clearly incorrect and 
>> the 
>> >> > implementation should report an error, instead of returning an 
>> >> > incorrectly 
>> >> > formatted time. 
>> >> 
>> >> I think it would be difficult to define "clearly incorrect" in a way 
>> >> that does not introduce any false negatives while remaining useful. 
>> > 
>> > 
>> > In my case I specified stdZeroDay twice. 
>> > 
>> > The AppendFormat function can define some additional boolean variables: 
>> > hasYear, hasMonth, hasDay, ... 
>> > and return an error if a variable is set to true more than one time. 
>>
>> But it's not clearly incorrect to write 
>>
>> "2006-01-02 or Jan 02, 2006" 
>>
>>
> I'm probably missing something, but "2006-01-02" is a valid time layout 
> string.
>
> 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.

Re: [go-nuts] time: error prone implementation of Time.Format

[David Collier-Brown]

>From your described implementation, I assume you're asking for something 
like

As a programmer, if I ask for a date with month twice, I wish to 
revieve a warning"

If so, it would complain if I asked to print something like "01/01/2017 (1 
Jan 2017)"

--dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] time: error prone implementation of Time.Format

[David Collier-Brown]

>From your described implementation, I assume youre asking for



On Wednesday, March 29, 2017 at 5:29:19 PM UTC-4, Manlio Perillo wrote:
>
> Il giorno mercoledì 29 marzo 2017 23:18:09 UTC+2, Ian Lance Taylor ha 
> scritto:
>>
>> On Wed, Mar 29, 2017 at 2:03 PM, Manlio Perillo 
>>  wrote: 
>> > In a program I have a function that formats the time in Italian date 
>> format: 
>> > dd/mm/, but, due to an oversight, I wrote the layout string as 
>> > "02/02/2006", instead of "02/01/2006". 
>> > This caused all the dates to be incorrectly formatted. 
>> > 
>> > IMHO, this is a nasty behavior.  The layout is clearly incorrect and 
>> the 
>> > implementation should report an error, instead of returning an 
>> incorrectly 
>> > formatted time. 
>>
>> I think it would be difficult to define "clearly incorrect" in a way 
>> that does not introduce any false negatives while remaining useful. 
>>
>
> In my case I specified stdZeroDay twice.
>
> The AppendFormat function can define some additional boolean variables:
> hasYear, hasMonth, hasDay, ...
> and return an error if a variable is set to true more than one time.
>
>
> 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.

Re: [go-nuts] Re: Algorithm Club

[David Collier-Brown]

Folks, is this something that we should do with a template processor?
More topically, is this a set of somethings that we should prototype each 
of, using templates?

I'd love to see actual experiments in computer "science" (;-)) and a debate 
about the tradeoffs based on code.

--dave 



On Monday, March 27, 2017 at 2:40:12 AM UTC-4, Egon wrote:
>
> On Monday, 27 March 2017 04:06:17 UTC+3, Mandolyte wrote:
>>
>> I agree that it makes the suitable trade-offs. And Linq is doing pretty 
>> well without generics (https://github.com/ahmetb/go-linq); not familiar 
>> with Rx.
>>
>> When I consider the dilemma, the two things I don't want are slow 
>> programmers and slow execution, leaving "slow compilers and bloated 
>> binaries". But here is how I think about this option:
>> - There are alternatives that only impact compiler speed if they are 
>> actually used. I think that's fair.
>>
>
> The unfortunate reality is that when you add generics to a language it 
> will be almost impossible to avoid it.
>
> And the dilemma is not a binary-yes-no... e.g. would you give 100x 
> performance to have fast programmers, fast execution and no code-bloat... 
> or would you give 10% performance for medium speed programmers, fast 
> execution and some code-bloat?
>
> It's better to view the dilemma as a rating system. As a facilitated 
> example:
>
> *copy-paste:*
> 1. convenience: 0/10
> 2. code size: 10/10
> 3. performance: 10/10
> 4. flexibility: 10/10
> 5. readability: 5/10
>
> *interfaces:*
> 1. convenience: 4/10
> 2. code size: 0/10
> 3. performance: 2/10
> 4. flexibility: 6/10
> 5. readability: 8/10
>
> *type-level generics with boxing:*
> 1. convenience: 7/10
> 2. code size: 0/10
> 3. performance: 5/10
> 4. flexibility: 8/10
> 5. readability: 1/10
>
> *package-level generics with out-of-bounds boxing:*
> 1. convenience: 6/10
> 2. code size: 3/10
> 3. performance: 8/10
> 4. flexibility: 5/10
> 5. readability: 7/10
>
> *Obviously, do not take these numbers seriously.*
>
> - There are alternatives that result in binaries hardly any larger than if 
>> you copy-pasted. Again, I think that's reasonable.
>>
>
> Here you are making a trade-off... it's not just about size, but also 
> about performance. More code means more icache misses.
>
> The main point is that *"there are approaches that produce less code than 
> copy-pasting"*. So ideally we want smaller binaries than you would get 
> from copy-pasting.
>
> As I understand it, the package template approaches fall into this camp. 
>> So with the above restrictions, count me in favor of slow and bloated :-)
>>
>
> Not necessarily. I suspect it will be faster to compile than most generics 
> packages and similarly dealing with bloat will be easier.
>
>
>> On Sunday, March 26, 2017 at 9:08:20 AM UTC-4, Egon wrote:
>>>
>>> On Sunday, 26 March 2017 15:30:30 UTC+3, Mandolyte wrote:

 @Bakul - is your approach documented in Egon's collection? I think it 
 is essentially the same as Egon's at
 https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J

 Perhaps your syntax is cleaner, simpler. I also like this general 
 approach. In Egon's document, this approach has nearly no downsides.

>>>
>>> Depending what do you want to use generics for, there are significant 
>>> downsides. Mainly, you cannot create chained general purpose functions... 
>>> e.g. LINQ, Rx... *in the summary document see problems "functional 
>>> code" and "language extensions".*
>>>
>>> You could argue that using such approaches is not good for Go... but 
>>> this wouldn't invalidate that this generics approach doesn't solve these 
>>> problems nicely.
>>>
>>> You are always making trade-offs.
>>>
>>> *Personally, I think it makes trade-offs that are suitable to Go... but 
>>> I understand why people would disagree with it.*
>>>
>>

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

Re: [go-nuts] Re: Algorithm Club

[David Collier-Brown]

Hmmn, we may be thinking different things... I *think* I'm looking for a 
way to say "an X of Y", and see composition as a possible approach.

I just don't know if it will be a, the, or not the answer (;-))

--dave


On 24/03/17 11:21 PM, Michael Jones wrote:

I think I was saying that what I seem to want personally is the "simple,
weak, slight" thing that you likely see as failure.

The opposite end of that--where everything is a list and can be composed
without special regard (lisp) or everything is an object that can
receive any message (smalltalk) are comfortable for me, but just not
what I find myself wanting very often.

My own view is not important in the sense that a broad survey would be,
but since it seems much less than what people seem to dream of, I wanted
to share that maybe people could be happy with less than they seek.

Or maybe that ultimate typeless generality is what others really need
somehow. I would not know.

On Fri, Mar 24, 2017 at 6:13 PM David Collier-Brown <davecb...@gmail.com
<mailto:davecb...@gmail.com>> wrote:

We still don't understand genrality: the current generics are
unimpressive. The proposals for Go are typically "let's do something
that has failed already, in hopes that trying it agin will have a
different result".  That, alas, is one of the definitions of insanity.

Due caution is advised!


--
You received this message because you are subscribed to the Google
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.

--
Michael T. Jones
michael.jo...@gmail.com <mailto: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.

[go-nuts] Re: Algorithm Club

[David Collier-Brown]

We still don't understand genrality: the current generics are unimpressive. 
The proposals for Go are typically "let's do something that has failed 
already, in hopes that trying it agin will have a different result".  That, 
alas, is one of the definitions of insanity.

Due caution is advised!


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: How to control the symbol visibility of shared lib built from Go

[David Collier-Brown]

Hidden isn't used by Go at this time, but if it's part of the elf 
tradition, then the term probably refers to the same thing that 
Sunw_PRIVATE did on Solaris: this symbol can only be used within the 
library, not by anyone outside it.

It's a tiny bit of a kludge: we didn't realize we needed a "binder"[1]  to 
remove symbols we didn't want visible, so we declared them private and 
complained when they were used by anything other than a system library.

Were you thinking of this kind of use, or did you have soemthing else in 
mind? 

--dave
[1. http://multicians.org/mgb.html]

On Monday, March 20, 2017 at 7:51:56 AM UTC-4, Song Liu wrote:
>
> But it seems that all the symbols from this library is "DEFAULT", is there 
> a way to use the "HIDDEN" symbol visibility by default, but "DEFAULT" only 
> for the API exposed by this library.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Different latency inside and outside

[David Collier-Brown]

Are you seeing the average response time / latency of the cache from 
outside? 

If so, you should see lots of really quick responeses, and a few ones as 
slow as inside that average to what you're seeing.

--dave


On Saturday, March 18, 2017 at 3:52:21 PM UTC-4, Alexander Petrovsky wrote:
>
> Hello!
>
> Colleagues, I need your help!
>
> And so, I have the application, that accept through http (fasthttp) 
> dynamic json, unmarshal it to the map[string]interface{} using ffjson, 
> after that some fields reads into struct, then using this struct I make 
> some calculations, and then struct fields writes into 
> map[string]interface{}, this map writes to kafka (asynchronous), and 
> finally the result reply to client through http. Also, I have 2 caches, one 
> contains 100 millions and second 20 millions items, this caches build using 
> freecache to avoid slow GC pauses. Incoming rate is 4k rps per server 
> (5 servers at all), total cpu utilisation about 15% per server.
>
> The problem — my latency measurements show me that inside application 
> latency significantly less then outside.
> 1. How I measure latency?
> - I've add timings into http function handlers, and after that make 
> graphs.
> 2. How I understood that latency inside application significantly less 
> then outside?
> - I'm installed in front of my application the nginx server and log 
> $request_time, $upstream_response_time, after that make graphs too.
>
> It graphs show me that inside application latency is about 500 
> microseconds in 99 percentile, and about 10-15 milliseconds outside 
> (nginx). The nginx and my app works on the same server. My graphs show me 
> that GC occur every 30-40 seconds, and works less then 3 millisecond.
>
>
> 
>
>
> 
>
>
> Could someone help me find the problem and profile my application?
>

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

[go-nuts] Re: No Allman-Style, No go!

[David Collier-Brown]

We learned in the C era to /ALWAYS/ run code through indent(1) before 
comitting to source control. Otherwise we'd misread each other.

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