[9fans] 9P/Styx: streaming / contigious reading
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 an position field, but quite trivial to implement). What do you think about this ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 174 7066481 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] Interested in improving networking in Plan 9
On Aug 30, 2009, at 10:34 PM, erik quanstrom quans...@quanstro.net 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 sandia, and, let me tell you, it was a pain. It is amusing to watch the programs traverse million line /etc/hosts file -- for a while. how does this apply to plan 9? ndb already provides for indexed databases. but i have not tried this with millions of entries. 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 using DNS in plan 9 - maybe it's easy and just not well documented. Then there's issue of locality - finding the registered service that is closest to you. Then there is load balancing - finding the closest service whch isn't heavily loaded. Then there is dealing with reliability, security, and so forth and so on.
Re: [9fans] Interested in improving networking in Plan 9
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 using DNS in plan 9 - maybe it's easy and just not well documented. i'm sure there are. 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? by the way, ndb/cs is already a program that replaces a static file. why couldn't you use it to do these interesting lookups? it already has some specialized knowledge of protocols. it seems like the place for these things. i've probablly just given away my vast ignorance. please set me straight. :-) - erik
Re: [9fans] Interested in improving networking in Plan 9
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 linux needed to be implemented for Plan 9 ? Again forgive me if I came out looking like an idiot ! On Mon, Aug 31, 2009 at 6:21 PM, erik quanstromquans...@quanstro.net wrote: 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 using DNS in plan 9 - maybe it's easy and just not well documented. i'm sure there are. 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? by the way, ndb/cs is already a program that replaces a static file. why couldn't you use it to do these interesting lookups? it already has some specialized knowledge of protocols. it seems like the place for these things. i've probablly just given away my vast ignorance. please set me straight. :-) - erik -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science Engg, IIT Kharagpur, India.
Re: [9fans] 9P/Styx: streaming / contigious reading
Why don't you use a protocol more suitable for high latencies? On Mon, Aug 31, 2009 at 12:20 PM, Enrico Weigeltweig...@metux.de 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 server that it should send RRead's contigiously, within some given some range. (will require an ordered transport, since RRead lacks an position field, but quite trivial to implement). What do you think about this ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 174 7066481 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] 9P/Styx: streaming / contigious reading
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. - erik
Re: [9fans] Interested in improving networking in Plan 9
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 linux needed to be implemented for Plan 9 ? Again forgive me if I came out looking like an idiot ! not at all. of course this only works for computers that can import /net. just theoretically suppose that your gateway is a plan 9 machine and someone in the house has a windows box. nat would be useful for supporting the windows box that can't import /net. some people would argue that a lot of modems can do the nat so why bother. the reason to bother is to (a) avoid buggy modem firmware and (b) to integrate nat into the rest of one's network services so things like logging, etc. are uniform. and you don't have to deal with the modems dumb http interface. :-) - erik
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 7:51 AM, erik quanstromquans...@quanstro.net 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 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 hierarchical style of the rest of the system. If there is a masters project in here, its to look at a revision of the whole suite and extension of the relevant file system based interfaces. The other side of this is then to integrate this new service registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. -eric
Re: [9fans] Interested in improving networking in Plan 9
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.
Re: [9fans] Interested in improving networking in Plan 9
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 hierarchical style of the rest of the system. If there is a masters project in here, its to look at a revision of the whole suite and extension of the relevant file system based interfaces. The other side of this is then to integrate this new service i definately think there's room for improvement, but i would hate for ndb to morph into the windows registry. the main situation where ndb is weak is when there are rapid changes. otherwise ndb/cs and ndb/mkhash should make it unnecessary to scan whole files. given the database= option, if one could confine rapid changes to smaller files, one could teach ndb to only reread changed files. registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. what do you mean by export? - erik
Re: [9fans] 9P/Styx: streaming / contigious reading
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, 9p doesn't have this restriction. we just use it that way. Maybe the way fcp(1) works is the answer? -- Yaroslav
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 9:04 AM, erik quanstromquans...@quanstro.net 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 this is my primary problem. Granular modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. what do you mean by export? When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. -eric
Re: [9fans] 9P/Styx: streaming / contigious reading
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 9:20 AM, yaroslavyari...@gmail.com wrote: 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, 9p doesn't have this restriction. we just use it that way. Maybe the way fcp(1) works is the answer? -- Yaroslav
Re: [9fans] new sources
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.
Re: [9fans] Interested in improving networking in Plan 9
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 modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. 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 also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. could you give an example? When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. sounds interesting. but i don't understand what you're talking about exactly. maybe you're thinking that cpu could be rigged so that cpu with no host specifier would be equivalent to cpu -h '$boredcpu' where '$boredcpu' would be determined by cs via dynamic mapping? or am i just confused? - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 Vinu Rajashekhar vinuthe...@gmail.com: 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 linux needed to be implemented for Plan 9 ? My student's summer of code project, which was quite unfortunately not completed, was to implement support for NAT in Plan 9, and to implement a firewalling infrastructure. I think it would be good to implement something like this, and several people thought that implementing NAT, if done correctly, would be quite useful for people running Plan 9. I'm still interested in providing guidance and info about this if it's something you're interested in pursuing -- I have quite a few ideas on how it should work. Kind regards, Devon H. O'Dell
Re: [9fans] Interested in improving networking in Plan 9
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) were file servers could keep an open file as long as they were alive. We didn´t do load balancing but it shouldn´t be hard to add that to this program. If there´s interest I can dig in our worm (although it should be also on sources). On Mon, Aug 31, 2009 at 4:25 PM, Eric Van Hensbergeneri...@gmail.com wrote: On Mon, Aug 31, 2009 at 9:04 AM, erik quanstromquans...@quanstro.net 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 this is my primary problem. Granular modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. what do you mean by export? When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. -eric
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 9:36 AM, erik quanstromquans...@quanstro.net 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/local is a combination of scale and number of writers. Writing static config files could work fine in a typical plan 9 network of hundreds of machines, even with multiple admins. I have a feeling it starts to break down with thousands of machines, particularly in an environment where machines are appearing and disappearing at regular intervals (clouds, HPC partitioning, or Blue Gene). Hundreds of thousands of nodes with this sort of behavior probably makes it impractical. Of course -- this won't effect the casual user, but its something that effects us. Its also possible that such a dynamic environment would better support a 9grid style environment. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. There is the relatively mundane configuration examples of publishing multiple file servers, authentication servers, and cpu servers. There's a slightly more interesting example of more pervasive sharing (imagine sharing portions of your ACME file system to collaborate with several co-authors, or for code review). The more applications which export synthetic file systems, the more opportunity there is for sharing and requiring a broader pub/sub interface. There is another option here which I'm side-stepping because its something I'm actively working on -- which is instead of doing such a pub/sub interface within ndb and CS, extending srv to provide a registry for cluster/grid/cloud. However, underneath it may still be nice to have zeroconf as a pub/sub for interoperation with non-Plan 9 systems. When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. sounds interesting. but i don't understand what you're talking about exactly. maybe you're thinking that cpu could be rigged so that cpu with no host specifier would be equivalent to cpu -h '$boredcpu' where '$boredcpu' would be determined by cs via dynamic mapping? or am i just confused? Actually, the idea would be that cpu's default behavior would be to go grab $boredcpu -- but that's part of the idea. That would make adding cpu servers as easy as booting them -- they'd publish their service with zeroconf and everyone would automatically pick it up and be able to query them for additional attributes related to utilization, authentication, or even fee-structures. Of course, as a I alluded to earlier, I think its much more interesting in the presence of pervasive network services exported through file systems. I'd suggest those who haven't to go grab sugar on a stick from the OLPC folks and run it under vmware or whatever. I'm not broadly endorsing every aspect of their environment, but I really liked their loosely coupled sharing/collaboration framework built upon zeroconf and their mesh networks (it may be a bit hard to see this on sugar on a stick, but there were in the past several public OLPC zeroconf servers you could attach to and play around. -eric
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 8:21 PM, Devon H. O'Delldevon.od...@gmail.com wrote: 2009/8/31 Vinu Rajashekhar vinuthe...@gmail.com: 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 linux needed to be implemented for Plan 9 ? My student's summer of code project, which was quite unfortunately not completed, was to implement support for NAT in Plan 9, and to implement a firewalling infrastructure. I think it would be good to implement something like this, and several people thought that implementing NAT, if done correctly, would be quite useful for people running Plan 9. I'm still interested in providing guidance and info about this if it's something you're interested in pursuing -- I have quite a few ideas on how it should work. Yea I did see that it was accepted as a project, but I couldn't see the actual sources or anything, so I assumed it may have got stalled. I am interested in it, from an overall point of view, but right now I am don't know enough about Plan 9 to give any constructive ideas. Still climbing the learning curve ! Thanks for responding though. Kind regards, Devon H. O'Dell -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science Engg, IIT Kharagpur, India.
Re: [9fans] Interested in improving networking in Plan 9
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 machines, particularly in an environment where machines are appearing and disappearing at regular intervals (clouds, HPC partitioning, or Blue Gene). Hundreds of thousands of nodes with this sort of behavior probably makes it impractical. Of course -- this won't effect the casual user, but its something that effects us. 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 files. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. There is the relatively mundane configuration examples of publishing multiple file servers, authentication servers, and cpu servers. how many file servers and authentication servers are you running? - erik
Re: [9fans] Interested in improving networking in Plan 9
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, we certainly don't want unrestricted multicast in such an environment lest we drown in our own vomit of multicast queries and responses). Inferno also has a dynamic registry service available as another example implementation. However -- I think embracing some internet standards wouldn't be a bad thing -- DNS is certainly an existing example of an external protocol we support even though we could have invented our own. Extending the DNS support to mDNS and DNS-SD shouldn't be that big of a deal -- and most of the hard work is in defining the Plan 9 interface not actually writing the protocol support. It would allow us to play nice with other systems, which may be very beneficial in xcpu environments (which also currently suffers from a static configuration), and in particular on our Blue Gene work where front-end nodes are typically Linux or MacOSX workstations. dns is a bad protocol to build on. it's not really secure and the security measures are onerous. not to be confused with a technical argument for or against building on top of dns, but it's worth noting that ndb/dns has been pushed just about as far as it can go. it tends to suffer from cache funnies and can leak memory. i'm hoping that i can get a chance to build a thread library based dns server in the near future. - erik
Re: [9fans] Interested in improving networking in Plan 9
On Mon, 31 Aug 2009 09:25:36 CDT Eric Van Hensbergen eri...@gmail.com 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 system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. ndb maps directly to a list of lisp's association lists but how would you map this to a synthetic fs? Something like attr/value to yield a tuple? For example: % cat ndb/ip/198.41.0.4 # same as ndbquery ip 198.41.0.4 dom=A.ROOT-SERVERS.NET ip=198.41.0.4 % cat ndb/dom/A.ROOT-SERVERS.NET dom=A.ROOT-SERVERS.NET ip=198.41.0.4 But this is nasty! % cat ndb/dom/'' # same as ndbquery dom '' dom= ns=A.ROOT-SERVERS.NET ns=B.ROOT-SERVERS.NET ns=C.ROOT-SERVERS.NET ns=D.ROOT-SERVERS.NET ns=E.ROOT-SERVERS.NET ns=F.ROOT-SERVERS.NET ns=G.ROOT-SERVERS.NET ns=H.ROOT-SERVERS.NET ns=I.ROOT-SERVERS.NET ns=J.ROOT-SERVERS.NET ns=K.ROOT-SERVERS.NET ns=L.ROOT-SERVERS.NET ns=M.ROOT-SERVERS.NET And it is not clear how you would map % ndbquery attr value rattr ... Another alternative is to map each tuple to a directory: % ls ndb/dom/A.ROOT-SERVERS.NET # just show the attributes! dom ip % grep '' ndb/dom/A.ROOT-SERVERS.NET/* dom:A.ROOT-SERVERS.NET ip:198.41.0.4 An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface.
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 10:52 AM, erik quanstromquans...@coraid.com 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 files. I don't disagree. Worst case, this is a complementary platform for large-scale deployments, best case is that its an alternative interface that also improves the experience for the casual user -- I think the main benefit here will be in establishing better mechanisms for collaboration amongst casual users. If any aspect of this makes things more complicated, we are doing something wrong. The whole point of going zeroconf is to make configuration simple. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. There is the relatively mundane configuration examples of publishing multiple file servers, authentication servers, and cpu servers. how many file servers and authentication servers are you running? From a file server perspective on blue gene, a full scale rack will have thousands. we're currently operating without auth (in part due to configuration issues), so I don't know how well it will scale. The other aspect here is that in current configurations, every run has a different machine configuration based on what you request from the job scheduler and what you actually get. We pretty much get different IP addresses every time, with different front ends, different file servers, etc. etc. Again though - the idea is to use file systems more pervasively within the applications as well -- so there may be multiple file servers per node providing different services depending on workload needs at the particular point of computation. Read our MTAGS paper from last year's supercomputing conference to get a bigger picture view on how we view services coming, going, migrating, and adapting to changing application usage and failure. -eric
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.com wrote: ndb maps directly to a list of lisp's association lists but how would you map this to a synthetic fs? Something like attr/value to yield a tuple? For example: My current intuition in these situations is to allow for both interfaces -- top level aggregated queries as well as granular hierarchical queries. Both make sense for different reasons. An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface. The fact that its not immediately clear is what makes it a good research topic. It will likely take several iterations to identify a best fit interface with the likely result that multiple interfaces/views are required. I think there are precious little information on synthetic file system design, given its continuing popularity in the non-Plan-9 world, we could use more published wisdom/experiences from the evolution of various file-system based interfaces. -eric
[9fans] postscript printer trouble
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/gs # make sure its not me ; pdf2ps upasexp.pdf /tmp/x.ps Error: /syntaxerror in -file- Operand stack: --nostringval-- 916 6921 40 78 --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1122/1686(ro)(G)-- --dict:0/20(G)-- --dict:72/200(L)-- --dict:64/80(ro)(L)-- --dict:37/197(L)-- Current allocation mode is local Last OS error: 20 Current file position is 53619 AFPL Ghostscript 8.53: Unrecoverable error, exit code 1 - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com: 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 cat ndb/dom/root) as something that shouldn't ever conflict with anything else -- but the root of DNS is not an empty string. aren't you being a little bit pedantic? quoting is a fact of life. we don't say that it's evil to need to quote or transform things in rc or smtp to deal with local requirements. why would it be evil to quote '.'? and why would be calling '.' 'root' or 'dot' rather than '' be any less evil? - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 erik quanstrom quans...@coraid.com: 2009/8/31 Bakul Shah bakul+pl...@bitblocks.com: 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 cat ndb/dom/root) as something that shouldn't ever conflict with anything else -- but the root of DNS is not an empty string. aren't you being a little bit pedantic? quoting is a fact of life. we don't say that it's evil to need to quote or transform things in rc or smtp to deal with local requirements. why would it be evil to quote '.'? and why would be calling '.' 'root' or 'dot' rather than '' be any less evil? 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 string'. So: less evil because it makes code more intuitive and it makes documentation easier. Also, I think I should state that I really don't care about implementation as long as it's documented, and that the root is not an empty string. I don't particularly care about quoting at all, and I don't consider that any reason for one method to be more obtuse than another. --dho - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com: 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 cat ndb/dom/root) as something that shouldn't ever conflict with anything else -- but the root of DNS is not an empty string. --dho dom= ns=A.ROOT-SERVERS.NET ns=B.ROOT-SERVERS.NET ns=C.ROOT-SERVERS.NET ns=D.ROOT-SERVERS.NET ns=E.ROOT-SERVERS.NET ns=F.ROOT-SERVERS.NET ns=G.ROOT-SERVERS.NET ns=H.ROOT-SERVERS.NET ns=I.ROOT-SERVERS.NET ns=J.ROOT-SERVERS.NET ns=K.ROOT-SERVERS.NET ns=L.ROOT-SERVERS.NET ns=M.ROOT-SERVERS.NET And it is not clear how you would map % ndbquery attr value rattr ... Another alternative is to map each tuple to a directory: % ls ndb/dom/A.ROOT-SERVERS.NET # just show the attributes! dom ip % grep '' ndb/dom/A.ROOT-SERVERS.NET/* dom:A.ROOT-SERVERS.NET ip:198.41.0.4 An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface.
Re: [9fans] Interested in improving networking in Plan 9
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 string'. So: less evil because it makes code more intuitive and it makes documentation easier. having the root be '' makes sense to me. having it be otherwise, say dot would mean that one would properly request example.net.dot not example.net and implies that there are other roots than dot. - erik
Re: [9fans] postscript printer trouble
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. unfortunately, gs isn't up to this task: ; bind /n/sources/plan9/386/bin/gs /bin/gs # make sure its not me ; pdf2ps upasexp.pdf /tmp/x.ps Error: /syntaxerror in -file- Operand stack: --nostringval-- 916 6921 40 78 --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1122/1686(ro)(G)-- --dict:0/20(G)-- --dict:72/200(L)-- --dict:64/80(ro)(L)-- --dict:37/197(L)-- Current allocation mode is local Last OS error: 20 Current file position is 53619 AFPL Ghostscript 8.53: Unrecoverable error, exit code 1 using gs 7.04 from the dump works perfectly. bummer! - erik
[9fans] 9 Games of Go
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 working interface to use. I also have plans to add the same ability to Mirtchovski's port of GNU Go, so that the antisocial community can play amongst themselves (or oneself). The filesystem is meant to simulate a proper game server, through basic file and permissions operations. Creating a directory in the root of the fs is equivalent to a game room. The fs automatically creates two files: 'W' and 'B' under the newly created dir, which correspond, respectively, to the positional data of white and black players. The files, as well as the directory, have uid and gid of the user who created them. When that user wants to play against someone, they set the gid of either 'W' or 'B' to their opponent's uname. To this effect, both files are mode 464. Both files block until new data is written. The fs implements no formatting restrictions to data -- it is left up to clients to agree on a format and use it for the duration of a game. (Oh what fun it might be to map the operations of a Chess game to that of Go) In this way, the fs implements only one real rule, which is general enough for any sort of game (in this class): once either 'W' or 'B' is written, a dirty flag is set on the file, so it may not again be written to, until the other file has been written. There are a few things left to do still, and they are briefly documented in the NOTES[2] file. I crave feedback, so please do not hesitate. Programming suggestions, fs implementations, and the like, all more than welcome. Privately, or publicly. Best, ak [1] The source can be found in /n/sources/contrib/akumar/α/gofs [2] /n/sources/contrib/akumar/α/gofs/NOTES For convenience, I've attached just the gofs source file to this mail. Let me know if this is undesirable. gofs.c.gz Description: GNU Zip compressed data
[9fans] nupas changelog
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
Re: [9fans] 9 Games of Go
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 aku...@mail.nanosouffle.net: 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 working interface to use. I also have plans to add the same ability to Mirtchovski's port of GNU Go, so that the antisocial community can play amongst themselves (or oneself). The filesystem is meant to simulate a proper game server, through basic file and permissions operations. Creating a directory in the root of the fs is equivalent to a game room. The fs automatically creates two files: 'W' and 'B' under the newly created dir, which correspond, respectively, to the positional data of white and black players. The files, as well as the directory, have uid and gid of the user who created them. When that user wants to play against someone, they set the gid of either 'W' or 'B' to their opponent's uname. To this effect, both files are mode 464. Both files block until new data is written. The fs implements no formatting restrictions to data -- it is left up to clients to agree on a format and use it for the duration of a game. (Oh what fun it might be to map the operations of a Chess game to that of Go) In this way, the fs implements only one real rule, which is general enough for any sort of game (in this class): once either 'W' or 'B' is written, a dirty flag is set on the file, so it may not again be written to, until the other file has been written. There are a few things left to do still, and they are briefly documented in the NOTES[2] file. I crave feedback, so please do not hesitate. Programming suggestions, fs implementations, and the like, all more than welcome. Privately, or publicly. Best, ak [1] The source can be found in /n/sources/contrib/akumar/α/gofs [2] /n/sources/contrib/akumar/α/gofs/NOTES For convenience, I've attached just the gofs source file to this mail. Let me know if this is undesirable.
Re: [9fans] 9 Games of Go
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 is left open to serve any interface that provides a two-player turn-based game. This includes Go, Chess, Checkers, and whatever else. After the rudimentary interface is provided by an application (i.e., a board or an automated engine), the only thing required to make it networked is to decide on a format and use it to read/write on files served by the fs (and handle gid permissions, if one wants). To this effect, I've added *no* Go primitives or specifications to the filesystem, and don't intend to do so in the future. I never found it interesting to play with random people on the internet, anyway. This is at least a dreidel roll away from being the roll of dice. Anyway, nice work. Thanks, ak
[9fans] 8c vlong bug
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 u.h
#include libc.h
void
main(void)
{
int three, one;
uvlong twelve, z;
one = 1;
three = 3;
twelve = 12;
z = one*(twelve - three);
print(z = %llud\n, z);
z = (twelve - three) * one;
print(z = %llud\n, z);
exits(0);
}
output:
z = 9
z = 0
- erik
Re: [9fans] 8c vlong bug
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 quanstromquans...@quanstro.net 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.
#include u.h
#include libc.h
void
main(void)
{
int three, one;
uvlong twelve, z;
one = 1;
three = 3;
twelve = 12;
z = one*(twelve - three);
print(z = %llud\n, z);
z = (twelve - three) * one;
print(z = %llud\n, z);
exits(0);
}
output:
z = 9
z = 0
- erik
Re: [9fans] 8c vlong bug
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 at 6:51 PM, Bruce Ellisbruce.el...@gmail.com wrote:
if it's my fault i'll fix it. it did screw up mod in a subtle way but
that's been fixed.
it looks like the cgen64 multiply case is
not managing the registers correctly
when AX is not where it expects.
more details for you:
int three = 3;
int one = 1;
uvlong twelve = 12;
/* ok */
uvlong
mul1(void)
{
return one * (twelve - three);
}
TEXTmul1+0(SB),0,$12
MOVLthree+0(SB),AX
MOVLAX,CX
SARL$31,CX
// three is now in CX:AX
LEALtwelve+0(SB),DX
MOVL(DX),BX
SUBLAX,BX
MOVL4(DX),AX
SBBLCX,AX
// twelve - three is now in AX:BX
MOVLAX,CX
// twelve - three is now in CX:BX
MOVLone+0(SB),AX
MOVLAX,DX
SARL$31,DX
// one is now in DX:AX
// 64-bit multiply CX:BX * DX:AX - DX:AX
MOVLCX,BP
ORL DX,BP
CMPLBP,$0
JNE ,3(PC)
MULLBX,
JMP ,8(PC)
IMULL BX,DX
MOVLAX,BP
IMULL CX,BP
ADDLDX,BP
MOVLBX,DX
MULLDX,
ADDLBP,DX
MOVL.ret+0(FP),CX // probably LEAL
MOVLAX,(CX)
MOVLDX,4(CX)
RET ,
RET ,
vs
/* not ok */
uvlong
mul2(void)
{
return (twelve - three) * one;
}
TEXTmul2+0(SB),0,$12
MOVLone+0(SB),AX
MOVLAX,CX
SARL$31,CX
MOVLAX,BX
// one is now in CX:BX
MOVLthree+0(SB),AX
MOVLAX,DX
SARL$31,DX
// three is now in DX:AX
LEALtwelve+0(SB),BP
MOVL(BP),SI
SUBLAX,SI
MOVL4(BP),AX
SBBLDX,AX
// twelve - three is now in AX:SI
// 64-bit multiply CX:BX * AX:SI
// saving AX and DX so they can be reused.
// DX doesn't even need saving.
MOVLAX,.safe+-4(SP)
MOVLDX,.safe+-8(SP)
MOVLSI,DX
// 8c is very confused at this point.
// it is using AX for multiple purposes.
MOVLCX,AX
ORL SI,AX
CMPLAX,$0
JNE ,4(PC)
MOVLBX,AX
MULLAX,
JMP ,7(PC)
IMULL BX,DX
IMULL CX,AX
ADDLDX,AX
MOVLBX,DX
MULLDX,
ADDLAX,DX
// restore old AX DX now that multiply is over.
// (forgot that multiply left result in DX:AX)
MOVL.safe+-4(SP),AX
MOVL.safe+-8(SP),DX
MOVL.ret+0(FP),CX // probably LEAL
MOVLAX,(CX)
MOVLDX,4(CX)
RET ,
