Re: [9fans] RESOLVED: recoving important header file rudely
term% mkdir trashdir cd trashdir mkdir x
term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
i=`{echo $i+1|hoc} } }
term% cp abc* abc* x
# watch the cp executable suicide
# now, make SURE there's nothing in this rio window that you want to keep...
term% rm abc*
# watch the rio window go bye bye!
I'm not someone to complain without also offering solutions, though.
I'm in the process of writing some C macros that might help clean up the
source code, ensure intended bounary conditions, improve some
interfaces, etc. I already have some working code, but it's still very
experimental.
I don't see how C macros would improve rc's globbing code, which
thinks that there won't be files with names that long.
--
Federico G. Benavento
Re: [9fans] RESOLVED: recoving important header file rudely
Somehow a particular problem with a particular application
has degenerated into a rather unfair generalization of the
whole system:
Reading about Plan 9, I was quite excited to install it. I was quite
excited when I first booted and ran it, too. But I distinctly felt my
heart sink a little the first time it hung. Since then, I've browsed
some of the OS source code and, having done that, I came to understand
why the system was so buggy. The core applications appear to be written
in a style of C programming reminiscent of the dawn of UNIX. While the
operating system architecture is BEAUTIFULLY designed (with the
exception, perhaps of that fossil/conf gotcha!), the C code used to
implement it doesn't seem to take advantage of any of the programming
paradigms that have emerged in the intervening 30 years...
It would help the conversation if you described what these
new paradigms are. For instance, Plan 9 does not have any
code that's built upon any sort of functional programming
language. But again, that's not necessary. What practices
has everyone here missed, which would turn Plan 9 code
into gold? The argument seems a bit pretentious.
Getting Plan 9 code to crash is almost too easy:
term% mkdir trashdir cd trashdir mkdir x
term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
i=`{echo $i+1|hoc} } }
term% cp abc* abc* x
# watch the cp executable suicide
# now, make SURE there's nothing in this rio window that you want to keep...
term% rm abc*
# watch the rio window go bye bye!
Sorry, this does not crash any Plan 9 code on my system.
How much data globbing should handle is a matter of practicality.
When rc dies, the rio window closes.
ak
Re: [9fans] RESOLVED: recoving important header file rudely
lotte% 9fs sources
lotte% diff /sys/src/cmd/rc/plan9.c /n/sources/plan9/sys/src/cmd/rc/plan9.c
446d445
char *s;
468,474c467
s = dir[f].dbuf[dir[f].i].name;
if(strlen(s) = NDIR){
pfmt(err, rc: file name too long: %s\n, s);
return 0;
}
strcpy(p, s);
---
strcpy(p, dir[f].dbuf[dir[f].i].name);
lotte% mkdir trashdir cd trashdir mkdir x
lotte% touch `{i=0; while (test $i -lt 128) { echo -n
abcdefghijklmnop; i=`{echo $i+1|hoc} } }
lotte% cp abc* abc* x
file name too long:
abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop
file name too long:
abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop
cp: can't stat abc*: 'abc*' file does not exist
cp: can't stat abc*: 'abc*' file does not exist
lotte% rm abc*
file name too long:
Re: [9fans] RESOLVED: recoving important header file rudely
Some, yes. But most not. At least not yet. :) I expect I might run into trouble figuring out how to pass around strings containing NUL bytes, though. why would you do that? what's the application? if you tell me sed'ing an object file, i'm going to remain unconvinced. if you tell me supporting utf16, then i'm going to disagree. tcs handles utf16 just fine so the rest of the system can use utf-8, as god intended. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
term% mkdir trashdir cd trashdir mkdir x
term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
i=`{echo $i+1|hoc} } }
term% cp abc* abc* x
# watch the cp executable suicide
# now, make SURE there's nothing in this rio window that you want to keep...
term% rm abc*
# watch the rio window go bye bye!
it used to be that path elements on the file server were limited
to 26 non-space characters. if you're running ken, that limit
is typically 56 characters. but fileservers (e.g. ramfs) are free
to choose any limit they wish.
i think fgb's fix is a good band-aid. but we need to
be flexible and handle arbitrary sized file names.
i'm applying this. i goto Again because i don't want
to break the rest of the glob.
; diffy -c plan9.c
/n/dump/2011/0201/sys/src/cmd/rc/plan9.c:443,448 - plan9.c:443,449
int
Readdir(int f, void *p, int onlydirs)
{
+ char *s;
int n;
if(f0 || f=NFD)
/n/dump/2011/0201/sys/src/cmd/rc/plan9.c:465,472 - plan9.c:466,478
}
if(dir[f].i == dir[f].n)
return 0;
- strcpy(p, dir[f].dbuf[dir[f].i].name);
+ s = dir[f].dbuf[dir[f].i].name;
dir[f].i++;
+ if(strlen(s) = NDIR){
+ pfmt(err, rc: file name too long: %s\n, s);
+ goto Again;
+ }
+ strcpy(p, s);
return 1;
}
- erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
least for me). Then I don't have to worry about whether I screwed up a file system setup: that's what distributed repos are for. hg isn't a filesystem. - erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
http://www.ueber.net/code/r/hgfs ? I'm sure its not the only one On Tue, Feb 1, 2011 at 8:49 AM, erik quanstrom quans...@labs.coraid.com wrote: least for me). Then I don't have to worry about whether I screwed up a file system setup: that's what distributed repos are for. hg isn't a filesystem. - erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
On Tue Feb 1 10:01:54 EST 2011, eri...@gmail.com wrote: http://www.ueber.net/code/r/hgfs ? I'm sure its not the only one but it is quite distinct in concept from a cwfs no? - erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
doesn't mean its not a file system -- nothing saying such things can't be layered. On Tue, Feb 1, 2011 at 9:18 AM, erik quanstrom quans...@labs.coraid.com wrote: On Tue Feb 1 10:01:54 EST 2011, eri...@gmail.com wrote: http://www.ueber.net/code/r/hgfs ? I'm sure its not the only one but it is quite distinct in concept from a cwfs no? - erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
On Tue Feb 1 10:40:33 EST 2011, eri...@gmail.com wrote: doesn't mean its not a file system -- nothing saying such things can't be layered. hg itself is not a file system, and i would imagine if one layered hgfs on top, one would either need to manually trigger dumps, or one wouldn't want to live directly on hgfs. - erik
[9fans] EagleTec ET-LE100BT2 PCMCIA NIC not identified by Plan9
Hi, I'm a new kid on the block, I installed Plan9 on my TP A21e today. It lacks a built-in network card so I use a PCMCIA card in it. The card was not recognized by installer but quintile figured out (many thanks!) that is based on NS8390 which is supported by Plan9. Can somebody help me to make this thing work? Best wishes, johnny_b
Re: [9fans] RESOLVED: recoving important header file rudely
The docs I've read seem to suggest that gcc is kind of glued onto the side of Plan 9 proper. it's kind of unglued off the side of Plan 9 proper: gcc came unstuck (in more ways than one). i'm afraid it's harder to port (or do i mean compile?) than it ever was. and then there's glibc, which you'll certainly also need ... something must be done! (and that's certainly a lot of something.)
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
Then set up a repo on a free place like bitbucket. or github. wasn't that in the news lately?
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
On Tue, Feb 1, 2011 at 9:45 AM, erik quanstrom quans...@labs.coraid.com wrote: On Tue Feb 1 10:40:33 EST 2011, eri...@gmail.com wrote: doesn't mean its not a file system -- nothing saying such things can't be layered. hg itself is not a file system, and i would imagine if one layered hgfs on top, one would either need to manually trigger dumps, or one wouldn't want to live directly on hgfs. Is fossil not a file system if it doesn't maintain a disk cache and only dumps to venti? Perhaps our disagreement would be solved by saying that its not a disk file system. Don't you oppress me we with narrow minded views of what a file system is and isn't. Queue brzr saying sometimes a file system is just a file systemexcept when its not. Anyone have any cigars? -eric
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
Is fossil not a file system if it doesn't maintain a disk cache and only dumps to venti? Perhaps our disagreement would be solved by saying that its not a disk file system. Don't you oppress me we with narrow minded views of what a file system is and isn't. my narrow views? perhaps you've forgotten the op's statement which was hg fixes file system system install problems. i don't see how this can be the case unless you make hg into some sort of dump. or have we gone completely context insensitive to increase the flame potential of the list? - erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
On Tue, Feb 1, 2011 at 6:49 AM, erik quanstrom quans...@labs.coraid.com wrote: least for me). Then I don't have to worry about whether I screwed up a file system setup: that's what distributed repos are for. hg isn't a filesystem. hg is not a lot of things. It is one thing, however, and the thing it is is extremely useful to me. So what's the point of this discussion again? Oh, right, we're showing Smiley that we don't even agree with each other much of the time :-) ron
Re: [9fans] Cute plan9/inferno client?
On 28 Jan 2011, at 1:36 pm, erik quanstrom wrote: if you want to be a cynic, a non-pluggable architecture is super for hardware companies. they can segment the heck out of the market and get to the bad old says of charging big bucks for little extra features. since there's no way to add them yourselves. there goes my worldview. ;) i had been thinking integrated solutions were the way to go because they can be so much simpler but i had forgotten about this possibility. thanks for the reminder. come to think of it, it's not just a matter of the hardware companies being able to charge big bucks for extra features. it can also take a lot of work to add a little extra to a non-pluggable design.
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
On Tue, Feb 1, 2011 at 8:45 AM, erik quanstrom quans...@quanstro.net wrote: Is fossil not a file system if it doesn't maintain a disk cache and only dumps to venti? Perhaps our disagreement would be solved by saying that its not a disk file system. Don't you oppress me we with narrow minded views of what a file system is and isn't. my narrow views? perhaps you've forgotten the op's statement which was hg fixes file system system install problems. relax. It's Eric's sense of humor. He even spells his name wrong. I was not trying to say hg fixes file system install problems. I was trying to say that if one uses hg, one is less sensitive to lack of a dump file system, because lost files are not really an issue if you've to a repo somewhere holding that file you just trashed. Two means, one end: don't lose that .h file! ron
Re: [9fans] ARM based terminal?
On 27 Jan 2011, at 8:50 pm, Nick LaForge wrote: I mean 'Pandaboard'. On 1/27/11, Nick LaForge nicklafo...@gmail.com wrote: A9 based SoCs do 1080p, and you can try one out by getting a Pandoraboard. heh, speaking of the pandora[1] has anyone looked at it with an eye to getting plan 9 on it? It's pocket sized with a fair-sized display, 600MHz omap 3530, 256MB ram, wifi, bluetooth, etc. [1]: http://openpandora.org/
Re: [9fans] RESOLVED: recoving important header file rudely
On Feb 1, 2011 1:05 AM, smi...@zenzebra.mv.com wrote:
Reading about Plan 9, I was quite excited to install it. I was quite
excited when I first booted and ran it, too. But I distinctly felt my
heart sink a little the first time it hung. Since then, I've browsed
some of the OS source code and, having done that, I came to understand
why the system was so buggy. The core applications appear to be written
in a style of C programming reminiscent of the dawn of UNIX. While the
operating system architecture is BEAUTIFULLY designed (with the
exception, perhaps of that fossil/conf gotcha!), the C code used to
implement it doesn't seem to take advantage of any of the programming
paradigms that have emerged in the intervening 30 years...
What hasn't plan 9 adopted that would make it a better system? OOP? Plan 9
adopted (afaik) things like concurrency before other mainstream systems.
Plan 9's namespaces are still unique to the system, and the way most things
are represented as a fileserver is something very unique to plan 9/inferno.
What programming paradigms do you think plan 9 shoul
take advantage of?
Getting Plan 9 code to crash is almost too easy:
term% mkdir trashdir cd trashdir mkdir x
term% touch `{i=0; while (test $i -lt 128) { echo -n abcdefghijklmnop;
i=`{echo $i+1|hoc} } }
term% cp abc* abc* x
# watch the cp executable suicide
# now, make SURE there's nothing in this rio window that you want to
keep...
term% rm abc*
# watch the rio window go bye bye!
Yes, plan 9's file name length can be a bit 'short' in some cases. The
example you gave is a bit extreme, as fgb showed. When and why would you
need a filename/path that long?
[9fans] upas/fs still modifying gmail inbox after window closed
in plan 9: using upas/fs, i mounted my gmail inbox over imap, then started acme. at some point, the acme window disappeared. newly received messages in my gmail inbox continue to get marked as read shortly after they arrive. my assumption is that upas/fs is still accessing the mailbox. how can i prove (or disprove) this, and stop it from happening? -sl
Re: [9fans] upas/fs still modifying gmail inbox after window closed
On Tue Feb 1 12:32:34 EST 2011, stanley.lie...@gmail.com wrote: in plan 9: using upas/fs, i mounted my gmail inbox over imap, then started acme. at some point, the acme window disappeared. newly received messages in my gmail inbox continue to get marked as read shortly after they arrive. my assumption is that upas/fs is still accessing the mailbox. how can i prove (or disprove) this, and stop it from happening? echo close mbox /mail/fs/ctl i don't know if nupas handles this correctly or not. but i seem to recall that it does. it's a matter of issuing the right imap command when you're fetching the message body for internal use, rather than for viewing. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
ron minnich rminn...@gmail.com writes:
term% cp abc* abc* x
# watch the cp executable suicide
# now, make SURE there's nothing in this rio window that you want to keep...
term% rm abc*
# watch the rio window go bye bye!
it's not cp and it's not rio. I think you need to diagnose this a bit
better. If you look a bit more at it I think you'll see what's going
on.
I know the cp suicide is a problem in cp, because I designed the test
case to exercise a buffer overflow I found at /sys/src/cmd/cp.c:77,93
void
copy(char *from, char *to, int todir)
{
Dir *dirb, dirt;
char name[256];
int fdf, fdt, mode;
if(todir){
char *s, *elem;
elem=s=from;
while(*s++)
if(s[-1]=='/')
elem=s;
sprint(name, %s/%s, to, elem);
to=name;
}
The bug in rc's globbing was just a fun bonus I discovered while
trying to clean up after the cp test. :)
but I have to wonder if you've been inside glibc lately. I don't think
Agreed. glibc has become quite ugly.
There are other, very good paradigms that the code does use, such as
lock-free threads.
Threads are one great paradigm that Plan 9 adopted. Native UTF-8 is
another. However, the Plan 9 code (at last that under /sys/src/cmd)
doesn't seem to make use of iterators, string objects (or even
object-orientation), modern string parsing routines, etc. All of these
programming techniques can free the programmer from having to think
about byte-level boundary conditions and focus on the higher-level
operation of the code. Having to tend to such details over and over
again leads to lots of missed boundary conditions (like in cp.c and
plan9.c), application instability, and security vulnerabilities
(remember the factotum exploit?)
It's probably worth noting that higher-level code abstractions are
probably more useful in userspace code than in the kernel. This is
partly for reasons of performance, and partly because the kernel is so
much closer to the hardware. The Linux kernel, for example, is still
largely written in old UNIX-style C. It wasn't even until series 2.5 or
so that the Linux kernel became palpably object-oriented.
The common problem is that people come to Plan 9 and view it through
the prism of their experiences with other systems such as Linux.
Yes, I am familiar with the notion that the Plan 9 way is very different
from other ways, such as the Linux way. One of the things that I enjoy
about Plan 9 is that it makes me feel naive again. :)
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---+
Re: [9fans] RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 9:51 AM, smi...@zenzebra.mv.com wrote: However, the Plan 9 code (at last that under /sys/src/cmd) doesn't seem to make use of iterators, string objects (or even object-orientation), modern string parsing routines, etc. There's a reason it does not use that stuff, and it may not be what you think. That said, why are you thinking in terms of writing in C anyway? If you're going to put a lot of work out, why not use a modern language in which strings are actually a first class object, that has garbage collection, and so on? I don't see how macro foo is going to make things all that much better. You're still stuck with C. It's probably worth noting that higher-level code abstractions are probably more useful in userspace code than in the kernel. This is partly for reasons of performance, and partly because the kernel is so much closer to the hardware. The Linux kernel, for example, is still largely written in old UNIX-style C. It wasn't even until series 2.5 or so that the Linux kernel became palpably object-oriented. Actually, Plan 9 kernel is palpably object-oriented in a very real sense, if you consider the whole. The plan 9 devices and servers are all accessed via a common interface, and kernel and user objects can be interchanged -- consider that one can put a custom IP stack in place just by mounting on /net. I've worked with object oriented operating systems written in C++ that were far less object oriented than Plan 9. Over the years I've come to believe that whether a system is object-oriented does not always depend on the language it is written in. In fact given some of the C++ code I've had to work with I almost wonder if it's not an inverse relationship ... thanks ron p.s. If you're going to rewrite /bin, maybe it's time to look at Go?
Re: [9fans] upas/fs still modifying gmail inbox after window closed
On Tue, Feb 1, 2011 at 11:52 AM, erik quanstrom quans...@quanstro.net wrote: On Tue Feb 1 12:32:34 EST 2011, stanley.lie...@gmail.com wrote: in plan 9: using upas/fs, i mounted my gmail inbox over imap, then started acme. at some point, the acme window disappeared. newly received messages in my gmail inbox continue to get marked as read shortly after they arrive. my assumption is that upas/fs is still accessing the mailbox. how can i prove (or disprove) this, and stop it from happening? echo close mbox /mail/fs/ctl i don't know if nupas handles this correctly or not. but i seem to recall that it does. it's a matter of issuing the right imap command when you're fetching the message body for internal use, rather than for viewing. should this work even when my namespace doesn't reflect the gmail mount? the rio window where i started upas/fs died and disappeared (note: without my intervention) sometime last night. i can't find any trace of the gmail messages on my system. i sent the command above, but messages in my gmail inbox are still getting marked as read a few seconds after they arrive. in the future i'll try nupas. thanks, -sl
Re: [9fans] RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 10:33 AM, ron minnich rminn...@gmail.com wrote: p.s. If you're going to rewrite /bin, maybe it's time to look at Go? I've written a few unix-style programs in Go: http://code.google.com/p/mango-doc/ http://code.google.com/p/simple-shell-utils/ (neither are exactly examples of my best-foot-forward coding, both need to be cleaned up and could be made clearer by utilizing more of the Go standard library) It's in many ways the perfect language for this sort of thing. It's almost like its creators had some sort of expertise in this area :)
Re: [9fans] ARM based terminal?
Dyslexia and confirmation bias. Wikipedia says I have source amnesia. I do remember reading about the thing, but only that. However nice it may be, I can't justify buying yet another N900-parity SBC. Nick On 2/1/11, Ethan Grammatikidis eeke...@fastmail.fm wrote: On 27 Jan 2011, at 8:50 pm, Nick LaForge wrote: I mean 'Pandaboard'. On 1/27/11, Nick LaForge nicklafo...@gmail.com wrote: A9 based SoCs do 1080p, and you can try one out by getting a Pandoraboard. heh, speaking of the pandora[1] has anyone looked at it with an eye to getting plan 9 on it? It's pocket sized with a fair-sized display, 600MHz omap 3530, 256MB ram, wifi, bluetooth, etc. [1]: http://openpandora.org/
Re: [9fans] Cute plan9/inferno client?
i can get as many nics or sata ports as i wish. i can plug as much memory in as i want. Really? You can upgrade more easily, but there are still limits. Instead of upgrading S-ATA interfaces, CPUs and RAM, I can plug more SOCs into my switch. I agree that this is not a very economic option yet, but it's an old, ongoing trend as I see it. In the end I only want Gigabit Ethernet, S-ATA, DVI and USB. Lets see what other pc buses the future brings. Did I miss anything?
Re: [9fans] Cute plan9/inferno client?
Instead of upgrading S-ATA interfaces, CPUs and RAM, I can plug more SOCs into my switch. I agree that this is not a very economic option yet, but it's an old, ongoing trend as I see it. yes, people have been doing this with pcs (in 1u/2u/3u boxes) for so long that all the parts are standardized. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
ron minnich rminn...@gmail.com writes: However, the Plan 9 code (at last that under /sys/src/cmd) doesn't seem to make use of iterators, string objects (or even object-orientation), modern string parsing routines, etc. There's a reason it does not use that stuff, and it may not be what you think. OK, come on already, quit teasing me! :) What's the secret reason? That said, why are you thinking in terms of writing in C anyway? Because Plan 9 only has a C compiler? I don't see how macro foo is going to make things all that much better. You're still stuck with C. Yes, but C macros can be used to approximate higher-level language constructs such as objects, iterators (Java style or Ruby style, though I'm focusing only on the latter), throw/catch clauses, and so on. Actually, Plan 9 kernel is palpably object-oriented in a very real sense, if you consider the whole. The plan 9 devices and servers are I'll first repeat a previous comment of mine for purposes of disclaimer: I haven't even LOOKED at ANY of the Plan 9 kernel code, yet... Architecturally, the Plan 9 operating system appears to be leading-edge, modern, elegant, and generally kick-ass. How that architecture is IMPLEMENTED, however, is an entirely different story. The wonderfully modern architecture of the OS looks like it's been implemented using wonderfully ancient methods. BTW, I should mention how I impressed I am by the quality of the discussion on this list. There are obviously a lot of smart people on this OS. :) -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 4:28 PM, smi...@zenzebra.mv.com wrote: ron minnich rminn...@gmail.com writes: There's a reason it does not use that stuff, and it may not be what you think. OK, come on already, quit teasing me! :) What's the secret reason? I don't think it's a secret. There is a not very small group of people who find all the things you mentioned unsatisfying in both an esthetic and practical sense, especially when implemented in the manner of C++, particularly the STL. Hence, I am not surprised that nobody in this community has rushed to add them. It's not like people here don't know about them. Rather, it is that those who might have brought those ideas in have likely considered and rejected them. That said, why are you thinking in terms of writing in C anyway? Because Plan 9 only has a C compiler? I think you should set your sights higher than the macro approach you propose. At least in my opinion it's a really ugly idea. You could make a lasting contribution by bringing a good modern language to Plan 9. I'll say it again, I don't think a cpp-based approach will be well received in this community, and for good reason. A Go port? Well, that's another story. Or even native Limbo, that one is frequently requested. good luck. ron
Re: [9fans] RESOLVED: recoving important header file rudely
There's a reason it does not use that stuff, and it may not be what you think. OK, come on already, quit teasing me! :) What's the secret reason? when ron says this it's almost always a formula that means that it was not done out of ignorance, stogginess, etc. as oo proponents tend to assume. odd but true fact: not everyone agrees that oo trappings are uniformly a good idea. anyway, oo was know about, just not used. Yes, but C macros can be used to approximate higher-level language constructs such as objects, iterators (Java style or Ruby style, though I'm focusing only on the latter), throw/catch clauses, and so on. s.r.bourne would agree! (c'mon smile.) i'm not convinced that throw/catch is a good idea to emulate. it's very hard to get right. goto is a like a pet bunny; throw is like a pet bunny on the loose. with t-t-teeth. i think you'll have more success with plan 9 if you don't try to pound it into a ruby-sized hole. - erik
Re: [9fans] HELP: recoving important header file rudely clobbered by mk
Two means, one end: don't lose that .h file! I'm still waiting to see that crazy mkfile... -- Federico G. Benavento
Re: [9fans] RESOLVED: recoving important header file rudely
I know the cp suicide is a problem in cp, because I designed the test
case to exercise a buffer overflow I found at /sys/src/cmd/cp.c:77,93
void
copy(char *from, char *to, int todir)
{
Dir *dirb, dirt;
char name[256];
int fdf, fdt, mode;
if(todir){
char *s, *elem;
elem=s=from;
while(*s++)
if(s[-1]=='/')
elem=s;
sprint(name, %s/%s, to, elem);
to=name;
}
The bug in rc's globbing was just a fun bonus I discovered while
trying to clean up after the cp test. :)
I take it was trivial to find that overflow, come on the code is so simple
that you just see and get it the first time, which makes easier to find/fix
bugs, iterators and the other crap you mentioned would had obfuscated it.
now you found a related bug in rc, if I ever get to write code as beautiful
as rc that will be a day to remember.
Plan 9 is not bug-free, but they easier to find and fix, think about that.
--
Federico G. Benavento
[9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
ron minnich rminn...@gmail.com writes: I think you should set your sights higher than the macro approach you propose. At least in my opinion it's a really ugly idea. You might be surprised to hear that I agree. :) It's far from an ideal solution. I am certainly open to alternatives! You could make a lasting contribution by bringing a good modern language to Plan 9. Maybe. My first criterion for such a language would be that it compile to native machine code. Although requiring such may be presumptive, it seems appropriate that the core OS applications (file servers, command line utilities, etc.) be in native machine code. On the other hand, on Inferno, Limbo compiles to architecture-independent bytecode, eliminating the need for the /$objtype directories on Plan 9, while enabling easier sharing of object code. What are all your thoughts' on this compiled vs interpreted design decision? The Go language (from Google? sigh. Evil, evil.) appears to compile to native machine code. The Go web site (http://golang.org), however, claims that Go requires a small runtime... which causes me to wonder just how fully compiled it is. Anyone know the scoop on what this runtime is all about? Go is also a garbage-collected language. I'm also a bit leery of using a GC language for coding core OS applications. I've generally thought of GC as being for lazy programmers (/me runs and hides under his desk, peeks out...) and incurring somewhat of a performance hit. I'm not sure if that would be appropriate for core applications. Then again, it seems to be what's done on Inferno. Thoughts on this? Wikipedia says that Go doesn't support safe concurrency. However, the Go web site claims that goroutines (which are kinda like threads) coordinate through explicit synchronization. Isn't that how the Plan 9 threading library works, too? I'm not sure why the Wikipedia article would make a claim like that. Thoughts on the relative merits of concurrency in Go vs Plan 9 C would also be welcome. On an implementation note, it sounds like Go can be bootstrapped from C, with a little bit of assembly. It might not be so monumental a task to port Go to Plan 9, though I would hesitate to use ANY code written by Google without a thorough audit. I'll say it again, I don't think a cpp-based approach will be well Did you mean what you wrote, cpp or did you mean C++? Or even native Limbo, that one is frequently requested. Can Libmo be compiled to native machine code? There was some mention that, during the history of Plan 9, developers had difficulty maintaining two different languages on the system. I wonder how much of that difficulty would still apply today. Although the kernel could concievably be translated to a modern compiled language, I doubt it could be written in Go. If Go were used, then, there would still have to be two languages/compilers/development environments on the system. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On 02/02/2011 12:14 AM, smi...@zenzebra.mv.com wrote: [...] though I would hesitate to use ANY code written by Google without a thorough audit. This is where I point out that GO isn't so much written by Google, as more it's written by Rob Pike and Ken Thompson who now work at Google. -- Scott Sullivan
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 02 Feb 2011 05:14:54 +, smi...@zenzebra.mv.com wrote: Can Libmo be compiled to native machine code? There was some mention that, during the history of Plan 9, developers had difficulty maintaining two different languages on the system. I wonder how much of that difficulty would still apply today. Although the kernel could concievably be translated to a modern compiled language, I doubt it could be written in Go. If Go were used, then, there would still have to be two languages/compilers/development environments on the system. along those lines, can a Libmo byte code be used as an intermediate language and be compiles/assembled into machine code instead of interpreted? EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
And russ cox, and everyone else in the CONTRIBUTORS file. On Feb 2, 2011 12:39 AM, Scott Sullivan sc...@ss.org wrote:
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
Actually, I think we've talked quite enough at this point, perhaps it's time to take a break and let's see some concrete work. Where's the mkfile that broke your .h? What do your macros look like? What are you going to do? I'll retire from the thread now. Just remember, Smiley, it's a good idea not to come across too much like a missionary bringing knowledge to the ignorant heathens -- which is certainly a bit of the tone of your notes. Missionaries, at least according to the cartoons, sometimes are invited to dinner, and other times are invited to BE dinner. :-) So, let's see it. ron
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, 01 Feb 2011 23:06:33 PST ron minnich rminn...@gmail.com wrote: Just remember, Smiley, it's a good idea not to come across too much like a missionary bringing knowledge to the ignorant heathens -- which is certainly a bit of the tone of your notes. Missionaries, at least according to the cartoons, sometimes are invited to dinner, and other times are invited to BE dinner. :-) More Smiley (as played by Alec Guinness) and less Bond?
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 01, 2011 at 11:06:33PM -0800, ron minnich wrote: Missionaries, at least according to the cartoons, sometimes are invited to dinner, and other times are invited to BE dinner. :-) And they often are fatter than sacred cows :-) ++L
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
I hope it won't seem rude to suggest it, but the go-nuts list is the optimum place for your specific concerns. The Go authors read it and are very conscientious in responding to serious questions. The Go authors did express confidence that GC performance could eventually be made competitive, although I couldn't tell you whether that has yet happened. I would nevertheless keep in mind that they are experienced professionals (c.f. Inferno) and that you'd be wrong to malign GC categorically based on your experiences with the proliferation of various toy languages on the net. (I won't mention names.) If you want a modern C++ or some other heavyweight language on Plan 9, I'll point out that there was some talk in August about a LLVM port, though you'll be hard pressed to find many here that desire it above Go. Nick On 2/2/11, Jacob Todd jaketodd...@gmail.com wrote: And russ cox, and everyone else in the CONTRIBUTORS file. On Feb 2, 2011 12:39 AM, Scott Sullivan sc...@ss.org wrote:
