Well, actually, I was thinking of something along the lines of Lisaac: "dynamic" modules are statically compiled ala object files, & the run time handles issues between Plan9 & Inferno. Sys->load & the like would not be dynamic, but would work as expected. Hell, it could even just be a .Net/perl2exe clone: every binary is just an ultra-cut down Dis + compiled modules. I like the Lisaac model better, and that's where I was hedging my bets; I have a bunch of notes on my local Inferno install, but nothing to show due to more pressing issues. C'est la vie.
& debugging this would require a 9Limbo-aware debugger; the .Net-style approach could serve a /lproc or the like though (not that the native one couldn't, but the VMish approach could have hooks for stopping execution).
$0.02
> > >Or have a native Limbo compiler; I've been itching for that for some time,
> >
> > it doesn't mean anything.
>
> Uh, considering that ircfs is for Inferno (via Limbo), having a Limbode top-posted for your reading pleasure.
> compiler to native Plan9 would be a potential solution, assuming the run
> time could be kept the same.
the reason that a native limbo compiler doesn't make any
sense is that inferno is not a virtual cpu, it is a virtual
system, complete with system calls, file system access,
etc. of course, this is the right way to do things since
inferno needs to run natively and on top of other systems
like windows as well as natively.
i've heard that it was the opinion of some at the labs
in the early days of plan 9 (can anyone confirm?) that
plan 9 was a way to glue the unixes together. if that's
what plan 9 is, then one should have a fs to make an
inferno's /proc appear nativeish. but it's not clear to
me that one could bridge enough of the gap to make
this anything other than an annoyance. for example,
what if you wanted to debug an inferno process?
- erik