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!
>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
>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
>>
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
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
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
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 a
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:
>
>
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
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*,
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*,
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
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
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
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
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 custom
verything_.
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 th
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
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
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
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
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
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
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
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
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
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:
>
>
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
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
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
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
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
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 golan
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`
mably 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
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
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
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
>
>
> 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
>
> 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
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
/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
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
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
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
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
>
>
> 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
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
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
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 descri
d
“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...@spamco
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
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
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.
--
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
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
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
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
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
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
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
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
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
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 {
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
>
> 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
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
>
>
> 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
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
69 matches
Mail list logo
