Quoting lu...@proxima.alt.za:
Stop being sarcastic and you may stop seeing defensiveness and
hilariousness, too.
Please identify the sarcasm.
As for the Go-vs-Python issue, (a) Python was
latest-language-cum-fashion-accessory itself not too long ago and
(b) enough has been written about it
On Dec 3, 2013, at 1:31 AM, lu...@proxima.alt.za wrote:
I am totally with you on this one. But the macros are in bio.h, so
we may be able to avoid them. They are obscene and trigger many
annoying warnings.
See https://codereview.appspot.com/15750047 as it gets around the
issue w/o using
I have not been able
to discern why people are excited about Go; that is why I asked the
question. As far as I can tell, Go is just a de-facto web programming
language, in direct lineage from perl through python. If that's all the
there there, then I'll just ignore it instead. If there's
runtime: do not use memmove in the Plan 9 signal handler
https://codereview.appspot.com/34640045
I've lost track, but would it make sense to apply go386=387 instead of
that patch (I'm pretty sure that is what I did for at least a while)
in all Plan 9 builds? I'm thinking that we
I’m still not completely satisfied, but once I figure out cmd/dist
internals a little more then the file I’ve currently dropped in
$GOROOT/src/lib9/bio_plan9.c can be moved to $GOROOT/src/libbio
and just compiled storing the $O in $GOROOT/pkg/obj/plan9_$objtype
and linked in addition to Plan
On 3 December 2013 08:14, Jeff Sickel j...@corpus-callosum.com wrote:
See https://codereview.appspot.com/15750047 as it gets around the
issue w/o using the current go supplied bio.h but the Plan 9
go has its own bio, used by its self-contained source tree.
why can't it just use the one it
go has its own bio, used by its self-contained source tree.
why can't it just use the one it expects?
i think you explained it once, but i've reverted to being mystified.
Does Go, the tool chain itself, need libbio? If not, then it is there
only for building Go on platforms other than Plan 9
On 3 December 2013 10:08, lu...@proxima.alt.za wrote:
I seem to remember
Charles suggesting that it is difficult to do. And as it caught a
rather embarrassing case of sloppy programming
It's not sloppy programming, but an underlying assumption about RISC
machines in the (then) future
having
On 3 December 2013 10:08, lu...@proxima.alt.za wrote:
I seem to remember
Charles suggesting that it is difficult to do. And as it caught a
rather embarrassing case of sloppy programming
It's not sloppy programming, but an underlying assumption about RISC
machines in the (then) future
On Tue, Dec 3, 2013 at 11:04 AM, lu...@proxima.alt.za wrote:
a merge of libmachs between Go
and Plan 9 would in any case be an asset.
No, because the Go one changes all the time. E.g., now go puts half
the linker into the compilers; object files will contain real machine
code.
These details
Does Go, the tool chain itself, need libbio? If not, then it is there
yes.
- erik
I saw your CL, but I think your description is a bit too concise, I
can't quite get my mind around it. Has anyone consulted with Bell
Labs and tried to convince them to add Bgetle* and Bputle* in libbio,
yet? I have a feeling that a clean patch (I'm sure I have one handy)
lucho, as
BTW, another big item that I forgot to mention, which ironically has been
the Subject of this thread, is the support for 21bit runes.
that was the trigger for getting them into sources,
but unicode specifies a 21-bit rune. we were wrong.
and both 9atom and p9p had 21-bit runes several years
other issues, of course). What I can't do is develop the tool
chain, for that I use Python/Mercurial/Codereview on a NetBSD host
9atom + jas' python will solve that issue. and still you have
a netbsd+python dependency.
- erik
why can't it just use the one it expects?
why does it have to be the same as the one in /sys/src?
To keep the Go distribution honest? Eventually, we'd want as much
convergence as possible, forking the library would make it easier to
diverge without consequences.
Of course, it doesn't really
Because then you’ve got to use additional ifdefs per patch
https://codereview.appspot.com/14604047/. Sorry Anthony, I
died a little seeing
#if !defined(_WIN32) !defined(PLAN9)
The cmd/dist/build.c changes are fine as I’m messing around
with similar edge cases. And of course getting [569]c to
On 3 December 2013 16:04, lu...@proxima.alt.za wrote:
To keep the Go distribution honest? Eventually, we'd want as much
convergence as possible, forking the library would make it easier to
diverge without consequences.
but it's not a question of forking the library. there's a ton of stuff
The patch was a bit of a scream. I'm the first to admit that 8c needs
a touch of TLC and that an abort() in the middle of a compiler,
without the slightest attempt to deal with the problem is at least as
embarrassing as the expansion of BGETLE, but the original code that
tripped the compiler
Compile or not compile, there is no try.
One does not simply compile.
2013/12/3 erik quanstrom quans...@quanstro.net
The patch was a bit of a scream. I'm the first to admit that 8c needs
a touch of TLC and that an abort() in the middle of a compiler,
without the slightest attempt to deal
What do people use for /sys/lib/tls/ca.pem?
I noticed that David added it as the default for Go’s
crypt/x509, but do you use a blank, self-signed template,
or an actual trusted CA chain?
i agree; i was also surprised when i realized this.
On Tue, Dec 3, 2013 at 8:47 AM, Charles Forsyth
charles.fors...@gmail.comwrote:
On 3 December 2013 16:04, lu...@proxima.alt.za wrote:
To keep the Go distribution honest? Eventually, we'd want as much
convergence as possible, forking the
One does not simply compile.
certainly not. one simply compiles.
- erik
It is mean to contain the trusted root certification authorities.
Such a file didn't exist previously on Plan 9, since the native X.509
libraries didn't handle certificate chain verification.
--
David du Colombier
obviously, plan9 has no root.
--
cinap
On Tue Dec 3 13:16:42 EST 2013, cinap_len...@felloff.net wrote:
obviously, plan9 has no root.
it fell off.
- erik
Yes, but if you put a synthesized ca.pem file in place, say
from FreeBSD’s /etc/ssl/cert.pem, then the crypto/rsa test
passes. Though maybe having an empty ca.pem will do the
same.
Either way, it’s needed to successfully use go get.
On Dec 3, 2013, at 12:15 PM, cinap_len...@felloff.net wrote:
Yes, but using go get on a HTTPS URI will fail if you don't trust its
root certificate authority.
--
David du Colombier
I was primarily interested in doing:
go get code.google.com/p/goprotobuf/proto
go get code.google.com/p/goprotobuf/protoc-gen-go
Which works w/ a ca.pem using a trusted root CA. I should probably
fix that with the python code as well since hg pull of go ends
up getting new
root CA certificates. David's reply jogged my memory; if i recall, i cat'ed
/etc/ssl/certs/*.pem of the ubuntu box and it was so i could go get.
On Tue, Dec 3, 2013 at 9:44 AM, Jeff Sickel j...@corpus-callosum.com wrote:
What do people use for /sys/lib/tls/ca.pem?
I noticed that David added
Skip Tavakkolian skip.tavakkol...@gmail.com wrote:
|root CA certificates. David's reply jogged my memory; if i recall, i cat'ed
|/etc/ssl/certs/*.pem of the ubuntu box and it was so i could go get.
I've not really followed it but there was a thread on
OpenSSL-users which mentioned an issue
On Tue, Dec 3, 2013 at 2:47 AM, lu...@proxima.alt.za wrote:
Does anyone know what this is about? It makes me think that I forgot
to delete the 9fans recipient when replying to all, where my
intention was to reply only to Erik, but I can't be sure. If that was
the case, then the moderator
On 12/03/2013 11:47 PM, Charles Forsyth wrote:
On 3 December 2013 16:04, lu...@proxima.alt.za
mailto:lu...@proxima.alt.za wrote:
To keep the Go distribution honest? Eventually, we'd want as much
convergence as possible, forking the library would make it easier to
diverge without
if you are reading this you are committing a crime
This is a public mailing list.
sl
but it's not a question of forking the library. there's a ton of stuff
under go/src,
so what makes libbio special?
I'm not sure where the wires get crossed, let's see if I can get my
point across or, alternatively, if I can figure out what I'm missing.
In building the Go tool chain, in Plan
I'm not sure where the wires get crossed, let's see if I can get my
point across or, alternatively, if I can figure out what I'm missing.
i don't think any wires are crossed.
The point here is that once we grant licence for libbio to diverge,
there is no limit to how far it will go [...]
On Wednesday 04 December 2013 06:25:33 lu...@proxima.alt.za wrote:
For a more Posix-y environment, lib9 and libbio are also required to
provide features that Plan 9 has natively. Lib9 mirrors libc and
libbio is analogous to the real thing. My contention is that we
ought to keep these
one does not attempt in a compiler.
I was talking about outputting an explanatory message. Your point is
valid, but not pertinent here.
++L
what would we recover from? divergence? go never left the building
as it wasn't in the building to begin with. i think this is likely what
you may be missing.
Are you suggesting that any efforts to keep Go and Plan 9 in sync
should be measured purely against short term gain? To me, that
The Go ‘builder’ for Plan 9 386 is on the chopping block:
https://groups.google.com/forum/#!topic/golang-dev/QW4zUbMHMBM
https://code.google.com/p/go-wiki/wiki/PortingPolicy
Lucio, there is no symbiotic relationship between Plan 9 and Go.
Go is its own language, and maybe eventually platform,
The Go ‘builder’ for Plan 9 386 is on the chopping block:
https://groups.google.com/forum/#!topic/golang-dev/QW4zUbMHMBM
https://code.google.com/p/go-wiki/wiki/PortingPolicy
Maybe I am misunderstanding, or maybe our perspectives are
irreconcilably different. As I see it, if we cannot comply
Russ did release the Porting Policy which gives us a good benchmark.
That said, getting the changes people have submitted to codereview
rolled into the default branch so the builder will work is another
issue all together.
On Dec 4, 2013, at 1:20 AM, lu...@proxima.alt.za wrote:
It also means
41 matches
Mail list logo
