Re: [9fans] Help requested. Boyd, where are you?
Boyd thought Sudoko sucked, I wrote a limbo program that serves a webpage. brucee On 13 January 2014 15:28, andrey mirtchovski mirtchov...@gmail.com wrote: you can borrow the ui from here: http://mirtchovski.com/p9/sudoku/ On Sun, Jan 12, 2014 at 9:20 PM, lu...@proxima.alt.za wrote: I was thinking of doing a Sudoku solver in Plan 9. So, what kind of peripherals are going to be available for the UI? ++L
[9fans] /n convention history?
When I first met plan9 (2nd ed) I realized that /n was a very powerful ordering concept. (Since then I usually create a /n or ~/n on every unix where I will use mount to customize my ns.) I'd like to know - what's the story of /n? (why was it invented?) - what does n stand for? (a set of n things?) thanks, fgergo
Re: [9fans] /n convention history?
/n was introduced (i believe) in 8th edition for weinberger's neta (and later netb) remote filesystem. there was a directory in /n for each remote machine. the gmount() system call was used to mount a stream, usually a datakit connection, to the remote machine. it was great. brucee On 13 January 2014 19:32, fge...@gmail.com wrote: When I first met plan9 (2nd ed) I realized that /n was a very powerful ordering concept. (Since then I usually create a /n or ~/n on every unix where I will use mount to customize my ns.) I'd like to know - what's the story of /n? (why was it invented?) - what does n stand for? (a set of n things?) thanks, fgergo
[9fans] Acme, dump, and $HOME
Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? I know I can pass it a different filename, but it seems odd to put it in $HOME instead of where acme is called from. My use case is this: I'm working on two projects, and so want to maintain two long-term sessions. Dump does most of what I need when I move from one to the other, but if I don't chord in the project root directory to save the dump to, I kill my other project session. A one line change to looking at $PWD instead of $HOME makes acme much more useful for my case, but am I missing an important other use? Paul
Re: [9fans] Acme, dump, and $HOME
On Monday 13 of January 2014 08:42:22 Paul Lalonde wrote: Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? I know I can pass it a different filename, but it seems odd to put it in $HOME instead of where acme is called from. My use case is this: I'm working on two projects, and so want to maintain two long-term sessions. Dump does most of what I need when I move from one to the other, but if I don't chord in the project root directory to save the dump to, I kill my other project session. A one line change to looking at $PWD instead of $HOME makes acme much more useful for my case, but am I missing an important other use? from acme(1): Dump Write the state of acme to the file name, if specified, or $home/acme.dump by default. i.e., Dump takes one optional argument: file pathname. -- dexen deVries [[[↓][→]]]
Re: [9fans] Acme, dump, and $HOME
On 13 January 2014 16:42, Paul Lalonde paul.a.lalo...@gmail.com wrote: Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? alternatively, if started with acme -l dumpfile, why not write it back to the same file?
Re: [9fans] Acme, dump, and $HOME
Yes, I understand the current behaviour. I don't understand why $home was privileged this way, instead of the startup directory. So for instance, if I drop the dump filename in the top-level tag, and chord it against dump, I get the right thing - it's deposited in the directory where acme was started. I just don't understand why acme.dump should go to $home by default, when everything else in the editor is relative to the window directory. On Mon, Jan 13, 2014 at 8:49 AM, dexen deVries dexen.devr...@gmail.comwrote: On Monday 13 of January 2014 08:42:22 Paul Lalonde wrote: Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? I know I can pass it a different filename, but it seems odd to put it in $HOME instead of where acme is called from. My use case is this: I'm working on two projects, and so want to maintain two long-term sessions. Dump does most of what I need when I move from one to the other, but if I don't chord in the project root directory to save the dump to, I kill my other project session. A one line change to looking at $PWD instead of $HOME makes acme much more useful for my case, but am I missing an important other use? from acme(1): Dump Write the state of acme to the file name, if specified, or $home/acme.dump by default. i.e., Dump takes one optional argument: file pathname. -- dexen deVries [[[↓][→]]]
Re: [9fans] Acme, dump, and $HOME
That seems even more magical, I think. I've been running with Dump's $HOME lookup changed to $PWD for a few days now with nary a glitch. Unless someone tells me otherwise I'll start pushing for a patch :-) Paul On Mon, Jan 13, 2014 at 8:57 AM, Charles Forsyth charles.fors...@gmail.comwrote: On 13 January 2014 16:42, Paul Lalonde paul.a.lalo...@gmail.com wrote: Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? alternatively, if started with acme -l dumpfile, why not write it back to the same file?
Re: [9fans] Acme, dump, and $HOME
Because this way there is one default dump file. Maybe it should be $home/lib/acme.dump But when i turn on my terminal it runs acme -l $home/acme.dump automatically. And before i turn it off i just press dump. If I need to preserve a state for longer i can do Dump otherfile. For me this seems the saner behaviour. tl;dr I'm against your patch, sorry 2014/1/13 Paul Lalonde paul.a.lalo...@gmail.com That seems even more magical, I think. I've been running with Dump's $HOME lookup changed to $PWD for a few days now with nary a glitch. Unless someone tells me otherwise I'll start pushing for a patch :-) Paul On Mon, Jan 13, 2014 at 8:57 AM, Charles Forsyth charles.fors...@gmail.com wrote: On 13 January 2014 16:42, Paul Lalonde paul.a.lalo...@gmail.com wrote: Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? alternatively, if started with acme -l dumpfile, why not write it back to the same file?
Re: [9fans] Acme, dump, and $HOME
Your described behaviour is unaffected by the patch unless you are running acme (automatically) from another directory. Paul On Mon, Jan 13, 2014 at 10:53 AM, Bence Fábián beg...@gmail.com wrote: Because this way there is one default dump file. Maybe it should be $home/lib/acme.dump But when i turn on my terminal it runs acme -l $home/acme.dump automatically. And before i turn it off i just press dump. If I need to preserve a state for longer i can do Dump otherfile. For me this seems the saner behaviour. tl;dr I'm against your patch, sorry 2014/1/13 Paul Lalonde paul.a.lalo...@gmail.com That seems even more magical, I think. I've been running with Dump's $HOME lookup changed to $PWD for a few days now with nary a glitch. Unless someone tells me otherwise I'll start pushing for a patch :-) Paul On Mon, Jan 13, 2014 at 8:57 AM, Charles Forsyth charles.fors...@gmail.com wrote: On 13 January 2014 16:42, Paul Lalonde paul.a.lalo...@gmail.com wrote: Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME instead of $PWD? alternatively, if started with acme -l dumpfile, why not write it back to the same file?
Re: [9fans] Acme, dump, and $HOME
On 13 January 2014 18:30, Paul Lalonde paul.a.lalo...@gmail.com wrote: That seems even more magical, I think. The idea is that the dump file is a snapshot of a particular state, and it made sense to me to update the given state, instead of putting it back in the default file despite being given an explicit state. That seemed to me a bit contrary.
Re: [9fans] Acme, dump, and $HOME
The idea is that the dump file is a snapshot of a particular state, and it made sense to me to update the given state, instead of putting it back in the default file despite being given an explicit state. That seemed to me a bit contrary. agree. - erik
Re: [9fans] Acme, dump, and $HOME
The idea is that the dump file is a snapshot of a particular state, and it made sense to me to update the given state, instead of putting it back in the default file despite being given an explicit state. That seemed to me a bit contrary. also if a snapshot is wanted, then we have a tool for that: cp(1). :-) - erik
Re: [9fans] Acme, dump, and $HOME
It certainly addresses my use case. I'll give it a spin when I next have 5 minutes to mess with it. Paul On Mon, Jan 13, 2014 at 11:17 AM, Charles Forsyth charles.fors...@gmail.com wrote: On 13 January 2014 18:30, Paul Lalonde paul.a.lalo...@gmail.com wrote: That seems even more magical, I think. The idea is that the dump file is a snapshot of a particular state, and it made sense to me to update the given state, instead of putting it back in the default file despite being given an explicit state. That seemed to me a bit contrary.
Re: [9fans] Acme, dump, and $HOME
On 2014年01月13日 18:30, Paul Lalonde wrote: I've been running with Dump's $HOME lookup changed to $PWD for a few days now with nary a glitch. I think using $PWD might give you a few problems. I had written a wrapper script around acme that bound ./acme.dump over $home/acme.dump, and when ./ happens to be inside a remote filesystem, acme would get upset if it suddenly became inaccessible due to flaky wifi or something, and of course the time that you want a dump the most is when you can't save your work by other means. I've switched to just binding dumps from a directory in $home. If you want to do some guessing of the dump name or something, I don't suspect that it'd take more than about 10 or 20 lines of rc to do it.
[9fans] devdraw memory corruption
when user does read of exactly 12*12 bytes on draw
ctl file, the snprint() adds one more \0 byte writing
beyond the user buffer and corrupting memory.
fix this by not snprint()ing the final space and add
it manually:
--- /sys/src/9/port/devdraw.c Wed Dec 25 13:55:16 2013 UTC
+++ /sys/src/9/port/devdraw.c Mon Jan 13 23:22:13 2014 UTC
@@ -1187,10 +1187,11 @@
error(Enodrawimage);
i = di-image;
}
- n =
sprint(a, %11d %11d %11s %11d %11d %11d %11d %11d %11d %11d %11d %11d ,
+ n =
sprint(a, %11d %11d %11s %11d %11d %11d %11d %11d %11d %11d %11d %11d,
cl-clientid, cl-infoid, chantostr(buf, i-chan),
(i-flagsFrepl)==Frepl,
i-r.min.x, i-r.min.y, i-r.max.x, i-r.max.y,
i-clipr.min.x, i-clipr.min.y, i-clipr.max.x,
i-clipr.max.y);
+ ((char*)a)[n++] = ' ';
cl-infoid = -1;
break;
test program:
#include u.h
#include libc.h
#include draw.h
void
main(int argc, char *argv[])
{
char buf[12*12+1];
buf[12*12] = 'X';
if(read(0, buf, 12*12) != 12*12)
sysfatal(read: %r);
if(buf[12*12] != 'X')
sysfatal(corrupt);
}
term% ./8.out /dev/draw/new
corrupt
--
cinap
Re: [9fans] Help requested. Boyd, where are you?
Yeah. I don't disagree with Boyd's views on Sudoku, as filtered through Brucee. Although, I feel that Boyd would have expressed them by saying something like When I hear the word Sudoku, I reach for my insert your weapon of choice here. However, I have the solver code, thanks to Knuth. The UI, thanks to Andrey. And the raspberry pi implementation, thanks to Richard Miller. So will try to put them together, with the help of a young colleague, who grew positively enthused at Richard's video on plan9 on the pi, having been trained on a diet of Java and Windows, and said, when I suggested that it might be easier to do something on Linux, said, no, we have to use plan9. In answer to Lucio, peripherals are keyboard, mouse, monitor.
Re: [9fans] devdraw memory corruption
+++ /sys/src/9/port/devdraw.c Mon Jan 13 23:22:13 2014 UTC @@ -1187,10 +1187,11 @@ error(Enodrawimage); i = di-image; } - n = sprint(a, %11d %11d %11s %11d %11d %11d %11d %11d %11d %11d %11d %11d , + n = sprint(a, %11d %11d %11s %11d %11d %11d %11d %11d %11d %11d %11d %11d, cl-clientid, cl-infoid, chantostr(buf, i-chan), (i-flagsFrepl)==Frepl, i-r.min.x, i-r.min.y, i-r.max.x, i-r.max.y, i-clipr.min.x, i-clipr.min.y, i-clipr.max.x, i-clipr.max.y); + ((char*)a)[n++] = ' '; cl-infoid = -1; break; why not use a 145 byte buffer and readstr? - erik
[9fans] Venti on OpenBSD: vtversion: bad format in version string
Hello everyone, I am new to the list and to Plan 9. I have been trying to set up an OpenBSD venti server for a few days now, but to no success. My intention was to use it as the default venti server for my Plan 9 machine. I partitioned the disk using fdisk to create one large OpenBSD partition, and then created two paritions with disklabel, one for arenas and one for isect. I followed the wiki page for setting up venti, and have been able to get it working on Plan 9 and other OSes, but not OpenBSD. Using plan9port-20120508 that is provided with OpenBSD seems to have venti working properly on the system, but it does not work across the network, when trying to connect with vac/unvac to the server with a different OS, I invariably get vtversion: bad format in version string. Using the most up to date plan9port-20140107, I get the same vtversion string when connecting from other OSes, and venti doesn't seem to even work on the server, I in turn get vac: could not connect to server: Connection refused. Any help would be much appreciated it, I don't know what's going on. grm
Re: [9fans] devdraw memory corruption
just saw, sources seems to have already fixed this by using snprint()... so never mind :) -- cinap
