Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 15:33:57 EST erik quanstrom 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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> $ 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/
Re: [9fans] files vs. directories
> >> >> > > This feature might be more useful if the directory entries > were > presented to clients of the FS in a textual format, but that > would > encourage, if not require, far more parsing in the system, and > that is > bad both for performance and for security. > > Sounds like a good argument for requests to potentially specify > response formats (at least in cases where the default is undesirable > or sub-optimal for performance reasons) wanted: interpreter droid to interpret the binary language of my moisture evaporators. - erik
Re: [9fans] files vs. directories
did i hear cloud-backed directory entries?
Re: [9fans] files vs. directories
On Feb 3, 2011, at 9:30 PM, Robert Ransom wrote: >> >> > > This feature might be more useful if the directory entries were > presented to clients of the FS in a textual format, but that would > encourage, if not require, far more parsing in the system, and that is > bad both for performance and for security. Sounds like a good argument for requests to potentially specify response formats (at least in cases where the default is undesirable or sub-optimal for performance reasons) -Eric
Re: [9fans] files vs. directories
On Thu, 3 Feb 2011 20:49:17 -0500 erik quanstrom wrote: > > FreeBSD 8.0 lets you cat the raw data of a directory, and I would > > expect the other free BSDs to have that misfeature, too. > > i don't see how allowing this is a misfeature. regardless, > plan 9 allows it. > > ; sha1sum < /adm/timezone > 05d16cd216a58fae746ae36f72c784d10bcc1392 It felt like a misfeature every time I dumped raw directory entries to my terminal, and I didn't think of a good use like your example. This feature might be more useful if the directory entries were presented to clients of the FS in a textual format, but that would encourage, if not require, far more parsing in the system, and that is bad both for performance and for security. Robert Ransom signature.asc Description: PGP signature
Re: [9fans] files vs. directories
> FreeBSD 8.0 lets you cat the raw data of a directory, and I would > expect the other free BSDs to have that misfeature, too. i don't see how allowing this is a misfeature. regardless, plan 9 allows it. ; sha1sum < /adm/timezone 05d16cd216a58fae746ae36f72c784d10bcc1392 - erik
Re: [9fans] files vs. directories
On Thu, 03 Feb 2011 18:42:39 + smi...@zenzebra.mv.com wrote: > There's no way that I know of to possibly interperet a path ending in > "/" as a file (with the exception of reading raw Dir data, as on Plan > 9 or "cat /" on, what was it, Solaris?). FreeBSD 8.0 lets you cat the raw data of a directory, and I would expect the other free BSDs to have that misfeature, too. Robert Ransom signature.asc Description: PGP signature
Re: [9fans] files vs. directories
> me wonders what ever happened to Hans... Is that really necessary? I'm guessing it was intended as a joke. Back in the 10th grade I spent a few months running a Reiser4 linux root. It was kind of a piece of junk, frequently locking up and giving inconsistent performance. C.f. http://en.wikipedia.org/wiki/Second-system_effect Nick
Re: [9fans] files vs. directories
try asking his jail warden. On Thu, Feb 3, 2011 at 4:24 PM, wrote: > /me wonders what ever happened to Hans...
Re: [9fans] files vs. directories
Eric Van Hensbergen writes: >> build an experimental OS around it! But if you go this path, >> do consider providing a few more datatypes in the filesystem >> (integers, file-id, strings, ...). Basically persistent data >> types. Or just use an object or relational database as your >> filesystem. IIRC, Reiserfs was aiming to incorporate general database semantics into the file system design. /me wonders what ever happened to Hans... > gets in the way of the sensible interface. The world has become > considerably richer than collections of byte-stream files, yet we have > no way of notionally representing richer structures in the name space. I occasionally daydream about having naming conventions like: $mtpt/timestamp# application interface node $mtpt/timestamp.printf # returns printf strings representing I/O format $mtpt/timestamp.usage # returns human readable help on "timestamp" file ...etc. -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 21:32:24 +, 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 --
Re: [9fans] files vs. directories
On Thu, Feb 3, 2011 at 10:58 AM, Bakul Shah wrote: > On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries > wrote: >> >> why do we keep distinction between files and directories? > > David Cheriton's `thoth' operating system didn't keep this > distinction. But every other OS I know of keeps them > separate. IIRC thoth provided functions for getting the > first child or next sibing given a path name. [Cheriton used > words like father, son, brother -- this was pre-PC!] > >> Does it provide any extra value over model with unified file/directory? > > They serve functions. A directory is an associative table, > indexed by a string key. A file is an array, indexed by an > integer. But most filesystems do store some attributes with a > file thus breaking this simple model. > > One advantage of always storing a directory with a file is > that you can represent file attributes via a directory. Then > you can have an extensible attributes model. XML probably > maps well to this model. > > Not sure doing so in plan9 makes any sense but you could > build an experimental OS around it! But if you go this path, > do consider providing a few more datatypes in the filesystem > (integers, file-id, strings, ...). Basically persistent data > types. Or just use an object or relational database as your > filesystem. > I'd tend to agree with this sentiment. I think, particularly in the construction of synthetic file hierarchies as interfaces, the tendency to do what is expected (from a disk file system perspective) often gets in the way of the sensible interface. The world has become considerably richer than collections of byte-stream files, yet we have no way of notionally representing richer structures in the name space. I've actually got some words on this in a position paper I've been crafting, I'll try to get it out posted to my blog before too long. -eric
Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9
On Thu, 03 Feb 2011 23:08:38 +, John Stalker wrote: I don't write in fortran, but I certainly link to libraries written in it. It is a truly awful language in any of its incarnations, but sometimes the library you need is in fortran. Fortunately it's not to hard to link to from C once you understand its calling conventions and array ordering. Agreed, but is there a FORTRAN compiler/cross-compiler for Plan 9? Isn't the compiler for plan9port a wrapper for gcc? If so, that should work for my purposes, but in general? EBo --
Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9
I don't write in fortran, but I certainly link to libraries written in it. It is a truly awful language in any of its incarnations, but sometimes the library you need is in fortran. Fortunately it's not to hard to link to from C once you understand its calling conventions and array ordering. > On Thu, 03 Feb 2011 18:21:28 +, smi...@zenzebra.mv.com 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. > > > > 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. > > Some of the scientists use those tools, but I am looking first at the > primary models like WRF , CMAQ and Air Quality>, etc., > > These are all written in FORTRAN 90/95/RatFOR, but some of the > underlying tools are written in C/C++, but only a few. If you can show > me a Matlab Global Circulation Model (even for a single cell, but which > accounts for the vertical profile and pressure) I'll arrange to buy you > a beer or your favorite beverage. > > I know of some of the energy budget models http://www.shodor.org/master/environmental/general/energy/application.html> > and similar things, but I would prefer to port something to HPD9 that > is a little more substantial. I want to couple various other models > like plant growth and survivorship, economics, etc. > >EBo -- > -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282
Re: [9fans] files vs. directories
On Thursday 03 of February 2011 19:42:39 smi...@zenzebra.mv.com wrote: > dexen deVries writes: > >> oh yes, maintaining the usual semantics for cp becomes tricky. > >> > >> mkdir z > >> cp x.c z > >> > >> do i mean to write x.c to z itself, or to a new file within z? > > > > nb., with the current semantics you *could* say `cp x.c z/' to be > > unambiguous you want to create a child of `z', but it seems to be common > > not to use trailing slash unless 100% necessary. > > dexen hits the nail on the head right there... files and directories > could be contextually distinguished from each other by always specifying > the directory name with a trailing "/". > > "foo.c/" means the directory foo.c/. > > "foo.c" means the file ./foo.c > > There's no way that I know of to possibly interperet a path ending in > "/" as a file (with the exception of reading raw Dir data, as on Plan > 9 or "cat /" on, what was it, Solaris?). I refuse to be signed under that idea. Really, I hate that idea. The trailing slash could only be for cp(1)'s interpretation of second argument -- it literally could mean, ``append the first argument's last component''. To have it a system-wide policy is overkill. It's only the small optimization done by cp(1) -- that is, it automagically appends first argument's last component to the last argument -- that makes this distinction sensible in some cases. tl;dr version: Hell no. -- dexen deVries ``One can't proceed from the informal to the formal by formal means.''
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> > 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
I don't know if f2c meets your needs, but it has always worked. On Thu, Feb 3, 2011 at 9:07 AM, EBo wrote: > On Thu, 3 Feb 2011 10:38:30 +, 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom wrote: > On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote: > > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom 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.
[9fans] FORTRAN and tools [was: Modern development language for Plan 9
On Thu, 03 Feb 2011 18:21:28 +, smi...@zenzebra.mv.com 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. 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. Some of the scientists use those tools, but I am looking first at the primary models like WRF , CMAQ and Air Quality>, etc., These are all written in FORTRAN 90/95/RatFOR, but some of the underlying tools are written in C/C++, but only a few. If you can show me a Matlab Global Circulation Model (even for a single cell, but which accounts for the vertical profile and pressure) I'll arrange to buy you a beer or your favorite beverage. I know of some of the energy budget models http://www.shodor.org/master/environmental/general/energy/application.html> and similar things, but I would prefer to port something to HPD9 that is a little more substantial. I want to couple various other models like plant growth and survivorship, economics, etc. EBo --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu Feb 3 13:33:52 EST 2011, bakul+pl...@bitblocks.com wrote: > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom > 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, Feb 3, 2011 at 10:21 AM, wrote: > EBo 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
Re: [9fans] RESOLVED: recoving important header file rudely
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, wrote: > ron minnich 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: smi...@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---+ > >
Re: [9fans] files vs. directories
dexen deVries writes: >> oh yes, maintaining the usual semantics for cp becomes tricky. >> >> mkdir z >> cp x.c z >> >> do i mean to write x.c to z itself, or to a new file within z? > > nb., with the current semantics you *could* say `cp x.c z/' to be unambiguous > you want to create a child of `z', but it seems to be common not to use > trailing slash unless 100% necessary. dexen hits the nail on the head right there... files and directories could be contextually distinguished from each other by always specifying the directory name with a trailing "/". "foo.c/" means the directory foo.c/. "foo.c" means the file ./foo.c There's no way that I know of to possibly interperet a path ending in "/" as a file (with the exception of reading raw Dir data, as on Plan 9 or "cat /" on, what was it, Solaris?). -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom 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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
EBo 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: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 07:08:57 PST David Leimbach wrote: > On Wednesday, February 2, 2011, erik quanstrom 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.
Re: [9fans] files vs. directories
On Thu, 03 Feb 2011 12:45:33 +0100 dexen deVries wrote: > > why do we keep distinction between files and directories? David Cheriton's `thoth' operating system didn't keep this distinction. But every other OS I know of keeps them separate. IIRC thoth provided functions for getting the first child or next sibing given a path name. [Cheriton used words like father, son, brother -- this was pre-PC!] > Does it provide any extra value over model with unified file/directory? They serve functions. A directory is an associative table, indexed by a string key. A file is an array, indexed by an integer. But most filesystems do store some attributes with a file thus breaking this simple model. One advantage of always storing a directory with a file is that you can represent file attributes via a directory. Then you can have an extensible attributes model. XML probably maps well to this model. Not sure doing so in plan9 makes any sense but you could build an experimental OS around it! But if you go this path, do consider providing a few more datatypes in the filesystem (integers, file-id, strings, ...). Basically persistent data types. Or just use an object or relational database as your filesystem. There are some uses for cloud based strings :-)
Re: [9fans] RESOLVED: recoving important header file rudely
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, wrote: > "Federico G. Benavento" 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: smi...@zenzebra.mv.com PGP key ID: BC549F8B| > |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| > +---+ > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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 > On Wednesday, February 2, 2011, erik quanstrom > 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. > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wednesday, February 2, 2011, erik quanstrom 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.
Re: [9fans] files vs. directories
On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in the root
> >> > object.
> >> >
> >> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> >> > hierarchical section of object `/foo'.
> >>
> >> there's no distinction between readdir and read in plan 9.
> >
> > Forgot about that. Still, you can't chdir() into an inode that doesn't
> > indicate being a directory. And the bytestream returned by
> > read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for
> > free- form bytestream.
>
> i don't think that helps you.
>
> under plan 9, reading a directory is this:
>
> translate(read(open(dir)))
>
> i don't see how you can make read(open(dir)) return
> something different.
>
> oh yes, maintaining the usual semantics for cp becomes tricky.
>
> mkdir z
> cp x.c z
>
> do i mean to write x.c to z itself, or to a new file within z?
another gotcha would be:
echo aaa > foo
echo bbb > bar
bind -a foo bar# or bind -b foo.txt bar.txt
cat foo
any sensible semantics possible?
--
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
Re: [9fans] files vs. directories
On Thursday, February 03, 2011 03:15:29 pm roger peppe wrote:
> On 3 February 2011 13:44, dexen deVries wrote:
> > On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> >> On 3 February 2011 11:45, dexen deVries wrote:
> >> > read(open("/foo")) returns byte stream under entry `foo' in the root
> >> > object.
> >> >
> >> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> >> > hierarchical section of object `/foo'.
> >>
> >> there's no distinction between readdir and read in plan 9.
> >
> > Forgot about that. Still, you can't chdir() into an inode that doesn't
> > indicate being a directory. And the bytestream returned by
> > read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for
> > free- form bytestream.
>
> i don't think that helps you.
>
> under plan 9, reading a directory is this:
>
> translate(read(open(dir)))
>
> i don't see how you can make read(open(dir)) return
> something different.
no contest there. I'd like to have a look at the handling of multiple forks of
files in other OSes (from userland perspective).
> oh yes, maintaining the usual semantics for cp becomes tricky.
>
> mkdir z
> cp x.c z
>
> do i mean to write x.c to z itself, or to a new file within z?
I have only linux experience with cp -- and this usage pattern always irked
me. Theoretically, it's prone to race condition: suppose somebody removes the
dir `z' right between `mkdir' and `cp'. You `cp x.c z', and end up with `z'
file. It's unpredictable, unless you're on a single-process OS (yuck).
I'd rather see `cp x.c z' always duplicates bytestream from x.c into z's
bytestream, whatever `z' happens to be right now. Creating `z' in the process,
if not present. If you want to have `z/x.c', you'd state that explicitly as
`cp x.c z/x.c'.
nb., with the current semantics you *could* say `cp x.c z/' to be unambiguous
you want to create a child of `z', but it seems to be common not to use
trailing slash unless 100% necessary.
--
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
Re: [9fans] RESOLVED: recoving important header file rudely
>usually with oversized log files. sam -d, indeed!
Re: [9fans] RESOLVED: recoving important header file rudely
On 3 February 2011 14:17, erik quanstrom wrote: > On Thu Feb 3 09:17:27 EST 2011, rogpe...@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 wrote: >> > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote: >> >> On 3 February 2011 13:01, erik quanstrom 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...
Re: [9fans] RESOLVED: recoving important header file rudely
On Thu Feb 3 09:17:27 EST 2011, rogpe...@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 wrote: > > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote: > >> On 3 February 2011 13:01, erik quanstrom 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
Re: [9fans] RESOLVED: recoving important header file rudely
i've found it very useful quite a few times. usually with oversized log files. On 3 February 2011 13:59, erik quanstrom wrote: > On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote: >> On 3 February 2011 13:01, erik quanstrom 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 > >
Re: [9fans] files vs. directories
On 3 February 2011 13:44, dexen deVries wrote:
> On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
>> On 3 February 2011 11:45, dexen deVries wrote:
>> > read(open("/foo")) returns byte stream under entry `foo' in the root
>> > object.
>> >
>> > readdir("/foo") returns `bar' (and possibly others) -- entries in
>> > hierarchical section of object `/foo'.
>>
>> there's no distinction between readdir and read in plan 9.
>
> Forgot about that. Still, you can't chdir() into an inode that doesn't
> indicate being a directory. And the bytestream returned by
> read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for free-
> form bytestream.
i don't think that helps you.
under plan 9, reading a directory is this:
translate(read(open(dir)))
i don't see how you can make read(open(dir)) return
something different.
oh yes, maintaining the usual semantics for cp becomes tricky.
mkdir z
cp x.c z
do i mean to write x.c to z itself, or to a new file within z?
Re: [9fans] files vs. directories
> How about 8c(1)? would it be too confusing to issue: > 8c foo.c > if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C > code? > > rc(1)? How could `. foo.rc' handle situation when also > `foo.rc/bar.rc/baz.rc' > exists? exactly. this is the same problem one has with arbitrary attributes. - erik
Re: [9fans] RESOLVED: recoving important header file rudely
On Thu Feb 3 08:41:23 EST 2011, rogpe...@gmail.com wrote: > On 3 February 2011 13:01, erik quanstrom 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
Re: [9fans] files vs. directories
On Thursday, February 03, 2011 02:36:40 pm roger peppe wrote:
> On 3 February 2011 11:45, dexen deVries wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root
> > object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical section of object `/foo'.
>
> there's no distinction between readdir and read in plan 9.
Forgot about that. Still, you can't chdir() into an inode that doesn't
indicate being a directory. And the bytestream returned by
read(SOME_DIRECTORY) is fixed-format and doesn't provide any space for free-
form bytestream.
--
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
Re: [9fans] files vs. directories
On Thursday, February 03, 2011 02:05:02 pm erik quanstrom wrote: > > why do we keep distinction between files and directories? Does it provide > > any extra value over model with unified file/directory? > > yes. the advantage is that it's easy to tell the difference > between a file and a directory. no comments ;-) > and we have a lot of code > that works with the current model. That was my first objection, too; stuff like acme(1) could become strange: I can't imagine how to present mixed bytestream+subfiles/subdirectories in a reasonable way. Unless the user left the one of the forks empty, that is... tar(1) would become confused beyond imagination. How about 8c(1)? would it be too confusing to issue: 8c foo.c if `foo.c' contained some C code, AND `foo.c/bar.h' contained some more C code? rc(1)? How could `. foo.rc' handle situation when also `foo.rc/bar.rc/baz.rc' exists? The model seems somewhat sensible in regard to user-oriented documents, especially multi-part ones. `mail/1' could hold body of an email message nr 1, and `mail/1/1' its first MIME part. Perhaps /dev/sd0, /dev/sd0/p0, /dev/sd0/p0/p0 could make some sense in regard to drives, partitions etc.? Perhaps my whole confusion stems from the fact I've never used any record- oriented filesystem -- otherwise I'd understand pains related to it, as some of them would apply in case of my question. -- 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
Re: [9fans] files vs. directories
On Thu Feb 3 08:39:20 EST 2011, rogpe...@gmail.com wrote:
> On 3 February 2011 11:45, dexen deVries wrote:
> > read(open("/foo")) returns byte stream under entry `foo' in the root object.
> >
> > readdir("/foo") returns `bar' (and possibly others) -- entries in
> > hierarchical
> > section of object `/foo'.
>
> there's no distinction between readdir and read in plan 9.
offset tracking is different.
- erik
Re: [9fans] RESOLVED: recoving important header file rudely
On 3 February 2011 13:01, erik quanstrom 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.
Re: [9fans] files vs. directories
On 3 February 2011 11:45, dexen deVries wrote:
> read(open("/foo")) returns byte stream under entry `foo' in the root object.
>
> readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical
> section of object `/foo'.
there's no distinction between readdir and read in plan 9.
Re: [9fans] files vs. directories
> why do we keep distinction between files and directories? Does it provide any > extra value over model with unified file/directory? yes. the advantage is that it's easy to tell the difference between a file and a directory. and we have a lot of code that works with the current model. what is the extra value of a unified model? - erik
Re: [9fans] RESOLVED: recoving important header file rudely
On Thu Feb 3 04:36:35 EST 2011, fors...@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
Re: [9fans] network connection on virtualbox
> > > Hi, Running plan 9 on virtual box 4.0.2, I've configured network
> > > adaptaters as below.
> > > Attached to NAT
> > > Adapter type: PCnet-FAST 3(Am79C973)
> > > check cable connected.
> >
> > > After booting plan 9, I typed ip/ipconfig, after waiting some time,
> > > ipconfig: no success with DHCP.
> > > I don't know what's wrong??
> > > Please help.
> >
> > virtualbox is finicky and what works depends a lot on the
> > version of vb and it seems to depend on your own hardware.
> >
> > the 79c973 driver doesn't track link state currently, so there's
> > limited ways i can think of to remotely help. did you happen
> > to see a message that looks like this on the console?
> >
> > print("#l%d: unknown PCnet card version 0x%.7ux\n",
> > ether->ctlrno, x&0xFFF);
> >
> > can you verify a /net/ether0 exists? if the answers are no and yes,
> > then it might be worth running snoopy in another window
> > to verify that you can see any packets.
> >
> > you might also try another emulated chipset.
> >
> > - erik
>
> I tried on Qemu, still same problem even though now ip/ipconfig and
> ndb/dns -r seems ok,
i don't understand the problem, then. i thought it was that ip/ipconfig
didn't work. what is it?
- erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 10:38:30 +, 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 --
[9fans] files vs. directories
As this list seems to be open to discussion of strange OS-related ideas, here
goes my question:
why do we keep distinction between files and directories? Does it provide any
extra value over model with unified file/directory?
A possible consideration for representation of unified files/directories is a
three-part file: name (& other meta), byte-stream (==content), ordered list of
subfiles (== subfiles/subdirectories). In a way, that'd be somewhat similar to
files with two forks you can see on some OSes. Or, to put it the other way
around, it's like a directory with extra section for one unnamed byte stream.
Path sematnics stays exactly the same:
read(open("/foo/bar")) returns byte stream related to entry `bar' in (for lack
of any better word) object `/foo'.
read(open("/foo")) returns byte stream under entry `foo' in the root object.
readdir("/foo") returns `bar' (and possibly others) -- entries in hierarchical
section of object `/foo'.
The sourece of the idea is a (www) CMS I'm working on which doesn't make such
distinction, and it somehow makes some sense -- at least as served over HTTP &
addressed via URIs.
--
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
Re: [9fans] HELP: recoving important header file rudely clobbered
On Thu, Feb 03, 2011 at 10:37:39AM +, 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
Re: [9fans] HELP: recoving important header file rudely clobbered
On 3 February 2011 10:23, Richard Miller <9f...@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"!
Re: [9fans] HELP: recoving important header file rudely clobbered
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
Re: [9fans] HELP: recoving important header file rudely clobbered
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
Re: [9fans] HELP: recoving important header file rudely clobbered
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%
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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.
Re: [9fans] HELP: recoving important header file rudely clobbered
> %: %.$O > $LD $LDFLAGS -o $target $prereq Not a good idea. '%' matches everything, not just files with no suffix.
Re: [9fans] Modern development language for Plan 9,
In article , 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. 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?
Re: [9fans] network connection on virtualbox
On Feb 2, 9:11 pm, quans...@quanstro.net (erik quanstrom) wrote:
> On Wed Feb 2 05:04:07 EST 2011, nyanhtoo...@gmail.com wrote:
>
> > Hi, Running plan 9 on virtual box 4.0.2, I've configured network
> > adaptaters as below.
> > Attached to NAT
> > Adapter type: PCnet-FAST 3(Am79C973)
> > check cable connected.
>
> > After booting plan 9, I typed ip/ipconfig, after waiting some time,
> > ipconfig: no success with DHCP.
> > I don't know what's wrong??
> > Please help.
>
> virtualbox is finicky and what works depends a lot on the
> version of vb and it seems to depend on your own hardware.
>
> the 79c973 driver doesn't track link state currently, so there's
> limited ways i can think of to remotely help. did you happen
> to see a message that looks like this on the console?
>
> print("#l%d: unknown PCnet card version 0x%.7ux\n",
> ether->ctlrno, x&0xFFF);
>
> can you verify a /net/ether0 exists? if the answers are no and yes,
> then it might be worth running snoopy in another window
> to verify that you can see any packets.
>
> you might also try another emulated chipset.
>
> - erik
I tried on Qemu, still same problem even though now ip/ipconfig and
ndb/dns -r seems ok,
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 09:46:00 +, 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 --
Re: [9fans] RESOLVED: recoving important header file rudely
> 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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 3 Feb 2011 08:35:53 +, 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 --
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
>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.
