* [9fans] HELP: recoving important header file rudely clobbered by mk @ 2011-01-29 22:47 smiley 2011-01-29 22:54 ` erik quanstrom ` (4 more replies) 0 siblings, 5 replies; 192+ messages in thread From: smiley @ 2011-01-29 22:47 UTC (permalink / raw) To: 9fans I'm REALLY hoping someone can help me with this... For some reason, mk decided it would be fun to run the following command for me: 8l $LDFLAGS -o important.h important.h.8 Of course, this overwrote important.h, a file containing C macros I spent all day writing. I tried mounting dump, but get an error saying that archive/main doesn't exist. Fortunately, there's a magic string in important.h (that exists only in important.h) that I could use to find the file on /dev/sdC0/fossil. But Plan 9's grep doesn't seem to support the context switches -A, -B, or -C. There also doesn't appear to be a hexdup, od, or a pager capable of performing searches. What would be the equivalent to a context grep on Plan 9? Or else, how might I recover the text surrounding my magic string? Any help would be greatly appreciated! (I'm also wondering why mk decided to try to update my header file with the loader(??)... but that's a less important matter ATM.) ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-29 22:47 [9fans] HELP: recoving important header file rudely clobbered by mk smiley @ 2011-01-29 22:54 ` erik quanstrom 2011-01-29 22:58 ` Steve Simon ` (3 subsequent siblings) 4 siblings, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-01-29 22:54 UTC (permalink / raw) To: 9fans > For some reason, mk decided it would be fun to run the following command > for me: > > 8l $LDFLAGS -o important.h important.h.8 sounds like important.h was the target and a rule like this was chosen: %: %.$O $CC $CFLAGS $stem $stem.$O > Fortunately, there's a magic string in important.h (that exists only in > important.h) that I could use to find the file on /dev/sdC0/fossil. But > Plan 9's grep doesn't seem to support the context switches -A, -B, or > -C. There also doesn't appear to be a hexdup, od, or a pager capable of > performing searches. > > What would be the equivalent to a context grep on Plan 9? Or else, how > might I recover the text surrounding my magic string? strings will give you byte addresses, grep will zero in on your magic string. dd can give you a big block surrounding your magic string. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-29 22:47 [9fans] HELP: recoving important header file rudely clobbered by mk smiley 2011-01-29 22:54 ` erik quanstrom @ 2011-01-29 22:58 ` Steve Simon 2011-01-30 1:16 ` smiley 2011-01-29 23:24 ` [9fans] RESOLVED: " smiley ` (2 subsequent siblings) 4 siblings, 1 reply; 192+ messages in thread From: Steve Simon @ 2011-01-29 22:58 UTC (permalink / raw) To: 9fans sorry this happened to you. is this native plan9, p9p, or 9vx? so, are you using fossil or do you run cwfs or kfs or somthing else? do you definitely have fossil and venti running? a missing archive/main looks like you don't have archival dumps enabled in fossil.conf? perhaps you have snapshots enabled? what happens if you run 9fs snap? Here is an implementation of context grep, I think its erik's code but I cannot remember. #!/bin/rc # cgrep - context grep # NB: /dev/null in list of files to force printing source # files when there is just one file supplied grep -n $* /dev/null | sed 's/^(.*):([0-9]*): .*$/\1 \2/' | while(loc=`{read}){ echo $loc(1)^:$loc(2) start=`{echo 'if(' $loc(2) ' > 2) print(' $loc(2) ' - 2) else print 0' | hoc} tail -n +^$start $loc(1) | sed 's/^/ /; 6q' } -Steve ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-29 22:58 ` Steve Simon @ 2011-01-30 1:16 ` smiley 2011-01-30 4:07 ` John Floren 0 siblings, 1 reply; 192+ messages in thread From: smiley @ 2011-01-30 1:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "Steve Simon" <steve@quintile.net> writes: > is this native plan9, p9p, or 9vx? I'm running the stock 386 distribution, on a real hard drive on real hardware. I figured learning a new OS would be simpler without having to think about what's virtual versus what's real, versus what's Linux. > do you definitely have fossil and venti running? I have no idea. I just chose the default installation options, installing from the CD following the install instructions. As far as I know, "Venti" is a volcano in Italy. > a missing archive/main looks like you don't > have archival dumps enabled in fossil.conf? Oops, s|archive/main|main/archive| > perhaps you have snapshots enabled? I know I have "fossil". I didn't know "dump" and "snapshots" were two different things. Are there any docs that describe these file systems in language a newbie has a snowball's chance in Inferno of understanding? The man pages for Plan 9 file systems all seem rather opaque... i.e., "cached-worm file system"? > what happens if you run 9fs snap? The mount succeeds, but /n/snap is empty. > Here is an implementation of context grep, > I think its erik's code but I cannot remember. LOL. That's classic. I will try and decipher it. (To all of you,) thanks for all the help! ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-30 1:16 ` smiley @ 2011-01-30 4:07 ` John Floren 2011-01-30 4:49 ` erik quanstrom 2011-02-01 6:22 ` smiley 0 siblings, 2 replies; 192+ messages in thread From: John Floren @ 2011-01-30 4:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, Jan 29, 2011 at 5:16 PM, <smiley@zenzebra.mv.com> wrote: > "Steve Simon" <steve@quintile.net> writes: > >> is this native plan9, p9p, or 9vx? > > I'm running the stock 386 distribution, on a real hard drive on real > hardware. I figured learning a new OS would be simpler without having > to think about what's virtual versus what's real, versus what's Linux. > >> do you definitely have fossil and venti running? > > I have no idea. I just chose the default installation options, > installing from the CD following the install instructions. As far as I > know, "Venti" is a volcano in Italy. > In that case, you'll only have Fossil installed. >> a missing archive/main looks like you don't >> have archival dumps enabled in fossil.conf? > > Oops, s|archive/main|main/archive| > >> perhaps you have snapshots enabled? > > I know I have "fossil". I didn't know "dump" and "snapshots" were two > different things. Are there any docs that describe these file systems > in language a newbie has a snowball's chance in Inferno of > understanding? The man pages for Plan 9 file systems all seem rather > opaque... i.e., "cached-worm file system"? > Fossil is the "front-end" filesystem. You can run it alone. It can be configured to take snapshots at regular intervals (I like every 15 minutes, check the fossilcons man page for how to set it up) which eventually (typically after a few days) expire and are cleared. Venti is the archival storage; if Venti is present, Fossil will try to make an archival dump to Venti every morning. The dump is basically a snapshot, except it's permanent. One side effect is that when a dump happens, data on Fossil gets replaced with a pointer to a block in Venti, clearing up your Fossil partition. For that reason, I typically only allocate a few gigabytes to Fossil and all the rest of the disk to Venti. The cached-worm filesystem, cwfs, is related to the old filesystem. The same goes for "fs" (in many cases, for example the man page fs(4)), "cwfs", "worm", "kfs", or "kenfs". Erik Quanstrom still uses kenfs, and based on his positive experiences with it some others have been experimenting with it as well. However, kenfs requires its own dedicated machine and is a bit tougher to set up. I've continually meant to write some sort of beginners-level summary of the system including things like Fossil and Venti, but the magnitude of the task is daunting. I may try to do a more clear description of how the filesystems work together in the near future. >> what happens if you run 9fs snap? > > The mount succeeds, but /n/snap is empty. > I don't remember for sure, but it's possible that Fossil doesn't get configured to take snapshots when Venti isn't installed, for space reasons. If you can run "fossil/conf /dev/sdC0/fossil" and post the results here, we'll be able to tell, or you can run the command and examine the results for yourself based on the fossilcons man page. If you haven't spent too much time configuring your system, or put too much on it that cannot be backed up, and if you have a large enough disk (20 GB should be plenty unless you're storing large files or music/video), you might want to try re-installing and choosing the fossil+venti option. This will give you the archival dump storage, which can be really nice. John ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-30 4:07 ` John Floren @ 2011-01-30 4:49 ` erik quanstrom 2011-01-30 4:56 ` John Floren 2011-02-01 6:22 ` smiley 1 sibling, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-01-30 4:49 UTC (permalink / raw) To: 9fans > > I have no idea. I just chose the default installation options, > > installing from the CD following the install instructions. As far as I > > know, "Venti" is a volcano in Italy. > > > > In that case, you'll only have Fossil installed. and here i thought that venti was a swimming pool of rather bland coffee. ☺ just for clarity, it's possible to install from cd with either fossil or fossil+venti. i'd recommend against a fossil+venti install unless you can give clean shutdowns more than just a good college try. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-30 4:49 ` erik quanstrom @ 2011-01-30 4:56 ` John Floren 0 siblings, 0 replies; 192+ messages in thread From: John Floren @ 2011-01-30 4:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, Jan 29, 2011 at 8:49 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> > I have no idea. I just chose the default installation options, >> > installing from the CD following the install instructions. As far as I >> > know, "Venti" is a volcano in Italy. >> > >> >> In that case, you'll only have Fossil installed. > > and here i thought that venti was a swimming pool of > rather bland coffee. ☺ > > just for clarity, it's possible to install from cd with either > fossil or fossil+venti. i'd recommend against a fossil+venti > install unless you can give clean shutdowns more than just a > good college try. > > - erik > > That is definitely a consideration. For instance, I've found that Fossil wants to dump to Venti in the first boot after installation; if you should reboot before it's done, you can easily end up with a corrupted filesystem. This has happened to me several times, usually because I install and then immediately begin setting up the system as a cpu/auth/file server... which requires rebooting after a few minutes of configuration changes. Oh, and if you don't have DMA on, your Venti dumps will take hours. I found that after ripping a few CDs, the 4 a.m. scheduled dump would still be going on at noon. "echo dma on > /dev/sdC0/ctl" will take care of that, put it in your termrc/cpurc to enable it at every boot. John ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-30 4:07 ` John Floren 2011-01-30 4:49 ` erik quanstrom @ 2011-02-01 6:22 ` smiley 2011-02-01 6:47 ` Federico G. Benavento 1 sibling, 1 reply; 192+ messages in thread From: smiley @ 2011-02-01 6:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs John Floren <john@jfloren.net> writes: > I've continually meant to write some sort of beginners-level summary > of the system including things like Fossil and Venti, but the > magnitude of the task is daunting. I may try to do a more clear > description of how the filesystems work together in the near future. I've been writing a guide to Plan 9 for UNIX users, hilighting the differences between Plan 9 and UNIX needed to get UNIX users up to speed on Plan 9. I shudder to think how much work it would take to write a guide for complete newbies (without a UNIX background). A description how the filesystems interact would be awesome! As far as system administration goes, this appears to be one of the areas in which the difference P9 and UNIX is most confusing. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 6:22 ` smiley @ 2011-02-01 6:47 ` Federico G. Benavento 2011-02-01 6:54 ` John Floren 0 siblings, 1 reply; 192+ messages in thread From: Federico G. Benavento @ 2011-02-01 6:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs have you checked the wiki? http://www.plan9.bell-labs.com/wiki/plan9/Documentation/ there are tons of articles on Using this or that, a recommended readings section and even a "UNIX to Plan 9 command translation." there's also: http://www.quanstro.net/newbie-guide.pdf On Tue, Feb 1, 2011 at 3:22 AM, <smiley@zenzebra.mv.com> wrote: > John Floren <john@jfloren.net> writes: > >> I've continually meant to write some sort of beginners-level summary >> of the system including things like Fossil and Venti, but the >> magnitude of the task is daunting. I may try to do a more clear >> description of how the filesystems work together in the near future. > > I've been writing a guide to Plan 9 for UNIX users, hilighting the > differences between Plan 9 and UNIX needed to get UNIX users up to speed > on Plan 9. I shudder to think how much work it would take to write a > guide for complete newbies (without a UNIX background). > > A description how the filesystems interact would be awesome! As far as > system administration goes, this appears to be one of the areas in which > the difference P9 and UNIX is most confusing. > > -- > +---------------------------------------------------------------+ > |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---------------------------------------------------------------+ > > -- Federico G. Benavento ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 6:47 ` Federico G. Benavento @ 2011-02-01 6:54 ` John Floren 0 siblings, 0 replies; 192+ messages in thread From: John Floren @ 2011-02-01 6:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Writing a newbie guide is a newbie rite of passage :) John On Mon, Jan 31, 2011 at 10:47 PM, Federico G. Benavento <benavento@gmail.com> wrote: > have you checked the wiki? > > http://www.plan9.bell-labs.com/wiki/plan9/Documentation/ > > there are tons of articles on Using this or that, a recommended > readings section and even a "UNIX to Plan 9 command translation." > > there's also: > > http://www.quanstro.net/newbie-guide.pdf > > On Tue, Feb 1, 2011 at 3:22 AM, <smiley@zenzebra.mv.com> wrote: >> John Floren <john@jfloren.net> writes: >> >>> I've continually meant to write some sort of beginners-level summary >>> of the system including things like Fossil and Venti, but the >>> magnitude of the task is daunting. I may try to do a more clear >>> description of how the filesystems work together in the near future. >> >> I've been writing a guide to Plan 9 for UNIX users, hilighting the >> differences between Plan 9 and UNIX needed to get UNIX users up to speed >> on Plan 9. I shudder to think how much work it would take to write a >> guide for complete newbies (without a UNIX background). >> >> A description how the filesystems interact would be awesome! As far as >> system administration goes, this appears to be one of the areas in which >> the difference P9 and UNIX is most confusing. >> >> -- >> +---------------------------------------------------------------+ >> |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| >> |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| >> +---------------------------------------------------------------+ >> >> > > > > -- > Federico G. Benavento > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* [9fans] RESOLVED: recoving important header file rudely clobbered by mk 2011-01-29 22:47 [9fans] HELP: recoving important header file rudely clobbered by mk smiley 2011-01-29 22:54 ` erik quanstrom 2011-01-29 22:58 ` Steve Simon @ 2011-01-29 23:24 ` smiley 2011-01-29 23:41 ` Steve Simon 2011-02-01 6:54 ` [9fans] HELP: recoving important header file rudely clobbered by mk ron minnich 2011-02-01 7:01 ` Federico G. Benavento 4 siblings, 1 reply; 192+ messages in thread From: smiley @ 2011-01-29 23:24 UTC (permalink / raw) To: 9fans smiley@zenzebra.mv.com writes: > Of course, this overwrote important.h, a file containing C macros I > spent all day writing. Never mind! I was able to recover the file from Linux: term% aux/listen1 tcp!headache!1234 cat /dev/sdC0/fossil I then used netcat on the Linux end and got the data back. Sigh. I guess now I should be reading up on how to configure that "dump" filesystem... eh? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely clobbered by mk 2011-01-29 23:24 ` [9fans] RESOLVED: " smiley @ 2011-01-29 23:41 ` Steve Simon 2011-01-30 14:19 ` [9fans] RESOLVED: recoving important header file rudely Richard Miller 0 siblings, 1 reply; 192+ messages in thread From: Steve Simon @ 2011-01-29 23:41 UTC (permalink / raw) To: 9fans yep, dump is great. sadly there is a bug in fossil that makes it unreliable if snapshots ar enabled - it locks up once a month or so, dumps work fine though. free beer to the first person to find the fossil deadlock... -Steve ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-01-29 23:41 ` Steve Simon @ 2011-01-30 14:19 ` Richard Miller 2011-01-30 14:28 ` erik quanstrom 2011-01-31 18:02 ` smiley 0 siblings, 2 replies; 192+ messages in thread From: Richard Miller @ 2011-01-30 14:19 UTC (permalink / raw) To: 9fans > sadly there is a bug in fossil that makes it unreliable > if snapshots ar enabled - it locks up once a month or so, > dumps work fine though. YMMV. My fossil has never locked up, but I get a corrupted daily dump two or three times a month. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-01-30 14:19 ` [9fans] RESOLVED: recoving important header file rudely Richard Miller @ 2011-01-30 14:28 ` erik quanstrom 2011-01-31 18:02 ` smiley 1 sibling, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-01-30 14:28 UTC (permalink / raw) To: 9fans On Sun Jan 30 09:20:31 EST 2011, 9fans@hamnavoe.com wrote: > > sadly there is a bug in fossil that makes it unreliable > > if snapshots ar enabled - it locks up once a month or so, > > dumps work fine though. > > YMMV. My fossil has never locked up, but I get a corrupted daily > dump two or three times a month. isn't deadlock or a race condition just computer science jargon for ymmv? - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-01-30 14:19 ` [9fans] RESOLVED: recoving important header file rudely Richard Miller 2011-01-30 14:28 ` erik quanstrom @ 2011-01-31 18:02 ` smiley 2011-01-31 22:12 ` Steve Simon 1 sibling, 1 reply; 192+ messages in thread From: smiley @ 2011-01-31 18:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Richard Miller <9fans@hamnavoe.com> writes: > YMMV. My fossil has never locked up, but I get a corrupted daily > dump two or three times a month. My system/file system locks up periodically, and (as I recently discovered) I don't even appear to have dumps/snapshots enabled. If the system doesn't lock up hard, any command that needs to read from the filesystem (i.e. running any command that's not built into rc) causes the shell to hang uninterruptably. MMDV (My Mileage Does Vary). ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-01-31 18:02 ` smiley @ 2011-01-31 22:12 ` Steve Simon 2011-02-01 6:02 ` smiley 0 siblings, 1 reply; 192+ messages in thread From: Steve Simon @ 2011-01-31 22:12 UTC (permalink / raw) To: 9fans > My system/file system locks up periodically, and (as I recently > discovered) I don't even appear to have dumps/snapshots enabled. If the > system doesn't lock up hard, any command that needs to read from the > filesystem (i.e. running any command that's not built into rc) causes > the shell to hang uninterruptably. MMDV (My Mileage Does Vary). This is the exact scenario I had when I ran fossil + venti with ephemerial snapshots enabled, are you sure you don't have them on? try fossil/conf /dev/sd??/fossil | grep snaptime This is an example of ephemerial snapshots enabled: fsys main snaptime -s 15 -a 0400 -t 3600 and disabled: fsys main snaptime -s none -a 0400 -t none -Steve ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-01-31 22:12 ` Steve Simon @ 2011-02-01 6:02 ` smiley 2011-02-01 6:26 ` Lucio De Re ` (5 more replies) 0 siblings, 6 replies; 192+ messages in thread From: smiley @ 2011-02-01 6:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "Steve Simon" <steve@quintile.net> writes: > This is the exact scenario I had when I ran fossil + venti with ephemerial > snapshots enabled, are you sure you don't have them on? Quite sure. :) That's why I ended up recovering the data from Linux. > fossil/conf /dev/sd??/fossil | grep snaptime I have just two lines: fsys main config, fsys main open. Incidentally, that fossil/conf drove me nuts(!) until I finally discovered it. I tried switching the drive from /dev/sdC1 to /dev/sdC0. I couldn't figure out why it kept insisting on mounting /dev/sdC1 when I changed EVERYTHING in plan9.ini to refer to /dev/sdC0. (Some day, I'll get around to asking why someone thought that hiding the device name on the device itself was a good idea. ??) 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... 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! 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. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:02 ` smiley @ 2011-02-01 6:26 ` Lucio De Re 2011-02-01 7:07 ` smiley 2011-02-01 6:45 ` ron minnich ` (4 subsequent siblings) 5 siblings, 1 reply; 192+ messages in thread From: Lucio De Re @ 2011-02-01 6:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 01, 2011 at 06:02:06AM +0000, smiley@zenzebra.mv.com wrote: > > 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. > Beware of macros, they provide a level of indirection that makes the code really hard to read. I personally have grown to dislike them with a passion when I found the ISDN device driver for Linux considerably easier to follow than the FreeBSD one. Also, you have managed to stomp all over a couple of this mailing list's most sacred cows with your suggestion that the Plan 9 kernel code is less than perfect (some of us may well agree with you, but I'm not amongst those) so _my_ suggestion to you is that you port the code to GCC and do what you like with it there. Chances are that the the changes you want to introduce are going to be incompatible in some or other manner; at least by porting stuff to the most common development base you are targetting an audience that may be interested. ++L ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:26 ` Lucio De Re @ 2011-02-01 7:07 ` smiley 2011-02-01 7:22 ` Lucio De Re ` (2 more replies) 0 siblings, 3 replies; 192+ messages in thread From: smiley @ 2011-02-01 7:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: lucio Lucio De Re <lucio@proxima.alt.za> writes: > Also, you have managed to stomp all over a couple of this mailing list's > most sacred cows with your suggestion that the Plan 9 kernel code is less > than perfect Ooh! No intent to offend. I actually haven't even looked at the kernel code, yet. I was referring to the bits under /sys/src/cmd/. > _my_ suggestion to you is that you port the code to GCC and do what > you like with it there. You mean port the userspace to GCC? Or the kernel? Wouldn't that kind of defeat the intent behind Plan 9's redesigned toolchain? Is gcc even supported enough on Plan 9 for serious work? The docs I've read seem to suggest that gcc is kind of "glued onto the side of" Plan 9 proper. > Chances are that the the changes you want to introduce are going to be > incompatible in some or other manner; 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. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 7:07 ` smiley @ 2011-02-01 7:22 ` Lucio De Re 2011-02-01 13:45 ` erik quanstrom 2011-02-01 16:24 ` Charles Forsyth 2 siblings, 0 replies; 192+ messages in thread From: Lucio De Re @ 2011-02-01 7:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 01, 2011 at 07:07:30AM +0000, smiley@zenzebra.mv.com wrote: > Lucio De Re <lucio@proxima.alt.za> writes: > > > Also, you have managed to stomp all over a couple of this mailing list's > > most sacred cows with your suggestion that the Plan 9 kernel code is less > > than perfect > > Ooh! No intent to offend. I actually haven't even looked at the kernel > code, yet. I was referring to the bits under /sys/src/cmd/. > No offense taken, sacred cows are usually very thin because they are sacred :-) > > _my_ suggestion to you is that you port the code to GCC and do what > > you like with it there. > > You mean port the userspace to GCC? Or the kernel? Wouldn't that kind > of defeat the intent behind Plan 9's redesigned toolchain? Is gcc even > supported enough on Plan 9 for serious work? The docs I've read seem to > suggest that gcc is kind of "glued onto the side of" Plan 9 proper. > The kernel code, so you can have your paradigms where I assumed you would miss them the most. No one cares about user space applications: they work, why change them? That way lies a proliferation of incompatible versions. And plan9port provides most of the Plan 9 userspace under a plethora of platforms, so that job is already done. As for GCC, it's like Linux, you know where to get it. It doesn't fit very well within Plan 9 (I have a sort-of-working version I keep as a monument), so my idea was to encourage you to turn the Plan 9 platform into something that ought to match your religious beliefs more closely. There is merit to having Plan 9 supported as a GCC application, but no one here has the necessary faith in GCC to invest in doing it. > > Chances are that the the changes you want to introduce are going to be > > incompatible in some or other manner; > > 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. As long as you don't try to treat them as text strings, I don't see why you should encounter any problems. And I fail to see how you would do any better on any other platform, without resorting to a completely new string type. And in that vein, do you want to compare Plan 9's support for UTF-8 to other platforms' support for internationalisation? ++L ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 7:07 ` smiley 2011-02-01 7:22 ` Lucio De Re @ 2011-02-01 13:45 ` erik quanstrom 2011-02-01 16:24 ` Charles Forsyth 2 siblings, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-01 13:45 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 7:07 ` smiley 2011-02-01 7:22 ` Lucio De Re 2011-02-01 13:45 ` erik quanstrom @ 2011-02-01 16:24 ` Charles Forsyth 2 siblings, 0 replies; 192+ messages in thread From: Charles Forsyth @ 2011-02-01 16:24 UTC (permalink / raw) To: 9fans >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.) ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:02 ` smiley 2011-02-01 6:26 ` Lucio De Re @ 2011-02-01 6:45 ` ron minnich 2011-02-01 17:51 ` smiley 2011-02-01 8:25 ` Federico G. Benavento ` (3 subsequent siblings) 5 siblings, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-01 6:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jan 31, 2011 at 10:02 PM, <smiley@zenzebra.mv.com> wrote: > 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'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'm not totally in agreement with your other comments but to each his own. Yes, there are some good things that have come along in 30 years, but I have to wonder if you've been inside glibc lately. I don't think that the span of time has much if anything to do with code quality. And many of the "great ideas" of the last 30 years are not, in the end, so terribly great. There are other, very good paradigms that the code does use, such as lock-free threads. 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. To paraphrase the old Macintosh programming guides, "everything you know is wrong". It's really worth taking the time seeing how these ideas work before wading in with a machete and changing it all. There's a reason that things are the way they are. That doesn't mean, btw, always better; but it pays to figure out what's what first. > 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. would be interesting to see it. I propose that you offer up your ideas of C macros etc. before too much longer. ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:45 ` ron minnich @ 2011-02-01 17:51 ` smiley 2011-02-01 18:33 ` ron minnich 2011-02-02 4:19 ` [9fans] " Federico G. Benavento 0 siblings, 2 replies; 192+ messages in thread From: smiley @ 2011-02-01 17:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs ron minnich <rminnich@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: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 17:51 ` smiley @ 2011-02-01 18:33 ` ron minnich 2011-02-01 19:16 ` jimmy frasche 2011-02-02 0:28 ` smiley 2011-02-02 4:19 ` [9fans] " Federico G. Benavento 1 sibling, 2 replies; 192+ messages in thread From: ron minnich @ 2011-02-01 18:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 1, 2011 at 9:51 AM, <smiley@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? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 18:33 ` ron minnich @ 2011-02-01 19:16 ` jimmy frasche 2011-02-02 0:28 ` smiley 1 sibling, 0 replies; 192+ messages in thread From: jimmy frasche @ 2011-02-01 19:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 1, 2011 at 10:33 AM, ron minnich <rminnich@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 :) ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 18:33 ` ron minnich 2011-02-01 19:16 ` jimmy frasche @ 2011-02-02 0:28 ` smiley 2011-02-02 0:42 ` erik quanstrom 2011-02-02 0:47 ` ron minnich 1 sibling, 2 replies; 192+ messages in thread From: smiley @ 2011-02-02 0:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs ron minnich <rminnich@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: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-02 0:28 ` smiley @ 2011-02-02 0:42 ` erik quanstrom 2011-02-02 0:47 ` ron minnich 1 sibling, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-02 0:42 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-02 0:28 ` smiley 2011-02-02 0:42 ` erik quanstrom @ 2011-02-02 0:47 ` ron minnich 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley 1 sibling, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-02 0:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 1, 2011 at 4:28 PM, <smiley@zenzebra.mv.com> wrote: > ron minnich <rminnich@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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 0:47 ` ron minnich @ 2011-02-02 5:14 ` smiley 2011-02-02 5:37 ` Scott Sullivan ` (4 more replies) 0 siblings, 5 replies; 192+ messages in thread From: smiley @ 2011-02-02 5:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs ron minnich <rminnich@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: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley @ 2011-02-02 5:37 ` Scott Sullivan 2011-02-02 5:38 ` EBo ` (3 subsequent siblings) 4 siblings, 0 replies; 192+ messages in thread From: Scott Sullivan @ 2011-02-02 5:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 02/02/2011 12:14 AM, smiley@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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley 2011-02-02 5:37 ` Scott Sullivan @ 2011-02-02 5:38 ` EBo 2011-02-02 15:54 ` Anthony Sorace 2011-02-02 12:54 ` erik quanstrom ` (2 subsequent siblings) 4 siblings, 1 reply; 192+ messages in thread From: EBo @ 2011-02-02 5:38 UTC (permalink / raw) To: 9fans On Wed, 02 Feb 2011 05:14:54 +0000, smiley@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 -- ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 5:38 ` EBo @ 2011-02-02 15:54 ` Anthony Sorace 0 siblings, 0 replies; 192+ messages in thread From: Anthony Sorace @ 2011-02-02 15:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Just to address the unanswered Limbo questions: The only Limbo compilers extant compile to a portable bytecode for the Dis virtual machine. The only first-class Dis implementation is built into Inferno. Dis can be either interpreted or just-in-time compiled. The historical claim was a that the JIT gave performance about 1.5x slower than compiled C, although I've not seen that benchmarked in about a decade. Years ago, Russ did a sort of first draft of getting Dis to run directly under Plan 9 (which I believe is still available), and I have some vague recollection of someone extending that a bit. Limbo remains my favorite language to write in, but given Go's surprisingly rapid uptake and current momentum, I somewhat suspect the community would be better served by assisting in those porting efforts. As an aside, the comments about Alef's demise aren't really relevant. Alef had no significant development community outside the Labs, only ran on one other platform afaik, and all the work to support it had to be done by the same group doing "core" Plan 9. A community-provided port of a language with an existing language with its own community wouldn't fit those circumstances. Anthony ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley 2011-02-02 5:37 ` Scott Sullivan 2011-02-02 5:38 ` EBo @ 2011-02-02 12:54 ` erik quanstrom 2011-02-02 13:48 ` Devon H. O'Dell 2011-02-02 17:47 ` David Leimbach 2011-02-02 17:44 ` David Leimbach 2011-02-18 5:23 ` ron minnich 4 siblings, 2 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-02 12:54 UTC (permalink / raw) To: 9fans > 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. although the proof is in the putting, i don't see why a kernel in principle, can't be written in go, or a slightly restricted subset of go. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 12:54 ` erik quanstrom @ 2011-02-02 13:48 ` Devon H. O'Dell 2011-02-02 17:47 ` David Leimbach 1 sibling, 0 replies; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-02 13:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/2 erik quanstrom <quanstro@quanstro.net>: >> 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. > > although the proof is in the putting, i don't see why a kernel > in principle, can't be written in go, or a slightly restricted subset > of go. There existed part of the tree called "pchw," renamed "tiny" and then removed due to lack of maintenance that used the xv6 bootloader and implemented a tiny "Hello, World" kernel. It's clear that some changes would have to be made for a serious kernel (ensuring not blocking in an interrupt handler for instance), but it's certainly possible -- and has been done -- with the language as-is. --dho > - erik > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 12:54 ` erik quanstrom 2011-02-02 13:48 ` Devon H. O'Dell @ 2011-02-02 17:47 ` David Leimbach 2011-02-02 17:53 ` erik quanstrom 2011-02-02 18:07 ` tlaronde 1 sibling, 2 replies; 192+ messages in thread From: David Leimbach @ 2011-02-02 17:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 822 bytes --] On Wed, Feb 2, 2011 at 4:54 AM, erik quanstrom <quanstro@quanstro.net>wrote: > > 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. > > although the proof is in the putting, i don't see why a kernel > in principle, can't be written in go, or a slightly restricted subset > of go. > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET FRENCH BENEFITS!?! > > - erik > > [-- Attachment #2: Type: text/html, Size: 1328 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:47 ` David Leimbach @ 2011-02-02 17:53 ` erik quanstrom 2011-02-02 18:07 ` tlaronde 1 sibling, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-02 17:53 UTC (permalink / raw) To: 9fans > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > FRENCH BENEFITS!?! sadly, no. the work week is still 100hrs and we get -3 holidays/decade. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:47 ` David Leimbach 2011-02-02 17:53 ` erik quanstrom @ 2011-02-02 18:07 ` tlaronde 2011-02-02 18:26 ` David Leimbach 1 sibling, 1 reply; 192+ messages in thread From: tlaronde @ 2011-02-02 18:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Feb 02, 2011 at 09:47:01AM -0800, David Leimbach wrote: > > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > FRENCH BENEFITS!?! Please explain. -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:07 ` tlaronde @ 2011-02-02 18:26 ` David Leimbach 2011-02-02 18:48 ` tlaronde 2011-02-03 0:39 ` Charles Forsyth 0 siblings, 2 replies; 192+ messages in thread From: David Leimbach @ 2011-02-02 18:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1224 bytes --] On Wed, Feb 2, 2011 at 10:07 AM, <tlaronde@polynum.com> wrote: > On Wed, Feb 02, 2011 at 09:47:01AM -0800, David Leimbach wrote: > > > > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > > FRENCH BENEFITS!?! > > Please explain. > I was just pointing out something that happens a lot in our speech that can translate into text and I think most every american I've ever met falls into :-). Sometimes we americans say a lot of things that aren't quite right but sound close like my ex girlfriend who used to say "supposably" instead of "supposedly". "Fringe" is close enough to "French" that it's often heard in it's place. Another one is "He couldn't care a less" for "He couldn't care less". A fringe benefit is pretty well described here: http://www.wisegeek.com/what-are-fringe-benefits.htm and you'll hear people call them "French Benefits". As for me, I wasn't really sure if the proof was in the pudding or the putting, so I was trying to poke fun at myself. Dave > -- > Thierry Laronde <tlaronde +AT+ polynum +dot+ com> > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > [-- Attachment #2: Type: text/html, Size: 2021 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:26 ` David Leimbach @ 2011-02-02 18:48 ` tlaronde 2011-02-02 19:26 ` Nick LaForge 2011-02-03 0:39 ` Charles Forsyth 1 sibling, 1 reply; 192+ messages in thread From: tlaronde @ 2011-02-02 18:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Feb 02, 2011 at 10:26:34AM -0800, David Leimbach wrote: > On Wed, Feb 2, 2011 at 10:07 AM, <tlaronde@polynum.com> wrote: > > > On Wed, Feb 02, 2011 at 09:47:01AM -0800, David Leimbach wrote: > > > > > > Wait, isn't it "the proof is in the *pudding*"? YOU MEAN WE DON'T GET > > > FRENCH BENEFITS!?! > > > > Please explain. > > > > [...] > A fringe benefit is pretty well described here: > http://www.wisegeek.com/what-are-fringe-benefits.htm and you'll hear people > call them "French Benefits". > [...] Sorry, I'm quite edgy at the moment ;) And I'm not the only one... -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:48 ` tlaronde @ 2011-02-02 19:26 ` Nick LaForge 0 siblings, 0 replies; 192+ messages in thread From: Nick LaForge @ 2011-02-02 19:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "BCPL makes C look like a very high-level language and provides absolutely no type checking or run-time support." B. Stroustrup, The Design and Evolution of C++, 1994 "C++ was designed to be used in a rather traditional compilation and run-time environment, the C programming environment on the UNIX system. Facilities such as exception handling or concurrent programming that require nontrivial loader and run-time support are not included in C++. Consequently, a C++ implementation can be very easily ported." B. Stroustrup, The C++ Programming Language, 1986 "Except for the new, delete, typeid, dynamic_cast, and throw operators and the try-block, individual C++ expressions and statements need no run-time support." B. Stroustrup, The C++ Programming Language, 3rd ed., 2000 Nick ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:26 ` David Leimbach 2011-02-02 18:48 ` tlaronde @ 2011-02-03 0:39 ` Charles Forsyth 1 sibling, 0 replies; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 0:39 UTC (permalink / raw) To: 9fans >you'll hear people call [fringe benefits] "French Benefits". i did not expect that! i'd have guessed: `cheese'. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley ` (2 preceding siblings ...) 2011-02-02 12:54 ` erik quanstrom @ 2011-02-02 17:44 ` David Leimbach 2011-02-02 17:50 ` erik quanstrom 2011-02-02 18:03 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely erik quanstrom 2011-02-18 5:23 ` ron minnich 4 siblings, 2 replies; 192+ messages in thread From: David Leimbach @ 2011-02-02 17:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 5412 bytes --] On Tue, Feb 1, 2011 at 9:14 PM, <smiley@zenzebra.mv.com> wrote: > ron minnich <rminnich@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? > You can already write Limbo programs for Plan 9. The line between the "OS" of Inferno and the VM of Inferno is small. You should be able to access your plan 9 resources from Inferno just fine. Just like you can access most of what you'd want from an operating system from Java or Erlang. It's not very different, except that Inferno has shells and editors and a GUI that run in it's VM. > > 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? > Even C has a runtime. Perhaps you should look more into how programming languages are implemented :-). C++ has one too, especially in the wake of exceptions and such. > > 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? > GC can incur performance hits in some families of applications where timing guarantees are needed and make writing code for hard realtime applications basically impossible, unless you can get some guarantees from the GC that it won't interrupt your processing that must complete by a particular deadline. > > 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. > The memory model is very clear on how changes become visible across goroutines. One must either synchronize with channels or synchronize via some locking mechanism to guarantee that updates to shared data are visible. Go encourages a CSP style of concurrency that promotes using channels for both synchronization and update of shared data. This is something you could learn by reading more about it yourself, or trying it out. There's even an in-browser sandbox you can use. > > 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. > People already have a Go cross compiler to Plan 9. You could verify these "sounds like" factoids yourself though by checking it out and trying it. > > > 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++? > C pre-processor probably. > > > 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. > Where did your C compiler come from? Someone probably compiled it with a C compiler. Bootstrapping is a fact of life as a new compiler can't just be culled from /dev/random or willed into existence otherwise. It takes a plan 9 system to build plan 9 right? (This was not always true for infinitely recursive reasons) > > -- > +---------------------------------------------------------------+ > |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---------------------------------------------------------------+ > > [-- Attachment #2: Type: text/html, Size: 7144 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:44 ` David Leimbach @ 2011-02-02 17:50 ` erik quanstrom 2011-02-02 18:15 ` Jonathan Cast ` (2 more replies) 2011-02-02 18:03 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely erik quanstrom 1 sibling, 3 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-02 17:50 UTC (permalink / raw) To: 9fans > Even C has a runtime. Perhaps you should look more into how programming > languages are implemented :-). C++ has one too, especially in the wake of > exceptions and such. really? what do you consider to be the c runtime? i don't think that the asm goo that gets you to main really counts as "runtime" and neither does the c library, because neither implement language features. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:50 ` erik quanstrom @ 2011-02-02 18:15 ` Jonathan Cast 2011-02-02 18:21 ` erik quanstrom 2011-02-02 18:21 ` David Leimbach 2011-02-03 10:00 ` [9fans] Modern development language for Plan 9, Greg Comeau 2 siblings, 1 reply; 192+ messages in thread From: Jonathan Cast @ 2011-02-02 18:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2011-02-02 at 12:50 -0500, erik quanstrom wrote: > > Even C has a runtime. Perhaps you should look more into how programming > > languages are implemented :-). C++ has one too, especially in the wake of > > exceptions and such. > > really? what do you consider to be the c runtime? > i don't think that the asm goo that gets you to main > really counts as "runtime" and neither does the c > library, because neither implement language features. A runtime system is just a library whose entry points are language keywords.[1] In go, dynamic allocation, threads, channels, etc. are accessed via language features, so the libraries that implement those things are considered part of the RTS. That's a terminological difference only from Plan 9 C, which has the same features[2] but accesses them through ordinary library entry points so the libraries that implement them aren't called `runtimes'. But I think complaining about a library only because its entry point is a keyword is kind of silly. jcc [1] Or other syntactic features of the language. I'm not aware of any other simplification in this statement; correct me if I'm wrong. [2] Well, C has somewhat less useful versions of the same features. The difference has no significant impact on the size of the relevant libraries. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:15 ` Jonathan Cast @ 2011-02-02 18:21 ` erik quanstrom 2011-02-02 18:36 ` David Leimbach 2011-02-02 19:15 ` Jonathan Cast 0 siblings, 2 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-02 18:21 UTC (permalink / raw) To: 9fans > A runtime system is just a library whose entry points are language > keywords.[1] In go, dynamic allocation, threads, channels, etc. are > accessed via language features, so the libraries that implement those > things are considered part of the RTS. That's a terminological > difference only from Plan 9 C, which has the same features[2] but > accesses them through ordinary library entry points so the libraries > that implement them aren't called `runtimes'. But I think complaining > about a library only because its entry point is a keyword is kind of > silly. i think this glosses over a key difference. a runtime can do things that are not invoked by function call. the canonical example is garbage collection. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:21 ` erik quanstrom @ 2011-02-02 18:36 ` David Leimbach 2011-02-02 18:38 ` erik quanstrom 2011-02-02 19:15 ` Jonathan Cast 1 sibling, 1 reply; 192+ messages in thread From: David Leimbach @ 2011-02-02 18:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1379 bytes --] On Wed, Feb 2, 2011 at 10:21 AM, erik quanstrom <quanstro@quanstro.net>wrote: > > A runtime system is just a library whose entry points are language > > keywords.[1] In go, dynamic allocation, threads, channels, etc. are > > accessed via language features, so the libraries that implement those > > things are considered part of the RTS. That's a terminological > > difference only from Plan 9 C, which has the same features[2] but > > accesses them through ordinary library entry points so the libraries > > that implement them aren't called `runtimes'. But I think complaining > > about a library only because its entry point is a keyword is kind of > > silly. > > i think this glosses over a key difference. a runtime can do things > that are not invoked by function call. the canonical example is > garbage collection. > > - erik > > An excellent example would also be the scheduling of goroutines. I do not believe there's anything in the language specification that says that goroutines could not one day be pre-emptive. Also, from this point of view, could pthreads be considered runtime for C? Depends on the implementation I suppose. You've got thread local storage, which is not handled by any explicit C code, but by a coordinated effort between the kernel and the pthreads library. So the kernel is a C runtime too :-). Dave [-- Attachment #2: Type: text/html, Size: 1782 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:36 ` David Leimbach @ 2011-02-02 18:38 ` erik quanstrom 2011-02-02 18:46 ` David Leimbach 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-02 18:38 UTC (permalink / raw) To: 9fans > Also, from this point of view, could pthreads be considered runtime for C? no. then every library/os function ever bolted onto c would be "part of the c runtime". clearly this isn't the case and pthreads are not specified in the c standard. it might be part of /a/ runtime, but not the c runtime. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:38 ` erik quanstrom @ 2011-02-02 18:46 ` David Leimbach 0 siblings, 0 replies; 192+ messages in thread From: David Leimbach @ 2011-02-02 18:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wednesday, February 2, 2011, erik quanstrom <quanstro@quanstro.net> wrote: >> Also, from this point of view, could pthreads be considered runtime for C? > > no. then every library/os function ever bolted onto > c would be "part of the c runtime". clearly this isn't > the case and pthreads are not specified in the c standard. > > it might be part of /a/ runtime, but not the c runtime. > > - erik > > You are right. I suppose in C only the stack space is really needed for function calls and that may be pushing it too. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:21 ` erik quanstrom 2011-02-02 18:36 ` David Leimbach @ 2011-02-02 19:15 ` Jonathan Cast 2011-02-02 19:31 ` erik quanstrom 1 sibling, 1 reply; 192+ messages in thread From: Jonathan Cast @ 2011-02-02 19:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2011-02-02 at 13:21 -0500, erik quanstrom wrote: > > A runtime system is just a library whose entry points are language > > keywords.[1] In go, dynamic allocation, threads, channels, etc. are > > accessed via language features, so the libraries that implement those > > things are considered part of the RTS. That's a terminological > > difference only from Plan 9 C, which has the same features[2] but > > accesses them through ordinary library entry points so the libraries > > that implement them aren't called `runtimes'. But I think complaining > > about a library only because its entry point is a keyword is kind of > > silly. > > i think this glosses over a key difference. a runtime can do things > that are not invoked by function call. the canonical example is > garbage collection. I don't follow. Garbage collection certainly can be done in a library (e.g., Boehm). GC is in my experience normally triggered by * Allocation --- which is a function call in C * Explicit call to the `garbage collect now' entry point in the standard library. A function call in every language. What other events canonically would trigger garbage collection, but not be invoked by function calls? jcc ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 19:15 ` Jonathan Cast @ 2011-02-02 19:31 ` erik quanstrom 2011-02-02 19:48 ` Jeff Sickel 2011-02-02 20:07 ` Jonathan Cast 0 siblings, 2 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-02 19:31 UTC (permalink / raw) To: 9fans > I don't follow. Garbage collection certainly can be done in a library > (e.g., Boehm). GC is in my experience normally triggered by > > * Allocation --- which is a function call in C > * Explicit call to the `garbage collect now' entry point in the > standard library. A function call in every language. > > What other events canonically would trigger garbage collection, but not > be invoked by function calls? i should have said automatic garbage collection. i think of it this way, the janitor doesn't insist that the factory shut down so he can sweep. he waits for the factory to be idle, and then sweeps. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 19:31 ` erik quanstrom @ 2011-02-02 19:48 ` Jeff Sickel 2011-02-02 20:07 ` Jonathan Cast 1 sibling, 0 replies; 192+ messages in thread From: Jeff Sickel @ 2011-02-02 19:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Feb 2, 2011, at 1:31 PM, erik quanstrom wrote: > i think of it this way, the janitor doesn't insist that the factory shut > down so he can sweep. he waits for the factory to be idle, and then > sweeps. Clearly I've been working on the wrong floors. That or all the janitors I know are using the Java GC model: never around for long periods of time, then right in the midst of a critical section it's stop what you're doing, stand up, and move out of the way. Don't forget to take your chair and any other items you might want to be around when you can get back to the task. Otherwise those important bits will be in the dust bin on route to the garbage chute before taking the long trek out to the land fill. -jas ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 19:31 ` erik quanstrom 2011-02-02 19:48 ` Jeff Sickel @ 2011-02-02 20:07 ` Jonathan Cast 2011-02-02 20:11 ` erik quanstrom 1 sibling, 1 reply; 192+ messages in thread From: Jonathan Cast @ 2011-02-02 20:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2011-02-02 at 14:31 -0500, erik quanstrom wrote: > > I don't follow. Garbage collection certainly can be done in a library > > (e.g., Boehm). GC is in my experience normally triggered by > > > > * Allocation --- which is a function call in C > > * Explicit call to the `garbage collect now' entry point in the > > standard library. A function call in every language. > > > > What other events canonically would trigger garbage collection, but not > > be invoked by function calls? > > i should have said automatic garbage collection. > i think of it this way, the janitor doesn't insist that the factory shut > down so he can sweep. he waits for the factory to be idle, and then > sweeps. I think factory owners get pretty upset when their factories idle. I still think the program needs to call into the threading library (whether you call it part of the RTS or not) to idle. So the only benefit you have is that putting threading and the garbage collector into the RTS allows you to ignore the abstraction barriers between the two systems, which makes it easier for the thread system to signal the garbage collector. I mean, if the thread does this (making up syntax on the spot): start := now(); while (now() < start + 2hours); You don't expect GC to be able to trigger, right? jcc ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 20:07 ` Jonathan Cast @ 2011-02-02 20:11 ` erik quanstrom 2011-02-02 20:22 ` Jonathan Cast 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-02 20:11 UTC (permalink / raw) To: 9fans > start := now(); > while (now() < start + 2hours); > > You don't expect GC to be able to trigger, right? i sure do. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 20:11 ` erik quanstrom @ 2011-02-02 20:22 ` Jonathan Cast 0 siblings, 0 replies; 192+ messages in thread From: Jonathan Cast @ 2011-02-02 20:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 2011-02-02 at 15:11 -0500, erik quanstrom wrote: > > start := now(); > > while (now() < start + 2hours); > > > > You don't expect GC to be able to trigger, right? > > i sure do. Ah. Interesting. Who's done that? jcc ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:50 ` erik quanstrom 2011-02-02 18:15 ` Jonathan Cast @ 2011-02-02 18:21 ` David Leimbach 2011-02-03 10:00 ` [9fans] Modern development language for Plan 9, Greg Comeau 2 siblings, 0 replies; 192+ messages in thread From: David Leimbach @ 2011-02-02 18:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1127 bytes --] On Wed, Feb 2, 2011 at 9:50 AM, erik quanstrom <quanstro@quanstro.net>wrote: > > Even C has a runtime. Perhaps you should look more into how programming > > languages are implemented :-). C++ has one too, especially in the wake > of > > exceptions and such. > > really? what do you consider to be the c runtime? > i don't think that the asm goo that gets you to main > really counts as "runtime" and neither does the c > library, because neither implement language features. > > How about setting up stack space in the code for an operating system kernel? That's something you don't explicitly write in C that must be there somehow, for example in an operating system kernel. You end up changing that runtime bit and then all your C code has different stack space available. I suppose you could group that into the kernel's runtime, but since the operating system I'm thinking of is coded in C, that kind of line drawing seems silly ;-) I agree that C has a really really minimal need for any "help" to run on raw metal, but some level of support is still necessary. Dave > - erik > > [-- Attachment #2: Type: text/html, Size: 1812 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, 2011-02-02 17:50 ` erik quanstrom 2011-02-02 18:15 ` Jonathan Cast 2011-02-02 18:21 ` David Leimbach @ 2011-02-03 10:00 ` Greg Comeau 2 siblings, 0 replies; 192+ messages in thread From: Greg Comeau @ 2011-02-03 10:00 UTC (permalink / raw) To: 9fans In article <be3e16017566e26d4074ae69bc9b12c2@chula.quanstro.net>, erik quanstrom <quanstro@quanstro.net> wrote: >> Even C has a runtime. Perhaps you should look more into how programming >> languages are implemented :-). C++ has one too, especially in the wake of >> exceptions and such. > >really? what do you consider to be the c runtime? >i don't think that the asm goo that gets you to main >really counts as "runtime" and neither does the c >library, because neither implement language features. Yes and no, though it's worthing point out that enough people do seem to call it all a runtime. However, the "asm goo" surely does really count, since on some system it is more than just a jump to the start, and can include memory allocation, memory initialiation, math routines not available on the chip, opening files, etc. The way I see it, it's not so much that is implements language features per se (though that's part of it) but a way to support the run time execution of the program (and I agree that does not necessarily mean printf either) which is a wishy washy kind of way supporting "the language" even though the standard does not literally defines how it happens. Probably I put my foot in my mouth with this unofficial definition, but I'm sure somebody will point that out :) -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:44 ` David Leimbach 2011-02-02 17:50 ` erik quanstrom @ 2011-02-02 18:03 ` erik quanstrom 2011-02-02 18:30 ` David Leimbach 1 sibling, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-02 18:03 UTC (permalink / raw) To: 9fans > Where did your C compiler come from? Someone probably compiled it with a C > compiler. Bootstrapping is a fact of life as a new compiler can't just be > culled from /dev/random or willed into existence otherwise. It takes a plan > 9 system to build plan 9 right? (This was not always true for infinitely > recursive reasons) ah, but where did your go compiler come from? - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 18:03 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely erik quanstrom @ 2011-02-02 18:30 ` David Leimbach 0 siblings, 0 replies; 192+ messages in thread From: David Leimbach @ 2011-02-02 18:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1452 bytes --] On Wed, Feb 2, 2011 at 10:03 AM, erik quanstrom <quanstro@labs.coraid.com>wrote: > > Where did your C compiler come from? Someone probably compiled it with a > C > > compiler. Bootstrapping is a fact of life as a new compiler can't just > be > > culled from /dev/random or willed into existence otherwise. It takes a > plan > > 9 system to build plan 9 right? (This was not always true for infinitely > > recursive reasons) > > ah, but where did your go compiler come from? > > - erik > > Well my Go compiler came from a plan 9 C compiler that came from a gcc compiler, that came from the operating system distribution CD that shipped with Mac OS X. Someone at apple presumably bootstrapped that gcc build for Mac OS X from another GCC build for Mac OS X, and that one probably goes back to some version of OpenStep, all the way back to NeXTStep, and before that some version of Unix most likely that bootstrapped NeXTStep. A lot of that lineage was a guess. It's really difficult, for instance, to bootstrap the GHC (Haskell) compiler from the intermediate C files it generates these days, and you pretty much need a port of Haskell to your platform in order get a port of haskell to your platform. It's a bit of an undocumented black art as far as I can tell, but it was supposed to be simpler :-). Many lisp compilers/systems need a lisp compiler or system in place in order to bootstrap them too. Dave [-- Attachment #2: Type: text/html, Size: 1856 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley ` (3 preceding siblings ...) 2011-02-02 17:44 ` David Leimbach @ 2011-02-18 5:23 ` ron minnich 2011-02-18 5:34 ` Paul Lalonde 4 siblings, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-18 5:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I was looking at another fine example of modern programming from glibc and just had to share it. Where does the getpid happen? It's anyone's guess. This is just so readable too ... I'm glad they want to such effort to optimize getpid. ron #ifndef NOT_IN_libc static inline __attribute__((always_inline)) pid_t really_getpid (pid_t oldval); static inline __attribute__((always_inline)) pid_t really_getpid (pid_t oldval) { if (__builtin_expect (oldval == 0, 1)) { pid_t selftid = THREAD_GETMEM (THREAD_SELF, tid); if (__builtin_expect (selftid != 0, 1)) return selftid; } INTERNAL_SYSCALL_DECL (err); pid_t result = INTERNAL_SYSCALL (getpid, err, 0); /* We do not set the PID field in the TID here since we might be called from a signal handler while the thread executes fork. */ if (oldval == 0) THREAD_SETMEM (THREAD_SELF, tid, result); return result; } #endif pid_t __getpid (void) { #ifdef NOT_IN_libc INTERNAL_SYSCALL_DECL (err); pid_t result = INTERNAL_SYSCALL (getpid, err, 0); #else pid_t result = THREAD_GETMEM (THREAD_SELF, pid); if (__builtin_expect (result <= 0, 0)) result = really_getpid (result); #endif return result; } libc_hidden_def (__getpid) weak_alias (__getpid, getpid) libc_hidden_def (getpid) ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 5:23 ` ron minnich @ 2011-02-18 5:34 ` Paul Lalonde 2011-02-18 13:29 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Paul Lalonde @ 2011-02-18 5:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Best recent c99 example: int foo[] = { [0] = 1, [1] = 2, [2] = 4, [3] = 8, [4] = 16, [5] = 32 }; I shudder to think about foo[6]. Paul On Thursday, February 17, 2011, ron minnich <rminnich@gmail.com> wrote: > I was looking at another fine example of modern programming from glibc > and just had to share it. > > Where does the getpid happen? It's anyone's guess. This is just so > readable too ... I'm glad they want to such effort to optimize getpid. > > ron > > #ifndef NOT_IN_libc > static inline __attribute__((always_inline)) pid_t really_getpid (pid_t oldval); > > static inline __attribute__((always_inline)) pid_t > really_getpid (pid_t oldval) > { > if (__builtin_expect (oldval == 0, 1)) > { > pid_t selftid = THREAD_GETMEM (THREAD_SELF, tid); > if (__builtin_expect (selftid != 0, 1)) > return selftid; > } > > INTERNAL_SYSCALL_DECL (err); > pid_t result = INTERNAL_SYSCALL (getpid, err, 0); > > /* We do not set the PID field in the TID here since we might be > called from a signal handler while the thread executes fork. */ > if (oldval == 0) > THREAD_SETMEM (THREAD_SELF, tid, result); > return result; > } > #endif > > pid_t > __getpid (void) > { > #ifdef NOT_IN_libc > INTERNAL_SYSCALL_DECL (err); > pid_t result = INTERNAL_SYSCALL (getpid, err, 0); > #else > pid_t result = THREAD_GETMEM (THREAD_SELF, pid); > if (__builtin_expect (result <= 0, 0)) > result = really_getpid (result); > #endif > return result; > } > > libc_hidden_def (__getpid) > weak_alias (__getpid, getpid) > libc_hidden_def (getpid) > > -- I'm migrating my email. plalonde@telus.net will soon be disconnected. Please use paul.a.lalonde@gmail.com from now on. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 5:34 ` Paul Lalonde @ 2011-02-18 13:29 ` erik quanstrom 2011-02-18 13:45 ` dexen deVries 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 13:29 UTC (permalink / raw) To: 9fans so this is a complete waste of time if forks > getpids. and THREAD_GETMEM must allocate memory. so the first call isn't exactly cheep. aren't they optimizing for bad programming? not only that, ... from getpid(2) NOTES Since glibc version 2.3.4, the glibc wrapper function for getpid() caches PIDs, so as to avoid additional system calls when a process calls getpid() repeatedly. Normally this caching is invisible, but its correct operation relies on support in the wrapper functions for fork(2), vfork(2), and clone(2): if an application bypasses the glibc wrappers for these system calls by using syscall(2), then a call to getpid() in the child will return the wrong value (to be precise: it will return the PID of the parent process). See also clone(2) for dis- - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 13:29 ` erik quanstrom @ 2011-02-18 13:45 ` dexen deVries 2011-02-18 14:54 ` David Leimbach 2011-02-18 15:15 ` Devon H. O'Dell 0 siblings, 2 replies; 192+ messages in thread From: dexen deVries @ 2011-02-18 13:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: > so this is a complete waste of time if forks > getpids. > and THREAD_GETMEM must allocate memory. so > the first call isn't exactly cheep. aren't they optimizing > for bad programming? > > not only that, ... from getpid(2) > > NOTES > Since glibc version 2.3.4, the glibc wrapper function for > getpid() caches PIDs, so as to avoid additional system calls when a > process calls getpid() repeatedly. Normally this caching is invisible, > but its correct operation relies on support in the wrapper > functions for fork(2), vfork(2), and clone(2): if an application bypasses > the glibc wrappers for these system calls by using syscall(2), then a > call to getpid() in the child will return the wrong value (to be > precise: it will return the PID of the parent process). See also > clone(2) for dis- which boggles my mind: why would getpid() need to be optimized for in the first place? Konqueror 4.5.5 (browser) calls it once per short session (few tabs) Firefox 4 (browser) calls it about once per tab openssh calls it once or twice per session bash calls it once lsof, find do not call it at all. what does call getpid() often? @_@ anyway, it looks a bit like library lock-in to me: ``your app better perform _every_ syscall through glibc, or else'' -- or else strange things may happen, eh? -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 13:45 ` dexen deVries @ 2011-02-18 14:54 ` David Leimbach 2011-02-18 15:15 ` Devon H. O'Dell 1 sibling, 0 replies; 192+ messages in thread From: David Leimbach @ 2011-02-18 14:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Fans of the OS Plan 9 from Bell Labs Sent from my iPhone On Feb 18, 2011, at 5:45 AM, dexen deVries <dexen.devries@gmail.com> wrote: > On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: >> so this is a complete waste of time if forks > getpids. >> and THREAD_GETMEM must allocate memory. so >> the first call isn't exactly cheep. aren't they optimizing >> for bad programming? >> >> not only that, ... from getpid(2) >> >> NOTES >> Since glibc version 2.3.4, the glibc wrapper function for >> getpid() caches PIDs, so as to avoid additional system calls when a >> process calls getpid() repeatedly. Normally this caching is invisible, >> but its correct operation relies on support in the wrapper >> functions for fork(2), vfork(2), and clone(2): if an application bypasses >> the glibc wrappers for these system calls by using syscall(2), then a >> call to getpid() in the child will return the wrong value (to be >> precise: it will return the PID of the parent process). See also >> clone(2) for dis- > > which boggles my mind: why would getpid() need to be optimized for in the first > place? LMbench? > > Konqueror 4.5.5 (browser) calls it once per short session (few tabs) > Firefox 4 (browser) calls it about once per tab > openssh calls it once or twice per session > bash calls it once > lsof, find do not call it at all. > > what does call getpid() often? @_@ > > > anyway, it looks a bit like library lock-in to me: ``your app better perform > _every_ syscall through glibc, or else'' -- or else strange things may happen, > eh? > > > -- > dexen deVries > > [[[↓][→]]] > >> how does a C compiler get to be that big? what is all that code doing? > > iterators, string objects, and a full set of C macros that ensure > boundary conditions and improve interfaces. > > ron minnich, in response to Charles Forsyth > > http://9fans.net/archive/2011/02/90 > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 13:45 ` dexen deVries 2011-02-18 14:54 ` David Leimbach @ 2011-02-18 15:15 ` Devon H. O'Dell 2011-02-18 16:11 ` erik quanstrom ` (2 more replies) 1 sibling, 3 replies; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 15:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 dexen deVries <dexen.devries@gmail.com>: > On Friday, February 18, 2011 02:29:54 pm erik quanstrom wrote: >> so this is a complete waste of time if forks > getpids. >> and THREAD_GETMEM must allocate memory. so >> the first call isn't exactly cheep. aren't they optimizing >> for bad programming? >> >> not only that, ... from getpid(2) >> >> NOTES >> Since glibc version 2.3.4, the glibc wrapper function for >> getpid() caches PIDs, so as to avoid additional system calls when a >> process calls getpid() repeatedly. Normally this caching is invisible, >> but its correct operation relies on support in the wrapper >> functions for fork(2), vfork(2), and clone(2): if an application bypasses >> the glibc wrappers for these system calls by using syscall(2), then a >> call to getpid() in the child will return the wrong value (to be >> precise: it will return the PID of the parent process). See also >> clone(2) for dis- > > which boggles my mind: why would getpid() need to be optimized for in the first > place? > > Konqueror 4.5.5 (browser) calls it once per short session (few tabs) > Firefox 4 (browser) calls it about once per tab > openssh calls it once or twice per session > bash calls it once > lsof, find do not call it at all. > > what does call getpid() often? @_@ Benchmark utilities to measure the overhead of syscalls. It's cheating to do for getpid, but for other things like gettimeofday, it's *extremely* nice. Linux's gettimeofday(2) beats the socks off of the rest of the time implementations. About the only faster thing is to get CPU speed and use rdtsc. Certainly no other OS allows you to get the timestamp faster with a syscall. > > anyway, it looks a bit like library lock-in to me: ``your app better perform > _every_ syscall through glibc, or else'' -- or else strange things may happen, > eh? I know we're fond of bashing people who need to eek performance out of systems, and a lot of time it's all in good fun. There's little justification for getpid, but getpid isn't the only implementor of this functionality. For other interfaces, it definitely makes sense to speed up the system to speed up applications. Argue about it all you want, but without this sort of mentality, we also wouldn't have non-blocking I/O or kernel thread support. Yes, processors are fast enough. Except when they aren't. --dho ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 15:15 ` Devon H. O'Dell @ 2011-02-18 16:11 ` erik quanstrom 2011-02-18 16:28 ` Devon H. O'Dell 2011-02-18 16:53 ` dexen deVries 2011-02-19 10:34 ` Steve Simon 2 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 16:11 UTC (permalink / raw) To: 9fans > I know we're fond of bashing people who need to eek performance out of > systems, and a lot of time it's all in good fun. There's little > justification for getpid, but getpid isn't the only implementor of > this functionality. For other interfaces, it definitely makes sense to > speed up the system to speed up applications. Argue about it all you > want, but without this sort of mentality, we also wouldn't have > non-blocking I/O or kernel thread support. define "we". there's no non-blocking io in plan 9. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:11 ` erik quanstrom @ 2011-02-18 16:28 ` Devon H. O'Dell 2011-02-18 16:49 ` erik quanstrom 2011-02-18 17:05 ` andrey mirtchovski 0 siblings, 2 replies; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 16:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 erik quanstrom <quanstro@labs.coraid.com>: >> I know we're fond of bashing people who need to eek performance out of >> systems, and a lot of time it's all in good fun. There's little >> justification for getpid, but getpid isn't the only implementor of >> this functionality. For other interfaces, it definitely makes sense to >> speed up the system to speed up applications. Argue about it all you >> want, but without this sort of mentality, we also wouldn't have >> non-blocking I/O or kernel thread support. > > define "we". there's no non-blocking io in plan 9. I didn't mean "we" in the context of Plan 9. I meant "we" in the context of computer science and software engineering. Someone thought there was a problem with an interface and came up with a solution. Plan 9 has a different approach to solving the problem by providing a different means to addressing it entirely. Arguing that performance is unimportant is counterintuitive. It certainly is. Arguing that it is unimportant if it causes unnecessary complexity has merit. Defining when things become "unnecessarily complex" is important to the argument. Applications with timers (or doing lots of logging) using gettimeofday(2) being instantaneously improved by *very* measurable amounts due to such changes seems like a good idea to me, and it doesn't seem too complex. Doing it for getpid(2) seems pretty dumb. I think it's time that we do some real-world style benchmarks on multiple systems for Plan 9 versus other systems. I'd be interested in seeing what we could come up with, how we address it, and the relative "ease" for each solution. Anybody want to work together to put something like that together? --dho > - erik > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:28 ` Devon H. O'Dell @ 2011-02-18 16:49 ` erik quanstrom 2011-02-18 17:10 ` Devon H. O'Dell 2011-02-18 18:43 ` Joseph Stewart 2011-02-18 17:05 ` andrey mirtchovski 1 sibling, 2 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-18 16:49 UTC (permalink / raw) To: 9fans > Arguing that performance is unimportant is counterintuitive. It > certainly is. Arguing that it is unimportant if it causes unnecessary > complexity has merit. Defining when things become "unnecessarily > complex" is important to the argument. Applications with timers (or > doing lots of logging) using gettimeofday(2) being instantaneously > improved by *very* measurable amounts due to such changes seems like a > good idea to me, and it doesn't seem too complex. Doing it for > getpid(2) seems pretty dumb. i take a different view of performance. performance is like scotch. you always want better scotch, but you only upgrade if the stuff you're drinking is a problem. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:49 ` erik quanstrom @ 2011-02-18 17:10 ` Devon H. O'Dell 2011-02-18 17:32 ` erik quanstrom 2011-02-18 18:43 ` Joseph Stewart 1 sibling, 1 reply; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 17:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 erik quanstrom <quanstro@quanstro.net>: >> Arguing that performance is unimportant is counterintuitive. It >> certainly is. Arguing that it is unimportant if it causes unnecessary >> complexity has merit. Defining when things become "unnecessarily >> complex" is important to the argument. Applications with timers (or >> doing lots of logging) using gettimeofday(2) being instantaneously >> improved by *very* measurable amounts due to such changes seems like a >> good idea to me, and it doesn't seem too complex. Doing it for >> getpid(2) seems pretty dumb. > > i take a different view of performance. > > performance is like scotch. you always want better scotch, > but you only upgrade if the stuff you're drinking is a problem. I really like this viewpoint. Unfortunately in software engineering, we are more the creators and purveyors of scotch, and our customers constantly request better scotch. Sometimes you have to say "live with it" -- but sometimes you really do need to upgrade what you are providing. I'd like to think my viewpoint maps equally well to libations. A good wine matures with age, becoming ever more complex in flavor. If you don't keep it right, that complexity turns right into vinegar. :) I agree with your point. At the same time, we have large customers who constantly push the limits of our mail server, and they have extremely good performance with it. Likely better than they can get with any competitor's implementation. If you ask an ISP or large social network if they would like to do more with less, then answer will always be "yes." Ergo there is always a perceived problem -- even if you're the de-facto leader in your industry. I'd be surprised if things were dissimilar for you at Coraid -- and I certainly *am not* implying that you guys have poor performance. I'm just saying if you went to your customers and asked, "Given the choice between something that is the same as what you have now, and something that's faster, and both have the same reliability, which do you want?" you probably wouldn't have many people who wouldn't take advantage of improved performance. --dho > - erik > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:10 ` Devon H. O'Dell @ 2011-02-18 17:32 ` erik quanstrom 2011-02-18 17:44 ` ron minnich 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 17:32 UTC (permalink / raw) To: 9fans > I'd be surprised if things were dissimilar for you at Coraid -- and I > certainly *am not* implying that you guys have poor performance. I'm > just saying if you went to your customers and asked, "Given the choice > between something that is the same as what you have now, and something > that's faster, and both have the same reliability, which do you want?" > you probably wouldn't have many people who wouldn't take advantage of > improved performance. wire speed is generally considered "good enough". ☺ - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:32 ` erik quanstrom @ 2011-02-18 17:44 ` ron minnich 2011-02-18 19:28 ` Devon H. O'Dell 0 siblings, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-18 17:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 18, 2011 at 9:32 AM, erik quanstrom <quanstro@quanstro.net> wrote: > wire speed is generally considered "good enough". ☺ depends on field of use. In my biz everyone hits wire speed, and the question from there is: how much of the CPU are you eating to get that wire speed. It's a very tangled thicked. ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:44 ` ron minnich @ 2011-02-18 19:28 ` Devon H. O'Dell 2011-02-18 19:33 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 19:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 ron minnich <rminnich@gmail.com>: > On Fri, Feb 18, 2011 at 9:32 AM, erik quanstrom <quanstro@quanstro.net> wrote: > >> wire speed is generally considered "good enough". ☺ Touche. > depends on field of use. In my biz everyone hits wire speed, and the > question from there is: how much of the CPU are you eating to get that > wire speed. > > It's a very tangled thicked. Indeed. It's very difficult to do SMTP anywhere close to wire speed with the protocol-required persistent I/O overhead, the typical content analysis stuff that ISPs, ESPs, and large content providers tend to want to do. Add on RBL lookups, crypto-related stuff (e.g. DKIM), etc., it's just not really feasible on commodity hardware. (Of course, these days, operating systems and RAID controllers with battery-backed caches make it impossible to guarantee that your message ever ends up in persistent storage, but that's still a small part of the processing overhead for a given message.) --dho > ron > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:28 ` Devon H. O'Dell @ 2011-02-18 19:33 ` erik quanstrom 2011-02-18 19:49 ` Devon H. O'Dell 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 19:33 UTC (permalink / raw) To: 9fans > DKIM), etc., it's just not really feasible on commodity hardware. (Of > course, these days, operating systems and RAID controllers with > battery-backed caches make it impossible to guarantee that your > message ever ends up in persistent storage, but that's still a small bb cache is persistent storage. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:33 ` erik quanstrom @ 2011-02-18 19:49 ` Devon H. O'Dell 0 siblings, 0 replies; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 19:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 erik quanstrom <quanstro@quanstro.net>: >> DKIM), etc., it's just not really feasible on commodity hardware. (Of >> course, these days, operating systems and RAID controllers with >> battery-backed caches make it impossible to guarantee that your >> message ever ends up in persistent storage, but that's still a small > > bb cache is persistent storage. My bad, indeed. :-). Still, modern filesystems still raise questions as to whether the data even winds up there. Modern data stores (like Mongo) raise questions as to whether the data makes it to VFS. "We" make a lot of assumptions about quite volatile systems in the name of performance. And that's usually ok, until it isn't. It's kind of an addendum to Rob's point, actually: you can quite easily decrease the reliability / efficacy / correctness of your implementation without (or with!) the right information. And of course, there's also something to be said for eeking performance out of a system that can't perform because it's poorly designed. (I'm looking at you, Twitter.) The amount of resources they have and the amount of downtime they have are really quite extraordinary. For their popularity, you'd really expect to see an inverse correlation in one way or the other. I think I've digressed further from the original point discussed (which wasn't even the original topic) and contributed way more than I intended to, though. Food for thought. --dho > - erik > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:49 ` erik quanstrom 2011-02-18 17:10 ` Devon H. O'Dell @ 2011-02-18 18:43 ` Joseph Stewart 1 sibling, 0 replies; 192+ messages in thread From: Joseph Stewart @ 2011-02-18 18:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > i take a different view of performance. > > performance is like scotch. you always want better scotch, > but you only upgrade if the stuff you're drinking is a problem. > > - erik Awesome. That quote is going on my office door below the Tanenbaum quote on bandwidth and station wagons! ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:28 ` Devon H. O'Dell 2011-02-18 16:49 ` erik quanstrom @ 2011-02-18 17:05 ` andrey mirtchovski 2011-02-18 17:12 ` Devon H. O'Dell 1 sibling, 1 reply; 192+ messages in thread From: andrey mirtchovski @ 2011-02-18 17:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I think it's time that we do some real-world style benchmarks on > multiple systems for Plan 9 versus other systems. I'd be interested in Ron did work measuring syscall costs and latencies in plan9. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:05 ` andrey mirtchovski @ 2011-02-18 17:12 ` Devon H. O'Dell 0 siblings, 0 replies; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 17:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 andrey mirtchovski <mirtchovski@gmail.com>: >> I think it's time that we do some real-world style benchmarks on >> multiple systems for Plan 9 versus other systems. I'd be interested in > > Ron did work measuring syscall costs and latencies in plan9. I would love to duplicate that across multiple systems doing similar tests. I'd also like to do real-world benchmarking -- not just microbenchmarking. --dho ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 15:15 ` Devon H. O'Dell 2011-02-18 16:11 ` erik quanstrom @ 2011-02-18 16:53 ` dexen deVries 2011-02-18 16:59 ` Devon H. O'Dell 2011-02-19 10:34 ` Steve Simon 2 siblings, 1 reply; 192+ messages in thread From: dexen deVries @ 2011-02-18 16:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Friday, February 18, 2011 04:15:10 pm you wrote: > Benchmark utilities to measure the overhead of syscalls. It's cheating > to do for getpid, but for other things like gettimeofday, it's > *extremely* nice. Linux's gettimeofday(2) beats the socks off of the > rest of the time implementations. About the only faster thing is to > get CPU speed and use rdtsc. Certainly no other OS allows you to get > the timestamp faster with a syscall. Would you mind explaining what technique is used by Linux to speed up the gettimeofday()? I'd guess it's not per-process caching... and if it's not, then it involves two context-switches; not the fastest thing in my books. As for performance in general, some speculative fiction: in general, drivers are kept in kernel for two reasons -- to protect resources from processes going rogue and to provide common, infrequently changing API to diverse hardware. The later reason is pretty much security-insensitive and serves to aid cross-platform development. In principle, the read-only parts of some drivers could be embedded in processes (things like system timer, rather than harddrive). Is there any OS out there that actually lets processes embed the read-only parts of drivers to avoid context switches for going through kernel? The closest thing I can think of is Google's Native Client, which lets untrusted code execute (within a trusted `host process') with constrained, readexecute-only access to trusted code so it can execute hand-picked syscalls & communication with the host process. Perhaps a *constrained* read-write driver for harddrive (and filesystem) access could perhaps also be held rx-only in virtual memory of untrusted code... -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:53 ` dexen deVries @ 2011-02-18 16:59 ` Devon H. O'Dell 2011-02-18 17:07 ` erik quanstrom 2011-02-18 17:12 ` andrey mirtchovski 0 siblings, 2 replies; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 16:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 dexen deVries <dexen.devries@gmail.com>: > On Friday, February 18, 2011 04:15:10 pm you wrote: >> Benchmark utilities to measure the overhead of syscalls. It's cheating >> to do for getpid, but for other things like gettimeofday, it's >> *extremely* nice. Linux's gettimeofday(2) beats the socks off of the >> rest of the time implementations. About the only faster thing is to >> get CPU speed and use rdtsc. Certainly no other OS allows you to get >> the timestamp faster with a syscall. > > Would you mind explaining what technique is used by Linux to speed up the > gettimeofday()? I'd guess it's not per-process caching... and if it's not, > then it involves two context-switches; not the fastest thing in my books. The high level overview is that it is stored in a shared page, mapped into each new process's memory space at start-up. The kernel is never entered; there are no context switches. The kernel has a timer that updates this page atomically. --dho ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:59 ` Devon H. O'Dell @ 2011-02-18 17:07 ` erik quanstrom 2011-02-18 17:11 ` Devon H. O'Dell 2011-02-18 17:16 ` Russ Cox 2011-02-18 17:12 ` andrey mirtchovski 1 sibling, 2 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-18 17:07 UTC (permalink / raw) To: 9fans > The high level overview is that it is stored in a shared page, mapped > into each new process's memory space at start-up. The kernel is never > entered; there are no context switches. The kernel has a timer that > updates this page atomically. i wonder if that is uniformly faster. consider that making reads of that page coherent enough on a big multiprocessor and making sure there's not too much interprocesser skew might be slower than a system call. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:07 ` erik quanstrom @ 2011-02-18 17:11 ` Devon H. O'Dell 2011-02-18 17:21 ` erik quanstrom 2011-02-18 17:16 ` Russ Cox 1 sibling, 1 reply; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 17:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 erik quanstrom <quanstro@quanstro.net>: >> The high level overview is that it is stored in a shared page, mapped >> into each new process's memory space at start-up. The kernel is never >> entered; there are no context switches. The kernel has a timer that >> updates this page atomically. > > i wonder if that is uniformly faster. consider that > making reads of that page coherent enough on a > big multiprocessor and making sure there's not too > much interprocesser skew might be slower than a > system call. Real world tests show that it is consistently faster. It's probably cached anyway. > - erik > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:11 ` Devon H. O'Dell @ 2011-02-18 17:21 ` erik quanstrom 2011-02-18 17:52 ` John Floren 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 17:21 UTC (permalink / raw) To: 9fans > > i wonder if that is uniformly faster. consider that > > making reads of that page coherent enough on a > > big multiprocessor and making sure there's not too > > much interprocesser skew might be slower than a > > system call. > > Real world tests show that it is consistently faster. It's probably > cached anyway. as andrey points out that's exactly the problem if you want an accurate time. also, while making gettimeofday() faster, you potentially invalidate BY2PG/BY2CL cachelines on *every* processor in the system. this has the real potential for being a problem on, say, a 256 processor system and making everything else on the system slower. linux optimization is a ratrace. you are only judged on the immediate effect on your subsystem, not the system as a whole. so unless you play the game, your system will appear to regress over time as other optimizers take resources away from you. there aren't many processor arm systems yet, but on such a system, the os will need to do the equivalent of cachedinvse() and l2cacheuwbinvse often enough to make the timing look reasonable. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:21 ` erik quanstrom @ 2011-02-18 17:52 ` John Floren 2011-02-18 18:46 ` Rob Pike 0 siblings, 1 reply; 192+ messages in thread From: John Floren @ 2011-02-18 17:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 18, 2011 at 9:21 AM, erik quanstrom <quanstro@quanstro.net> wrote: > linux optimization is a ratrace. you are only judged on > the immediate effect on your subsystem, not the system > as a whole. so unless you play the game, your system will > appear to regress over time as other optimizers take resources > away from you. On the other hand, how many optimizations have been put into the Plan 9 kernel recently? If Linux adds 100 optimizations a year, I bet at least a few of them are going to actually improve things. Is it better to have optimized and failed than never to have optimized at all? John ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:52 ` John Floren @ 2011-02-18 18:46 ` Rob Pike 2011-02-18 19:15 ` Bakul Shah 2011-02-18 19:15 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Devon H. O'Dell 0 siblings, 2 replies; 192+ messages in thread From: Rob Pike @ 2011-02-18 18:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs The more you optimize, the better the odds you slow your program down. Optimization adds instructions and often data, in one of the paradoxes of engineering. In time, then, what you gain by "optimizing" increases cache pressure and slows the whole thing down. C++ inlines a lot because microbenchmarks improve, but inline every modest function in a big program and you make the binary much bigger and blow the i-cache. -rob ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 18:46 ` Rob Pike @ 2011-02-18 19:15 ` Bakul Shah 2011-02-18 19:26 ` erik quanstrom 2011-02-18 19:35 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely David Leimbach 2011-02-18 19:15 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Devon H. O'Dell 1 sibling, 2 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-18 19:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 18 Feb 2011 10:46:51 PST Rob Pike <robpike@gmail.com> wrote: > The more you optimize, the better the odds you slow your program down. > Optimization adds instructions and often data, in one of the > paradoxes of engineering. In time, then, what you gain by > "optimizing" increases cache pressure and slows the whole thing down. You need a feedback loop. Uncontrolled anything is a recipe for disaster. Optimizations need to be `judicious' but that requires experience, profiling and understanding but the trend seems to be away from that..... On a slightly different tangent, 9p is simple but it doesn't handle latency very well. To make efficient use of long fat pipes you need more complex mechanisms -- there is no getting around that fact. rsync & hg in spite of their complexity beat the pants off replica. Their cache behavior is not very relevant here. Similarly file readahead is usually a win. > C++ inlines a lot because microbenchmarks improve, but inline every > modest function in a big program and you make the binary much bigger > and blow the i-cache. That's a compiler fault. Surely modern compilers need to be cache aware? ideally a smart compiler treats `inline' as a hint at most, just like `register'. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:15 ` Bakul Shah @ 2011-02-18 19:26 ` erik quanstrom 2011-02-18 19:46 ` Bakul Shah 2011-02-18 19:35 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely David Leimbach 1 sibling, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 19:26 UTC (permalink / raw) To: 9fans > On a slightly different tangent, 9p is simple but it doesn't > handle latency very well. To make efficient use of long fat > pipes you need more complex mechanisms -- there is no getting > around that fact. rsync & hg in spite of their complexity > beat the pants off replica. Their cache behavior is not very > relevant here. Similarly file readahead is usually a win. i don't think that it makes sense to say that since replica is slow and hg/rsync are fast, it follows that 9p is slow. 9p is a file protocol, and the rest are programs. it's apples and giraffes. as a child might tell you, an apple is just as fast as a giraffe if the apple is inside the giraffe. similarly, you blame c++ compilers for excessive inlining. i might blame the mount driver for its 1 oustanding policy. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:26 ` erik quanstrom @ 2011-02-18 19:46 ` Bakul Shah 2011-02-18 20:15 ` erik quanstrom 2011-02-24 10:09 ` [9fans] Modern development language for Plan 9, Greg Comeau 0 siblings, 2 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-18 19:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 18 Feb 2011 14:26:32 EST erik quanstrom <quanstro@quanstro.net> wrote: > > On a slightly different tangent, 9p is simple but it doesn't > > handle latency very well. To make efficient use of long fat > > pipes you need more complex mechanisms -- there is no getting > > around that fact. rsync & hg in spite of their complexity > > beat the pants off replica. Their cache behavior is not very > > relevant here. Similarly file readahead is usually a win. > > i don't think that it makes sense to say that since replica > is slow and hg/rsync are fast, it follows that 9p is slow. It is the other way around. 9p can't handle latency so on high latency pipes programs using 9p won't be as fast as programs using streaming (instead of rpc). Granted that there are many other factors when it comes to hg & replica but latency is a major one. > similarly, you blame c++ compilers for excessive inlining. I am suggesting modern compilers should ignore the inline keyword and be cache aware. For the same reason as why the register keyword is mostly ignored. People are wont to use inlining in the hope of improving performance (just as they used register). Sometime it is better to fix a program than try educating the hordes. Actually what I'd really like to suggest is C++ shouldn't be used at all :-) ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:46 ` Bakul Shah @ 2011-02-18 20:15 ` erik quanstrom 2011-02-18 21:06 ` John Floren 2011-02-24 10:09 ` [9fans] Modern development language for Plan 9, Greg Comeau 1 sibling, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-18 20:15 UTC (permalink / raw) To: 9fans > > i don't think that it makes sense to say that since replica > > is slow and hg/rsync are fast, it follows that 9p is slow. > > It is the other way around. 9p can't handle latency so on > high latency pipes programs using 9p won't be as fast as > programs using streaming (instead of rpc). Granted that there > are many other factors when it comes to hg & replica but > latency is a major one. you're still comparing apples and girraffes. rsync/hg have protocols ment for syncing. replica uses 9p, which is not a protocol designed for syncing. it's designed for regular file access. it would be similarly difficult to use rsync's protocol directly for file access. while 9p can and should be improved upon, this case doesn't seem like a real motivator. the nfs guys don't complain similarly about nfs loosing to rsync. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 20:15 ` erik quanstrom @ 2011-02-18 21:06 ` John Floren 2011-02-18 22:21 ` Bakul Shah 2011-02-19 15:36 ` erik quanstrom 0 siblings, 2 replies; 192+ messages in thread From: John Floren @ 2011-02-18 21:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Feb 18, 2011 at 12:15 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> > i don't think that it makes sense to say that since replica >> > is slow and hg/rsync are fast, it follows that 9p is slow. >> >> It is the other way around. 9p can't handle latency so on >> high latency pipes programs using 9p won't be as fast as >> programs using streaming (instead of rpc). Granted that there >> are many other factors when it comes to hg & replica but >> latency is a major one. > > you're still comparing apples and girraffes. rsync/hg have > protocols ment for syncing. replica uses 9p, which is not a > protocol designed for syncing. it's designed for regular file > access. it would be similarly difficult to use rsync's protocol > directly for file access. > So why does replica use 9P? Because it's *The Plan 9 Protocol*. If *The Plan 9 Protocol* turns out to not serve our needs, we need to figure out why. You like to put forward devmnt's penchant for only having one Tread/Twrite per process in flight at one time. I agree that this is a problem, now, how do we fix it? All it needs is somebody willing to rewrite devmnt... I think you may just have to rewrite mntrdwr to be just a little smarter. Any takers? 9P as specified in the documentation might not necessarily be the problem, but the implementation apparently is. > while 9p can and should be improved upon, this case doesn't > seem like a real motivator. the nfs guys don't complain similarly > about nfs loosing to rsync. > > - erik I don't see the NFS guys pretending that NFS is a good protocol for transferring large files across high-latency links... I've only ever heard of it being used in LAN environments. Yet 9P, which is not really that dissimilar for NFS in basic concept, gets presented as something we ought to be using over the Internet, for example to keep our systems updated. John ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 21:06 ` John Floren @ 2011-02-18 22:21 ` Bakul Shah 2011-02-18 23:39 ` [9fans] Modern development language for Plan 9, Lyndon Nerenberg (VE6BBM/VE7TFX) ` (3 more replies) 2011-02-19 15:36 ` erik quanstrom 1 sibling, 4 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-18 22:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 18 Feb 2011 13:06:43 PST John Floren <john@jfloren.net> wrote: > On Fri, Feb 18, 2011 at 12:15 PM, erik quanstrom <quanstro@quanstro.net> wr= > ote: > >> > i don't think that it makes sense to say that since replica > >> > is slow and hg/rsync are fast, it follows that 9p is slow. > >> > >> It is the other way around. 9p can't handle latency so on > >> high latency pipes programs using 9p won't be as fast as > >> programs using streaming (instead of rpc). Granted that there > >> are many other factors when it comes to hg & replica but > >> latency is a major one. > > > > you're still comparing apples and girraffes. =A0rsync/hg have > > protocols ment for syncing. =A0replica uses 9p, which is not a > > protocol designed for syncing. =A0it's designed for regular file > > access. =A0it would be similarly difficult to use rsync's protocol > > directly for file access. > > So why does replica use 9P? Because it's *The Plan 9 Protocol*. If > *The Plan 9 Protocol* turns out to not serve our needs, we need to > figure out why. The point I was trying to make (but clearly not clearly) was that simplicity and performance are often at cross purposes and a simple solution is not always "good enough". RPC (which is what 9p is) is simpler and perfectly fine when latencies are small but not when there is a lot of latency in relation to the amount of work doable with each rpc call. Instead of reading/writing in small chunks, you want to minimize the number of request/response round trips by conveying information at a more abstract level (which is what rsync does). > 9P as specified in the documentation might not necessarily be the > problem, but the implementation apparently is. It is inherent to 9p (and RPC). The wikipedia page on plan9 says "Plan 9 was engineered for modern distributed environments, designed from the start to be a networked operating system." -- but it _is_ curious that a networked/distributed OS does not handle latency well. This may be a heretical thing to say but there it is :-) I think it is worth looking at a successor protocol instead of just minimally fixing up 9p (a clean slate approach frees up your mind. You can then merge the two later). ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, 2011-02-18 22:21 ` Bakul Shah @ 2011-02-18 23:39 ` Lyndon Nerenberg (VE6BBM/VE7TFX) 2011-02-19 10:26 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Steve Simon ` (2 subsequent siblings) 3 siblings, 0 replies; 192+ messages in thread From: Lyndon Nerenberg (VE6BBM/VE7TFX) @ 2011-02-18 23:39 UTC (permalink / raw) To: 9fans > I think it is worth looking at a successor protocol instead > of just minimally fixing up 9p (a clean slate approach frees > up your mind. You can then merge the two later). 9p is fine for what it is. If you want to talk to Mars, a new metaphor is required, not the rape and bastardization of 9p. Mars seems to be any place beyond 100ms reach of 'here'. --lyndon ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 22:21 ` Bakul Shah 2011-02-18 23:39 ` [9fans] Modern development language for Plan 9, Lyndon Nerenberg (VE6BBM/VE7TFX) @ 2011-02-19 10:26 ` Steve Simon 2011-02-19 15:09 ` erik quanstrom 2011-02-19 16:57 ` Skip Tavakkolian 3 siblings, 0 replies; 192+ messages in thread From: Steve Simon @ 2011-02-19 10:26 UTC (permalink / raw) To: 9fans > So why does replica use 9P? Because it's *The Plan 9 Protocol*. If > *The Plan 9 Protocol* turns out to not serve our needs, we need to > figure out why. I really don't get this, what is the problem with replica's speed? I run replica once every week or two and it typically runs for about 30 secconds. This is not a major part of my life, it doesn't stop me working in another window. 9p being slow over high latency links is occasionally an annoyance but replica is not a good example of this. -Steve ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 22:21 ` Bakul Shah 2011-02-18 23:39 ` [9fans] Modern development language for Plan 9, Lyndon Nerenberg (VE6BBM/VE7TFX) 2011-02-19 10:26 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Steve Simon @ 2011-02-19 15:09 ` erik quanstrom 2011-02-19 20:09 ` Bakul Shah 2011-02-19 16:57 ` Skip Tavakkolian 3 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-19 15:09 UTC (permalink / raw) To: 9fans > The point I was trying to make (but clearly not clearly) was > that simplicity and performance are often at cross purposes > and a simple solution is not always "good enough". RPC > (which is what 9p is) is simpler and perfectly fine when > latencies are small but not when there is a lot of latency in > relation to the amount of work doable with each rpc call. this is a pretty general claim. but i don't see the argument. the difference between, e.g. tcp and an explicitly rpc protocol like 9p is basically 2 relevant things 1. 9p requires 1:1 message and reply; tcp can combine replies 2. 9p sends a set of tagged messages; tcp sends an ordered byte stream. i don't see how either one is necessarly going to slow 9p down. the structure of 9p (tagged rpc) is the same for reads & writes as aoe. aoe is always talking over a long fat network with large jitter, as disk drives are slow and sometimes misseek but have relatively large bandwidth. i've had no trouble filling even 10gbe pipes with aoe traffic. > Instead of reading/writing in small chunks, you want to > minimize the number of request/response round trips by > conveying information at a more abstract level (which is > what rsync does). that's not what rsync does. rsync calculates and sends the differences. that's not on the same planet as 9p. by the way, rsync is fundamentally broken. it takes unbounded memory to do its job. > It is inherent to 9p (and RPC). please defend this. i don't see any evidence for this bald claim. > I think it is worth looking at a successor protocol instead > of just minimally fixing up 9p (a clean slate approach frees > up your mind. You can then merge the two later). what is the goal? without a clear problem to solve that you can build a system around, i don't see the point. making replica fast doesn't seem like sufficient motivation to me at all. as to the problem of latency, i think there are two things i note 1. plan 9 can work well with latency. most days i do some link that has 25-2000ms latency. the way plan 9 is structured, this latency is not very noticable until it reaches ~750ms, and then only when i'm saving files, or sometimes, due to an oversite or bug in acme, when searching. clearly a kernel mk over a 2000ms link will take nearly forever, but you don't have to do that. you can cpu where you need to be and work there. 2. at cross-u.s. latencies of 80ms, serial file operations like mk can be painful. if bringing the work to the data doesn't work or still takes too many rtts, the only solution i see is to cache everything. and try to manage coherence vs. latency. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-19 15:09 ` erik quanstrom @ 2011-02-19 20:09 ` Bakul Shah 2011-02-19 21:15 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Bakul Shah @ 2011-02-19 20:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, 19 Feb 2011 10:09:08 EST erik quanstrom <quanstro@quanstro.net> wrote: > > It is inherent to 9p (and RPC). > > please defend this. i don't see any evidence for this bald claim. We went over latency issues multiple times in the past but let us take your 80ms latency. You can get 12.5 rpc calls through in 1 sec even if you take 0 seconds to generate & process each request & response. If each call transfers 64K, at most you get a throughput of 800KB/sec. If you pipeline your requests, without waiting for each reply, you are using streaming. To avoid `streaming' you can setup N parallel connections but that is again adding a lot of complexity to a relatively simple problem. > > I think it is worth looking at a successor protocol instead > > of just minimally fixing up 9p (a clean slate approach frees > > up your mind. You can then merge the two later). > > what is the goal? Better handling of latency at a minimum? If I were to do this I would experiment with extending the channel concept. > without a clear problem to solve that you > can build a system around, i don't see the point. making replica > fast doesn't seem like sufficient motivation to me at all. No. I just use Ron's hg repo now. > 2. at cross-u.s. latencies of 80ms, serial file operations like > mk can be painful. if bringing the work to the data doesn't work > or still takes too many rtts, the only solution i see is to cache everything. > and try to manage coherence vs. latency. For things like remote copy of a whole bunch of files caching is not going to help you much but streaming will. So will increasing parllelism (upto a point). Compression might. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-19 20:09 ` Bakul Shah @ 2011-02-19 21:15 ` erik quanstrom 2011-02-20 23:49 ` Bakul Shah 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-19 21:15 UTC (permalink / raw) To: 9fans On Sat Feb 19 15:10:58 EST 2011, bakul+plan9@bitblocks.com wrote: > On Sat, 19 Feb 2011 10:09:08 EST erik quanstrom <quanstro@quanstro.net> wrote: > > > It is inherent to 9p (and RPC). > > > > please defend this. i don't see any evidence for this bald claim. > > We went over latency issues multiple times in the past but > let us take your 80ms latency. You can get 12.5 rpc calls > through in 1 sec even if you take 0 seconds to generate & > process each request & response. If each call transfers 64K, > at most you get a throughput of 800KB/sec. If you pipeline > your requests, without waiting for each reply, you are using > streaming. To avoid `streaming' you can setup N parallel > connections but that is again adding a lot of complexity to a > relatively simple problem. i think that your analysis of 9p rpc is missing the fact that each read() or write() can have 1 out standing through the mount driver. so the mountpt can have > 800kb/s in your example if multiple reads or writes are oustanding. also, sending concurrent rpc doesn't seem the the same to me as a stream since there's no requirement that the rpcs are sent, arrive or are processed in order. in plan 9, one would assume they would be sent in order. (wikipedia's definition.) and i don't really see that this is complicated. the same logic is in devaoe(3). the logic is trivial. > > what is the goal? > > Better handling of latency at a minimum? If I were to do > this I would experiment with extending the channel concept. hmm. let me try again ... do you have a concrete goal? it's hard to know why a new file protocol would be necessary given the very abstract goal of "reduced latency". for example, i would like to use 1 file server at 3 locations. 2 on the east coast, 1 on the west coast. the rtt is a:b 80ms a:c 20ms b:c 100ms. i don't think any sort of streaming will help that much. 100ms is a long time. i think (pre)caching will need to be the answer. > For things like remote copy of a whole bunch of files caching > is not going to help you much but streaming will. So will > increasing parllelism (upto a point). Compression might. that depends entirely on your setup. it may make sense to copy the files before anyone asks for them. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-19 21:15 ` erik quanstrom @ 2011-02-20 23:49 ` Bakul Shah 2011-02-21 14:47 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Bakul Shah @ 2011-02-20 23:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, 19 Feb 2011 16:15:47 EST erik quanstrom <quanstro@quanstro.net> wrote: > > > what is the goal? > > > > Better handling of latency at a minimum? If I were to do > > this I would experiment with extending the channel concept. > > hmm. let me try again ... do you have a concrete goal? > it's hard to know why a new file protocol would be necessary > given the very abstract goal of "reduced latency". Not reduced latency but increased throughput by streaming. Obviously a new protocol is not "necessary" but something worth exploring is what I said. > for example, i would like to use 1 file server at 3 locations. > 2 on the east coast, 1 on the west coast. the rtt is a:b 80ms > a:c 20ms b:c 100ms. i don't think any sort of streaming will > help that much. 100ms is a long time. i think (pre)caching will > need to be the answer. Caching is definitely worth doing but you don't always have the opportunity to do it. If you are copying a lot of files across, it would help quite a bit if you can just pipeline requests (or send fewer bundled requests). If you are copying very large files, streaming would help. When copying large amounts of data from various sources to a local file server, caching is not very relevant. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-20 23:49 ` Bakul Shah @ 2011-02-21 14:47 ` erik quanstrom 0 siblings, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-21 14:47 UTC (permalink / raw) To: 9fans > Caching is definitely worth doing but you don't always have > the opportunity to do it. If you are copying a lot of files > across, it would help quite a bit if you can just pipeline > requests (or send fewer bundled requests). If you are copying > very large files, streaming would help. When copying large > amounts of data from various sources to a local file server, > caching is not very relevant. i'm not sure why the focus on copying a bunch of files. i wouldn't go to the effort to better stand-alone ftp/scp/http. the application is a file server and you choose to operate synchronously, between amdahl's law and the speed of light, you're going to be in quite a box. as a contrived example, imagine two nodes of a distributed fs 80ms apart. now imagine both nodes writing to /sys/log/timesync. naively copying and locking is going to be so slow that one imagines that timesync will drift off course. :-) - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 22:21 ` Bakul Shah ` (2 preceding siblings ...) 2011-02-19 15:09 ` erik quanstrom @ 2011-02-19 16:57 ` Skip Tavakkolian 3 siblings, 0 replies; 192+ messages in thread From: Skip Tavakkolian @ 2011-02-19 16:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs it seems to me that trying Op (Octopus) on Plan 9 would be a logical first step. On Fri, Feb 18, 2011 at 2:21 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote: > On Fri, 18 Feb 2011 13:06:43 PST John Floren <john@jfloren.net> wrote: >> On Fri, Feb 18, 2011 at 12:15 PM, erik quanstrom <quanstro@quanstro.net> wr= >> ote: >> >> > i don't think that it makes sense to say that since replica >> >> > is slow and hg/rsync are fast, it follows that 9p is slow. >> >> >> >> It is the other way around. 9p can't handle latency so on >> >> high latency pipes programs using 9p won't be as fast as >> >> programs using streaming (instead of rpc). Granted that there >> >> are many other factors when it comes to hg & replica but >> >> latency is a major one. >> > >> > you're still comparing apples and girraffes. =A0rsync/hg have >> > protocols ment for syncing. =A0replica uses 9p, which is not a >> > protocol designed for syncing. =A0it's designed for regular file >> > access. =A0it would be similarly difficult to use rsync's protocol >> > directly for file access. >> >> So why does replica use 9P? Because it's *The Plan 9 Protocol*. If >> *The Plan 9 Protocol* turns out to not serve our needs, we need to >> figure out why. > > The point I was trying to make (but clearly not clearly) was > that simplicity and performance are often at cross purposes > and a simple solution is not always "good enough". RPC > (which is what 9p is) is simpler and perfectly fine when > latencies are small but not when there is a lot of latency in > relation to the amount of work doable with each rpc call. > > Instead of reading/writing in small chunks, you want to > minimize the number of request/response round trips by > conveying information at a more abstract level (which is > what rsync does). > >> 9P as specified in the documentation might not necessarily be the >> problem, but the implementation apparently is. > > It is inherent to 9p (and RPC). > > The wikipedia page on plan9 says "Plan 9 was engineered for > modern distributed environments, designed from the start to > be a networked operating system." -- but it _is_ curious that > a networked/distributed OS does not handle latency well. This > may be a heretical thing to say but there it is :-) > > I think it is worth looking at a successor protocol instead > of just minimally fixing up 9p (a clean slate approach frees > up your mind. You can then merge the two later). > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 21:06 ` John Floren 2011-02-18 22:21 ` Bakul Shah @ 2011-02-19 15:36 ` erik quanstrom 1 sibling, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-19 15:36 UTC (permalink / raw) To: 9fans > So why does replica use 9P? Because it's *The Plan 9 Protocol*. If > *The Plan 9 Protocol* turns out to not serve our needs, we need to > figure out why. i appreciate the sentiment, but i think that's just taking it a wee bit overboard. we don't pretend that 9p replaces http, ftp, smtp, etc. venti/fossil don't even use 9p. nor does factotum, secstore nor the auth server. these last few might be mistakes, but it's clear that the thinking was never, we've got a 9p hammer, and all the world's a nail. that being said, i agree with steve. replica is a fine tool when used as intended. i think it assumes size(corpus) >> size(differences). when you use it as a file transfer mechanism, it doesn't work as well. note the bulk of plan 9 is distributed as an iso through http. this was necessary because before you have the iso, you don't have replica. (pre p9p, anyway.) so i don't see why bulk transfer would have been optimized. it's a simple tool for a narrow problem. and there are many ways to speed up replica if anyone cares to solve the problem. > You like to put forward devmnt's penchant for only having one > Tread/Twrite per process in flight at one time. I agree that this is a > problem, now, how do we fix it? All it needs is somebody willing to > rewrite devmnt... I think you may just have to rewrite mntrdwr to be > just a little smarter. Any takers? i think there are two things required. first, the mount driver needs to have the ability to send 1..n T(read write) messages at once (and therefore the ability to manage the number of outstanding) and a mount flag enabling multiple outstanding. bls suggssted that a mode bit could be added to each file. this would allow, e.g., exportfs to maintain multiple outstanding on some files but not others, but that would require an additional open mode that could be or'd with OREAD/OWRITE. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, 2011-02-18 19:46 ` Bakul Shah 2011-02-18 20:15 ` erik quanstrom @ 2011-02-24 10:09 ` Greg Comeau 1 sibling, 0 replies; 192+ messages in thread From: Greg Comeau @ 2011-02-24 10:09 UTC (permalink / raw) To: 9fans In article <20110218194658.8BEA75B77@mail.bitblocks.com>, Bakul Shah <bakul+plan9@bitblocks.com> wrote: >It is the other way around. 9p can't handle latency so on >high latency pipes programs using 9p won't be as fast as >programs using streaming (instead of rpc). Granted that there >are many other factors when it comes to hg & replica but >latency is a major one. > >> similarly, you blame c++ compilers for excessive inlining. > >I am suggesting modern compilers should ignore the inline >keyword and be cache aware. For the same reason as why the >register keyword is mostly ignored. People are wont to use >inlining in the hope of improving performance (just as they >used register). Sometime it is better to fix a program than >try educating the hordes. Indeed, and then some: http://comeaucomputing.com/techtalk/#whentoinline >Actually what I'd really like to suggest is C++ shouldn't >be used at all :-) Probably not much should be used at all :) -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:15 ` Bakul Shah 2011-02-18 19:26 ` erik quanstrom @ 2011-02-18 19:35 ` David Leimbach 2011-02-18 20:10 ` Bakul Shah 2011-02-18 23:55 ` Federico G. Benavento 1 sibling, 2 replies; 192+ messages in thread From: David Leimbach @ 2011-02-18 19:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Fans of the OS Plan 9 from Bell Labs Sent from my iPhone On Feb 18, 2011, at 11:15 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrote: > On Fri, 18 Feb 2011 10:46:51 PST Rob Pike <robpike@gmail.com> wrote: >> The more you optimize, the better the odds you slow your program down. >> Optimization adds instructions and often data, in one of the >> paradoxes of engineering. In time, then, what you gain by >> "optimizing" increases cache pressure and slows the whole thing down. > > You need a feedback loop. Uncontrolled anything is a recipe > for disaster. Optimizations need to be `judicious' but that > requires experience, profiling and understanding but the > trend seems to be away from that..... > > On a slightly different tangent, 9p is simple but it doesn't > handle latency very well. To make efficient use of long fat > pipes you need more complex mechanisms -- there is no getting > around that fact. rsync & hg in spite of their complexity > beat the pants off replica. Their cache behavior is not very > relevant here. Similarly file readahead is usually a win. > >> C++ inlines a lot because microbenchmarks improve, but inline every >> modest function in a big program and you make the binary much bigger >> and blow the i-cache. > > That's a compiler fault. Surely modern compilers need to be > cache aware? ideally a smart compiler treats `inline' as a hint > at most, just like `register'. > Well how does template expansion affect all of this? I've heard in conversations that C++ is pretty register hungry which makes me think lots of inlining happens behind the scenes. Then again that's an implementation detail, except maybe for templates. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:35 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely David Leimbach @ 2011-02-18 20:10 ` Bakul Shah 2011-02-18 21:03 ` ron minnich 2011-02-18 23:55 ` Federico G. Benavento 1 sibling, 1 reply; 192+ messages in thread From: Bakul Shah @ 2011-02-18 20:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, 18 Feb 2011 11:35:18 PST David Leimbach <leimy2k@gmail.com> wrote: > >> C++ inlines a lot because microbenchmarks improve, but inline every > >> modest function in a big program and you make the binary much bigger > >> and blow the i-cache. > > > > That's a compiler fault. Surely modern compilers need to be > > cache aware? ideally a smart compiler treats `inline' as a hint > > at most, just like `register'. > > Well how does template expansion affect all of this? I've heard in conversa= > tions that C++ is pretty register hungry which makes me think lots of inlini= > ng happens behind the scenes. Then again that's an implementation detail, e= > xcept maybe for templates.= Templates encourage inlining. There is at least one template libraries where the bulk of code is implemented in separate .cc files (using void* tricks), used by some embedded products. But IIRC the original STL from sgi was all in .h files and things don't seem to have changed much -- but I avoid them so who knows. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 20:10 ` Bakul Shah @ 2011-02-18 21:03 ` ron minnich 0 siblings, 0 replies; 192+ messages in thread From: ron minnich @ 2011-02-18 21:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Bakul Shah On Fri, Feb 18, 2011 at 12:10 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote: > Templates encourage inlining. There is at least one template > libraries where the bulk of code is implemented in separate > .cc files (using void* tricks), used by some embedded > products. But IIRC the original STL from sgi was all in .h > files and things don't seem to have changed much -- but I avoid > them so who knows. Very little of Boost libraries are libraries -- they are include files. If I have 100 files, and they include a lot of boost stuff, then I get to recompile the same Boost files many, many times. I spent several hours yesterday watching Boost "build" and then install -- 7000+ files in all. I guess it's all very useful. And modern. There was a C++ package called Pooma. It introduced the notion of 38 MB symbol tables and symbols so long (due to use of templates and so on) that they caused almost every extant C++ compiler to core dump in 1999 -- 256 characters is such a limitation on symbol name length ... the fix was to issue lots of money to people to "fix" their compiler to handle multi-thousand-character symbol names. ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:35 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely David Leimbach 2011-02-18 20:10 ` Bakul Shah @ 2011-02-18 23:55 ` Federico G. Benavento 2011-02-24 10:09 ` [9fans] Modern development language for Plan 9, Greg Comeau 1 sibling, 1 reply; 192+ messages in thread From: Federico G. Benavento @ 2011-02-18 23:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs afaik, templates might be inlined, static or shared... depending on the compiler and the flags. for gcc see: http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html On Fri, Feb 18, 2011 at 4:35 PM, David Leimbach <leimy2k@gmail.com> wrote: > > > Sent from my iPhone > > On Feb 18, 2011, at 11:15 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrote: > >> On Fri, 18 Feb 2011 10:46:51 PST Rob Pike <robpike@gmail.com> wrote: >>> The more you optimize, the better the odds you slow your program down. >>> Optimization adds instructions and often data, in one of the >>> paradoxes of engineering. In time, then, what you gain by >>> "optimizing" increases cache pressure and slows the whole thing down. >> >> You need a feedback loop. Uncontrolled anything is a recipe >> for disaster. Optimizations need to be `judicious' but that >> requires experience, profiling and understanding but the >> trend seems to be away from that..... >> >> On a slightly different tangent, 9p is simple but it doesn't >> handle latency very well. To make efficient use of long fat >> pipes you need more complex mechanisms -- there is no getting >> around that fact. rsync & hg in spite of their complexity >> beat the pants off replica. Their cache behavior is not very >> relevant here. Similarly file readahead is usually a win. >> >>> C++ inlines a lot because microbenchmarks improve, but inline every >>> modest function in a big program and you make the binary much bigger >>> and blow the i-cache. >> >> That's a compiler fault. Surely modern compilers need to be >> cache aware? ideally a smart compiler treats `inline' as a hint >> at most, just like `register'. >> > > Well how does template expansion affect all of this? I've heard in conversations that C++ is pretty register hungry which makes me think lots of inlining happens behind the scenes. Then again that's an implementation detail, except maybe for templates. > -- Federico G. Benavento ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, 2011-02-18 23:55 ` Federico G. Benavento @ 2011-02-24 10:09 ` Greg Comeau 0 siblings, 0 replies; 192+ messages in thread From: Greg Comeau @ 2011-02-24 10:09 UTC (permalink / raw) To: 9fans Some more info/thoughts to add to the gcc docs mentioned: http://www.comeaucomputing.com/4.0/docs/userman/ati.html In article <AANLkTikW2u13rSB2FUsc=tEVxmGe095FF69ZeXLwTy8E@mail.gmail.com>, Federico G. Benavento <benavento@gmail.com> wrote: >afaik, templates might be inlined, static or shared... depending on >the compiler and the flags. > >for gcc see: >http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html > > >On Fri, Feb 18, 2011 at 4:35 PM, David Leimbach <leimy2k@gmail.com> wrote: >> >> >> Sent from my iPhone >> >> On Feb 18, 2011, at 11:15 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrot= >e: >> >>> On Fri, 18 Feb 2011 10:46:51 PST Rob Pike <robpike@gmail.com> =C2=A0wrot= >e: >>>> The more you optimize, the better the odds you slow your program down. >>>> Optimization adds instructions and often data, in one of the >>>> paradoxes of engineering. =C2=A0In time, then, what you gain by >>>> "optimizing" increases cache pressure and slows the whole thing down. >>> >>> You need a feedback loop. =C2=A0Uncontrolled anything is a recipe >>> for disaster. Optimizations need to be `judicious' but that >>> requires experience, profiling and understanding but the >>> trend seems to be away from that..... >>> >>> On a slightly different tangent, 9p is simple but it doesn't >>> handle latency very well. =C2=A0To make efficient use of long fat >>> pipes you need more complex mechanisms -- there is no getting >>> around that fact. rsync & hg in spite of their complexity >>> beat the pants off replica. Their cache behavior is not very >>> relevant here. =C2=A0Similarly file readahead is usually a win. >>> >>>> C++ inlines a lot because microbenchmarks improve, but inline every >>>> modest function in a big program and you make the binary much bigger >>>> and blow the i-cache. >>> >>> That's a compiler fault. Surely modern compilers need to be >>> cache aware? ideally a smart compiler treats `inline' as a hint >>> at most, just like `register'. >>> >> >> Well how does template expansion affect all of this? =C2=A0I've heard in = >conversations that C++ is pretty register hungry which makes me think lots = >of inlining happens behind the scenes. =C2=A0Then again that's an implement= >ation detail, except maybe for templates. >> > > > >--=20 >Federico G. Benavento > -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 18:46 ` Rob Pike 2011-02-18 19:15 ` Bakul Shah @ 2011-02-18 19:15 ` Devon H. O'Dell 2011-02-21 5:08 ` smiley 1 sibling, 1 reply; 192+ messages in thread From: Devon H. O'Dell @ 2011-02-18 19:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2011/2/18 Rob Pike <robpike@gmail.com>: > The more you optimize, the better the odds you slow your program down. > Optimization adds instructions and often data, in one of the > paradoxes of engineering. In time, then, what you gain by > "optimizing" increases cache pressure and slows the whole thing down. > > C++ inlines a lot because microbenchmarks improve, but inline every > modest function in a big program and you make the binary much bigger > and blow the i-cache. I think what I've been trying to say in this thread doesn't clash with anything that you, Erik, or others have said. Understanding the system, the complexity you are introducing, and carefully measuring the net effect are all important parts of the optimization process. You can't just switch from one data structure to another. Skip lists are a really great example: they have really amazing properties, but you trash your cache when you use them, and gathering entropy to determine where a node is placed is *not* cheap. In the end, an optimization that slows things down is not an optimization at all. You can't do it if you don't understand what you're doing, and you don't understand the overall effect. I don't think that Linux's gettimeofday(2) optimization falls into this category, though I do think that some of the similar optimizations they've done using the same approach do. In this specific case, it is an easy optimization that is cheap and works quite well. It provides measurable performance improvements in the general case, as well as in special cases. As mentioned before, people who need more accurate times can still use rdtsc. > -rob --dho ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 19:15 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Devon H. O'Dell @ 2011-02-21 5:08 ` smiley 0 siblings, 0 replies; 192+ messages in thread From: smiley @ 2011-02-21 5:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "Devon H. O'Dell" <devon.odell@gmail.com> writes: > determine where a node is placed is *not* cheap. In the end, an > optimization that slows things down is not an optimization at all. You There are many different kinds of optimization one can perform. One may optimize compiled code for size, speed, simplicity, or reliability. One may optimize communications for throughput, latency, reliability, or bandwidth efficiency. Operations may be optimized to peform within guaranteed constraints, such as with real-time applications, bandwith contracting, etc. Very often, optimizing for one property sacrifices optimization in one or more of the others. For example, code optimized for speed may occupy more memory; code optimized for simplicity may run more slowly; etc. Which optimization (implementation) is chosen for a particular application depends on the intended use of the application. Ultimately, the resultant properties of the application should be reflected in its documentation. If an app like rsync is intended for -- and good at -- synchronizing files, but not as fast as wget for copying them, it would only be appropriate for rsync's documentation to indicate that design assumption. That way, the user can choose the application with the desired properties for the job. It's not possible simply to "optimize" code. It always has to be optimized for some specific set of intended uses. The design of a protocol (such as 9P) for a certain set of circumstances entails that it will perform better under some circumstances than others. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 17:07 ` erik quanstrom 2011-02-18 17:11 ` Devon H. O'Dell @ 2011-02-18 17:16 ` Russ Cox 1 sibling, 0 replies; 192+ messages in thread From: Russ Cox @ 2011-02-18 17:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: erik quanstrom On Fri, Feb 18, 2011 at 12:07 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> The high level overview is that it is stored in a shared page, mapped >> into each new process's memory space at start-up. The kernel is never >> entered; there are no context switches. The kernel has a timer that >> updates this page atomically. > > i wonder if that is uniformly faster. consider that > making reads of that page coherent enough on a > big multiprocessor and making sure there's not too > much interprocesser skew might be slower than a > system call. are you claiming that enter system call look at kernel data page to figure out time exit system call could be faster than look at kernel data page to figure out time ? either way the memory accesses in the middle are the same. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 16:59 ` Devon H. O'Dell 2011-02-18 17:07 ` erik quanstrom @ 2011-02-18 17:12 ` andrey mirtchovski 1 sibling, 0 replies; 192+ messages in thread From: andrey mirtchovski @ 2011-02-18 17:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > The kernel has a timer that > updates this page atomically. which timer updates the page even when nobody is interested in knowing what the time is, increasing the noise in the system[1]. i still keep graphs of a full-blown plan9 cpu server with users logged in and close to 200 running processes exhibiting very little deviation: http://mirtchovski.com/screenshots/ftq.jpg people are doing work negating the timer "optimization": http://ozlabs.org/~anton/linux/osjitter/ andrey [1] http://www.computer.org/portal/web/csdl/doi/10.1109/CLUSTR.2004.1392636 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-18 15:15 ` Devon H. O'Dell 2011-02-18 16:11 ` erik quanstrom 2011-02-18 16:53 ` dexen deVries @ 2011-02-19 10:34 ` Steve Simon 2011-02-19 17:25 ` dexen deVries 2 siblings, 1 reply; 192+ messages in thread From: Steve Simon @ 2011-02-19 10:34 UTC (permalink / raw) To: 9fans > Benchmark utilities to measure the overhead of syscalls. It's cheating > to do for getpid, but for other things like gettimeofday, it's > *extremely* nice. Linux's gettimeofday(2) beats the socks off of the > rest of the time implementations. About the only faster thing is to > get CPU speed and use rdtsc. Certainly no other OS allows you to get > the timestamp faster with a syscall. Here is where my memory gets hazy, however Solaris 2 had a very fast implementation of gettimeofday(), it was still a syscall I think but had a shortcut in the kernel. This was added (If I rembember correctly) to get a database (Sybase I think) to run on Solaris 2 as fast as it always used to run on SunOS. This was commented in the code as a special, ugly hack as a result of extreme pressure from an important customer. I wonder if Linux inherited the hack from Solaris? -Steve ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-19 10:34 ` Steve Simon @ 2011-02-19 17:25 ` dexen deVries 0 siblings, 0 replies; 192+ messages in thread From: dexen deVries @ 2011-02-19 17:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Saturday 19 of February 2011 11:34:19 Steve Simon wrote: > > Benchmark utilities to measure the overhead of syscalls. It's cheating > > to do for getpid, but for other things like gettimeofday, it's > > *extremely* nice. Linux's gettimeofday(2) beats the socks off of the > > rest of the time implementations. About the only faster thing is to > > get CPU speed and use rdtsc. Certainly no other OS allows you to get > > the timestamp faster with a syscall. > > Here is where my memory gets hazy, however Solaris 2 had a very fast > implementation of gettimeofday(), it was still a syscall I think but > had a shortcut in the kernel. > > This was added (If I rembember correctly) to get a database (Sybase > I think) to run on Solaris 2 as fast as it always used to run on SunOS. > This was commented in the code as a special, ugly hack as a result of > extreme pressure from an important customer. > > I wonder if Linux inherited the hack from Solaris? Perhaps the concept of providing very fast gettimeofday() at the cost of using an uncommon implementation, but not necessarily the actual implementation. Linux' gettimeofday() /is not a syscall/ at all. Devon posted the following earlier: > The high level overview is that it is stored in a shared page, mapped > into each new process's memory space at start-up. The kernel is never > entered; there are no context switches. The kernel has a timer that > updates this page atomically. > > --dho -- dexen deVries ``One can't proceed from the informal to the formal by formal means.'' ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 17:51 ` smiley 2011-02-01 18:33 ` ron minnich @ 2011-02-02 4:19 ` Federico G. Benavento 2011-02-02 19:15 ` smiley 1 sibling, 1 reply; 192+ messages in thread From: Federico G. Benavento @ 2011-02-02 4:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-02 4:19 ` [9fans] " Federico G. Benavento @ 2011-02-02 19:15 ` smiley 2011-02-02 21:47 ` ron minnich 2011-02-03 16:23 ` Noah Evans 0 siblings, 2 replies; 192+ messages in thread From: smiley @ 2011-02-02 19:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "Federico G. Benavento" <benavento@gmail.com> writes: > 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 Oh, really? Simple to find? Trivial? If so, then why wasn't that overflow found and fixed long before I ever laid eyes on it? (Rhetorical question, of course.) > bugs, iterators and the other crap you mentioned would had obfuscated > it. The "other crap" I mentioned would have made that bug IMPOSSIBLE. > Plan 9 is not bug-free, but they easier to find and fix, think about > that. I know you love Plan 9, and I have no desire to disrupt that relationship. I'm quite infatuated with it, myself. But neither of our loves' would be very realistic if we didn't admit that Plan 9 is just full of bugs like this. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-02 19:15 ` smiley @ 2011-02-02 21:47 ` ron minnich 2011-02-03 3:35 ` smiley 2011-02-03 16:23 ` Noah Evans 1 sibling, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-02 21:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Feb 2, 2011 at 11:15 AM, <smiley@zenzebra.mv.com> wrote: >> bugs, iterators and the other crap you mentioned would had obfuscated >> it. > > The "other crap" I mentioned would have made that bug IMPOSSIBLE. OK, let's do a test. You write your stuff with iterators and put it on a machine with 256MB. I'll create a file with a file name that is 257MB long. What does your stuff do then? ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-02 21:47 ` ron minnich @ 2011-02-03 3:35 ` smiley 2011-02-03 4:32 ` andrey mirtchovski ` (3 more replies) 0 siblings, 4 replies; 192+ messages in thread From: smiley @ 2011-02-03 3:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs ron minnich <rminnich@gmail.com> writes: > OK, let's do a test. You write your stuff with iterators and put it on > a machine with 256MB. I'll create a file with a file name that is > 257MB long. What does your stuff do then? The finished version will support strings backed by file storage and should actually be able to handle that. But that's still far in the future, at this point. I haven't even finished coding the basic string operations for data in memory, yet. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 3:35 ` smiley @ 2011-02-03 4:32 ` andrey mirtchovski 2011-02-03 6:15 ` Lucio De Re ` (2 subsequent siblings) 3 siblings, 0 replies; 192+ messages in thread From: andrey mirtchovski @ 2011-02-03 4:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > The finished version will support strings backed by file storage and I'm patiently waiting for strings backed by cloud storage. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 3:35 ` smiley 2011-02-03 4:32 ` andrey mirtchovski @ 2011-02-03 6:15 ` Lucio De Re 2011-02-03 7:54 ` dexen deVries 2011-02-03 18:45 ` Skip Tavakkolian 3 siblings, 0 replies; 192+ messages in thread From: Lucio De Re @ 2011-02-03 6:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 03, 2011 at 03:35:04AM +0000, smiley@zenzebra.mv.com wrote: > > The finished version will support strings backed by file storage and > should actually be able to handle that. But that's still far in the > future, at this point. I haven't even finished coding the basic string > operations for data in memory, yet. > And you propose finishing this by when? And re-inventing mmap by when? ++L ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 3:35 ` smiley 2011-02-03 4:32 ` andrey mirtchovski 2011-02-03 6:15 ` Lucio De Re @ 2011-02-03 7:54 ` dexen deVries 2011-02-03 9:48 ` Charles Forsyth 2011-02-03 18:45 ` Skip Tavakkolian 3 siblings, 1 reply; 192+ messages in thread From: dexen deVries @ 2011-02-03 7:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thursday, February 03, 2011 04:35:04 am smiley@zenzebra.mv.com wrote: > ron minnich <rminnich@gmail.com> writes: > > OK, let's do a test. You write your stuff with iterators and put it on > > a machine with 256MB. I'll create a file with a file name that is > > 257MB long. What does your stuff do then? > > The finished version will support strings backed by file storage and > should actually be able to handle that. But that's still far in the > future, at this point. I haven't even finished coding the basic string > operations for data in memory, yet. "The standard rule is, when you're in a hole, stop digging; that seems not to apply in software nowadays." -- dexen deVries [[[↓][→]]] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 7:54 ` dexen deVries @ 2011-02-03 9:48 ` Charles Forsyth 2011-02-03 13:01 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 9:48 UTC (permalink / raw) To: 9fans > The finished version will support strings backed by file storage string(2) doesn't go quite that far, but is used by the mailer upas and perhaps other things to reduce the instances of arbitrarily low limits and bounds exceeded. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 9:48 ` Charles Forsyth @ 2011-02-03 13:01 ` erik quanstrom 2011-02-03 13:40 ` roger peppe 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 13:01 UTC (permalink / raw) To: 9fans On Thu Feb 3 04:36:35 EST 2011, forsyth@terzarima.net wrote: > > The finished version will support strings backed by file storage > > string(2) doesn't go quite that far, but is used by the mailer upas > and perhaps other things to reduce the instances of arbitrarily low limits > and bounds exceeded. unfortunately string has an clunky interface. s_to_c, etc. and it begets clunky hacks that assume implementation. but i don't think you can do much better with the interface in c. Rune*s don't work very well and they've essentially doubled the functions in the c library. i think you're better off with char*s and realloc. it's worth looking at the heavy machinery in sam and acme, though, and comparing against ed. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 13:01 ` erik quanstrom @ 2011-02-03 13:40 ` roger peppe 2011-02-03 13:59 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: roger peppe @ 2011-02-03 13:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 3 February 2011 13:01, erik quanstrom <quanstro@quanstro.net> wrote: > i think you're better off with char*s and realloc. > it's worth looking at the heavy machinery in sam > and acme, though, and comparing against ed. i'd hesitate before trying to edit 500MB files in ed... nor does ed cope with arbitrary length lines. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 13:40 ` roger peppe @ 2011-02-03 13:59 ` erik quanstrom 2011-02-03 14:16 ` roger peppe 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 13:59 UTC (permalink / raw) To: 9fans On Thu Feb 3 08:41:23 EST 2011, rogpeppe@gmail.com wrote: > On 3 February 2011 13:01, erik quanstrom <quanstro@quanstro.net> wrote: > > i think you're better off with char*s and realloc. > > it's worth looking at the heavy machinery in sam > > and acme, though, and comparing against ed. > > i'd hesitate before trying to edit 500MB files in ed... > > nor does ed cope with arbitrary length lines. when has editing a 500mb text file ever been a problem? - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 13:59 ` erik quanstrom @ 2011-02-03 14:16 ` roger peppe 2011-02-03 14:17 ` erik quanstrom 2011-02-03 14:38 ` Charles Forsyth 0 siblings, 2 replies; 192+ messages in thread From: roger peppe @ 2011-02-03 14:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs i've found it very useful quite a few times. usually with oversized log files. On 3 February 2011 13:59, erik quanstrom <quanstro@quanstro.net> wrote: > On Thu Feb 3 08:41:23 EST 2011, rogpeppe@gmail.com wrote: >> On 3 February 2011 13:01, erik quanstrom <quanstro@quanstro.net> wrote: >> > i think you're better off with char*s and realloc. >> > it's worth looking at the heavy machinery in sam >> > and acme, though, and comparing against ed. >> >> i'd hesitate before trying to edit 500MB files in ed... >> >> nor does ed cope with arbitrary length lines. > > when has editing a 500mb text file ever been a problem? > > - erik > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 14:16 ` roger peppe @ 2011-02-03 14:17 ` erik quanstrom 2011-02-03 14:24 ` roger peppe 2011-02-03 14:38 ` Charles Forsyth 1 sibling, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 14:17 UTC (permalink / raw) To: 9fans On Thu Feb 3 09:17:27 EST 2011, rogpeppe@gmail.com wrote: > i've found it very useful quite a few times. > usually with oversized log files. > > On 3 February 2011 13:59, erik quanstrom <quanstro@quanstro.net> wrote: > > On Thu Feb 3 08:41:23 EST 2011, rogpeppe@gmail.com wrote: > >> On 3 February 2011 13:01, erik quanstrom <quanstro@quanstro.net> wrote: > >> > i think you're better off with char*s and realloc. > >> > it's worth looking at the heavy machinery in sam > >> > and acme, though, and comparing against ed. > >> > >> i'd hesitate before trying to edit 500MB files in ed... > >> > >> nor does ed cope with arbitrary length lines. > > > > when has editing a 500mb text file ever been a problem? it's not a log file if you edit it. ☺ - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 14:17 ` erik quanstrom @ 2011-02-03 14:24 ` roger peppe 0 siblings, 0 replies; 192+ messages in thread From: roger peppe @ 2011-02-03 14:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 3 February 2011 14:17, erik quanstrom <quanstro@quanstro.net> wrote: > On Thu Feb 3 09:17:27 EST 2011, rogpeppe@gmail.com wrote: >> i've found it very useful quite a few times. >> usually with oversized log files. >> >> On 3 February 2011 13:59, erik quanstrom <quanstro@quanstro.net> wrote: >> > On Thu Feb 3 08:41:23 EST 2011, rogpeppe@gmail.com wrote: >> >> On 3 February 2011 13:01, erik quanstrom <quanstro@quanstro.net> wrote: >> >> > i think you're better off with char*s and realloc. >> >> > it's worth looking at the heavy machinery in sam >> >> > and acme, though, and comparing against ed. >> >> >> >> i'd hesitate before trying to edit 500MB files in ed... >> >> >> >> nor does ed cope with arbitrary length lines. >> > >> > when has editing a 500mb text file ever been a problem? > > it's not a log file if you edit it. ☺ structural regexps are excellent for making sense of some log files... ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 14:16 ` roger peppe 2011-02-03 14:17 ` erik quanstrom @ 2011-02-03 14:38 ` Charles Forsyth 1 sibling, 0 replies; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 14:38 UTC (permalink / raw) To: 9fans >usually with oversized log files. sam -d, indeed! ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-03 3:35 ` smiley ` (2 preceding siblings ...) 2011-02-03 7:54 ` dexen deVries @ 2011-02-03 18:45 ` Skip Tavakkolian 3 siblings, 0 replies; 192+ messages in thread From: Skip Tavakkolian @ 2011-02-03 18:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs cool! it seems you could implement an fs with unlimited name length using the file-backed-strings and store the data as the file name; very efficient. On Wed, Feb 2, 2011 at 7:35 PM, <smiley@zenzebra.mv.com> wrote: > ron minnich <rminnich@gmail.com> writes: > >> OK, let's do a test. You write your stuff with iterators and put it on >> a machine with 256MB. I'll create a file with a file name that is >> 257MB long. What does your stuff do then? > > The finished version will support strings backed by file storage and > should actually be able to handle that. But that's still far in the > future, at this point. I haven't even finished coding the basic string > operations for data in memory, yet. > > -- > +---------------------------------------------------------------+ > |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---------------------------------------------------------------+ > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-02 19:15 ` smiley 2011-02-02 21:47 ` ron minnich @ 2011-02-03 16:23 ` Noah Evans 1 sibling, 0 replies; 192+ messages in thread From: Noah Evans @ 2011-02-03 16:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Plan 9 is a research operating system. It also happens that many people who use it for research also use it in production. Many of the engineering decisions that went into Plan 9 were a matter of priorities. The creators of Plan 9 chose a simple, comprehensible C compiler over more complex alternatives because it made understanding the transition from code on the page to code on the machine easier. There were experiments in other languages like Aleph(mentioned earlier) which were deprecated when the effort of maintaining them outweighed their benefits. Likewise Plan 9 doesn't have a real mode 16 bit assembler, all of the real mode code is written as packed macros for the regular assembler. It wasn't worth the effort. Many of the issues you bring up are similar. If the bugs you find keep you from getting productive work done on Plan 9, by all means submit a patch. If you desperately need a high level language to solve your problems, refer to the languages that other people on the list have mentioned and roll your own. If you'd like it to be adopted by the greater Plan 9 community, write in a way that an expert versed in the Plan 9 coding style could easily understand and modify it. Noah On Wed, Feb 2, 2011 at 8:15 PM, <smiley@zenzebra.mv.com> wrote: > "Federico G. Benavento" <benavento@gmail.com> writes: > >> 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 > > Oh, really? Simple to find? Trivial? If so, then why wasn't that > overflow found and fixed long before I ever laid eyes on it? > (Rhetorical question, of course.) > >> bugs, iterators and the other crap you mentioned would had obfuscated >> it. > > The "other crap" I mentioned would have made that bug IMPOSSIBLE. > >> Plan 9 is not bug-free, but they easier to find and fix, think about >> that. > > I know you love Plan 9, and I have no desire to disrupt that > relationship. I'm quite infatuated with it, myself. But neither of our > loves' would be very realistic if we didn't admit that Plan 9 is just > full of bugs like this. > > -- > +---------------------------------------------------------------+ > |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---------------------------------------------------------------+ > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:02 ` smiley 2011-02-01 6:26 ` Lucio De Re 2011-02-01 6:45 ` ron minnich @ 2011-02-01 8:25 ` Federico G. Benavento 2011-02-01 8:37 ` Akshat Kumar ` (2 subsequent siblings) 5 siblings, 0 replies; 192+ messages in thread From: Federico G. Benavento @ 2011-02-01 8:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:02 ` smiley ` (2 preceding siblings ...) 2011-02-01 8:25 ` Federico G. Benavento @ 2011-02-01 8:37 ` Akshat Kumar 2011-02-01 9:02 ` Federico G. Benavento 2011-02-01 14:11 ` erik quanstrom [not found] ` <AANLkTimYW2wofCNn1WB09cTVrQ69QxjPMZqY=Qrri5Xi@mail.gmail.com> 5 siblings, 1 reply; 192+ messages in thread From: Akshat Kumar @ 2011-02-01 8:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 8:37 ` Akshat Kumar @ 2011-02-01 9:02 ` Federico G. Benavento 0 siblings, 0 replies; 192+ messages in thread From: Federico G. Benavento @ 2011-02-01 9:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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: abcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnopabcdefghijklmnop rm: abc*: 'abc*' file does not exist lotte% On Tue, Feb 1, 2011 at 5:37 AM, Akshat Kumar <akumar@mail.nanosouffle.net> wrote: > 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 > > -- Federico G. Benavento ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] RESOLVED: recoving important header file rudely 2011-02-01 6:02 ` smiley ` (3 preceding siblings ...) 2011-02-01 8:37 ` Akshat Kumar @ 2011-02-01 14:11 ` erik quanstrom [not found] ` <AANLkTimYW2wofCNn1WB09cTVrQ69QxjPMZqY=Qrri5Xi@mail.gmail.com> 5 siblings, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-01 14:11 UTC (permalink / raw) To: 9fans > 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(f<0 || 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
[parent not found: <AANLkTimYW2wofCNn1WB09cTVrQ69QxjPMZqY=Qrri5Xi@mail.gmail.com>]
[parent not found: <AANLkTikM+LcEzaHMjWoSGubNnzXx-5h_bprQcJsrGnnG@mail.gmail.com>]
[parent not found: <AANLkTim4mPBHv8R=2XwdWaBc_aPHyRjj_CbdkgC8KZbd@mail.gmail.com>]
[parent not found: <AANLkTi=9HkdLfNLFWxddDkHWC8w_uWKPEnWQ4r2gD7an@mail.gmail.com>]
[parent not found: <AANLkTikjYkyW75PLm8z65=1+gTLUZLxG-xcN9wkQVuPr@mail.gmail.com>]
[parent not found: <AANLkTimLMLsWWQtVPZwGb0qwFxjbpy05qVZHDv92LfYY@mail.gmail.com>]
[parent not found: <AANLkTimoXQLMpciQh_tLRfS5ht8ONFvqz2QXEC0td2G4@mail.gmail.com>]
[parent not found: <AANLkTimDXcriCuejuYZ2OixXVjoYckB-hcy9+FkMsjcS@mail.gmail.com>]
[parent not found: <AANLkTikmQuhyXh6qhgM4hgWK2N-EhebLkWtpf9OnUkx1@mail.gmail.com>]
* Re: [9fans] RESOLVED: recoving important header file rudely [not found] ` <AANLkTikmQuhyXh6qhgM4hgWK2N-EhebLkWtpf9OnUkx1@mail.gmail.com> @ 2011-02-01 17:20 ` Jacob Todd 0 siblings, 0 replies; 192+ messages in thread From: Jacob Todd @ 2011-02-01 17:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1738 bytes --] On Feb 1, 2011 1:05 AM, <smiley@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? [-- Attachment #2: Type: text/html, Size: 2014 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-29 22:47 [9fans] HELP: recoving important header file rudely clobbered by mk smiley ` (2 preceding siblings ...) 2011-01-29 23:24 ` [9fans] RESOLVED: " smiley @ 2011-02-01 6:54 ` ron minnich 2011-02-01 14:49 ` erik quanstrom 2011-02-01 16:25 ` Charles Forsyth 2011-02-01 7:01 ` Federico G. Benavento 4 siblings, 2 replies; 192+ messages in thread From: ron minnich @ 2011-02-01 6:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sat, Jan 29, 2011 at 2:47 PM, <smiley@zenzebra.mv.com> wrote: > I'm REALLY hoping someone can help me with this... > > BTW, apropos this sad tale, go ahead and install python and mercurial on your plan 9 system. Then set up a repo on a free place like bitbucket. Voila, standard tools, which make Plan 9 a better place (at 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. good luck! ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 6:54 ` [9fans] HELP: recoving important header file rudely clobbered by mk ron minnich @ 2011-02-01 14:49 ` erik quanstrom 2011-02-01 14:58 ` Eric Van Hensbergen 2011-02-01 16:41 ` ron minnich 2011-02-01 16:25 ` Charles Forsyth 1 sibling, 2 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-01 14:49 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 14:49 ` erik quanstrom @ 2011-02-01 14:58 ` Eric Van Hensbergen 2011-02-01 15:18 ` erik quanstrom 2011-02-01 16:41 ` ron minnich 1 sibling, 1 reply; 192+ messages in thread From: Eric Van Hensbergen @ 2011-02-01 14:58 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <quanstro@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 > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 14:58 ` Eric Van Hensbergen @ 2011-02-01 15:18 ` erik quanstrom 2011-02-01 15:37 ` Eric Van Hensbergen 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-01 15:18 UTC (permalink / raw) To: 9fans On Tue Feb 1 10:01:54 EST 2011, ericvh@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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 15:18 ` erik quanstrom @ 2011-02-01 15:37 ` Eric Van Hensbergen 2011-02-01 15:45 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Eric Van Hensbergen @ 2011-02-01 15:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <quanstro@labs.coraid.com> wrote: > On Tue Feb 1 10:01:54 EST 2011, ericvh@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 > > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 15:37 ` Eric Van Hensbergen @ 2011-02-01 15:45 ` erik quanstrom 2011-02-01 16:31 ` Eric Van Hensbergen 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-01 15:45 UTC (permalink / raw) To: 9fans On Tue Feb 1 10:40:33 EST 2011, ericvh@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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 15:45 ` erik quanstrom @ 2011-02-01 16:31 ` Eric Van Hensbergen 2011-02-01 16:45 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Eric Van Hensbergen @ 2011-02-01 16:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 1, 2011 at 9:45 AM, erik quanstrom <quanstro@labs.coraid.com> wrote: > On Tue Feb 1 10:40:33 EST 2011, ericvh@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 system....except when its not. Anyone have any cigars? -eric ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 16:31 ` Eric Van Hensbergen @ 2011-02-01 16:45 ` erik quanstrom 2011-02-01 16:59 ` ron minnich 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-01 16:45 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 16:45 ` erik quanstrom @ 2011-02-01 16:59 ` ron minnich 2011-02-02 3:46 ` Federico G. Benavento 0 siblings, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-01 16:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 1, 2011 at 8:45 AM, erik quanstrom <quanstro@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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 16:59 ` ron minnich @ 2011-02-02 3:46 ` Federico G. Benavento 0 siblings, 0 replies; 192+ messages in thread From: Federico G. Benavento @ 2011-02-02 3:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Two means, one end: don't lose that .h file! > I'm still waiting to see that crazy mkfile... -- Federico G. Benavento ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 14:49 ` erik quanstrom 2011-02-01 14:58 ` Eric Van Hensbergen @ 2011-02-01 16:41 ` ron minnich 1 sibling, 0 replies; 192+ messages in thread From: ron minnich @ 2011-02-01 16:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 1, 2011 at 6:49 AM, erik quanstrom <quanstro@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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 6:54 ` [9fans] HELP: recoving important header file rudely clobbered by mk ron minnich 2011-02-01 14:49 ` erik quanstrom @ 2011-02-01 16:25 ` Charles Forsyth 1 sibling, 0 replies; 192+ messages in thread From: Charles Forsyth @ 2011-02-01 16:25 UTC (permalink / raw) To: 9fans >Then set up a repo on a free place like bitbucket. or github. wasn't that in the news lately? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-01-29 22:47 [9fans] HELP: recoving important header file rudely clobbered by mk smiley ` (3 preceding siblings ...) 2011-02-01 6:54 ` [9fans] HELP: recoving important header file rudely clobbered by mk ron minnich @ 2011-02-01 7:01 ` Federico G. Benavento 2011-02-02 19:05 ` smiley 4 siblings, 1 reply; 192+ messages in thread From: Federico G. Benavento @ 2011-02-01 7:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 8l $LDFLAGS -o important.h important.h.8 I'm interested in seeing this mkfile which causes mk misbehavior -- Federico G. Benavento ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered by mk 2011-02-01 7:01 ` Federico G. Benavento @ 2011-02-02 19:05 ` smiley 2011-02-03 10:16 ` [9fans] HELP: recoving important header file rudely clobbered Richard Miller 2011-02-03 10:23 ` Richard Miller 0 siblings, 2 replies; 192+ messages in thread From: smiley @ 2011-02-02 19:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Enjoy... </$objtype/mkfile CFLAGS=-FTVwp binaries=app headers=important.h tarfile=app.tgz srcfiles=${binaries:%=%.c} $headers mkfile objfiles=${binaries:%=%.$O} all:V: $binaries app.$O: important.h %.$O: %.c $CC $CFLAGS $prereq %: %.$O $LD $LDFLAGS -o $target $prereq %.tgz: $srcfiles tar czf $target $prereq clean:VE: rm $objfiles $binaries $tarfile ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered 2011-02-02 19:05 ` smiley @ 2011-02-03 10:16 ` Richard Miller 2011-02-03 10:24 ` dexen deVries 2011-02-03 10:27 ` dexen deVries 2011-02-03 10:23 ` Richard Miller 1 sibling, 2 replies; 192+ messages in thread From: Richard Miller @ 2011-02-03 10:16 UTC (permalink / raw) To: 9fans > %: %.$O > $LD $LDFLAGS -o $target $prereq Not a good idea. '%' matches everything, not just files with no suffix. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered 2011-02-03 10:16 ` [9fans] HELP: recoving important header file rudely clobbered Richard Miller @ 2011-02-03 10:24 ` dexen deVries 2011-02-03 10:27 ` dexen deVries 1 sibling, 0 replies; 192+ messages in thread From: dexen deVries @ 2011-02-03 10:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thursday, February 03, 2011 11:16:05 am Richard Miller wrote: > > %: %.$O > > > > $LD $LDFLAGS -o $target $prereq > Perhaps wont' be a problem with mk(1), but make(1) had biten me more than once with a rule like `-o $SOMEOUTPUT $SOMESOURCES'. When $SOMEOUTPUT was empty... the source file that had the bad luck of being the first on $SOMEOUTPUT got overwritten. tl;dr: put -o $SOMEOUTPUT last in a recipe, at least for make(1) -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered 2011-02-03 10:16 ` [9fans] HELP: recoving important header file rudely clobbered Richard Miller 2011-02-03 10:24 ` dexen deVries @ 2011-02-03 10:27 ` dexen deVries 1 sibling, 0 replies; 192+ messages in thread From: dexen deVries @ 2011-02-03 10:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thursday, February 03, 2011 11:24:53 am dexen wrote: > On Thursday, February 03, 2011 11:16:05 am Richard Miller wrote: > > > %: %.$O > > > > > > $LD $LDFLAGS -o $target $prereq > > Perhaps wont' be a problem with mk(1), but make(1) had biten me more than > once with a rule like `-o $SOMEOUTPUT $SOMESOURCES'. When $SOMEOUTPUT was > empty... the source file that had the bad luck of being the first on > $SOMEOUTPUT got overwritten. > > tl;dr: put -o $SOMEOUTPUT last in a recipe, at least for make(1) edit: the first on $SOMESOURCES* got overwritten -- dexen deVries [[[↓][→]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered 2011-02-02 19:05 ` smiley 2011-02-03 10:16 ` [9fans] HELP: recoving important header file rudely clobbered Richard Miller @ 2011-02-03 10:23 ` Richard Miller 2011-02-03 10:37 ` roger peppe 1 sibling, 1 reply; 192+ messages in thread From: Richard Miller @ 2011-02-03 10:23 UTC (permalink / raw) To: 9fans On the other hand, can anyone explain this? term% cat foo.mk %: /dev/null echo making $target term% mk -f foo.mk x.y echo making x.y making x.y term% mk -f foo.mk x.y z.w echo making x.y making x.y echo making z.w making z.w echo making command line arguments making command line arguments term% ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered 2011-02-03 10:23 ` Richard Miller @ 2011-02-03 10:37 ` roger peppe 2011-02-03 10:48 ` Lucio De Re 0 siblings, 1 reply; 192+ messages in thread From: roger peppe @ 2011-02-03 10:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 3 February 2011 10:23, Richard Miller <9fans@hamnavoe.com> wrote: > On the other hand, can anyone explain this? > term% mk -f foo.mk x.y z.w > echo making x.y > making x.y > echo making z.w > making z.w > echo making command line arguments > making command line arguments > term% yes, it's because of this: /* fake a new rule with all the args as prereqs */ you're not supposed to have a metarule with a target that matches "command line arguments"! ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] HELP: recoving important header file rudely clobbered 2011-02-03 10:37 ` roger peppe @ 2011-02-03 10:48 ` Lucio De Re 0 siblings, 0 replies; 192+ messages in thread From: Lucio De Re @ 2011-02-03 10:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 03, 2011 at 10:37:39AM +0000, roger peppe wrote: > > you're not supposed to have a metarule with a target > that matches "command line arguments"! What would break if "mk" had an empty rule matching "command line arguments" itself? ++L ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely @ 2011-02-02 6:56 Jacob Todd 2011-02-02 7:06 ` ron minnich 2011-02-02 7:35 ` Nick LaForge 0 siblings, 2 replies; 192+ messages in thread From: Jacob Todd @ 2011-02-02 6:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 124 bytes --] And russ cox, and everyone else in the CONTRIBUTORS file. On Feb 2, 2011 12:39 AM, "Scott Sullivan" <scott@ss.org> wrote: [-- Attachment #2: Type: text/html, Size: 235 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 6:56 [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Jacob Todd @ 2011-02-02 7:06 ` ron minnich 2011-02-02 7:25 ` Bakul Shah 2011-02-02 7:25 ` Lucio De Re 2011-02-02 7:35 ` Nick LaForge 1 sibling, 2 replies; 192+ messages in thread From: ron minnich @ 2011-02-02 7:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 7:06 ` ron minnich @ 2011-02-02 7:25 ` Bakul Shah 2011-02-02 7:25 ` Lucio De Re 1 sibling, 0 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-02 7:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, 01 Feb 2011 23:06:33 PST ron minnich <rminnich@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? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 7:06 ` ron minnich 2011-02-02 7:25 ` Bakul Shah @ 2011-02-02 7:25 ` Lucio De Re 1 sibling, 0 replies; 192+ messages in thread From: Lucio De Re @ 2011-02-02 7:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 6:56 [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Jacob Todd 2011-02-02 7:06 ` ron minnich @ 2011-02-02 7:35 ` Nick LaForge 2011-02-02 17:45 ` David Leimbach 1 sibling, 1 reply; 192+ messages in thread From: Nick LaForge @ 2011-02-02 7:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <jaketodd422@gmail.com> wrote: > And russ cox, and everyone else in the CONTRIBUTORS file. > On Feb 2, 2011 12:39 AM, "Scott Sullivan" <scott@ss.org> wrote: > ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 7:35 ` Nick LaForge @ 2011-02-02 17:45 ` David Leimbach 2011-02-02 19:19 ` Bakul Shah 0 siblings, 1 reply; 192+ messages in thread From: David Leimbach @ 2011-02-02 17:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1302 bytes --] On Tue, Feb 1, 2011 at 11:35 PM, Nick LaForge <nicklaforge@gmail.com> wrote: > 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. > Well if I were funded and had an infinite amount of time I'd think LLVM for Plan 9 would be excellent, as well as Go on LLVM :-). > > Nick > > On 2/2/11, Jacob Todd <jaketodd422@gmail.com> wrote: > > And russ cox, and everyone else in the CONTRIBUTORS file. > > On Feb 2, 2011 12:39 AM, "Scott Sullivan" <scott@ss.org> wrote: > > > > [-- Attachment #2: Type: text/html, Size: 1940 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 17:45 ` David Leimbach @ 2011-02-02 19:19 ` Bakul Shah 2011-02-03 0:30 ` Charles Forsyth 2011-02-04 5:54 ` andrey mirtchovski 0 siblings, 2 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-02 19:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 02 Feb 2011 09:45:56 PST David Leimbach <leimy2k@gmail.com> wrote: > > Well if I were funded and had an infinite amount of time I'd think LLVM for > Plan 9 would be excellent, as well as Go on LLVM :-). llvm port would need c++. $ size /usr/local/bin/clang text data bss dec hex filename 22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang 1.2+ Million LOC in **/*.cpp **/*.h (though this includes tests etc.) Even gcc is smaller now! It boggles my mind they chose C++ instead of one of Scheme, Ocaml, Haskell or CL. Then there is libfirm (in C) which uses Cliff Click's ideas of a low level graph based intermediate representation. Seemed quite promising when I looked at it (a couple of years ago). It is much smaller than llvm (where they can be compared). But looks like most of funding oxygen has been going to llvm. http://pp.info.uni-karlsruhe.de/firm/Main_Page ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 19:19 ` Bakul Shah @ 2011-02-03 0:30 ` Charles Forsyth 2011-02-03 0:21 ` erik quanstrom 2011-02-04 5:54 ` andrey mirtchovski 1 sibling, 1 reply; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 0:30 UTC (permalink / raw) To: 9fans >$ size /usr/local/bin/clang > text data bss dec hex filename >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang impressive. certainly in the sense of `makes quite a dent if dropped'. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 0:30 ` Charles Forsyth @ 2011-02-03 0:21 ` erik quanstrom 2011-02-03 0:52 ` Charles Forsyth 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 0:21 UTC (permalink / raw) To: 9fans On Wed Feb 2 19:19:13 EST 2011, forsyth@terzarima.net wrote: > >$ size /usr/local/bin/clang > > text data bss dec hex filename > >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang > > impressive. certainly in the sense of `makes quite a dent if dropped'. and quite a clang. i worked on a project that big ... a 35yo 3d cad system. and to be fair to the cad system, most of its bulk was static tables. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 0:21 ` erik quanstrom @ 2011-02-03 0:52 ` Charles Forsyth 2011-02-03 0:50 ` ron minnich 2011-02-03 2:16 ` Bakul Shah 0 siblings, 2 replies; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 0:52 UTC (permalink / raw) To: 9fans > >$ size /usr/local/bin/clang > > text data bss dec hex filename > >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang i suppose a more useful comment might be a question: how does a C compiler get to be that big? what is all that code doing? ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 0:52 ` Charles Forsyth @ 2011-02-03 0:50 ` ron minnich 2011-02-03 2:16 ` Bakul Shah 1 sibling, 0 replies; 192+ messages in thread From: ron minnich @ 2011-02-03 0:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Feb 2, 2011 at 4:52 PM, Charles Forsyth <forsyth@terzarima.net> wrote: > i suppose a more useful comment might be a question: > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 0:52 ` Charles Forsyth 2011-02-03 0:50 ` ron minnich @ 2011-02-03 2:16 ` Bakul Shah 2011-02-03 2:25 ` David Leimbach ` (2 more replies) 1 sibling, 3 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-03 2:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth <forsyth@terzarima.net> wrote: > > >$ size /usr/local/bin/clang > > > text data bss dec hex filename > > >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang > > i suppose a more useful comment might be a question: > how does a C compiler get to be that big? what is all that code doing? It is a C/C++/Obj-C compiler & does static analysis, has backends for multiple processor types as well as C as a target, a lot of optimization tricks etc. See llvm.org. But frankly, I think they have lost the plot. C is basically a portable assembly programming language & in my highly biased opinion a C compiler should do no more than peephole optimizations. If you want more, might as well use a high level language. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 2:16 ` Bakul Shah @ 2011-02-03 2:25 ` David Leimbach 2011-02-03 2:26 ` erik quanstrom 2011-02-03 8:35 ` Charles Forsyth 2 siblings, 0 replies; 192+ messages in thread From: David Leimbach @ 2011-02-03 2:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1100 bytes --] On Wed, Feb 2, 2011 at 6:16 PM, Bakul Shah <bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com> > wrote: > On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth <forsyth@terzarima.net> > wrote: > > > >$ size /usr/local/bin/clang > > > > text data bss dec hex filename > > > >22842862 1023204 69200 23935266 16d3922 > /usr/local/bin/clang > > > > i suppose a more useful comment might be a question: > > how does a C compiler get to be that big? what is all that code doing? > > It is a C/C++/Obj-C compiler & does static analysis, has > backends for multiple processor types as well as C as a > target, a lot of optimization tricks etc. See llvm.org. But > frankly, I think they have lost the plot. C is basically a > portable assembly programming language & in my highly biased > opinion a C compiler should do no more than peephole > optimizations. If you want more, might as well use a high > level language. > > Don't forget objective-c++ :-). http://clang.llvm.org/features.html#simplecode has some interesting pictures and words [-- Attachment #2: Type: text/html, Size: 1616 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 2:16 ` Bakul Shah 2011-02-03 2:25 ` David Leimbach @ 2011-02-03 2:26 ` erik quanstrom 2011-02-03 15:08 ` David Leimbach 2011-02-03 8:35 ` Charles Forsyth 2 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 2:26 UTC (permalink / raw) To: 9fans > It is a C/C++/Obj-C compiler & does static analysis, has > backends for multiple processor types as well as C as a > target, a lot of optimization tricks etc. See llvm.org. But > frankly, I think they have lost the plot. C is basically a > portable assembly programming language & in my highly biased > opinion a C compiler should do no more than peephole > optimizations. If you want more, might as well use a high > level language. preach it, brother. i couldn't agree more. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 2:26 ` erik quanstrom @ 2011-02-03 15:08 ` David Leimbach 2011-02-03 16:19 ` Eugene Gorodinsky 2011-02-03 17:41 ` Bakul Shah 0 siblings, 2 replies; 192+ messages in thread From: David Leimbach @ 2011-02-03 15:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wednesday, February 2, 2011, erik quanstrom <quanstro@quanstro.net> wrote: >> It is a C/C++/Obj-C compiler & does static analysis, has >> backends for multiple processor types as well as C as a >> target, a lot of optimization tricks etc. See llvm.org. But >> frankly, I think they have lost the plot. C is basically a >> portable assembly programming language & in my highly biased >> opinion a C compiler should do no more than peephole >> optimizations. If you want more, might as well use a high >> level language. > > preach it, brother. i couldn't agree more. > > - erik > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt it? My understanding is LLVM is a stack of software that you compose other programming language tools by including the libraries you want. One might be able to remove the optimizing behaviors one doesn't want pretty easily, or write one's own optimizing layer that's stripped down. Then one could have the "do what I said" compiler instead of the "do what you think I meant" one. I believe there are occasions for each type of compiler really. It might seem really big and bloated but I still think what they've done is kind of neat. Making a real compiler in Haskell or O'Caml is pretty damned easy with LLVM bindings. I wonder how difficult it is to target Plan 9 with LLVM. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 15:08 ` David Leimbach @ 2011-02-03 16:19 ` Eugene Gorodinsky 2011-02-03 17:41 ` Bakul Shah 1 sibling, 0 replies; 192+ messages in thread From: Eugene Gorodinsky @ 2011-02-03 16:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1618 bytes --] To be fair, gcc, g++ and gobjc combined are actually bigger than clang+llvm. At least on my system. So it could have been worse. 2011/2/3 David Leimbach <leimy2k@gmail.com> > On Wednesday, February 2, 2011, erik quanstrom <quanstro@quanstro.net> > wrote: > >> It is a C/C++/Obj-C compiler & does static analysis, has > >> backends for multiple processor types as well as C as a > >> target, a lot of optimization tricks etc. See llvm.org. But > >> frankly, I think they have lost the plot. C is basically a > >> portable assembly programming language & in my highly biased > >> opinion a C compiler should do no more than peephole > >> optimizations. If you want more, might as well use a high > >> level language. > > > > preach it, brother. i couldn't agree more. > > > > - erik > > > > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt > it? My understanding is LLVM is a stack of software that you compose > other programming language tools by including the libraries you want. > One might be able to remove the optimizing behaviors one doesn't want > pretty easily, or write one's own optimizing layer that's stripped > down. Then one could have the "do what I said" compiler instead of > the "do what you think I meant" one. > > I believe there are occasions for each type of compiler really. > > It might seem really big and bloated but I still think what they've > done is kind of neat. Making a real compiler in Haskell or O'Caml is > pretty damned easy with LLVM bindings. > > I wonder how difficult it is to target Plan 9 with LLVM. > > [-- Attachment #2: Type: text/html, Size: 2192 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 15:08 ` David Leimbach 2011-02-03 16:19 ` Eugene Gorodinsky @ 2011-02-03 17:41 ` Bakul Shah 2011-02-03 18:11 ` erik quanstrom 2011-02-03 18:29 ` Joseph Stewart 1 sibling, 2 replies; 192+ messages in thread From: Bakul Shah @ 2011-02-03 17:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 03 Feb 2011 07:08:57 PST David Leimbach <leimy2k@gmail.com> wrote: > On Wednesday, February 2, 2011, erik quanstrom <quanstro@quanstro.net> wrote: > >> It is a C/C++/Obj-C compiler & does static analysis, has > >> backends for multiple processor types as well as C as a > >> target, a lot of optimization tricks etc. See llvm.org. But > >> frankly, I think they have lost the plot. C is basically a > >> portable assembly programming language & in my highly biased > >> opinion a C compiler should do no more than peephole > >> optimizations. If you want more, might as well use a high > >> level language. > > > > preach it, brother. i couldn't agree more. > > > > - erik > > > > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt > it? My understanding is LLVM is a stack of software that you compose > other programming language tools by including the libraries you want. > One might be able to remove the optimizing behaviors one doesn't want > pretty easily, or write one's own optimizing layer that's stripped > down. Then one could have the "do what I said" compiler instead of > the "do what you think I meant" one. I agree with their goal but not its execution. I think a toolkit for manipulating graph based program representations to build optimizing compilers is a great idea but did they do it in C++? Consider what `stalin' does in about 3300 lines of Scheme code. It translates R4RS scheme to C and takes a lot of time doing so but the code is generates is blazingly fast. The kind of globally optimized C code you or I wouldn't have the patience to write. Or the ability to keep all that context in one's head to do as good a job. Stalin compiles itself to over 660K lines of C code! Then you give this C code to gcc and it munches away for many minutes and finally dies on a 2GB system! If gcc was capable of only doing peephole optimizing, it would've been able to generate code much more quickly and without need gigabytes of memory. Given funding and a lot of free time it would make more sense to build a language agnostic optimizing toolkit by learning & stealing concepts/code from Stalin. Ideally: < src src-to-graph | optimizer | graph-to-C | cc > obj Where pipes are two way. > I believe there are occasions for each type of compiler really. Yes. > It might seem really big and bloated but I still think what they've > done is kind of neat. Making a real compiler in Haskell or O'Caml is > pretty damned easy with LLVM bindings. > > I wonder how difficult it is to target Plan 9 with LLVM. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 17:41 ` Bakul Shah @ 2011-02-03 18:11 ` erik quanstrom 2011-02-03 18:33 ` Bakul Shah 2011-02-03 18:29 ` Joseph Stewart 1 sibling, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 18:11 UTC (permalink / raw) To: 9fans > I agree with their goal but not its execution. I think a > toolkit for manipulating graph based program representations > to build optimizing compilers is a great idea but did they > do it in C++? are you sure that the problem isn't the graph representation? gcc also takes a graph-based approach. abstraction isn't free. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 18:11 ` erik quanstrom @ 2011-02-03 18:33 ` Bakul Shah 2011-02-03 18:54 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Bakul Shah @ 2011-02-03 18:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom <quanstro@quanstro.net> wrote: > > I agree with their goal but not its execution. I think a > > toolkit for manipulating graph based program representations > > to build optimizing compilers is a great idea but did they > > do it in C++? > > are you sure that the problem isn't the graph representation? > gcc also takes a graph-based approach. What problem? All programs are graphs in any case. Optimizations in effect replace one subgraph with another that has better properties. Global optimizers need to keep many more graphs in memory. But you can take short cuts when not optimizing -- if you know a graph is not going to change under you, you can generate code incrementally and may not even need to keep all subgraphs in memory. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 18:33 ` Bakul Shah @ 2011-02-03 18:54 ` erik quanstrom 2011-02-03 19:40 ` Bakul Shah 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 18:54 UTC (permalink / raw) To: 9fans On Thu Feb 3 13:33:52 EST 2011, bakul+plan9@bitblocks.com wrote: > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom <quanstro@quanstro.net> wrote: > > > I agree with their goal but not its execution. I think a > > > toolkit for manipulating graph based program representations > > > to build optimizing compilers is a great idea but did they > > > do it in C++? > > > > are you sure that the problem isn't the graph representation? > > gcc also takes a graph-based approach. > > What problem? the problem you yourself mentioned. gcc/llvm/etc have seem to have produced monsterously huge piles of code, out of all proportion to the problem at hand. i believe you're putting forth the theory that llvm is huge because it's c++. and i'm not so sure. > All programs are graphs in any case. Optimizations in effect > replace one subgraph with another that has better properties. > Global optimizers need to keep many more graphs in memory. > But you can take short cuts when not optimizing -- if you > know a graph is not going to change under you, you can > generate code incrementally and may not even need to keep all > subgraphs in memory. all programs are graphs implies that we should represent them as graphs? maybe all programs ar markov chains, too. ?c and ?a seem to get by fine using pseudoassembler instead of a graph. they are also quite a bit faster and smaller than their graph-based counterparts. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 18:54 ` erik quanstrom @ 2011-02-03 19:40 ` Bakul Shah 2011-02-03 20:33 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Bakul Shah @ 2011-02-03 19:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom <quanstro@quanstro.net> wrote: > On Thu Feb 3 13:33:52 EST 2011, bakul+plan9@bitblocks.com wrote: > > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom <quanstro@quanstro.net> wr > ote: > > > > I agree with their goal but not its execution. I think a > > > > toolkit for manipulating graph based program representations > > > > to build optimizing compilers is a great idea but did they > > > > do it in C++? > > > > > > are you sure that the problem isn't the graph representation? > > > gcc also takes a graph-based approach. > > > > What problem? > > the problem you yourself mentioned. gcc/llvm/etc have seem > to have produced monsterously huge piles of code, out of all > proportion to the problem at hand. > > i believe you're putting forth the theory that llvm is huge > because it's c++. and i'm not so sure. I must also say llvm has a lot of functionality. But even so there is a lot of bloat. Let me just say the bloat is due to many factors but it has far *less* to do with graphs. Download llvm and take a peek. I think the chosen language and the habits it promotes and the "impedance match" with the problem domain does play a significant role. At any rate, a graph representation would have `data' bloat if any, but not so much code bloat! > > All programs are graphs in any case. Optimizations in effect > > replace one subgraph with another that has better properties. > > Global optimizers need to keep many more graphs in memory. > > But you can take short cuts when not optimizing -- if you > > know a graph is not going to change under you, you can > > generate code incrementally and may not even need to keep all > > subgraphs in memory. > > all programs are graphs implies that we should represent them > as graphs? Or something equivalent. Example: How do you know moving an expression out of a for loop is valid? The optimizer needs to understand the control flow. The _model_ is graph based. But if you look at c/c++ code, typically the "graphiness" is hidden in a mess of ptrs. Which makes equivalent xforms on the representation harder. > seem to get by fine using pseudoassembler instead of a graph. > they are also quite a bit faster and smaller than their graph-based > counterparts. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 19:40 ` Bakul Shah @ 2011-02-03 20:33 ` erik quanstrom 2011-02-04 7:16 ` Bakul Shah 0 siblings, 1 reply; 192+ messages in thread From: erik quanstrom @ 2011-02-03 20:33 UTC (permalink / raw) To: 9fans > I must also say llvm has a lot of functionality. But even so > there is a lot of bloat. Let me just say the bloat is due to > many factors but it has far *less* to do with graphs. > Download llvm and take a peek. I think the chosen language > and the habits it promotes and the "impedance match" with the > problem domain does play a significant role. do you know of a compiler that uses a graph-based approach that isn't huge? > Or something equivalent. Example: How do you know moving an > expression out of a for loop is valid? The optimizer needs to > understand the control flow. is this still a useful thing to be doing? - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 20:33 ` erik quanstrom @ 2011-02-04 7:16 ` Bakul Shah 2011-02-04 14:38 ` erik quanstrom 0 siblings, 1 reply; 192+ messages in thread From: Bakul Shah @ 2011-02-04 7:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, 03 Feb 2011 15:33:57 EST erik quanstrom <quanstro@quanstro.net> wrote: > > I must also say llvm has a lot of functionality. But even so > > there is a lot of bloat. Let me just say the bloat is due to > > many factors but it has far *less* to do with graphs. > > Download llvm and take a peek. I think the chosen language > > and the habits it promotes and the "impedance match" with the > > problem domain does play a significant role. > > do you know of a compiler that uses a > graph-based approach that isn't huge? Stalin (source code ~3300 lines). There are others. > > Or something equivalent. Example: How do you know moving an > > expression out of a for loop is valid? The optimizer needs to > > understand the control flow. > > is this still a useful thing to be doing? Yes. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-04 7:16 ` Bakul Shah @ 2011-02-04 14:38 ` erik quanstrom 0 siblings, 0 replies; 192+ messages in thread From: erik quanstrom @ 2011-02-04 14:38 UTC (permalink / raw) To: 9fans > > > Or something equivalent. Example: How do you know moving an > > > expression out of a for loop is valid? The optimizer needs to > > > understand the control flow. > > > > is this still a useful thing to be doing? > > Yes. what's your argument? my argument is that the cpu is so fast relative to the network and disk, that wasting a few cycles is a good tradeoff for compiler and debugging simplicity, and compile speed. further, i'm not sure the compiler is in a position to know when strength reduction will make sense. intel, for example, does a lot of optimization that is "not architectural". that's code that means they won't tell you what will be a net win. i can think of a number of things that might defeat moving code out of a loop, such as the computation using otherwise idle functional units, keeping the value in the trace cache, keeping the value out of l2, the loop detector, etc. - erik ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 17:41 ` Bakul Shah 2011-02-03 18:11 ` erik quanstrom @ 2011-02-03 18:29 ` Joseph Stewart 1 sibling, 0 replies; 192+ messages in thread From: Joseph Stewart @ 2011-02-03 18:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 827 bytes --] Consider what `stalin' does in about 3300 lines of Scheme > code. It translates R4RS scheme to C and takes a lot of time > doing so but the code is generates is blazingly fast. The > kind of globally optimized C code you or I wouldn't have the > patience to write. Or the ability to keep all that context in > one's head to do as good a job. Stalin compiles itself to > over 660K lines of C code! Then you give this C code to gcc > and it munches away for many minutes and finally dies on a > 2GB system! If gcc was capable of only doing peephole > optimizing, it would've been able to generate code much more > quickly and without need gigabytes of memory. > Ha! Just tried to compile Stalin on my 4G laptop... it quickly became a laptop fryer... OUCH! I might try 6c or 8c in a bit for comparison. -joe [-- Attachment #2: Type: text/html, Size: 1087 bytes --] ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 2:16 ` Bakul Shah 2011-02-03 2:25 ` David Leimbach 2011-02-03 2:26 ` erik quanstrom @ 2011-02-03 8:35 ` Charles Forsyth 2011-02-03 8:56 ` EBo 2 siblings, 1 reply; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 8:35 UTC (permalink / raw) To: 9fans >It is a C/C++/Obj-C compiler & does static analysis, has >backends for multiple processor types as well as C as a >target, a lot of optimization tricks etc. 22mbytes is still a lot of "etc.". i've no objection to optimisations big and small, but that still wouldn't explain the size (to me). FORTRAN H Enhanced did so much with so little! if they combine every language and every target into one executable -- a "busybox" for compilers i suppose -- that might plump it up, but even then ... seriously, i'm just astounded. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 8:35 ` Charles Forsyth @ 2011-02-03 8:56 ` EBo 2011-02-03 9:46 ` Charles Forsyth 0 siblings, 1 reply; 192+ messages in thread From: EBo @ 2011-02-03 8:56 UTC (permalink / raw) To: 9fans On Thu, 3 Feb 2011 08:35:53 +0000, Charles Forsyth wrote: >>It is a C/C++/Obj-C compiler & does static analysis, has >>backends for multiple processor types as well as C as a >>target, a lot of optimization tricks etc. > > ... FORTRAN H Enhanced did so much with so little! ... Is there a compiler that does FORTRAN compiler for Plan 9? Or have I lost track of the thread? EBo -- ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 8:56 ` EBo @ 2011-02-03 9:46 ` Charles Forsyth 2011-02-03 9:47 ` EBo 0 siblings, 1 reply; 192+ messages in thread From: Charles Forsyth @ 2011-02-03 9:46 UTC (permalink / raw) To: 9fans FORTRAN H Enhanced was an early optimising compiler. FORTRAN H for System/360, then FORTRAN H Extended for System/370; FORTRAN H Enhanced added further insight to get better code. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 9:46 ` Charles Forsyth @ 2011-02-03 9:47 ` EBo 2011-02-03 9:50 ` Lucio De Re ` (2 more replies) 0 siblings, 3 replies; 192+ messages in thread From: EBo @ 2011-02-03 9:47 UTC (permalink / raw) To: 9fans On Thu, 3 Feb 2011 09:46:00 +0000, Charles Forsyth wrote: > FORTRAN H Enhanced was an early optimising compiler. > > FORTRAN H for System/360, then FORTRAN H Extended for System/370; > FORTRAN H Enhanced added further insight to get better code. Ah. Thanks for the info. I asked because some of the physicists and atmospheric scientists I work with are likely to insist on having FORTRAN. I still have not figured how I will deal with that if at all. EBo -- ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 9:47 ` EBo @ 2011-02-03 9:50 ` Lucio De Re 2011-02-03 10:38 ` C H Forsyth 2011-02-03 18:21 ` smiley 2 siblings, 0 replies; 192+ messages in thread From: Lucio De Re @ 2011-02-03 9:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 03, 2011 at 03:47:17AM -0600, EBo wrote: > > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at > all. > If the cost can be met, porting GCC 3.0 (the Hogan efforts) and the Fortran front end may be feasible. You may even be able to rope me into helping, but that is hardly a recommendation :-) ++L ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 9:47 ` EBo 2011-02-03 9:50 ` Lucio De Re @ 2011-02-03 10:38 ` C H Forsyth 2011-02-03 12:07 ` EBo 2011-02-03 18:21 ` smiley 2 siblings, 1 reply; 192+ messages in thread From: C H Forsyth @ 2011-02-03 10:38 UTC (permalink / raw) To: 9fans > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at all. it's not just the FORTRAN but supporting libraries, sometimes large ones, including ones in C++, are often required as well. i'd concluded that cross-compilation was currently the only effective route. i hadn't investigated whether something like linuxemu could be used (or extended easily enough) to allow cross-compilation within the plan 9 environment. i have found a few exceptions written in plain, reasonably portable C, good for my purposes, but not characteristic of scientific applications in general. ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 10:38 ` C H Forsyth @ 2011-02-03 12:07 ` EBo 2011-02-03 20:49 ` Federico G. Benavento 0 siblings, 1 reply; 192+ messages in thread From: EBo @ 2011-02-03 12:07 UTC (permalink / raw) To: 9fans On Thu, 3 Feb 2011 10:38:30 +0000, C H Forsyth wrote: > it's not just the FORTRAN but supporting libraries, sometimes large > ones, > including ones in C++, are often required as well. i'd concluded that > cross-compilation was currently the only effective route. > i hadn't investigated whether something like linuxemu could be > used (or extended easily enough) to allow cross-compilation within > the plan 9 environment. > > i have found a few exceptions written in plain, reasonably portable > C, good for my purposes, > but not characteristic of scientific applications in general. Agreed, and then there is the Netlib Java numerical analysis code -- That one gave be indigestion... One of the biggest problems is that no one wants rewrite linpack, blas, etc., not that it has been polished within an inch of the developers lives. As for FORTRAN, I thought about looking into the old f2c, and see how that worked for getting some FORTRAN compiled in Plan 9 as a demonstration. I'll think about linuxemu in this context. EBo -- ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 12:07 ` EBo @ 2011-02-03 20:49 ` Federico G. Benavento 2011-02-03 21:07 ` ron minnich 0 siblings, 1 reply; 192+ messages in thread From: Federico G. Benavento @ 2011-02-03 20:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I don't know if f2c meets your needs, but it has always worked. On Thu, Feb 3, 2011 at 9:07 AM, EBo <ebo@sandien.com> wrote: > On Thu, 3 Feb 2011 10:38:30 +0000, C H Forsyth wrote: >> >> it's not just the FORTRAN but supporting libraries, sometimes large ones, >> including ones in C++, are often required as well. i'd concluded that >> cross-compilation was currently the only effective route. >> i hadn't investigated whether something like linuxemu could be >> used (or extended easily enough) to allow cross-compilation within >> the plan 9 environment. >> >> i have found a few exceptions written in plain, reasonably portable >> C, good for my purposes, >> but not characteristic of scientific applications in general. > > Agreed, and then there is the Netlib Java numerical analysis code -- That > one gave be indigestion... > > One of the biggest problems is that no one wants rewrite linpack, blas, > etc., not that it has been polished within an inch of the developers lives. > > As for FORTRAN, I thought about looking into the old f2c, and see how that > worked for getting some FORTRAN compiled in Plan 9 as a demonstration. I'll > think about linuxemu in this context. > > EBo -- > > > -- Federico G. Benavento ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 20:49 ` Federico G. Benavento @ 2011-02-03 21:07 ` ron minnich 2011-02-03 21:32 ` Steve Simon 0 siblings, 1 reply; 192+ messages in thread From: ron minnich @ 2011-02-03 21:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento <benavento@gmail.com> wrote: > I don't know if f2c meets your needs, but it has always worked. As compared to modern fortran compilers, it is basically a toy. ron ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 21:07 ` ron minnich @ 2011-02-03 21:32 ` Steve Simon 2011-02-03 23:19 ` EBo 0 siblings, 1 reply; 192+ messages in thread From: Steve Simon @ 2011-02-03 21:32 UTC (permalink / raw) To: 9fans > > I don't know if f2c meets your needs, but it has always worked. > > > As compared to modern fortran compilers, it is basically a toy. > But he did say some of his source is in ratfor, I am pretty sure f2c would be happy with ratfor's output. years ago I supported the pafec FE package - tens of thousands of lines of Fortran. All the additions I made I did in ratfor, quite a reasonable language (compared to F77) I thought. -Steve ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 21:32 ` Steve Simon @ 2011-02-03 23:19 ` EBo 0 siblings, 0 replies; 192+ messages in thread From: EBo @ 2011-02-03 23:19 UTC (permalink / raw) To: 9fans On Thu, 3 Feb 2011 21:32:24 +0000, Steve Simon wrote: >> > I don't know if f2c meets your needs, but it has always worked. >> >> >> As compared to modern fortran compilers, it is basically a toy. >> > > But he did say some of his source is in ratfor, > I am pretty sure f2c would be happy with ratfor's output. > > years ago I supported the pafec FE package - tens of thousands of > lines > of Fortran. All the additions I made I did in ratfor, quite a > reasonable > language (compared to F77) I thought. Yes, I mentioned f2c WAY back in the thread. That was something I was going to try first. As for ratfor, I am not sure how much of that code I have to contend with, but I am aware of it's existence (and have written a few thousand lines in the distance past). EBo -- ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 9:47 ` EBo 2011-02-03 9:50 ` Lucio De Re 2011-02-03 10:38 ` C H Forsyth @ 2011-02-03 18:21 ` smiley 2011-02-03 18:50 ` John Floren 2 siblings, 1 reply; 192+ messages in thread From: smiley @ 2011-02-03 18:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs EBo <ebo@sandien.com> writes: > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at > all. I thought those folks used languages like Matlab & Mathematica for analysis, modeling, etc. At least those were what we used in the physics department @ RPI. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-03 18:21 ` smiley @ 2011-02-03 18:50 ` John Floren 0 siblings, 0 replies; 192+ messages in thread From: John Floren @ 2011-02-03 18:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Feb 3, 2011 at 10:21 AM, <smiley@zenzebra.mv.com> wrote: > EBo <ebo@sandien.com> writes: > >> Ah. Thanks for the info. I asked because some of the physicists and >> atmospheric scientists I work with are likely to insist on having >> FORTRAN. I still have not figured how I will deal with that if at >> all. > > I thought those folks used languages like Matlab & Mathematica for > analysis, modeling, etc. At least those were what we used in the > physics department @ RPI. > Matlab and Mathematica are great for quick stuff (loved Matlab for my engineering courses) but parallel scientific computing still loves its FORTRAN + MPI + LAPACK etc. The reason being that Matlab is extremely easy to write... but is also slow, and limited to one machine. FORTRAN is extremely primitive, but scientists like it because 1. It's simple (no pesky lambdas etc), 2. They're familiar with it, and 3. It's very efficient. For similar reasons, C + MPI is also quite popular. John ^ permalink raw reply [flat|nested] 192+ messages in thread
* Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely 2011-02-02 19:19 ` Bakul Shah 2011-02-03 0:30 ` Charles Forsyth @ 2011-02-04 5:54 ` andrey mirtchovski 1 sibling, 0 replies; 192+ messages in thread From: andrey mirtchovski @ 2011-02-04 5:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > $ size /usr/local/bin/clang > text data bss dec hex filename > 22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang "It is interesting to note the 5 minutes reduction in system time. I assume that this is in part because of the builtin assembler." -- http://blog.mozilla.com/respindola/2011/02/04/clang-results/ ^ permalink raw reply [flat|nested] 192+ messages in thread
end of thread, other threads:[~2011-02-24 10:09 UTC | newest] Thread overview: 192+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-29 22:47 [9fans] HELP: recoving important header file rudely clobbered by mk smiley 2011-01-29 22:54 ` erik quanstrom 2011-01-29 22:58 ` Steve Simon 2011-01-30 1:16 ` smiley 2011-01-30 4:07 ` John Floren 2011-01-30 4:49 ` erik quanstrom 2011-01-30 4:56 ` John Floren 2011-02-01 6:22 ` smiley 2011-02-01 6:47 ` Federico G. Benavento 2011-02-01 6:54 ` John Floren 2011-01-29 23:24 ` [9fans] RESOLVED: " smiley 2011-01-29 23:41 ` Steve Simon 2011-01-30 14:19 ` [9fans] RESOLVED: recoving important header file rudely Richard Miller 2011-01-30 14:28 ` erik quanstrom 2011-01-31 18:02 ` smiley 2011-01-31 22:12 ` Steve Simon 2011-02-01 6:02 ` smiley 2011-02-01 6:26 ` Lucio De Re 2011-02-01 7:07 ` smiley 2011-02-01 7:22 ` Lucio De Re 2011-02-01 13:45 ` erik quanstrom 2011-02-01 16:24 ` Charles Forsyth 2011-02-01 6:45 ` ron minnich 2011-02-01 17:51 ` smiley 2011-02-01 18:33 ` ron minnich 2011-02-01 19:16 ` jimmy frasche 2011-02-02 0:28 ` smiley 2011-02-02 0:42 ` erik quanstrom 2011-02-02 0:47 ` ron minnich 2011-02-02 5:14 ` [9fans] Modern development language for Plan 9, WAS: " smiley 2011-02-02 5:37 ` Scott Sullivan 2011-02-02 5:38 ` EBo 2011-02-02 15:54 ` Anthony Sorace 2011-02-02 12:54 ` erik quanstrom 2011-02-02 13:48 ` Devon H. O'Dell 2011-02-02 17:47 ` David Leimbach 2011-02-02 17:53 ` erik quanstrom 2011-02-02 18:07 ` tlaronde 2011-02-02 18:26 ` David Leimbach 2011-02-02 18:48 ` tlaronde 2011-02-02 19:26 ` Nick LaForge 2011-02-03 0:39 ` Charles Forsyth 2011-02-02 17:44 ` David Leimbach 2011-02-02 17:50 ` erik quanstrom 2011-02-02 18:15 ` Jonathan Cast 2011-02-02 18:21 ` erik quanstrom 2011-02-02 18:36 ` David Leimbach 2011-02-02 18:38 ` erik quanstrom 2011-02-02 18:46 ` David Leimbach 2011-02-02 19:15 ` Jonathan Cast 2011-02-02 19:31 ` erik quanstrom 2011-02-02 19:48 ` Jeff Sickel 2011-02-02 20:07 ` Jonathan Cast 2011-02-02 20:11 ` erik quanstrom 2011-02-02 20:22 ` Jonathan Cast 2011-02-02 18:21 ` David Leimbach 2011-02-03 10:00 ` [9fans] Modern development language for Plan 9, Greg Comeau 2011-02-02 18:03 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely erik quanstrom 2011-02-02 18:30 ` David Leimbach 2011-02-18 5:23 ` ron minnich 2011-02-18 5:34 ` Paul Lalonde 2011-02-18 13:29 ` erik quanstrom 2011-02-18 13:45 ` dexen deVries 2011-02-18 14:54 ` David Leimbach 2011-02-18 15:15 ` Devon H. O'Dell 2011-02-18 16:11 ` erik quanstrom 2011-02-18 16:28 ` Devon H. O'Dell 2011-02-18 16:49 ` erik quanstrom 2011-02-18 17:10 ` Devon H. O'Dell 2011-02-18 17:32 ` erik quanstrom 2011-02-18 17:44 ` ron minnich 2011-02-18 19:28 ` Devon H. O'Dell 2011-02-18 19:33 ` erik quanstrom 2011-02-18 19:49 ` Devon H. O'Dell 2011-02-18 18:43 ` Joseph Stewart 2011-02-18 17:05 ` andrey mirtchovski 2011-02-18 17:12 ` Devon H. O'Dell 2011-02-18 16:53 ` dexen deVries 2011-02-18 16:59 ` Devon H. O'Dell 2011-02-18 17:07 ` erik quanstrom 2011-02-18 17:11 ` Devon H. O'Dell 2011-02-18 17:21 ` erik quanstrom 2011-02-18 17:52 ` John Floren 2011-02-18 18:46 ` Rob Pike 2011-02-18 19:15 ` Bakul Shah 2011-02-18 19:26 ` erik quanstrom 2011-02-18 19:46 ` Bakul Shah 2011-02-18 20:15 ` erik quanstrom 2011-02-18 21:06 ` John Floren 2011-02-18 22:21 ` Bakul Shah 2011-02-18 23:39 ` [9fans] Modern development language for Plan 9, Lyndon Nerenberg (VE6BBM/VE7TFX) 2011-02-19 10:26 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Steve Simon 2011-02-19 15:09 ` erik quanstrom 2011-02-19 20:09 ` Bakul Shah 2011-02-19 21:15 ` erik quanstrom 2011-02-20 23:49 ` Bakul Shah 2011-02-21 14:47 ` erik quanstrom 2011-02-19 16:57 ` Skip Tavakkolian 2011-02-19 15:36 ` erik quanstrom 2011-02-24 10:09 ` [9fans] Modern development language for Plan 9, Greg Comeau 2011-02-18 19:35 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely David Leimbach 2011-02-18 20:10 ` Bakul Shah 2011-02-18 21:03 ` ron minnich 2011-02-18 23:55 ` Federico G. Benavento 2011-02-24 10:09 ` [9fans] Modern development language for Plan 9, Greg Comeau 2011-02-18 19:15 ` [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Devon H. O'Dell 2011-02-21 5:08 ` smiley 2011-02-18 17:16 ` Russ Cox 2011-02-18 17:12 ` andrey mirtchovski 2011-02-19 10:34 ` Steve Simon 2011-02-19 17:25 ` dexen deVries 2011-02-02 4:19 ` [9fans] " Federico G. Benavento 2011-02-02 19:15 ` smiley 2011-02-02 21:47 ` ron minnich 2011-02-03 3:35 ` smiley 2011-02-03 4:32 ` andrey mirtchovski 2011-02-03 6:15 ` Lucio De Re 2011-02-03 7:54 ` dexen deVries 2011-02-03 9:48 ` Charles Forsyth 2011-02-03 13:01 ` erik quanstrom 2011-02-03 13:40 ` roger peppe 2011-02-03 13:59 ` erik quanstrom 2011-02-03 14:16 ` roger peppe 2011-02-03 14:17 ` erik quanstrom 2011-02-03 14:24 ` roger peppe 2011-02-03 14:38 ` Charles Forsyth 2011-02-03 18:45 ` Skip Tavakkolian 2011-02-03 16:23 ` Noah Evans 2011-02-01 8:25 ` Federico G. Benavento 2011-02-01 8:37 ` Akshat Kumar 2011-02-01 9:02 ` Federico G. Benavento 2011-02-01 14:11 ` erik quanstrom [not found] ` <AANLkTimYW2wofCNn1WB09cTVrQ69QxjPMZqY=Qrri5Xi@mail.gmail.com> [not found] ` <AANLkTikM+LcEzaHMjWoSGubNnzXx-5h_bprQcJsrGnnG@mail.gmail.com> [not found] ` <AANLkTim4mPBHv8R=2XwdWaBc_aPHyRjj_CbdkgC8KZbd@mail.gmail.com> [not found] ` <AANLkTi=9HkdLfNLFWxddDkHWC8w_uWKPEnWQ4r2gD7an@mail.gmail.com> [not found] ` <AANLkTikjYkyW75PLm8z65=1+gTLUZLxG-xcN9wkQVuPr@mail.gmail.com> [not found] ` <AANLkTimLMLsWWQtVPZwGb0qwFxjbpy05qVZHDv92LfYY@mail.gmail.com> [not found] ` <AANLkTimoXQLMpciQh_tLRfS5ht8ONFvqz2QXEC0td2G4@mail.gmail.com> [not found] ` <AANLkTimDXcriCuejuYZ2OixXVjoYckB-hcy9+FkMsjcS@mail.gmail.com> [not found] ` <AANLkTikmQuhyXh6qhgM4hgWK2N-EhebLkWtpf9OnUkx1@mail.gmail.com> 2011-02-01 17:20 ` Jacob Todd 2011-02-01 6:54 ` [9fans] HELP: recoving important header file rudely clobbered by mk ron minnich 2011-02-01 14:49 ` erik quanstrom 2011-02-01 14:58 ` Eric Van Hensbergen 2011-02-01 15:18 ` erik quanstrom 2011-02-01 15:37 ` Eric Van Hensbergen 2011-02-01 15:45 ` erik quanstrom 2011-02-01 16:31 ` Eric Van Hensbergen 2011-02-01 16:45 ` erik quanstrom 2011-02-01 16:59 ` ron minnich 2011-02-02 3:46 ` Federico G. Benavento 2011-02-01 16:41 ` ron minnich 2011-02-01 16:25 ` Charles Forsyth 2011-02-01 7:01 ` Federico G. Benavento 2011-02-02 19:05 ` smiley 2011-02-03 10:16 ` [9fans] HELP: recoving important header file rudely clobbered Richard Miller 2011-02-03 10:24 ` dexen deVries 2011-02-03 10:27 ` dexen deVries 2011-02-03 10:23 ` Richard Miller 2011-02-03 10:37 ` roger peppe 2011-02-03 10:48 ` Lucio De Re 2011-02-02 6:56 [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Jacob Todd 2011-02-02 7:06 ` ron minnich 2011-02-02 7:25 ` Bakul Shah 2011-02-02 7:25 ` Lucio De Re 2011-02-02 7:35 ` Nick LaForge 2011-02-02 17:45 ` David Leimbach 2011-02-02 19:19 ` Bakul Shah 2011-02-03 0:30 ` Charles Forsyth 2011-02-03 0:21 ` erik quanstrom 2011-02-03 0:52 ` Charles Forsyth 2011-02-03 0:50 ` ron minnich 2011-02-03 2:16 ` Bakul Shah 2011-02-03 2:25 ` David Leimbach 2011-02-03 2:26 ` erik quanstrom 2011-02-03 15:08 ` David Leimbach 2011-02-03 16:19 ` Eugene Gorodinsky 2011-02-03 17:41 ` Bakul Shah 2011-02-03 18:11 ` erik quanstrom 2011-02-03 18:33 ` Bakul Shah 2011-02-03 18:54 ` erik quanstrom 2011-02-03 19:40 ` Bakul Shah 2011-02-03 20:33 ` erik quanstrom 2011-02-04 7:16 ` Bakul Shah 2011-02-04 14:38 ` erik quanstrom 2011-02-03 18:29 ` Joseph Stewart 2011-02-03 8:35 ` Charles Forsyth 2011-02-03 8:56 ` EBo 2011-02-03 9:46 ` Charles Forsyth 2011-02-03 9:47 ` EBo 2011-02-03 9:50 ` Lucio De Re 2011-02-03 10:38 ` C H Forsyth 2011-02-03 12:07 ` EBo 2011-02-03 20:49 ` Federico G. Benavento 2011-02-03 21:07 ` ron minnich 2011-02-03 21:32 ` Steve Simon 2011-02-03 23:19 ` EBo 2011-02-03 18:21 ` smiley 2011-02-03 18:50 ` John Floren 2011-02-04 5:54 ` andrey mirtchovski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).