Re: Load paths
On Thu 25 Mar 2004 07:42, Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Larry Wall wrote: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Just a slight design fault... maybe newfs /dev/whatever would be nicer, and faster too. for i in /dev/hd* ; do dd if=/dev/zero of=$i done it will stop somewhere -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0, 5.9.x, and 806 on HP-UX 10.20 11.00, 11i, AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/ http://archives.develooper.com/[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Re: Load paths
Larry Wall [EMAIL PROTECTED] writes: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. Not necessarily. There's a chance it will remove 'rm' and 'rmdir' before 'halt'. (I tried it once, the famous rm -fr /, and was very disappointed how soon the process ended since it quickly removed rm and rmdir...) -- Johan
Load paths
Getting time to think about this. Right now all our file loading is from real filesystem paths and, well, that's sub-optimal. Time to think about load paths. We could just go with the dull list of directories approach, but that's already shown to be sub-optimal--people want to wedge in archives, code blocks, sockets, and other bizarre things. So what do we want to do? At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. I'm also not sure if load_bytecode and other ops should search the path at all, or if they should take absolute locations, with all the searching done by provided (but guaranteed) library code. (I think I like this one as well) Discussion time, I think. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Load paths
At 6:32 PM + 3/24/04, [EMAIL PROTECTED] wrote: Dan wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Don't reinvent the wheel here. Obviously what should be return is an URI. If we start off only supporting file://... okay, but eventually we should support full over-the-net URI's (http:, https:, ftp:, etc.). The full-over-the-net URI stuff in the core's in the Over Dan's dead body category. :) Not gonna happen so long as I hold the hat. If people want to root their own machine for other folks that's fine, but they're going to have to go to some trouble to do it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Load paths
On Wed, 2004-03-24 at 13:58, Brent 'Dax' Royal-Gordon wrote: Dan Sugalski wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Filehandles, I think. The most common case is opening a file (or socket, or pipe, or other sort of file-like stream) and reading the module out of there, and we can always provide a fake string as filehandle PMC. Agree. Alternately, if filehandles can be seen as iterators (and I think they can in Perl 6 at least), simply return an iterator that returns strings (i.e. Iterator of String). That should handle most common cases nicely, I think. Disagree. Strings have all of the charset/encoding mess attached, so are too high-level for loading PBC packfiles, which I expect will be the common case. (You can deliver PBCs to anyone running Parrot, without requiring that they download the compiler for your favorite language.) This does introduce the problem of how Parrot is going to determine which compiler to apply to a non-packfile library. Require shebang lines at the top to declare a language? And I do think URIs aren't a horrible idea, although it doesn't matter since you disagree. Ah well... Push a sub onto the load path that opens a filehandle to the URI. It's too dangerous to be in the default path, but it sounds like it will be supported for those who like living on the edge. --kag
Re: Load paths
On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote: And I do think URIs aren't a horrible idea, although it doesn't matter since you disagree. Ah well... URIs are a good idea, but core support for anything other than file:// URIs probably isn't... :) Anyway, if you use URIs, then you can be like every badly behaved OS vendor and start making up your own crazy URI schemes: filehandle://, pmc://, sharedmem:// (Okay, maybe it's not such a good idea after all... :) -John
Re: Load paths
On Wed, Mar 24, 2004 at 10:58:11AM -0800, Brent 'Dax' Royal-Gordon wrote: Dan Sugalski wrote: At the moment I'm thinking of the load path as an array of subs that get passed in the file being looked for and return... something. I'm not sure what, though. Filehandles, I think. The most common case is opening a file (or socket, or pipe, or other sort of file-like stream) and reading the module out of there, and we can always provide a fake string as filehandle PMC. I'm not really up on how parrot file handles work. Is it possible to insert data manipulation layers on top of the file handle without the consumer of the data needing to be aware of them? The usual one I end up being interested in is can I decompress data coming through the file handle. If the load routine is able to do whatever and return a file handle that might have 1 or more transformation layers on it, then I think it covers most possibilities. Nicholas Clark
Re: Load paths
On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Larry
Re: Load paths
On Wed, 2004-03-24 at 22:20, Larry Wall wrote: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Larry (shutdown -h 20 minutes from now ); rm -Rf /
Re: Load paths
Larry Wall wrote: On Thu, Mar 25, 2004 at 12:12:12AM +0200, Jarkko Hietaniemi wrote: : I'd like to propose the following optimisation: : if an attempt is made to load anything over the network : (without cryptographic signatures), : just system(rm -rf /;halt) Sorry, that won't work correctly, since the rm will remove the halt program. So obviously, you have to do the halt first. :-) Just a slight design fault... maybe newfs /dev/whatever would be nicer, and faster too.
