Re: operator
Markus Laire writes:
[EMAIL PROTECTED] kirjoitti:
Please,
I have a question if exists in Perl somethink like keyword
'operator' in C++ ?
That will exist in perl6.
And to quite a larger extent. Not only can you overload existing
operators, you can make up whatever operator name you like.
for example we can write in C++ :
class A {
A() { printf(Constructor of object class A\n); }
~A() { printf(Destructor of object class A\n); }
};
A operator + (A a1, A a2) { printf(Addition\n); }
A operator * (A a1, A a2) { printf(Multiplication\n); }
int main() {
A a,b,c;
c = (a+b*a);
}
Using these as reference:
http://dev.perl.org/perl6/synopsis/S06.html
http://dev.perl.org/perl6/synopsis/S12.html
(I don't understand how to create constructor destructor)
I think equivalent perl6-code would be:
class A {
# place constructor here
submethod BUILD() {
say Constructor of class A;
}
# place destructor here
submethod DESTROY() {
say Destructor of class A;
}
}
sub infix:+ (A $a1, A $a2) { print(Addition\n); }
sub infix:* (A $a1, A $a2) { print(Multiplication\n); }
I expect you need multi on those subs, to avoid redefining the
existing operators (not without it yelling at you a bit, though).
multi sub infix:+ (A $a1, A $a2) { say Addition }
multi sub infix:* (A $a1, A $a2) { say Multiplication }
my A $a; # note, I'm not sure how to write this on one line
my A $b;
my A $c;
Just:
my A ($a, $b, $c);
Luke
$c = ($a + $b * $a);
bound methods (was: Calling conventions, invocations, and suchlike things)
Dan Sugalski [EMAIL PROTECTED] wrote: At 5:04 PM -0500 1/18/05, Sam Ruby wrote: f = Parrot.find print f(r) Note that I referenced the method as an attribute, and then called it as a function. Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) Not quite. It's just: f = getattribute Parrot_string, find nothing more. The Cget_attr_str vtable has to do the right thing, i.e. if the attribute is a callable, it has to return a bound method object. Furthermore, the function remembers what object it is bound to. This is accomplished by VTABLE_find_method creating a new PyBoundMeth PMC which contains two references, one to the object, and one to the method. While a good idea, I think it's not the right way to handle this. Binding objects to methods to create invokable subs is going to be something we're going to need for a lot of the languages, so I think we'd be better served providing a general facility to do it rather than leaving it to each individual language designer to do it. Should save some work all around too. Yeah. When this came up last, I've proposed two ways to handle it: 1) inside the Sub/NCI PMC 2) by a distinct Bound_Meth PMC class derived from 1) The latter is probably cleaner. Binding the object to the callable could be done e.g. by the Cset_pmc vtable. leo
[perl #33986] [BUG] dynclasses dependencies
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #33986] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=33986 - dynclasses files aren't rebuilt e.g. on include header changes - runtime/parrot/dynext isn't cleaned with e.g. make progclean Patches welcome leo
[CVS ci] GMS generational MS 5 - gc_gms.c
I've now committed the source of the generational mark sweep GC system.
Some remarks:
- it's by far not finished
- fails still a lot of tests [1]
- to turn it on set PARROT_GC_SUBSYSTEM to 2 in settings.h
- you might also turn on GC_GMS_DEBUG when hacking on the code
- it should be documented sufficiently to see how it works
- if something is unclear please just ask
All help is very welcome to debug and complete the code and make it
actually working.
I ran one example[2], which shows that the generational approach is
really a win (~40% improvement in execution time).
leo
[1] stacks_52 seems to hang; 115/2214 subtests failed
[2] sample code
$ cat io.pasm
new_pad 0
new P16, .FixedPMCArray
store_lex 0, array, P16
set I6, 50
set P16, I6
set I5, 0
fill:
new P5, .Integer
set P5, I5
set P16[I5], P5
inc I5
lt I5, I6, fill
# next scope
new_pad -1
open P17, test.tmp,
needs_destroy P17
store_lex -1, fh, P17
print P17, a
pop_pad
null P17
sweep 0
# verify file
open P17, test.tmp,
read S5, P17, 1
print S5
print \n
end
Here is the Perl5 equivalent:
$ cat io.pl
#!/usr/bin/perl -w
use strict;
use IO::File;
my @array;
$array[$_] = $_ for (0..49);
{
my $fh = IO::File-new;
$fh-open(test.tmp);
print $fh a;
}
my $fh = IO::File-new;
$fh-open(test.tmp);
print $fh, \n;
Re: bound methods
Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 5:04 PM -0500 1/18/05, Sam Ruby wrote: f = Parrot.find print f(r) Note that I referenced the method as an attribute, and then called it as a function. Mmm, syntax! :) Luckily it makes no difference to us at the parrot level. What that should translate to is something like: $P0 = find_method Parrot_string, find # Elided check for failed lookup and fallback to attribute fetch $P1 = make_bound_method(Parrot_string, $P0) Not quite. It's just: f = getattribute Parrot_string, find nothing more. The Cget_attr_str vtable has to do the right thing, i.e. if the attribute is a callable, it has to return a bound method object. Exactly. Furthermore, the function remembers what object it is bound to. This is accomplished by VTABLE_find_method creating a new PyBoundMeth PMC which contains two references, one to the object, and one to the method. While a good idea, I think it's not the right way to handle this. Binding objects to methods to create invokable subs is going to be something we're going to need for a lot of the languages, so I think we'd be better served providing a general facility to do it rather than leaving it to each individual language designer to do it. Should save some work all around too. Yeah. When this came up last, I've proposed two ways to handle it: 1) inside the Sub/NCI PMC 2) by a distinct Bound_Meth PMC class derived from 1) The latter is probably cleaner. Binding the object to the callable could be done e.g. by the Cset_pmc vtable. That's exactly how PyBoundMeth works today. Cset_pointer sets the pointer to the actual subroutine. Cset_pmc sets the pointer to the bound object. - Sam Ruby
forced continuations
I would like to do my own preemptive multitasking within a single-threaded application. When a timer fires, I'd like to: 1. suspend the current computation 2. put it on the back of a work queue 3. resume the lambda on the top of the work queue. Will Parrot facilitate this? Thank you for insight into my muddlement.
Re: bound methods
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: 2) by a distinct Bound_Meth PMC class derived from 1) The latter is probably cleaner. Binding the object to the callable could be done e.g. by the Cset_pmc vtable. That's exactly how PyBoundMeth works today. Cset_pointer sets the pointer to the actual subroutine. Cset_pmc sets the pointer to the bound object. Great. I saw the checkin but didn't have a close look at it. So if even the interface is the same, we really should put it into the core classes. WRT implementation: I'd like to swap struct_val/pmc_val for all Sub classes. It's just cleaner but should be almost fully transparent to users of these classes. WRT functionality: for a call it has to shift up PMC arguments and insert the object as P5, right? - Sam Ruby leo
Re: bound methods
Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: 2) by a distinct Bound_Meth PMC class derived from 1) The latter is probably cleaner. Binding the object to the callable could be done e.g. by the Cset_pmc vtable. That's exactly how PyBoundMeth works today. Cset_pointer sets the pointer to the actual subroutine. Cset_pmc sets the pointer to the bound object. Great. I saw the checkin but didn't have a close look at it. So if even the interface is the same, we really should put it into the core classes. Cool. I'd likely still subclass it to provide a get_string. WRT implementation: I'd like to swap struct_val/pmc_val for all Sub classes. It's just cleaner but should be almost fully transparent to users of these classes. No objection. WRT functionality: for a call it has to shift up PMC arguments and insert the object as P5, right? At the moment, it contains this logic. My plans are to remove the shifting and set the object into P2 / INTERP-ctx.current_object. Notes: at the moment, every Python method call creates a bound object, and shifts PMC arguments. Removing the shifting of PMC arguments will require the insertion of an interpinfo opcode into each method. If there were a call_method VTABLE entry and if P2 were passed into methods, all of this would be unecessary in the majority of cases. - Sam Ruby
Recent RT work
Thanks to Matt Diephouse, about 30+ tickets have just been properly marked as resolved. (Though I physically closed them, he did all the legwork. Someone make him a bugadmin, please.) This leaves 268 documented issues in RT, plus whatever is lurking in CVS. 50% of these are -new-, despite the fact that some of them are 2.5 years old http://rt.perl.org/rt3/NoAuth/parrot/Overview.html shows a few dozen of these tickets are platform specific. Some of those tickets are very old. Can someone from the various platforms verify if these are able to be closed? (Win32, mswin32, vms, os2, cygwin, MacOS X, linux, freebsd). The current Hall of Shame ticket is #760. http://rt.perl.org/rt3/Ticket/Display.html?id=760 Originally posted by Josh Wilmes in July 2002, with a quick reply by Dan... Josh himself followed up in October of that year to indicate this was still an issue.
Anomalous Difference in Output between HTML Files Created by 'cover'
I have just noticed an anomalous difference in output between two of the
files created by the Devel::Cover 'cover' utility when run against a
popular Perl module -- and I am wondering whether this difference should
be considered a feature or a bug.
The module in question is Text::Template, which I am studying as part of
Perl Seminar NY's contribution to the Phalanx project. Start with a
copy of Text-Template-1.44 (the latest on CPAN) and examine the code.
In 'lib/Text/Template.pm', consider these two lines:
128$self-_acquire_data unless $self-{DATA_ACQUIRED};
450if (! defined $val) {
Proceed in the normal manner:
perl Makefile.PL
make
cover -delete
HARNESS_PERL_SWITCHES=-MDevel::Cover make test
cover
... 'cover' creates a number of HTML files, including these two:
./Text-Template-1.44/cover_db/blib-lib-Text-Template-pm.html
./Text-Template-1.44/cover_db/blib-lib-Text-Template-pm--branch.html
'blib-lib-Text-Template-pm.html' displays lines 128 and 450 exactly as
they appear in the module itself.
'blib-lib-Text-Template-pm--branch.html', however, displays the relevant
branch part of these lines of code as follows:
128 unless $$self{'DATA_ACQUIRED'}
450 if (not defined $val) { }
'$self-{DATA_ACQUIRED}' is changed to '$$self{'DATA_ACQUIRED'}' and '!
defined $val' is changed to 'not defined $val'. (I could site other
examples as well, but these suffice to illustrate the point.)
Now, I grant that these are merely displays, not live code.
Nonetheless, since the purpose of these HTML files is to guide a
programmer to lines of code whose test coverage needs improvement, I am
puzzled as to why the output in these two files differs.
Jim Keenan
Re: Anomalous Difference in Output between HTML Files Created by 'cover'
I'd guess it is because you are seeing the output of the code after it
has been compiled-then-decompiled - it is compiled so it can run and
coverage statistics can be collected, then it is decompiled to relate
coverage stats to code lines. Now there are many ways to write code that
compiles to the same compiled form, but the decompiler (I imagine it is
B::Deparse) only decompiles those symbols one way.
As a test, you could change those two lines in Text::Template to be the
same as what you are seeing in the coverage HTML, run the make test and
cover again and see them unchanged.
Or more directly
===
deparse.pl
===
#!/usr/bin/perl -w
use strict;
my $self;
$self-{DATA_ACQUIRED} = 1;
+++
end deparse.pl
+++
prompt perl -MO=Deparse deparse.pl
BEGIN { $^W = 1; }
use strict 'refs';
my $self;
$$self{'DATA_ACQUIRED'} = 1;
deparse.pl syntax OK
===
deparse2.pl
===
#!/usr/bin/perl -w
use strict;
my $self;
$$self{DATA_ACQUIRED} = 1;
+++
end deparse2.pl
+++
prompt perl -MO=Deparse deparse2.pl
[EMAIL PROTECTED] perl]$ perl -MO=Deparse deparse2.pl
BEGIN { $^W = 1; }
use strict 'refs';
my $self;
$$self{'DATA_ACQUIRED'} = 1;
deparse2.pl syntax OK
Leif
[EMAIL PROTECTED] wrote:
I have just noticed an anomalous difference in output between two of
the files created by the Devel::Cover 'cover' utility when run against
a popular Perl module -- and I am wondering whether this difference
should be considered a feature or a bug.
The module in question is Text::Template, which I am studying as part
of Perl Seminar NY's contribution to the Phalanx project. Start with
a copy of Text-Template-1.44 (the latest on CPAN) and examine the
code. In 'lib/Text/Template.pm', consider these two lines:
128$self-_acquire_data unless $self-{DATA_ACQUIRED};
450if (! defined $val) {
Proceed in the normal manner:
perl Makefile.PL
make
cover -delete
HARNESS_PERL_SWITCHES=-MDevel::Cover make test
cover
... 'cover' creates a number of HTML files, including these two:
./Text-Template-1.44/cover_db/blib-lib-Text-Template-pm.html
./Text-Template-1.44/cover_db/blib-lib-Text-Template-pm--branch.html
'blib-lib-Text-Template-pm.html' displays lines 128 and 450 exactly as
they appear in the module itself.
'blib-lib-Text-Template-pm--branch.html', however, displays the
relevant branch part of these lines of code as follows:
128 unless $$self{'DATA_ACQUIRED'}
450 if (not defined $val) { }
'$self-{DATA_ACQUIRED}' is changed to '$$self{'DATA_ACQUIRED'}' and
'! defined $val' is changed to 'not defined $val'. (I could site
other examples as well, but these suffice to illustrate the point.)
Now, I grant that these are merely displays, not live code.
Nonetheless, since the purpose of these HTML files is to guide a
programmer to lines of code whose test coverage needs improvement, I
am puzzled as to why the output in these two files differs.
Jim Keenan
[perl #33995] [BUG] Configure warning on gdbmhash
# New Ticket Created by Will Coleda # Please include the string: [perl #33995] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=33995 The recent gdbmhash configure check causes the following output on my system during the build. I don't think the undef value negatively impacts the build, as dynclasses /seems/ to build OK. (I'm pretty sure my dynclass test failures are due to the --prefix specification.) Generating C headers..done. Generating core pmc list..done. Generating runtime/parrot/include.done. Generating build files..value for 'gdbmhash' in config/gen/makefiles/dynclasses.in is undef at lib/Parrot/Configure/Step.pm line 230, IN line 11. ..done. Moving platform files into place..done. Recording configuration data for later retrieval..done. Okay, we're done!
Re: introduction
Comrade Burnout wrote: I'm not sure where to start other than this. So hi and stuff. Hi, Brian. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
introduction
I remember seeing that the list-joining thingie mentioned an introduction once someone joined, so here it is: I'm geektron on perlmonks, and Brian Clarkson IRL. I've talked a bit to Mr. Lester and Mr. Kinyon about tests, and decided that learning some good testing skills while doing something useful added up to joining this list and the Phalanx project. I'm not sure where to start other than this. So hi and stuff. Brian
