Re: Should a closure-in-a-string get the placeholder parameters from its surroundings?
HaloO,
Carl Mäsak wrote:
I expected this to DWIM today:
$ perl6 -e 'my $cl = { "$^name upcased becomes {$^name.uc}" }; say $cl("larry")'
...but it doesn't in Rakudo r32938:
too few arguments passed (0) - 1 params expected
...and for understandable (if not good) reasons: the closure inside
the string expects a parameter ($^name), which it isn't getting.
I just want to make sure that I got the problem right. Would
my $cl = { "$^name upcased becomes {$^OUTER::name.uc}" };
say $cl("larry")
work? The idea is that the embedded closure refers to the strings
$^name. And now the dwimmyness shall make that implicit, right?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
[perl #60718] [PATCH] better error message for .new on undefined class
# New Ticket Created by Chris Dolan
# Please include the string: [perl #60718]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60718 >
If you accidentally try to instantiate a class that has not been
defined, but the namespace for that class has been vivified, then you
get an obscure error message:
% perl6 -e 'class Foo::Bar::Baz { }; Foo::Bar.new;'
Null PMC access in get_string()
current instr.: 'parrot;Perl6Object;new' pc 277 (src/
gen_builtins.pir:190)
called from Sub '_block11' pc 27 (EVAL_11:17)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 898 (src/PCT/
HLLCompiler.pir:510)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1450
(src/PCT/HLLCompiler.pir:774)
called from Sub 'parrot;Perl6;Compiler;main' pc 16257 (perl6.pir:
168)
With the attached patch, Rakudo instead dies with a more informative
message:
% perl6 -e 'class Foo::Bar::Baz { }; Foo::Bar.new;'
Cannot instantiate Module. Perhaps you have not defined a class
named Foo::Bar?
current instr.: 'die' pc 12358 (src/gen_builtins.pir:7530)
called from Sub 'parrot;Module;new' pc 8086 (src/
gen_builtins.pir:5170)
called from Sub '_block11' pc 27 (EVAL_11:17)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 898 (src/PCT/
HLLCompiler.pir:510)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1450
(src/PCT/HLLCompiler.pir:774)
called from Sub 'parrot;Perl6;Compiler;main' pc 16257 (perl6.pir:
168)
The patch is a bit of a hack. It introduces a new() method to
Module.pir which just constructs the error message and dies. Most of
the added code is used to build the intended class name. Surely
someone more familiar with the NameSpace pmc can improve it a bit?
Module.pir | 19 +++
1 files changed, 19 insertions(+)
undefined_class.patch
Description: Binary data
[perl #60716] [PATCH] invoke multi-level namespace grammars from rules
# New Ticket Created by Chris Dolan
# Please include the string: [perl #60716]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60716 >
This code works in Rakudo rev 32970:
grammar GrammarOne { token foo { 'foo' }; }
grammar GrammarTwo { token foobar { 'bar' }; }
'foobar' ~~ GrammarTwo::foobar or die 'failed one-level namespace
grammar';
But this code does dies:
grammar Grammar::A { token foo { 'foo' }; }
grammar Grammar::B { token foobar { 'bar' }; }
'foobar' ~~ Grammar::B::foobar or die 'failed two-level namespace
grammar';
The attached patch fixes the latter problem. The patch changes the
implementation of !keyword_grammar to be much more like !
keyword_class, which has had more recent attention. If this patch is
applied, I recommend that somebody do the analogous work for !
keyword_role too.
guts.pir | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
grammar_namespace.patch
Description: Binary data
Re: [perl #60678] Configure.pl manifest problem on Win32
Will Coleda wrote: > On Thu, Nov 20, 2008 at 4:12 PM, Will Coleda <[EMAIL PROTECTED]> wrote: >> On Thu, Nov 20, 2008 at 3:45 PM, Peter Schwenn <[EMAIL PROTECTED]> wrote: >>> Will Coleda >>> >>> You can drop this thread if you like. This is a waste of your time. What I >>> need to do is to find someone who is building parrot with XP, Cygwin or >>> mingw -- who has been through most of what I'm going to encounter. >> I often build with Strawberry Perl's toolkit on windows with no >> problem, and we have several active windows developers; I tend to >> build right out of the repository, though, and not off the releases. >> >> At first blush it sounds like the filenames got case-mangled when the >> package was unzipped. How did you unpack the file? >> >> -- >> Will "Coke" Coleda >> > > As a data point, I just grabbed parrot-0.8.1-tar.gz from CPAN and was > able to run Configure.pl with no issues using a recent Strawberry > perl. I'm not seeing the case mangled filenames; they match up with > what's in the MANIFEST for me. > > Regards. I second Will's examination. trunk and the 0.8.1 release tarball Configure just fine for me as well. That's Windows XP SP3, Perl 5.10 and VC++ 9. Ron
Re: [perl #60674] sign($x) always returns 1 when $x ~~ Complex
On Thu, Nov 20, 2008 at 4:25 PM, Wolfgang Laun <[EMAIL PROTECTED]> wrote: > So, calling sqrt with a real < 0, should not come back with a complex > number. Again, I think this should depend on context. In Perl5, simply use'ing "Math::Complex" changes the behavior of sqrt such that sqrt(-1) returns i. That fits with the fact that 1/2 returns 0.5, and not zero (unlike certain other languages); I don't have to coerce one of the operands to a float to get a float result. I want to keep that sort of DWIMmishness - if I'm computing with complex numbers, reals should be autopromoted without my having to convert them manually. So simply making sqrt a multi doesn't quite suffice. > Calling sqrt with a complex z where Re(z) < 0 and Im(z)=0 should return a > complex number. Agreed. (Side topic: what about autodemotion? Should calling sqrt with a complex z where Re(z) >= 0 and Im(z) = 0 return a complex or a real?) > Calling sgn() with a complex - why not give me what I'm (obviously) asking > for? My only objection to that behavior was that I want to avoid surprise interactions; a lot of code assumes that sgn() can only return one of three values. As long as it's sufficiently unlikely that a Complex will show up when the programmer isn't expecting it, I'm fine with just having sgn() return 0 for 0 and z/abs(z) for everything else. -- Mark J. Reed <[EMAIL PROTECTED]>
S16: chown, chmod
Reading S16, I was struck by the lack of abstraction over the
underlying Unix API for chown and chmod. Nothing wrong with having the
existing functions lying about in a module that people can "use Unix"
for; but I do feel that the variants in the global namespace should be
more user-friendly.
chown, for example, accepts uid and gid only as integers, -1 meaning
"don't change". To my mind, perl6 should have a variant of chown
strings for uid and gid (and lookup the integers automatically). And
it should accept "undef" as a synonym for "-1".
BTW, the Synopsis fails to define the return value of chown (except
that it's an integer). The underlying Unix API returns success/error
status: The p6 wrapper should be defined to return the appropriate
Failure object (so that { use fatal } will work).
A similar situation exists for "chmod", except it is harder to fix.
The fact that it needs a discussion of "don't say 0644" has a pungent
aroma. A list of integers might solve that. Or perhaps something with
named args: { chmod :u(6), :g(4), :o(4) <== @files }.
But this still isn't as flexible (nor readable) as a Unix command
line. The command line allows you to say "add execute permission"
without specifying any of the other bits. A bunch of methods might the
the right approach, but that would fall foul of the same issue that
filetest operators have: Do we really want to add all these methods to
the Str class?
The return value of chmod is defined, in the synopsis, as the number
of files modified. The underlying Unix API returns success/fail. As
with chown, I feel that we should return a Failure object to represent
failures.
One final point is that not all systems use the Unix security model.
The primary P6 abstraction should probably reflect that fact. The
synopsis does make brief mention of "use filetest" from P5 for
interacting with ACLs, but then punts to the P5 definition/
implementation.
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 08:44:51AM -0800, dpuu wrote: : Reading S16, I was struck by the lack of abstraction over the : underlying Unix API for chown and chmod. Nothing wrong with having the : existing functions lying about in a module that people can "use Unix" : for; but I do feel that the variants in the global namespace should be : more user-friendly. Please feel free to whack on the spec; it's in the pugs repo for that reason. (In fact, we're moving all the specs to the pugs repo so that people can fix things that need fixing without excess interaction with document "owners".) Currently, it's called IO.pod, but it'll probably end up somewhere else in the dir structure with a more S16-io-ish name. Larry
Re: S16: chown, chmod
On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
> Please feel free to whack on the spec
OK, working on it.
Question: is it appropriate to P6 look&feel to have methods on
functions?
The definition of C includes the statement that it's not
available on most system unless you're superuser; and this can be
checked using a POSIX incantation. I was wondering if it would be
reasonable to provide this as a method on the chown function, so that
a user could say:
if &chown.is_restricted {
...
}
else {
chown $user, $group <== @files
}
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 09:57:30AM -0800, dpuu wrote:
: On Nov 21, 9:16 am, [EMAIL PROTECTED] (Larry Wall) wrote:
: > Please feel free to whack on the spec
:
: OK, working on it.
:
: Question: is it appropriate to P6 look&feel to have methods on
: functions?
:
: The definition of C includes the statement that it's not
: available on most system unless you're superuser; and this can be
: checked using a POSIX incantation. I was wondering if it would be
: reasonable to provide this as a method on the chown function, so that
: a user could say:
:
: if &chown.is_restricted {
: ...
: }
: else {
: chown $user, $group <== @files
: }
On security issues where you often can't really determine in advance
whether something will work without trying it, I'd tend to lean more
towards throwing an exception and letting the user trap it, rather
than introducing more interface. But that's just a general guideline.
To answer your actual question, yes, there can certainly be methods
on code objects. But it's not clear to what extent this is a problem
for set theory to get involved with, unless the kernel knows your
set theory and agrees with you. :)
Another problem with the "can I do this" ask-in-advance approach
is that it opens you up to race conditions, though in this case
it's unlikely (but possible) that another thread would change your
superuser status in between.
Larry
Re: S16: chown, chmod
dpuu wrote:
> Question: is it appropriate to P6 look&feel to have methods on
> functions?
I don't think that's such a good idea in this case. If a file is
chown'able is not a property of the chown function, but of the file.
> The definition of C includes the statement that it's not
> available on most system unless you're superuser; and this can be
> checked using a POSIX incantation. I was wondering if it would be
> reasonable to provide this as a method on the chown function, so that
> a user could say:
>
> if &chown.is_restricted {
> ...
> }
> else {
> chown $user, $group <== @files
> }
I'd rather go with the "try it and fail() if you can't" approach, partly
because of race conditions, partly because it's much more reliable in
the presence of extended security models (think of SeLinux for example).
If 'use fatal' is in effect, that dies, if not, you can check the return
value.
For chmod() I could imagine an interface like this:
$file.chmod(:8<540>);
$file.chmod( :set, :user => :r & :x, :group => :r)
# both same as 'chmod 540 $file'
$file.chmod( :modifiy, :other => :!x)
# same as 'chmod o-x $file'
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote: : For chmod() I could imagine an interface like this: : : $file.chmod(:8<540>); : $file.chmod( :set, :user => :r & :x, :group => :r) :# both same as 'chmod 540 $file' : : $file.chmod( :modifiy, :other => :!x) :# same as 'chmod o-x $file' A pair on the left side of => could be construed as a design smell. And I wonder if the set/modify distinction can be better mapped onto assignops somehow... Larry
Re: S16: chown, chmod
Larry Wall wrote: > On Fri, Nov 21, 2008 at 07:30:08PM +0100, Moritz Lenz wrote: > : For chmod() I could imagine an interface like this: > : > : $file.chmod(:8<540>); > : $file.chmod( :set, :user => :r & :x, :group => :r) > :# both same as 'chmod 540 $file' > : > : $file.chmod( :modifiy, :other => :!x) > :# same as 'chmod o-x $file' > > A pair on the left side of => could be construed as a design smell. oops, I menat 'user => :r' instead of ':user => :r'. I should take the warning serious that 'sudo' prints out the first time you use it ;-) > And I wonder if the set/modify distinction can be better mapped onto > assignops somehow... maybe as hash slices? $file.perms = 1, 0, 1; Still that would become clumsy if you want to change the rights for user, group and other at the same time... Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
multi return values
(Sorry if this dbl-posts, sent it from the wrong account the first time)
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
using:
This is Rakudo Perl 6, revision 32970 built on parrot 0.8.1-devel
for i486-linux-thread-multi.
I get:
Method 'lvalue' not found for invocant of class 'PAST;Stmts'
current instr.: 'parrot;PAST;Compiler;as_post' pc 2924
(src/PAST/Compiler.pir:742)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2060
(src/PAST/Compiler.pir:500)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;pirop' pc 3061
(src/PAST/Compiler.pir:796)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2408
(src/PAST/Compiler.pir:614)
called from Sub 'parrot;PCT;HLLCompiler;compile' pc 434
(src/PCT/HLLCompiler.pir:303)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 868
(src/PCT/HLLCompiler.pir:502)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1233
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1412
(src/PCT/HLLCompiler.pir:765)
called from Sub 'parrot;Perl6;Compiler;main' pc 16160 (perl6.pir:168)
Re: multi return values
Andy Colson wrote:
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
Nothing that I can see.
using:
This is Rakudo Perl 6, revision 32970 built on parrot 0.8.1-devel
for i486-linux-thread-multi.
I get:
Method 'lvalue' not found for invocant of class 'PAST;Stmts'
Yes - while the code is fine, it uses list assignment, which we don't
currently support in Rakudo. Hopefully it won't be too long until that's
in place.
Thanks,
Jonathan
Re: multi return values
Andy Colson wrote:
> (Sorry if this dbl-posts, sent it from the wrong account the first time)
>
> Hi all, what's wrong with this code:
>
> use v6;
>
> sub multireturn($x, $y)
> {
> my $a = $x * 2;
> my $b = $y * 2;
> return($a, $b);
> }
>
> my($a, $b) = multireturn(2, 3);
There's (nearly) nothing wrong with your code, only with the compiler ;-)
Rakudo doesn't support list assignment yet (that's where the error
message comes from), and doesn't support returning values either.
A workaround for now is to use arrays instead.
(The thing that's still wrong with your code is that you need a
whitespace after the 'my', otherwise my(...) should be parsed as a
function call).
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: multi return values
Moritz Lenz wrote:
Andy Colson wrote:
(Sorry if this dbl-posts, sent it from the wrong account the first time)
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
There's (nearly) nothing wrong with your code, only with the compiler ;-)
Rakudo doesn't support list assignment yet (that's where the error
message comes from), and doesn't support returning values either.
A workaround for now is to use arrays instead.
You mean like:
my @list = multireturn(2, 3);
That still doesn't work. But its not a big deal... I was just playing
around trying to learn the language.
(The thing that's still wrong with your code is that you need a
whitespace after the 'my', otherwise my(...) should be parsed as a
function call).
OH! Good call, I'd forgotten about that. That's going to take some
getting used to. I assume it'll error out and say "method my not found?"
Thanks all,
-Andy
Re: S16: chown, chmod
before I attempt to change the POD, would this wording be appropriate?
=item chown
our multi chown (Int $uid, Int $gid, Str|IO [EMAIL PROTECTED])
our multi chown (Str $user, Str $group, Str|IO [EMAIL PROTECTED])
Changes the owner (and/or group) of a list of files. The new
ownership can be specified either as integers or as strings.
If an argument is either a negative integer or undefined then
the ownership (or group membership) of the files will be
unchanged.
A True value will be returned if the operation succeeds,
otherwise the function will C.
The list of files may contain strings and/or filehandles.
Strings are interpretted as filenames. On systems that don't
support C the use of file handles will result in
failure
When $user or $group are passed as strings, the implementation
will convert this name to the underlying uid/gid using a
function such as getpwnam.
On most systems, you are not allowed to change the ownership of
the file unless you?re the superuser, although you should be
able to change the group to any of your secondary groups. On
insecure systems, these restrictions may be relaxed, but this
is not a portable assumption. On POSIX systems, you can detect
this condition this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
=item chmod
our multi chmod( Int $mode, Str|IO [EMAIL PROTECTED] );
our multi chmod( PermissionModifier :$user?, PermissionModifier :
$group?, PermissionModifier :$other?, Str|IO [EMAIL PROTECTED] );
class PermissionModifier {
submethod BUILD ( Bool :$r, Bool :$w, Bool :$x );
...
};
Changes the permissions of a list of files. Returns a true value if
the operation is sucessful on all the files, otherwise C.
The files to modify can be given either as Strings, or FileHandles.
The permissions can be provided as either a single integer,
corresponding
to the underlying Unix permissions mode value, or as named options
using PermissionModifier objects.
A PermissionModifier object is constructed using options similar
to filetest operators. :r, :w and :x (and their inverted forms).
If a given option is not included in the object that the corresponding
permission mode of the file(s) will not be changed.
Examples:
chmod 0o755, @executables;
$mode = '0644'; chmod $mode, 'foo';# !!! sets mode to --
wr-T
$mode = '0o644'; chmod $mode, 'foo'; # this is better
$mode = 0o644; chmod $mode, 'foo'; # this is best
@executables ==> chmod :user( :x ),# users can execute
these
:group( :x ), # as can group members
:other( :!x :!r :!w ); # but non-group members
cannot
Re: multi return values
Andy Colson wrote:
> Moritz Lenz wrote:
>> Andy Colson wrote:
>>> (Sorry if this dbl-posts, sent it from the wrong account the first time)
>>>
>>> Hi all, what's wrong with this code:
>>>
>>> use v6;
>>>
>>> sub multireturn($x, $y)
>>> {
>>> my $a = $x * 2;
>>> my $b = $y * 2;
>>> return($a, $b);
>>> }
>>>
>>> my($a, $b) = multireturn(2, 3);
>>
>> There's (nearly) nothing wrong with your code, only with the compiler ;-)
>>
>> Rakudo doesn't support list assignment yet (that's where the error
>> message comes from), and doesn't support returning values either.
>>
>> A workaround for now is to use arrays instead.
>
> You mean like:
>
> my @list = multireturn(2, 3);
That, and make multireturn return an array, not a list.
> That still doesn't work. But its not a big deal... I was just playing
> around trying to learn the language.
>
>>
>> (The thing that's still wrong with your code is that you need a
>> whitespace after the 'my', otherwise my(...) should be parsed as a
>> function call).
>
> OH! Good call, I'd forgotten about that. That's going to take some
> getting used to. I assume it'll error out and say "method my not found?"
s/method/sub/, but apart from that: yes.
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: Should a closure-in-a-string get the placeholder parameters from its surroundings?
TSa (>):
> I just want to make sure that I got the problem right. Would
>
> my $cl = { "$^name upcased becomes {$^OUTER::name.uc}" };
> say $cl("larry")
>
> work? The idea is that the embedded closure refers to the strings
> $^name. And now the dwimmyness shall make that implicit, right?
I guess that should work. I'm not sure how OUTER:: works together with
the hat twigil, but it has all the hallmarks of avoiding the problem,
yes.
// Carl
Re: multi return values
On Fri, Nov 21, 2008 at 08:16:21PM +0100, Moritz Lenz wrote: > Andy Colson wrote: > (The thing that's still wrong with your code is that you need a > whitespace after the 'my', otherwise my(...) should be parsed as a > function call). Also this, I think: > > return($a, $b); -ryan
Re: Should a closure-in-a-string get the placeholder parameters from its surroundings?
On Fri, Nov 21, 2008 at 09:42:41AM +0100, TSa wrote:
> HaloO,
>
> Carl Mäsak wrote:
>> I expected this to DWIM today:
>>
>> $ perl6 -e 'my $cl = { "$^name upcased becomes {$^name.uc}" }; say
>> $cl("larry")'
>>
>> ...but it doesn't in Rakudo r32938:
>>
>> too few arguments passed (0) - 1 params expected
>>
>> ...and for understandable (if not good) reasons: the closure inside
>> the string expects a parameter ($^name), which it isn't getting.
>
> I just want to make sure that I got the problem right. Would
>
>my $cl = { "$^name upcased becomes {$^OUTER::name.uc}" };
>say $cl("larry")
>
> work? The idea is that the embedded closure refers to the strings
> $^name. And now the dwimmyness shall make that implicit, right?
That seems a bit odd to me, but if $^name merely causes a signature
to be generated that declares $name as a (lexically scope) parameter,
then it's just:
my $cl = { "$^name upcased becomes {$name.uc}" };
But perhaps for clarity you would just write:
my $cl = { "$^name upcased becomes $^name.uc()" };
Larry
Re: multi return values
Ryan (>), Moritz (>>), Andy (>>>): >> (The thing that's still wrong with your code is that you need a >> whitespace after the 'my', otherwise my(...) should be parsed as a >> function call). > > Also this, I think: > >> > return($a, $b); ...except that that _is_ a function call. // Carl
Re: S16: chown, chmod
On Fri, Nov 21, 2008 at 11:46:48AM -0800, dpuu wrote:
: before I attempt to change the POD, would this wording be appropriate?
It's a good first whack, though we might want to think about making
it a little less P5ish/Unixish in changing a list of files, and rely
instead of one of P6's distribution mechanisms, such as hypers or maps:
my @status = @files».io».chmod($mode);
my @status = map { .io.chmod($mode) }, @files;
my @status = (for @files { .io.chmod($mode) });
The advantage of this approach is that you don't get complete failure
if only one of the files failed to change. Any you could even do it
in parallel:
my @status = hyper map { .io.chmod($mode) }, @files
though it's possible your sysadmin will complain about what you're
doing with the disk drive heads. :)
Of course, along with the methods we could also provide the old-fashioned
functions so that someone can write a FAQ telling people not to use them. :)
It's also possible that «*.c *.h».io.chmod($mode) should do something
dwimmy, given «...» is defined as "shell quoting". And maybe IO
objects themselves can track multiple files, similar to how we can
turn @*ARGS into a single abstract file handle.
Larry
[svn:perl6-synopsis] r14607 - doc/trunk/design/syn
Author: larry Date: Fri Nov 21 15:16:01 2008 New Revision: 14607 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S06.pod Log: various clarifications Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podFri Nov 21 15:16:01 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 7 Nov 2008 + Last Modified: 19 Nov 2008 Number: 2 - Version: 142 + Version: 143 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -911,6 +911,16 @@ Capture Function call arguments (right-hand side of a binding) BlobAn undifferentiated mass of bits +Insofar as Lists are lazy, they're really only partially immutable, in +the sense that the past is fixed but the future is not. The portion of +a List yet to be determined by iterators may depend on mutable values. +When an iterator is called upon to iterate and extend the known part +of the list, some number of immutable values (which includes immutable +references to mutable objects) are decided and locked in at that point. +Iterators may have several different ways of iterating depending on +the degree of laziness/eagerness desired in context. The iterator +API is described in S07. + =head2 Mutable types Objects with these types have distinct C<.WHICH> values that do not change @@ -3226,7 +3236,7 @@ string buf Str ~ There are also various container contexts that require particular kinds of -containers. +containers (such as slice and hash context; see S03 for details). =item * Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Nov 21 15:16:01 2008 @@ -13,9 +13,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 21 Mar 2003 - Last Modified: 14 Oct 2008 + Last Modified: 21 Nov 2008 Number: 6 - Version: 96 + Version: 97 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1530,6 +1530,12 @@ Placeholders may also be used in method bodies that have no formal signature. +Since the placeholder declares a parameter variable without the twigil, +the twigil is needed only on the first occurence of the variable within +the block. Subsequent mentions of that variable may omit the twigil. +Within an internal nested block the twigil I be omitted, since +it would wrongly attach to the inner block. + =head1 Properties and traits Compile-time properties are called "traits". The
[svn:perl6-synopsis] r14608 - doc/trunk/design/syn
Author: larry Date: Fri Nov 21 15:40:52 2008 New Revision: 14608 Modified: doc/trunk/design/syn/S06.pod Log: typo Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Nov 21 15:40:52 2008 @@ -1531,7 +1531,7 @@ Placeholders may also be used in method bodies that have no formal signature. Since the placeholder declares a parameter variable without the twigil, -the twigil is needed only on the first occurence of the variable within +the twigil is needed only on the first occurrence of the variable within the block. Subsequent mentions of that variable may omit the twigil. Within an internal nested block the twigil I be omitted, since it would wrongly attach to the inner block.
multi return values
Hi all, what's wrong with this code:
use v6;
sub multireturn($x, $y)
{
my $a = $x * 2;
my $b = $y * 2;
return($a, $b);
}
my($a, $b) = multireturn(2, 3);
using:
This is Rakudo Perl 6, revision 32970 built on parrot 0.8.1-devel
for i486-linux-thread-multi.
I get:
Method 'lvalue' not found for invocant of class 'PAST;Stmts'
current instr.: 'parrot;PAST;Compiler;as_post' pc 2924
(src/PAST/Compiler.pir:742)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2060
(src/PAST/Compiler.pir:500)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;pirop' pc 3061
(src/PAST/Compiler.pir:796)
called from Sub 'parrot;PAST;Compiler;post_children' pc 1783
(src/PAST/Compiler.pir:368)
called from Sub 'parrot;PAST;Compiler;as_post' pc 2408
(src/PAST/Compiler.pir:614)
called from Sub 'parrot;PCT;HLLCompiler;compile' pc 434
(src/PCT/HLLCompiler.pir:303)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 868
(src/PCT/HLLCompiler.pir:502)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1233
(src/PCT/HLLCompiler.pir:676)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1412
(src/PCT/HLLCompiler.pir:765)
called from Sub 'parrot;Perl6;Compiler;main' pc 16160 (perl6.pir:168)
Re: S16: chown, chmod
The restriction of chown to the superuser is a property of the OS, not the
files. The example from the pod is:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
my $can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
Thinking about it, perhaps that means that it's a method on $*OS.
The use of filetest operators as a way to specify the desired chmod modes
seems good, but I'm not sure how to specify the signature. I can imagine:
our multi chmod ( Int $mode, [EMAIL PROTECTED] );
our multi chmod ( PermissionModifier :$owner,
PermissionModifier :$group,
PermissionModifier :$other,
[EMAIL PROTECTED]);
but I'm not sure how to define that a PermissionModifer object can be created
as a chain of positive and negative options so that these would work:
@exe_files ==> chmod :owner( :x ), :group( :x ), :other( :!x );
@my_files ==> chmod :owner( :r :w ), :group( :r :!w ), :other( :!r :!w );
There would be a little less line-noise if these could be passed as:
@my_files ==> chmod :owner :group :other;
From: Moritz Lenz <[EMAIL PROTECTED]>
To: dpuu <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Sent: Friday, November 21, 2008 10:30:08 AM
Subject: Re: S16: chown, chmod
dpuu wrote:
> Question: is it appropriate to P6 look&feel to have methods on
> functions?
I don't think that's such a good idea in this case. If a file is
chown'able is not a property of the chown function, but of the file.
> The definition of C includes the statement that it's not
> available on most system unless you're superuser; and this can be
> checked using a POSIX incantation. I was wondering if it would be
> reasonable to provide this as a method on the chown function, so that
> a user could say:
>
> if &chown.is_restricted {
> ...
> }
> else {
> chown $user, $group <== @files
> }
I'd rather go with the "try it and fail() if you can't" approach, partly
because of race conditions, partly because it's much more reliable in
the presence of extended security models (think of SeLinux for example).
If 'use fatal' is in effect, that dies, if not, you can check the return
value.
For chmod() I could imagine an interface like this:
$file.chmod(:8<540>);
$file.chmod( :set, :user => :r & :x, :group => :r)
# both same as 'chmod 540 $file'
$file.chmod( :modifiy, :other => :!x)
# same as 'chmod o-x $file'
Cheers,
Moritz
--
Moritz Lenz
http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: S16: chown, chmod
Larry Wall wrote: On Fri, Nov 21, 2008 at 11:46:48AM -0800, dpuu wrote: : before I attempt to change the POD, would this wording be appropriate? It's a good first whack, though we might want to think about making it a little less P5ish/Unixish in changing a list of files, and rely instead of one of P6's distribution mechanisms, such as hypers or maps: my @status = @files».io».chmod($mode); > [...] I think that can be accomplished by adding corresponding methods to the IO class. I don't have write permissions for the pugs repository, so I've attached the file, including the addition of chmod and chown methods to the IO class. =encoding utf8 =head1 Title DRAFT: Synopsis 16: IPC / IO / Signals =head1 Version Author:Largely, the authors of the related Perl 5 docs. Maintainer:Larry Wall <[EMAIL PROTECTED]> Contributions: Mark Stosberg <[EMAIL PROTECTED]> Date: 12 Sep 2006 Last Modified: 1 May 2007 Version: 17 This is a draft document. Many of these functions will work as in Perl 5, except we're trying to rationalize everything into packages. For now you can assume most of the important functions will automatically be in the * namespace. However, with IO operations in particular, many of them are really methods on an IO handle, and if there is a corresponding global function, it's merely an exported version of the method. As a starting point, you can help by finding the official Perl 5 documentation for these functions and copying it here. =head1 Filehandles, files, and directories =over 4 =item IO ~~ :X X<:r>X<:w>X<:x>X<:o>X<:R>X<:W>X<:X>X<:O>X<:e>X<:z>X<:s>X<:f>X<:d>X<:l>X<:p> X<:S>X<:b>X<:c>X<:t>X<:u>X<:g>X<:k>X<:T>X<:B>X<:M>X<:A>X<:C> =item EXPR ~~ :X $file.:X $file ~~ :X A file test, where X is one of the letters listed below. This unary operator takes one argument, either a filename or a filehandle, and tests the associated file to see if something is true about it. A Pair used as a pattern is treated as a file test. :r File is readable by effective uid/gid. :w File is writable by effective uid/gid. :x File is executable by effective uid/gid. :o File is owned by effective uid. :R File is readable by real uid/gid. :W File is writable by real uid/gid. :X File is executable by real uid/gid. :O File is owned by real uid. :e File exists. :z File has zero size (is empty). :s File has nonzero size (returns size in bytes). :f File is a plain file. :d File is a directory. :l File is a symbolic link. :p File is a named pipe (FIFO), or Filehandle is a pipe. :S File is a socket. :b File is a block special file. :c File is a character special file. :t Filehandle is opened to a tty. :u File has setuid bit set. :g File has setgid bit set. :k File has sticky bit set. :T File is an ASCII text file (heuristic guess). :B File is a "binary" file (opposite of :T). :M Script start time minus file modification time, in days. :A Same for access time. :C Same for inode change time (Unix, may differ for other platforms) The interpretation of the file permission operators C<:r>, C<:R>, C<:w>, C<:W>, C<:x>, and C<:X> is by default based solely on the mode of the file and the uids and gids of the user. There may be other reasons you can't actually read, write, or execute the file. Such reasons may be for example network filesystem access controls, ACLs (access control lists), read-only filesystems, and unrecognized executable formats. Also note that, for the superuser on the local filesystems, the C<:r>, C<:R>, C<:w>, and C<:W> tests always return 1, and C<:x> and C<:X> return 1 if any execute bit is set in the mode. Scripts run by the superuser may thus need to do a stat() to determine the actual mode of the file, or temporarily set their effective uid to something else. If you are using ACLs, there is a pragma called C that may produce more accurate results than the bare stat() mode bits. When under the C the above-mentioned filetests will test whether the permission can (not) be granted using the access() family of system calls. Also note that the C<:x> and C<:X> may under this pragma return true even if there are no execute permission bits set (nor any extra execute permission ACLs). This strangeness is due to the underlying system calls' definitions. Read the documentation for the C pragma for more information. The C<:T> and C<:B> switches work as follows. The first block or so of the file is examined for odd characters such as strange control codes or characters with the high bit set. If too many strange characters (>30%) are found, it's a C<:B> file; otherwise it's a C<:T> file. Also, any file containing null in the first block is considered a binary file. If C<:T> or C<:B> is used on a filehandle, the current IO buffer is examined rather than the first block. Both C<:T> and C<:B> return true on a null f
bytes, lazy strings and zlib
In my ongoing quest to create a PDF parser in Perl6, I have some Rakudo/PGE/parrot questions. These are low-urgency and some of these may not be implemented yet... 1) byte orientation PDF's syntax is inherently an 8-bit ASCII superset. Some subsections may be interpreted as some multi-byte encoding or even binary, but low-level parsers can safely work solely in the string-as-byte-array domain. How do I make a grammar work on bytes instead of chars? Is that a property of the $.target string? 2) file as lazy string PDF files are largely random access, but individual segments have arbitrary lengths. Rather than slurping in the whole file or guessing at segment lengths, I'd like to emulate a string via a wrapper around a seekable file, and then apply my grammar to that fake string. I think I can accomplish this by subclassing PGE::Match and override new(), text() and item() appropriately. text() would seek to appropriate locations in the file and buffer chunks at a time. From there, I could substr the desired passages. Does anyone know any implementation details that would make this lazy- string approach work or not work? Has someone tried this? It seems like the runtime/parrot/library/Stream classes parallel what I want to accomplish. 3) gzip Has anyone worked on a zlib interface? Thanks, Chris
[perl #60732] Hash indexes shouldn't work on array refs
# New Ticket Created by Moritz Lenz # Please include the string: [perl #60732] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=60732 > >From #perl6 today: 19:33 < moritz_> rakudo: my $x = [ 42 ]; say $x<0> 19:33 < p6eval> rakudo 32984: OUTPUT[42] I don't think that should be allowed. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
[perl #60734] [TODO] $^foo variable should also declare corresponding $foo variable
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #60734]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60734 >
This should output "dito" twice:
$ ./perl6 -e '{ say $^same; say $same }.("dito")'
Scope not found for PAST::Var '$same'
...but it doesn't in Rakudo r32290.
Re: [perl #60732] Hash indexes shouldn't work on array refs
On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Moritz Lenz > # Please include the string: [perl #60732] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=60732 > > > > From #perl6 today: > > 19:33 < moritz_> rakudo: my $x = [ 42 ]; say $x<0> > 19:33 < p6eval> rakudo 32984: OUTPUT[42] > > I don't think that should be allowed. > the real test is: (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x<0_but_true>; (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $x; (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $x; (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x; (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x<1.4>; (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x<0.4>; (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] so, the index is coerced to an integer. is that really wrong? ~jerry
