I've set up a Mercurial patch queue with some instructions on building
at https://bitbucket.org/paulzhol/golang-plan9-runtime-patches/
with Andrey and Taru's patches. I'll try to keep it updated :)
Pavel
On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach leim...@gmail.com wrote:
So wait... We can get the toolchain built on plan 9. Or we can target plan 9
via cross compiler? Either way is pretty awesome! Nice work!
We are cross-compiling unless someone syncs
http://code.google.com/p/go-plan9/
On Apr 3, 2011 12:18 PM, erik quanstrom quans...@quanstro.net wrote:
okay, i volunteer. just to make sure, we're talking
about a plan 9 port, not a cross compile?
just let me know what i need to get set up. i can
easily do 386 and arm at this point.
- erik
I think Rob meant it would be a
Could you comment on your changes at http://code.google.com/p/go-plan9/ ?
Can they be pushed to mainline ?
i don't think they can in total. we should push the silly
print format fixes and the added USED() that 8c caught
and gcc didn't.
but there definately are some difficult bits. this
Hello 9fans,
I found that tr2post (at least on p9p) seems to discard [not process]
lines produced with \X'anything' in troff, so an input like
hello
\X'ps: exec 1 0 0 setrgbcolor'
blabla
results in output *without* the setrgbcolor line.
(using lines like this one can achieve coloured .ps, in
On 3 April 2011 13:21, Rudolf Sykora rudolf.syk...@gmail.com wrote:
Hello 9fans,
I found that tr2post (at least on p9p) seems to discard [not process]
lines produced with \X'anything' in troff, so an input like
hello
\X'ps: exec 1 0 0 setrgbcolor'
blabla
results in output *without* the
On Sat, Apr 02, 2011 at 07:48:14PM -0700, Rob Pike wrote:
We'll get the Plan 9 implementation up to scratch. It's not there yet,
though. Once things look solid we'll need a volunteer to set up a
builder so we can automatically make sure the Plan 9 port stays
current.
That's code for we'll
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
but there definately are some difficult bits. this hacked
inclusion of stdio.h is a problem on plan 9.
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
a real solution would be one of
0 copy u.h; hack to taste
1 add the hacks to the real u.h
2 come to a concensus with go about what the defined-bit-width
types should be called. change both plan 9 and go to conform.
i'd
As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free
way to satisfy both toolchains unless one wants to pervert the Plan 9
toolchain. One trivial change to GCC, namely Plan 9's use of empty names
to represent unused arguments, would improve GCC greatly, but is unlikely
to be
Why can't we use linuxemu to run the build?
-Skip
On Apr 3, 2011, at 8:43 AM, erik quanstrom quans...@quanstro.net wrote:
As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free
way to satisfy both toolchains unless one wants to pervert the Plan 9
toolchain. One trivial change to
While browsing in 9fans today I discovered that some people actually
have written cool user interfaces in Plan9:
http://marc.info/?l=9fansm=111558827311549w=2
http://basalt.cias.osakafu-u.ac.jp/plan9/Tyrrhena.gif
http://basalt.cias.osakafu-u.ac.jp/plan9/Tyrrhena2.gif
On Sat, Apr 2, 2011 at 4:12
What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com
wrote:
On Sun, Apr 03, 2011 at 07:49:06PM +0300, Pavel Zholkover wrote:
What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com
wrote:
You'd perpetuate an alien binary format, which sounds like a bad idea
to me.
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
On Apr 3, 2011 11:26 AM, Lucio De Re lu...@proxima.alt.za wrote:
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
but there definately are some difficult bits. this hacked
inclusion of stdio.h is a problem
On Sun Apr 3 12:27:29 EDT 2011, skip.tavakkol...@gmail.com wrote:
Why can't we use linuxemu to run the build?
sure we could, but then you have to maintain linuxemu, and
go. that seems silly.
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
what does gcc have to do
On Sun, Apr 03, 2011 at 01:43:53PM -0400, Devon H. O'Dell wrote:
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
That would be great. I don't even pretend to keep track of what the GCC
group does, I guess I owe you thanks for correcting me. If that's how one
goes
I'm not sure I follow. The 6c and 6g compilers in the Go distribution
are compiled with the local compiler, such as gcc on Linux and OS X.
I don't believe it's possible they have Plan 9-specific features in
their source. I can believe they would have problems compiling on
Plan 9, but that's the
A month or so ago I got the go compiler chain to build on plan9,
port is too grand a term, it was just fixing a few nits.
I wrote mkfiles and fixed a few minor bugs. The bigest problem was my knowledge
of yacc was not sufficent to rework the error generation magic go uses from
the bison based
On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote:
I'm not sure I follow. The 6c and 6g compilers in the Go distribution
are compiled with the local compiler, such as gcc on Linux and OS X.
I don't believe it's possible they have Plan 9-specific features in
their source. I can
On Sun, Apr 03, 2011 at 07:50:20PM +0100, Steve Simon wrote:
A month or so ago I got the go compiler chain to build on plan9,
port is too grand a term, it was just fixing a few nits.
That makes a third version. I seem to remember Erik's version compiled clean
and I have to ask Steve now
andrey mirtchovski mirtchov...@gmail.com once said:
cross-compilation (GOOS=plan9, GOARCH=386, link with -s), but there
are a few issues -- the build fails at crypto, so fmt is not compiled.
for a hello world you need to manually make install pkg/strconv and
pkg/reflect and pkg/fmt.
Anthony Martin al...@pbrane.org once said:
Right now, if you want to run Go binaries on Plan 9, you have to
apply the patch at the bottom of this message. In the future we
should probably have the runtime use the segment(3) device.
That should have been '9vx' instead of 'Plan 9'. Sorry.
I'm not sure I understand the reason 9vx will fail to reserve 768mb
with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
fine, as long as it is not written to.
The -s is no longer needed, 8l generates a.out symbols correctly.
Pavel
On Mon, Apr 4, 2011 at 12:16 AM, Anthony
The reason it doesn't work on 9vx is because the 32 bit Go runtime
reserves a large chunk of address space (currently 768mb). On all
other platforms, this is accomplised with an mmap equivalient, which
we all know won't work on Plan 9.
if i read the thread on this topic correctly, this
Pavel Zholkover paulz...@gmail.com once said:
I'm not sure I understand the reason 9vx will fail to reserve 768mb
with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
fine, as long as it is not written to.
The reason is because 9vx gives user processes a virtual
address space
I'm in the process of writing some filters in rc(1). One thing that has
come to concern me about rc(1) is that read(1) is not a builtin
command. For example, with a loop like:
while(message=`{read})
switch($message) {
case foo
dofoo
case bar
dobar
Write some real world tests using bash/GNU tools, rc (with static
linked versions of p9p) and tell us what happend.
Maybe you will be surprised.
[1] http://cm.bell-labs.com/cm/cs/tpop/
On Mon, Apr 4, 2011 at 12:30 AM, smi...@zenzebra.mv.com wrote:
I'm in the process of writing some filters
One thing that has come to concern me about rc(1) is that read(1) is
not a builtin command.
The general idea here is that forking a new process is not usually
(ever?) the bottleneck, if you have a script that needs to run faster,
there's other overhead to trim first, and if you really need to,
(As a side note, if anyone goes into rc(1)'s source to implement any of
this, please add a -- option (or similar) to the echo builtin while
you're there.
Echo is not a builtin, and for one possible solution see
/n/sources/contrib/lyndon/echon.c
On 4 Apr 2011, at 12:41 am, Tristan Plumb wrote:
I'm also a bit stumped by the fact that rc(1) doesn't have anything
analogous to bash(1)'s string parsing operations: ${foo#bar},
${foo##bar}, ${foo%bar}, ${foo%%bar}, or ${foo/bar/baz}.
I could never remember what these did, except the last
The general idea here is that forking a new process is not usually
(ever?) the bottleneck, if you have a script that needs to run faster,
there's other overhead to trim first, and if you really need to, you can:
(giving up line at a time response).
ifs=($nl)
lines=`{cat}
for($lines as
Each line that's read by the script causes it to fork a new process,
we're not running out. even with a mere four billion odd to choose from.
I understand the Unix/Plan 9 philosophy of connecting tools that do one
job and do it well. But I don't think /bin/read and /bin/test are
places
33 matches
Mail list logo
