Re: [9fans] Install from CD fails

Re: [9fans] Install from CD fails

[erik quanstrom]

i think there is a #3 here.  extension.

dynamic linking allows one to extend a program without inventing a metalanguage.
i believe there is a paper on how inferno's shell uses this to nice effect.

- erik

On Tue Apr 18 16:56:40 CDT 2006, leimy2k@gmail.com wrote:
> >   And you would have to go through all of the aforementioned troubles
> >   to achieve exactly what ? What is it, that shared libraries are good
> >   at ?
>
> #1 Maintenance - If you have 50 programs that depend on one library
> and you have a fix for the library how many things do you want to
> "remember to build"?  (though people are throwing up straw man
> arguments for this too.  I suspect the worst case scenario is not
> always the common case though.)
>
> #2 Supposed physical memory savings - libSystem on Mac OS X only
> exists in memory 1 time for all the programs that use it... sorta.
> Read Only pages are shared, writable pages are COW and yes, this adds
> a good deal of complexity to the VM of the OS to have this.
>

Re: [9fans] Install from CD fails

[Russ Cox]

> dynamic linking allows one to extend a program without inventing a metalanguage.
> i believe there is a paper on how inferno's shell uses this to nice effect.

shared libraries != dynamic loading of modules.
both require a dynamic linking implementation
but they are not at all the same.

shared libraries are just a bad replacement
for static libraries.  they're used implicitly without
a program having to ask for anything, and there
is never an appropriate situation in which
to use them.

dynamic loading of modules can be a very
powerful method of extension.  i have been
meaning for a long time to convert snoopy to
make the protocol parsers dynamically loaded
instead of having one huge binary.  the inferno
shell is another good example.

the boundary is a bit blurred on inferno,
because the explicitly module loading there
is most commonly used to load what on other
systems would be libraries.  but the result,
at least as implemented, has a very different
feel from the shared library hell on unix
and windows.

russ

[9fans] dynamic module loading and versioning

[Michael Baldwin]

> the boundary is a bit blurred on inferno, because the explicitly
> module loading there is most commonly used to load what on other
> systems would be libraries.  but the result, at least as
> implemented, has a very different feel from the shared library hell
> on unix and windows.

Aren't some of the same maintenance and versioning headaches
associated with shared libraries still there with dynamic loading of
modules?  In Inferno, occasionally the Sys module changes (just to
pick a nasty one), and that can wreak similar havoc as incompatible
shared libraries unless you have a flag day.  I've pondered playing
with the PATH string in a module header to make this less burdensome,
but I haven't seen anyone actually do it or even talk to the issue
(OK, there aren't that (m)any users of Inferno to have people to ask,
I know).

It just seems that, if for some reason I go and change a function
signature in the String module, say, isn't it a similar headache as
shared libraries to keep all the programs that use the old and new
module running and happy at the same time?  I know merely adding
functions is still compatible, but sometimes incompatible changes
must be made (int->big for file sizes and offsets comes to mind).
And to keep old and new programs not just running but compiling is a
bit of a bitch.  Has anyone thought about or addressed these issues
in Inferno or another dynamic-loading system?  Any lessons that can
be learned and brought back to the unwashed world of shared libraries?

Re: [9fans] dynamic module loading and versioning

[Bruce Ellis]

inferno is a bit more clever.  only the used functions from a load
of Sys are required.  everything is a module, tho many modules
are apps that can be run from whatever shell.  the code, if it be
jitted or not, is shared.  the module data is copied.  i like it.

strong type checking rules.

and it achieves the goal of making apps tiny.

brucee

On 4/19/06, Michael Baldwin <michael@cibernet.com> wrote:
> > the boundary is a bit blurred on inferno, because the explicitly
> > module loading there is most commonly used to load what on other
> > systems would be libraries.  but the result, at least as
> > implemented, has a very different feel from the shared library hell
> > on unix and windows.
>
> Aren't some of the same maintenance and versioning headaches
> associated with shared libraries still there with dynamic loading of
> modules?  In Inferno, occasionally the Sys module changes (just to
> pick a nasty one), and that can wreak similar havoc as incompatible
> shared libraries unless you have a flag day.  I've pondered playing
> with the PATH string in a module header to make this less burdensome,
> but I haven't seen anyone actually do it or even talk to the issue
> (OK, there aren't that (m)any users of Inferno to have people to ask,
> I know).
>
> It just seems that, if for some reason I go and change a function
> signature in the String module, say, isn't it a similar headache as
> shared libraries to keep all the programs that use the old and new
> module running and happy at the same time?  I know merely adding
> functions is still compatible, but sometimes incompatible changes
> must be made (int->big for file sizes and offsets comes to mind).
> And to keep old and new programs not just running but compiling is a
> bit of a bitch.  Has anyone thought about or addressed these issues
> in Inferno or another dynamic-loading system?  Any lessons that can
> be learned and brought back to the unwashed world of shared libraries?
>
>

Re: [9fans] dynamic module loading and versioning

[Lyndon Nerenberg]

On Apr 19, 2006, at 2:37 AM, Bruce Ellis wrote:

> and it achieves the goal of making apps tiny.
>
> brucee

blonde?  how much?

Re: [9fans] dynamic module loading and versioning

[Bruce Ellis]

ozinferno (i haven't worked on it for  while because of mAny reaons).

--rw-rw-r-- M 89 brucee brucee   546 Dec  8 04:24 addpass.dis
--rw-rw-r-- M 89 brucee brucee   542 Dec  8 04:24 addtosrv.dis
--rw-rw-r-- M 89 brucee brucee  2936 Dec  8 04:24 bceget.dis
--rw-rw-r-- M 89 brucee brucee   492 Dec  8 04:24 bind.dis
--rw-rw-r-- M 89 brucee brucee  5551 Dec  8 04:24 boot.dis
--rw-rw-r-- M 89 brucee brucee   568 Dec  8 04:24 cat.dis
--rw-rw-r-- M 89 brucee brucee   498 Dec  8 04:24 cd.dis
--rw-rw-r-- M 89 brucee brucee  9351 Dec  8 04:24 certx509.dis
--rw-rw-r-- M 89 brucee brucee  1345 Dec  8 04:24 chmod.dis
--rw-rw-r-- M 89 brucee brucee  1749 Dec  8 04:24 cmp.dis
--rw-rw-r-- M 89 brucee brucee  3691 Dec  8 04:24 cp.dis
--rw-rw-r-- M 89 brucee brucee   801 Dec  8 04:24 dcall.dis
--rw-rw-r-- M 89 brucee brucee   521 Dec  8 04:24 dclient.dis
--rw-rw-r-- M 89 brucee brucee  6491 Dec  8 04:24 dd.dis
--rw-rw-r-- M 89 brucee brucee   897 Dec  8 04:24 df.dis
--rw-rw-r-- M 89 brucee brucee   728 Dec  8 04:24 dserver.dis
--rw-rw-r-- M 89 brucee brucee  2300 Dec  8 04:24 du.dis
--rw-rw-r-- M 89 brucee brucee   369 Dec  8 04:24 echo.dis
--rw-rw-r-- M 89 brucee brucee  2770 Dec  8 04:24 fencode.dis
--rw-rw-r-- M 89 brucee brucee  3674 Dec  8 04:24 filefs.dis
--rw-rw-r-- M 89 brucee brucee  4466 Dec  8 04:24 findex.dis
--rw-rw-r-- M 89 brucee brucee 37006 Dec  8 04:24 flashfs.dis
--rw-rw-r-- M 89 brucee brucee   272 Dec  8 04:24 fpit.dis
--rw-rw-r-- M 89 brucee brucee  1434 Dec  8 04:24 ftest.dis
--rw-rw-r-- M 89 brucee brucee  1037 Dec  8 04:24 genfs.dis
--rw-rw-r-- M 89 brucee brucee   576 Dec  8 04:24 getpass.dis
--rw-rw-r-- M 89 brucee brucee  1497 Dec  8 04:24 grep.dis
--rw-rw-r-- M 89 brucee brucee   748 Dec  8 04:24 hmac.dis
--rw-rw-r-- M 89 brucee brucee  1134 Dec  8 04:24 ipclass.dis
--rw-rw-r-- M 89 brucee brucee 29025 Dec  8 04:24 jfs.dis
--rw-rw-r-- M 89 brucee brucee  1439 Dec  8 04:24 kill.dis
--rw-rw-r-- M 89 brucee brucee  2051 Dec  8 04:24 ls.dis
--rw-rw-r-- M 89 brucee brucee  4473 Dec  8 04:24 mash.dis
--rw-rw-r-- M 89 brucee brucee   997 Dec  8 04:24 memfs.dis
--rw-rw-r-- M 89 brucee brucee  1307 Dec  8 04:24 mkdatafs.dis
--rw-rw-r-- M 89 brucee brucee   386 Dec  8 04:24 mkdir.dis
--rw-rw-r-- M 89 brucee brucee  5911 Dec  8 04:24 mkffs.dis
--rw-rw-r-- M 89 brucee brucee  6399 Dec  8 04:24 mkjfs.dis
--rw-rw-r-- M 89 brucee brucee  1422 Dec  8 04:24 mkkeypair.dis
--rw-rw-r-- M 89 brucee brucee  8078 Dec  8 04:24 mksakfs.dis
--rw-rw-r-- M 89 brucee brucee  2858 Dec  8 04:24 mv.dis
--rw-rw-r-- M 89 brucee brucee  1721 Dec  8 04:24 ossrv.dis
--rw-rw-r-- M 89 brucee brucee   349 Dec  8 04:24 pig.dis
--rw-rw-r-- M 89 brucee brucee    81 Dec  8 04:24 proto.dis
--rw-rw-r-- M 89 brucee brucee  1170 Dec  8 04:24 protosrvfs.dis
--rw-rw-r-- M 89 brucee brucee   635 Dec  8 04:24 ps.dis
--rw-rw-r-- M 89 brucee brucee   345 Dec  8 04:24 pwd.dis
--rw-rw-r-- M 89 brucee brucee   241 Dec  8 04:24 quote.dis
--rw-rw-r-- M 89 brucee brucee   976 Dec  8 04:24 rm.dis
--rw-rw-r-- M 89 brucee brucee   859 Dec  8 04:24 sadd.dis
--rw-rw-r-- M 89 brucee brucee   987 Dec  8 04:24 sakfs.dis
--rw-rw-r-- M 89 brucee brucee  5169 Dec  8 04:24 sh.dis
--rw-rw-r-- M 89 brucee brucee  4026 Dec  8 04:24 sign.dis
--rw-rw-r-- M 89 brucee brucee   651 Dec  8 04:24 srvfs.dis
--rw-rw-r-- M 89 brucee brucee   512 Dec  8 04:24 unmount.dis
--rw-rw-r-- M 89 brucee brucee  7117 Dec  8 04:24 venti.dis
--rw-rw-r-- M 89 brucee brucee  4262 Dec  8 04:24 web.dis
--rw-rw-r-- M 89 brucee brucee 39376 Dec  8 04:24 yacc.dis

hmm shell 5169 bytes ...

brucee

On 4/19/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
>
> On Apr 19, 2006, at 2:37 AM, Bruce Ellis wrote:
>
> > and it achieves the goal of making apps tiny.
> >
> > brucee
>
> blonde?  how much?
>

Re: [9fans] dynamic module loading and versioning

[Artem Letko]

how about a ps form a non-jitted shell?

-art

On 4/19/06, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> ozinferno (i haven't worked on it for  while because of mAny reaons).
>
> --rw-rw-r-- M 89 brucee brucee   546 Dec  8 04:24 addpass.dis
> --rw-rw-r-- M 89 brucee brucee   542 Dec  8 04:24 addtosrv.dis
> --rw-rw-r-- M 89 brucee brucee  2936 Dec  8 04:24 bceget.dis
> --rw-rw-r-- M 89 brucee brucee   492 Dec  8 04:24 bind.dis
> --rw-rw-r-- M 89 brucee brucee  5551 Dec  8 04:24 boot.dis
> --rw-rw-r-- M 89 brucee brucee   568 Dec  8 04:24 cat.dis
> --rw-rw-r-- M 89 brucee brucee   498 Dec  8 04:24 cd.dis
> --rw-rw-r-- M 89 brucee brucee  9351 Dec  8 04:24 certx509.dis
> --rw-rw-r-- M 89 brucee brucee  1345 Dec  8 04:24 chmod.dis
> --rw-rw-r-- M 89 brucee brucee  1749 Dec  8 04:24 cmp.dis
> --rw-rw-r-- M 89 brucee brucee  3691 Dec  8 04:24 cp.dis
> --rw-rw-r-- M 89 brucee brucee   801 Dec  8 04:24 dcall.dis
> --rw-rw-r-- M 89 brucee brucee   521 Dec  8 04:24 dclient.dis
> --rw-rw-r-- M 89 brucee brucee  6491 Dec  8 04:24 dd.dis
> --rw-rw-r-- M 89 brucee brucee   897 Dec  8 04:24 df.dis
> --rw-rw-r-- M 89 brucee brucee   728 Dec  8 04:24 dserver.dis
> --rw-rw-r-- M 89 brucee brucee  2300 Dec  8 04:24 du.dis
> --rw-rw-r-- M 89 brucee brucee   369 Dec  8 04:24 echo.dis
> --rw-rw-r-- M 89 brucee brucee  2770 Dec  8 04:24 fencode.dis
> --rw-rw-r-- M 89 brucee brucee  3674 Dec  8 04:24 filefs.dis
> --rw-rw-r-- M 89 brucee brucee  4466 Dec  8 04:24 findex.dis
> --rw-rw-r-- M 89 brucee brucee 37006 Dec  8 04:24 flashfs.dis
> --rw-rw-r-- M 89 brucee brucee   272 Dec  8 04:24 fpit.dis
> --rw-rw-r-- M 89 brucee brucee  1434 Dec  8 04:24 ftest.dis
> --rw-rw-r-- M 89 brucee brucee  1037 Dec  8 04:24 genfs.dis
> --rw-rw-r-- M 89 brucee brucee   576 Dec  8 04:24 getpass.dis
> --rw-rw-r-- M 89 brucee brucee  1497 Dec  8 04:24 grep.dis
> --rw-rw-r-- M 89 brucee brucee   748 Dec  8 04:24 hmac.dis
> --rw-rw-r-- M 89 brucee brucee  1134 Dec  8 04:24 ipclass.dis
> --rw-rw-r-- M 89 brucee brucee 29025 Dec  8 04:24 jfs.dis
> --rw-rw-r-- M 89 brucee brucee  1439 Dec  8 04:24 kill.dis
> --rw-rw-r-- M 89 brucee brucee  2051 Dec  8 04:24 ls.dis
> --rw-rw-r-- M 89 brucee brucee  4473 Dec  8 04:24 mash.dis
> --rw-rw-r-- M 89 brucee brucee   997 Dec  8 04:24 memfs.dis
> --rw-rw-r-- M 89 brucee brucee  1307 Dec  8 04:24 mkdatafs.dis
> --rw-rw-r-- M 89 brucee brucee   386 Dec  8 04:24 mkdir.dis
> --rw-rw-r-- M 89 brucee brucee  5911 Dec  8 04:24 mkffs.dis
> --rw-rw-r-- M 89 brucee brucee  6399 Dec  8 04:24 mkjfs.dis
> --rw-rw-r-- M 89 brucee brucee  1422 Dec  8 04:24 mkkeypair.dis
> --rw-rw-r-- M 89 brucee brucee  8078 Dec  8 04:24 mksakfs.dis
> --rw-rw-r-- M 89 brucee brucee  2858 Dec  8 04:24 mv.dis
> --rw-rw-r-- M 89 brucee brucee  1721 Dec  8 04:24 ossrv.dis
> --rw-rw-r-- M 89 brucee brucee   349 Dec  8 04:24 pig.dis
> --rw-rw-r-- M 89 brucee brucee    81 Dec  8 04:24 proto.dis
> --rw-rw-r-- M 89 brucee brucee  1170 Dec  8 04:24 protosrvfs.dis
> --rw-rw-r-- M 89 brucee brucee   635 Dec  8 04:24 ps.dis
> --rw-rw-r-- M 89 brucee brucee   345 Dec  8 04:24 pwd.dis
> --rw-rw-r-- M 89 brucee brucee   241 Dec  8 04:24 quote.dis
> --rw-rw-r-- M 89 brucee brucee   976 Dec  8 04:24 rm.dis
> --rw-rw-r-- M 89 brucee brucee   859 Dec  8 04:24 sadd.dis
> --rw-rw-r-- M 89 brucee brucee   987 Dec  8 04:24 sakfs.dis
> --rw-rw-r-- M 89 brucee brucee  5169 Dec  8 04:24 sh.dis
> --rw-rw-r-- M 89 brucee brucee  4026 Dec  8 04:24 sign.dis
> --rw-rw-r-- M 89 brucee brucee   651 Dec  8 04:24 srvfs.dis
> --rw-rw-r-- M 89 brucee brucee   512 Dec  8 04:24 unmount.dis
> --rw-rw-r-- M 89 brucee brucee  7117 Dec  8 04:24 venti.dis
> --rw-rw-r-- M 89 brucee brucee  4262 Dec  8 04:24 web.dis
> --rw-rw-r-- M 89 brucee brucee 39376 Dec  8 04:24 yacc.dis
>
> hmm shell 5169 bytes ...
>
> brucee
>
> On 4/19/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> >
> > On Apr 19, 2006, at 2:37 AM, Bruce Ellis wrote:
> >
> > > and it achieves the goal of making apps tiny.
> > >
> > > brucee
> >
> > blonde?  how much?
> >
>

Re: [9fans] dynamic module loading and versioning

[Bruce Ellis]

cpu% emu
Inferno Oz Beta main (pid=327) interp
Initialize Dis: #U/boot.dis
stash$ ps
       1        1     brucee    release     4K     0:00.0 Sh[$Sys]
       4        4     brucee        alt    11K     0:00.0 Boot
       5        1     brucee    release     3K     0:00.0 FsLib[$Sys]
       6        1     brucee       recv     8K     0:00.0 SrvFS
       7        1     brucee    release     3K     0:00.0 FsLib[$Sys]
       8        1     brucee       recv     8K     0:00.0 SrvFS
       9        1     brucee      ready     1K     0:00.0 Ps[$Sys]
stash$

On 4/20/06, Artem Letko <aletko@gmail.com> wrote:
> how about a ps form a non-jitted shell?
>
> -art
>
> On 4/19/06, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> > ozinferno (i haven't worked on it for  while because of mAny reaons).
> >
> > --rw-rw-r-- M 89 brucee brucee   546 Dec  8 04:24 addpass.dis
> > --rw-rw-r-- M 89 brucee brucee   542 Dec  8 04:24 addtosrv.dis
> > --rw-rw-r-- M 89 brucee brucee  2936 Dec  8 04:24 bceget.dis
> > --rw-rw-r-- M 89 brucee brucee   492 Dec  8 04:24 bind.dis
> > --rw-rw-r-- M 89 brucee brucee  5551 Dec  8 04:24 boot.dis
> > --rw-rw-r-- M 89 brucee brucee   568 Dec  8 04:24 cat.dis
> > --rw-rw-r-- M 89 brucee brucee   498 Dec  8 04:24 cd.dis
> > --rw-rw-r-- M 89 brucee brucee  9351 Dec  8 04:24 certx509.dis
> > --rw-rw-r-- M 89 brucee brucee  1345 Dec  8 04:24 chmod.dis
> > --rw-rw-r-- M 89 brucee brucee  1749 Dec  8 04:24 cmp.dis
> > --rw-rw-r-- M 89 brucee brucee  3691 Dec  8 04:24 cp.dis
> > --rw-rw-r-- M 89 brucee brucee   801 Dec  8 04:24 dcall.dis
> > --rw-rw-r-- M 89 brucee brucee   521 Dec  8 04:24 dclient.dis
> > --rw-rw-r-- M 89 brucee brucee  6491 Dec  8 04:24 dd.dis
> > --rw-rw-r-- M 89 brucee brucee   897 Dec  8 04:24 df.dis
> > --rw-rw-r-- M 89 brucee brucee   728 Dec  8 04:24 dserver.dis
> > --rw-rw-r-- M 89 brucee brucee  2300 Dec  8 04:24 du.dis
> > --rw-rw-r-- M 89 brucee brucee   369 Dec  8 04:24 echo.dis
> > --rw-rw-r-- M 89 brucee brucee  2770 Dec  8 04:24 fencode.dis
> > --rw-rw-r-- M 89 brucee brucee  3674 Dec  8 04:24 filefs.dis
> > --rw-rw-r-- M 89 brucee brucee  4466 Dec  8 04:24 findex.dis
> > --rw-rw-r-- M 89 brucee brucee 37006 Dec  8 04:24 flashfs.dis
> > --rw-rw-r-- M 89 brucee brucee   272 Dec  8 04:24 fpit.dis
> > --rw-rw-r-- M 89 brucee brucee  1434 Dec  8 04:24 ftest.dis
> > --rw-rw-r-- M 89 brucee brucee  1037 Dec  8 04:24 genfs.dis
> > --rw-rw-r-- M 89 brucee brucee   576 Dec  8 04:24 getpass.dis
> > --rw-rw-r-- M 89 brucee brucee  1497 Dec  8 04:24 grep.dis
> > --rw-rw-r-- M 89 brucee brucee   748 Dec  8 04:24 hmac.dis
> > --rw-rw-r-- M 89 brucee brucee  1134 Dec  8 04:24 ipclass.dis
> > --rw-rw-r-- M 89 brucee brucee 29025 Dec  8 04:24 jfs.dis
> > --rw-rw-r-- M 89 brucee brucee  1439 Dec  8 04:24 kill.dis
> > --rw-rw-r-- M 89 brucee brucee  2051 Dec  8 04:24 ls.dis
> > --rw-rw-r-- M 89 brucee brucee  4473 Dec  8 04:24 mash.dis
> > --rw-rw-r-- M 89 brucee brucee   997 Dec  8 04:24 memfs.dis
> > --rw-rw-r-- M 89 brucee brucee  1307 Dec  8 04:24 mkdatafs.dis
> > --rw-rw-r-- M 89 brucee brucee   386 Dec  8 04:24 mkdir.dis
> > --rw-rw-r-- M 89 brucee brucee  5911 Dec  8 04:24 mkffs.dis
> > --rw-rw-r-- M 89 brucee brucee  6399 Dec  8 04:24 mkjfs.dis
> > --rw-rw-r-- M 89 brucee brucee  1422 Dec  8 04:24 mkkeypair.dis
> > --rw-rw-r-- M 89 brucee brucee  8078 Dec  8 04:24 mksakfs.dis
> > --rw-rw-r-- M 89 brucee brucee  2858 Dec  8 04:24 mv.dis
> > --rw-rw-r-- M 89 brucee brucee  1721 Dec  8 04:24 ossrv.dis
> > --rw-rw-r-- M 89 brucee brucee   349 Dec  8 04:24 pig.dis
> > --rw-rw-r-- M 89 brucee brucee    81 Dec  8 04:24 proto.dis
> > --rw-rw-r-- M 89 brucee brucee  1170 Dec  8 04:24 protosrvfs.dis
> > --rw-rw-r-- M 89 brucee brucee   635 Dec  8 04:24 ps.dis
> > --rw-rw-r-- M 89 brucee brucee   345 Dec  8 04:24 pwd.dis
> > --rw-rw-r-- M 89 brucee brucee   241 Dec  8 04:24 quote.dis
> > --rw-rw-r-- M 89 brucee brucee   976 Dec  8 04:24 rm.dis
> > --rw-rw-r-- M 89 brucee brucee   859 Dec  8 04:24 sadd.dis
> > --rw-rw-r-- M 89 brucee brucee   987 Dec  8 04:24 sakfs.dis
> > --rw-rw-r-- M 89 brucee brucee  5169 Dec  8 04:24 sh.dis
> > --rw-rw-r-- M 89 brucee brucee  4026 Dec  8 04:24 sign.dis
> > --rw-rw-r-- M 89 brucee brucee   651 Dec  8 04:24 srvfs.dis
> > --rw-rw-r-- M 89 brucee brucee   512 Dec  8 04:24 unmount.dis
> > --rw-rw-r-- M 89 brucee brucee  7117 Dec  8 04:24 venti.dis
> > --rw-rw-r-- M 89 brucee brucee  4262 Dec  8 04:24 web.dis
> > --rw-rw-r-- M 89 brucee brucee 39376 Dec  8 04:24 yacc.dis
> >
> > hmm shell 5169 bytes ...
> >
> > brucee
> >
> > On 4/19/06, Lyndon Nerenberg <lyndon@orthanc.ca> wrote:
> > >
> > > On Apr 19, 2006, at 2:37 AM, Bruce Ellis wrote:
> > >
> > > > and it achieves the goal of making apps tiny.
> > > >
> > > > brucee
> > >
> > > blonde?  how much?
> > >
> >
>

Re: [9fans] Install from CD fails

[Roman Shaposhnick]

On Tue, Apr 18, 2006 at 09:35:27PM -0500, erik quanstrom wrote:
> i think there is a #3 here.  extension.
>
> dynamic linking allows one to extend a program without inventing a metalanguage.
> i believe there is a paper on how inferno's shell uses this to nice effect.

  I think you're confusing two notions here. What you're talking about
  sounds more like dynamic loading, not dynamic linking. And with dynamic
  loading the control is *explicitly* at client's possession. You're
  supposed to know what to dlopen, what to look for inside, etc. Such
  a controlled environment lets you be much more precise and avoid
  many of the shortcomings of the true "dynamic linking".

  Now, it would be interesting to know what others think about the need
  for dynamic loading in Plan9.

  Personally, my dream has always been to make all of the applications
  which rely heavily on console input-output to be dynamically loaded
  on top of each other, so that when I do something like:

    $ bash
    <long session with bash, with lots of useful stuff in history and such>
    $ gdb

  I don't leave shell (and lose all of the context) but I rather have
  my shell augmented with gdb commands. Sort of like Tcl works with
  external modules.

  Have anybody thought about anything likes this ?

Thanks,
Roman.

Re: [9fans] Install from CD fails

[Bruce Ellis]

that is how mash works ... you augment it's command set by loading
modules (for example "make").

brucee

On 4/20/06, Roman Shaposhnick <rvs@sun.com> wrote:
> On Tue, Apr 18, 2006 at 09:35:27PM -0500, erik quanstrom wrote:
> > i think there is a #3 here.  extension.
> >
> > dynamic linking allows one to extend a program without inventing a metalanguage.
> > i believe there is a paper on how inferno's shell uses this to nice effect.
>
>  I think you're confusing two notions here. What you're talking about
>  sounds more like dynamic loading, not dynamic linking. And with dynamic
>  loading the control is *explicitly* at client's possession. You're
>  supposed to know what to dlopen, what to look for inside, etc. Such
>  a controlled environment lets you be much more precise and avoid
>  many of the shortcomings of the true "dynamic linking".
>
>  Now, it would be interesting to know what others think about the need
>  for dynamic loading in Plan9.
>
>  Personally, my dream has always been to make all of the applications
>  which rely heavily on console input-output to be dynamically loaded
>  on top of each other, so that when I do something like:
>
>    $ bash
>    <long session with bash, with lots of useful stuff in history and such>
>    $ gdb
>
>  I don't leave shell (and lose all of the context) but I rather have
>  my shell augmented with gdb commands. Sort of like Tcl works with
>  external modules.
>
>  Have anybody thought about anything likes this ?
>
> Thanks,
> Roman.
>

Re: [9fans] Install from CD fails

[Roman Shaposhnick]

On Thu, Apr 20, 2006 at 05:42:15AM +1000, Bruce Ellis wrote:
> that is how mash works ... you augment it's command set by loading
> modules (for example "make").

  what's mash ?

Thanks,
Roman.

P.S. And yes, I've tried google ;-)

Re: [9fans] Install from CD fails

[Jack Johnson]

On 4/19/06, Roman Shaposhnick <rvs@sun.com> wrote:
>   what's mash ?

http://www.vitanuova.com/inferno/man/1/mash.html

-Jack

Re: [9fans] Install from CD fails

[Charles Forsyth]

>   Now, it would be interesting to know what others think about the need
>   for dynamic loading in Plan9.

the mechanisms are probably not much used yet outside Plan 9's emu for Inferno
but [58q]l support dynamic loading in a way that unusually provides type checking,
and structured in a similar way to Inferno's Dis modules.
?l can produce loadable modules that contain two sets of type-tagged symbols,
one set to be imported from the surrounding environment and the other to be
exported to it.  there is a small supporting library.
economically, it uses the same type checking mechanism that is used statically by ?l.
or to put it another way, the mechanism was designed to support both.

Re: [9fans] Install from CD fails

[Brantley Coile]

>   Now, it would be interesting to know what others think about the need
>   for dynamic loading in Plan9.

If you want Oberon you know where to get it?
	:)

(I like Oberon--the system and the language.)

Re: [9fans] Install from CD fails

[quanstro]

yes.  there are a couple (okay, three) problems to address here.  byron and paul haahr
addressed some of the problems with a shell called "es" years ago, even though they
didn't have dynamic modules.

1.  what interface do external modules get to see?  perhaps masquerading as
a shell function would be good enough.

2. what hooks are provided by the shell.  the "es" shell provided a hook
for darn near every language construct there was.  for example, it was possible
to redefine globbing, piping, the if statement, etc.

i thought the result was effective, but somewhat like pounding a nail with
a jackhammer. (traditional shell syntax was first converted from
	a | b
to es's perferred syntax
	%pipe {a} 0 1 {b}
then bound as
	$&pipe {a} {b},
assuming one hadn't redefined %pipe.)

3. shell syntax vs. command syntax.  the shell's syntax often gets in the way
of command syntax.  mike hartel wrote up some stuff about this years ago.
basically, it's a pain that the shell and, say, grep, want to use the same characters.
i can't just type
	; grep ^fn *.[ch]
i must type
	; grep '^fn' *.[ch]
instead.  this would get very difficult if one added awk-like functions to the shell.
es did this: anything passed to a function inside curly braces was passed verbatim.
thus "if" in es looks like a normal es function call:
	; if {condition1} {body1} {condition2} {body2}
a trivial grep module could make
	; grep {^fn} *.[ch]
acceptable syntax.

- erik


On Wed Apr 19 14:35:12 CDT 2006, rvs@sun.com wrote:
>
>   Personally, my dream has always been to make all of the applications
>   which rely heavily on console input-output to be dynamically loaded
>   on top of each other, so that when I do something like:
>
>     $ bash
>     <long session with bash, with lots of useful stuff in history and such>
>     $ gdb
>
>   I don't leave shell (and lose all of the context) but I rather have
>   my shell augmented with gdb commands. Sort of like Tcl works with
>   external modules.
>
>   Have anybody thought about anything likes this ?
>
> Thanks,
> Roman.

Re: [9fans] Install from CD fails

[rog]

> yes.  there are a couple (okay, three) problems to address here.  byron and paul haahr
> addressed some of the problems with a shell called "es" years ago, even though they
> didn't have dynamic modules.

i had es in mind when i wrote the inferno shell (vita nuova's, not the original tiny shell).
i thought then that some of the es concepts were nice, but the whole complete functional language
thing was overkill and didn't get one very far (why make it possible to redefine
core shell concepts such as the pipe? - it just confuses everyone if you make use of this.)

inferno made it very easy to provide "internal" modules (which i called "builtins";
i never really thought of a satisfactory name) - the interface they get to
see is a restricted version of the interface seen by the shell itself internally.
i tried to keep this as clean as possible. (by contrast, mash, which did a similar
thing, had quite a complex interface at this level).

> es did this: anything passed to a function inside curly braces was passed verbatim.

that was the main bit of es that i stole for the inferno shell. it works well,
and combined with dynamically loaded shell modules, makes many nice things quite
easy.

for instance:
> 	; if {condition1} {body1} {condition2} {body2}

is not implemented by the core inferno shell, but by an externally loaded
module (std).

since then, shell modules have been implemented for all kinds of things (e.g. graphics,
s-expression parsing, mash-like make).
externally implemented programs are still preferable (smaller interface,
the shell doesn't break if the program does), for interfaces which
need to maintain state across calls or wish to call back into the shell,
a shell module can work well. it also makes it easy (and efficient)
for a function in such a module to return a list of values (the fundamental
type).

the main problem is that a shell of this style
has no concept of storage of any item but a string (ok, a list of strings), so it is not
possible to manipulate other data items directly. also, the interface makes
it quite natural to pass code fragments to external programs to execute,
e.g.
	listen 'tcp!*!6666' {export /&}
but the external programs don't have access to the original shell's
environment (e.g. loaded shell modules).

i don't think it's possible to address these problems without
breaking the simplicity of the whole thing; the moment you
introduce lexical binding, differently typed variables, etc,
a whole raft of other issues starts to drift into view.
another kind of language might begin to help, but that's another
story.

just having shell blocks as values is a big win, in my book.
i don't think it would be hard to do this in rc.

> a trivial grep module could make
>	; grep {^fn} *.[ch]
> acceptable syntax.

i'm sorry, i don't see why this is preferable to the original.
it has the same number of characters.

Re: [9fans] Install from CD fails

[Charles Forsyth]

>> es did this: anything passed to a function inside curly braces was passed verbatim.
>
> that was the main bit of es that i stole for the inferno shell. it works well,
> and combined with dynamically loaded shell modules, makes many nice things quite
> easy.

i thought that in the inferno sh the bit inside the {} was parsed, and later converted
back to a string if passed to a command (uniform treatment of {} as in `{}, and you
discover your syntax errors in good time).  i don't remember what es did.

Re: [9fans] Install from CD fails

[rog]

> i thought that in the inferno sh the bit inside the {} was parsed, and later converted
> back to a string if passed to a command (uniform treatment of {} as in `{}, and you
> discover your syntax errors in good time).  i don't remember what es did.

that's true, but es did exactly the same thing. the internal representation is the
shell's syntax tree (which means that evaluation of sub-blocks is reasonably efficient,
unlike tcl, which has to rescan the string each time through), but the string representation
should generate exactly the same tree when parsed, so for most practical purposes,
it can be treated as if it *was* verbatim (excess white space is removed, as are comments).

i could have used a similar approach to your v7 "export a function containing the code", but
it's nice to be able to pass code fragments around to unrelated processes, for instance
to remotely execute some code on a file server.

the other thing the inferno shell allows, which i thought quite neat at the time,
is that a running program can load itself as a module into an instance of the shell,
and define shell "builtins" that call back into the program, thus giving scriptability
at little cost. for instance, the window manager does this for its initialisation script:
the "menu" primitive adds a new item to the window manager menu (its argument is,
of course, a shell command to run when the item is invoked).

Re: [9fans] Install from CD fails

[Roman Shaposhnick]

On Wed, Apr 19, 2006 at 04:46:47PM -0500, quanstro@quanstro.net wrote:
> yes.  there are a couple (okay, three) problems to address here.  byron and paul haahr
> addressed some of the problems with a shell called "es" years ago, even though they
> didn't have dynamic modules.
>
> 1.  what interface do external modules get to see?  perhaps masquerading as
> a shell function would be good enough.

  I think Tcl has struck a nice balance here -- everything is a command
  taking a number of arguments. Or are you talking about a different
  sort of interface ?

> 2. what hooks are provided by the shell.  the "es" shell provided a hook
> for darn near every language construct there was.  for example, it was possible
> to redefine globbing, piping, the if statement, etc.

  That is a bit too much, in my oppinion. I think what the 'core' shell
  is supposed to do is provide a nice glue for the rest of the dynamic
  functionality. Sort of like file system is a universal glue for every
  other application running on the system. I would say that this is the
  most challenging aspect of designing my dream 'shell' -- the glue is
  supposed to be easy enough for me to understand, yet powerful enough
  to express simple things in simple terms. Tcl comes pretty close
  to being that glue.

  Any other suggestions ?

> 3. shell syntax vs. command syntax.  the shell's syntax often gets in the way
> of command syntax.

  I think this is unavoidable. But somehow, I don't really perceive it to
  be that big of a deal, anyway. Quoting is quite useful and not really
  painful. At least as long as you understand the rules involved. That's
  why I like Tcl so much -- even though you have to use extra quote or eval
  from time to time, you know exactly how everything gets parsed because
  there's only 11 rules to describe the entire language machinery.

> mike hartel wrote up some stuff about this years ago.
> basically, it's a pain that the shell and, say, grep, want to use the same characters.
> i can't just type
> 	; grep ^fn *.[ch]
> i must type
> 	; grep '^fn' *.[ch]
> instead.  this would get very difficult if one added awk-like functions to the shell.
> es did this: anything passed to a function inside curly braces was passed verbatim.
> thus "if" in es looks like a normal es function call:
> 	; if {condition1} {body1} {condition2} {body2}

   That sounds exactly like Tcl.

Thanks,
Roman.