Re: Vocabulary
On Dec 16, 2003, at 10:20 PM, Rafael Garcia-Suarez wrote: There's a need (more or less) for special blocks that can be run at the end of the compilation phase of any arbitrary compilation unit. This would be especially useful in an environment such as mod_perl, where CHECK and INIT blocks currently _never_ execute, no matter when they're declared. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Vocabulary
On Dec 17, 2003, at 1:39 AM, Simon Cozens wrote: The desire to optimize the hell out of Perl 6 is a good one, but surely you optimize when there is a problem, not when before. Is there a problem with the speed you're getting from Perl 6 at the moment? Yes, it's taking too long to be released! ;-) Regards, David (Who wants to start writing Perl 6 applications yesterday.) -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Vocabulary
On Wed, Dec 17, 2003 at 06:20:22AM -, Rafael Garcia-Suarez wrote: : Larry Wall wrote in perl.perl6.language : : On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: : : When you say CHECK time, do you mean there'll be a CHECK phase for : : code that gets required at run time? : : Dunno about that. When I say CHECK time I'm primarily referring : to the end of the main compilation. Perl 5 appears to ignore CHECK : blocks declared at run time, so in the absence of other considerations : I suspect Perl 6 might do the same. : : This has proven to be inconvenient except for a few specialized usages, : such as the B::/O compiler framework. : : There's a need (more or less) for special blocks that can be run at the : end of the compilation phase of any arbitrary compilation unit. Well, if you want to run at the end of the current compilation unit, a BEGIN block at the end is close to what you want. Admittedly, the BEGIN block can't easily *know* that it's the last thing... That's not to say we can't improve the semantics of CHECK and INIT. Larry
Re: remarks WRT clone
At 10:59 PM +0100 12/17/03, Leopold Toetsch wrote: In former days and before YAPC::EU I changed the original clone vtable, which was IIRC: PMC* clone() # return new clone of pmc to the now existing form, which gets an uninitialized destination PMC. This change was at that time necessary because of reasons described in Fdocs/dev/infant.dev keyword Variant 2: Anchor early, anchor often. This is solved, stackwalking during DOD works, so /me thinks, that we can use again the original signature of the clone vtable. This does also simplify switching clone to Parrot_clone (the real and final clone via freeze/thaw), which just happens to return a newly created PMC. Works. Go for it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: pdd03 and method calls
At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote: While playing with calling threaded subs, I came along a thing which I think might be suboptimal: pdd03 states that the method PMC should go into P2. This doesn't really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain subs, where the first param is the object. PDD 03 states that the *object* goes in P2. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
How to raise an exception inside a PMC?
Hi, I'm just wondering how I should raise an exception inside a vtable function. I found the function real_exception, but I don't know what to put into the *dest argument. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
Leopold Toetsch [EMAIL PROTECTED] writes:
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't
really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods
are plain subs, where the first param is the object. I dunno, if Ponie
will ever use ParrotClass/ParrotObject, but I'm sure, that calling
Perl6 methods should work (and vv). So me thinks that the method PMC
should be the first PMC argument living in P5.
When I was experimenting with native methods in ParrotIO.pmc i had
also the problem that there was no way to put the P2 register to the
argument list. I don't know if this changed since then, but I had
put the object to P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
This makes a method-call and a sub-call more symetric. Both a method
object and a sub object are called via
invokecc P0
and returned with
invoke P1
the difference between them is currently that a method will use one more
register for the data transfer: P2
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
Dan Sugalski [EMAIL PROTECTED] writes: PDD 03 states that the *object* goes in P2. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. It is missing from PDD03 that P2 must be set to NULL in case of a normal subroutine call. Otherwise P2 can contain everything and the called function has no way to decide if the data is valid. An other possibility would be to let invoke set P2 to null, but I don't like the idea of having more sideeffects in invoke. This also makes it impossible to write callmeth as: find_method P0, P2, S0 invoke P0 bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
At 10:42 PM 12/17/2003 +0100, Leopold Toetsch wrote:
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't really
play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods are plain
subs, where the first param is the object. I dunno, if Ponie will ever use
ParrotClass/ParrotObject, but I'm sure, that calling Perl6 methods should
work (and vv). So me thinks that the method PMC should be the first PMC
argument living in P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
Comments?
Makes sense to me for non-prototyped methods.
How 'bout:
Non-prototyped: pass object in P5 array with rest of arguments
Prototyped: pass in P2 as in current spec
-Melvin
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
Leo wrote: Very likely that SIGFPE isn't defined. Does Fruntime/parrot/include/signal.pasm have an entry for SIGFPE? (line 14) .constant SIGFPE8 Is PARROT_HAS_HEADER_SIGNAL defined? (Finclude/parrot/has_header.h: line 46) define PARROT_HAS_HEADER_SIGNAL 1 Allison
testing File::Finder
In my recently released File::Finder module, I have the basic tests to ensure that the find options are grabbed correctly, and that the core and/or/not/parens logic is clean, along with the easy test to ensure that eval() works. However, to test the file operations, like files named moe, I have to test a live file tree. Or do I? I was hoping to leverage off the tests for find2perl, because that's exactly what I'd be testing as well. Alas, none. The tests for File::Find are rather simple, because there it's more about the mechanism and the odd cases (like symlinks) than about individual file properties. Should my test come with a tar file that gets extracted? Should I build a small tree on the fly? Any thoughts would be appreciated. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: testing File::Finder
On Thu, Dec 18, 2003 at 01:28:57PM -0800, Randal L. Schwartz wrote: In my recently released File::Finder module, I have the basic tests to ensure that the find options are grabbed correctly, and that the core and/or/not/parens logic is clean, along with the easy test to ensure that eval() works. However, to test the file operations, like files named moe, I have to test a live file tree. Or do I? I was hoping to leverage off the tests for find2perl, because that's exactly what I'd be testing as well. Alas, none. The tests for File::Find are rather simple, because there it's more about the mechanism and the odd cases (like symlinks) than about individual file properties. Should my test come with a tar file that gets extracted? Should I build a small tree on the fly? If you're not planning on your tests modifying the test tree at all, you can probably just get away with having t/tree/... as a bunch of normal files and directorys in the tarball. Don't ship a seperate tar file, that introduces unnecessary dependencies. If you plan on making changes to the tree you'll need some way to setup/teardown the tree between test runs to ensure its clean. In that case a tarball or small perl script would be best. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I've just gone through a lung-crushing breakup with my blender and I don't think I should screw my forehead alone tonight.
Re: testing File::Finder
Michael == Michael G Schwern [EMAIL PROTECTED] writes: Michael If you're not planning on your tests modifying the test tree at all, Michael you can probably just get away with having t/tree/... as a bunch of Michael normal files and directorys in the tarball. Don't ship a seperate Michael tar file, that introduces unnecessary dependencies. oh. duh. Yeah, that makes great sense. I can add local symlinks and hardlinks. I'll compute ownership out-of-band and compare it to the test result though... I wouldn't want someone extracting this as joebloe to fail because the uid wasn't root. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: testing File::Finder
Op een winterige herfstdag (Thursday 18 December 2003 22:44), schreef Randal L. Schwartz: Michael == Michael G Schwern [EMAIL PROTECTED] writes: Michael If you're not planning on your tests modifying the test tree at all, Michael you can probably just get away with having t/tree/... as a bunch of Michael normal files and directorys in the tarball. Don't ship a seperate Michael tar file, that introduces unnecessary dependencies. oh. duh. Yeah, that makes great sense. I can add local symlinks and hardlinks. Oh yeah, that's just great! Exclude all them poor Win32 users! Please stick to the advice Schwern gave and ship with a true directory tree (or a script that creates one) for your testing! I'll compute ownership out-of-band and compare it to the test result though... I wouldn't want someone extracting this as joebloe to fail because the uid wasn't root. :) what's 'root' ;-) Good luck, Abe -- Jarkko Hietaniemi is actually the code name for a whole team of Finnish super-programmers, capable of working continuously 25 hours a day without tripping each other up, and running solely only on intravenous caffeine. -- Nicholas Clark on p5p @ 2002-03-04
Re: More object stuff
Dan Sugalski wrote: It's util/ncidef2pasm.pl, actually. build_nativecall builds the stub routines for the interpreter if a JIT isn't available. The definitions of the characters are the same, but ncidef2pasm's a bit better documented. (There's embedded POD) Invocation is: perl util/ncidef2pasm.pl definition_file output.pasm I have done postgres.declarations, please see below. Woo! And, might I add, hoo! :) Thanks. Do you want me to do anything else with it. The script above works fine on the file. h
[perl #24692] Re: NJZPUXCJ, and the little
# New Ticket Created by Tanya # Please include the string: [perl #24692] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=24692 blackboard utah definition yalta corkscrew theodosian jura trail corinthian ed controlled demiscible ditty bloodstain chalkline arthritis myeline
[ANNOUNCE] Devel::Cover 0.29
On Mon, Dec 01, 2003 at 01:45:22AM +0100, Paul Johnson wrote: People seem to be using this module. I keep getting bug reports, suggestions and even patches ;-) Changes in this release: - Merge data from files with identical MD5 checksums (Arthur Bergman). - Add do test. - Handle $x || return. - Keep cover -delete happy when there is no existing database. - In cover, make -file a glob and add -exclude. - Watch for coverage options being set in cover (PERL5OPT set?). - Fix up html_basic and html_subtle. - Make 5.6.x builds a bit quieter. - Clean up time routines in XS code. The last change means that this release might have a better chance of working on Win32 systems. If anyone is able to try that, and optionally fix any problems, I'd be grateful. As usual, available from CPAN soon or my homepage now. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
