Re: $*CWD and chdir()
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 directory, and that Perl exclusively talks to the real file-system in terms of absolute paths. This means that the real file-system's chdir() is never invoked during the execution of a Perl program, and a Perl process' external concept of current working directory is static, not changing during its execution, as if the concept didn't actually exist. When a Perl process starts up, its internal $*CWD starts out identical to the external/system one, but any changes to $*CWD then move them out of sync. When a new Perl thread starts, its own separate $*CWD starts out identical to that of the thread that spawned it, but otherwise evolves separately. Perl can have a chdir(), but it only affects the virtual concept, same as updates to $*CWD do. All relative or not-fully-qualified paths used with IO operations in Perl are interpreted relative to the current thread's $*CWD, and then their action takes place external to Perl in terms of absolute/fully-qualified paths in the file system. If these suggestions are followed, we should have a solution that is all of: simple, thread-safe, portable, no surprises, etc. (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 own IO uses, and any such change would have no effect on any Perl $*CWD.) -- Darren Duncan
directories of interest, a multiplicity alternative to CWD
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 design aspect of my Muldis D language in
regards to how fully-qualified names for DBMS entities are written out,
including the names of types, routines, variables, and so on, which is in turn
inspired by how SQL DBMSs tend to name things, where you qualify them with a
database name plus schema name plus package name if applicable and so on; for a
DBMS, the hierarchy of namespaces is like a filesystem, since everything
relevant lives in there, and so schema names etc are like directories and
variables or routines etc are like files, or alternately they are like
namespaces in a programming language defined by packages or classes etc for
their routines or types or variables. The Muldis D concept is that there are
some primary namespaces whose definition is relative to where they are invoked;
and invoking entities by way of these means I refer to this entity in terms of
a particular context of mine, such as in my package ($pkg.foo) or in my
schema ($sdp.foo or $dep.bar.foo etc).
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 is called a directory of interest or doi.
The named filesystem roots can be defined or altered at runtime by Perl code,
and each one is defined within the context of another.
Obviously at least one must be system-defined by Perl so to be able to genesis
the others, and that one corresponds to the actual filesystem root (or some
other dir if the Perl process is operating in a jail).
When you write a path, then rather than rooting it with /, you instead root it
with doi/.
Examples of doi can be:
fsroot - the root of the real file system, analogous to /
fscwd - the dir that was the fs CWD when Perl started up
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
So to refer to common things on a Unix system like the fully-qualified ways, you
can write paths like:
fsroot/home/me/myfile
fsroot/usr/bin/perl
fsroot
For something analogous to traditional CWD sans modifications:
fscwd/mynewfile.txt
fscwd/lib/doit.pl
To define a new doi at runtime, something like:
%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.
Note, please ignore my specific syntax for denoting Path objects. I defer to
other discussions and synopsis for those details, and mainly what I'm trying to
put across here is concepts.
My main point here is that we effectively can have multiple CWD in the same Perl
thread, and it shouldn't be too much trouble to make this work well.
-- Darren Duncan
Re: directories of interest, a multiplicity alternative to CWD
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
which perl6 programs operate, rather than having to understand the whole
environment in which software could run
- delegates to a module if perl6 is to be used to manage a specific
environment/OS
- offers more future proofing and portability than constraining what can
or cannot be in a pathname.
- allows users to configure via Policy.pm standard pathnames to
something non-standard for development and testing, leaving the software
itself unchanged.
Darren Duncan wrote:
snip
When you write a path, then rather than rooting it with /, you
instead root it with doi/.
Examples of doi can be:
fsroot - the root of the real file system, analogous to /
fscwd - the dir that was the fs CWD when Perl started up
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
To define a new doi at runtime, something like:
%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.
Note, please ignore my specific syntax for denoting Path objects. I
defer to other discussions and synopsis for those details, and mainly
what I'm trying to put across here is concepts.
My main point here is that we effectively can have multiple CWD in the
same Perl thread, and it shouldn't be too much trouble to make this
work well.
-- Darren Duncan
Re: $*CWD and chdir()
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 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 own IO uses, and any such change would have no effect on any Perl $*CWD.) I would propose that whenever Perl spawns a non-Perl process, that process automatically executes a chdir() to the spawning thread's value of $*CWD. But this should be done without changing the parent process's external/OS working directory. In UNIX that's easy - fork(), then chdir(), then exec() - but in Windows it may be trickier. -- Mark J. Reed markjr...@gmail.com
Re: Last IO discussion
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 be set with use flags or more verbose syntax, this should also
make it easier to make portable programmes in Perl 6. So far I'm quite happy
with the current result, way to go people :)
But what should we do when reading path's from the filesystem is still
a problem.
We can go the old Perl 5 way of treating filenames as binary by default and
then trying to convert it based on local encoding settings.
But this just mean any sane program will have to do an explicit, decoding to a
Unicode path or string.
Like we do in Perl 5:
my $file = readdir $dir;
$decoded_file = eval { decode(utf8, $file, Encode::FB_CROAK); };
if($@) {
# Try something else as this was clearly not utf8.
} else {
$file = $decoded_file;
}
But then again is this reasonable, on both Windows and MacOS X we know exactly
what we get as the filesystem will tell us. Even FAT has an encoding attribute
telling us what encoding the filesystem is in. And given that the OS actually
refuses to write files that are not valid, it would be a safe bet that a Path
can be decoded with that encoding.
So the problem of knowing encoding really only exists on Unix/Linux. This is
mainly because As POSIX does not care about encoding and most filesystems seem
to follow. But who knows if future filesystems will still be so lax with input,
the current trend of putting more database features in the filesystem might
also bring some more input validation, and the future we might not have to deal
with the insanity of multiple encodings.
Apparently JFS today has the option of limiting file name encoding.
http://lwn.net/Articles/71472/
Even without a filesystem restriction, on Linux/Unix we have a default encoding
specified in the locale that most software will respect, so when I name a file
ÆØÅ on my Ubuntu box all my programs will show it as such and not give me a
garbled string. So even if we have no guaranty that file names are encoded in
what the locale is set to, it's the best information we have.
One could always argue that even if the filesystem restricts file name input,
one still have the option of ignoring this as one encoded string of bytes will
be valid under the rules of another encoding just with another meaning. But
this file name will be wrong in all other programs, so why should it be correct
or unspecified(as in just a stream of bytes) in Perl 6?
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.
my $file = readdir $dir; # Default to locale settings. fx utf8
This will return a UTF8 encoded Path unless and if this fails, no decoding will
be done and we return a binary Path.
my $file = readdir $dir, :utf8; # Decodes as utf8
my $file = readdir $dir, :bin; # No decoding is done
The whole reason for this is paths and filenames should not be special, it's
just another form of user input, where we should have some sane default so it
does what we expect.
More reading on the topic:
Python 3 problems:
http://bugs.python.org/issue4006
Unicode handling in Linux:
http://hektor.umcs.lublin.pl/~mikosmul/computing/articles/linux-unicode.html
Regards Troels.
On Wed, Aug 19, 2009 at 03:17, Timothy S. Nelsonwayl...@wayland.id.au wrote:
See this link.
http://archive.netbsd.se/?ml=perl6-languagea=2008-11t=9170058
In particular, I thought Tom Christiansen's long message had some
relevant info about filename literals.
:)
-
| Name: Tim Nelson | Because the Creator is, |
| E-mail: wayl...@wayland.id.au | I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++
R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: directories of interest, a multiplicity alternative to CWD
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 is called a directory of interest or doi.
I briefly mentioned a similar idea, but with no theoretical background
:). I would've called them bookmarks instead of doi, though.
For those who shied away from Darren's large theoretical background,
fearing that it would lead to pie-in-the-sky or something, the simple
version of his proposal was to have a magic global hash, and have it work
like:
%*DOIhome = /home/foo;
$path = p{home/Music}; # $path points at /home/foo/Music
I disagree with the syntax, but the idea has merit.
Your idea for making everything a relative path isn't one that
appeal to me. But having a predefined set of bookmarks that could be used is
certainly an interesting idea.
I don't like your syntax, though :). But see below.
fsroot - the root of the real file system, analogous to /
I think we should stick with / as it's well-understood. Unless the
Windows users among us see some advantage to fsroot -- I'd be happy to discuss
it with them.
fscwd - the dir that was the fs CWD when Perl started up
Stick with $*CWD for this, I reckon, and have it implicit in all paths
that don't start with an absolute path. But all the other variables below
should be absolute paths.
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
Vote yes to temp and home. Don't understand what you mean by docs.
So to refer to common things on a Unix system like the fully-qualified ways,
you can write paths like:
fsroot/home/me/myfile
fsroot/usr/bin/perl
fsroot
This is a great example of why fsroot is a bad idea.
For something analogous to traditional CWD sans modifications:
fscwd/mynewfile.txt
fscwd/lib/doit.pl
...and a great example of why fscwd is a bad idea.
To define a new doi at runtime, something like:
%DOI{'mycwd'} = %DOI{'fscwd'};
%DOI{'mycwd'} ~= 'subdir';
# later
my $fh = IO.open( 'mycwd/myfile.txt' );
If I were doing it, I'd make it look like this:
%bookmarkmycwd = $*CWD;
%bookmarkmycwd.push('subdir');
# later
my $fh = IO.open( p{#mycwd#/myfile.txt} );
The only part I don't like is marking the mycwd with the hashes. I
think we can't do without markers altogether because it would absolutely
confuse everyone :). Putting a hash before and after is also a bad idea
because it's like nothing else in Perl.
The only other idea I can think of is to come up with another quote
adverb/pragma pair. Something like:
use hashinterpolate %*bookmark;
...and have the :hi (short for :hashinterpolate) quote modifier make
$mycwd refer to %*bookmarkmycwd, and then have :path automatically do :hi as
well, unless :qq is used, or something.
Anyway, I home someone who knows more about Perl interpolation than me
has an idea here.
Anyway, I like my terminology better, because it's less scary, and
I've shaved off some of the scariest bits of syntax from your proposal, but
there is still some work to be done on it here.
HTH,
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
[perl #64566] @a[1..*] adds trailing undef value
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 of a range, a lone whatever means to the maximum
specified index (if fixed indices were defined):
say @calendar[5..*]; # Same as: say @calendar[5..11]
say @calendar{Jun..*};# Same as: say @calendar{Jun..Dec}
or to the largest allocated index (if there are no fixed indices):
say @data[1..*]; # Same as: say @results[1..5]
It doesn't mention how the postcifcumfix:[ ] is supposed to introspect
those to find out if the WhateverCode object constructed by 1..* needs
to receive self.elems or self.elems-1 as an argument.
Which is why I CC: p6l to get some ideas or clarification, and if we
want to maintain this DWIMmy but not very consistent behaviour.
Cheers,
Moritz
Re: [perl #64566] @a[1..*] adds trailing undef value
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 defined):
say @calendar[5..*]; # Same as: say @calendar[5..11]
say @calendar{Jun..*};# Same as: say @calendar{Jun..Dec}
or to the largest allocated index (if there are no fixed indices):
say @data[1..*]; # Same as: say @results[1..5]
It doesn't mention how the postcifcumfix:[ ] is supposed to introspect
those to find out if the WhateverCode object constructed by 1..* needs
to receive self.elems or self.elems-1 as an argument.
Which is why I CC: p6l to get some ideas or clarification, and if we
want to maintain this DWIMmy but not very consistent behaviour.
I like it the way S09 says it.
But there is a problem with sparse arrays, isn't there?
S32/Containers (S32-array) says this about elems:
our Int method elems (@array: ) is export
Returns the length of the array counted in elements. (Sparse array types
should return the actual number of elements, not the distance between the
maximum and minimum elements.)
For arrays, it appears that using end is more relevant:
our Any method end (@array: ) is export
Returns the final subscript of the first dimension; for a one-dimensional
array this simply the index of the final element. For fixed dimensions this
is the declared maximum subscript. For non-fixed dimensions (undeclared or
explicitly declared with *), the index of the actual last element is used.
Does that seem usable to y'all?
--
Jan
Re: [perl #64566] @a[1..*] adds trailing undef value
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 whatever means to the maximum
specified index (if fixed indices were defined):
say @calendar[5..*]; # Same as: say @calendar[5..11]
say @calendar{Jun..*}; # Same as: say @calendar{Jun..Dec}
or to the largest allocated index (if there are no fixed indices):
say @data[1..*]; # Same as: say @results[1..5]
It doesn't mention how the postcifcumfix:[ ] is supposed to introspect
those to find out if the WhateverCode object constructed by 1..* needs
to receive self.elems or self.elems-1 as an argument.
Which is why I CC: p6l to get some ideas or clarification, and if we
want to maintain this DWIMmy but not very consistent behaviour.
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. That
said, when dealing with a custom index, there generally isn't an
easily identified one element past the end position that can be
referenced; so I'd be inclined to standardize everything there such
that '*' always refers to the last element. And if we're going to do
that, why not do the same for standard indexing? e.g., '*' is always
the last element; '*-1' is always one in from the last element; etc.
I like it the way S09 says it.
But there is a problem with sparse arrays, isn't there?
There shouldn't be, because there shouldn't be sparse arrays - at
least, not in standard indexing. One of the reasons for the
introduction of custom indices was the idea that sparseness would
take place in them, so that the standard index could be relied upon yo
provide ordinal access to the elements: @a[0] should _always_ be the
first element; @a[1] should always be the second element, and so on.
And you should always be able to reach the next item by adding one to
the current item's index. That is, the standard index will always be
'0..^$number-of-items'.
If we're not going to follow this rule, then I see no reason why we
shouldn't just have the custom indexing mechanism _replace_ standard
indexing, rather than exist side by side with it. If the standard
index can't be depended on for standardized behavior, it's useless.
That said, a case could be made that the custom indexing model is too
strict as written: it forces you to pre-establish a one-to-one
relationship between the standard and custom indices, which largely
negates its usefulness in implementing the concept of sparse arrays.
I recommend loosening up the restrictions on custom indexing and
putting a note in the spec to clarify the intended purpose and
features of the standard index.
S32/Containers (S32-array) says this about elems:
our Int method elems (@array: ) is export
Returns the length of the array counted in elements. (Sparse array types
should return the actual number of elements, not the distance between the
maximum and minimum elements.)
This is exactly what the division between standard and custom indexing
was supposed to avoid. When using standard indexing, the distance
between the minimum (i.e., [0]) and maximum (i.e., [*-1]) elements
should always be the actual number of elements; so no such special
note should be needed.
--
Jonathan Dataweaver Lang
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
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 $cwd = $*CWD; Assuming that no exception was thrown, should $cwd now be '/some/absolute/relative/path' or '../relative/path' ? If the former, you've broken the user's reasonable expectation that a value assigned to a variable can be retrieved by looking in the same variable. If the latter, $*CWD is a relative path name that doesn't exist in the current directory. Now that I think about it, I'm having doubts about whether it makes sense to have a $*CWD variable at all. Suppose the current directory is /a/b/c, and a different process renames /a/b to /surprise. Should reading $*CWD reflect that? Calling a POSIX-like getcwd() would do, but that's surprising in just the same way. But if $*CWD doesn't reflect external changes, you can't expect to be able to opendir its value; at that point, it doesn't seem very useful. If the motivation for $*CWD is simply so that it can be temporized, perhaps it would be better to provide a more direct method of doing that (preferably using fchdir where available). -- Aaron Crane ** http://aaroncrane.co.uk/
Re: S26 - The Next Generation
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
sandbox. Is that worth it?
I believe so. The sheer range of approaches that people said they wanted
Pod to support made it impossible for Pod to support anyone, unless
everyone can configure Pod directly. The choice then becomes: do we
provide Pod with a DSL for configuration, or do we just use
Perl 6 as its metalanguage? The answer seemed pretty obvious then.
I'm certainly not smart enough to design a config language that's powerful
enough to do everything everyone wants documentation-wise. But Larry is.
And already did. ;-)
Sure, there are downsides: Pod becomes much more tightly tied to Perl 6.
And the black hats can indeed do bad things with it.
But, you know, the bad guys have been able to do that with CPAN modules
for a long time now, and the incidence of that happening is vanishingly
small. I'm prepared to bet that most people who download something from
CPAN don't scour the source checking for system('rm -rf /')'s, nor do
they run that code in a sandbox.
And the people who *do* take such precautions will simply start to do
the same thing for any documented code (or coded documentation :-). Or
maybe the sandbox will just be an option to disable any DOC blocks
except the default one. Or else maybe perl -doc will just run under an
augmented taint mode that suspects not just anything that emerges from
an input op, but also anything created in a DOC'd command.
Two minor comments:
A valid identifier is a sequence of alphanumerics and/or
underscores, beginning with an alphabetic or underscore
Is there a good reason to deviate from Perl 6's definition of an
identifier? For the sake of consistentcy I'd just say that the Perl 6 rules
apply.
Great idea. Should definitely be that way. Patch applied.
sub fu ( #= This text stored in Cfu.WHY
This seems to be ignorant of multi subs.
Not ignorant of. Just not an example of. ;-)
If I write
multi sub fu () { #= some Pod
Then fu is a multi, not a particular candidate. Does it actually
attach to the .WHY of the candidate? Or of the multi?
Of the particular candidate. I'll make that clearer.
(If you want to document the entire multi, attach the documentation to
the proto.)
Damian
Re: S26 - The Next Generation
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 that has no declarator to a warning). The latter would fully restore the generic applicability of the POD 5 parser, right? While I'm all in favour of other languages using Pod as a documentation format, I think that's unlikely. Pod says that anything of the form: =identfiier *anywhere* as the first non-whitespace of a line, is considered a Pod directive. I can't see many other language designers being willing to limit their assignment statements that way. While I like the design, and I think it's near enough complete, and I think a reader who knows perl and pod well could understand your current description of that design, I think it could do with a major rewrite to make it less confusing to work out what you really mean as against what's currently written. ;) However, I think it's too early to attempt such a rewrite, or even to comment on specific problems; I plan to wait another couple weeks for some list back-and-forth before commenting further about clarity and/or proposing edits and/or providing patches. I agree that a rewrite would certainly help it. And will be happy to kibitz anyone who volunteers to do so! ;-) Or, of course, to accept patches. You don't say whether attached pod allows for configuration info or formatting codes. It does. I don't say it doesn't, and I do show attached comments with it (e.g. the $chainsaw example). I'll make it explicit however. (Incidentally, .WHY seems a bit too cute; what about .DOC or .POD? Same with .WHEREFORE; my boring suggestion is .CODE.) I think you're going to have to take that up with Larry. Presumably the WHO, HOW, WHERE, WHENCE, etc. should go too? Personally (and I say this as the guy who pioneered you think that's cute now... ;-) I think the interrogatives work very well, especially because they stay so well out of the way of anything a sane person (pace Larry) would use to name an ordinary method. Declarator aliases, as specced, seem to me the weakest part of the design. Declarator aliases seem to only allow one my, one has, etc. in a given context. We could certainly consider allowing a fourth form of alias like so: =alias IDENTIFIER DECLARATOR which would use the specified identifier as the alias's name, rather than the declarator. Lets see what other people think. Having to use non-attached pod syntax to do an attached thing seems very weird. I think they have to be different, because they do opposite things...or at least things in opposite directions. A declarator block says this Pod belongs to this code; an alias says this code can be referred to in subsequent Pod. I'd be happy to be proved wrong if someone can come up with a better mechanism than aliases that still allows us to pull code into Pod. Having to use aliases at all to refer to things that the Perl 6 compiler already has a name for seems like an ugly/heavyweight/suboptimal approach. I think aliases are essential. We need a way of referring to ambient code within Pod, without the Podder having to write more code to get it. Damian
Re: S26 - The Next Generation
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* an ambiguity, by defining an operator
such as infix:=x but then you get precisely what you deserve. ;-)
if really_long_expression
== value { ... } # Pod, or equality operator?
Always equality. Pod is always =IDENT. Only.
Note the recent revisions to how Perl comments work - in particular,
an embedded comment is now spelled #`[ ... ]. Should embedded
attached Pod be spelled as #=`[ ... ]?
Larry and I discussed this and concluded that #=[ is better.
I can see the logic of #`[= but I just can't see the aesthetics of it.
I'd much rather have to only look at the second character to determine
it's Pod, not a vanilla comment. Besides, I think people will simply learn
that #symbol[ is an embedded comment, where symbol specifies
what kind of comment it is (I can certainly envisage other kinds
besides just vanilla and Pod-flavoured)
Damian
Re: S26 - The Next Generation
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 Item =item # Third Item or even just: =item# First Item =item# Second Item =item# Third Item =term First Name Definition =term Second Name Definition This doesn't work, because it doesn't conform to the general syntax of abbreviated blocks (which is that the content starts immediately after the typename). The term of a term/definition is basically a very complicated bullet point, and hence needs to be configured with an option. Of course, we could make a special exemption to the general syntax, or say that in this one case the first line of content is special, but I'm *really* loathe to inject special cases when a general mechanism already exists. Within tables, you should probably replace whitespace with multiple whitespace as a column delimiter; otherwise, the space between two words in an identifier would trigger a new column: Indeed. That was both the intention and the implementation in Perl6::Perldoc, but it definitely needs to be mentioned explicitly. Thank-you. 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. Why is =END a block, and not a directive? Damn good question. I can't think of any reason off the top of my head. I'll need to ponder that. Damian
Re: S26 - The Next Generation
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 time), with all the security risks implied. So we'll need a *very* good sandbox. Is that worth it? I believe so. The sheer range of approaches that people said they wanted Pod to support made it impossible for Pod to support anyone, unless everyone can configure Pod directly. The choice then becomes: do we provide Pod with a DSL for configuration, or do we just use Perl 6 as its metalanguage? The answer seemed pretty obvious then. Pod itself is a DSL. 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 it? Module authors can use it to generate files to go with the distribution. 'make install' can use it to generate docs with locally-set values in them. Casual browsers can stay safe. 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. Kyle.
Re: S26 - The Next Generation
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 hint that you're running the compiler, just as 'perl -c' does, and 'perldoc' doesn't. ~jerry
Re: S26 - The Next Generation
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 it? There is no perl6doc. There is only: perl6 -doc That is, running the Perl interpreter in a special mode to get documentation. 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. But the reason will be exactly the same. Namely, because in Perl you can't tell what's documentation and what's code until you parse the mixture. And you can't parse Perl (5 or 6) without executing stuff. Look, I'm sure we *will* have a safety mode of parsing Pod (maybe: perl -undoc) But it can't be on by default, otherwise no-one can write anything but vanilla Pod and expect it to work. It's like saying that 'use' is potentially dangerous (which it *is*) so can we have it off by default. In Perl, the answer has to be no. Damian
Re: S26 - The Next Generation
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 '=for alias' as special cases: the Perl parser makes an exception for them and doesn't treat them as the start or end of POD Blocks, merely as single-line directives; but the Pod parser treats them as normal Pod Blocks, with the contents being attached to the alias. Net result: said contents count both as ambient code and as aliased text. Benefits: you can alias any ambient code that you want, as long as it consists of one or more full lines; and your method for delimiting the alias is one that Pod writers will be quite use to. Drawback: the Perl parser will need to look forward a bit further before deciding how much ambient commentary there is. -- Jonathan Dataweaver Lang
Re: S26 - The Next Generation
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 POD Blocks, merely as single-line directives; but the Pod parser treats them as normal Pod Blocks, with the contents being attached to the alias. Well, clearly I'm not going to be in favour of introducing exceptions to the general syntax. However, I had originally thought that we should have =alias and =dealias directives to delimit code extractions. In the end I liked the use of the code's own delimiters better, but I guess if people preferred to have two directives as delimiters, we could consider that instead. Let's see what others think. Damian
Re: Last IO discussion
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 vaguely related to locale. The problem (or one of them) is that if I create a file today, and then change my locale tomorrow, I end up with a garbled filename. Of course, people don't as a rule change to a different locale every day, but I still think this is a situation where we need to put the onus on the user. That is, either Perl can determine the encoding (e.g. because the filesystem indicates it in some way), or else the user needs to pick one explicitly. If you get a list of files from reading a dir, and don't need to display the names or anything, you might get away with treating them as undistinguished bytes; but as soon as Perl does anything that needs an encoding and one hasn't been specified, it should complain bitterly. It's the same reasoning why I think specifying a timezone should be required: it's not that much work for the user to add use IO::Encoding $volume = utf-8, and at least that way naive users will be alerted to the fact that something's going on. It's up to them how much effort they think is worth devoting to the issue, but at least they will be warned that there's an issue there to grapple with. -David
Re: S26 - The Next Generation
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 Lang proposed:
OK. Let me propose an alternative (which I expect will be immediately
shot down):
BANG!
;-)
D'oh!
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 POD Blocks, merely as single-line directives; but
the Pod parser treats them as normal Pod Blocks, with the contents
being attached to the alias.
Well, clearly I'm not going to be in favour of introducing exceptions to
the general syntax.
However, I had originally thought that we should have =alias and
=dealias directives to delimit code extractions. In the end I liked the
use of the code's own delimiters better, but I guess if people preferred
to have two directives as delimiters, we could consider that instead.
What I liked the most about my proposal was that it allowed for a
blank line termination form as well as an explicit directive
termination form. On review, '=for alias' would have been redundant
with '=alias' (although I don't think that redundancy hurts). And
again, the Pod coder would be able to think in the same terms that he
does for ordinary blocks.
But assuming for the moment that the pseudo-block idea is off the
table, how about saying that an ambient code alias is normally
terminated by the next blank line or Pod directive (as per =for)
unless you give it a :begin adverb, in which case it terminates with
an appropriately nested =alias name :end directive:
=alias outer :begin
while (...) {
=alias inner
blah blah blah
}
=alias outer :end
Unless there's some reason why adverbs don't work for =alias
directives, that's fully consistent with normal syntax. OTOH, that's
exactly what the problem would be, isn't it? '=alias outer :begin'
would be parsed as an inline alias, where outer is equated with
:begin. So how about borrowing from your earlier example of
numbered items, and identifying explicitly terminated blocks with a +
or - immediately following the '=alias':
=alias+ outer
while (...) {
=alias inner
blah blah blah
}
=alias- outer
I'm also considering a more radical possibility whereas the ambient
code has a means of tagging portions of itself for Pod inclusion.
I'll think it through some more and then offer a proposal.
Still, I think that treating =alias as a block when it has only one
argument, and as a directive when it has none or two, would be more
user-friendly (though admittedly more hostile to the guy coding the
Pod Parser) than any of these alternatives.
Let's see what others think.
OK.
--
Jonathan Dataweaver Lang
Re: directories of interest, a multiplicity alternative to CWD
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 was just illustrative, meant to evoke how you set signal handlers
in Perl 5, and in no way does that syntax need to be used.
The idea of starting all paths with doi/ rather than / was to first imply
that there was no single root, and also for consistency in that the one
representing / has the *same* syntax as all the others.
I wasn't actually proposing using fsroot, etc as the names; those were just
examples, and in fact my proposal was about users picking what names they want,
so my list of 6 examples, such as docs, was meant to represent something users
might pick and name for their own circumstances, not that these are built-ins.
Come to think of it, if a doi is allowed to be any string at all, like a
hash key can, then the system-defined one representing the real filesystem root,
/, could just be the empty string, which means that you end up using the exact
same / syntax as you're already used to, and it means the same thing. So then
under my proposal, its more that the syntax for relative urls like foo/bar has
had its meaning changed so foo is a doi rather than a subdir of the single CWD.
While I didn't explicitly state it, the roots that came system-defined could
conceivably also be altered by the user, eg they could redefine
whatever-fsroot-is-called, which incidentally would result in them chroot-ing
themselves. This also means that part of what I had in mind is that you can't
use a relative url to go to some parent/sibling of a doi by way of that doi,
meaning all urls visually are absolute. This might mean that the name
bookmark isn't as appropriate if it implies you can go to a parent of the
doi by way of it, but this is a minor quibble and if the feature is called
bookmark I won't really object.
-- Darren Duncan
Timothy S. Nelson wrote:
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 is called a directory of
interest or doi.
I briefly mentioned a similar idea, but with no theoretical
background :). I would've called them bookmarks instead of doi,
though.
For those who shied away from Darren's large theoretical background,
fearing that it would lead to pie-in-the-sky or something, the simple
version of his proposal was to have a magic global hash, and have it
work like:
%*DOIhome = /home/foo;
$path = p{home/Music}; # $path points at /home/foo/Music
I disagree with the syntax, but the idea has merit.
Your idea for making everything a relative path isn't one that
appeal to me. But having a predefined set of bookmarks that could be
used is certainly an interesting idea.
I don't like your syntax, though :). But see below.
fsroot - the root of the real file system, analogous to /
I think we should stick with / as it's well-understood. Unless the
Windows users among us see some advantage to fsroot -- I'd be happy to
discuss it with them.
fscwd - the dir that was the fs CWD when Perl started up
Stick with $*CWD for this, I reckon, and have it implicit in all
paths that don't start with an absolute path. But all the other
variables below should be absolute paths.
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
Vote yes to temp and home. Don't understand what you mean by docs.
So to refer to common things on a Unix system like the fully-qualified
ways, you can write paths like:
fsroot/home/me/myfile
fsroot/usr/bin/perl
fsroot
This is a great example of why fsroot is a bad idea.
For something analogous to traditional CWD sans modifications:
fscwd/mynewfile.txt
fscwd/lib/doit.pl
...and a great example of why fscwd is a bad idea.
To define a new doi at runtime, something like:
%DOI{'mycwd'} = %DOI{'fscwd'};
%DOI{'mycwd'} ~= 'subdir';
# later
my $fh = IO.open( 'mycwd/myfile.txt' );
If I were doing it, I'd make it look like this:
%bookmarkmycwd = $*CWD;
%bookmarkmycwd.push('subdir');
# later
my $fh = IO.open( p{#mycwd#/myfile.txt} );
The only part I don't like is marking the mycwd with the hashes.
I think we can't do without markers altogether because it would
absolutely confuse everyone :). Putting a hash before and after is also
a bad idea because it's like nothing else in Perl.
The only other idea I can think of is to come up with another
Re: [perl #64566] @a[1..*] adds trailing undef value
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 out if the WhateverCode object constructed by 1..* needs to receive self.elems or self.elems-1 as an argument. The * can tell when it's in a range, and set some range-flag on the resulting object, right? Then .[] will test for $whatever.range- flag. Or am I missing the point? 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 little difference, it seems more worthwhile to be consistent than to be DWIMy. So, yes, either * always means last+1, and use 1..^*, or make * mean the last index, and use [*+1] to append. But there is a problem with sparse arrays, isn't there? Sparseness is an implementation detail. Arrays all look the same to the user; sparseness just means perl is smart enough to do @foo[1]=$bar without trying to suck up a zillobyte of RAM. -David
Re: directories of interest, a multiplicity alternative to CWD
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/directory tree/file system on which perl6 programs operate, rather than having to understand the whole environment in which software could run - delegates to a module if perl6 is to be used to manage a specific environment/OS - offers more future proofing and portability than constraining what can or cannot be in a pathname. - allows users to configure via Policy.pm standard pathnames to something non-standard for development and testing, leaving the software itself unchanged. Richard, thanks for your feedback. I think you raise a lot of good points about further consequences of my proposal. I think I'll also raise the point that depending on how its further designed, my proposal could help with security as well, by implicitly defining sandboxes as it were. If it is interpreted that you can not refer to something that is a parent or sibling dir of a DOI by way of that DOI, hence treating it like an absolute root, then that means that any code can only access parts of the filesystem that are visible-to-it DOIs or subdirs of said, because there's simply no syntax to reference anything outside. There is no '..' in my scheme. For example, if a Perl thread starts out seeing only a single DOI representing the filesystem root, and they update it to some subdir, then they have just chrooted themselves. Similarly, if a Perl thread does not see any DOI at all, then they effectively are denied access to the filesystem period. So in general, I hope people can see that a natural consequence of my proposal is that we also have an elegant means for security or virtualization, which among other things can aid Perl's support for running in restrictive environments, such as a cloud, or whatever. Note, I want to make clear that my proposal is *not* about abstracting away all kinds of IO into a single uri scheme, but only abstracting the file system. Not that it can't be further extended in appropriate ways. -- Darren Duncan
Re: $*CWD and chdir()
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 to what all of Perl's own IO uses, and any such change would have no effect on any Perl $*CWD.) I would propose that whenever Perl spawns a non-Perl process, that process automatically executes a chdir() to the spawning thread's value of $*CWD. But this should be done without changing the parent process's external/OS working directory. In UNIX that's easy - fork(), then chdir(), then exec() - but in Windows it may be trickier. I agree with your proposal, which seems to better conform to expected behavior. -- Darren Duncan
Re: [perl #64566] @a[1..*] adds trailing undef value
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 little difference, it seems more worthwhile to be consistent than to be DWIMy. So, yes, either * always means last+1, and use 1..^*, or make * mean the last index, and use [*+1] to append. ...and if addressed properly, it can be DWIMmy too. In many ways, saying that * is just off the end of the index range is counterintuitive; it's more reasonable to people who haven't been trained to think in terms of Perl 5's negative indices to think of 0 as being the first element and * as being the last element. And again, there are fewer problems with custom indexing if you go this route. But there is a problem with sparse arrays, isn't there? Sparseness is an implementation detail. Arrays all look the same to the user; sparseness just means perl is smart enough to do @foo[1]=$bar without trying to suck up a zillobyte of RAM. To the extent that that is true, @foo.elems should equal 10001. -- Jonathan Dataweaver Lang
Re: directories of interest, a multiplicity alternative to CWD
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 when you define one
DOI in terms of another, their definitions are *not* bound together. For
example, if you define DOI b as subdir foo of DOI a, and then you later
redefine what a is, then b does *not* automatically update to be the foo
subdir of the altered a, but rather keeps its original meaning. So this keeps
things simpler and avoids action at a distance. Well the only action at a
distance is that any subsequently executed code with a p{a/bar/baz} will use
the new meaning of a. -- Darren Duncan
Re: directories of interest, a multiplicity alternative to CWD
'home' should be spelled '~'. -- Jonathan Dataweaver Lang
Re: directories of interest, a multiplicity alternative to CWD
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
Re: directories of interest, a multiplicity alternative to CWD
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 something similar, but you should be able to do
this with any directory object.
my $dir = $*CWD; # returns an IO object, not merely
a string
my $dir ~= subdir; # $dir is now an object
representing the subdir
my $file = io $dir/filename;
{
temp $*CWD = $dir;
...
}
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 running on a Mac, so $IO::DOI::MacOSX is
automatically loaded
use IO::DOI Home Music Downloads; # names that ::MacOSX makes
available
say $Home; # /Users/david
say $Music;# /Users/david/Music
say $Downloads;# /Users/david/Junk drawer
There will be a few names that should be standard as much as possible
across OS's, e.g. Home even though on a Mac the dir is actually
called Users. Trash might be another one (which will be undef if
the OS doesn't handle it).
This doesn't address the security side of things; dir objects might
have a flag you can set so that it will warn you (perhaps fatally) if
you try to use $dir.parent or $dir/.., etc., but you could always
get to an outside dir some other way. I think a more explicit way to
set a chroot is better, such as:
$IO::Root = $*CWD;
$IO::Root = $Home;
temp $IO::Root = $IO::DOI{Docs};
Similarly, if a Perl thread does not see any DOI at all, then they
effectively are denied access to the filesystem period.
Hm, undef $IO::Root?
Of course, that still doesn't cover everything your suggestion does,
because your way allows for multiple roots. But you also weren't
suggesting a specific syntax, and I'm leaning to something like my
example above. Perhaps along the lines of:
$IO::Root{file} = /; # default root (assumes file://)
$IO::Root{http} = http://;; # means any website
$IO::Root{ftp} = ftp://;;# etc.
Every time you use IO::Some_protocol_name, it would set a default
$IO::Root{protocol-name}. But there's nothing special about the
names; you can add or change $IO::Root as you wish.
$IO::Root{file} = /foo;
$IO::Root{more files} = /bar;
# Now can access only files that come under /foo or /bar
$IO::Root$_.delete for «file more files»;
# Now there are no more file:// roots, cannot access any files
$IO::Roothttp = http://localhost/~david/;;
# Now can access only URLs from my section of the local website
Hm, having just written that, it obviously should be the case that
$IO::Rootfile should be a hash with all the available file: roots,
i.e. $IO::Root is a hash-of-hashes where the keys are {protocol-name}
{arbitrary-name}. And the default arbitrary-name might just be
default.
-David
r28036 - in docs/Perl6/Spec: . S32-setting-library
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. More spec
will be
needed when I (or someone) understands better :).
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-08-19 20:32:00 UTC (rev 28035)
+++ docs/Perl6/Spec/S16-io.pod 2009-08-19 22:04:27 UTC (rev 28036)
@@ -174,6 +174,23 @@
It is expected that other sets of constraints, such as VMS, DOS, and old-style
Mac will be provided by modules.
+=head2 $*CWD
+
+The global variable $*CWD is a Path object with certain special properties,
+mainly:
+ * It must check whether the path exists before changing its value
+ * It can only be assigned an absolute path; if you want to make relative
+ changes, use the Array interface
+
+$*CWD is specific to the current thread, unlike %*ENVPATH or the native
+getcwd/chdir path, which are both usually process-wide.
+
+The variable is used in at least these cases:
+* When a Path object is created, if the string it is given is not an absolute
+ path, then $*CWD is prepended to it.
+* When a subprocess is executed, it is executed with the current thread's
+ $*CWD as its working directory.
+
=head1 Name Services
=head2 User role
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-19 20:32:00 UTC (rev
28035)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-19 22:04:27 UTC (rev
28036)
@@ -660,7 +660,9 @@
Changes the current working directory to the one specified by FILENAME.
If it succeeds it returns true, otherwise it returns CFailure and
-sets C$! (errno).
+sets C$! (errno). Note, though, that chdir affects only the system
+directory; most things in Perl 6 that need a current directory depend
+on their thread's copy of $*CWD.
=item find
@@ -682,12 +684,21 @@
role Path does Str does Array {
has Str $.Type;
-has Array of Str @.Elements;
+has Str $.Encoding;
+has Array of Buf @.Elements;
has Array of IO::ACL @.ACLs;
has Hash of %.times;
...
}
+C$.Type can be CFile, CDirectory, CLink, or COther. See
+C.create() method documentation for how it is set.
+
+$.Encoding tells us what the encoding is, if known. If $.Encoding is
+undefined, then there are a number of things that can't be done with it,
+such as treating is the Path as a Str, using say/print/any other display
+method on it, and those kinds of things.
+
The @.Elements array is a list of Str that contain the path elements, but
all are checked before being pushed onto the array.
@@ -695,13 +706,10 @@
CAccess (and maybe others on other operating systems), and the values are
all CTemporal::Instant objects.
-C$.Type can be CFile, CDirectory, CLink, or COther. See
-C.create() method documentation for how it is set.
+When a Path is used as a Str, it allows some operations, so that it can
+be concatenated easily with other strings. When used as an Array, it
+acts as an array of path elements.
-When used as a Str, it allows some operations, so that it can be concatenated
-easily with other strings. When used as an Array, it acts as an array of
-path elements.
-
=head3 Methods
=over 4
Re: Filename literals
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
File::Spec documentation), which will do No physical check on the
filesystem, but a logical cleanup of a path, and realpath (idea
taken from p5's Cwd documentation), which will resolve symlinks,
etc, and provide an absolute path. Oh, and resolvepath, which
does both. I'm not quite sure I followed all your discussion above
-- have I left something out?
I think there's a difference between canonical as in a webpage with
link rel=canonical, and cleanup as in Windows turning PROGRA~1
into Program Files. There could also be other types of
normalisation depending on the FS, but we probably shouldn't concern
ourselves with them, other than having some way to get to such native
calls.
Anyway, my assumption is that there should be a number of
comparison options. Since we do Str, we should get string
comparison for free. But I'm expecting other options at other
levels, but have no idea how or what at this point.
As Leon Timmermans keeps reminding us, that really should be delegated
to the OS/FS. I think $file1 =:= $file2 should ask the OS whether it
thinks those are the same item or not (it can check paths, it can
check inodes, whatever is its official way to compare file-thingies).
Similarly, $file1.name === $file2.name should ask the OS whether it
thinks those names mean the same thing. And if you want to compare
the canonical paths or anything else, just say $file1.name.canonical
=== $file2.name.canonical, or use 'eq', or whatever you want to do,
just do it explicitly.
According to my last commit, p{} will return a Path object that
just stores the path, but has methods attached for accessing all the
metadata. But it doesn't do file opening or things like that
(unless you use the :T and :B thingies, which read the first block
and try to guess whether it's text or binary -- these are in Perl 5
too).
There are two things going on here: the user-friendly syntax for
casual use, which we basically agree should be something short and
pithy, although we have but begun to shed this bike, I'm sure.
$file = io /foo/bar;
$file = p{/foo/bar};
$file = Q:p/foo/bar/;
$file = File(/foo/bar);
However we end up spelling it, we want that to give us unified access
to the separate inside parts:
IO::Data# contents of file
IO::Handle # filehandle for using manually
IO::Metadata
IO::Path
I'm not sure why Path isn't actually just part of IO::Metadata...
maybe it's just handy to have it out on its own because pathnames are
so prominent. In any case, $file.size would just be shorthand for
something like $file.io.metadata{size}. The :T and :B tests probably
ought to be part of IO::Data, since they require opening the file to
look at it; I'd rather put them there (vs. ::Metadata, which is all
outside info) since plain ol' $file abstracts over that detail
anyway. You can say $file.r, $file.x, $file.T, $file.B, and not care
where those test live under the hood.
We might actually want to distinguish IO::Metadata::Stat from
IO::Metadata::Xattr or something... but that's probably too FS-
specific. I don't think I mind much whether it's IO::Path or
IO::Metadata::Path, or whether they both as exist as synonyms
I think we want many of the same things, I'm just expressing them
slightly differently. Let's keep working on this, and hopefully we
end up with something great.
Yes. A great mess! Er, wait, no
And there's no perfect solution, but it would be useful for Perl to
stick as closely as the FS/OS's idea of types as it can. Sometimes
that would mean looking up an extension; it might mean using (or
emulating) file magic; it might mean querying the FS for a MIME-
type or a UTI. After all, the filename extension may not actually
match the correct type of the file.
My suggestion would be that it's an interesting idea, but should
maybe be left to a module, since it's not a small problem. Of
course, I'm happy to be overruled by a higher power :). I'd like
the feature, I'm just unsure it deserved core status.
Well, it's all modules anyway... certainly we'll have to rely on
IO::Filesystem::XXX, but I do think this is another area to defer to
the OS's own type-determining functions rather than try to do it all
internally. What we should have, though, is a standard way to
represent the types in Perl so that users know how to deal with them.
I think roles are the obvious choice: if the OS tells you that a file
is HTML, then $file would do IO::Datatype::HTML, which means in turn
it would also do IO::Datatype::Plaintext, and so on.
Of
Re: Filename literals
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 that the string started life as the
name of a file somewhere. I could convert it explicitly, but it's
not obvious that I need to; 'name' sounds like something that should
return Str.
On 8/19/09, David Green david.gr...@telus.net wrote:
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
File::Spec documentation), which will do No physical check on the
filesystem, but a logical cleanup of a path, and realpath (idea
taken from p5's Cwd documentation), which will resolve symlinks,
etc, and provide an absolute path. Oh, and resolvepath, which
does both. I'm not quite sure I followed all your discussion above
-- have I left something out?
I think there's a difference between canonical as in a webpage with
link rel=canonical, and cleanup as in Windows turning PROGRA~1
into Program Files. There could also be other types of
normalisation depending on the FS, but we probably shouldn't concern
ourselves with them, other than having some way to get to such native
calls.
Anyway, my assumption is that there should be a number of
comparison options. Since we do Str, we should get string
comparison for free. But I'm expecting other options at other
levels, but have no idea how or what at this point.
As Leon Timmermans keeps reminding us, that really should be delegated
to the OS/FS. I think $file1 =:= $file2 should ask the OS whether it
thinks those are the same item or not (it can check paths, it can
check inodes, whatever is its official way to compare file-thingies).
Similarly, $file1.name === $file2.name should ask the OS whether it
thinks those names mean the same thing. And if you want to compare
the canonical paths or anything else, just say $file1.name.canonical
=== $file2.name.canonical, or use 'eq', or whatever you want to do,
just do it explicitly.
According to my last commit, p{} will return a Path object that
just stores the path, but has methods attached for accessing all the
metadata. But it doesn't do file opening or things like that
(unless you use the :T and :B thingies, which read the first block
and try to guess whether it's text or binary -- these are in Perl 5
too).
There are two things going on here: the user-friendly syntax for
casual use, which we basically agree should be something short and
pithy, although we have but begun to shed this bike, I'm sure.
$file = io /foo/bar;
$file = p{/foo/bar};
$file = Q:p/foo/bar/;
$file = File(/foo/bar);
However we end up spelling it, we want that to give us unified access
to the separate inside parts:
IO::Data# contents of file
IO::Handle # filehandle for using manually
IO::Metadata
IO::Path
I'm not sure why Path isn't actually just part of IO::Metadata...
maybe it's just handy to have it out on its own because pathnames are
so prominent. In any case, $file.size would just be shorthand for
something like $file.io.metadata{size}. The :T and :B tests probably
ought to be part of IO::Data, since they require opening the file to
look at it; I'd rather put them there (vs. ::Metadata, which is all
outside info) since plain ol' $file abstracts over that detail
anyway. You can say $file.r, $file.x, $file.T, $file.B, and not care
where those test live under the hood.
We might actually want to distinguish IO::Metadata::Stat from
IO::Metadata::Xattr or something... but that's probably too FS-
specific. I don't think I mind much whether it's IO::Path or
IO::Metadata::Path, or whether they both as exist as synonyms
I think we want many of the same things, I'm just expressing them
slightly differently. Let's keep working on this, and hopefully we
end up with something great.
Yes. A great mess! Er, wait, no
And there's no perfect solution, but it would be useful for Perl to
stick as closely as the FS/OS's idea of types as it can. Sometimes
that would mean looking up an extension; it might mean using (or
emulating) file magic; it might mean querying the FS for a MIME-
type or a UTI. After all, the filename extension may not actually
match the correct type of the file.
My suggestion would be that it's an interesting idea, but should
maybe be left to a module, since it's not a small problem. Of
course, I'm happy to be overruled by a higher power :). I'd like
the feature, I'm just unsure it deserved core status.
Well, it's all modules
Re: Custom object constructors
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 just
one or the other. I guess you could redefine new and parse your
arguments into the correct named pair arguments the other initialization
functions (bless, BUILDALL, BUILD) expect, but that would be before
blessing, and seems sort of limiting.
Mark J. Reed wrote:
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 kben...@a-1networks.com wrote:
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 correctly passed to the right BUILD method. It seems a
whole chain of new - bless - BUILDALL - BUILD would need to be
defined with specific signatures just to get a custom constructor.
Two possible thoughts on how to achieve this were put forth in the
#perl6 discussion. One, auto build the chain on definition of a BUILD
method, which was thought be some to be a bit too magical (me included,
even though it was my suggestion at first). Alternatively, pass the
capture of arguments as supplied by new down the chain of initialization
methods so any that were defined as multi's can be called correctly by
multiple dispatch at the correct point.
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 DateModule $d .= new('2007-03-12');
Relevant bits of #perl6 discussion copied below:
(2009-08-19 11:47:49) Kentrak: Q re: object initialization in p6; Should
defining a BUILD with a non standard signature imply an implicit
declaration of new with the same signature?
(2009-08-19 11:48:05) moritz_: KyleHa: no
(2009-08-19 11:48:23) moritz_: erm sorry, meant Kentrak
(2009-08-19 11:48:26) moritz_: tab fail :/
(2009-08-19 11:48:35) moritz_: Kentrak: it's a nice idea, but it seems
like too much magic to me
(2009-08-19 11:48:50) Kentrak: moritz_: I'm aware it doesn't currently,
but it seems like it really makes sense
(2009-08-19 11:48:59) Kentrak: moritz_: in a DWIMmy sort of way
(2009-08-19 11:49:28) moritz_: Kentrak: right, but I don't see how it
fits in the current system without defining a huge exception
(2009-08-19 11:49:29) r0bby left the room (quit: Read error: 104
(Connection reset by peer)).
(2009-08-19 11:49:34) r0bby [n=wakaw...@guifications/user/r0bby] entered
the room.
(2009-08-19 11:49:43) __ash__: jnthn: http://gist.github.com/170571
(2009-08-19 11:49:51) Kentrak: moritz_: it seems I need to define a
new() AND a BUILD() with matching signatures just to get the
initialization syntax I want, soI might as well use new(), but then I
have to cless...
(2009-08-19 11:49:52) moritz_: anyway, I'll think about it
(2009-08-19 11:50:02) Kentrak: err, bless
(2009-08-19 11:50:15) moritz_: Kentrak: no, new() is enough, no need for
another BUILD
mofino molaf moritz_
mofino molaf moritz_
(2009-08-19 11:50:52) moritz_: well, maybe we could have a new() with
slurpy positional arguments
(2009-08-19 11:50:55) masak: I override new() when I want magic
parameter handling, and BUILD when I want non-standard object
initialization.
(2009-08-19 11:50:56) japhb: moritz_, What are your rules of thumb for
when to use the various ways (implicit and explicit) to define constructors?
(2009-08-19 11:51:13) masak: #p6s in 10, by the way.
(2009-08-19 11:51:28) dalek: rakudo: 5a85869 | pmichaud++ |
docs/announce/2009-08:
(2009-08-19 11:51:28) dalek: rakudo: Small fix to release announcement.
(2009-08-19 11:51:28) dalek: rakudo: review:
http://github.com/rakudo/rakudo/commit/5a85869ddbc17095cdb884f10a6cd1618804d773
(2009-08-19 11:51:31) moritz_: and have it try to dispatch to a BUILD
method, and fail if there's no matching one
(2009-08-19 11:51:37) jnthn: __ash__: OK, looks sane.
(2009-08-19 11:51:41) jnthn: __ash__: Two questions
(2009-08-19 11:51:42) Kentrak: moritz_: so if I want to add initializer
methods to support something like my DateModule $d .= new('2007-03-12');
then I have to define new() submethods and use bless like in p5?
(2009-08-19 11:51:47) jnthn: 1) Does it make what you wanted to work
actually work?
(2009-08-19 11:51:51) moritz_: japhb: sorry, I'm involved in too many
things at a time, maybe I'll blog later about it
(2009-08-19 11:51:55) jnthn: 2) Does it still pass the spectests? :-)
(2009-08-19 11:51:58)
Re: Custom object constructors
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('...',$timestamp));
}
?
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 correctly passed to the right BUILD method. It seems a
whole chain of new - bless - BUILDALL - BUILD would need to be
defined with specific signatures just to get a custom constructor.
BUILD allows you to tweaken the initialization of known attributes. Your
BUILD submethod will only receive then named arguments for the
attributes locally defined in your class.
The purpose of BUILD is *not* to provide alternative signatures to the
constructor.
Two possible thoughts on how to achieve this were put forth in the
#perl6 discussion. One, auto build the chain on definition of a BUILD
method, which was thought be some to be a bit too magical (me included,
even though it was my suggestion at first). Alternatively, pass the
capture of arguments as supplied by new down the chain of initialization
methods so any that were defined as multi's can be called correctly by
multiple dispatch at the correct point.
The bless-BUILDALL-BUILD chain uses the positional arguments as the
candidate protoobjects that define additional parameters for the
builders. the named parameters are passed to each BUILD method for
initialization.
Again, if you want a custom signature for new, just write a custom new.
daniel
Re: Custom object constructors
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 DateModule $d .= new('2007-03-12');
My first thought is also coercion: say my DateModule $d = '2007-03-12'
and let DateModule::.(Str) worry about making the new object.
(Or does that need to be my DateModule $d = DateModule('2007-03-12')?
That seems unnecessarily redundant.)
-David
Re: Filename literals
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 things without having to worry about the fact that the string started life as the name of a file somewhere. I could convert it explicitly, but it's not obvious that I need to; 'name' sounds like something that should return Str. $file1.name == $file2.name is kinda strange because it does a numeric comparison between the filenames (see S03). Methinks you want $file1 eq $file2 (both of which are assumed to be of type Path) which does a string comparison between them without consulting the filesystem. Having said that, you've made me realise that $file1 == $file2 might be the perfect operator for comparing inodes, since inodes are numbers. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: Filename literals
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-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: directories of interest, a multiplicity alternative to CWD
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 running on a Mac, so $IO::DOI::MacOSX is automatically
loaded
use IO::DOI Home Music Downloads; # names that ::MacOSX makes
available
say $Home; # /Users/david
say $Music;# /Users/david/Music
say $Downloads;# /Users/david/Junk drawer
Similarly, I think it very reasonable that for OS's like Windows where it is
commonplace for paths to start with a particular disk volume, then
$IO::DOI::Windows would automatically load a DOI for each mounted disk; eg that
$C or $E etc would be pre-defined.
There will be a few names that should be standard as much as possible
across OS's, e.g. Home even though on a Mac the dir is actually called
Users. Trash might be another one (which will be undef if the OS
doesn't handle it).
Trash wouldn't be so simple since there are multiple .trash directories; for
starters, at least one for each logical disk volume, and also one inside each
home folder under Users. If we had a Trash, it would have to pick one of
those. Anyway, this is a minor issue that doesn't need to be worried about now.
This doesn't address the security side of things; dir objects might have
a flag you can set so that it will warn you (perhaps fatally) if you try
to use $dir.parent or $dir/.., etc., but you could always get to an
outside dir some other way. I think a more explicit way to set a chroot
is better, such as:
$IO::Root = $*CWD;
$IO::Root = $Home;
temp $IO::Root = $IO::DOI{Docs};
I would say that by design a $dir/.. or $dir.parent should simply be
impossible; if someone tried to write that, they would get a subdir named
parent or .., or a fatal warning if that isn't possible.
Similarly, if a Perl thread does not see any DOI at all, then they
effectively are denied access to the filesystem period.
Hm, undef $IO::Root?
Of course, that still doesn't cover everything your suggestion does,
because your way allows for multiple roots. But you also weren't
suggesting a specific syntax, and I'm leaning to something like my
example above. Perhaps along the lines of:
$IO::Root{file} = /; # default root (assumes file://)
$IO::Root{http} = http://;; # means any website
$IO::Root{ftp} = ftp://;;# etc.
What I had in mind was that every canonical DOI just lives as a member of a
single hash, and deleting the hash key is how you remove one. If you have a
separate variable for a single one then any use of it would be semantically
equivalent to substituting a hash access in its place, and the variable would be
undefined if the corresponding DOI doesn't exist, like a Perl 5 weakref when its
target is garbage-collected.
Every time you use IO::Some_protocol_name, it would set a default
$IO::Root{protocol-name}. But there's nothing special about the names;
you can add or change $IO::Root as you wish.
$IO::Root{file} = /foo;
$IO::Root{more files} = /bar;
# Now can access only files that come under /foo or /bar
$IO::Root$_.delete for «file more files»;
# Now there are no more file:// roots, cannot access any files
$IO::Roothttp = http://localhost/~david/;;
# Now can access only URLs from my section of the local website
Hm, having just written that, it obviously should be the case that
$IO::Rootfile should be a hash with all the available file: roots,
i.e. $IO::Root is a hash-of-hashes where the keys are
{protocol-name}{arbitrary-name}. And the default arbitrary-name might
just be default.
-- Darren Duncan
Announce: Rakudo Perl 6 development release #20 (PDX)
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 . Due to the continued rapid pace of Rakudo development and the frequent addition of new Perl 6 features and bugfixes, we continue to recommend that people wanting to use or work with Rakudo obtain the latest source directly from the main repository at github. More details are available at http://rakudo.org/how-to-get-rakudo . Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. August 2009 is code named PDX for the Portland Perl Mongers. PDX.pm has been home to several Rakudo contributors (chromatic, Allison Randal, and more) and PDX.pm has held meetings that have produced feature and bugfix patches for Rakudo. Beginning with this release, Rakudo Perl builds from an installed Parrot instead of using Parrot's build tree. This release of Rakudo requires Parrot 1.5.0. For the latest information on building and using Rakudo Perl, see the README file section titled Building and invoking Rakudo. (Quick note: the --gen-parrot option still automatically downloads and builds Parrot as before, if you prefer that approach.) Also, unlike previous versions of Rakudo Perl, the perl6 (or perl6.exe) executables only work when invoked from the Rakudo root directory until a make install is performed. Running make install will install Rakudo and its libraries into the Parrot installation that was used to build it, and then the executables will work when invoked from any directory. Some of the specific major changes and improvements occuring with this release include: * Rakudo is now passing 12,369 spectests, an increase of 493 passing tests since the July 2009 release. With this release Rakudo is now passing 69.98% of the available spectest suite. * We now have a much cleaner traits implementation. Many of the Perl 6 built-in traits are now implemented in Perl 6, and user-defined traits can now be defined and applied to classes and roles. * The 'hides' trait on classes can make one class hide another. * Many not-yet-implemented operators and features now provide more helpful error messages instead of simply producing parse errors. * The ROADMAP has been substantially updated and includes some details regarding the Rakudo Star release [2]. * Embedded comments now require backticks (Perl 6 specification change). Since the Perl 6 specification is still in flux, some deprecated features will be removed from Rakudo. Prominently among those are: * '=$handle' is deprecated in favor of '$handle.get' (one line) and '$handle.lines' (all lines). * 'int $obj' is deprecated in favor of '$obj.Int'. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. If you would like to contribute, see http://rakudo.org/how-to-help , ask on the perl6-compi...@perl.org mailing list, or ask on IRC #perl6 on freenode. The next release of Rakudo (#21) is scheduled for September 17, 2009. A list of the other planned release dates and codenames for 2009 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Have fun! References: [1] Parrot, http://parrot.org/ [2] Rakudo Star, http://use.perl.org/~pmichaud/journal/39411
r28040 - in docs/Perl6/Spec: . S32-setting-library
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
things to
me
* Added a number of things to better cope with the Encoding
* Other minor cleanups
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-08-20 04:09:07 UTC (rev 28039)
+++ docs/Perl6/Spec/S16-io.pod 2009-08-20 05:12:22 UTC (rev 28040)
@@ -104,6 +104,9 @@
Any path that starts with a / is considered an absolute path, otherwise
the path is considered relative.
+When creating a path with p{}, the Path.Encoding attribute is set to $?ENC,
unless
+the :bin modifier (see below) is used.
+
=head3 Default constraints
The default constraints can be set with the use path pragma, for example:
@@ -167,7 +170,9 @@
=head3 :bin constraints (no constraints at all)
If the above are causing problems, p:bin{} can be used as no checking is
-done here, other than assuming that / is the separator.
+done here. However, this leaves the Path.Encoding attribute undefined, which
+means that certain features of Path will remain unavailable unless this
+attribute is set.
=head3 Other constraints
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-20 04:09:07 UTC (rev
28039)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-20 05:12:22 UTC (rev
28040)
@@ -528,7 +528,7 @@
=item shutdown
-method shutdown(Array of Str @how)
+method shutdown(Str @how)
Does a Ishutdown(2) on the connection. See also IO::Readable.isReadable and
IO::Writeable.isWriteable.
@@ -644,7 +644,7 @@
This represents the file systems mounted on the current machine (ie.
accessible via a
filesystem path).
-class IO::FileSystem does IO::Streamable {
+class IO::FileSystems {
has Str $.illegal-chars; # ie. /\x0
has Int $.max-path;
has Int $.max-path-element;
@@ -662,15 +662,20 @@
If it succeeds it returns true, otherwise it returns CFailure and
sets C$! (errno). Note, though, that chdir affects only the system
directory; most things in Perl 6 that need a current directory depend
-on their thread's copy of $*CWD.
+on their thread's copy of $*CWD, so you probably want to set $*CWD
+instead of using chdir().
=item find
-Returns CPath objects.
+Returns CPath objects. Path.Encoding is set to $?ENC unless the
+$Encoding parameter is passed in (see Path for further discussion of
+encoding).
=item glob
-Returns CPath objects.
+Returns CPath objects. Path.Encoding is set to $?ENC unless the
+Encoding parameter is passed in (see Path for further discussion of
+encoding).
=item rename
@@ -684,9 +689,10 @@
role Path does Str does Array {
has Str $.Type;
+has Str @.Elements;
has Str $.Encoding;
-has Array of Buf @.Elements;
-has Array of IO::ACL @.ACLs;
+has Buf $.Binary;
+has IO::ACL @.ACLs;
has Hash of %.times;
...
}
@@ -694,14 +700,10 @@
C$.Type can be CFile, CDirectory, CLink, or COther. See
C.create() method documentation for how it is set.
-$.Encoding tells us what the encoding is, if known. If $.Encoding is
-undefined, then there are a number of things that can't be done with it,
-such as treating is the Path as a Str, using say/print/any other display
-method on it, and those kinds of things.
+The C@.Elements array is a list of Str that contain the path elements, but
+all are checked before being pushed onto the array. Note that @.Elements
+can not be accessed unless $.Encoding is defined.
-The @.Elements array is a list of Str that contain the path elements, but
-all are checked before being pushed onto the array.
-
The C%times has keys that can be eg. Cctime, CModification, and
CAccess (and maybe others on other operating systems), and the values are
all CTemporal::Instant objects.
@@ -721,23 +723,31 @@
This is called automatically on object creation.
-method new(
-Str :$Path,
-Array of Str :@PathElements,
+multi method new(
+Str|Buf :$Path,
+Str :@PathElements,
+Str :$Encoding,
-Array of Str :$Constraints,
+Str :@Constraints,
Str :$Protocol,
Str :$Target,
Str :$LinkType,
+ Str :$Type,
);
Path and PathElements are mutually exclusive.
+If the $Encoding parameter is not defined, then, if Path is a Buf,
+the $.Encoding attribute remains undefined, otherwise it is set to
+$?ENC. There are
+a number of features that don't work without the encoding being set.
+
$Constraints determines whether the $Path and
