Re: [9fans] native limbo

Re: [9fans] native limbo

[rog]

the main reason, in my view, why limbo seems so distinct from plan 9 is
that it runs in its own little box in its own little console in its own
little portion of the namespace.

changing the inferno draw device so that it was the same as plan 9's
(and hence emu could just use the plan 9 draw device, same as it uses
plan 9's /net) would go a long way towards lowering the barriers.

there's no real reason why the console always has to be visible; and
apparently it shouldn't be too difficult to get the emu window to
resize.

those changes, along with a 9p->styx (and vice versa) bridge could make
inferno much more tightly integrated with plan 9, while preserving its
useful "ultra-portability" properties.

if it was up to me (it isn't), i'd feel reluctant to start divorcing
limbo from emu - much of the power of limbo comes from the environment
in which it lives, which is essentially the whole of inferno.

i've hacked up my version of emu and wm so that the snarf buffer is
held in common with plan 9.  so i can copy out of a charon in one emu
window and paste into a terminal window in another, or into acme. i
find that this minor change has lessened to a great extent the amount
of frustration i experience due to the two separate environments.

bridging the two plumb spaces would help a lot too.

  cheers,
    rog.

Re: [9fans] native limbo

[Boyd Roberts]

> the main reason, in my view, why limbo seems so distinct from plan 9 is
> that it runs in its own little box in its own little console in its own
> little portion of the namespace.

limbo is a programming language.  plan 9 is an operating system.  qed.
 

Re: [9fans] native limbo

[rog]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

okay, okay.

maybe what i should have said is "why inferno programs seem so distinct
from plan9 programs"


[-- Attachment #2: Type: message/rfc822, Size: 2011 bytes --]

To: <cse.psu.edu!9fans>
Subject: Re: [9fans] native limbo
Date: Tue, 1 May 2001 20:25:39 +0200
Message-ID: <035d01c0d26c$1f803250$e8b7c6d4@SOMA>

> the main reason, in my view, why limbo seems so distinct from plan 9 is
> that it runs in its own little box in its own little console in its own
> little portion of the namespace.

limbo is a programming language.  plan 9 is an operating system.  qed.
 

Re: [9fans] native limbo

[Dan Cross]

In article <LPBBIBIIHKHEGDBPHBDOKEGFCAAA.kiwane@dream.com> you write:
>2) a dis interpreter and plan9 native modules
>
>Similar to 1), but modules and apps in dis binary. Thanks to Vita Nuova,
>there already is a limbo-to-dis compiler on plan9 (right? don't know how
>inferno/emu-dependent it is, though). You'd invoke a dis interpreter,
>which would provide gc, syscall i/f and whatnot, to execute limbo apps.

Hmm, not to be contrary, but isn't this basically what emu does
already?  It provides a dis interpreter, plus modules which map native
limbo services into native Plan 9 services (eg, a call to Sys->open()
gets mapped into open(2)).  Maybe I'm missing something.

	- Dan C.

(ps- I think that a native limbo compiler would be sweet; but I too
fear that it would go the way Alef did.)

[9fans] native limbo

[kazumi iwane]

Hello 9fans,

The idea of having native limbo appeals to me, too. There seem to be
various degrees of nativeness people are talking about, though; some
see limbo as yet another language to write apps on plan9, others as
an integral part of inferno. I 'd be happy with the scenario "2" below.

1) a limbo compiler that produces plan9 native executables

Modules that access plan9 services must be written, probably taking
every advantage of native environment rather than trying to conform to
inferno's module layout. Limbo apps would speak 9p instead of styx,
too. A reincarnation of alef, really, and I fear the same fate might await.

2) a dis interpreter and plan9 native modules

Similar to 1), but modules and apps in dis binary. Thanks to Vita Nuova,
there already is a limbo-to-dis compiler on plan9 (right? don't know how
inferno/emu-dependent it is, though). You'd invoke a dis interpreter,
which would provide gc, syscall i/f and whatnot, to execute limbo apps.

3) Inferno Compatibility Environment (ICE)

Together with 2), in a manner and spirit similar to APE, it might be
possible to create a set of compatibility modules for inferno, using all
the namespace tricks and a 9p-styx gateway. But this *is* what emu
is all about, I guess...

4) a complete inferno environment *without emu*

No idea if/how this is possible, but I guess this is what some people
are after.

P.S.
No pun intented on the subject line, really.

- kazumi