Re: What's needed for a new languages/t/*?
On Thu, 2005-08-04 at 08:52 -0400, Amir Karger wrote: I'm about to commit an updated version of leo's Z-code-to-PIR translator. I'm wondering what I should do about t. I hope to have a variant of Test::More written in pure PIR in the near future (though it probably requires the new calling conventions code to reach the trunk) and a port of Parrot::Test shortly after that. That ought to let you write tests either in PIR or, with the appropriate calling code, in the language of your choice. -- c
Starting 0.2.3 release
Please no more checkins to parrot svn until further notice. Thanks, leo
Various questions on .ref and .meta
Hi, ~Str;# class? Str? ~::Str; # class? Str? ~Str.meta; # class? (fill in please)? ~::Str.meta; # class? (fill in please)? +Str; +::Str; +Str.meta; +::Str.meta; # all errors? ?Str; ?::Str; ?Str.meta; ?::Str.meta; # all true? Str =:= ::Str; # true? some string.ref =:= Str; # true? Str.ref; # (fill in please) ::Str.ref; # (fill in please) Str.meta.ref;# (fill in please) ::Str.meta.ref; # (fill in please) Str.ref.ref; # (fill in please) ::Str.ref.ref; # (fill in please) --Ingo -- Linux, the choice of a GNU | The future is here. It's just not widely generation on a dual AMD | distributed yet. -- William Gibson Athlon!|
Reassigning .ref and .meta? Rebinding class objects?
Hi, my $str = Hello; $str.ref = Int; # allowed? $str.meta = some_sub.meta; # allowed? my $str = Hello; Str ::= Int; # allowed? ::Str ::= ::Int;# or is this allowed? say $str; # still Hello? Or is it an Int now? my $new_str = Hi; say $new_str; # is this an Int now? Str ::= simple string; # not allowed? ::Str ::= simple string; # not allowed? --Ingo -- Linux, the choice of a GNU | Row, row, row your bits, gently down the generation on a dual AMD | stream... Athlon!|
Parrot 0.2.3 Serenity Released!
Parrot 0.2.3 Serenity Released! On behalf of the Parrot team I'm proud to announce another monthly release of Parrot and I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.2.3 changes and news - Dynamic classes now compile on Windows (including ParTcl) - New Super PMC allows easy access to superclass methods - Implement C3 method resolution order (just like Perl6 Python) - ParTcl has new PIR-based parser and passes more Tcl tests - added character class support in Globs to PGE - added language implementations of unlambda, Lazy-k - many bugfixes, including GC and memory leaks - the new calling scheme continued to evolve in branches/leo-ctx5 After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.2.3.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html
Re: undef.chars?
On Thu, Aug 04, 2005 at 10:48:49PM -0700, Brent 'Dax' Royal-Gordon wrote: : Luke Palmer [EMAIL PROTECTED] wrote: : On 8/4/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: : my $undef = undef; : say $undef.chars? # 0? undef? die? : say chars $undef; # 0? undef? die? : : I'd opt for undef.chars to be an error (no such method) and chars : undef to return 0 (with a warning printed to STDERR^W$*ERR). : : Well, I think that chars $undef should be exactly equivalent to : $undef.chars. In fact, I think it is: chars $undef is just the : indirect object form. : : Didn't $Larry rule that method calls on undef return undef, for the : same reason array and hash subscripting does? Um, by default, that's exactly what fail does. I don't think it's a problem for it to die under use fatal, since that's saying you prefer an exception model in general. Larry
Re: [perl #36755] [PATCH] dynclasses with MinGW32
François PERRAD (via RT) [EMAIL PROTECTED] wrote:
With this patch, dynclasses work with MinGW32.
(same as r8717 by Jonathan Worthington with MSC)
Unfortunately, your changes to dynclasses_pl.in break the build for MSVC.
Fortunately, it looks to be something fairly minor.
-${ld_out} . $target . . $def .
+-o . $target . . $def .
You can't hardcode -o in there - you must use ${ld_out}. As MinGW32 uses
gcc (I believe that's the case, anyway...) and ${ld_out} works for gcc on
other platforms, I guess that changing that line back to how it was won't
break things for MinGW32?
If using ${ld_out} won't break stuff for MinGW32, I can apply the patch with
this fix (no need for you to send a new one) unless I spot any other issues.
If it does, then we need to work out a way of making MinGW32 happy without
breaking things for @other compilers.
Please let me know.
Thanks,
Jonathan
Interpolation of arrays
While trying to use say for debugging, I ran across an oddity. While I can:
say [EMAIL PROTECTED];
and
say @some_array;
this doesn't work:
say @some_array;
Even stranger:
class SomeClass {
has $.scalar_attr;
has @.array_attr;
method trial () {
say $.scalar_attr @.array_attr;
}
}
Calling trial yields the correct value of the scalar, but the literal
'@.array_attr' instead of its value. Oddly, substituting $.array_attr yields
the value with no complaint that there is no such scalar.
Am I missing something, or should I submit a test?
If the later, what folder should I put it in?
Phil
Re: Interpolation of arrays
Hi,
[EMAIL PROTECTED] wrote:
While trying to use say for debugging, I ran across an oddity. While
I can:
say [EMAIL PROTECTED];
and
say @some_array;
this doesn't work:
say @some_array;
Pugs is correct here, you need to use [] or {} to interpolate
aggregates:
say $scalar @array[] %hash{};
Even stranger:
class SomeClass {
has $.scalar_attr;
has @.array_attr;
method trial () {
say $.scalar_attr @.array_attr;
}
}
Calling trial yields the correct value of the scalar, but the literal
'@.array_attr' instead of its value. Oddly, substituting $.array_attr
yields the value with no complaint that there is no such scalar.
Ah, that's probably because under the current runcore, all $.vars are
merely keys for a hash, and the sigil seems to get stripped away.
(Under the new PIL runcore, Stevan's metamodel will be/is integrated,
i.e. we'll have real OO, and accessing
$.attributes_which_do_not_exist will fail at compile-time.)
Am I missing something, or should I submit a test?
Yes, please do so! :)
If the later, what folder should I put it in?
t/oo/attributes/, probably.
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: Reassigning .ref and .meta? Rebinding class objects?
On 8/5/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
Hi,
my $str = Hello;
$str.ref = Int; # allowed?
$str.meta = some_sub.meta; # allowed?
I hardly think those work. Both of those require a change of
implementation, which we can't do generically. So people would have
to specify how the implementation changes in that way, which they
generally won't/can't. You can do the first using user-defined
methods like so:
$str = $str as Int# $str as= Int ?
I'm not sure about the latter.
my $str = Hello;
Str ::= Int; # allowed?
::Str ::= ::Int;# or is this allowed?
One of these two is probably allowed. But maybe it should be louder.
say $str; # still Hello? Or is it an Int now?
That's a hard question. If say is implemented like so (this is
hypothetical; it will surely be implemented in terms of print):
multi say () { internal_put_str \n }
multi say (*$first, [EMAIL PROTECTED]) {
given $first {
when Str { internal_put_str $first }
when Int { internal_put_int $first }
...
}
say @stuff;
}
Then the first case becomes equivalent to when Int, which would call
internal_put_str with an Int, which could be very dangerous. This is
why rebinding names globally is a bad idea. And in that case, I don't
know how or whether we should provide the ability.
Globally subclassing, however, isn't so dangerous:
Str does role {
method blah () {...}
};
But then comes to your question:
my $foo = hello;
Str does role {
method blah () {...}
};
$foo.blah; # allowed
That is, do existing Strs all does the new role as well?
Luke
Re: Various questions on .ref and .meta
On 8/5/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote: Hi, ~Str;# class? Str? Str ~::Str; # class? Str? I don't know how :: works anymore. I'll avoid these. ~Str.meta; # class? (fill in please)? Class ~::Str.meta; # class? (fill in please)? +Str; +::Str; +Str.meta; +::Str.meta; # all errors? Yep... unless Str somehow specifies that it can be numified, which it shouldn't. some string.ref =:= Str; # true? Yeah, if .ref is what we end up calling it. Str.ref; # (fill in please) Class ? Str.meta.ref;# (fill in please) ETOOMUCHMETA at Luke line 40. I don't know about this one. Luke
Re: [pirate] OSCON slides
Leopold Toetsch wrote: Citing 33.html: Parrot's current implementation relies on the ability to morph an object to another type. Leo has attempted to challenge this a number of times, but to my knowledge never successfully. I'm a bit bewildered that pirate folks seem not to bother following parrot dev list [1] or even summaries. For short: n_add d, l, r will create a new destination PMC and with the help of .HLL a new Python PMC. See also t/dynclass/pycomplex_3 and _4. (This is just one point of several from the slides of what I'm inclined to name FUD) leo E.g. [1] http://xrl.us/gz5b At the end of the presentation, a person in the front row asked me if I planned to continue to contribute to the project. My response was something along the lines of, I appreciate having been given the opportunity to contribute, I hope I fixed more things than I broke, but I probably won't contribute in any major way again unless I see signs of things turning around. From the back row, Chip introduced himself. At which point, I ammended my previous statement saying that Chip was in a position to make a difference. My experiences with Parrot was that everything I did was met with either direct animosity or by being ignored. If that changed, I could see myself becoming active again. In the past few weeks, I have received two pieces of feedback from the Parrot community. One was attacking me for having adopted the suggestion by Leo that the object of the method should be passed on the first argument of method call. The second was to attack me for saying something nice about morphing. I said in slide 3 that this presentation was based mostly on memory. In slide 4, I said that Parrot is evolving. I said in slide 31 that my memory was based on the work I did in December of 2004. I said in slide 33 that Leo was working to change how morphing was being used in Parrot, but my real point was made in slide 36: morphing was cheap and efficient in practice. My research prior to the presentation was to check to see if morphing was still in the VTable, and it is. For now, I'll probably limit the amount of time I devote to Parrot as there are plenty of other places where I feel more welcome. - Sam Ruby
Re: $pair[0]?
On Fri, Aug 05, 2005 at 12:27:53AM +0200, Ingo Blechschmidt wrote: : Hi, : : Andrew Shitov wrote: : say $pair[0]; # a? : : It looks like $pair is an arrayref while 'say ref $pair' tells 'Pair'. : : right, this is why I asked, IMHO it's bogus. Yes, for bare pairs, it's probably somewhat bogus. But now I'm asking myself about the use of as a Lispish '.': 'a' = 'b' = 'c' = 'd' There's something to be said for having a way of indexing into that using numeric subscripts. Certainly Lisp's extensible car/cdr notation is the wrong way to do it, but cdddr is certainly shorter than $pair.value.value.value But maybe that's worth being dehuffmanized like that... Larry
Re: $pair[0]?
On Fri, Aug 05, 2005 at 11:36:16 -0700, Larry Wall wrote:
There's something to be said for having a way of indexing into that
using numeric subscripts. Certainly Lisp's extensible car/cdr notation
is the wrong way to do it, but cdddr is certainly shorter than
$pair.value.value.value
But maybe that's worth being dehuffmanized like that...
Haskell has !! :
sub infix:!! (Pair $x, 0) { $x.key }
sub infix:!! (Pair $x, Int $index) { $x.value !! ($index - 1) }
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!
pgpMrMvGz2R03.pgp
Description: PGP signature
Re: $pair[0]?
Seems like you left out the degenerate case for when you run out of pairs:
sub infix:!! (Scalar $x, 0) { $x }
On 2005-08-05 16:24, Yuval Kogman [EMAIL PROTECTED] wrote:
On Fri, Aug 05, 2005 at 11:36:16 -0700, Larry Wall wrote:
There's something to be said for having a way of indexing into that
using numeric subscripts. Certainly Lisp's extensible car/cdr notation
is the wrong way to do it, but cdddr is certainly shorter than
$pair.value.value.value
But maybe that's worth being dehuffmanized like that...
Haskell has !! :
sub infix:!! (Pair $x, 0) { $x.key }
sub infix:!! (Pair $x, Int $index) { $x.value !! ($index - 1) }
Re: [pirate] OSCON slides
On Aug 5, 2005, at 20:17, Sam Ruby wrote: My experiences with Parrot was that everything I did was met with either direct animosity or by being ignored. If that changed, I could see myself becoming active again. I would very much appreciate your contributions the more that parrot was and is evolving in a direction that should simplify e.g. implementing Python. A lot of parrot cruft that caused vivid discusssions (which was never animosity) is gone. There are still issues e.g. with namespaces. I've put out numberless mails on p6i where I invited HLL folks to discuss it and make some proposals. Guess how many answers these mails got. And there is: http://svn.perl.org/parrot/trunk/docs/req/model_users.pod In the past few weeks, I have received two pieces of feedback from the Parrot community. One was attacking me for having adopted the suggestion by Leo that the object of the method should be passed on the first argument of method call. You know my position very well with that point. I've always said that Dan's 'we pass the object out-of-band' is not the way our target languages are working. And I said that your implementation is a hack to work around these deficiency of parrot. Passing the invocant twice to e.g. '__abs__' isn't a solution either the more that the user visible signature of that function changes. Anyway the new calling conventions will for sure pass the object as the first argument and the calling conventions will very likely support the full Pythons specs. *args is already done, as well as all issues regarding I/S/N/P mismatch. Parrot just converts these argumens forth and back as needed so that it's fully transparent for a HLL that just has PMCs. The second was to attack me for saying something nice about morphing. Sorry if I missed the niceness factor of morph in your slides (I just saw that html page, you know). Python's scalars (and some other types don't morph). Any implementation that forces morph for doing e.g. 'a=2+3' can only be considered being b0rken by all pythonistas in your talk. I'm really missing 'nice' in such a slide the more that it's based on ... I said in slide 3 that this presentation was based mostly on memory. ... old and unneeded assumptions how parrot works. Again you very well know my position regarding this point. I always said there shoud be a means to create a new destination PMC. And this is implemented and working since months. In slide 4, I said that Parrot is evolving. I said in slide 31 that my memory was based on the work I did in December of 2004. Ok. Sorry I've missed that. - Sam Ruby leo
Unable to run perl 6 test under Parrot 0.2.x
Parrot 0.2.3 Serenity Released!
Possibly I'm growling again but I cannot run any Perl 6 programme with
new Parrots.
One-liner test.p6 containing 'print perl 6;' is compiled to test.imc and
cause an error:
C:\parrot-0.2.3\languages\perl6perl perl6 test.p6
error:imcc:syntax error, unexpected IDENTIFIER, expecting '\n' or COMMA in file
'test.imc' line 61
Error: 'C:/parrot-0.2.3\parrot.exe -r test.imc ' failed with exit code 18
Stopped at perl6 line 351
main::mydie(4608, 'C:/parrot-0.2.3\parrot.exe -r test.imc ') called at
perl6 line 844
main::pass4('test.imc', 'test.warn') called at perl6 line 766
main::pass2('test.imc', 'test.warn') called at perl6 line 459
main::output_tree('P6C::prog=ARRAY(0x2c5aa40)', 'test.p6', 'test.warn')
called at perl6 line 524
main::pass1('Parse::RecDescent=HASH(0x2b2c43c)', 'test.p6',
'test.warn', 'undef') called at perl6 line 586
main::run() called at perl6 line 231
Line 61 in test.imc is here:
.sub __main @MAIN
new_pad 0
call __setup
pop_pad
end
.end
.sub _main prototyped ### line 61
.param PerlHash Sunknown_named1 # named args
# Argument handling
if I0 goto L_got_params2
L_got_params2:
# Named locals:
find_lex $P1, print
Thanks in advance.
--
___
Andrew, [EMAIL PROTECTED]
___
Re: Whitespace
On Thu, Aug 04, 2005 at 09:29:21PM +0400, Andrew Shitov wrote: : in fact, that is exactly : : (print.getArgument(3) * 3); the same as above. : : so why not 'print($x)' == 'print ($x)' ;-) Because most people's expectations diverge from yours, actually, and we got tired of answering the FAQ. On top of which, we think it's probably easier to retrain you than the typical newbie. :-) Plus we got rid of Perl-5's no-op unary +, so instead we're using whitespace to force it to be a list operator. But the overriding reason is that we're trying to be consistent about using whitespace to distinguish postfix operators from binary operators or terms when it's ambiguous. We also consisently allow dot to force it the other way even in the presence of whitespace. If you were to add a ++ binary operator, it would be distinguished from postfix ++ by whitespace. But .++ would be the postfix anyway. Larry
