Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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 i

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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 , 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 the

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

On 3 December 2013 08:14, Jeff Sickel wrote: > See https://codereview.appspot.com/15750047 as it gets around the > issue w/o using the current go supplied 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 expects? i think you explained

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> * Repro for Plan 9 8c bug: > unsigned long long x; > > int f(int); > > void > test(void) > { > int a; > a = f(a-x+a); > } Is anybody working on fixing this? If not, I'll volunteer.

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

>> * Repro for Plan 9 8c bug: >> unsigned long long x; >> >> int f(int); >> >> void >> test(void) >> { >> int a; >> a = f(a-x+a); >> } > > Is anybody working on fixing this? If not, I'll volunteer. I haven't heard any offers, I think you're first. I seem to remember Charles suggesting that i

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> 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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

On 3 December 2013 10:08, 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 a respectable nu

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> On 3 December 2013 10:08, 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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

On Tue, Dec 3, 2013 at 11:04 AM, 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 change all the time

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> Does Go, the tool chain itself, need libbio? If not, then it is there yes. - erik

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

why can't it just use the one it expects? why does it have to be the same as the one in /sys/src? On 3 December 2013 14:42, erik quanstrom wrote: > > Does Go, the tool chain itself, need libbio? If not, then it is there > > yes. > > - erik > >

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> 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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> 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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

On 3 December 2013 16:04, 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 under go/src, so w

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

Compile or not compile, there is no try. One does not simply compile. 2013/12/3 erik quanstrom > > 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 proble

[9fans] ca.pem

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?

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

i agree; i was also surprised when i realized this. On Tue, Dec 3, 2013 at 8:47 AM, Charles Forsyth wrote: > > On 3 December 2013 16:04, wrote: > >> To keep the Go distribution honest? Eventually, we'd want as much >> convergence as possible, forking the library would make it easier to >> dive

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> One does not simply compile. certainly not. one simply compiles. - erik

Re: [9fans] ca.pem

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

Re: [9fans] ca.pem

obviously, plan9 has no root. -- cinap

Re: [9fans] ca.pem

On Tue Dec 3 13:16:42 EST 2013, cinap_len...@felloff.net wrote: > obviously, plan9 has no root. it fell off. - erik

Re: [9fans] ca.pem

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:

Re: [9fans] ca.pem

Yes, but using "go get" on a HTTPS URI will fail if you don't trust its root certificate authority. -- David du Colombier

Re: [9fans] ca.pem

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

Re: [9fans] ca.pem

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 wrote: > What do people use for /sys/lib/tls/ca.pem? > > I noticed that David added it as the default for

Re: [9fans] ca.pem

Skip Tavakkolian 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 ([1]). That thread mentioned a

Re: [9fans] Your message to 9fans awaits moderator approval

On Tue, Dec 3, 2013 at 2:47 AM, 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 may as well just

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

On 12/03/2013 11:47 PM, Charles Forsyth wrote: On 3 December 2013 16:04, > 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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> if you are reading this you are committing a crime This is a public mailing list. sl

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> 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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

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

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> Sorry for hijacking - but out of interest, has anyone approached an > implementation of SIGCHLD either in the "go - plan9 reconciliation effort" or > in any of the "fix APE" efforts (if I remember correctly, it would be needed > for > an APE pthreads implementation)? > > My personal interest

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> one does not attempt in a compiler. I was talking about outputting an explanatory message. Your point is valid, but not pertinent here. ++L

Re: [9fans] Go and 21-bit runes (and a bit of Go status)

> 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

Re: [9fans] Your message to 9fans awaits moderator approval

> Hi, I've been on vacation, and just saw this. > As a very weak anti-spam measure we limit the number of recipients > to 9fans mail. Looks like you ran into that. > I'll check the queue and let you know. Thanks, Scott. It is not serious, but I am a little puzzled by the possibility that a mes

[9fans] Go port [was Re: Go and 21-bit runes (and a bit of Go status)]

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, th

Re: [9fans] Go port [was Re: Go and 21-bit runes (and a bit of Go

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

Re: [9fans] Go port [was Re: Go and 21-bit runes (and a bit of Go

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 th