* [9fans] Pegasus 2.6 is released @ 2009-02-01 4:29 Kenji Arisawa 2009-02-01 4:41 ` lucio ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: Kenji Arisawa @ 2009-02-01 4:29 UTC (permalink / raw) To: Fans Bell Labs of the OS Plan 9 from Hello, Pegasus 2.6 is released with new WebDAV script written in Lua. Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details. Enjoy Kenji Arisawa ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 4:29 [9fans] Pegasus 2.6 is released Kenji Arisawa @ 2009-02-01 4:41 ` lucio 2009-02-01 4:47 ` Kenji Arisawa 2009-02-01 4:43 ` John Barham 2009-02-01 5:47 ` John Barham 2 siblings, 1 reply; 51+ messages in thread From: lucio @ 2009-02-01 4:41 UTC (permalink / raw) To: 9fans > Pegasus 2.6 is released with new WebDAV script written in Lua. > Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details. We need a little bit more than "plan9" in the host name :-) ++L ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 4:41 ` lucio @ 2009-02-01 4:47 ` Kenji Arisawa 0 siblings, 0 replies; 51+ messages in thread From: Kenji Arisawa @ 2009-02-01 4:47 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs Sorry, http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/ Kenji Arisawa On 2009/02/01, at 13:41, lucio@proxima.alt.za wrote: >> Pegasus 2.6 is released with new WebDAV script written in Lua. >> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more >> details. > > We need a little bit more than "plan9" in the host name :-) > > ++L > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 4:29 [9fans] Pegasus 2.6 is released Kenji Arisawa 2009-02-01 4:41 ` lucio @ 2009-02-01 4:43 ` John Barham 2009-02-01 4:50 ` andrey mirtchovski 2009-02-01 5:47 ` John Barham 2 siblings, 1 reply; 51+ messages in thread From: John Barham @ 2009-02-01 4:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: arisawa Kenji Arisawa wrote: > Pegasus 2.6 is released with new WebDAV script written in Lua. > Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details. Do you have a non-local URL host name? ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 4:43 ` John Barham @ 2009-02-01 4:50 ` andrey mirtchovski 0 siblings, 0 replies; 51+ messages in thread From: andrey mirtchovski @ 2009-02-01 4:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/ ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 4:29 [9fans] Pegasus 2.6 is released Kenji Arisawa 2009-02-01 4:41 ` lucio 2009-02-01 4:43 ` John Barham @ 2009-02-01 5:47 ` John Barham 2009-02-01 6:44 ` erik quanstrom ` (2 more replies) 2 siblings, 3 replies; 51+ messages in thread From: John Barham @ 2009-02-01 5:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Pegasus 2.6 is released with new WebDAV script written in Lua. Interesting that you used Lua. I think it's generally under-appreciated but IMO is very well designed and philosophically a good fit for Plan 9. However, inasmuch as you had to build a custom interpreter to add features for Pegasus this exposes a weakness of Plan 9 in that it can't dynamically load libraries at run-time which is the normal extension mechanism for scripting languages on other platforms. Can someone comment on how feasible it would be to add general support for dynamically loading libraries to Plan 9? Is there some structural reason why it can't be done or is it just that nobody has done the work yet? Note that I am specifically not asking about "shared" libraries... John ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 5:47 ` John Barham @ 2009-02-01 6:44 ` erik quanstrom 2009-02-01 7:27 ` John Barham 2009-02-01 7:31 ` [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) lucio 2009-02-01 11:26 ` [9fans] Pegasus 2.6 is released Charles Forsyth 2 siblings, 1 reply; 51+ messages in thread From: erik quanstrom @ 2009-02-01 6:44 UTC (permalink / raw) To: 9fans > However, inasmuch as you had to build a custom > interpreter to add features for Pegasus this exposes a weakness of > Plan 9 in that it can't dynamically load libraries at run-time which > is the normal extension mechanism for scripting languages on other > platforms. pegasus is written in c, not a scripting language. i believe lua is used as one possible language for cgi. the argument that if the normal extension mechanism for scripting languages is x, thereforenot having x is a weakness seems a version of argumentum ad populum. doesn't dynamic loading seem at odds with the tools approach? the more complex the interface, the less general the tool. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 6:44 ` erik quanstrom @ 2009-02-01 7:27 ` John Barham 2009-02-01 11:12 ` Francisco J Ballesteros ` (2 more replies) 0 siblings, 3 replies; 51+ messages in thread From: John Barham @ 2009-02-01 7:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > the argument that if the normal extension > mechanism for scripting languages is x, > thereforenot having x is a weakness seems > a version of argumentum ad populum. > > doesn't dynamic loading seem at odds with the > tools approach? the more complex the interface, > the less general the tool. Dynamic loading allows scripting languages to load arbitrary binary extensions at run-time. Without dynamic loading in Plan 9 you need to recompile the Lua (or Python) interpreters to statically link in your binary extensions, so in this case dynamic loading makes the tool more general. (FWIW, as has been pointed out on this list previously, Inferno applications can dynamically load modules at run-time.) John ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 7:27 ` John Barham @ 2009-02-01 11:12 ` Francisco J Ballesteros 2009-02-01 12:56 ` erik quanstrom 2009-02-02 19:25 ` sqweek 2 siblings, 0 replies; 51+ messages in thread From: Francisco J Ballesteros @ 2009-02-01 11:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Can't you just execute new processes to "load" your extensions? I understand that's not a dll, but I'm really scared of dlls after looking at what happen to linux. At least separate binaries still work if you change libraries. Just wondering. On Sun, Feb 1, 2009 at 8:27 AM, John Barham <jbarham@gmail.com> wrote: >> the argument that if the normal extension >> mechanism for scripting languages is x, >> thereforenot having x is a weakness seems >> a version of argumentum ad populum. >> >> doesn't dynamic loading seem at odds with the >> tools approach? the more complex the interface, >> the less general the tool. > > Dynamic loading allows scripting languages to load arbitrary binary > extensions at run-time. Without dynamic loading in Plan 9 you need to > recompile the Lua (or Python) interpreters to statically link in your > binary extensions, so in this case dynamic loading makes the tool more > general. (FWIW, as has been pointed out on this list previously, > Inferno applications can dynamically load modules at run-time.) > > John > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 7:27 ` John Barham 2009-02-01 11:12 ` Francisco J Ballesteros @ 2009-02-01 12:56 ` erik quanstrom 2009-02-02 19:25 ` sqweek 2 siblings, 0 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-01 12:56 UTC (permalink / raw) To: 9fans > > the argument that if the normal extension > > mechanism for scripting languages is x, > > thereforenot having x is a weakness seems > > a version of argumentum ad populum. > > > > doesn't dynamic loading seem at odds with the > > tools approach? the more complex the interface, > > the less general the tool. > > Dynamic loading allows scripting languages to load arbitrary binary > extensions at run-time. Without dynamic loading in Plan 9 you need to > recompile the Lua (or Python) interpreters to statically link in your > binary extensions, so in this case dynamic loading makes the tool more > general. (FWIW, as has been pointed out on this list previously, > Inferno applications can dynamically load modules at run-time.) why do you assume that lua or whatever is not sufficient for the task? maybe it's the language itself that needs fixing. otoh, my experience building websites is that i've never wanted arbitrary functionality in the cgi. once things got sufficiently compliated, it made sense to build a server to manage user sessions and whatnot. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 7:27 ` John Barham 2009-02-01 11:12 ` Francisco J Ballesteros 2009-02-01 12:56 ` erik quanstrom @ 2009-02-02 19:25 ` sqweek 2009-02-02 19:44 ` erik quanstrom ` (2 more replies) 2 siblings, 3 replies; 51+ messages in thread From: sqweek @ 2009-02-02 19:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote: > Dynamic loading allows scripting languages to load arbitrary binary > extensions at run-time. Without dynamic loading in Plan 9... You're missing the beauty of 9p. Who needs dynload() when you have mount()? -sqweek ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 19:25 ` sqweek @ 2009-02-02 19:44 ` erik quanstrom 2009-02-02 19:49 ` Roman V. Shaposhnik 2009-02-02 21:22 ` John Barham 2 siblings, 0 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-02 19:44 UTC (permalink / raw) To: 9fans > On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote: >> Dynamic loading allows scripting languages to load arbitrary binary >> extensions at run-time. Without dynamic loading in Plan 9... > > You're missing the beauty of 9p. Who needs dynload() when you have mount()? this thinking goes back to the beginning with pipes and the shell. to use object-oriented language out of place, any program that produces or consumes a byte stream can be extended by another program that produces or consumes a byte stream. with a thread library program that passes messages on channels, one could do similar extensions by replacing one end of the channel in a similar manner to replacing a program in a regular pipe. though message typing would limit the generality of the arrangement. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 19:25 ` sqweek 2009-02-02 19:44 ` erik quanstrom @ 2009-02-02 19:49 ` Roman V. Shaposhnik 2009-02-02 21:22 ` John Barham 2 siblings, 0 replies; 51+ messages in thread From: Roman V. Shaposhnik @ 2009-02-02 19:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, 2009-02-03 at 04:25 +0900, sqweek wrote: > On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote: > > Dynamic loading allows scripting languages to load arbitrary binary > > extensions at run-time. Without dynamic loading in Plan 9... > > You're missing the beauty of 9p. Who needs dynload() when you have mount()? I was going to say exactly that! dynload() is really not very well suited for a highly distributed age. I have come to realize that it is nothing but an unfortunate optimization of R out of RPC. Now, making 'R' fast (if your caller-callee is on the same node, etc) is very much desired. Trying to get rid of it, or pretend that it is not needed -- is doomed. Thanks, Roman. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 19:25 ` sqweek 2009-02-02 19:44 ` erik quanstrom 2009-02-02 19:49 ` Roman V. Shaposhnik @ 2009-02-02 21:22 ` John Barham 2009-02-02 21:27 ` erik quanstrom ` (2 more replies) 2 siblings, 3 replies; 51+ messages in thread From: John Barham @ 2009-02-02 21:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > You're missing the beauty of 9p. Who needs dynload() when you have mount()? Mount allows me to add new names to the process namespace. Dynload allows me to call functions or access data in a library that is not known to the process (e.g., scripting language interpreter) until runtime. They solve different problems. John ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 21:22 ` John Barham @ 2009-02-02 21:27 ` erik quanstrom 2009-02-02 21:32 ` David Leimbach 2009-02-02 22:07 ` Roman V. Shaposhnik 2 siblings, 0 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-02 21:27 UTC (permalink / raw) To: 9fans >> You're missing the beauty of 9p. Who needs dynload() when you have mount()? > > Mount allows me to add new names to the process namespace. Dynload > allows me to call functions or access data in a library that is not > known to the process (e.g., scripting language interpreter) until > runtime. They solve different problems. there is no fundamental reason they could not solve the same problem. why are you so keen to remove the rpc? - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 21:22 ` John Barham 2009-02-02 21:27 ` erik quanstrom @ 2009-02-02 21:32 ` David Leimbach 2009-02-02 22:11 ` Roman V. Shaposhnik 2009-02-02 22:12 ` ron minnich 2009-02-02 22:07 ` Roman V. Shaposhnik 2 siblings, 2 replies; 51+ messages in thread From: David Leimbach @ 2009-02-02 21:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1001 bytes --] On Mon, Feb 2, 2009 at 1:22 PM, John Barham <jbarham@gmail.com> wrote: > > You're missing the beauty of 9p. Who needs dynload() when you have > mount()? > > Mount allows me to add new names to the process namespace. Dynload > allows me to call functions or access data in a library that is not > known to the process (e.g., scripting language interpreter) until > runtime. They solve different problems. They solve the same class of problems, if you step back far enough. If your application's mechanism of dealing with processing is to use the namespace, then binding new functionality over old is roughly equivalent to a plugin mechanism. I mean sure you could use FTP to transfer files, but the old shell based tools are automagically plugged in with network capabilities when they deal with a FTP backed namespace right? So without any binary loader capabilities "cp" "mv" and other existing "small programs" are now "plugged in". Dave > > > John > > [-- Attachment #2: Type: text/html, Size: 1609 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 21:32 ` David Leimbach @ 2009-02-02 22:11 ` Roman V. Shaposhnik 2009-02-02 22:17 ` erik quanstrom 2009-02-02 22:12 ` ron minnich 1 sibling, 1 reply; 51+ messages in thread From: Roman V. Shaposhnik @ 2009-02-02 22:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2009-02-02 at 13:32 -0800, David Leimbach wrote: > I mean sure you could use FTP to transfer files, but the old shell > based tools are automagically plugged in with network capabilities > when they deal with a FTP backed namespace right? So without any > binary loader capabilities "cp" "mv" and other existing "small > programs" are now "plugged in". Right. That plus the fact that the "plugin" is now generally available over the network makes it much more interesting. In fact, these current trend towards REST in web services seems to be a validation of 9P view of the world. Thanks, Roman. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:11 ` Roman V. Shaposhnik @ 2009-02-02 22:17 ` erik quanstrom 2009-02-02 22:30 ` Anthony Sorace 0 siblings, 1 reply; 51+ messages in thread From: erik quanstrom @ 2009-02-02 22:17 UTC (permalink / raw) To: 9fans > Right. That plus the fact that the "plugin" is now generally available > over the network makes it much more interesting. > > In fact, these current trend towards REST in web services seems > to be a validation of 9P view of the world. it's interesting to compare this with the sleezy not-paths that e.g. gnome programs can take, like uris. great as long as long as you don't care to use anything but gnome tools. i suppose you could link sed &c against gnome. but that's crass, even by linux standards. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:17 ` erik quanstrom @ 2009-02-02 22:30 ` Anthony Sorace 2009-02-02 22:44 ` erik quanstrom 2009-02-02 23:18 ` David Leimbach 0 siblings, 2 replies; 51+ messages in thread From: Anthony Sorace @ 2009-02-02 22:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs erik wrote: > it's interesting to compare this with the sleezy not-paths > that e.g. gnome programs can take, like uris. great as long > as long as you don't care to use anything but gnome tools. i had that debate with a kde-loving linux admin. i had been explaining why plan 9 was interesting or significant, and he countered with the kde example. i was marginally impressed by the number of protocols they handled, but when i asked how you'd use it with cat and friends, he said "no, just use kate". i reeled, stuttered, tried to get out something that sounded like "layering violation", and ran away. it wasn't even a cost/benefit argument; there wasn't any recognition of the costs. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:30 ` Anthony Sorace @ 2009-02-02 22:44 ` erik quanstrom 2009-02-02 22:57 ` Anthony Sorace 2009-02-03 4:26 ` lucio 2009-02-02 23:18 ` David Leimbach 1 sibling, 2 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-02 22:44 UTC (permalink / raw) To: 9fans > i had that debate with a kde-loving linux admin. i had been explaining > why plan 9 was interesting or significant, and he countered with the > kde example. i was marginally impressed by the number of protocols > they handled, but when i asked how you'd use it with cat and friends, > he said "no, just use kate". > > i reeled, stuttered, tried to get out something that sounded like > "layering violation", and ran away. it wasn't even a cost/benefit > argument; there wasn't any recognition of the costs. does he also plans to build a tcp/ip stack into his applications? maybe we could dispense with the kernel. it's complicated anyway. each application could drive hardware itself. but to make this easier, we'll used shared libraries. the only system service we'd need is a shared library loader. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:44 ` erik quanstrom @ 2009-02-02 22:57 ` Anthony Sorace 2009-02-02 23:04 ` Bruce Ellis 2009-02-03 4:26 ` lucio 1 sibling, 1 reply; 51+ messages in thread From: Anthony Sorace @ 2009-02-02 22:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs you, um... never mind. what can i say? http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:57 ` Anthony Sorace @ 2009-02-02 23:04 ` Bruce Ellis 0 siblings, 0 replies; 51+ messages in thread From: Bruce Ellis @ 2009-02-02 23:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Can I just say hahahahahahaha. Or maybe welcome to the 80's. brrucee On Tue, Feb 3, 2009 at 9:57 AM, Anthony Sorace <anothy@gmail.com> wrote: > you, um... never mind. what can i say? > > http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:44 ` erik quanstrom 2009-02-02 22:57 ` Anthony Sorace @ 2009-02-03 4:26 ` lucio 2009-02-03 4:43 ` Bruce Ellis 2009-02-03 6:38 ` ron minnich 1 sibling, 2 replies; 51+ messages in thread From: lucio @ 2009-02-03 4:26 UTC (permalink / raw) To: 9fans > maybe we could dispense with the kernel. > it's complicated anyway. each application could drive > hardware itself. but to make this easier, we'll used shared > libraries. the only system service we'd need is a shared library > loader. There's your final word in microkernels. Throw away security and things get a lot less complicated. The human brain does not have, that I am aware, security boundaries, why can't we model our personal computers on that? ++L PS: In jest, of course, but there's some value... ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-03 4:26 ` lucio @ 2009-02-03 4:43 ` Bruce Ellis 2009-02-03 6:38 ` ron minnich 1 sibling, 0 replies; 51+ messages in thread From: Bruce Ellis @ 2009-02-03 4:43 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs Or as Mark V. Shaney once said ... "Why can't everyone wake up at 3am, totally confused". I'm not sure of the relevance. brucee On Tue, Feb 3, 2009 at 3:26 PM, <lucio@proxima.alt.za> wrote: >> maybe we could dispense with the kernel. >> it's complicated anyway. each application could drive >> hardware itself. but to make this easier, we'll used shared >> libraries. the only system service we'd need is a shared library >> loader. > > There's your final word in microkernels. Throw away security and > things get a lot less complicated. The human brain does not have, > that I am aware, security boundaries, why can't we model our personal > computers on that? > > ++L > > PS: In jest, of course, but there's some value... > > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-03 4:26 ` lucio 2009-02-03 4:43 ` Bruce Ellis @ 2009-02-03 6:38 ` ron minnich 1 sibling, 0 replies; 51+ messages in thread From: ron minnich @ 2009-02-03 6:38 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs On Mon, Feb 2, 2009 at 8:26 PM, <lucio@proxima.alt.za> wrote: >> maybe we could dispense with the kernel. >> it's complicated anyway. each application could drive >> hardware itself. but to make this easier, we'll used shared >> libraries. the only system service we'd need is a shared library >> loader. um, sadly, this *is* the norm nowadays in HPC. And here you all thought you were joking. ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:30 ` Anthony Sorace 2009-02-02 22:44 ` erik quanstrom @ 2009-02-02 23:18 ` David Leimbach 1 sibling, 0 replies; 51+ messages in thread From: David Leimbach @ 2009-02-02 23:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1047 bytes --] On Mon, Feb 2, 2009 at 2:30 PM, Anthony Sorace <anothy@gmail.com> wrote: > erik wrote: > > > it's interesting to compare this with the sleezy not-paths > > that e.g. gnome programs can take, like uris. great as long > > as long as you don't care to use anything but gnome tools. > > i had that debate with a kde-loving linux admin. i had been explaining > why plan 9 was interesting or significant, and he countered with the > kde example. i was marginally impressed by the number of protocols > they handled, but when i asked how you'd use it with cat and friends, > he said "no, just use kate". > > i reeled, stuttered, tried to get out something that sounded like > "layering violation", and ran away. it wasn't even a cost/benefit > argument; there wasn't any recognition of the costs. > > Right but when you consider KDE runs on windows, then it's not as much of a layering violation... no more than Java is I guess anyway. The layering violation that I usually point at is the /dev/tcp created by the bash shell :-). [-- Attachment #2: Type: text/html, Size: 1443 bytes --] ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 21:32 ` David Leimbach 2009-02-02 22:11 ` Roman V. Shaposhnik @ 2009-02-02 22:12 ` ron minnich 2009-02-02 22:14 ` erik quanstrom ` (2 more replies) 1 sibling, 3 replies; 51+ messages in thread From: ron minnich @ 2009-02-02 22:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote: > They solve the same class of problems, if you step back far enough. > If your application's mechanism of dealing with processing is to use the > namespace, then binding new functionality over old is roughly equivalent to > a plugin mechanism. I hate to be the one to bring this up but ... if you are providing some extended (e.g.) math functionality to a program with a shared library, people are going to be upset with you if you argue that it can be done with RPC. I hope the reason is obvious :-) ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:12 ` ron minnich @ 2009-02-02 22:14 ` erik quanstrom 2009-02-02 22:32 ` ron minnich 2009-02-02 22:18 ` Roman V. Shaposhnik 2009-02-03 10:55 ` Richard Miller 2 siblings, 1 reply; 51+ messages in thread From: erik quanstrom @ 2009-02-02 22:14 UTC (permalink / raw) To: 9fans > I hate to be the one to bring this up but ... if you are providing > some extended (e.g.) math functionality to a program with a shared > library, people are going to be upset with you if you argue that it > can be done with RPC. i thought we were talking about linking c into scripting languages. you're not using python to actually do the calcuations, are you? - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:14 ` erik quanstrom @ 2009-02-02 22:32 ` ron minnich 2009-02-02 22:34 ` erik quanstrom 0 siblings, 1 reply; 51+ messages in thread From: ron minnich @ 2009-02-02 22:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Feb 2, 2009 at 2:14 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> I hate to be the one to bring this up but ... if you are providing >> some extended (e.g.) math functionality to a program with a shared >> library, people are going to be upset with you if you argue that it >> can be done with RPC. > > i thought we were talking about linking c into scripting languages. > you're not using python to actually do the calcuations, are you? > not me. But a depressingly large number of people do, nowadays. ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:32 ` ron minnich @ 2009-02-02 22:34 ` erik quanstrom 0 siblings, 0 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-02 22:34 UTC (permalink / raw) To: 9fans > not me. But a depressingly large number of people do, nowadays. i don't drink enough to keep up with modern developments. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:12 ` ron minnich 2009-02-02 22:14 ` erik quanstrom @ 2009-02-02 22:18 ` Roman V. Shaposhnik 2009-02-02 22:22 ` Francisco J Ballesteros 2009-02-03 10:55 ` Richard Miller 2 siblings, 1 reply; 51+ messages in thread From: Roman V. Shaposhnik @ 2009-02-02 22:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote: > On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote: > > > They solve the same class of problems, if you step back far enough. > > If your application's mechanism of dealing with processing is to use the > > namespace, then binding new functionality over old is roughly equivalent to > > a plugin mechanism. > > > I hate to be the one to bring this up but ... if you are providing > some extended (e.g.) math functionality to a program with a shared > library, people are going to be upset with you if you argue that it > can be done with RPC. > > I hope the reason is obvious :-) It is. It is a trivial case, after all. In non-trivial ones, the same kind of discussion used to be quite popular in OpenMP vs. MPI circles. And I shouldn't be the one to tell you where it is going, right? Thanks, Roman. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:18 ` Roman V. Shaposhnik @ 2009-02-02 22:22 ` Francisco J Ballesteros 2009-02-02 22:30 ` Roman V. Shaposhnik 0 siblings, 1 reply; 51+ messages in thread From: Francisco J Ballesteros @ 2009-02-02 22:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs But can't you `script' by calling an external program, sending it your input, and reading its output? I understand that if you have a language (say limbo) that requires loadable modules then it's another thing. However, if you want, say, to be able to process web pages or whatever just by applying different modules. Why can't them be different processes? You can just pipe your data through them. On Mon, Feb 2, 2009 at 11:18 PM, Roman V. Shaposhnik <rvs@sun.com> wrote: > On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote: >> On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote: >> >> > They solve the same class of problems, if you step back far enough. >> > If your application's mechanism of dealing with processing is to use the >> > namespace, then binding new functionality over old is roughly equivalent to >> > a plugin mechanism. >> >> >> I hate to be the one to bring this up but ... if you are providing >> some extended (e.g.) math functionality to a program with a shared >> library, people are going to be upset with you if you argue that it >> can be done with RPC. >> >> I hope the reason is obvious :-) > > It is. It is a trivial case, after all. In non-trivial ones, the > same kind of discussion used to be quite popular in OpenMP vs. > MPI circles. And I shouldn't be the one to tell you where it > is going, right? > > Thanks, > Roman. > > > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:22 ` Francisco J Ballesteros @ 2009-02-02 22:30 ` Roman V. Shaposhnik 0 siblings, 0 replies; 51+ messages in thread From: Roman V. Shaposhnik @ 2009-02-02 22:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2009-02-02 at 23:22 +0100, Francisco J Ballesteros wrote: > But can't you `script' by calling an external program, sending it your > input, and reading its output? Well, the way I see it: exec'ing is just a way to get to a transient channel. Its no different from that very same channel being present permanently in /srv or /mnt/factotum/rpc. There's *slightly* less overhead with pipes, but that's about it. Thanks, Roman. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 22:12 ` ron minnich 2009-02-02 22:14 ` erik quanstrom 2009-02-02 22:18 ` Roman V. Shaposhnik @ 2009-02-03 10:55 ` Richard Miller 2009-02-03 16:03 ` ron minnich 2 siblings, 1 reply; 51+ messages in thread From: Richard Miller @ 2009-02-03 10:55 UTC (permalink / raw) To: 9fans > if you are providing > some extended (e.g.) math functionality to a program with a shared > library, people are going to be upset with you if you argue that it > can be done with RPC. > > I hope the reason is obvious :-) Not obvious to me. In today's (well, tomorrow's) massively multicore world, I would expect a remote call to a process in another core, with its own instruction cache, could easily be more efficient than a local procedure call. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-03 10:55 ` Richard Miller @ 2009-02-03 16:03 ` ron minnich 2009-02-03 16:07 ` erik quanstrom 0 siblings, 1 reply; 51+ messages in thread From: ron minnich @ 2009-02-03 16:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Feb 3, 2009 at 2:55 AM, Richard Miller <9fans@hamnavoe.com> wrote: > Not obvious to me. In today's (well, tomorrow's) massively multicore > world, I would expect a remote call to a process in another core, with > its own instruction cache, could easily be more efficient than a local > procedure call. > well, there's remote calls and remote calls. Remote calls that go through some shared memory queue are one thing. But a remote call that goes through the kernel? You'd better have lots of work to amortize that cost. The packages I've seen do not. thanks ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-03 16:03 ` ron minnich @ 2009-02-03 16:07 ` erik quanstrom 2009-02-03 16:48 ` ron minnich 0 siblings, 1 reply; 51+ messages in thread From: erik quanstrom @ 2009-02-03 16:07 UTC (permalink / raw) To: 9fans > > Not obvious to me. In today's (well, tomorrow's) massively multicore > > world, I would expect a remote call to a process in another core, with > > its own instruction cache, could easily be more efficient than a local > > procedure call. > > > > well, there's remote calls and remote calls. Remote calls that go > through some shared memory queue are one thing. But a remote call that > goes through the kernel? You'd better have lots of work to amortize > that cost. The packages I've seen do not. ignorant question. is the cost in latency or cycles? if the cost is latency and your application is parallel, could the simple trick of having multple outstanding help? - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-03 16:07 ` erik quanstrom @ 2009-02-03 16:48 ` ron minnich 2009-02-03 17:01 ` erik quanstrom 0 siblings, 1 reply; 51+ messages in thread From: ron minnich @ 2009-02-03 16:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Here's the best answer I can give, check this out: http://www.scipy.org/ But as for introducing parallelism to cover the latency, it's an old trick and works well. But do you want to be the one to tell people, "you're going to have to introduce parallelism and fingernail-pulling bugs because I want you to use RPC, not shared libraries". I'm sure not going to do it, I've been handed my head enough times by the programmers :-) One thing I've learned: some people will take a hit of a factor of 1000 in performance to preserve their concept of what is easy to use. Hence things like scipy. It works well for many people. ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-03 16:48 ` ron minnich @ 2009-02-03 17:01 ` erik quanstrom 0 siblings, 0 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-03 17:01 UTC (permalink / raw) To: 9fans > One thing I've learned: some people will take a hit of a factor of > 1000 in performance to preserve their concept of what is easy to use. > Hence things like scipy. It works well for many people. thanks for the reference. this is an interesting problem. most of the time a 1000x hit is a great deal in the interest of simplicity. the trick is finding the problems you're willing to pay for. to the original complaint about gnome and its ilk: i don't see the argument against using file servers (rpc) instead of shared libraries (creating a super-secret wormhole world). it's not like the ftp/http transfers aren't all of the slowness, at least to a first-order approximation. - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 21:22 ` John Barham 2009-02-02 21:27 ` erik quanstrom 2009-02-02 21:32 ` David Leimbach @ 2009-02-02 22:07 ` Roman V. Shaposhnik 2 siblings, 0 replies; 51+ messages in thread From: Roman V. Shaposhnik @ 2009-02-02 22:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, 2009-02-02 at 13:22 -0800, John Barham wrote: > > You're missing the beauty of 9p. Who needs dynload() when you have > mount()? > > Mount allows me to add new names to the process namespace. Dynload > allows me to call functions or access data in a library that is not > known to the process (e.g., scripting language interpreter) until > runtime. They solve different problems. Depends on your point of view. Except for accessing data directly in the same address space, dynload() is just a way of doing fast RPC. In that line of thought, 9P offers you a very similar mechanism. I think the most obvious example of how 9P can be used to provide the kind of extensibility that folks usually associate with dynload() is factotum. Especially if you compare it with things like PAM. Thanks, Roman. ^ permalink raw reply [flat|nested] 51+ messages in thread
* [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) 2009-02-01 5:47 ` John Barham 2009-02-01 6:44 ` erik quanstrom @ 2009-02-01 7:31 ` lucio 2009-02-01 17:26 ` ron minnich 2009-02-01 18:04 ` Dave Eckhardt 2009-02-01 11:26 ` [9fans] Pegasus 2.6 is released Charles Forsyth 2 siblings, 2 replies; 51+ messages in thread From: lucio @ 2009-02-01 7:31 UTC (permalink / raw) To: 9fans > it can't dynamically load libraries at run-time which > is the normal extension mechanism for scripting languages on other > platforms. Let me sneak in here, irrespective of Erik's objections. My wild attempts at getting GCC/G++ working have led me to believe that the right idea is going to be, firstly, to get the Plan 9 kernel to load static ELF executables and, quickly on its heels, to teach it to load dynamically linked ELF objects. So far, the follow on to Lua and language interpretation, etc. I now leave this subject about which I know way too little for a diversion. I have a three-step path ahead of me: (a) cross-build a GNU toolchain targetting Plan 9 instead of, say NetBSD, which is my GNU-oriented platform of choice. The target binary format will be ELF, because my efforts at reshaping Binutils to produce Plan 9 a.out binaries were frustrated by an inability to grasp the complexity of the multiple levels of indirection (functions that call function through pointers that are overwritten by compiler flags :-( My solution does not remove the complications, but it re-uses the efforts of others, as ELF binaries are more or less native to the GNU toolchain and, hopefully, the best supported format. And before I hear too many arguments against ELF, I have done a "careful" study of the format (as it pertains to the two targets I have at hand, NetBSD and Linux/Ubuntu) and it is not totally evil, even though there are some serious gaps/flaws in it. Bottom line, I think I can use it. (b) Construct a start-up module for Plan 9's ELF libc (to be) that accepts arguments as passed by the kernel and sets up the execution environment required by, at this stage, statically-linked ELF binary modules. I'll get back to this issue. It then becomes possible to produce static ELF binaries and execute them under Plan 9. Of course, all the Plan 9 libraries now require recompiling and it all becomes massive, but not much worse than previous attempts where similar compromises were made. (c) Construct a fresh version of the linking loader (I use NetBSD's /libexec/ld.elf_so, I'm getting closer to grasping more or less how it works) that does not use MMAP to do the job of allocating memory and loading the file image. Once again, once this is coded, the kernel will need adjustment to trigger its use and, on the other end, a special start-up module to connect the kernel and the linking loader correctly. Now, the tricky parts. For one, even though assembler (as ageneric development tool for small applications) is a favourite of mine and I always felt I would be at home in any variation thereof, I'm having enormous trouble with the AT&T variations both Plan 9 and the GNU toolchain use. Most likely because I have yet to find a comprehensive manual as I used to be acquainted with when I dealt with Univac, IBM and Intel Assemblers (to name a few, to me, remarkable ones). That means that I am embarrassingly stumped both to understand the existing code and to write fresh code to serve the purposes I mentioned above. In case it is not clear: HELP! I need some tutoring to produce the start-up modules. I think there are only two: one for the linking loader, one for ELF binaries. I'm hoping that dynamic and static linking behave identically, someone here may know better. A totally distinct issue on which I am willing to accept advice is whether Plan 9 actually needs an ELF version (statically linked) of the linking loader. The initial version will be a.out, why should it not be when I'm re-writing it from scratch? But an ELF version may have many advantages, of which needing a third version of the very same start-up module is not one :-( Anyway, anyone (besides Cinap with whom I am already in touch), feel free to mail me any helpful suggestions. ++L PS: I may be missing something in the cross-compilation step, I have not dug particularly deep in that direction. I know David Hogan needed the APE libraries to be able to generate the GNU toolchain using itself. I'm about to find out how hard it all is, although that's my second step, the first is to produce the cross-toolchain on NetBSD. If anyone can save me some failures, please do. PPS: And after all this, two plugs: firstly, a grateful thank you to Russ Cox and Cinap Lenrek (I had a chance to discover his real name at Volos, but I missed it) for providing a lot of guidance with the Linux emulation code they produced and continue to support. Secondly, Cinap and I agree that based on the Linux emulation it becomes useful to implement MMAP on Plan 9. So don't be surprised if that is also going to happen with a little bit of encouragement and assistance. Oh, Cinap did a pretty adequate job of MMAP in the Linux emulation (I believe it postdates Russ' version, but I'm open to historical correction) and he should be praised for doing it. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) 2009-02-01 7:31 ` [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) lucio @ 2009-02-01 17:26 ` ron minnich 2009-02-01 18:42 ` lucio 2009-02-01 18:04 ` Dave Eckhardt 1 sibling, 1 reply; 51+ messages in thread From: ron minnich @ 2009-02-01 17:26 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs On Sat, Jan 31, 2009 at 11:31 PM, <lucio@proxima.alt.za> wrote: > > (b) Construct a start-up module for Plan 9's ELF libc (to be) that > accepts arguments as passed by the kernel and sets up the > execution environment required by, at this stage, > statically-linked ELF binary modules. This is what I'm doing on bg/p now. I've got a small program that reads in an elf binary, sets up the argv/env/aux vector(ppc thing) and jumps to main. It works. I use libmach. ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) 2009-02-01 17:26 ` ron minnich @ 2009-02-01 18:42 ` lucio 2009-02-01 20:14 ` ron minnich 0 siblings, 1 reply; 51+ messages in thread From: lucio @ 2009-02-01 18:42 UTC (permalink / raw) To: 9fans > This is what I'm doing on bg/p now. I've got a small program that > reads in an elf binary, sets up the argv/env/aux vector(ppc thing) and > jumps to main. It works. I use libmach. Can you share documentation and code? Although I would have to limit my experimentation to the 386 platform rather than the PPC. And what do you use to generate the ELF code? Static or dynamic? Both? ++L ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) 2009-02-01 18:42 ` lucio @ 2009-02-01 20:14 ` ron minnich 0 siblings, 0 replies; 51+ messages in thread From: ron minnich @ 2009-02-01 20:14 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs On Sun, Feb 1, 2009 at 10:42 AM, <lucio@proxima.alt.za> wrote: >> This is what I'm doing on bg/p now. I've got a small program that >> reads in an elf binary, sets up the argv/env/aux vector(ppc thing) and >> jumps to main. It works. I use libmach. > > Can you share documentation and code? Although I would have to limit > my experimentation to the 386 platform rather than the PPC. --rw-r--r-- M 1614 rminnich sys 7183 Feb 1 15:06 /n/sources/contrib/rminnich/bgp/machcnk.c There is stuff in there specific to bgp, as you can see. This is derived from gpl'ed code fore coreboot but I was able to use the wonderful libmach -- which does need a few more changes, I have a private copy with an enhancement I doubt you will need. It's pretty simple code and you won't need the devsegment stuff -- that's a very bgp-specific requirement -- you can just malloc code for text and data, and you can just use the plan 9 heap, whereas bgp needs a different heap. Long story. > > And what do you use to generate the ELF code? Static or dynamic? The BGP toolchain, which produces statically linked binaries. I am also supporting limited linux emulation on BGP but in kernel. The notes approach is higher overhead than I want to pay. The open and write of /dev/cnk is what flips a process into "linux system call interface" mode. The only mmap I support is for anon memory. thanks ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) 2009-02-01 7:31 ` [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) lucio 2009-02-01 17:26 ` ron minnich @ 2009-02-01 18:04 ` Dave Eckhardt 2009-02-01 18:39 ` lucio 1 sibling, 1 reply; 51+ messages in thread From: Dave Eckhardt @ 2009-02-01 18:04 UTC (permalink / raw) To: 9fans > Secondly, Cinap and I agree that based on the Linux emulation > it becomes useful to implement MMAP on Plan 9. If you do pay costs on that scale, it might be nice to get something better than just mmap() when you're done. http://9fans.net/archive/2008/07/729 http://9fans.net/archive/2008/07/535 http://9fans.net/archive/2008/07/773 Dave Eckhardt ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) 2009-02-01 18:04 ` Dave Eckhardt @ 2009-02-01 18:39 ` lucio 0 siblings, 0 replies; 51+ messages in thread From: lucio @ 2009-02-01 18:39 UTC (permalink / raw) To: 9fans > If you do pay costs on that scale, it might be nice to get > something better than just mmap() when you're done. I'm sure Cinap will drive this in the right direction. He certainly made it clear to me that his vision for MMAP is an improvement on the present model for Linux emulation. But I cannot speak for him. ++L ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 5:47 ` John Barham 2009-02-01 6:44 ` erik quanstrom 2009-02-01 7:31 ` [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) lucio @ 2009-02-01 11:26 ` Charles Forsyth 2009-02-01 11:56 ` lucio 2009-02-02 17:38 ` John Barham 2 siblings, 2 replies; 51+ messages in thread From: Charles Forsyth @ 2009-02-01 11:26 UTC (permalink / raw) To: 9fans using a variant of something we developed and then re-developed for Inferno, you can dynamically load C modules at run time, and unusually, with type checking, with support in the compilers and loaders. well, i say "modules", but of course the language pre-dates them. people pretend. it uses import/export tables with type signatures. those are stashed in the a.out (viz. DYN_MAGIC in a.out.h) so they stay together. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 11:26 ` [9fans] Pegasus 2.6 is released Charles Forsyth @ 2009-02-01 11:56 ` lucio 2009-02-01 13:02 ` erik quanstrom 2009-02-02 17:38 ` John Barham 1 sibling, 1 reply; 51+ messages in thread From: lucio @ 2009-02-01 11:56 UTC (permalink / raw) To: 9fans > well, i say "modules", but of course the language pre-dates > them. people pretend. it uses import/export tables with type signatures. > those are stashed in the a.out (viz. DYN_MAGIC in a.out.h) > so they stay together. It's not what the OP suggested. Nor are Nemo's reservation valid. We're talking about loading source modules into an interpreter. This means that different modules may be loaded, sometimes even by the same instruction and that libraries are not terribly significant unless the invoker gets the sequence wrong, which is a programming error. The remaining reservation is security, can somebody replace a module with a Trojan horse? In Plan 9 the risk is much smaller, I dare not say non-existent. Recent instances of the Korn shell have this feature. Bolsky and Korn describe these features in some details in "The New Korn Shell", 1995. ++L ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 11:56 ` lucio @ 2009-02-01 13:02 ` erik quanstrom 0 siblings, 0 replies; 51+ messages in thread From: erik quanstrom @ 2009-02-01 13:02 UTC (permalink / raw) To: lucio, 9fans On Sun Feb 1 06:57:13 EST 2009, lucio@proxima.alt.za wrote: > > well, i say "modules", but of course the language pre-dates > > them. people pretend. it uses import/export tables with type signatures. > > those are stashed in the a.out (viz. DYN_MAGIC in a.out.h) > > so they stay together. > > It's not what the OP suggested. Nor are Nemo's reservation valid. > We're talking about loading source modules into an interpreter. This > means that different modules may be loaded, sometimes even by the same > instruction and that libraries are not terribly significant unless the > invoker gets the sequence wrong, which is a programming error. not true. this is the original quote. > Dynamic loading allows scripting languages to load arbitrary binary > extensions at run-time. Without dynamic loading in Plan 9 you need to - erik ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-01 11:26 ` [9fans] Pegasus 2.6 is released Charles Forsyth 2009-02-01 11:56 ` lucio @ 2009-02-02 17:38 ` John Barham 2009-02-02 17:48 ` ron minnich 1 sibling, 1 reply; 51+ messages in thread From: John Barham @ 2009-02-02 17:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, forsyth > using a variant of something we developed and then > re-developed for Inferno, you can dynamically load > C modules at run time, and unusually, with type checking, > with support in the compilers and loaders. Is the code to do this available for public consumption? ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released 2009-02-02 17:38 ` John Barham @ 2009-02-02 17:48 ` ron minnich 0 siblings, 0 replies; 51+ messages in thread From: ron minnich @ 2009-02-02 17:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Feb 2, 2009 at 9:38 AM, John Barham <jbarham@gmail.com> wrote: >> using a variant of something we developed and then >> re-developed for Inferno, you can dynamically load >> C modules at run time, and unusually, with type checking, >> with support in the compilers and loaders. > > Is the code to do this available for public consumption? > > I think we're going in circles again. IIRC my discussion of dynload for python should point at what Charles et. al. enabled and what I subsequently used to do dynload for python, which is usable in general, esp. if your code is type-safe (unlike Python). ron ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [9fans] Pegasus 2.6 is released
@ 2009-02-01 4:50 Kenji Arisawa
0 siblings, 0 replies; 51+ messages in thread
From: Kenji Arisawa @ 2009-02-01 4:50 UTC (permalink / raw)
To: Fans Bell Labs of the OS Plan 9 from
Sorry,
http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/
Kenji Arisawa
On 2009/02/01, at 13:41, lucio@proxima.alt.za wrote:
>> Pegasus 2.6 is released with new WebDAV script written in Lua.
>> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more
>> details.
>
> We need a little bit more than "plan9" in the host name :-)
>
> ++L
^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2009-02-03 17:01 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-02-01 4:29 [9fans] Pegasus 2.6 is released Kenji Arisawa 2009-02-01 4:41 ` lucio 2009-02-01 4:47 ` Kenji Arisawa 2009-02-01 4:43 ` John Barham 2009-02-01 4:50 ` andrey mirtchovski 2009-02-01 5:47 ` John Barham 2009-02-01 6:44 ` erik quanstrom 2009-02-01 7:27 ` John Barham 2009-02-01 11:12 ` Francisco J Ballesteros 2009-02-01 12:56 ` erik quanstrom 2009-02-02 19:25 ` sqweek 2009-02-02 19:44 ` erik quanstrom 2009-02-02 19:49 ` Roman V. Shaposhnik 2009-02-02 21:22 ` John Barham 2009-02-02 21:27 ` erik quanstrom 2009-02-02 21:32 ` David Leimbach 2009-02-02 22:11 ` Roman V. Shaposhnik 2009-02-02 22:17 ` erik quanstrom 2009-02-02 22:30 ` Anthony Sorace 2009-02-02 22:44 ` erik quanstrom 2009-02-02 22:57 ` Anthony Sorace 2009-02-02 23:04 ` Bruce Ellis 2009-02-03 4:26 ` lucio 2009-02-03 4:43 ` Bruce Ellis 2009-02-03 6:38 ` ron minnich 2009-02-02 23:18 ` David Leimbach 2009-02-02 22:12 ` ron minnich 2009-02-02 22:14 ` erik quanstrom 2009-02-02 22:32 ` ron minnich 2009-02-02 22:34 ` erik quanstrom 2009-02-02 22:18 ` Roman V. Shaposhnik 2009-02-02 22:22 ` Francisco J Ballesteros 2009-02-02 22:30 ` Roman V. Shaposhnik 2009-02-03 10:55 ` Richard Miller 2009-02-03 16:03 ` ron minnich 2009-02-03 16:07 ` erik quanstrom 2009-02-03 16:48 ` ron minnich 2009-02-03 17:01 ` erik quanstrom 2009-02-02 22:07 ` Roman V. Shaposhnik 2009-02-01 7:31 ` [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released) lucio 2009-02-01 17:26 ` ron minnich 2009-02-01 18:42 ` lucio 2009-02-01 20:14 ` ron minnich 2009-02-01 18:04 ` Dave Eckhardt 2009-02-01 18:39 ` lucio 2009-02-01 11:26 ` [9fans] Pegasus 2.6 is released Charles Forsyth 2009-02-01 11:56 ` lucio 2009-02-01 13:02 ` erik quanstrom 2009-02-02 17:38 ` John Barham 2009-02-02 17:48 ` ron minnich 2009-02-01 4:50 Kenji Arisawa
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).