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 archive
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
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
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
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
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
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
[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
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
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 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
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
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
[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/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
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
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
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
(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
[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
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
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
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 its
24 matches
Mail list logo
