will fix.
On Tue, Sep 1, 2009 at 1:10 PM, Russ Cox wrote:
>> temporarly out of time on this one. it appears
>> from the assembly output that 8c multiplies by
>> 0 and not 1 when computing z a second time.
>> nonetheless, i haven't yet seen the problem.
>
> not quite that simple.
> it's a register
> temporarly out of time on this one. it appears
> from the assembly output that 8c multiplies by
> 0 and not 1 when computing z a second time.
> nonetheless, i haven't yet seen the problem.
not quite that simple.
it's a register allocation
(really register management) bug.
On Mon, Aug 31, 2009
if it's my fault i'll fix it. it did screw up mod in a subtle way but
that's been fixed.
brucee
On Tue, Sep 1, 2009 at 11:47 AM, erik quanstrom wrote:
> temporarly out of time on this one. it appears
> from the assembly output that 8c multiplies by
> 0 and not 1 when computing z a second time.
>
temporarly out of time on this one. it appears
from the assembly output that 8c multiplies by
0 and not 1 when computing z a second time.
nonetheless, i haven't yet seen the problem.
#include
#include
void
main(void)
{
int three, one;
uvlong twelve, z;
one = 1;
> It might be worth the effort to implement Go Text Protocol
> (http://www.lysator.liu.se/~gunnar/gtp/), just in case you're having
> trouble finding people to play with.
No, I'm going for world domination. Starting with the local Go group.
The fileserver is meant for Plan 9 communications, and i
It might be worth the effort to implement Go Text Protocol
(http://www.lysator.liu.se/~gunnar/gtp/), just in case you're having
trouble finding people to play with.
Anyway, nice work.
fhs
2009/8/31 Akshat Kumar :
> With the hopes of playing Go amongst
> fellow Plan 9 users, I've written a little
it was too hard being lazy, so i finally put up a changelog
from the version of nupas presented at iwp9 3e in volos.
http://www.quanstro.net/plan9/changes2009.html
- erik
With the hopes of playing Go amongst
fellow Plan 9 users, I've written a little
filesystem[1] which can currently be
used for any two-player turn-based
games.
I'm currently working on Paurea's
wonderful goban code, to implement
support for reading from and writing to
files, so that we have a worki
> It's (in my opinion) slightly less evil because if(!strlen(name))
> seems like a pretty poor way to determine that you're looking at the
> root zone. It's also more intuitive and easier to document that you're
> looking at the root than saying `to find root, look for a file named
> as an empty st
2009/8/31 erik quanstrom :
>> 2009/8/31 Bakul Shah :
>> > But this is nasty!
>> > % cat ndb/dom/'' # same as ndbquery dom ''
>>
>> No, the nasty part is really that the file should be called `.' and
>> the filesystem reserves dot as the reference to the current directory.
>> You could probably call
> 2009/8/31 Bakul Shah :
> > But this is nasty!
> > % cat ndb/dom/'' # same as ndbquery dom ''
>
> No, the nasty part is really that the file should be called `.' and
> the filesystem reserves dot as the reference to the current directory.
> You could probably call the file `dot' or `root' (cat nd
2009/8/31 Bakul Shah :
> But this is nasty!
> % cat ndb/dom/'' # same as ndbquery dom ''
No, the nasty part is really that the file should be called `.' and
the filesystem reserves dot as the reference to the current directory.
You could probably call the file `dot' or `root' (cat ndb/dom/dot or
c
On Mon Aug 31 12:58:29 EDT 2009, quans...@coraid.com wrote:
> i don't know if this is related to recent postscript
> printer troubles, but i have no problems talking to
> the local printer. the problem is font support.
> to support fonts, gs is run to convert to a postscript
> bitmap. unfortunate
i don't know if this is related to recent postscript
printer troubles, but i have no problems talking to
the local printer. the problem is font support.
to support fonts, gs is run to convert to a postscript
bitmap. unfortunately, gs isn't up to this task:
; bind /n/sources/plan9/386/bin/gs /bin
On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shah wrote:
>
> ndb maps directly to a list of lisp's association lists but
> how would you map this to a synthetic fs? Something like
> / to yield a tuple? For example:
>
My current intuition in these situations is to allow for both
interfaces -- top level
On Mon, Aug 31, 2009 at 10:52 AM, erik quanstrom wrote:
>
> so plunkers like us with a few hundred machines are just "casual users"?
> i'd hate for plan 9 to become harder to use outside a hpc environment.
> it would be good to be flexable enough to support fairly degnerate cases
> like just flat f
On Mon, 31 Aug 2009 09:25:36 CDT Eric Van Hensbergen wrote:
>
> Why not have a synthetic file system interface to ndb that allows it
> to update its own files? I think this is my primary problem.
> Granular modification to static files is a PITA to manage -- we should
> be using synthetic file
> While that sounds interesting and may be useful in its own right, a
> centralized server isn't really desirable -- part of the nice thing of
> zeroconf is moving to a decentralized environment, and ideally doing
> it in a scalable fashion (which isn't trivial on hundreds of thousands
> of cores,
> > i can see in principle how this could be a good idea (no more
> > comments, though). could you elaborate, though. i have found
> > editing /lib/ndb/local works well at the scales i see.
[...]
> machines, even with multiple admins. I have a feeling it starts to
> break down with thousands of
On Mon, Aug 31, 2009 at 9:55 AM, Francisco J Ballesteros wrote:
> Hmmm. we did that for FS processes on Plan B. I mean, keep a
> dynamic version of a registry. It kept the list of volumes available at a
> central place.
>
> I think it can be used as is on Plan 9, without changes.
>
> There was a pr
On Mon, Aug 31, 2009 at 8:21 PM, Devon H. O'Dell wrote:
> 2009/8/31 Vinu Rajashekhar :
>> "You can implement a NAT by mounting a /net from a perimeter machine
>> with a public IP, while connecting to it from an internal network of private
>> IP addresses, using the Plan 9 protocol 9P in the interna
On Mon, Aug 31, 2009 at 9:36 AM, erik quanstrom wrote:
>
> i can see in principle how this could be a good idea (no more
> comments, though). could you elaborate, though. i have found
> editing /lib/ndb/local works well at the scales i see.
>
I think the main issue with just editing /lib/ndb/loc
Hmmm. we did that for FS processes on Plan B. I mean, keep a
dynamic version of a registry. It kept the list of volumes available at a
central place.
I think it can be used as is on Plan 9, without changes.
There was a program (I think it was called adsrv; not sure, it´s on the
Plan B man pages)
2009/8/31 Vinu Rajashekhar :
> "You can implement a NAT by mounting a /net from a perimeter machine
> with a public IP, while connecting to it from an internal network of private
> IP addresses, using the Plan 9 protocol 9P in the internal network."
>
> This is from the wikipedia page on Plan 9 OS.
> >
> > given the database= option, if one could confine rapid changes to
> > smaller files, one could teach ndb to only reread changed files.
> >
>
> Why not have a synthetic file system interface to ndb that allows it
> to update its own files? I think this is my primary problem.
> Granular mod
>How about we convince the mailing list software to stop
>inserting Reply-To headers.
please don't. it's a list, with reply to the list.
Was waiting for someone else to say it, but you should look at what
Octopus does with its operation continuation flags.
Another interesting twist on this is "lossy" streams -- but such a
thing may be best represented outside of 9P (or perhaps with a 9P
gateway).
-eric
On Mon, Aug 31, 2009 at
On Mon, Aug 31, 2009 at 9:04 AM, erik quanstrom wrote:
>
> given the database= option, if one could confine rapid changes to
> smaller files, one could teach ndb to only reread changed files.
>
Why not have a synthetic file system interface to ndb that allows it
to update its own files? I think t
> > > did anyone already investigate how an streaming (w/o expicit read
> > > requests) could be done via 9P ?
> >
> > Why don't you use a protocol more suitable for high latencies?
>
> i think the problem rather is the tradition of having one
> outstanding message per fid. as far as i can tell,
> Of course. My use of DNS was really just in abstract to refer to the
> suite of existing services for name and service resolution under Plan
> 9. However, I think the current interfaces for ndb and cs are very
> limiting and the single file based query mechanisms don't really match
> the hierar
that wiki writeup isn't really right. importing /net isn't NAT in any
sort of technical sense; rather, it's what plan 9 does instead.
there's no "translation" of ports or addresses, it's more
(conceptually) like a straight multiplexing.
On Mon, Aug 31, 2009 at 7:51 AM, erik quanstrom wrote:
> could you explan why you're focused on dns?
> a more natural way to use plan 9 would be to use
> ndb and cs directly. wouldn't it?
>
Of course. My use of DNS was really just in abstract to refer to the
suite of existing services for name a
> "You can implement a NAT by mounting a /net from a perimeter machine
> with a public IP, while connecting to it from an internal network of private
> IP addresses, using the Plan 9 protocol 9P in the internal network."
>
> This is from the wikipedia page on Plan 9 OS.
>
> Is something like ipta
On Mon Aug 31 09:00:33 EDT 2009, 23h...@googlemail.com wrote:
> Why don't you use a protocol more suitable for high latencies?
>
i think the problem rather is the tradition of having one
outstanding message per fid. as far as i can tell, 9p doesn't
have this restriction. we just use it that way
Why don't you use a protocol more suitable for high latencies?
On Mon, Aug 31, 2009 at 12:20 PM, Enrico Weigelt wrote:
>
> Hi folks,
>
>
> did anyone already investigate how an streaming (w/o expicit read
> requests) could be done via 9P ?
>
> An option could be adding a new opcode telling the ser
"You can implement a NAT by mounting a /net from a perimeter machine
with a public IP, while connecting to it from an internal network of private
IP addresses, using the Plan 9 protocol 9P in the internal network."
This is from the wikipedia page on Plan 9 OS.
Is something like iptables like in l
> I think there are a few issues beyond will it scale - of course with
> 128k nodes scaling is a baseline prereq for us. On BG we have a
> segmented network to deal with -- but it's likely you'll want some
> form of hierarchy regardless.
>
> I have done much with dynamic service registry us
On Aug 30, 2009, at 10:34 PM, erik quanstrom
wrote:
On Sun Aug 30 14:37:29 EDT 2009, rminn...@gmail.com wrote:
One way to make this kind of interesting is to address how you'd do a
reasonable zeroconf effort given that you need to boot 1m+ machines.
We've booted 4400*250 VMs on a machine at
Hi folks,
did anyone already investigate how an streaming (w/o expicit read
requests) could be done via 9P ?
An option could be adding a new opcode telling the server that it
should send RRead's contigiously, within some given some range.
(will require an ordered transport, since RRead lacks
On Sat, Aug 29, 2009 at 2:32 PM, Jonas Amoson wrote:
> I have not progressed any further in getting lp(1)
> to print to my networked printer. But by playing
> around, I found a work-around that solves my problem
> for the moment:
>
> cat myfile.ps | telnet tcp!192.168.1.101!9100
>
> /jonas
>
>
Fo
40 matches
Mail list logo
