> 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
> 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
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 on
> (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
> 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 t
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, wrote:
> I'm in the process of writing some filters in rc(1). One thing th
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
ca
Pavel Zholkover 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 of only 256mb.
> 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
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 Marti
Anthony Martin 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.
Anthony
andrey mirtchovski 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.
Everything works fine for m
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
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 b
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 code
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 i
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 abo
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 d
Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
On Apr 3, 2011 11:26 AM, "Lucio De Re" 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 plan 9.
>>
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"
> wrote:
You'd perpetuate an alien binary format, which sounds like a bad idea
to me. But I'm so muddled up
What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, "Skip Tavakkolian"
wrote:
While browsing in 9fans today I discovered that some people actually
have written cool user interfaces in Plan9:
http://marc.info/?l=9fans&m=111558827311549&w=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:1
Why can't we use linuxemu to run the build?
-Skip
On Apr 3, 2011, at 8:43 AM, erik quanstrom 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 GCC, namely Pla
> 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 b
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.
>
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.
>
> http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&r=d6ec95bd4f9b2e9af2d10f
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
On 3 April 2011 13:21, Rudolf Sykora 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 setrgbcolor lin
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 thi
> 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 hack
On Apr 3, 2011 12:18 PM, "erik quanstrom" 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 cross compi
On Sat Apr 2 22:49:25 EDT 2011, robp...@gmail.com 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.
okay, i volunteer. j
On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach 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/ with mainline.
Pav
my paatch is not correct. i've "fixed" it here, but i'd love to be
able to get a gotest binary to run on plan9 to make sure my fix is
right.
On Sun, Apr 3, 2011 at 1:45 AM, Pavel Zholkover wrote:
> I've set up a Mercurial patch queue with some instructions on building
> at https://bitbucket.org/p
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
35 matches
Mail list logo
