* Re: [9fans] Install from CD fails
@ 2006-04-19 2:35 erik quanstrom
2006-04-19 3:53 ` Russ Cox
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
0 siblings, 2 replies; 19+ messages in thread
From: erik quanstrom @ 2006-04-19 2:35 UTC (permalink / raw)
To: 9fans
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.
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 2:35 [9fans] Install from CD fails erik quanstrom
@ 2006-04-19 3:53 ` Russ Cox
2006-04-19 4:25 ` [9fans] dynamic module loading and versioning Michael Baldwin
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
1 sibling, 1 reply; 19+ messages in thread
From: Russ Cox @ 2006-04-19 3:53 UTC (permalink / raw)
To: 9fans
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [9fans] dynamic module loading and versioning
2006-04-19 3:53 ` Russ Cox
@ 2006-04-19 4:25 ` Michael Baldwin
2006-04-19 9:37 ` Bruce Ellis
0 siblings, 1 reply; 19+ messages in thread
From: Michael Baldwin @ 2006-04-19 4:25 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> 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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] dynamic module loading and versioning
2006-04-19 4:25 ` [9fans] dynamic module loading and versioning Michael Baldwin
@ 2006-04-19 9:37 ` Bruce Ellis
2006-04-19 9:40 ` Lyndon Nerenberg
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Ellis @ 2006-04-19 9:37 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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?
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] dynamic module loading and versioning
2006-04-19 9:37 ` Bruce Ellis
@ 2006-04-19 9:40 ` Lyndon Nerenberg
2006-04-19 9:54 ` Bruce Ellis
0 siblings, 1 reply; 19+ messages in thread
From: Lyndon Nerenberg @ 2006-04-19 9:40 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Apr 19, 2006, at 2:37 AM, Bruce Ellis wrote:
> and it achieves the goal of making apps tiny.
>
> brucee
blonde? how much?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] dynamic module loading and versioning
2006-04-19 9:40 ` Lyndon Nerenberg
@ 2006-04-19 9:54 ` Bruce Ellis
2006-04-19 14:12 ` Artem Letko
0 siblings, 1 reply; 19+ messages in thread
From: Bruce Ellis @ 2006-04-19 9:54 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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?
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] dynamic module loading and versioning
2006-04-19 9:54 ` Bruce Ellis
@ 2006-04-19 14:12 ` Artem Letko
2006-04-19 17:49 ` Bruce Ellis
0 siblings, 1 reply; 19+ messages in thread
From: Artem Letko @ 2006-04-19 14:12 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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?
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] dynamic module loading and versioning
2006-04-19 14:12 ` Artem Letko
@ 2006-04-19 17:49 ` Bruce Ellis
0 siblings, 0 replies; 19+ messages in thread
From: Bruce Ellis @ 2006-04-19 17:49 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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?
> > >
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 2:35 [9fans] Install from CD fails erik quanstrom
2006-04-19 3:53 ` Russ Cox
@ 2006-04-19 19:34 ` Roman Shaposhnick
2006-04-19 19:42 ` Bruce Ellis
` (3 more replies)
1 sibling, 4 replies; 19+ messages in thread
From: Roman Shaposhnick @ 2006-04-19 19:34 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
@ 2006-04-19 19:42 ` Bruce Ellis
2006-04-20 1:07 ` Roman Shaposhnick
2006-04-19 19:45 ` Charles Forsyth
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Bruce Ellis @ 2006-04-19 19:42 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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.
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
2006-04-19 19:42 ` Bruce Ellis
@ 2006-04-19 19:45 ` Charles Forsyth
2006-04-19 21:16 ` Brantley Coile
2006-04-19 21:46 ` quanstro
3 siblings, 0 replies; 19+ messages in thread
From: Charles Forsyth @ 2006-04-19 19:45 UTC (permalink / raw)
To: 9fans
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
2006-04-19 19:42 ` Bruce Ellis
2006-04-19 19:45 ` Charles Forsyth
@ 2006-04-19 21:16 ` Brantley Coile
2006-04-19 21:46 ` quanstro
3 siblings, 0 replies; 19+ messages in thread
From: Brantley Coile @ 2006-04-19 21:16 UTC (permalink / raw)
To: 9fans
> 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.)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
` (2 preceding siblings ...)
2006-04-19 21:16 ` Brantley Coile
@ 2006-04-19 21:46 ` quanstro
2006-04-20 1:03 ` rog
2006-04-20 4:02 ` Roman Shaposhnick
3 siblings, 2 replies; 19+ messages in thread
From: quanstro @ 2006-04-19 21:46 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 21:46 ` quanstro
@ 2006-04-20 1:03 ` rog
2006-04-20 6:08 ` Charles Forsyth
2006-04-20 4:02 ` Roman Shaposhnick
1 sibling, 1 reply; 19+ messages in thread
From: rog @ 2006-04-20 1:03 UTC (permalink / raw)
To: 9fans
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 19:42 ` Bruce Ellis
@ 2006-04-20 1:07 ` Roman Shaposhnick
2006-04-20 2:02 ` Jack Johnson
0 siblings, 1 reply; 19+ messages in thread
From: Roman Shaposhnick @ 2006-04-20 1:07 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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 ;-)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-20 1:07 ` Roman Shaposhnick
@ 2006-04-20 2:02 ` Jack Johnson
0 siblings, 0 replies; 19+ messages in thread
From: Jack Johnson @ 2006-04-20 2:02 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On 4/19/06, Roman Shaposhnick <rvs@sun.com> wrote:
> what's mash ?
http://www.vitanuova.com/inferno/man/1/mash.html
-Jack
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-19 21:46 ` quanstro
2006-04-20 1:03 ` rog
@ 2006-04-20 4:02 ` Roman Shaposhnick
1 sibling, 0 replies; 19+ messages in thread
From: Roman Shaposhnick @ 2006-04-20 4:02 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-20 1:03 ` rog
@ 2006-04-20 6:08 ` Charles Forsyth
2006-04-20 15:59 ` rog
0 siblings, 1 reply; 19+ messages in thread
From: Charles Forsyth @ 2006-04-20 6:08 UTC (permalink / raw)
To: 9fans
>> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [9fans] Install from CD fails
2006-04-20 6:08 ` Charles Forsyth
@ 2006-04-20 15:59 ` rog
0 siblings, 0 replies; 19+ messages in thread
From: rog @ 2006-04-20 15:59 UTC (permalink / raw)
To: 9fans
> 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).
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2006-04-20 15:59 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-04-19 2:35 [9fans] Install from CD fails erik quanstrom
2006-04-19 3:53 ` Russ Cox
2006-04-19 4:25 ` [9fans] dynamic module loading and versioning Michael Baldwin
2006-04-19 9:37 ` Bruce Ellis
2006-04-19 9:40 ` Lyndon Nerenberg
2006-04-19 9:54 ` Bruce Ellis
2006-04-19 14:12 ` Artem Letko
2006-04-19 17:49 ` Bruce Ellis
2006-04-19 19:34 ` [9fans] Install from CD fails Roman Shaposhnick
2006-04-19 19:42 ` Bruce Ellis
2006-04-20 1:07 ` Roman Shaposhnick
2006-04-20 2:02 ` Jack Johnson
2006-04-19 19:45 ` Charles Forsyth
2006-04-19 21:16 ` Brantley Coile
2006-04-19 21:46 ` quanstro
2006-04-20 1:03 ` rog
2006-04-20 6:08 ` Charles Forsyth
2006-04-20 15:59 ` rog
2006-04-20 4:02 ` Roman Shaposhnick
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).