Files, Directories, Resources, Operating Systems
The S16: chown, chmod thread seems to be too unix-focussed. Perl6 is being born in a world dominated by the internet. Whilst perl was the glue for the internet when the internet was born, it was a unix child. I learned perl from a Windows perspective and I found the discussion of ownership and file tests odd. Moreover, there were things I wanted to do with perl that seemed unduly cumbersome in Windows because the paradigm perl used was a unix one, but adapted to Windows. To be portable, the minimum assumptions need to be made about the environment in which a program operates. Alternatively, the software needs to be able to determine whether the environment it is operating in meets a minimum set of conditions. Where software is written for a specific environment, the developer already knows more about the environment. Thus I would suggest that the perl6 specifications should be written in an abstract way, one not related to a specific operating system and in a way that can be adapted by an implementor to specific systems. Following the general perl6 philosophy, perhaps too there should be an abstract definition for the language that is core and additional modules that are specific to operating systems. Thus when generic software is distributed, it comes with an installer that determines the operating system chooses whether to use IO::Unix, IO::Unix::Gnome, IO::MS::WindowsXP, IO::MS::Vista, IO::Apple, etc. Maybe also IO::Internet::Http, IO::Internet::Ftp? Thus, questions concerning ownership, chown, etc would be left to modules. Modules for specific systems would make it easy to deal naturally with those systems. Software written specifically for one OS would explicitly use the appropriate module, and hence would be able to rely on constructs natural for that system. The interesting questions then would be what abstract concepts should be core to perl6 and which ones should be left to Do we continue to talk about a file, or do we talk about a resource or datastream? When considering internet resources, the concept of trust is more important than the concept of ownership. It would seem to me that a program should be aware of the continuing ability of the datastream to operate, viz., supply / accept data, so that a program doesnt hang waiting for data from a source that has been disconnected.
Re: Files, Directories, Resources, Operating Systems
Richard Hainsworth wrote in perl.perl6.language : The S16: chown, chmod thread seems to be too unix-focussed. I was more or less thinking that the syscall-related primitives, like chown or chmod, could go in a POSIX namespace. Even in UNIX land nowadays the situation can be much more complex than traditional ownership and modes (a situation not entirely satisfactorily addressed by Perl 5's filetest pragma). Following the general perl6 philosophy, perhaps too there should be an abstract definition for the language that is core and additional modules that are specific to operating systems. Thus when generic software is distributed, it comes with an installer that determines the operating system chooses whether to use IO::Unix, IO::Unix::Gnome, IO::MS::WindowsXP, IO::MS::Vista, IO::Apple, etc. Maybe also IO::Internet::Http, IO::Internet::Ftp? IO (streams) and rights are not naturally related. Maybe you're thinking about filesystems and other content addressing schemes (like URLs). The subject is more complex than it seems at first glance, because you can have, for example, per-volume current working directories. It's quite hard to design something that is abstract enough, but at the same time not totally useless.
Re: Files, Directories, Resources, Operating Systems
* Richard Hainsworth ([EMAIL PROTECTED]) [081126 08:21]:
The S16: chown, chmod thread seems to be too unix-focussed.
To be portable, the minimum assumptions need to be made about the
environment in which a program operates. Alternatively, the software
needs to be able to determine whether the environment it is operating in
meets a minimum set of conditions.
...
Thus I would suggest that the perl6 specifications should be written in
an abstract way, one not related to a specific operating system and in a
way that can be adapted by an implementor to specific systems.
I fully agree with you: the way the design is going is making the same
mistakes of Perl5 again. Where we were able to release the Perl5
syntax more and more when the design of Perl6 made more progress, so
should we do with the way we use modules. S16 is not doing that.
Also Rafael's suggestion to focus on POSIX is not the way a nice
interface should work. POSIX calls (and non-POSIX means) are
ways to implement the interface to the Operating System, which can
be different from the most practical interface on implementation level.
We should focus on OS abstraction.
For instance, if a file is represented in an object, then the most
friendly interface names would be like:
$file-owner($user);
my $user = $file-owner;
under the hood, we use chown and stat.
I really would like to see a standard object oriented view on the
system, which mainly autodetects the environment. I am really
fed-up using File::Spec and Path::Class explicitly all the time.
Also, I get data from a CD which was written case-insensitive and then
copied to my Linux box. It would be nice to be able to say: treat this
directory case insensitive (even when the implementation is slow)
Shared with Windows default behavioral interface.
So, I would like a radical change... trying to be as much general
(non UNIX specific) as possible:
(sorry, my Perl6 syntax is still very sloppy)
some global $*OS
# may be different per parallel instance of the program
# Maybe an OS function which returns $*OS
my $dir = $*OS.dir($*PROGRAM.arg[0]);
# above maybe hidden with a functional wrappers: dir $argv[0]
$dir.case_sensitive(0);
if $dir.entry('xyz').is_file {}
my $f = $dir.file('xyz');
$f.owner($*OS.user);
$*OS.system('ls | lpr');
print $*OS.family;
print $*OS.kernel_version;
my $pid = $*OS.process.label;
We should also be aware that we design Perl6 for parallelism. Do we
require all nodes to run the same OS (~version)?
Besides, I would really like to get a incremental growth path to do
things we cannot do yet. Some things are currently difficult to realize
under UNIX/Linux because there is not kernel interface defined for it.
For instance, you do not know in which character-set the filename is;
that is file-system dependent. So, we treat filenames as raw bytes.
This does cause dangers (a UTF-8 codepoint in the filename with a \x2F
('/') byte in it, for instance) But as long as the OS cannot provide
the user with this information, we should still give the author a way
to specify it.
$*OS.filesystem('/home', type = 'xfs', name_encoding = 'latin1'
, text_content_encoding = 'utf-8,bom', illegal_chars = /\x0
, case_sensitive = 1, max_path = 1024);
I have been working on such a module for Perl5 (which has a much wider
field than Path::Class) but (as many other of my projects) did not
complete it to a usable/publishable level (yet).
It is all NOT too difficult to implement (we do share this knowledge),
but the design of this needs to be free from historical mistakes. That's
a challenge.
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
Re: [perl #60850] r33207: Multiple spectest failures on OS X
- Original Message On Tue Nov 25 23:38:58 2008, [EMAIL PROTECTED] wrote: t/spec/S12-methods/default-trait.t (Wstat: 0 Tests: 6 Failed: 1) Failed test: 2 I'd be especially interested in the test output of this one (or to know if it's no longer failing with latest Rakudo). Since I was just working on that recently, and can't reproduce a failure here. I'll try to get to this later, but after work, I'm heading out with friends. If anyone else has OS X and can reproduce this, that would be fantastic. I won't be home any time soon. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
[perl #59982] [BUG] MMD fail for undef/complex interaction.
On Sun Nov 23 10:33:24 2008, moritz wrote:
On Sat Oct 18 17:15:30 2008, bacek wrote:
Hello.
00:05 bacek
rakudo: my $a; $a = $a + 1i; say $a
00:05 polyglotbot
OUTPUT[Multiple Dispatch: No suitable candidate found for 'add', with
signature 'PPP-P'current instr.: 'infix:+' pc 1941
(src/gen_builtins.pir:1368)called from Sub '_block11' pc 60
(EVAL_12:25)called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864
(src/PCT/HLLCompiler.pir:498)called from Sub
Added test to the test suite in (pugs) r23061,
t/spec/S03-operators/autovivification.t
Fixed in r33214 and test unfudged.
Note on the fix and what I'm guessing general direction may be on such
things. I did it by implementing .Complex (which I believe should exist
as a method on Any), which is what coerces something to Complex. Types
can override this if they want to coerce in their own special way.
I suspect when we write things such as the infix:+ in a Perl 6 prelude
we'll end up writing something like:
multi method infix:+(Complex $a, $b as Complex) { ... }
Which could coerce that second parameter into being a Complex (note that
the Complex method actually returns a Complex, and doesn't modify the
original value).
I believe the Any method would also be exported...
multi method Complex() is export { ... }
So we'll get a sub form too...
Complex(...)
But trying to introduce a sub form right now causes clashes with the
Complex proto-object in the namespace. Ouch. :-( Anyway, that's a wider
issue and not specific to this ticket, so treating as resolved.
Jonathan
[perl #60426] [BUG] Implementation of Enums isn't perfect.
On Sat Nov 08 20:39:00 2008, [EMAIL PROTECTED] wrote: bacek rakudo: enum Fooget_string; polyglotbot OUTPUT[A method named 'get_string' already exists in class ''. It may have been supplied by a role.current instr.: '_block15' pc -339673149 ((unknown file):-1)called from Sub '_block15' pc 169 (EVAL_11:55)called from Sub 'parrot;PCT;HLLCompiler;evalpmc' pc 804 ..(src/PCT/HLLCompiler.pir:468)called from Sub 'parrot;PCT;HLLCompiler;compile' pc 4... bacek rakudo's enums are really bad... Fixed this one in r33217. bacek rakudo: enum Foopick; polyglotbot RESULT[Null PMC access in find_method()current instr.: '_block14' pc 25 (EVAL_15:12)called from Sub 'parrot;PCT;HLLCompiler;eval' pc 866 (src/PCT/HLLCompiler.pir:501)called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1141 (src/PCT/HLLCompiler.pir:631)called from Sub ..'parrot;PCT;HLLCompiler;command_line' pc 1320 (src/PCT/HLLCompiler.pir:72... That one worked when I tired it today, so not sure what it was. Maybe related to the single element enum breakage that was fixed before now. Thanks for reporting, Jonathan
[perl #60854] died when try to instant class with attribute type Range
On Wed Nov 26 04:27:12 2008, ihrd wrote:
Hi!
Rakudo 33212, example:
class R { has Range $.range }
my $r = R.new;
died with:
Null PMC access in clone()
current instr.: 'parrot;Perl6Object;!cloneattr' pc 782
Ah yes, a missing null check. Added in r33218.
Thanks,
Jonathan
[perl #60366] [PATCH] 'does' fails with roles that have '::' in their names
On Wed Nov 05 22:58:18 2008, [EMAIL PROTECTED] wrote:
There are two bugs here. The attached patch fixes bug #2 but not bug
#1.
Bug #1) role A::B is not interpreted as a role, but just as a module.
./perl6 -e 'role A { method foo { say Foo; } }; say A.WHAT'
Role
./perl6 -e 'role A::B { method foo { say Foo; } }; say A::B.WHAT'
Module
Fixed.
Bug #2) applying a role searches for the role in the wrong namespace.
./perl6 -e 'role A::B { method foo { say Foo; } }; class B does
A::B {}; B.new.foo'
Method 'foo' not found for invocant of class 'B'
./perl6 -e 'role A::B { method foo { say Foo; } }; class A::B::C
does A::B {}; A::B::C.new.foo'
Method 'foo' not found for invocant of class 'A;B;C'
Applied your patch with minor simplifications to the code and with my
fix to issue #1, it does indeed resolve this issue.
Both in together as r33215, plus added a few tests.
Thanks!
Jonathan
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 12:40:41PM +0100, Mark Overmeer wrote: We should focus on OS abstraction. [...] the design of this needs to be free from historical mistakes. And avoid making too many new ones. There must be useful prior art around. Java, for example, has a FileSystem abstraction java.nio.file.FileSystem http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileSystem.html which has been extended, based on leasons learnt, in the NIO.2 project (JSR 203: More New I/O APIs for the JavaTM Platform (NIO.2) APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams.) which enables things like being able to transparently treat a zip file as a filesystem: http://blogs.sun.com/rajendrag/entry/zip_file_system_provider_implementation See http://javanio.info/filearea/nioserver/WhatsNewNIO2.pdf Tim. p.s. I didn't know any of that when I started to write this look for prior art email, but a little searching turned up these examples. I'm sure there are more in other realms, but NIO.2 certainly looks like a rich source of good ideas derived from a wide range of experience.
[perl #60796] There's something wrong with creating classes inside block eval
On Mon Nov 24 15:12:48 2008, masak wrote:
masak rakudo: eval { class A { has $.x } }; say A.new(x=5).x
p6eval rakudo 33156: OUTPUT[5Null PMC access in
find_method()current instr.: 'parrot;Perl6;Compiler;main' pc 136910
(src/gen_actions.pir:13693)]
masak it gives the right answer, but then decides to die on some
error! :)
Taking a look at the S04:
(Perl 6's eval function only evaluates strings, not blocks.)
So I think the example is wrong (it sorta worked because classes are
declared at compile time and you're declaring a package class inside
that block; thus, even though we never invoked the block it still ended
up declaring the class; if you'd put a say in there, it wouldn't have
been run.)
So, why the odd error? In the builtins we weren't checking what was
passed to eval to a string. This led to oddness inside eval/the
compiler/somewhere - turns out if you feed in something that ain't a
string it does interesting stuff...but not until exit time! :-)
Anyway, a glance at S29 suggests the signature of eval should be:
multi eval ( Str $code, Grammar :$lang = CALLER::$?PARSER)
That is, we type-check it's a Str rather than coerce. So I've put in a
type check now and your example now gives a parameter type check
failure, which - unless the spec changes to say we should coerce instead
of type check - appears to be the right thing.
(Note: a spectest did do a very curious/useless use of eval, which I
ripped out...)
Thanks,
Jonathan
Re: [perl #59982] [BUG] MMD fail for undef/complex interaction.
On Wed, Nov 26, 2008 at 04:35:41AM -0800, [EMAIL PROTECTED] via RT wrote:
I believe the Any method would also be exported...
multi method Complex() is export { ... }
So we'll get a sub form too...
Complex(...)
But trying to introduce a sub form right now causes clashes with the
Complex proto-object in the namespace. Ouch. :-( Anyway, that's a wider
issue and not specific to this ticket, so treating as resolved.
Actually, coercion is done with postcircumfix:( ) on the type.
See S13.
Pm
[perl #60778] Strange error message in Rakudo on $var .= string
On Mon Nov 24 07:52:42 2008, masak wrote: $ perl6 -c -e 'my $a; $a .= A' Method 'panic' not found for invocant of class 'PGE;Match' I inadvertently wrote this when meaning '~='. It would probably be a good thing to emit a helpful error message in this case. (Unless it's legal Perl 6, which STD doesn't think it is.) Note that Rakudo (r33067) dies here during compilation, trying to find a missing method 'panic'. Aye, and that method panic was being called to give a helpful error message! :-) Fixed things up now (r33221) so we call panic on something that knows how to. Thanks, Jonathan
[perl #60850] r33207: Multiple spectest failures on OS X
Hi! Thanks for testing. :-) On Tue Nov 25 23:38:58 2008, [EMAIL PROTECTED] wrote: t/spec/S12-methods/default-trait.t (Wstat: 0 Tests: 6 Failed: 1) Failed test: 2 I'd be especially interested in the test output of this one (or to know if it's no longer failing with latest Rakudo). Since I was just working on that recently, and can't reproduce a failure here. Thanks, Jonathan
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 12:40 PM, Mark Overmeer [EMAIL PROTECTED] wrote:
Also, I get data from a CD which was written case-insensitive and then
copied to my Linux box. It would be nice to be able to say: treat this
directory case insensitive (even when the implementation is slow)
Shared with Windows default behavioral interface.
That is a task for the operating system, not Perl. You're trying to
solve the problem at the wrong end here IMHO.
For instance, you do not know in which character-set the filename is;
that is file-system dependent. So, we treat filenames as raw bytes.
On native file-system types (like ext3fs), character-set is not
file-system dependent but non-existent. It really is raw bytes.
This does cause dangers (a UTF-8 codepoint in the filename with a \x2F
('/') byte in it, for instance)
A \x2F always means a '/'. UTF-8 was designed to be backwards
compatible like that.
Regards,
Leon Timmermans
Re: Files, Directories, Resources, Operating Systems
* Leon Timmermans ([EMAIL PROTECTED]) [081126 15:43]:
On Wed, Nov 26, 2008 at 12:40 PM, Mark Overmeer [EMAIL PROTECTED] wrote:
That is a task for the operating system, not Perl. You're trying to
solve the problem at the wrong end here IMHO.
In my (and your) case, the operating system is not helping at all
and there is no chance in having that changed. So...
My remark was just one example, and I can give many more, where I
would like to see more abstraction in the OS interface to avoid the
need for each user to re-invent the wheel of interoperability.
For instance, you do not know in which character-set the filename is;
that is file-system dependent. So, we treat filenames as raw bytes.
On native file-system types (like ext3fs), character-set is not
file-system dependent but non-existent. It really is raw bytes.
Not on the presentation level to the user. This makes it even more
horrifying. It depends on the setting of an environment variable
of the actual user how the bytes of the filename are interpreted.
On the OS filesystem implementation you are probably correct (in
the UNIX/Linux case), but programs are used for end-user results.
This does cause dangers (a UTF-8 codepoint in the filename with
a \x2F ('/') byte in it, for instance)
A \x2F always means a '/'. UTF-8 was designed to be backwards
compatible like that.
Yes, you are right on this. ASCII does not suffer from UTF-8, so my
example was flawed. The second 128 does cause problems. How can glob()
sort filenames, for instance? UTF-16 names should not enter the Perl
program unless you are aware of it, because those can hurt badly.
Please comment on the big picture in the debate: there are all kinds
of OS dependent things I really would like to see hidden in a (large)
abstraction layer to simplify the development of portable scripts.
I don't say I know all the answers, but I do feel a lot of pain in
each module for CPAN the same thing again.
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
[perl #60620] @a[1].=subst parsefail
On Mon Nov 17 13:49:03 2008, masak wrote:
Rakudo r32733:
masak rakudo: my @a; @a[0].=subst( '', '')
polyglotbot OUTPUT[PAST::Compiler can't compile a null nodecurrent
instr.:
[...]
Ah, yes, .= was only handling a scalar on the LHS. Thanks to PAST
enhancements since I first implemented .=, it was nice and easy to
refactor it into something that'd do the right thing...
my @a = 'abc'; @a[0] .= subst('b','d'); say @a[0]
adc
my %h = x = 'abc'; %hx .= subst('b','d'); say %hx
adc
Committed in r33225, plus added tests into assign.t.
Thanks,
Jonathan
Re: [perl #60850] r33207: Multiple spectest failures on OS X
- Original Message
From: [EMAIL PROTECTED] via RT [EMAIL PROTECTED]
Thanks for testing. :-)
On Tue Nov 25 23:38:58 2008, [EMAIL PROTECTED] wrote:
t/spec/S12-methods/default-trait.t (Wstat: 0
Tests: 6 Failed: 1)
Failed test: 2
I'd be especially interested in the test output of this one (or to know
if it's no longer failing with latest Rakudo). Since I was just working
on that recently, and can't reproduce a failure here.
t/spec/S12-methods/default-trait.t ..
oh yes
oh yes
oh yes
1..6
ok 1 - 'is default' trait makes otherwise ambigous method dispatch live
not ok 2 - 'is default' trait tie-breaks on method dispatch
ok 3 - 'is default' trait makes otherwise ambigous method dispatch live
ok 4 - 'is default' trait on subs
ok 5 - basic sanity with arity based dispatch and slurpies
ok 6 - is default trait wins against empty slurpy param
Failed 1/6 subtests
Test Summary Report
---
t/spec/S12-methods/default-trait.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 2
Files=1, Tests=6, 1 wallclock secs ( 0.02 usr 0.01 sys + 1.17 cusr 0.08
csys = 1.28 CPU)
Result: FAIL
The failing test:
class Something {
multi method doit(Int $x){ 2 * $x };
multi method doit(Int $x) is default { 3 * $x };
}
my $obj = Something.new();
lives_ok { $obj.doit(3) }, 'is default' trait makes otherwise ambigous
method dispatch live;
is $obj.doit(3), 9, 'is default' trait tie-breaks on method dispatch;
$obj.doit(3) returns 6, not 9.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
[svn:parrot-pdd] r33229 - trunk/docs/pdds/draft
Author: bernhard Date: Wed Nov 26 10:30:07 2008 New Revision: 33229 Modified: trunk/docs/pdds/draft/pdd14_numbers.pod Log: [codingstd] add a VERSION section to PDD 14 Modified: trunk/docs/pdds/draft/pdd14_numbers.pod == --- trunk/docs/pdds/draft/pdd14_numbers.pod (original) +++ trunk/docs/pdds/draft/pdd14_numbers.pod Wed Nov 26 10:30:07 2008 @@ -9,6 +9,10 @@ This PDD describes Parrot's numeric data types. +=head1 VERSION + +$Revision$ + =head1 DESCRIPTION This PDD details the basic numeric datatypes that the Parrot core knows how to
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 11:21:58AM +0300, Richard Hainsworth wrote: The S16: chown, chmod thread seems to be too unix-focussed. Indeed, what you are currently reading in S16 is mostly just lightly edited copy-paste from P5 docs. But the S16 draft is out in the pugs repo for a reason--anyone and everyone on this thread should consider it perfectly okay to take S16 in hand and refactor it mercilessly. Any shortcuts we wish to install into the final Perl 6 can easily be done at the last moment by the prelude aliasing common operations into the core language. Anyway, feel free to coordinate this here and/or on #perl6. (Note that Patrick is in the process of moving all the Synopses to the pugs repo at some point soon, so the current S16 in pugs/docs/Perl6/Spec is likely to have its name/location changed soon.) If you need a pugs commit bit, please ask in #perl6 on irc.freenode.net. Larry
Re: Files, Directories, Resources, Operating Systems
I agree with the idea of making Perl 6's filesystem/etc interface more abstract,
as previously discussed, and also that users should be able to choose between
different levels of abstraction where that makes sense, either picking a more
portable interface versus a more platform-specific one.
Following up on Tim Bunce's comment about looking at prior art, I also recommend
looking at the SQLite DBMS, specifically its virtual file system layer; this one
is designed to give you deterministic behaviour and introspection over a wide
range of storage systems and attributes, both on PCs and on embedded devices, or
hard disks versus flash or write once vs write many etc, where a lot of
otherwise-assumptions are spelled out. One relevant url is
http://sqlite.org/c3ref/vfs.html and for the moment I forget where other good
urls are.
Mark Overmeer wrote:
$dir.case_sensitive(0);
$*OS.filesystem('/home', type = 'xfs', name_encoding = 'latin1'
, text_content_encoding = 'utf-8,bom', illegal_chars = /\x0
, case_sensitive = 1, max_path = 1024);
I understand that the above, concerning case-sensitivity, is just meant to be an
example, but I want to explore that in more detail for a moment, as it reflects
a common perception that only scratches the surface and needs to be fleshed out
more.
To summarize, what we really want is something more generic than
case-sensitivity, which is text normalization and text folding in general, as
well as distinctly dealing with distinctness for representation versus
distinctness for mutual exclusivity.
For example, one file system will represent your chosen case for a filename but
it won't allow 2 files in the same directory whose filenames are non-distinct
when uppercased; another file system in contrast would also represent a filename
uppercased. For another example, one file system will not distinguish between
accents on letters while another would, and this is orthogonal to
case-sensitivity. Or for another, one might treat a run of whitespace as being
equivalent to a single whitespace character, or whitespace characters are
ignored entirely.
Also, the paradigm that is the most distinguishing (case-sensitive,
accent-sensitive, whitespace-sensitive, etc) should be the default, and any
boolean option to change an aspect of this should be named that a false value is
more distinguishing and a true value is less distinguishing. For example, a
flag should be named ignores_case rather than case_sensitive; this also
assumes that if named arguments are optional, then the common default value of a
boolean-typed argument is false. Naming something case_sensitive implies that
sensitivity is special whereas sensitivity should be considered normal, and
rather insensitivity should be considered special.
-- Darren Duncan
[perl #60822] [TODO] lexical subroutines
On Tue Nov 25 13:19:15 2008, moritz wrote:
Rakudo as of r33193 doesn't implement lexical subroutines; neither 'my
sub ...' is implemented nor does 'my $x = sub { ... }' work properly (a
test for the latter can be found in t/spec/integration/man-or-boy.t).
All of:
my $x = sub { ... }
my x = sub { ... }
sub foo(x) { x() }
Now work. Lexical subroutines are still todo.
Jonathan
Re: Files, Directories, Resources, Operating Systems
On Wed, 2008-11-26 at 11:34 -0800, Darren Duncan wrote: I agree with the idea of making Perl 6's filesystem/etc interface more abstract, as previously discussed, and also that users should be able to choose between different levels of abstraction where that makes sense, either picking a more portable interface versus a more platform-specific one. Agreed on both counts. Following up on Tim Bunce's comment about looking at prior art, I also recommend looking at the SQLite DBMS, specifically its virtual file system layer; this one is designed to give you deterministic behaviour and introspection over a wide range of storage systems and attributes, both on PCs and on embedded devices, or hard disks versus flash or write once vs write many etc, where a lot of otherwise-assumptions are spelled out. One relevant url is http://sqlite.org/c3ref/vfs.html and for the moment I forget where other good urls are. There are also higher-level VFS systems, such as Icculus.org PhysicsFS, which goes farther than just abstracting the OS operations. It also abstracts away the differences between archives and real directories, unions multiple directory trees on top of each other, and transparently redirects writes to a different trunk than reads: http://icculus.org/physfs/ I want to be able to support that functionality in a way that still allows me to open and close PhysicsFS files and directories the way I would normally. I want to be able to layer it *under* the standard Perl IO ops, rather than above them. The following is all obvious, but just to keep it in people's minds and frame the discussion: Being able to layer IO abstractions is at least as important as the basic OS abstraction itself -- as well as the ability to use the high level abstraction most of the time, but reach down the stack when needed. This implies making best effort to minimize the ways in which upper layers will be hopelessly confused by low-level operations, and documenting the heck out of the problem areas. These layers should be mix-and-match as much as possible, with abstractions designed with common interfaces. Certainly Perl 5's IO layers, as well as any networking or library stack, are prior art here. To summarize, what we really want is something more generic than case-sensitivity, which is text normalization and text folding in general, as well as distinctly dealing with distinctness for representation versus distinctness for mutual exclusivity. Yes, definitely. [This] implies that sensitivity is special whereas sensitivity should be considered normal, and rather insensitivity should be considered special. If only that were true in other areas of life. :-) -'f
[perl #60380] [TODO] catch modification of read-only arguments
On Sat Nov 08 04:58:36 2008, bacek wrote:
there is attached patch to factor check readonly status to separate
function. Unfortunately I can't add call to '!CHECK_READONLY'
into (prefix|postfix)(++|--) because I'm waiting to resolve #59596 :)
Thanks for the patch. However, it's not really the way to go on these.
The op= cases are meta-operators, and should be equivalent to
infix:=($target, infix:{$op}($target, $arg))
In the (nearer) future I think we'll generate these from the op table
rather than maintaining them all by hand, but in the end the grammar
rules will parse them just as meta-operators and we can emit code like
the above directly. Then the check will fall out of the infix:=.
Thanks,
Jonathan
Re: S16: chown, chmod
* Brandon S. Allbery KF8NH [EMAIL PROTECTED] [2008-11-25 07:25]: OTOH Perl has historically not said much about doing that kind of thing. And I’m not in favour of it starting now. All I am saying is that APIs should be designed to encourage correct designs; arguably this is the spirit of Perl 6, which says TMTOWTDI yet tries to provide one good default way of doing any particular thing. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
[perl #60150] Rakudo can only call non-lexical -sigil subs
On Sun Oct 26 14:26:27 2008, masak wrote: Rakudo r32151 is only able to call -sigil subs if they have not been initialized with my. $ ./perl6 -e 'b = say; b(5)' # works 5 $ ./perl6 -e 'my b = say; b(5)' # fails Lexical 'b' not found [...] This was fixed earlier today, and I've made sure there's a couple of tests too. Thanks, Jonathan
[perl #60718] [PATCH] better error message for .new on undefined class
On Thu Nov 20 20:46:18 2008, [EMAIL PROTECTED] wrote: 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: ... With the attached patch, Rakudo instead dies with a more informative message: ... 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? We should actually detect this at compile time, not runtime. That depends on registering and checking/looking up symbols as we compile, which is on the task list for the next month or so. So thanks for the patch, but I'm afraid it's the wrong approach. I will leave the ticket open, however, as something that needs to happen as a result of the symbol registry stuff. Once we get a useful error message at compile time, it's can be closed. Thanks! Jonathan
Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 5:15 PM, Mark Overmeer [EMAIL PROTECTED] wrote: Yes, you are right on this. ASCII does not suffer from UTF-8, so my example was flawed. The second 128 does cause problems. How can glob() sort filenames, for instance? That's a matter of collation, not (just) character set. TIMTOWTDI. There is no right way to do it as it depends on the circumstances, but a simple binary sort is not a bad default. Leon Timmermans
Synopses moved to pugs svn repository
On Wed, Nov 26, 2008 at 11:18:01AM -0800, Larry Wall wrote: Anyway, feel free to coordinate this here and/or on #perl6. (Note that Patrick is in the process of moving all the Synopses to the pugs repo at some point soon, so the current S16 in pugs/docs/Perl6/Spec is likely to have its name/location changed soon.) If you need a pugs commit bit, please ask in #perl6 on irc.freenode.net. ...and the move is now done. The synopses currently live in docs/Perl6/Spec/ of the pugs svn repository, but we may be moving these to a different location in the repository and/or renaming the files soon. Pm
[perl #60850] r33207: Multiple spectest failures on OS X
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #60850] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60850 I still have out of country guests, so I won't have much follow up time on this. If there's specific help I can give, let me know and I'll see if I can squeeze in some time. Note that if you are using Test::Harness 3.X, you probably need to grab the latest version from Subversion: svn co http://svn.hexten.net/tapx/trunk test_harness Otherwise, the t/spec/S12-classes/declaration-order.t failure will not show up in the summary. I've also attached a the full output of 'make spectest'. Summary of failures: Test Summary Report --- t/spec/S02-literals/quoting.rakudo (Wstat: 256 Tests: 0 Failed: 0) Non-zero exit status: 1 Parse errors: No plan found in TAP output t/spec/S03-operators/increment.rakudo(Wstat: 0 Tests: 41 Failed: 0) TODO passed: 1, 3-4, 6, 8-9, 11-12, 14, 16 t/spec/S12-class/declaration-order.t (Wstat: 6 Tests: 2 Failed: 0) Non-zero wait status: 6 t/spec/S12-methods/default-trait.t (Wstat: 0 Tests: 6 Failed: 1) Failed test: 2 Files=224, Tests=6417, 295 wallclock secs ( 1.68 usr 0.88 sys + 489.80 cusr 24.57 csys = 516.93 CPU) Result: FAIL uname -a $ uname -a Darwin curtis-poes-computer-3.local 9.5.1 Darwin Kernel Version 9.5.1: Fri Sep 19 16:19:24 PDT 2008; root:xnu-1228.8.30~1/RELEASE_I386 i386 $ cd .. parrot $ svn info Path: . URL: https://svn.perl.org/parrot/trunk Repository Root: https://svn.perl.org/parrot Repository UUID: d31e2699-5ff4-0310-a27c-f18f2fbe73fe Revision: 33207 Node Kind: directory Schedule: normal Last Changed Author: moritz Last Changed Rev: 33207 Last Changed Date: 2008-11-25 21:43:42 + (Tue, 25 Nov 2008) Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 $ make spectest cd t/spec svn up At revision 23095. perl t/harness --fudge --keep-exit-code --jobs --tests-from-file=t/spectest.data t/spec/S02-builtin_data_types/array_extending.t ok t/spec/S02-builtin_data_types/anon_block.rakudo ok ===( 45;5 0/? 1/45 0/? )===Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/array_ref.rakudo . ok ===( 90;6 1/97 0/? 0/? )===Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/array.rakudo . ok t/spec/S02-builtin_data_types/bool.t ... ok t/spec/S02-builtin_data_types/assigning-refs.rakudo ok t/spec/S02-builtin_data_types/catch_type_cast_mismatch.rakudo .. ok t/spec/S02-builtin_data_types/flattening.rakudo ok ===( 269;14 0/? 1/32 0/? )==Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/hash_ref.rakudo .. ok ===( 301;18 1/58 0/? 0/? )==Use of uninitialized value Use of uninitialized value Use of uninitialized value Use of uninitialized value t/spec/S02-builtin_data_types/hash.rakudo .. ok t/spec/S02-builtin_data_types/multi_dimensional_array.rakudo ... ok t/spec/S02-builtin_data_types/nested_pairs.t ... ok t/spec/S02-builtin_data_types/nested_arrays.t .. ok t/spec/S02-builtin_data_types/mixed_multi_dimensional.rakudo ... ok ===( 495;27 0/? 0/? 1/8 )Use of uninitialized value t/spec/S02-builtin_data_types/subscripts_and_context.rakudo ok t/spec/S02-builtin_data_types/num.rakudo ... ok t/spec/S02-builtin_data_types/type.rakudo .. ok t/spec/S02-literals/array-interpolation.rakudo . ok ===( 590;32 1/79 0/? 0/? )==Undefined value shifted from empty range t/spec/S02-builtin_data_types/range.rakudo . ok
Re: [perl #60404] Array becomes string in subroutine or method calls
Thank you, very much!
2008/11/26 Moritz Lenz via RT [EMAIL PROTECTED]:
On Sat Nov 08 09:32:09 2008, pmichaud wrote:
On Sat, Nov 08, 2008 at 12:54:52AM -0800, Ilya Belikin wrote:
Hi there,
sub foo (@a) { 1.say for @a }
foo((1,2,3,4)); # only one 1
foo([1,2,3,4]); # only one 1
foo( my @a = 1,2,3 ); # only one 1
This one really pesky bug :(
I suspect this appeared as a result of the recent updates to
container semantics. Oddly, we don't seem to have any tests
for this in the spectest suite (or if there are tests, we aren't
running them for some reason).
There are now tests for that in t/spec/S06-signature/passing-arrays.t
(also added to spectest), I hope that I got them right (IMHO the counts
should be 4, 1, 3; if you disagree, feel free to correct the test)
moritz
Re: [perl #60828] [BUG] ^...@list returns ridicously long lists
Patrick R. Michaud wrote:
Currently Rakudo is treating [EMAIL PROTECTED] as though it's
prefix:^ on a List, which S03 says
If [prefix:^ is] applied to a list, it generates a
multidimensional set of subscripts.
for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
So, Rakudo is currently seeing [EMAIL PROTECTED] as following this definition,
and trying to generate the subscripts (perhaps wrongly).
Yes, wrongly:
08:48 moritz_ rakudo: say (^(3,3)).perl
08:48 p6eval rakudo 33212: OUTPUT[[0, 1, 2, 0, 1, 2]]
08:51 moritz_ rakudo: say (^(10,3)).perl
08:51 p6eval rakudo 33212: OUTPUT[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
1, 2]]
It counts up first the first index, then the second.
I see how the specced makes sense for a List of Ints, but not for any
other list - any ideas from the design team?
Moritz
There's still some ambiguity in how (or if) we should support
both interpretations [1], so we'll want to get that resolved before
we can fix prefix:^ here.
[1] http://irclog.perlgeek.de/perl6/2008-11-26#i_720703
[perl #60854] died when try to instant class with attribute type Range
# New Ticket Created by Ilya Belikin
# Please include the string: [perl #60854]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60854
Hi!
Rakudo 33212, example:
class R { has Range $.range }
my $r = R.new;
died with:
Null PMC access in clone()
current instr.: 'parrot;Perl6Object;!cloneattr' pc 782
(src/gen_builtins.pir:487)
called from Sub 'parrot;Range;clone' pc 5359 (src/gen_builtins.pir:3444)
called from Sub 'parrot;Perl6Object;new' pc 406 (src/gen_builtins.pir:266)
called from Sub '_block11' pc 35 (EVAL_13:21)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc 898
(src/PCT/HLLCompiler.pir:510)
...
Ilya
[perl #60868] [].min and [].max think +Inf and -Inf (respectively) are spelled undef
# New Ticket Created by Carl Mäsak # Please include the string: [perl #60868] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60868 From Rakudo r33221: $ perl6 -e'say [].min' Use of uninitialized value $ perl6 -e'say [].max' Use of uninitialized value pmichaud min of an empty list should be...? TimToady +Inf * masak files rakudobug TimToady according to S03, if you consider it equiv to [min]() pmichaud undef is what it returns now. pmichaud and .min isn't constrained to be numeric, is it? TimToady no, but +Inf isn't constrained to be numeric either, necessarily pmichaud ah. :-)
[perl #60404] Array becomes string in subroutine or method calls
On Sat Nov 08 09:32:09 2008, pmichaud wrote:
On Sat, Nov 08, 2008 at 12:54:52AM -0800, Ilya Belikin wrote:
sub foo (@a) { 1.say for @a }
foo((1,2,3,4)); # only one 1
foo([1,2,3,4]); # only one 1
foo( my @a = 1,2,3 ); # only one 1
This one really pesky bug :(
I suspect this appeared as a result of the recent updates to
container semantics.
Bang on. There's a bit of a subtlety in that when we have a parameter we
tend to wrap it in a Perl6Scalar (which we need to rename at some point
I guess, but anyways...). This inherits from ObjectRef. *But* just
because something was wrapped up in a Perl6Scalar to and enforce
readonly-ness and additional type checking doesn't mean it should have
ObjectRef semantics. Now we detect this and deref a level. Which fixes
the bug, and all other spectests go on passing, so I think it's the
right fix. Checked in as r33245.
Oddly, we don't seem to have any tests for this in the spectest
suite (or if there are tests, we aren't running them for some
reason).
I unfudged the ones moritz++ added.
Thanks,
Jonathan
Re: Files, Directories, Resources, Operating Systems
Can I just remind everyone that (IMO) we shouldn't just be considering
filesystems here? I think it would be a pretty useful feature to have a
general tree manipulation interface, and then this could be applied to
filesystems, or XML, or LDAP, or SQL (although this doesn't map so well), or
whatever.
I guess the way I see it, you'd have something like this:
role Tree::Node {...}
role Filesystem::Node inherits from Tree::Node {...}
role Filesystem::Directory inherits from Filesystem::Node {...}
class Filesystem::File does Filesystem::Node { # Interface, like DBI
has $implementation handles *;
$implementation = Filesystem::File::XML-new();
}
class Filesystem::File::XML inherits from Filesystem::File::Base {...}
In the case of Filesystem::Node, you would define some standard
attribute names (eg. owner, is_readable), but then they would be
accessible through the standard Tree::Node.get_attribute() interface. And the
standard Tree::Node.get_children() would be implemented by Filesystem::File as
something to fetch the contents of the file; in the case of
Filesystem::XMLFile, it would turn the contents into a tree of XML nodes.
I agree about the different levels of abstractions, but just wanted to
put in a plug for this one as one that I like.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: [EMAIL PROTECTED]| 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 #60404] Array becomes string in subroutine or method calls
Unfortunately I think this patch causes the following to fail:
sub foo($a) { 1.say for $a }
foo((1,2,3));
The problem is that simply looking at (misnamed) Perl6Scalar and
deciding what to do is a little coarse-grained. The real problem is in
the argument binding to a scalar versus array variable.
We'll probably revisit this as part of updating parameter passing
semantics. In the meantime, reopening the ticket until the above case
is resolved also.
Pm
[perl #55386] [TODO] Remove Configure.pl -miniparrot option
On Wed Nov 26 13:18:57 2008, coke wrote: The only remaining instance in branch that I'm not sure how to resolve is t/configure/034-step.t Jim - if you could take a look at that usage of miniparrot and either bless it or remove it, that'd be very helpful. (I can't tell if it's referencing the executable or the config option.) It was just dummy copy. The point of that particular test was to see if genfile() caught the Perl error found in 'sprint' in the next line. But I changed it anyway so that grep wouldn't find it -- and added a test for the captured error message while I was stopping by. I was mistakenly working in trunk rather than branch today when I updated 5 t/steps/*.t test files. I then subsequently discovered that you worked on those files yourself today in branch. So you might get some trivial conflicts when you do the merge. Coverage analysis for configure and build tools in the rm_miniparrot branch can be seen at http://thenceforward.net/parrot/coverage/configure-build/coverage.html. AFAICT you can do the merge back into trunk whenever you're ready. Thank you very much. kid51
Re: [perl #60828] [BUG] ^...@list returns ridicously long lists
On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote:
:
:
: Patrick R. Michaud wrote:
: Currently Rakudo is treating [EMAIL PROTECTED] as though it's
: prefix:^ on a List, which S03 says
:
: If [prefix:^ is] applied to a list, it generates a
: multidimensional set of subscripts.
:
: for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
:
: So, Rakudo is currently seeing [EMAIL PROTECTED] as following this
definition,
: and trying to generate the subscripts (perhaps wrongly).
:
: Yes, wrongly:
: 08:48 moritz_ rakudo: say (^(3,3)).perl
: 08:48 p6eval rakudo 33212: OUTPUT[[0, 1, 2, 0, 1, 2]]
: 08:51 moritz_ rakudo: say (^(10,3)).perl
: 08:51 p6eval rakudo 33212: OUTPUT[[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0,
: 1, 2]]
:
: It counts up first the first index, then the second.
:
:
: I see how the specced makes sense for a List of Ints, but not for any
: other list - any ideas from the design team?
My guess is that the list overloading will simply vanish into thin air,
and you'll have to say something like
^«(3,3)
to get the current Parrot meaning, and
[X] ^«(3,3)
or
^3 X ^3
to get the specced list meaning. But other viewpoints are welcome...
Larry
Re: Files, Directories, Resources, Operating Systems
Tom Christiansen wrote:
I believe database folks have been doing the same with character data, but
I'm not up-to-date on the DB world, so maybe we have some metainfo about
the locale to draw on there. Tim?
AFAIK, modern databases are all strongly typed at least to the point that the
values you store in and fetch from them are each explicitly character data or
binary data or numbers or what-have-you; and so, when you are dealing with a
DBMS in terms of character data, it is explicitly specified somewhere (either
locally for the data or globally/hardcoded for the DBMS) that each value of
character data belongs to a particular character repertoire and text encoding,
and so the DBMS knows what encoding etc the character data is in, or at least it
treats it consistently based on what the user said it was when it input the
data. The only time this information isn't really remembered is if the data is
supplied in terms of being binary data.
Maybe some older or unusual DBMSs aren't this way, and of course technically a
filesystem etc *is* a database ... I think that example mentioned about filename
storage being locale dependent, probably meant that at the actual filesystem
level it was just dealing with the names as binary data.
There is ABSOLUTELY NO WAY I've found to tell whether these utf-8
string should test equal, and when, nor how to order them, without
knowing the locale:
RESUME,
Resume
resume
Resum\x{e9}
r\x{E9}sum\x{E9}
r\x{E9}sume\x{301}
Re\x{301}sume\x{301}
Case insensitively, in Spanish they should be identical in all
regards. In French, they should be identical but for ties,
in which case you work your way right to left on the diactricals.
This leads me to talk about my main point about sensitivity etc.
I believe that the most important issues here, those having to do with identity,
can be discussed and solved without unduly worrying about matters of collation;
identity is a lot more important than collation, as well as a precondition for
collation, and collation is a lot more difficult and can be put off. With
respect to dealing with a file system, generally it is just identity that
matters and collation is a concern that can typically be just tacked on after
identity is solved.
That is, with a file system you need to know whether or not a file name you hold
will or won't match a file in the system, and matching or not-matching is the
main function of an identity. Similarly, the file system has to make sure that
no 2 distinct files in it have the same file name, that is the same public
identity. In contrast, the order that you order or sort a list of files by
their names usually isn't so important; while all work with a file system
requires working with identities, most work does not need to deal with
collation. In practice several parties can agree on a single means of
identifying files, while still having their own favorite collations, so the same
list can be ordered in different ways.
Collation criteria is something that can be naturally applied externally to a
file system, such as by a user program, and only identity criteria needs to be
built-in to the file system.
So collation doesn't need to be considered in Perl's file-system interface,
while identity does; collation can be a layer on top of the core interface that
just cares about identity.
One maxim I apply in my database work, and that I believe applies to this
discussion, is any logical difference is a big difference. If you have 2
distinct value literals such that you consider the difference in each literal's
spelling to be significant, such that you can't for all use cases substitute one
literal for the other, then the 2 literals denote 2 distinct values; in the
other case, where you can always substitute one for the other harmlessly, then
they denote the same value. The concept of 'value' and 'identity' are the same,
and any value is its own identity.
And so, with your 7 'resume' literals, I would say that if there is a reason for
any of the spellings to exist that couldn't be handled by one of the other
spellings, then all 7 literals are distinct/non-identical taken as-is.
If you *know* that the 7 strings are all UTF-8, then locale doesn't have to be
considered for equality; just your unicode abstraction level matters, such as if
you're defining the values in terms of graphemes vs codepoints vs bytes.
When talking about identity, there is no such thing as case-insensitivity or
accent insensitivity or whitespace insensitivity or what have you. If you have
any reason to not replace every E with an e or vice-versa in your character
string, then you consider those 2 non-identical and so they wouldn't match; by
contrast, true case-insensitivity means you can replace every e with an E
(for example) and forget than an e ever existed; the actual equality test is
then the same since all comparands would only have the E.
And so
Re: [perl #60828] [BUG] ^...@list returns ridicously long lists
On Wed, Nov 26, 2008 at 06:21:22PM -0800, Larry Wall wrote:
On Wed, Nov 26, 2008 at 08:54:50AM +0100, Moritz Lenz wrote:
: Patrick R. Michaud wrote:
: Currently Rakudo is treating [EMAIL PROTECTED] as though it's
: prefix:^ on a List, which S03 says
: for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
:
: I see how the specced makes sense for a List of Ints, but not for any
: other list - any ideas from the design team?
My guess is that the list overloading will simply vanish into thin air,
and you'll have to say something like
^«(3,3)
to get the current Parrot meaning, and
[X] ^«(3,3)
or
^3 X ^3
to get the specced list meaning. But other viewpoints are welcome...
+1 to the idea that [EMAIL PROTECTED] is the same as [EMAIL PROTECTED] . Now
implemented
as such in Rakudo, and unfudged the corresponding tests.
Closing ticket -- thanks!
Pm
r24080 - docs/Perl6/Spec src/perl6
Author: lwall
Date: 2008-11-27 08:21:32 +0100 (Thu, 27 Nov 2008)
New Revision: 24080
Modified:
docs/Perl6/Spec/S03-operators.pod
src/perl6/STD.pm
Log:
[STD] not() etc. is a function call
[S03] prefix:^ no longer tries to get fancy with lists
Modified: docs/Perl6/Spec/S03-operators.pod
===
--- docs/Perl6/Spec/S03-operators.pod 2008-11-27 06:14:03 UTC (rev 24079)
+++ docs/Perl6/Spec/S03-operators.pod 2008-11-27 07:21:32 UTC (rev 24080)
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 7 Nov 2008
+ Last Modified: 26 Nov 2008
Number: 3
- Version: 146
+ Version: 147
=head1 Overview
@@ -245,6 +245,14 @@
a(1)
+In term position, any identifier followed immediately by a
+parenthesized expression is always parsed as a term representing
+a function call even if that identifier also has a prefix meaning,
+so you never have to worry about precedence in that case. Hence:
+
+not($x) + 1 # means (not $x) + 1
+abs($x) + 1 # means (abs $x) + 1
+
=item *
Pair composers
@@ -2890,10 +2898,6 @@
for ^4 { say $_ } # 0, 1, 2, 3
-If applied to a list, it generates a multidimensional set of subscripts.
-
-for ^(3,3) { ... } # (0,0)(0,1)(0,2)(1,0)(1,1)(1,2)(2,0)(2,1)(2,2)
-
If applied to a type name, it indicates the metaclass instance instead,
so C^Moose is short for CHOW(Moose) or CMoose.HOW. It still kinda
means what is this thing's domain in an abstract sort of way.
Modified: src/perl6/STD.pm
===
--- src/perl6/STD.pm2008-11-27 06:14:03 UTC (rev 24079)
+++ src/perl6/STD.pm2008-11-27 07:21:32 UTC (rev 24080)
@@ -3271,7 +3271,7 @@
token term:identifier ( -- Term )
{
:my $t;
-identifier
+identifier ?before ['.'?'(']?
{ $t = $identifier.text; }
args( $¢.is_type($t) )
{{
Re: Files, Directories, Resources, Operating Systems
* Tom Christiansen ([EMAIL PROTECTED]) [081126 23:55]:
On Wed, 26 Nov 2008 11:18:01 PST.--or, for backwards compatibility,
at 7:18:01 p.m. hora Romae on a.d. VI Kal. Dec. MMDCCLXI AUC,
Larry Wall [EMAIL PROTECTED] wrote:
SUMMARY: I've been looking into this sort of thing lately (see p5p),
and there may not even *be* **a** right answer. The reasons
why take us into an area we've traditionally avoided.
What a long message...
Mark We should focus on OS abstraction.
Mark [...] the design of this needs to be free from historical mistakes.
... It cannot be
done in an automated fashion, since you can't know a filesystem that knew
*locale* each filename was created under, and without that, you have to
guess--almost always wrongly.
Exactly. This is an historical mistake, understandable to have at least
a path of growth from the current system open() interface. Only users
which have the same locale can see the names the same. If you change
your locale your filenames break! Say you change from cyrillic into
English.
In my suggestion, the programmer (who is ofter local on the system) can
at least say what the locale was when the filenames where created. On
some OS, that OS can tell you. What I would like is an object model
which does allow us at least to abstract these problems away... whether
it can be resolved automatically or only with help is for later.
There is ABSOLUTELY NO WAY I've found to tell whether these utf-8
string should test equal, and when, nor how to order them, without
knowing the locale:
RESUME,
Resume
resume
Resum\x{e9}
r\x{E9}sum\x{E9}
r\x{E9}sume\x{301}
Re\x{301}sume\x{301}
This is done by the locale of the user of the script, as usual for
ls(1). So, I do not see your problem here.
I don't mind if problems with unicode are not solved or solvable.
Could be discuss about a buildin File::Spec/Path::Class? And we
allow us the same limitations as these have, for the moment.
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
