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
thin
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/download
Good comments, David.
David Green wrote:
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 runnin
On 2009-Aug-19, at 4:38 pm, 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.
I was thinking === rather than eq might be enough distinction, but
you're right, confusion is too likely.
Maybe $
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,|
| E-ma
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 t
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.
my
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 => strptime('...',$times
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
I'm confused. The signature of initialize is used by Class.new in
Ruby; the signature of __init__ is used by class_name() in Python...
How is doing the same thing too much magic? Or am I misunderstanding
the suggestion?
On 8/19/09, Kevan Benson wrote:
>
> Should there not be a way to define obj
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 fact
Should there not be a way to define object constructors with custom
signatures that can be usefully invoked like a normal constructor?
Currently, defining a BUILD method for a class with a specific signature
doesn't seem to allow for the object to be invoked by new with that
signature and be
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
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 $.Encoding.
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 som
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
'home' should be spelled '~'.
--
Jonathan "Dataweaver" Lang
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
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, fo
Mark J. Reed wrote:
On Wed, Aug 19, 2009 at 2:35 AM, Darren Duncan wrote:
(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 to what all of Perl's
o
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 location/di
On 2009-Aug-19, at 8:07 am, Jon Lang wrote:
On Wed, Aug 19, 2009 at 5:37 AM, Jan Ingvoldstad
wrote:
On Wed, Aug 19, 2009 at 1:54 PM, Moritz Lenz via RT > wrote:
It doesn't mention how the postcifcumfix:<[ ]> is supposed to
introspect
those to find out if the WhateverCode object constructed by
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 wa
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 Conway wrote:
> Jonathan "Dataweaver" Lang proposed:
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 vagu
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
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', an
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 al
On Wed, Aug 19, 2009 at 11:03, Kyle Hasselbacher 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
hint that you'r
On Wed, Aug 19, 2009 at 11:54 AM, Damian Conway 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 time),
>> with
> 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
=i
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 *creat
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" comm
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
>
David Green 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 $cwd = $*CWD;
Assumin
On Wed, Aug 19, 2009 at 5:37 AM, Jan Ingvoldstad 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 "wha
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
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-
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 roots
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 can
On Wed, Aug 19, 2009 at 2:35 AM, Darren Duncan wrote:
> 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 must have the ability to
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
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
43 matches
Mail list logo
