Having read all of this thread to date, I'll state a solution which should be
elegant and which I'm not sure has been stated yet.
I propose that the concept of current working directory in Perl be a
completely internal, virtual concept, and each Perl thread has its own current
working
All this discussion about file paths, particularly about current working
directory, has inspired me to raise another idea for how this could be done,
which may be a little more abstract or different than you're used to, but may
also be an elegant solution.
My proposal draws inspiration from a
I think this is a much more flexible system than those suggested so far.
It seems to me that this approach
- lets the OS and the implementation deal with pathways that are valid
(taking into account locale and OS constraints).
- defines only that part of the location/directory tree/file system
On Wed, Aug 19, 2009 at 2:35 AM, Darren Duncan dar...@darrenduncan.netwrote:
Having read all of this thread to date, I'll state a solution which should
be elegant and which I'm not sure has been stated yet.
I think that's basically what we were suggesting above, except:
(If Perl really
Very interesting read, that opens a whole new can of worms. How should we
behave when we actually read file names from the filesystem.
As for the path literal the newest revision of S32-setting-library should make
most people happy as the default is OS independent and abstract. More
strictness
On Wed, 19 Aug 2009, Darren Duncan wrote:
My proposal is to have all filesystem paths as seen within Perl being
relative paths, and that there are multiple filesystem roots which can be
referred to by name and each relative path is explicitly relative to a named
root; each of these named
On Wed Apr 08 14:59:19 2009, moritz wrote:
23:55 @moritz_ rakudo: my @a = 1..4; say @a[1..*].perl
23:56 p6eval rakudo 6b9755: OUTPUT«[2, 3, 4, undef]»
It should just be [2, 3, 4].
Since the discussion came up on #perl6 if this is really the expected
behaviour, S09 says:
As the end-point
On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT
perl6-bugs-follo...@perl.org wrote:
Since the discussion came up on #perl6 if this is really the expected
behaviour, S09 says:
As the end-point of a range, a lone whatever means to the maximum
specified index (if fixed indices were
On Wed, Aug 19, 2009 at 5:37 AM, Jan Ingvoldstadfrett...@gmail.com wrote:
On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT
perl6-bugs-follo...@perl.org wrote:
Since the discussion came up on #perl6 if this is really the expected
behaviour, S09 says:
As the end-point of a range, a lone
David Green david.gr...@telus.net wrote:
Maybe setting $*CWD just calls chdir() under the hood? Same implementation,
brand new shiny Perl-style interface!
I don't think that's a good idea. Suppose you have code like this:
$*CWD = '/some/absolute/path';
$*CWD = '../relative/path';
my
Moritz wrote:
However it seems we have to pay a price: each act of rendering a Pod
file actually means executing the program that's being documented (at
least the BEGIN blocks and other stuff that happens at compile time),
with all the security risks implied. So we'll need a *very* good
Raiph commented:
Couldn't the pod processing be encapsulated, perhaps in PGE/NQP, so
that it could be reused in a different Parrot language, provided that
said language supports declarators and comments, or even just comments
(if one downgrades the impact of encountering an attached comment
Jonathan Dataweaver Lang enquired:
Will ther be any ambiguity between Pod and wraparound operators that
begin with =?
No. Lines that start with an '=' that is *immediately* followed by an
identifier are always Pod. If there's a space after the '=' it's always
an assignment. You could *create*
Could we also get =numbered and =term directives that are
equivalent to =item :numbered and =item :term, respectively, for
use with abbreviated blocks? E.g.:
=numbered First Item
=numbered Second Item
=numbered Third Item
That's just:
=item # First Item
=item # Second
On Wed, Aug 19, 2009 at 11:54 AM, Damian Conwaydam...@conway.org wrote:
Moritz wrote:
However it seems we have to pay a price: each act of rendering a Pod
file actually means executing the program that's being documented (at
least the BEGIN blocks and other stuff that happens at compile
On Wed, Aug 19, 2009 at 11:03, Kyle Hasselbacherkyl...@gmail.com wrote:
Perl 5 programmers are sometimes surprised to find that 'perl -c
strange.pl' can execute code. Imagine their surprise to find that
'perl6doc' does too.
this is why it's spelled 'perl6 --doc', which should give you some
Kyle suggested:
Pod itself is a DSL.
Sure. But to allow arbitrary processing and rendering of Pod, a DSL
isn't enough.
If we're committed to giving guns to books, can we default to having
the safety on? Can it be so that 'perl6doc foo.pl' does not execute
any code without an option to allow
Damian Conway wrote:
When using the code block alias, are the outermost curly braces
considered to be part of the ambient code?
Yes. All ambient code is actual code.
OK. Let me propose an alternative (which I expect will be immediately
shot down):
Allow '=begin alias', '=end alias', and
Jonathan Dataweaver Lang proposed:
OK. Let me propose an alternative (which I expect will be immediately
shot down):
BANG!
;-)
Allow '=begin alias', '=end alias', and '=for alias' as special cases:
the Perl parser makes an exception for them and doesn't treat them as
the start or end of
On 2009-Aug-19, at 5:00 am, Troels Liebe Bentsen wrote:
My idea of working with file names would be that we default to
locale or
filesystem settings, but give the options of working with paths/file
names as
binary or a specific encoding.
As mentioned in the old thread, encoding is only
FWIW, the current proposal for aliasing blocks of ambient text is
functional; it just feels a bit kludgey, and I'm a bit bothered by the
fact that you can't alias any ambient text other than a code block.
On Wed, Aug 19, 2009 at 11:29 AM, Damian Conwaydam...@conway.org wrote:
Jonathan Dataweaver
Timothy, thanks for your feedback.
My proposal was never about the syntax, which I stated at the end, but rather my
syntax was just illustrative. I actually meant for p{} or whatever syntax to be
used, but I didn't recall those details and was keeping it simple. And the use
of a %DOI hash
On 2009-Aug-19, at 8:07 am, Jon Lang wrote:
On Wed, Aug 19, 2009 at 5:37 AM, Jan Ingvoldstadfrett...@gmail.com
wrote:
On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT perl6-bugs-follo...@perl.org
wrote:
It doesn't mention how the postcifcumfix:[ ] is supposed to
introspect
those to find
Richard Hainsworth wrote:
I think this is a much more flexible system than those suggested so far.
It seems to me that this approach
- lets the OS and the implementation deal with pathways that are valid
(taking into account locale and OS constraints).
- defines only that part of the
Mark J. Reed wrote:
On Wed, Aug 19, 2009 at 2:35 AM, Darren Duncan dar...@darrenduncan.netwrote:
(If Perl really must have the ability to change the non-virtual current
working directory, such as because its going to spawn another non-Perl
process, then this should use some separate mechanism
David Green wrote:
Jon Lang wrote:
Given that it's relatively easy to say 1..^*, I wouldn't mind
standardizing this so that '*' always refers to the element just past
the last one, at least when dealing with the standard index.
I like the DWIMmery, but the more I think about it, for such a
Darren Duncan wrote:
The named filesystem roots can be defined or altered at runtime by Perl
code, and each one is defined within the context of another.
I should clarify my intention here, which is that each DOI is mapped behind the
scenes by Perl to a standalone absolute filesystem url, and
'home' should be spelled '~'.
--
Jonathan Dataweaver Lang
Jon Lang wrote:
'home' should be spelled '~'.
Yes, of course. And conceptually a DOI can be any string at all. Logically
we'd probably have non-alpha names for many of the common/standard ones. --
Darren Duncan
On 2009-Aug-19, at 2:08 am, Darren Duncan wrote:
%DOI{'mycwd'} = %DOI{'fscwd'};
%DOI{'mycwd'} ~= 'subdir';
# later
my $fh = IO.open( 'mycwd/myfile.txt' );
For ease of use, we can still have vars like $*CWD, which might be
an alias for a doi with a specific name.
I've been thinking of
Author: wayland
Date: 2009-08-20 00:04:27 +0200 (Thu, 20 Aug 2009)
New Revision: 28036
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S16] Documented $*CWD which was mentioned once in S28
[S32] Changed Path to have Buf instead of Str, and an
On 2009-Aug-18, at 7:20 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Some ways in which different paths can be considered equivalent:
Spelling: ... Simplification: ... Resolution: ... Content-wise: ...
Ok, my next commit will have canonpath (stolen directly from p5's
I don't think $file1.name == $file2.name should talk to the FS,
because I think File#name t+r whatever) should return a plain Str.
Having magical FilePathName objects is handy, but sometimes you want
to get the filename as a dumb string to do stringish things without
having to worry about the
I think the too much magic is in automatically creating the
appropriate new method with that signature. I idea is to get the
standard behavior, which is to define a method that's signature is used
for the instantiation.
Currently, I believe you have to define at least new and BUILD, not
Em Qua, 2009-08-19 às 15:37 -0700, Kevan Benson escreveu:
Should there not be a way to define object constructors with custom
signatures that can be usefully invoked like a normal constructor?
What's the problem with
method new(Str $timestamp) {
self.SUPER::new(ts =
On 2009-Aug-19, at 4:37 pm, Kevan Benson wrote:
I'm aware there's a default constructor that allows named parameters
to be set, but I think the usefulness of allowing specific
constructors that take defined parameters and initialize the object
as needed should not be overlooked. E.g.
On Wed, 19 Aug 2009, Mark J. Reed wrote:
I don't think $file1.name == $file2.name should talk to the FS,
because I think File#name t+r whatever) should return a plain Str.
Having magical FilePathName objects is handy, but sometimes you want
to get the filename as a dumb string to do stringish
I should've mentioned, though, we're currently using the smartmatch
operator for this, so I'm thinking maybe I'll just stick with that.
:)
-
| Name: Tim Nelson | Because the Creator is,|
|
Good comments, David.
David Green wrote:
snip
So the set of default standard dirs would just be a hash of IO objects:
$IO::DOI{home}, $IO::DOI{docs}, etc. Actually, different OS's would
provide different sets of standard named dirs, and you should be able to
import them:
# Assume I'm
On behalf of the Rakudo development team, I'm pleased to announce
the August 2009 development release of Rakudo Perl #20 PDX.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1].
The tarball for the August 2009 release is available from
http://github.com/rakudo/rakudo/downloads
Author: wayland
Date: 2009-08-20 07:12:22 +0200 (Thu, 20 Aug 2009)
New Revision: 28040
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S32/IO] and [S16] Changes include:
* Removed spurious references to Array of, now that pmichaud++ has explained
41 matches
Mail list logo
