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

[Jeff Sickel]

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 that the Plan 9 port will be decoupled from the
> codereview system and in effect will be left to bitrot wherever it
> will be maintained when that happens.
> 
> I consider that a disaster, others may think otherwise.

Codereview has it’s issues.  For me, it’s the inability to actual
construct a query that works to return any CLs related to Plan 9,
or anything for that matter.  Could be that I’m running a non-supported
browser when I’m trying to pull up details.  And I thought this version
of Chrome was the most recent…

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

[lucio]

> 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 with the
need of the Go developers to have sustained maintenance of the Plan 9
port of Go so that they need not provide this maintenance themselves,
then the Plan 9 port will no longer be supported, meaning that the Go
developers are under no obligation to correct any errors that may
affect (exclusively) the port to Plan 9 that may be caused by
development in their other territory.

It also means that the Plan 9 port will be decoupled from the
codereview system and in effect will be left to bitrot wherever it
will be maintained when that happens.

I consider that a disaster, others may think otherwise.

++L

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

[Jeff Sickel]

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, that does
share some history with Plan 9 and various other spin offs.  But
though it started with a few people who happened to have worked
on Plan 9 in the past to hone their ideas, the minimal stubs
used in Go that are similar to core Plan 9 libraries are just that,
mechanisms to bootstrap the language.  Taking libc and libbio and
the initial C toolchain is a great way to start.

I do think they’ve done a very nice job at getting the language
off the ground on several platforms.  And it’s great to see the
Go talks and references back to CSP.  But at the end of the day,
Go is a very different research platform that doesn’t really
map onto what draws many of us to Plan 9.  It’s a great tool to
have in the shop, but like any combo-tool, sometimes you just
have to put it on the bench so you can really use the kW CO2
laser without being distracted.



On Dec 4, 2013, at 12:19 AM, lu...@proxima.alt.za wrote:

>> 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 makes
> Plan 9 a superfluous platform for Go: the cost of maintaining the
> port(s) would never be recoverable in deployment of Go applications to
> any Plan 9 platform.
> 
> On the other hand, if Go and Plan 9 continue to influence each other's
> development and philosophy, I think both will benefit, as well as
> their respective communities.  The discussion here, superficial as it
> is, is a case in point.
> 
> ++L
> 
> 
> 
> 

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

[lucio]

> 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 message from me may have had too many recipients.
I'd like to inspect that message, if at all possible, I don't have
enough information to identify it and check its origin on this side.

++L

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

[lucio]

> 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 makes
Plan 9 a superfluous platform for Go: the cost of maintaining the
port(s) would never be recoverable in deployment of Go applications to
any Plan 9 platform.

On the other hand, if Go and Plan 9 continue to influence each other's
development and philosophy, I think both will benefit, as well as
their respective communities.  The discussion here, superficial as it
is, is a case in point.

++L

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

[lucio]

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

[erik quanstrom]

> 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 in this is that this is the only thing left to have 
> MirBSD Ksh fully functional (potentially an up-to-date and actively 
> maintained 
> sh for APE instead of the current pdksh).

i haven't done anything about SIGCHLD.  in your case, i think a special little
thread to call wait4 and kill(parent, SIGCHILD) would do.

- erik

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

[Jens Staal]

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 differences to an absolute minimum and,
> specifically, we ought to avoid libbio diverging from the Plan 9
> native version - at the cost of altering the latter, if necessary - so
> that the two systems are kept closer together.
> 

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 in this is that this is the only thing left to have 
MirBSD Ksh fully functional (potentially an up-to-date and actively maintained 
sh for APE instead of the current pdksh).

-- 

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

[erik quanstrom]

> 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 [...]
>
> It is moot, I grant that, but as a responsible citizen, I feel it is
> my duty not to create conditions than future generations can't recover
> from, at least as long as there is an option.  Yeah, it's a
> philosophical line in the sand, but you did ask where I was drawing it
> and I'm hoping I have made it a little clearer (even to myself).

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.

- erik

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

[lucio]

> 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 9, only libmach, of the
libararies required, differs substantially from the Go release version
to require special functionality.  The differences aren't
irreconcilable, but they are pretty vast.

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 differences to an absolute minimum and,
specifically, we ought to avoid libbio diverging from the Plan 9
native version - at the cost of altering the latter, if necessary - so
that the two systems are kept closer together.

The point here is that once we grant licence for libbio to diverge,
there is no limit to how far it will go and any efforts to bring
either in line with the other will be as difficult as it would be now
for libmach.  Libmach and lib9 both show how far apart this divergence
will go if encouraged.

It is moot, I grant that, but as a responsible citizen, I feel it is
my duty not to create conditions than future generations can't recover
from, at least as long as there is an option.  Yeah, it's a
philosophical line in the sand, but you did ask where I was drawing it
and I'm hoping I have made it a little clearer (even to myself).

++L

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

[sl]

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

[john francis lee]

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 it's not a question of forking the library. there's a ton of stuff 
under go/src,
so what makes libbio special? why not just compile the one there for 
its  use, which is the one it expects?

the output goes into a go-specific target directory; what else will care?

google and the nsa will care ?

--
--
Hi there, NSA 'analysts', in-house and/or contracted.

Just reminding you that if you are reading this you are committing a crime, 
that you are felons mocking the 4th Amendment of our US Constitution ...

  "The right of the people to be secure in their persons, houses, papers, and 
effects, against unreasonable searches and seizures, shall not be violated, and no 
warrants shall issue, but upon probable cause, supported by oath or affirmation, and 
particularly describing the place to be searched, and the persons or things to be 
seized."

... and that someday, really soon I hope, you're going to have to pay for your 
crimes.

You're breaking international laws as well, so if you're thinking of the 'I was 
only following orders!' defense ... Please see Nuremberg Principle IV ...

  "The fact that a person acted pursuant to order of his Government or of a superior 
does not relieve him from responsibility under international law, provided a moral choice 
was in fact possible to him".

... and start exercising your moral choice. Look upon Thomas Andrews Drake and 
Edward Snowden as your exemplars and Patron Saints.

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

[Scott Schwartz]

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 drop the message, it was
> somewhat personal.

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.

Re: [9fans] ca.pem

[Daode]

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 go(1) program [2] which was later also
suggested as good by Christian Heimes (in [1]).

  [1] 
  [2] 

I'm using curl-ca-bundle from curl(1), but that's perl(1).

--steffen
--- Begin Message ---
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 Go’s
> crypt/x509, but do you use a blank, self-signed template,
> or an actual trusted CA chain?
>
>
>
>
--- End Message ---

Re: [9fans] ca.pem

[Skip Tavakkolian]

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 Go’s
> crypt/x509, but do you use a blank, self-signed template,
> or an actual trusted CA chain?
>
>
>
>

Re: [9fans] ca.pem

[Jeff Sickel]

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.google.com fingerprints every few days.

On Dec 3, 2013, at 12:36 PM, David du Colombier <0in...@gmail.com> wrote:

> 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

[David du Colombier]

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

[Jeff Sickel]

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:

> obviously, plan9 has no root.
> 
> --
> cinap
> 

Re: [9fans] ca.pem

[erik quanstrom]

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

[cinap_lenrek]

obviously, plan9 has no root.

--
cinap

Re: [9fans] ca.pem

[David du Colombier]

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] Go and 21-bit runes (and a bit of Go status)

[erik quanstrom]

> One does not simply compile.

certainly not.  one simply compiles.

- erik

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

[Skip Tavakkolian]

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
>> diverge without consequences.
>>
>
> but it's not a question of forking the library. there's a ton of stuff
> under go/src,
> so what makes libbio special? why not just compile the one there for its
>  use, which is the one it expects?
> the output goes into a go-specific target directory; what else will care?
>

[9fans] ca.pem

[Jeff Sickel]

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)

[Bence Fábián]

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 problem is at least as
> > embarrassing as the expansion of BGETLE, but the original code that
> > tripped the compiler was also extremely shoddy.  And the Go
>
> one does not attempt in a compiler.  one does correctly or one does
> not do.  "attempting" is the path to madness.  it's been a while since
> i've debugged something down to the asm and found the compiler had
> got it wrong.  we must keep it this way!
>
> - erik
>
>

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

[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 problem is at least as
> embarrassing as the expansion of BGETLE, but the original code that
> tripped the compiler was also extremely shoddy.  And the Go

one does not attempt in a compiler.  one does correctly or one does
not do.  "attempting" is the path to madness.  it's been a while since
i've debugged something down to the asm and found the compiler had
got it wrong.  we must keep it this way!

- erik

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

[Charles Forsyth]

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 what makes libbio special? why not just compile the one there for its
 use, which is the one it expects?
the output goes into a go-specific target directory; what else will care?

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

[Jeff Sickel]

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 use the
ANSI C preprocessor in order to consume the $GOROOT/include/bio.h
is necessary.

In any case, both patches 14604047 and 15750047 fix the Go libbio
addition problem when building on Plan 9.  Neither have made any
progress in getting rolled up into the Go sources.  I’m proposing
modifying my patch, 15750047, to extract the four funcs from
bgetc.c and bputc.c and put them into a blec.c so that cmd/dist
will build just blec.c on Plan 9 and install it into
$GOROOT/pkg/obj/plan9_$objtype/blec.$O for linking.

On Dec 3, 2013, at 8:51 AM, Charles Forsyth  wrote:

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

[lucio]

> 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 matter because convergence is unlikely,
but I would say that the immediate gratification of taking the
convenience route does not compare with the rewards of sticking to
good principles.  In this case, I think the price to be paid is pretty
minimal.

++L

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

[erik quanstrom]

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

[erik quanstrom]

> 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
before they were added to sources.

by the way, the sources version of sort is broken wrt 21-bit runes.
i believe the 9atom version was correct.  somehow the sources
version got messed up.

- erik

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

[Charles Forsyth]

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)

[erik quanstrom]

> 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 explained before we think this is a *BAD* idea.  macros
are generally avoided.  especially long complicated ones like those.

> PS: Why the hell is there no Bgetbe* and Bputbe*?

because it's just a micro speed hack for the compiler.  i don't think
they're thinking of maintaining libbio as a system library.  there are
reasons not to use this as libbio.

- erik

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

[erik quanstrom]

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

[Aram Hăvărneanu]

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 in the Go world.

-- 
Aram Hăvărneanu

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

[lucio]

> 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 number of (truly) general-purpose registers, and the
> x86
> does not.

Oy! That's not what I was suggesting.  The sloppy programming was in
$GOROOT/src/cmd/8g/ggen.c where it triggered a compiler failure:
multiplication was used in an expression as argument to a function
invoked inside a loop.

In the compiler, the abort() invocation could be called sloppy, but
not in the same sense :-)

++L

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

[Charles Forsyth]

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 number of (truly) general-purpose registers, and the
x86
does not. The S-U numbers guide register allocation, but there is no
spilling code,
except for nested function calls, and a few special cases that don't use
the S-U numbers.
Given that the out of fixed registers diagnostic occurs rarely in the
normal source,
and the S-U numbers might or might not be strictly accurate, the potential
disadvantage
of introducing inefficiency in existing compiled code by spill code
misguided by inaccurate
estimates made it seem not worthwhile at the time.

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

[lucio]

> 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 and the Go libbio
should be a subset of the Plan 9 one.  Breaking this concept seems
unnecessary, not unforgivable: Go does this with libmach, but there
the details are much more complex and a merge of libmachs between Go
and Plan 9 would in any case be an asset.

As an interesting issue, we could have avoided introducing 21-bit
runes in Plan 9 by extracting a libutf from libc for use in Plan 9,
but we would have gained some time and nothing else.  The same, more
or less, applies to libbio, in my opinion.

++L

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

[lucio]

>> * 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 it is difficult to do.  And as it caught a
rather embarrassing case of sloppy programming, it is tempting to
retain its behaviour, somehow.  But that wouldn't advance the cause of
Plan 9 any, unfortunately.

And that lone 

abort();

against the left margin, is positively ugly.

++L

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

[Richard Miller]

> * 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)

[Charles Forsyth]

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 it once, but i've reverted to being mystified.

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

[lucio]

> 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 9’s /$objtype/lib/libbio.a.

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)
will be accepted if we request it with some urgency?

++L

PS: Why the hell is there no Bgetbe* and Bputbe*?

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

[lucio]

>   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 ought to stay close to the
release wherever possible and in this case Plan 9 needs to come up
with a solution that Go can propagate across present and future
platforms.

++L

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

[lucio]

> 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 something
> more to be said for it, I would like to know.

Almost certainly, Google's involvement is a significant part of the
equation, anyone who denies this is probably delusional (or different
from me, which really makes no difference from my point of view).

The primary objective stated by Rob Pike and in my opinion already
largely achieved in the development of Go was to provide a compiled
language with static typing that could compete in speed of deployment
with the many interpreter where dynamic typing ruled.  It needed to
compile faster than C++ and Java and be comparable in execution speed.

In this respect, Go has been mostly a success, although there are
performance issues that have not yet been sorted out.  The most
important of these is the garbage collector which is undergoing
considerable redesign right now.  The curren model was built out of
necessity without sufficient data points to optimise it; it included a
"stop-the-world" misfeature that has yet to be removed, but is in the
process of being designed out.

Additional objectives have also been achieved: multitasking
primitives, portability across diverse platforms, high readability,
conceptual simplicity, similarity to conventional languages and even
the ability to link to modules written in C and C++, inclusion in the
GNU language package, many more I can't possibly recall.

There is plenty of documentation out there.  If I were to write a
comprehensive dissertation condensing this information into a single
document, I find it difficult to believe that you would trouble
yourself to read it any more than you have read the contents of the
golang.org site.

If you consider such documentation hand-waving, then I doubt you're
interested in hearing more of the same.

++L

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

[Jeff Sickel]

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 current go supplied  but the Plan 9
system supplied bio.h (+ a little mingling in of the additions to
$GOROOT/include/plan9).

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 9’s /$objtype/lib/libbio.a.

I use:
cmd/8g: work around 64-bit bug in 8c for Plan 9
https://codereview.appspot.com/14521056

runtime: do not use memmove in the Plan 9 signal handler
https://codereview.appspot.com/34640045

libbio mod (not full replacement, just funcs and macros)
https://codereview.appspot.com/15750047 libbio

to build go for 386 off a standard sources release with my ape
patch and an install of python 2.7.5 + hg.  There are still issues
in trying to get amd64 working that require changes to cmd/dist
source and some of the pkg/runtime.  I’m close, but need to
eliminate some X11 distractions before really finishing it up.

There is one little bit I’d also like to figure out how to
work around: the install location of go & gofmt: the go_bootstrap
puts those binaries into $GOROOT/bin even though the actual
$objtype targets get installed into $GOROOT/pkg/*$objtype.  It’s
a small mess, but still one that makes multi-architecture
file servers a little awkward (no nearly as awkward as Python’s
attempt at cross-compilation).

-jas

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

[Kurt H Maier]

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 elsewhere by more competent
people than myself; I'm sure you can refer to that literature rather
than expect me to botch a description here.


(a) that's why I bring it up and (b) no, it hasn't.  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 something
more to be said for it, I would like to know.

Right now I get a bunch of hand-waving from everyone I ask, while some
people mutter about having a lot of libraries available -- as though
anything could compete with CPAN... but we don't see anyone helping get
perl a leg up.  So there has to be something capturing peoples interest.
I'm just trying to ascertain what.


I guess you would not like me to read "for COMPANY=Google shift span"
in the above, but I did and others probably too.  The challenge is out
there, $COMPANY does not want to allocate funding to the Plan 9 port
of Go and Plan 9 and Dragonfly BSD have been found wanting with regard
to the support needed by the developers to get their work done.  That
has caused the entry bar to be raised and I believe that is fair, if
inconvenient.


Google is not the first company to ride some fashion show into a bunch
of free work from programmers; they won't be the last.  I've seen similar
flurries of wild-eyed excitement about software from Sun and Nokia and
many others.  They all petered out into silence.  What makes this one
different?  This is an actual serious question; someone please answer
it.

The reason I typed '$COMPANY' instead of 'Google' was to indicate that
my statements were more generalized and not directly or uniquely about
Google.  I cannot believe that I have to explain this basic convention.


If you can contribute resources to the project, we may all be
grateful, but if they come with strings attached such as the need to
tolerate your sarcasm, I suspect some of us may well prefer to refuse
them.


Again, would rectify the sarcasm if there were any.  Instead I asked a
series of simple questions and got shit on for my interest.  You might
want to relax a bit.

khm