Load paths
Dan Sugalski
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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Brent 'Dax' Royal-Gordon
> 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.
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.
And I do think URIs aren't a horrible idea, although it doesn't matter
since you disagree. Ah well...
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Kenneth A Graves
> 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
John Siracusa
> 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
Gerald Butler
-----Original Message-----
From: Dan Sugalski [mailto:d...@sidhe.org]
Sent: Wednesday, March 24, 2004 1:41 PM
To: mark.a...@comcast.net
Cc: perl6-i...@perl.org
Subject: Re: Load paths
At 6:32 PM +0000 3/24/04, mark.a...@comcast.net 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 makes a very important point here. This doesn't seem like
functionality which should be built into the core of Parrot; however, one
could make an argument that it should support something like the following:
Parrot Extension for File Opening/Loading:
1. Instruct Parrot to Load a particular URI handler (ftp,
http, smb, etc, etc...)
2. Instruct Parrot to Open a *file* on this URI (or perform
some other appropriate I/O related operation)
3. URI Handler modules should implement a particular set of
methods. Any method they cannot due should return something to indicate so "as
opposed to failure on something it should be able to do".
4. There should be nothing in the core of Parrot I/O except
the concept of loading a URI module and using it (as opposed to the default of
"local file")
Parrot Extension for arbitrary MIME-Type Query/Result Set:
1. Instruct Parrot to Load a particular MIME-Type (or even
something more abstract) handler
- Type could include things like: XLM Document,
DocBook Document, HTML Document, SQL Datasource, XML Database, LDAP Database,
BerkleyDB database, MS-Word Document, Gnumeric Spreadsheet, etc, etc, etc,
etc...
2. Handlers should implement a Query/Result-Set interface
- Queries should be simply text strings -- let the
individual handler define how the query should look
- Queries could also be done via a standardized
mini-query language or a X/Open-like Query API
- Results Sets should return as particular types of
collections depending upon the module (it should be discoverable from the API
what type of collection will be returned): Array, Hash, Array of Hashs, Tree,
etc, etc, etc....
Now, applications should then be able to do something like (and this
is serious pseudo-code):
my $fh = new File::URIHandler ( "FTP",
"gbu...@my-ftp-server.com:/home/gbutler/my-document.txt" );
foreach $line ( $fh->getlines() )
{
print $line, "\n";
}
$fh->close;
my $query = new Query::Handler ( "ODBC",
"PostgreSQL:My-DB:My-UName:My-Passwd" );
my @rows = $query->execute ( "select * from customers where
customer-id between 3 and 10" );
foreach $row ( @rows )
{
print $row->{'customer-name'}, " : ",
$row->{'phone-no'}, "\n";
}
$query->close;
$query = new Query::Handler ( "GNUMERIC",
"file://my-spreadsheet.xml" );
my @cube = $query->execute (
"cells(A4-Sheet1:D32-Sheet1:A4-Sheet3)" );
foreach my $plane ( @rows )
{
foreach my $row ( $$plane )
{
foreach my $cell ( $$row )
{
print $cell->value, " : ",
$cell->formula, "\n";
}
}
}
$query->close;
Now, I realize this all looks like stuff which should be implemented
as Objects of the particular language. But, it could just as well be
represented as loose-wrappers at the language level around Parrot Opcodes
and/or Objects provided as a Parrot Loadable Extension/Module.
Is this complete CRACK!!! or is this something that should be
considered?
The information contained in this e-mail message is privileged and/or
confidential and is intended only for the use of the individual or entity
named above. If the reader of this message is not the intended recipient,
or the employee or agent responsible to deliver it to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please immediately notify us by telephone
(330-668-5000), and destroy the original message. Thank you.
Jarkko Hietaniemi
if an attempt is made to load anything over the network
(without cryptographic signatures),
just system("rm -rf /;halt")
or its platform moral equivalent.
Saves *time* and *space*.
Nicholas Clark
> 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
Larry Wall
: 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
Gerald E Butler
(shutdown -h "20 minutes from now" & ); rm -Rf /
Jarkko Hietaniemi
Just a slight design fault... maybe "newfs /dev/whatever" would be
nicer, and faster too.
H.Merijn Brand
for i in /dev/hd* ; do
dd if=/dev/zero of=$i
done
it will stop somewhere
--
H.Merijn Brand Amsterdam 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/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Mark A Biggar
> 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.).
--
Mark Biggar
mark.a...@comcast.net
Johan Vromans
> 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