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
"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
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 t
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
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
Juerd <[EMAIL PROTECTED]> writes:
> Jonadab the Unsightly One skribis 2004-09-17 10:46 (-0400):
>> * They are of critical importance on Apache-based webservers.
>
> They are not. See mod_mime_magic.
Magic, as far as I know, only works for filetypes that have known byte
sequences.
>> * They ins
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
Jonadab the Unsightly One skribis 2004-09-17 10:46 (-0400):
> * They are of critical importance on Apache-based webservers.
They are not. See mod_mime_magic.
> * They instruct command-line tab completion for some shells. This
>IMO is a biggie, and would be even bigger if more shells were
>
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 import
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
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
Thomas Seiler skribis 2004-09-07 20:23 (+0200):
> I touhght that it be nice to let module writers somehow associate their
> module with a file extention.
Most worlds don't use file extensions, except for humans. In the Windows
world, file extensions do matter, because it decides which program to
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 prep
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 tha
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.
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 whatev
[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
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
[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 mis
(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
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
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 minim
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
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 m
[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
On 9/5/04 8:31 PM, Luke Palmer wrote:
> 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 whatev
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 platform
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 pac
On Sat, 2004-09-04 at 18:44, John Siracusa wrote:
Without commenting on the issue of single-file bundling...
> 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 it
29 matches
Mail list logo
