Re: [9fans] RESOLVED: recoving important header file rudely
On Thursday, February 03, 2011 04:35:04 am smi...@zenzebra.mv.com 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. "The standard rule is, when you're in a hole, stop digging; that seems not to apply in software nowadays." -- dexen deVries [[[↓][→]]]
Re: [9fans] RESOLVED: recoving important header file rudely
On Thu, Feb 03, 2011 at 03:35:04AM +, smi...@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
Re: [9fans] RESOLVED: recoving important header file rudely
> The finished version will support strings backed by file storage and I'm patiently waiting for strings backed by cloud storage.
Re: [9fans] 9atom .iso builds
On Wed Feb 2 23:15:07 EST 2011, stanley.lie...@gmail.com wrote: > Apologies if I've overlooked mention of this, but is there > an easy way to determine when a given 9atom .iso was generated? the date of the file (viewable via ftp.) > How often are these updated? not very often. i'm actually working on speeding this up at this very moment. unfortunately, due to a day job, it won't be immediate. - erik
[9fans] 9atom .iso builds
Apologies if I've overlooked mention of this, but is there an easy way to determine when a given 9atom .iso was generated? How often are these updated? -sl
Re: [9fans] RESOLVED: recoving important header file rudely
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] 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. 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 6:16 PM, Bakul Shah > wrote: > On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth > wrote: > > > >$ size /usr/local/bin/clang > > > > textdata bss dec hex filename > > > >228428621023204 69200 2393526616d3922 > /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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth wrote: > > >$ size /usr/local/bin/clang > > > textdata bss dec hex filename > > >228428621023204 69200 2393526616d3922 > > >/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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 4:52 PM, Charles Forsyth 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> >$ size /usr/local/bin/clang > > textdata bss dec hex filename > >228428621023204 69200 2393526616d3922 /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?
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed Feb 2 19:19:13 EST 2011, fors...@terzarima.net wrote: > >$ size /usr/local/bin/clang > > textdata bss dec hex filename > >228428621023204 69200 2393526616d3922 /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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
>you'll hear people call [fringe benefits] "French Benefits". i did not expect that! i'd have guessed: `cheese'.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
>$ size /usr/local/bin/clang > textdata bss dec hex filename >228428621023204 69200 2393526616d3922 /usr/local/bin/clang impressive. certainly in the sense of `makes quite a dent if dropped'.
Re: [9fans] RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 11:15 AM, 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> start := now(); > while (now() < start + 2hours); > > You don't expect GC to be able to trigger, right? i sure do. - erik
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
"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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, 02 Feb 2011 09:45:56 PST David Leimbach 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 textdata bss dec hex filename 228428621023204 69200 2393526616d3922 /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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] RESOLVED: recoving important header file rudely
"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] HELP: recoving important header file rudely clobbered by mk
Enjoy...
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 02, 2011 at 10:26:34AM -0800, David Leimbach wrote: > On Wed, Feb 2, 2011 at 10:07 AM, 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 http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wednesday, February 2, 2011, erik quanstrom 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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 10:21 AM, 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. > > - 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 10:03 AM, erik quanstrom 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 10:07 AM, 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 > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 9:50 AM, 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. > > 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 > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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.
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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 http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Wed, Feb 2, 2011 at 4:54 AM, erik quanstrom 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 > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 11:35 PM, Nick LaForge 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 wrote: > > And russ cox, and everyone else in the CONTRIBUTORS file. > > On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote: > > > >
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
On Tue, Feb 1, 2011 at 9:14 PM, wrote: > ron minnich 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) > > -- > +---
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
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
Re: [9fans] network connection on virtualbox
On Wed, Feb 2, 2011 at 9:06 PM, 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. > I am using intel pro below under vb 4.02 snowleopard. It also worked on 3.12. I am also using 9atom not the official iso. You should find a month or 2 old thread regarding this if you do a search Adapter 1: Intel PRO/1000 MT Server (Bridged adapter, en1: AirPort)
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
2011/2/2 erik quanstrom : >> 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 > >
Re: [9fans] network connection on virtualbox
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
Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely
> 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
[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. Thanks in advance. Nyan
