* 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: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 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-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
* 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
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).