Re: What Requires Core Support (app packaging)Z
On Sat, 25 Sep 2004, Jonadab the Unsightly One wrote: to @INC, which implies that @INC needs to be able to contain more than just directories on the system-level filesystem -- it needs to be able to contain tied directories that are simulated by modules, or (Unless I've not really understood what you mean) this should not be a major problem since @INC already, i.e. in (recent) Perl5(s) can contain more than just directories, e.g. coderefs. HTH, Michele -- Ask about it in alt.folklore.computers. Somebody over there will know; they know everything or know somebody who does ;-). - Found somewhere in USENET
Re: What Requires Core Support (app packaging)Z
Adam D. Lopresto [EMAIL PROTECTED] writes:
On Sat, 18 Sep 2004, Jonadab the Unsightly One wrote:
The question is whether any of that needs to be core, and I'm
starting to strongly think it doesn't. I was about to say that perl
should only go trying to figure out that the file is an archive if
you pass it an appropriate command-line argument, but then I
realized that argument could well be -MPAR (or such).
If by core you mean language core, and if the module in question
would be in the core distribution, then I can mostly go along with
that (with one caveat, below). And on some platforms the Perl
installer could associate certain extensions (perhaps .par) with
perl -MPAR or whatever so that launching the thing Just Works.
Since most of the point of such a mechanism would be to allow people
who just have Perl installed to automagically run these
programs-in-an-archive that include all the modules they use in their
nice neat package, it would be unfortunate to require something extra
to be installed to make that work. Thus, this module should go in the
core distribution, along with the new and improved CPAN.pm equivalent.
So in one sense I would consider this core functionality, in the
sense that it's something Perl needs to be able to do out of the box,
but I can agree that it doesn't need to be in the _language_ core.
Except that the module will be prepending the contents of the archive
to @INC, which implies that @INC needs to be able to contain more than
just directories on the system-level filesystem -- it needs to be able
to contain tied directories that are simulated by modules, or
something along those lines. The core might have to have some hooks
for that.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: What Requires Core Support (app packaging)Z
On Sat, 18 Sep 2004, Jonadab the Unsightly One wrote: James Mastros [EMAIL PROTECTED] writes: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. I think it would be useful if the directory could also be an archive in certain common and widely-supported formats (gzipped tarball and PKWare ZIP being the most important ones to support IMO; probably should go for bzip2ed tarball also and maybe disk images containing ISO filesystems if a suitably unencumbered extant code library can be found for reading them). The question is whether any of that needs to be core, and I'm starting to strongly think it doesn't. I was about to say that perl should only go trying to figure out that the file is an archive if you pass it an appropriate command-line argument, but then I realized that argument could well be -MPAR (or such). Then the module would have to do some magic to see how it's being called and analyze the parameters, look for archives, etc, but the perl executable itself wouldn't need anything special (which feels a lot nicer, since presumably updating the PAR module installed would be a lot easier than updating perl to support a new archive type). -MPAR could also handle the directory case, removing any special casing whatsoever from perl. -- Adam Lopresto http://cec.wustl.edu/~adam/ Just once, I wish we would encounter an alien menace that wasn't immune to bullets. --The Brigadier, Dr. Who
Re: What Requires Core Support (app packaging)
On Sun 19 Sep, Jonadab the Unsightly One wrote: Archimedes. It doesn't allow them at all, from what I understand. It probably doesn't disallow file extensions [per se], but the dot Could be. I haven't used it personally. The name should be Risc-OS - the Archimedes is one of the computers that run it. Risc-OS has the concept of filetype, but it is not as part of the name, but a separate property of the files. Having said that, In converting from a filename with an extension from another system, a .ext is often converted to a /ext as . is the native directory symbol. Thus in converting between unix style file names and riscos style file names is roughly tr#/.#./# (there are some caveats). Richard (Using Risc-os on an RPC) -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: What Requires Core Support (app packaging)
Juerd [EMAIL PROTECTED] writes:
Most worlds don't use file extensions, except for humans.
You exaggerate their lack of importance. File extensions don't matter
to most operating system *kernels*, but they are nevertheless
important for more than just Windows:
* They are of critical importance on Apache-based webservers.
* They instruct command-line tab completion for some shells. This
IMO is a biggie, and would be even bigger if more shells were
smarter. (eshell has a leg up here.)
* They matter somewhat to many *nix applications, such as Emacs and
Gimp. When I say matter somewhat, I mean that the app
understands what the extension means, and so in the absense of the
extension you have to give the app additional information to
compensate.
* They matter to most GUI file managers in the *nix world. I
personally don't use GUI file managers, but some people do.
* They matter somewhat in the VMS world, though not as much as under
Windows I think.
* They matter in the OS/2 world, if anyone is still using that. Also
DOS, with the same caveat.
* On Mac OS X the extension matters for files that don't have
filetype/creator codes attached to them yet (unless the file is
coming from a source that supplies content-type, such as from a web
server or as an email attachment, in which case the content-type
instructs the addition of filetype/creator codes).
The only OS I know of where file extensions are *totally* not used is
Archimedes. It doesn't allow them at all, from what I understand.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: What Requires Core Support (app packaging)
On Fri, Sep 17, 2004 at 10:46:36AM -0400, Jonadab the Unsightly One wrote: Juerd [EMAIL PROTECTED] writes: Most worlds don't use file extensions, except for humans. You exaggerate their lack of importance. File extensions don't matter to most operating system *kernels*, but they are nevertheless important for more than just Windows: * They are of critical importance on Apache-based webservers. * They instruct command-line tab completion for some shells. This IMO is a biggie, and would be even bigger if more shells were smarter. (eshell has a leg up here.) * They matter somewhat to many *nix applications, such as Emacs and Gimp. When I say matter somewhat, I mean that the app understands what the extension means, and so in the absense of the extension you have to give the app additional information to compensate. make is an important example here * They matter to most GUI file managers in the *nix world. I personally don't use GUI file managers, but some people do. * They matter somewhat in the VMS world, though not as much as under Windows I think. * They matter in the OS/2 world, if anyone is still using that. Also DOS, with the same caveat. * On Mac OS X the extension matters for files that don't have filetype/creator codes attached to them yet (unless the file is coming from a source that supplies content-type, such as from a web server or as an email attachment, in which case the content-type instructs the addition of filetype/creator codes). The only OS I know of where file extensions are *totally* not used is Archimedes. It doesn't allow them at all, from what I understand. --
Re: What Requires Core Support (app packaging)
Nicholas Clark wrote: On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) Er, right -- I'd meant to say that there, but I must have lost it when I decided my verbiage was horrible and rewrote it. (There's a reason I don't post often.) Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The and as you say all this really isn't about perl 6 the language. Exactly -- most of this sort of thing is about perl's standard library, which I think is a discussion for much, much later, and a discussion (one that, for the most part, is finished) for perl6-language (the part of the list that should be renamed to parrot). -=- James Mastros
Re: What Requires Core Support (app packaging)
Simon Cozens wrote: For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't trust things which are self-declared scary hackery to be stable, you probably shouldn't be using Perl until Perl 6 comes out. And probably not until then. Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. Look, we're not going to agree on this. Should we just drop the subject? I know I've seen more than I wanted to. Dan
Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (Dan Hursh) writes: Um, on a somewhat unrelated note, having tried to get a department of mine to switch over to perl from csh and REXX of all things, I have co-workers I hope never see this. They may need to write their own operating system if they want to avoid the dodgy software rot entirely. :) -- If you give a man a fire, he'll be warm for a day. If you set a man on fire, he'll be warm for the rest of his life.
Re: What Requires Core Support (app packaging)
John Siracusa wrote: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. We can support this in several ways. We can say that core perl also supports the above if the file is a gzipped tar file, and contains a main.pl (including adding the archive to @*INC). We can ship a script with perl, and have the user use the #! mechinisim to run it, with the actual file being specified to be a #! line, ending with some combination of CR and LF, then a tarball. This is probably a lot more work for perl core, but would be quite nice. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. Parrot supports this well enough that it will be hard for perl6 to mess it up. Parrot, indeed, already supports... 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to bootstrap community implementations. Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The others require standard-library support, but all the major bits are things that should already be in the standard library (because a front-end to C6PAN should come with, and that means extracting some sort of .tar.gz files -- calling out to external utilities doesn't cut it too often). -=- James Mastros PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's and postfix:'th? It's 80s and postfix:th!
Re: What Requires Core Support (app packaging)
On Tue, 7 Sep 2004, James Mastros wrote: PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's Maybe in the 80's is like at the Jones's. Not that I care, mind you. and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. $foo = 3; @array[ $foo'th ];
Re: What Requires Core Support (app packaging)
John Williams skribis 2004-09-07 11:37 (-0600): and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. @array[ $foo'th ]; Maybe what I'm saying now is a really bad idea, because it doesn't make sense, but can't we just have an adverb that changes an integer into an ordinal? 4 :th $foo :th Obviously, the : should be optional for literal integers: 4th 3th Juerd
Re: What Requires Core Support (app packaging)
James Mastros wrote: We can, and I think should, write a one-paragraph documentation, one-screenful implementation of this that's in perl core: As a special case, if the filename argument to perl is a directory, and the directory contains a file named main.pl, then the directory is prepended to @*INC, and main.pl is run. Only [this] requires Cperl support, and that support is very minimal. I Agree. This is much simpler than what i came up during the recent discussion about app packaging: I touhght that it be nice to let module writers somehow associate their module with a file extention. This could also be useful for Modules that change the standart Perl 6 Syntax. The module that contains these macros could associate itself with a extension (e.g. *.klingonpl / *.kpl) In that way, its immediately clear that some macros are at work. Maybe this helps in other cases aswell, where the header is somehow predefined and its not possible to add some shebang magic or a use- clause to indicate some special treatement... Would such a feature be useful at all ? Thomas Seiler
Re: What Requires Core Support (app packaging)
On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote: 4. The single-file, platform dependent, machine language executable (realexe). This is a plain old executable, that does not particularly indicate it was generated by a scripting language. It requires no odd handing vs a normal executable for the target platform, because it /is/ a normal executable for the target platform. It may be staticly or dynamicly linked to the necessary libraries. Which parrot can already do. (Or at least could, but I don't think that anyone's been checking on it recently) This work was completed as a result of a TPF grant that Daniel Grunblatt received last year: http://www.perlfoundation.org/gc/grants/2003_q2.html Mostly, though, they require fairly minimal support from the core. Only 1 requires Cperl support, and that support is very minimal. The and as you say all this really isn't about perl 6 the language. Nicholas Clark
Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (John Siracusa) writes: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It *could* do this, but loading bytecode in Perl 5 is slower than loading and compiling source, so there's not really much point. What's so magic about bytecode, anyway? Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. In what way? How have you managed to break it? -- I would have more respect for Ruby if its docs were not in ALL YOUR BASE format. - Dennis Taylor
Re: What Requires Core Support (app packaging)
On 9/6/04 3:48 AM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It *could* do this, but loading bytecode in Perl 5 is slower than loading and compiling source, so there's not really much point. What's so magic about bytecode, anyway? Don't you think it's preferable to temp-expanding and compiling at runtime? I'd rather not have to write files to disk just to launch... Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. In what way? How have you managed to break it? The slides about the internals do start with Here begins the scary part and claim that PAR invokes four areas of Perl arcana, some of which were, or still are, undocumented. As for breaking it, I suppose all I'd have to do is try to use it on a platform that has perl but is not supported by PAR. Don't get me wrong, PAR is a great, impressive collection of code. But part of the reason that it's so impressive is that it's not easy to get Perl 5 to do this type of thing without a lot of clever tricks. I'd like it if this kind of thing doesn't have to be quite so clever in the Perl 6 age :) -John
Re: What Requires Core Support (app packaging)
On Sun, Sep 05, 2004 at 10:40:24AM -0400, John Siracusa wrote: 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. (Well, I suppose it could try to #! boostrap as well, but then you'd have to inline a bytecode interpreter or find some way to feed the bytecode to the right part of perl 6, which seems like it also leads to some sort of core support.) There is core support for this in perl5. use ByteLoader puts a source filter module in place that reads the rest of the file in as perl5 bytecode. But as Simon says in another message, this bytecode is bigger and slower to load than perl source. needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. Or in perl 5. The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do this better. The perl 6 core needs to be designed with this type of stuff in mind. Parrot is being designed with this stuff in mind. This is far more a parrot issue. Parrot has directly serialisable bytecode, and can run bytecode from disk. I think packaging has the same characteristics. But unlike CPAN, packaging does require some minimum amount of core support to meet what I consider to be the minimum standard of elegance. I think that this is true. I'm not sure what the minimal list is, and I suspect that really it's more a parrot issue than a perl 6 syntax issue. Nicholas Clark
Re: What Requires Core Support (app packaging)
On 9/6/04 12:21 PM, Nicholas Clark wrote: I think packaging has the same characteristics. But unlike CPAN, packaging does require some minimum amount of core support to meet what I consider to be the minimum standard of elegance. I think that this is true. I'm not sure what the minimal list is, and I suspect that really it's more a parrot issue than a perl 6 syntax issue. Hm, well, features of the perl6 executable itself aren't really fodder for the parrot lists (are they?)...although I forget where they've been discussed in the past. Anyway, the long-suffering internals guys are still hashing out whether or not to have a STRING type or use PMCs for that, yada yada, so I think this is an issue to save for a bit later on... :) -John
Re: What Requires Core Support (app packaging)
On Mon, Sep 06, 2004 at 12:28:16PM -0400, John Siracusa wrote: Hm, well, features of the perl6 executable itself aren't really fodder for the parrot lists (are they?)...although I forget where they've been discussed in the past. Anyway, the long-suffering internals guys are still hashing out whether or not to have a STRING type or use PMCs for that, yada yada, so I think this is an issue to save for a bit later on... :) I think that that problem comes down to a lack of Rule 1 for Dan. Nicholas Clark
Re: What Requires Core Support (app packaging)
(not on the list, please Cc me in replies.) On Sun, Sep 05, 2004 at 08:49:20PM -0400, John Siracusa wrote: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It's closest to item #2 in my feature list, but it's something very different than compiling down to bytecode. Minor nitpick: pp -f Bytecode does precompile to bytecode. But as we know, Perl5 bytecode is platform-dependent, slow, and somewhat fragile. Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. Well, PAR largely depends on the @INC-hook mechanism to do what it does, although in the pure exe-only mode it could also do without that, depending on extracting to temp and adding the temp dir to @INC instead. I suspect the PAR author would love to list the things he needs in the perl 6 core to implement PAR6 in a reliable, straight-forward manner. Well, having a core inflate() (or maybe the whole Archive::Zip API) would be a very good start. Compiling Zlib into core is perhaps a Parrot problem instead of a Perl6 one. Co-existence of multiple versions of loaded modules on the same machine. This is probably already in Perl6. Core support for reading (and seeking) HTTP/FTP sources would be pretty cool, but not required. Thanks, /Autrijus/ pgpRle6yihF0l.pgp Description: PGP signature
Re: What Requires Core Support (app packaging)
[EMAIL PROTECTED] (John Siracusa) writes: Don't you think it's preferable to temp-expanding and compiling at runtime? Not if it's slower, no. The choice was made not to go with bytecode because of a deficiency in Perl. If that deficiency wasn't there, then sure, go with bytecode. But you're missing the point, so I'll say it again: IT DOESN'T MATTER. The slides about the internals do start with Here begins the scary part For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't trust things which are self-declared scary hackery to be stable, you probably shouldn't be using Perl until Perl 6 comes out. And probably not until then. Look, we're not going to agree on this. Should we just drop the subject? -- Though a program be but three lines long, someday it will have to be maintained. -- The Tao of Programming
Re: What Requires Core Support (app packaging)
On 9/4/04 11:42 PM, chromatic wrote: On Sat, 2004-09-04 at 18:44, John Siracusa wrote: To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. I think the specially structured dir of files and its single-file packaged (and precompiled) variants are important enough to be standardized, or core, or whatever you want to call it. ... you can find almost anyone arguing this point for almost any feature. I'm inclined to distrust it. Yes, this is a hard aspect to get consensus on, but that doesn't mean it's not important. Totally avoiding this kind of question is not the solution, IMO. That said... I just don't see a way to achieve this level of transparency and elegance without core support. That's a much better gauge for whether a feature should go into the core. I don't know how this particular case fares with that metric, but it's one of the right questions to ask. I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. On 9/5/04 3:02 AM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: there's an official way, you'll certainly see less wheel reinvention than in Perl 5. This is a good thing. That is only true if you accept the fundamentalist principle that one should never reinvent wheels. If that were true, then we wouldn't be working on Perl 6. Perl 6 will do many things that Perl 5 can't, so its more aptly described as an upgrade :) The standardized class, method, submethod, and so on in Perl 6 will be an absolute breath of fresh air. Don't worry; people will soon create their own helper modules anyway. There'll still be More Than One Way To Do It, like it or not. Maybe, but I'll wager there'll be a lot less variety since the standard system is more than capable enough for most purposes. Even if it's tweaked a little, if you know the standard system then you have a huge head start on whatever a particular program is doing. Wholesale reinvention will likely be confined to Damians. Furthermore, every non-core implementation will necessarily be uglier than the built-in system. Again, this is dogma. If the core specifies every minute detail of what you can do with the language, it's going to be far uglier than any module or implementation you can come up with. It's not specifying what you can do, it's providing one (good) way to do it. This brings up (again) the issue of core vs standard lib and all that. Some features are naturally library functions, but some things either can't or shouldn't be done without core support. The packaging issue spans the whole range: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. (Well, I suppose it could try to #! boostrap as well, but then you'd have to inline a bytecode interpreter or find some way to feed the bytecode to the right part of perl 6, which seems like it also leads to some sort of core support.) The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do this better. The perl 6 core needs to be designed with this type of stuff in mind. Regardless of whether it's core or stdlib, I think Java benefited greatly from having the JAR format. Perl 6 should one-up Java here like it does everywhere else :) Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to
Re: What Requires Core Support (app packaging)
John Siracusa writes: I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. So have you, um, seen PAR? Luke
