Re: DBI v2 - Data In and Data Out
On Wed, Jul 13, 2005 at 17:23:28 -0600, John Williams wrote: The proposals so far have dealt mostly with the SQL itself, and supporting database-neutral layers on top of DBI. Personally, I don't mind writing the SQL myself, I rarely need to make a particular statement work on two databases in my work, and I can optimize a lot better than any SQL generator. I like DBI shortcuts (selectrow_array, etc), and I would like them to become even more convenient in DBIv2, so I have been thinking about ways to streamline the movement of data in and out of DBI. I would like to propose one more output format, optimized for performance: The packed array is a piddle like interface, which is 0 overhead - no conversion or copying is made, the driver simply implements an IType over the native data that it can provide. Result matrices are given back in the natural buffer size of the driver, or a user defined setting. I also think that your compatibility concerns shouldn't matter - we already have DBI for perl 5. It provides all the compatibility we need. I'd like a more accessible binding interface, and more flexible placeholders (especially for safety). Since Perl 6 has more explicit types I'd like DBI to be able to leverage these, too. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgpYfegqIItE4.pgp Description: PGP signature
Re: WTF? - Re: method calls on $self
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote: Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) Aankhen
Re: Mobilizing PM groups for parrot..
On Jul 12, 2005, at 15:59, Will Coleda wrote: Hey, Allison - you drafted up the project plan for TPF grant for parrot, neh? Yup. With a good deal of input from Dan, Leo, Patrick and others. Are you the defacto Project Manager for parrot? Or is that position unfilled? Indeed I am. Parrot and Perl 6. Jesse Vincent has also taken on the role of assistant project manager lately. Allison
Re: User-defined infix subs/methods?
On Wed, 13 Jul 2005, Ingo Blechschmidt wrote: no, if I understood Larry correctly, you can of course write a nice grammar-modifying module, but other modules you use() still use Perl 6's standard grammar. E.g.: Ah, then of course I would have never expected things to be different at all. If you wanted the compiler to parse SomeOtherModule.pm using Ruby's grammar, you'd have to write: use Grammar::Ruby; reuse SomeOtherModule So that, after all, I don't think it would be much used since if SomeOtherModule was thought to be parsed according to Grammar::Ruby, it would take care of using it in the first place, I guess. Unless, of course, SomeOtherModule could be parsed correctly -and hopefully behave differently- under two or more different grammars, in which case it would be funny to see the effects of, say, use Grammar::Ruby; reuse SomeOtherModule; use Grammar::hq9plus; reuse SomeOtherModule; # ... which reminds me of good'ol' GEB... Michele -- Never attribute to malice that which can be adequately explained by stupidity - Hanlon's Razor
[perl #36530] r8613: win32 build failure in leo-ctx5 branch
# New Ticket Created by jerry gay # Please include the string: [perl #36530] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36530 make failure using win32--msvc-7.1--perl-5.8.6. the last few lines of the build output are: Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. rem blib\lib\libparrot_s.lib D:\usr\local\perl\bin\perl.exe build_tools\parrot_config_c.pl --mini src\null_config.c src\null_config.c null_config.c link -out:.\miniparrot.exe -nologo -nodefaultlib -debug -machine:x86 -debug imcc\main.obj blib\lib\libparrot_s.lib oldnames.lib kernel32.lib user 32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib ol eaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32 .lib odbccp32.lib msvcrt.lib src\null_config.obj Invoking Parrot to generate runtime\parrot\include\config.fpmc --cross your fing ers .\miniparrot.exe config_lib.pasm runtime\parrot\include\config.fpmc NMAKE : fatal error U1077: '.\miniparrot.exe' : return code '0xc005' Stop. looks like miniparrot is acting up, and i dunno why. the trunk builds fine at r8613. ~jerry
[perl #36531] r8613: t/src/manifest.t failure
# New Ticket Created by jerry gay # Please include the string: [perl #36531] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36531 t\src\manifest.ok 2/5 t\src\manifest.NOK 4# Failed test (t\src\manifest.t at line 69) # Missing files in svn:ignore: # ^languages/punie/.*\.pbc$ # ^languages/punie/.*\.pbc/ # ^languages/punie/Makefile$ # ^languages/punie/Makefile/ # Looks like you failed 1 test of 5. t\src\manifest.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 4 Failed 1/5 tests, 80.00% okay
[PATCH] 0.2.2/Cygwin compile and (mostly) test
Applying the attached patch (Nick Glencross's changes to
dynclasses_pl.in modified by Matt Diephouse's suggestion and then
cargoculting H.Merijn Brand's voodoo for working around some weirdness
that caused Test::Harness to completely empty @INC) to 0.2.2 lets me
build and limp through make test.
The Python dynclasses were still pretty unhappy campers:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/dynclass/foo.t8 2048 98 88.89% 1-5 7-9
t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13
t/dynclass/pybuiltin.t 5 1280 65 83.33% 1-2 4-6
t/dynclass/pyclass.t6 1536 66 100.00% 1-6
t/dynclass/pycomplex.t 4 1024 44 100.00% 1-4
t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4
t/dynclass/pyint.t 25 640026 25 96.15% 1-25
t/op/trans.t1 256191 5.26% 13
t/p6rules/anchors.t 255 6528026 52 200.00% 1-26
t/p6rules/builtins.t 255 6528038 76 200.00% 1-38
t/perl/Parrot_Distribution.t 255 65280 58 160.00% 2-5
t/perl/Parrot_Docs.t 255 6528025 38 152.00% 7-25
t/perl/Parrot_IO.t255 6528055 108 196.36% 2-55
2 tests and 80 subtests skipped.
Failed 13/162 test scripts, 91.98% okay. 207/2715 subtests failed, 92.38% okay.
make: *** [test] Error 14
Greg
diff -ru dist-parrot-0.2.2/config/gen/makefiles/dynclasses_pl.in
parrot-0.2.2/config/gen/makefiles/dynclasses_pl.in
--- dist-parrot-0.2.2/config/gen/makefiles/dynclasses_pl.in 2005-06-06
06:57:42.0 -0500
+++ parrot-0.2.2/config/gen/makefiles/dynclasses_pl.in 2005-07-13
15:42:19.161604500 -0500
@@ -46,6 +46,12 @@
$LD_LOAD_FLAGS =~ s/(-def:)/$extraLibs $1..\\/;
}
+# Here comes some stuff for Cygwin
+if ($^O eq 'cygwin') {
+$LD_LOAD_FLAGS .= ' ${build_dir}/src/parrot_config.o';
+$LIBPARROT = q[-L${build_dir}/blib/lib -lparrot];
+}
+
# PMC2C Config
our $PMC2C = $PERL $PATHQUOTE .
q[${build_dir}${slash}build_tools${slash}pmc2c.pl] . $PATHQUOTE;
@@ -72,11 +78,12 @@
}
return
-$LD $LDFLAGS $LD_LOAD_FLAGS $liblist $PATHQUOTE$LIBPARROT$PATHQUOTE .
-${ld_out} . $target . .
-join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources);
+$LD $LDFLAGS $LD_LOAD_FLAGS -o $target .
+join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources) .
+ $PATHQUOTE$LIBPARROT$PATHQUOTE $liblist;
}
+
our $NOW = time();
### MAIN PROGRAM
diff -ru dist-parrot-0.2.2/t/harness parrot-0.2.2/t/harness
--- dist-parrot-0.2.2/t/harness 2005-04-11 04:49:42.0 -0500
+++ parrot-0.2.2/t/harness 2005-07-13 16:51:29.348938800 -0500
@@ -80,6 +80,9 @@
use Getopt::Std;
use Test::Harness qw(runtests);
+my @_INC = map { qq{-I$_} } @INC;
+$Test::Harness::Switches = @_INC -Mstrict;
+
# handle the long options
$ENV{RUNNING_MAKE_TEST} = grep { $_ eq '--running-make-test' } @ARGV;
Re: What do use and require evaluate to?
Larry Wall [EMAIL PROTECTED] writes: On Tue, Jul 12, 2005 at 08:48:41PM +0300, Gaal Yahas wrote: : I propose to throw away the filesystem coupling, and map from a more : general name of the bit of code we are requiring to a more general : description of which instance of it we actually got. Once modules return : interesting values, it might be useful to keep a copy of that value : somewhere on the value side of %*INC: or else turn it inside out and : stipulate that a standard field in the Module object is where you got : this particular module. Yes, that's basically what I was mumbling about in my response. Now just make sure %*INC is lexically scoped. : Probably, %*INC values should be weak references. Why should they be weak references? If %*INC is lexically scoped then its entries represent this lexical scope's *real* references to modules, and there's no need to weaken them, since it's not functioning as some kind of cache. As long as this lexical scope sticks around, it needs the modules it points to. As soon as the lexical scope is destroyed, it doesn't need them any more. (Counting all closures over this lexical scope as preserving its needfulness, until all such closures are dead objects.) It's my conjecture that any explicit need for weak references probably indicates a design failure somewhere. Something like the mis-scoping of a reference variable, or maybe only something niggly like the absence of a feature like is cached to encapsulate weak semantics. Or maybe something as major as the lack of robust GC, in the case of Perl 5... So long as there's some way of asking the garbage collector for everything in the live set so you can grep through them I'm sure you're right. Because almost everything is extensible at runtime a class is going to need some way of finding all its (and its subclasses) instances so it can update 'em when/if it's definition changes. I'm also trying to think how an object/database mapper could be made to work effectively without being able to keep track of all its managed objects, or would that just be handled through the use of 'is cached'?
Re: [perl #36540] [PATCH] Cygwin/0.2.2 compile and test
The permission denied message stems from the DLLs not having execute permissions, which is the same as the existing problem with HP-UX. http://rt.perl.org/rt3/Ticket/Display.html?id=36119 I did actually manage to get most of the dynclasses to pass 'make test' by partly hacking Makefiles and performing some steps manually on the command line. I can type up some notes on my recipe... There are some problems though as libparrot.dll needs to be built instead of libparrot.a, and this causes some problems with miniparrot and the *_config.o files. Nick Greg Bacon wrote: # New Ticket Created by Greg Bacon # Please include the string: [perl #36540] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36540 Using the attached patch, which contains Nick Glencross's change to dynclasses_pl.in modified by a suggestion from Matt Diephouse and also cargoculting H.Merijn Brand's voodoo to work around a problem that caused Test::Harness to empty @INC, I can at least build and scratch through make test. The dynclasses tests were pretty unhappy, all seeming to stem from Couldn't load '/tmp/parrot-0.2.2/runtime/parrot/dynext/python_group.dll': Permission denied. Summary below: Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 8 2048 98 88.89% 1-5 7-9 t/dynclass/gdbmhash.t13 332813 13 100.00% 1-13 t/dynclass/pybuiltin.t5 1280 65 83.33% 1-2 4-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t4 1024 44 100.00% 1-4 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/dynclass/pyint.t 25 640026 25 96.15% 1-25 t/op/trans.t 1 256191 5.26% 13 2 tests and 80 subtests skipped. Failed 8/162 test scripts, 95.06% okay. 66/2715 subtests failed, 97.57% okay. make: *** [test] Error 14
Re: Need to talk to an EU patent attorney
On Tue, 2005-07-12 at 14:00 -0700, Michael G Schwern wrote:
I've also
attempted to contact the Inventors listed on the patent (valid email
addresses are difficult to find these days) in the hopes of discussing
this
programmer-to-programmer and cut through the legal BS. Haven't heard
back yet.
My guess is that you could add a comment here:
http://gauss.ffii.org/PatentView/EP1170667/Comments?action=editbackto=PatentView/EP1170667
and express your point of view.
I hope this patent will not be granted ...
--
#!/usr/bin/perl -w ###
use strict;###
( $_ = qq{0912 3c1217 709073043p2it//,
'70kc1H 270P 70htonA t3uJ tni7p'8;})
=~tr/42179038/(larves)/;eval#uate;
##
Re: Need to talk to an EU patent attorney
On Thu, Jul 14, 2005 at 01:45:11PM +0300, George Nistorica wrote: My guess is that you could add a comment here: http://gauss.ffii.org/PatentView/EP1170667/Comments?action=editbackto=PatentView/EP1170667 and express your point of view. I hope this patent will not be granted ... Its already been granted. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: Need to talk to an EU patent attorney
On Thu, 2005-07-14 at 03:52 -0700, Michael G Schwern wrote:
On Thu, Jul 14, 2005 at 01:45:11PM +0300, George Nistorica wrote:
My guess is that you could add a comment here:
http://gauss.ffii.org/PatentView/EP1170667/Comments?action=editbackto=PatentView/EP1170667
and express your point of view.
I hope this patent will not be granted ...
Its already been granted.
Indeed, but still, it can be revoked by EPO. That's what I'm hoping,
that it will be revoked.
--
#!/usr/bin/perl -w ###
use strict;###
( $_ = qq{0912 3c1217 709073043p2it//,
'70kc1H 270P 70htonA t3uJ tni7p'8;})
=~tr/42179038/(larves)/;eval#uate;
##
Re: [perl #36540] [PATCH] Cygwin/0.2.2 compile and test
Guys, As suggested, here are some manual steps which can get a few more tests passing on cygwin. The 'problem' is that the dynclass DLLs when loaded cannot access symbols in the parrot executable, so libparrot.dll needs building and the dynclasses linking against it. If there turns out to be a flag or symbol export mechanism, then that solves things! 1. Build parrot with Greg's patch 2. Edit the top-level makefile, amending the build line for blib/lib/libparrot$(SHARE_EXT) to add $(SRC_DIR)/parrot_config$(O) 3. make shared # Nice. You now have libparrot.dll 4. gcc -o parrot.exe -s imcc/main.o blib/lib/libparrot.dll -lcrypt 5. PATH=$PATH:`pwd`/blib/lib 6. rm dynclasses/*.o 7. rm blib/lib/libparrot.a # So that dynclasses link against the DLL 8. make dynclasses 9. chmod 755 runtime/parrot/dynext/*.dll # Fixed by #36119 10. make dynclasses-test All being well, you should get Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13 3 subtests skipped. Failed 1/7 test scripts, 85.71% okay. 13/68 subtests failed, 80.88% okay. make[1]: *** [test] Error 14 I'm not sure why the gdbmhash tests fail -- I haven't looked into it. It says: no extension: file 'libgdbm' Updating the build process is not straightforward because libparrot.dll has been built against parrot_config.o, and miniparrot has already been built in step #1. Anyhow, hopefully it has helped ... Nick Nick Glencross wrote: The permission denied message stems from the DLLs not having execute permissions, which is the same as the existing problem with HP-UX. http://rt.perl.org/rt3/Ticket/Display.html?id=36119 I did actually manage to get most of the dynclasses to pass 'make test' by partly hacking Makefiles and performing some steps manually on the command line. I can type up some notes on my recipe... There are some problems though as libparrot.dll needs to be built instead of libparrot.a, and this causes some problems with miniparrot and the *_config.o files. Nick Greg Bacon wrote: # New Ticket Created by Greg Bacon # Please include the string: [perl #36540] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36540 Using the attached patch, which contains Nick Glencross's change to dynclasses_pl.in modified by a suggestion from Matt Diephouse and also cargoculting H.Merijn Brand's voodoo to work around a problem that caused Test::Harness to empty @INC, I can at least build and scratch through make test. The dynclasses tests were pretty unhappy, all seeming to stem from Couldn't load '/tmp/parrot-0.2.2/runtime/parrot/dynext/python_group.dll': Permission denied. Summary below: Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 8 2048 98 88.89% 1-5 7-9 t/dynclass/gdbmhash.t13 332813 13 100.00% 1-13 t/dynclass/pybuiltin.t5 1280 65 83.33% 1-2 4-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t4 1024 44 100.00% 1-4 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/dynclass/pyint.t 25 640026 25 96.15% 1-25 t/op/trans.t 1 256191 5.26% 13 2 tests and 80 subtests skipped. Failed 8/162 test scripts, 95.06% okay. 66/2715 subtests failed, 97.57% okay. make: *** [test] Error 14
Re: [perl #36540] [PATCH] Cygwin/0.2.2 compile and test
One final note. Unlike 'make dynclasses-test', 'make test' will spot that libparrot.a has been deleted and rebuild it and parrot.exe. You might want to finish up with: 11. make 12. Repeat step 4. 13. make test All very hacky, I know. Cheers, Nick Nick Glencross wrote: Guys, As suggested, here are some manual steps which can get a few more tests passing on cygwin. The 'problem' is that the dynclass DLLs when loaded cannot access symbols in the parrot executable, so libparrot.dll needs building and the dynclasses linking against it. If there turns out to be a flag or symbol export mechanism, then that solves things! 1. Build parrot with Greg's patch 2. Edit the top-level makefile, amending the build line for blib/lib/libparrot$(SHARE_EXT) to add $(SRC_DIR)/parrot_config$(O) 3. make shared # Nice. You now have libparrot.dll 4. gcc -o parrot.exe -s imcc/main.o blib/lib/libparrot.dll -lcrypt 5. PATH=$PATH:`pwd`/blib/lib 6. rm dynclasses/*.o 7. rm blib/lib/libparrot.a # So that dynclasses link against the DLL 8. make dynclasses 9. chmod 755 runtime/parrot/dynext/*.dll # Fixed by #36119 10. make dynclasses-test All being well, you should get Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13 3 subtests skipped. Failed 1/7 test scripts, 85.71% okay. 13/68 subtests failed, 80.88% okay. make[1]: *** [test] Error 14 I'm not sure why the gdbmhash tests fail -- I haven't looked into it. It says: no extension: file 'libgdbm' Updating the build process is not straightforward because libparrot.dll has been built against parrot_config.o, and miniparrot has already been built in step #1. Anyhow, hopefully it has helped ... Nick Nick Glencross wrote: The permission denied message stems from the DLLs not having execute permissions, which is the same as the existing problem with HP-UX. http://rt.perl.org/rt3/Ticket/Display.html?id=36119 I did actually manage to get most of the dynclasses to pass 'make test' by partly hacking Makefiles and performing some steps manually on the command line. I can type up some notes on my recipe... There are some problems though as libparrot.dll needs to be built instead of libparrot.a, and this causes some problems with miniparrot and the *_config.o files. Nick Greg Bacon wrote: # New Ticket Created by Greg Bacon # Please include the string: [perl #36540] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36540 Using the attached patch, which contains Nick Glencross's change to dynclasses_pl.in modified by a suggestion from Matt Diephouse and also cargoculting H.Merijn Brand's voodoo to work around a problem that caused Test::Harness to empty @INC, I can at least build and scratch through make test. The dynclasses tests were pretty unhappy, all seeming to stem from Couldn't load '/tmp/parrot-0.2.2/runtime/parrot/dynext/python_group.dll': Permission denied. Summary below: Failed TestStat Wstat Total Fail Failed List of Failed --- t/dynclass/foo.t 8 2048 98 88.89% 1-5 7-9 t/dynclass/gdbmhash.t13 332813 13 100.00% 1-13 t/dynclass/pybuiltin.t5 1280 65 83.33% 1-2 4-6 t/dynclass/pyclass.t 6 1536 66 100.00% 1-6 t/dynclass/pycomplex.t4 1024 44 100.00% 1-4 t/dynclass/pyfunc.t 4 1024 44 100.00% 1-4 t/dynclass/pyint.t 25 640026 25 96.15% 1-25 t/op/trans.t 1 256191 5.26% 13 2 tests and 80 subtests skipped. Failed 8/162 test scripts, 95.06% okay. 66/2715 subtests failed, 97.57% okay. make: *** [test] Error 14
Re: Mobilizing PM groups for parrot..
On Jul 14, 2005, at 3:15 AM, Allison Randal wrote: On Jul 12, 2005, at 15:59, Will Coleda wrote: Hey, Allison - you drafted up the project plan for TPF grant for parrot, neh? Yup. With a good deal of input from Dan, Leo, Patrick and others. Are you the defacto Project Manager for parrot? Or is that position unfilled? Indeed I am. Parrot and Perl 6. Jesse Vincent has also taken on the role of assistant project manager lately. Allison MUahahahahaha, my trap has been sprung! Perfect. I've been looking for you since before we lost Dan. =-) Had I know this at the conference, I would have had a much longer conversation with you. =-) I have a .. few.. questions for you. Hopefully none of them are *overly* snarky. Some progress has been made dealing with issues like this since I originally started bringing them up, but I think there's still room for improvement. - Where is parrot's current project plan? - Does it have any more details than the high level grant plan that was used to fund leo? - How does the monthly release cycle fit into this plan? - How do we tie in the items that are in RT and docs/ROADMAP to the plan? - Given current staffing and work remaining, what is your best guess on a 1.0 release? And a few observations (some of which overlap) - without a detailed description, we won't know when we're done. (The high level plan obviously helps here, but it's not pass this test suite and we're done.). - Someone I respect very much *cough* said, but you need a bunch of small, achievable goals. I don't think parrot currently has this. I *think* that having a project plan will help here, but having a project -manager- would be even better. - RT is slow. painfully slow. And not just for leo (for whom it should be very very fast and stay out of his way.). - Yes, I know you can't map a corporate PM mentality onto an open source project and have it stick. But I think there's a lot to be used from more formal methodologies. - The Architect is not necessarily the Project Manager. The roles have been conflated, I think, because most people don't know parrot has (had?) a PM. - We need to expose the process along with the code: because of the nature of our workforce, we need to make it much easier to pick and choose things to work on. - When possible, things should be on parrotcode.org; even better if it's just something from svn-latest that's been automatically web-ified.
Re: Mobilizing PM groups for parrot..
On Thu, Jul 14, 2005 at 10:26:54AM -0400, Will Coleda wrote: I have a .. few.. questions for you. Hopefully none of them are *overly* snarky. Some progress has been made dealing with issues like Being snarky on a public mailing list is not a good way to win friends an influence people. You have a lot to learn in this area, I see. Do not forget that when dealing with volunteers, they are just that, and have the ability to take umbrage and drop everything there and then. Nicholas Clark
Tcl GC Issues... Solved
As of r8617, the GC bug that ParTcl occasionally tickled has been fixed. This is a relief as it caused some odd behavior and many hours were spent by Will Coleda and Leo trying to debug. Thanks to both of them for their efforts and thanks to Leo for finally catching the bug! -- matt diephouse http://matt.diephouse.com
Re: [PATCH] 0.2.2/Cygwin compile and (mostly) test
Greg Bacon wrote: Applying the attached patch (Nick Glencross's changes to dynclasses_pl.in modified by Matt Diephouse's suggestion and then cargoculting H.Merijn Brand's voodoo for working around some weirdness that caused Test::Harness to completely empty @INC) to 0.2.2 lets me build and limp through make test. Could folks with some windows fu and ci permissions please take care of win32 patches. I can't test it. Thanks, leo
Re: vtable changes?
Nicholas Clark wrote: There were some PMC vtable changes recently. Are any more expected, or is the vtable size/disposition expected to remain unchanged from here on? I expect some additional PMC-only vtable functions needed for representing: *) $n = +$x; *) $s = ~$x; *) $b = ?$x; We have a rather complete list of vtables with native types, but PMC only variants aren't really complete. And as the vtables are already huge, I expect them to be split. But this should be transparent to existing code. Nicholas Clark leo
Re: Partioning PMCs
Nicholas Clark wrote: However, I'm still stuck on: #define ponie_pmc(pmc) ??? here ??? pmc-vtable-flags PONIE_BIT? Nicholas Clark leo
Re: PMC changes?
Nicholas Clark wrote: Is the PMC layout likely to remain stable? There's been talk of minimal PMC heads (data, vtable) in relation to the generational garbage collector proposals. Is this likely to happen? Related to this there has been talk of variable sized bodies. I'd like to have a small head and variable sized bodies. Now we have a rigid structure (or rather two: PMC, PMC_EXT), and the variable part e.g. object attributes hangs off another structure in pmc-pmc_ext-data. This is not only suboptimal from data locality or access time POV, it's more a serious restriction, how you lay out your PMC data. WRT generational GC: yes such a PMC layout is very likely needed to be able to partition your existing PMCs into generations. src/gc_gms.c tries a different approach and needs 4 extra pointers per PMC. If there are changes, how much of the existing API will still work? Will code using the macros in parrot/pobj.h need much changing? I don't expect much changes, because these macros exist and and used. PMCs can be switched one by one (mostly) to use a new data layout, but that again schould be transparent, if you use VTABLE_foo. Nicholas Clark leo
Re: WTF? - Re: method calls on $self
On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. // Carl
Re: WTF? - Re: method calls on $self
If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. Thanks, /Autrijus/ pgpWxBG7sIi5K.pgp Description: PGP signature
Re: DBI v2 - The Plan and How You Can Help
On 7/14/05, Sam Vilain [EMAIL PROTECTED] wrote: Of course it will be entirely possible to layer support for this sort of thing atop any DBI interface; Exactly my point. Please be so kind as to implement your ideas in a DBI extension. Time and community will prove whether you are right by using your extension or not. Fact is, that there are quite some drivers which will never be able to adhere to your wishes. Blocking them implementing a DBI2 driver seems (to me) to be a larger problem, compared with the need of using a DBI2 subclass and not DBI2 directly. Jochen -- What are the first steps on the moon, compared to your child's?
Re: refcounting hash
Nicholas Clark wrote: I'd like to be able to provide this as a non-singleton PMC class, with the addition of a value lookup, and (possibly) iteration. But cut and paste is evil. Well, the more general question is: how can we parameterize our aggregates. We already have tons of arrays with (bit, double, int, PMC*, STRING*) values. For hashes it could get worse: key /value STRING* /PMC* Hash PMC * /PMC * Python / Perl6 PMC /INTVALref hash x yPerl6 The hash functions in src/hash.c can handle this (probably), with key/value type and with user defined compare/hash functions already inside.. We need an interface above that constructs appropriate vtable pieces for key and value access from the PMC side. Nicholas Clark For now cp helps :-) leo
Re: signals and events
Nicholas Clark wrote: What is the state of signals and events support? As far as I can tell from watching which perl 5 regression tests fail or hang under parrot, currently parrot can't behave as a passive embedding target - it assumes that it needs to take ownership of all signals. Parrot currently captures SIGHUP for testing (I don't remember if other signals are blocked) And yes, there is no interface whatsoever to pass a signal on, or some such. Is this likely to change soon? We need an API. . Nicholas Clark leo
[perl #36548] GHC bugs
# New Ticket Created by Simon Marlow
# Please include the string: [perl #36548]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36548
Hi,
I've been trying in vain over the last day or so to reproduce the
following GHC bugs, both allegedly demonstrated by Pugs:
[ 1226252 ] internal error: EVACUATED object entered!
http://sourceforge.net/tracker/index.php?func=detailaid=1222522group_i
d=8032atid=108032
[ 1222522 ] scavenge_stack: weird activation record found on stack:37548
http://sourceforge.net/tracker/index.php?func=detailaid=1222522group_i
d=8032atid=108032
I checked out the exact revisions using SVN as specified in the bug
reports, and I've tried various combinations of {1386,x86_64},
{Linux,FreeBSD}, {GHC 6.4, 6.4.1-STABLE}, {optimised,unoptimised}. I do
indeed get test failures for the t/oo/desctruction.t test, but no
crashes. For example, on the FreeBSD/x86/optimised build I just did:
~/local/pugs GHCRTS=-H1m PERL_DL_NONLAZY=1 /usr/local/bin/perl
-I../../inc -I../inc -Iinc -MExtUtils::Command::MM -e
ENV-{HARNESS_PERL} = q{/home/simonmar/local/pugs/blib/script/pugs};
@ARGV = map glob, @ARGV; ENV-{PERL6LIB} =
q{/home/simonmar/local/pugs/blib6/lib}; test_harness(0, 'inc',
'/home/simonmar/local/pugs/blib/lib',
'/home/simonmar/local/pugs/blib/arch') t/oo/destruction.t
t/oo/destructionNOK 5# Looks like you failed 2 tests of 6
t/oo/destructionFAILED tests 4-5
Failed 2/6 tests, 66.67% okay
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/oo/destruction.t62 33.33% 4-5
Failed 1/1 test scripts, 0.00% okay. 2/6 subtests failed, 66.67% okay.
I can vary the success rate by altering GHC's garbage collector options
(e.g. the GHCRTS setting in the command above).
At this point I'm stuck. I don't doubt there's a bug somewhere, but
it's not showing itself for me.
If someone can provide me with a temporary account on a machine that
demonstrates the bug, that would be great. SSH key available on
request. Even better if you could set me up with an account and a Pugs
build tree all ready to go.
I've spent too much time on this to give up now!
Cheers,
Simon
Re: embedding/extending interface
chromatic wrote: On Wed, 2005-07-13 at 15:41 +0100, Nicholas Clark wrote: Did anything come of this? Or is chromatic still waiting in the wings for confirmation that this is the right way to go? I'm still waiting for confirmation. I can send my existing (needs polish) patch if that will help speed the discussion. As long as the program doesn't generate 'void retval; ... return retval;', it's ok for me ;-) -- c leo
Re: MML dispatch
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: Manhattan distance is
better.
Damian writes:
Similarly, since the number of potential variants is the Cartesian product of
the total sizes of the class hierarch(y|ies) for each parameter position,
getting adequate coverage of the MMD search space quickly becomes tedious if
most of the search space is (by default) ambiguous, as in pure ordering
dispatch schemes.
Indeed, pure MMD will be ambiguous in more cases. If you think
narrowly, then it causes you to write many disambiguating cases which
*usually* end up being what a manhattan metric would give you anyway.
But you can get away from that terrible duplication by being more
precise about your types. You can define type classes using empty
roles[1], where you simply organize your type dag into abstractions
that make sense to your dispatcher. The upshot of all this is that it
forces you to think in a way so that the *usually* above becomes an
always. And it involves defining more (very small) types that make
sense to humans, not gratuitously many MMD variants which are pretty
hard to think about.
One very common problem with pure ordering schemes is that subsequent changes
in one or more class hierarchies can cause previously unambiguous cases to
become ambiguous, by extending a zone of ambiguity in the search space.
In
contrast, because a metric approach always fully partitions the entire search
space, hierarchy changes may alter where a particular call dispatches to, but
only ever to a closer, more appropriate variant.
You just made my primary argument against manhattan distance for me.
If you change something in the middle of the class hierarchy,
manhattan distance causes multimethods on the leaves to change
semantics. You say that pure MMD causes them to break when a change
occurs. Isn't that better than changing? Presumably you ran it
through the ambiguity checker and a test suite and got it right once,
and then you have to do it again when you refactor. This comes with
the meaningless unit derivation that a metric scheme defines.
Perhaps I've made this argument before, but let me just ask a
question: if B derives from A, C derives from A, and D derives from
C, is it sensible to say that D is more derived from A than B is?
Now consider the following definitions:
class A { }
class B is A {
method foo () { 1 }
method bar () { 2 }
method baz () { 3 }
}
class C is A {
method foo () { 1 }
}
class D is C {
method bar () { 2 }
}
Now it looks like B is more derived than D is. But that is, of
course, impossible to tell. Basically I'm saying that you can't tell
the relative relationship of D and B when talking about A. They're
both derived by some amount that is impossible for a compiler to
detect. What you *can* say is that D is more derived than C.
In conclusion, the reason that manhattan distance scares me so, and
the reason that I'm not satisfied with use mmd 'pure' is that for
the builtins that heavily use MMD, we require *precision rather than
dwimmyness*. A module author who /inserts/ a type in the standard
hierarchy can change the semantics of things that aren't aware that
that type even exists. If you're going to go messing with the
standard types, you'd better be clear about your abstractions, and if
you're not, the program deserves to die, not dwim around it.
Oh, and the mmd style should probably look like:
multi foo (...) is mmdpure {...}
multi bar (...) is mmdmanhattan {...}
Rather than a pragma.
Note too that Perl 6 *will* still support a form of pure ordered dispatch--a
left-most-closest-match scheme like that used by CLOS--via invocant groups:
multi sub Foo(A: B: C:) {...}
multi sub Foo(A: D: C:) {...}
multi sub Foo(F: B: G:) {...}
This, of course, is not global pure ordering, but rather left-biased pure
ordering.
To summarize: pure ordering renders more of the MMD search space ambiguous,
which is potentially safer but much less DWIMish. Metric schemes have far
fewer ambiguities and usually dispatch in an predictable way. Metric schemes
can still provide pure-ordering analyses via static analysis tools or special
warning modes, but pure ordering schemes can't avoid ambiguities or DWIM.
Of course, none of this prevents:
use MMD pure;
Damian
Luke
[1] And I find this to be useful even when using manhattan distance.
I'd like to be able to define such type classes out-of-band, like:
role Foo
defines Bar # Bar does Foo now
defines Baz # Baz does Foo now
{ }
more .method (was: Perl 6 Summary for 2005-07-05 through 2005-07-12)
On Wed, 13 Jul 2005, Juerd wrote: Dave Whipp skribis 2005-07-13 8:44 (-0700): Within a method or submethod, C.method only works when C$_ =:= $?SELF. C.method is perfectly legal on *any* topic anywhere that $?SELF doesn't exist. Just to be clear, this includes any method/submethod with an explicitly named invocant, I hope. No, $?SELF exists in every method. It's not the *default* invocant variable, it's the *always there* invocant variable. There is no default variable anywhere in the language that isn't $_. Actually I took his question to be: If I explicitly name my invocant in the method signature, does that give the compiler enough assurance that I'm not going to use .method to mean $?SELF.method, and it will allow me to safely use .method as $_.method in for and given? ~ John Williams
Re: What do use and require evaluate to?
On Thu, Jul 14, 2005 at 11:09:40AM +0100, Piers Cawley wrote: : So long as there's some way of asking the garbage collector for everything in : the live set so you can grep through them I'm sure you're right. Because almost : everything is extensible at runtime a class is going to need some way of : finding all its (and its subclasses) instances so it can update 'em when/if : it's definition changes. I'm also trying to think how an object/database mapper : could be made to work effectively without being able to keep track of all its : managed objects, or would that just be handled through the use of 'is cached'? I just said it was my conjecture. That doesn't mean I think it's right. :-) Larry
Re: User-defined infix subs/methods?
On Thu, Jul 14, 2005 at 09:19:29AM +0800, Autrijus Tang wrote: : Within perl 5, there is an extremely easy way to write that, namely : coderef in @INC that provides line-based filtering: : : http://search.cpan.org/dist/Acme-use-strict-with-pride/pride.pm : : Are we to discontinue use of [EMAIL PROTECTED], and switch to the : slightly more difficult but far more manageable approach of rebinding : *require? I suppose that depends in part on whether we want to guarantee the @INC interface for Perl 6 at all. Or it may be that we keep @INC but make it point to abstract repositories rather than just directories. And maybe some of those repositories have an interface with active components. Or maybe @INC is a list of repository locating commands with optional arguments. Maybe @INC is *all* closures that return a package object or fail. Maybe @INC is just a fancy rule. I dunno. Nobody's actually designed the library system yet. It would be nice if it degenerated to a simple file lookup in list of a simple directories, I suppose, since that's the current Perl-think, but that doesn't mean we have to cap the abstraction at the top. I suppose what it comes down to is that we'll still have @INC, and allow closures in it, and probably pull in the standard library with a closure that knows how to load standard modules efficiently. Whether or not the standard library is represented by a closure in @INC, the standard library needs to have some kind of placeholder in the list so that users can put overrides in front of it or defaults in back of it. Or @INC has to be split into a @PREINC plus @POSTINC, but a single @INC seems simpler, and also allows multiple standard libraries, as long as there's some way to name them. Larry
Re: [PATCH] 0.2.2/Cygwin compile and (mostly) test
On Jul 14, 2005, at 17:31, Leopold Toetsch wrote: Could folks with some windows fu and ci permissions please take care of win32 patches. I can't test it. Another note: if you (aka a windows hacker, person-unspecific) don't have svn ci permissions, and can test and manage windows related patches (at first, but not exclusive of course), please write in PM to either me or chip and include your auth.perl account info. We'll provide an account. Thanks, leo leo - we need better windows support
Re: Mobilizing PM groups for parrot..
On Jul 14, 2005, at 7:26, Will Coleda wrote: MUahahahahaha, my trap has been sprung! Perfect. I've been looking for you since before we lost Dan. =-) Had I know this at the conference, I would have had a much longer conversation with you. =-) I can't say I've ever made any secret of the fact. :) http://dev.perl.org/perl6/people.html I have a .. few.. questions for you. Hopefully none of them are *overly* snarky. Some progress has been made dealing with issues like this since I originally started bringing them up, but I think there's still room for improvement. - Where is parrot's current project plan? - Does it have any more details than the high level grant plan that was used to fund leo? Yes and no. We have a good bit more detail, but not all of it is written down. The first milestone of the grant is all documentation precisely because we recognized this fact. - How does the monthly release cycle fit into this plan? Monthly releases promote stability, and improve public visibility of the progress of the project. - How do we tie in the items that are in RT and docs/ROADMAP to the plan? The ROADMAP provides some details beyond the grant proposal. RT is bugfixes, not a project planning tool. - Given current staffing and work remaining, what is your best guess on a 1.0 release? The first law of managing open source projects is no dates. I can give you approximate developer-hours: 1 year of two full-time developers. We're into about the 3rd month of two full-time funded developers, but our velocity has been slowed by the process of Chip needing to assimilate the entire architecture of Parrot in a single gulp. (He's doing quite well at it too.) And a few observations (some of which overlap) - without a detailed description, we won't know when we're done. (The high level plan obviously helps here, but it's not pass this test suite and we're done.). - Someone I respect very much *cough* said, but you need a bunch of small, achievable goals. I don't think parrot currently has this. I *think* that having a project plan will help here, but having a project -manager- would be even better. - Yes, I know you can't map a corporate PM mentality onto an open source project and have it stick. But I think there's a lot to be used from more formal methodologies. There's a deeper philosophy difference here between Agile methodologies and the more traditional methodologies. Perl and Parrot have always been Agile projects. So, no, we don't spend months writing up detailed specification documents, and waterfall charts and Gantt charts. We won't know we're done when we check off the appropriate number of boxes (that's a terrible way to gauge code quality anyway). We will know we're at a stage when we can make a 1.0 release (not exactly the same thing as being done) when the 9 critical subsystems are fully featured enough to support compilers on our major target languages, and stable enough to be considered production code. - RT is slow. painfully slow. And not just for leo (for whom it should be very very fast and stay out of his way.). I'll talk with Ask and Robert about this. It may be something a hardware upgrade could solve. - The Architect is not necessarily the Project Manager. The roles have been conflated, I think, because most people don't know parrot has (had?) a PM. Not really. There was always a clear distinction between Dan's role and my role. My role didn't require active participation on the mailing list. My role is changing now, partly because I'm tying up the legal side of things and getting more time to participate in development (thank goodness), and partly because the Allison-Chip-Leo team has a slightly different tone than the Allison-Dan-Leo team (which is perfectly natural when changing who fills a significant role). - We need to expose the process along with the code: because of the nature of our workforce, we need to make it much easier to pick and choose things to work on. - When possible, things should be on parrotcode.org; even better if it's just something from svn-latest that's been automatically web-ified. I agree with this. The documentation and webpages have become sorely out of date in the past year. This is one of Chip's big priorities (as he mentioned in his talk at YAPC::NA). So, summarizing, we've identified a big need in the documentation and public information area. Are you volunteering to help out there? The first place to start is updating the information on parrotcode.org. Allison
Re: [perl #36540] [PATCH] Cygwin/0.2.2 compile and test
In message [EMAIL PROTECTED], Nick Glencross via RT writes: : One final note. Unlike 'make dynclasses-test', 'make test' will spot : that libparrot.a has been deleted and rebuild it and parrot.exe. : : You might want to finish up with: : : 11. make : : 12. Repeat step 4. : : 13. make test : : All very hacky, I know. Works on my side too. Following steps 1 through 13, I see Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13 t/op/trans.t 1 256191 5.26% 13 2 tests and 80 subtests skipped. Failed 2/162 test scripts, 98.77% okay. 14/2715 subtests failed, 99.48% okay. make: *** [test] Error 14 Greg
creating threas in BEGIN
This is more a note to collective 'self' question than one I expect the answer to right now. (The answer I expect right now is a glib it will) How will the perl6 compiler cope with people creating threads inside BEGIN blocks? Whatever the docs say, people do it in Perl 5 as soon as someone CUses the module they wrote that starts a thread in its body code. Which as I understand it isn't considered a completely good thing in Perl 5 land, because of the state of the state that the thread clones. Nicholas Clark
standard asynchronous deferred-to-result syntax RFP
I have uploaded asynchronous::universal::ready and asynchronous::universal::set_callback to CPAN. They are both entirely trivial packages with a mess of documentation. The idea behind them is to support asynchonous frameworks in which the immediate result of passing away a message is a placeholder object with a ready method that will return a false value until its result message comes back, at which time the placeholder upgrades itself to a result. To avoid mandating true ready methods for all objects in the cosmos that might get returned as the result of an asynchronous function, asynchronous::universal::ready provides a true ready method in UNIVERSAL. set_callback presumes two interfaces to an asynchronous framework, set_callback for declaring a coderef that is supposed to be run when the asynchronous function completes. Synchronous objects have already completed, so UNIVERSAL::set_callback runs the coderef immediately. The other interface is a method callback_queue which would give direct, framework-dependent access to the callback queue on an object, should such a thing exist in the given asynchronous framework. UNIVERSAL::callback_queue returns an empty arrayref. The hubristic hope is that authors of asynchronous frameworks will standardize on these interfaces: ready, set_callback, callback_queue. Thanks for listening, and I'll take my answer off the air. :-) -- David L Nicol Aesop's fables, with text-sensitive advertising: http://cronos.advenge.com/pc/aesop/start.html
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote: On 7/14/05, Juerd [EMAIL PROTECTED] wrote: It's just a Solomon judgement situation. That can work out well, but I really hate when it's forced and used to test patience. If Juerd is right about this being a solomonian situation, let me just give up my baby to the other woman by saying: * It's hers. It's not important what syntax you give it. `./` is ok, but I trust @larry to make the right choice there. * Please don't hurt my baby. Let `.foo` still mean `$_.foo`, unconditionally. That's all that really matters. Yes, let .foo still mean $_.foo, unconditionally, please. The `./` is nice, but I'm willing to give up the syntax in favor of letting .foo always mean $_.foo. Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. So long as .foo (pretty please) means $_.foo all the time (with sugar on top?). -kolibrie
Re: WTF? - Re: method calls on $self
Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Method Resolution Order question
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote: : The way I am viewing the notion of current class for submethods : currently is: : : From inside another method or submethod: : : - a submethod should only be called from the class which defines it. This doesn't sound right to me. There is no distinction between inside or outside. A submethod is simply a method that says These aren't the droids you're looking for if you call it via either SMD or MMD dispatch and the first invocant isn't of the exact run-time type of the lexical class. In other words, it just has an implicit next METHOD if $?SELF != $?CLASS; at the front. So the dispatch continues until it finds either a submethod that does have an exact match or a method that isn't a submethod. : This means that since Object::bless() calls Object::BUILDALL() it is : all well and good, assuming you have not overridden bless() in your : class, and are calling it $class.bless(). No, Object::bless() (which perhaps delegates to Class.meta.bless so that different meta classes can have different .bless primitives) calls MyClass.CREATE to create the type, while will be an opaque type if that normal method dispatch runs up the tree to Object::CREATE. (But user classes are allowed to define their own CREATE method to create non-opaque objects.) After the storage is allocated, .meta.bless then calls $newobj.BUILDALL as an ordinary method call on the instance. Again this is overridable by each class, but typically goes back to Object::BUILDALL (which, as usual, probably delegates at least some of the work to the meta class). : (Object::BUILDALL of course then digs into the metaclass to call : BUILD() for all the superclasses in post-order. I am not sure how to do : that otherwise, submethod or not.) I believe there's pseudo-code for that in A12. The trick is that you can always force a call to a submethod of the wrong class by taking it as a sub reference and calling it like an ordinary subroutine. : However, if you define MyClass::bless, then you will need to define : MyClass::BUILDALL as well. We did not intend that people redefined .bless. It's really intended to be a primitive like .meta. The occasional redefinables are CREATE and BUILDALL, but it's really only intended that BUILD be defined typically. : Or is it possible just do $self.Object::BUILDALL()? So can I call a : submethod from a different class if I fully qualify it? No, that would just fail. You have to do the reference casting trick to call it as an ordinary subroutine. We made that hard on purpose. : From outside a method (in user space): : : - the invocant of the submethod must be a direct instance of the class : in which the submethod is defined. No inheritance involved. : : Maybe this is too strict, though? What do you think? There is no user space distinction. You still just call a method with the ordinary dispatcher, and it still just runs down the list of dispatcher class candidates till it either finds one that's a method or finds one that is a submethod and whose class matches the object's. Of course, that's highly unlikely to match a submethod on anything but the first probe, given the usual visitation order of the standard dispatcher and the fact that virtual method calls always start with the actual run-tiem type of the object, but MMD might have a different idea about order, and the same principle still applies. Plus other dispatchers are possible. The point of a submethod is that it doesn't make sense to call it on anything other than an actual object of this type (where initialization and finalization are examples of where we basically lie about the actual type because we want the various bit of the current object treated as if they were really an ancestral class even though they aren't really). Since that's the point of a submethod, the proper place to put the constraint is on the front of the submethod itself, and let it just fail to be dispatched to if it doesn't want to be dispatched to. In general, unless you are a funny dispatcher like .*foo, you shouldn't be thinking about how you call them. : There's some kind of yes I mean : you notion in the dispatcher. It comes out in user-visible terms : in .*foo calls but not ordinary .foo calls, : : I am not familiar with .*foo calls? Can you elaborate? This is all pretty much straight from A12. : which call a submethod : only when the object is actually that type, and otherwise look for an : ancestral method of that name. : : Yes, to expand upon my above statements. The method resolution would : begin looking in the local submethod table, then move onto the local : method table, and then on up the superclass hierarchy. Is that correct? There is no separate submethod table. From the standpoint of ordinary .foo method resolution they're ordinary methods that happen to say next METHOD as a form of failure. The dispatcher doesn't even have to know they failed because they
Re: Mobilizing PM groups for parrot..
Ah, thank you for your quick reply! On Jul 14, 2005, at 2:56 PM, Allison Randal wrote: On Jul 14, 2005, at 7:26, Will Coleda wrote: MUahahahahaha, my trap has been sprung! Perfect. I've been looking for you since before we lost Dan. =-) Had I know this at the conference, I would have had a much longer conversation with you. =-) I can't say I've ever made any secret of the fact. :) http://dev.perl.org/perl6/people.html Perhaps we need a similar page on parrotcode. =-) I have a .. few.. questions for you. Hopefully none of them are *overly* snarky. Some progress has been made dealing with issues like this since I originally started bringing them up, but I think there's still room for improvement. - Where is parrot's current project plan? - Does it have any more details than the high level grant plan that was used to fund leo? Yes and no. We have a good bit more detail, but not all of it is written down. The first milestone of the grant is all documentation precisely because we recognized this fact. - How does the monthly release cycle fit into this plan? Monthly releases promote stability, and improve public visibility of the progress of the project. - How do we tie in the items that are in RT and docs/ROADMAP to the plan? The ROADMAP provides some details beyond the grant proposal. RT is bugfixes, not a project planning tool. Ok. Does parrot/perl6 have a project planning tool? Should we move all the TODO items *out* of RT, then? It would be helpful if someone looking for a simple thing to work on could browse *all* the work queues, and not have to worry about whether something was broken or just undone. (note that we *can* track a huge amount of this kind of information in RT, including estimate project durations. Robert has said that he can generate reports of the information in here. So if there isn't something else, it *might* be worthwhile to pursue RT. But my goal is merely to have it tracked consistently, not have it tracked in RT.) - Given current staffing and work remaining, what is your best guess on a 1.0 release? The first law of managing open source projects is no dates. I can give you approximate developer-hours: 1 year of two full-time developers. We're into about the 3rd month of two full-time funded developers, but our velocity has been slowed by the process of Chip needing to assimilate the entire architecture of Parrot in a single gulp. (He's doing quite well at it too.) I completely agree on durations instead of dates, and that's how I should have phrased the question, apologies. Even with no specific developers assigned to tasks, this is the sort of thing someone could get quickly from say, an MS Project file. Which I'm guessing you have something like. ^_^ (or, say, a custom RT report) And a few observations (some of which overlap) - without a detailed description, we won't know when we're done. (The high level plan obviously helps here, but it's not pass this test suite and we're done.). - Someone I respect very much *cough* said, but you need a bunch of small, achievable goals. I don't think parrot currently has this. I *think* that having a project plan will help here, but having a project -manager- would be even better. - Yes, I know you can't map a corporate PM mentality onto an open source project and have it stick. But I think there's a lot to be used from more formal methodologies. There's a deeper philosophy difference here between Agile methodologies and the more traditional methodologies. Perl and Parrot have always been Agile projects. So, no, we don't spend months writing up detailed specification documents, and waterfall charts and Gantt charts. We won't know we're done when we check off the appropriate number of boxes (that's a terrible way to gauge code quality anyway). We will know we're at a stage when we can make a 1.0 release (not exactly the same thing as being done) when the 9 critical subsystems are fully featured enough to support compilers on our major target languages, and stable enough to be considered production code. - RT is slow. painfully slow. And not just for leo (for whom it should be very very fast and stay out of his way.). I'll talk with Ask and Robert about this. It may be something a hardware upgrade could solve. - The Architect is not necessarily the Project Manager. The roles have been conflated, I think, because most people don't know parrot has (had?) a PM. Not really. There was always a clear distinction between Dan's role and my role. My role didn't require active participation on the mailing list. My role is changing now, partly because I'm tying up the legal side of things and getting more time to participate in development (thank goodness), and partly because the Allison-Chip- Leo team has a slightly different tone than the Allison-Dan-Leo
Re: creating threas in BEGIN
On 7/14/05, Nicholas Clark [EMAIL PROTECTED] wrote: This is more a note to collective 'self' question than one I expect the answer to right now. (The answer I expect right now is a glib it will) How will the perl6 compiler cope with people creating threads inside BEGIN blocks? A glib it won't. Unless someone can come up with a reason you would want to do that. Perl 6's compilation model is such that you can't do anything at compile time under the assumption that you will be running it in the same process. So the only reason you would want a thread at BEGIN time is if you're doing some kind of threaded compilation, which blows my mind. I don't have much experience with threads, but putting myself in the shoes of someone who does, I still can't think of any application for that. So it's probably best to outlaw it to keep people from doing it accidentally. Luke
Re: creating threas in BEGIN
Hi,
Luke Palmer wrote:
On 7/14/05, Nicholas Clark [EMAIL PROTECTED] wrote:
This is more a note to collective 'self' question than one I expect
the answer to right now. (The answer I expect right now is a glib it
will)
How will the perl6 compiler cope with people creating threads inside
BEGIN blocks?
A glib it won't.
Unless someone can come up with a reason you would want to do that.
class SomeCryptMod {
my %tables_which_are_expensive_to_create =
precalc_tables();# called at BEGIN time
sub precalc_tables () {
# Use threads to speed up calculation:
for 0..1 - $i {
# Or whatever the thread API is.
Thread.create:{ precalc_table_for $i };
}
Thread.wait_for_all_threads;
}
...;
}
If you compile that module then, the compiler will only have to
calculate %tables_which_are_expensive_to_create once (as the results
are serialized in the .pbc), and the code could use threads to speed up
calculation.
(But I'm fine with outlawing it, or making it a new feature in Perl
6.x.y, or whatever :))
--Ingo
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Re: more .method (was: Perl 6 Summary for 2005-07-05 through 2005-07-12)
On Thu, Jul 14, 2005 at 12:14:57PM -0600, John Williams wrote: : Actually I took his question to be: : : If I explicitly name my invocant in the method signature, does that give : the compiler enough assurance that I'm not going to use .method to mean : $?SELF.method, and it will allow me to safely use .method as $_.method in : for and given? That question also came up in the cabal's last telecon, and I basically decided that it doesn't. If you want those assurances, a single use self; would be sufficient, even if you don't use the default of self, or whatever self defaults to. Or we might just go ahead and provide an explicit pragma dealing with the .foo construct, but I'll be switched if I can come up with a decent name for it. use topic; though arguably use topic it; would tend to mean that you want to always use it for the topic and leave .foo for $?SELF.foo. So maybe if you say use dot; it defaults to use dot '$_'; and in general says, I know the heck what I'm doing about dot. [From there our discussion digressed/descended into whether there should be an I am an expert pragma. I was dubious about any sort of non-feature-based razor.] Anyway, the people who always want to use .foo for self calls could then say use dot '$?SELF'; and then such programs could be plagued by self-dot. Larry
Re: MML dispatch
On Thu, Jul 14, 2005 at 03:27:53PM +1200, Sam Vilain wrote: : Can I present an alternative way of viewing them, which I don't think : contradicts with what I've understood of them so far from the : Apocalypses and Synopses documents. : : First a couple of definitions; : : A runtime class is a package name, and a collection of functions : that form a dispatch table. There are actually two tables - one : for private and one for public methods. Private and public methods are probably stored in a single table, but the private methods just happen to have a name starting with :. : The public table links to : superclasses where further dispatch may occur. Er, the concept of superclasses is not hidden in the dispatch table. Different dispatchers may have different ideas about method ordering, so the ISA information is really just passive trait data that must be interpreted by cooperation between dispatchers and meta classes. As such it's really a separate datum than the list of available methods. (Certainly, a given dispatcher might want to cache parental links in the current package's symbol table, but that's an optimization, and depends on the particular dispatcher's semantics.) : A method on a Role or a Class is a function that takes two : implicit arguments; a dispatch table for private method lookups, and : one for public methods lookups. The private dispatch table is bound : when the function is added to a runtime class, but the public : dispatch table is bound as late as possible (or until the class is : closed in some situations). I think you must be using private to mean something different than A12, but that's okay as long as we realize that. I'd prefer to couch things in terms of instantiated and uninstantiated generics, but we're probably just talking about the same things with different terms. : Here's the meat: : : A Class is then a Role that gets its runtime class created, and all : its methods' private dispatch tables bound at declaration time. I'd say the generic methods are forced to instantiate with either the default implementation provided by the role or the overriding implementation provided by the class, or by some combination of them if the class's method wants to delegate to the role's method. : A Role, on the other hand, leaves methods that can't be called, : until they are bound into a runtime class. So they _look_ like : they are flattened as the runtime classes are composed, unless you : are introspecting to the sufficient level. : : The runtime class would be the ::Type objects, and the real Class and : Role objects what you get from the .meta objects. Which you consider realer depends on whether you're a Platonist or an Aristotelian, but okay. I would say your runtime class is the representative proxy for all objects of its type, while the meta classes are in charge of the dirty work. So who's realer, the Senator who stands in front and smiles, or the Senator's aides who stand behind and frown? :-) : This might be a half empty / half full thing, I just thought you might : find that description interesting. Note that I don't deal with state, : I'm just treating attributes as if all they are is a set of accessor : functions, which store in an unspecifiedunimportant location. We're just basically assuming a role can behave like a parent class to the extent necessary to manage its state on behalf of the real object, so for instance it can have its own BUILD submethod that somehow magically gets incorporated into the object's own BUILD process. But politically the role is just that of the biological parent, not the guardian parent. You could almost think of a collection of roles as sort of a sperm and egg bank. Well, that's enough metaphors for today, at least till next week. Larry
Re: Method Resolution Order question
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
: currently is:
:
: From inside another method or submethod:
:
: - a submethod should only be called from the class which defines it.
This doesn't sound right to me. There is no distinction between
inside or outside.
Yes, I am not sure what I was thinking there. Shortly after I wrote
this mail I did some work on submethods in the metamodel and realized
how silly that idea is :)
I also realized that a sepereate submethod dispatch table made no sense
either, so scratch that thought out as well.
A submethod is simply a method that says These
aren't the droids you're looking for if you call it via either SMD
or MMD dispatch and the first invocant isn't of the exact run-time
type of the lexical class. In other words, it just has an implicit
next METHOD if $?SELF != $?CLASS;
at the front. So the dispatch continues until it finds either a
submethod
that does have an exact match or a method that isn't a submethod.
Now, the metamodel currently does not have MMD, and I think next
METHOD is not as relevant in SMD. So would it make sense to do:
next SUPER if $?SELF != $?CLASS;
or something like that? Here is some example code which might encounter
this:
class Foo {
method baz { ... }
}
class Bar is Foo {
submethod baz { ... }
}
class FooBar is Bar {}
my $foo_bar = FooBar.new();
$foo_bar.baz() # calls Foo::baz()
basically the dispatch goes from Bar::baz, which says next SUPER and
the dispatcher then goes to Foo::baz since it is a method.
Is that correct?
: This means that since Object::bless() calls Object::BUILDALL() it is
: all well and good, assuming you have not overridden bless() in your
: class, and are calling it $class.bless().
No, Object::bless() (which perhaps delegates to Class.meta.bless so
that different meta classes can have different .bless primitives)
Okay, this makes sense.
calls MyClass.CREATE to create the type, while will be an opaque type
if that normal method dispatch runs up the tree to Object::CREATE.
(But user classes are allowed to define their own CREATE method to
create non-opaque objects.)
After the storage is allocated, .meta.bless then calls $newobj.BUILDALL
as an ordinary method call on the instance. Again this is overridable
by each class, but typically goes back to Object::BUILDALL (which, as
usual, probably delegates at least some of the work to the meta class).
You refer to CREATE and BUILDALL as methods here, but A12 calls them
submethods. Which is correct?
: (Object::BUILDALL of course then digs into the metaclass to call
: BUILD() for all the superclasses in post-order. I am not sure how to
do
: that otherwise, submethod or not.)
I believe there's pseudo-code for that in A12. The trick is that you
can always force a call to a submethod of the wrong class by taking
it as a sub reference and calling it like an ordinary subroutine.
Okay, this is just as dirty a trick as sneaking up into the metamodel,
so I will leave it that way for now, knowing I need to change it later
:)
: However, if you define MyClass::bless, then you will need to define
: MyClass::BUILDALL as well.
We did not intend that people redefined .bless. It's really intended
to be
a primitive like .meta. The occasional redefinables are CREATE and
BUILDALL,
but it's really only intended that BUILD be defined typically.
Agreed, .bless should probably never be redefined, I will pull that up
into the MetaClass.
snip
: There's some kind of yes I mean
: you notion in the dispatcher. It comes out in user-visible terms
: in .*foo calls but not ordinary .foo calls,
:
: I am not familiar with .*foo calls? Can you elaborate?
This is all pretty much straight from A12.
I see now, I forgot about those :)
: which call a submethod
: only when the object is actually that type, and otherwise look for
an
: ancestral method of that name.
:
: Yes, to expand upon my above statements. The method resolution would
: begin looking in the local submethod table, then move onto the local
: method table, and then on up the superclass hierarchy. Is that
correct?
There is no separate submethod table. From the standpoint of ordinary
.foo method resolution they're ordinary methods that happen to say
next METHOD as a form of failure.
Yup, realized that as soon as I tried to implement it :)
Thanks,
Stevan
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
It's a little klunky but does localize the override rather visibly.
Doubtless people will generally put the use dot at the front though.
Larry
Re: Method Resolution Order question
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: A submethod is simply a method that says These
: aren't the droids you're looking for if you call it via either SMD
: or MMD dispatch and the first invocant isn't of the exact run-time
: type of the lexical class. In other words, it just has an implicit
:
: next METHOD if $?SELF != $?CLASS;
:
: at the front. So the dispatch continues until it finds either a
: submethod
: that does have an exact match or a method that isn't a submethod.
:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make sense to do:
:
: next SUPER if $?SELF != $?CLASS;
:
: or something like that?
It comes out to that under single inheritance, but under MI it might
well be that the next method that ought to be called is actually a
sibling method.
: Here is some example code which might encounter this:
:
: class Foo {
: method baz { ... }
: }
:
: class Bar is Foo {
: submethod baz { ... }
: }
:
: class FooBar is Bar {}
:
: my $foo_bar = FooBar.new();
: $foo_bar.baz() # calls Foo::baz()
:
: basically the dispatch goes from Bar::baz, which says next SUPER and
: the dispatcher then goes to Foo::baz since it is a method.
:
: Is that correct?
It says next METHOD, which has the same effect under SI. But we don't
know whether we're under MI, and we don't know if the dispatcher we're
working under has some weird order of visitation, so it's clearer to
say next METHOD and leave it up to the dispatcher to decide if the
SUPER is the next method. It *usually* is, but...
: You refer to CREATE and BUILDALL as methods here, but A12 calls them
: submethods. Which is correct?
The default versions are methods so that they can be inherited. The
individual versions defined by classes are submethods unless they intend
to be inherited, and force all their subclasses into a new set of default
sematics. And they're always called as methods (except when things like
.* cheat).
: I believe there's pseudo-code for that in A12. The trick is that you
: can always force a call to a submethod of the wrong class by taking
: it as a sub reference and calling it like an ordinary subroutine.
:
: Okay, this is just as dirty a trick as sneaking up into the metamodel,
: so I will leave it that way for now, knowing I need to change it later
: :)
Of course, the metamodel can do whatever dirty tricks it likes,
but in Perl 6 the metamodel might actually implement this particular
operation by forcing a sub call through a reference, if the metamodel
is implemented in Perl 6. It's the only way we've defined to
defeat the .foo dispatcher so far, from a language point of view.
(Though simply calling .meta could also be construed as cheating,
I guess. Or at least an authorization of cheating on your behalf.)
Larry
Re: creating threas in BEGIN
On Thu, Jul 14, 2005 at 04:32:13PM +0100, Nicholas Clark wrote: : How will the perl6 compiler cope with people creating threads inside : BEGIN blocks? Probably break, if they meant INIT. I can't think of a static way to detect that offhand, so I'm okay if we just call it erroneous. Or maybe there's some way at CHECK time to mark threads to complain if they do any real work later than CHECK time. Or we could just blow away any extra threads we find hanging around at CHECK time and see who screams. :-) (It would also be good if we could fix Perl 5 to make INIT always run as early as possible after CHECK time, even if it's too late, especially if we actually want to start encouaging people to use INIT correctly before they move to Perl 6.) Larry
Re: Method Resolution Order question
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make sense to do:
:
: next SUPER if $?SELF != $?CLASS;
:
: or something like that?
It comes out to that under single inheritance, but under MI it might
well be that the next method that ought to be called is actually a
sibling method.
This is just to clarify for me (and anyone else paying attention),
because this made more sense when I saw it.
class Foo {
method baz { ... }
}
class Bar {
submethod baz { ... }
}
class FooBar is Foo is Bar {}
my $foo_bar = FooBar.new();
$foo_bar.baz() # calls Foo::baz()
No need to respond unless I got it wrong :)
: Here is some example code which might encounter this:
:
: class Foo {
: method baz { ... }
: }
:
: class Bar is Foo {
: submethod baz { ... }
: }
:
: class FooBar is Bar {}
:
: my $foo_bar = FooBar.new();
: $foo_bar.baz() # calls Foo::baz()
:
: basically the dispatch goes from Bar::baz, which says next SUPER
and
: the dispatcher then goes to Foo::baz since it is a method.
:
: Is that correct?
It says next METHOD, which has the same effect under SI. But we
don't
know whether we're under MI, and we don't know if the dispatcher we're
working under has some weird order of visitation, so it's clearer to
say next METHOD and leave it up to the dispatcher to decide if the
SUPER is the next method. It *usually* is, but...
: You refer to CREATE and BUILDALL as methods here, but A12 calls them
: submethods. Which is correct?
The default versions are methods so that they can be inherited. The
individual versions defined by classes are submethods unless they
intend
to be inherited, and force all their subclasses into a new set of
default
sematics. And they're always called as methods (except when things
like
.* cheat).
: I believe there's pseudo-code for that in A12. The trick is that
you
: can always force a call to a submethod of the wrong class by
taking
: it as a sub reference and calling it like an ordinary subroutine.
:
: Okay, this is just as dirty a trick as sneaking up into the
metamodel,
: so I will leave it that way for now, knowing I need to change it
later
: :)
Of course, the metamodel can do whatever dirty tricks it likes,
but in Perl 6 the metamodel might actually implement this particular
operation by forcing a sub call through a reference, if the metamodel
is implemented in Perl 6. It's the only way we've defined to
defeat the .foo dispatcher so far, from a language point of view.
(Though simply calling .meta could also be construed as cheating,
I guess. Or at least an authorization of cheating on your behalf.)
Larry
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always means $_.method ($_ being the topic) then I don't see how
it is ever ambiguous. Unless I missed where nested loops would also
disallow .method because people might not be able to keep track of the
topic.
use dot;
it'll always be construed as unambigous. You could go so far as to
say
method foo($x) {
my $y = .bar; # $_ is self call because $_ := $?SELF
given $y { use dot; # yes I know what I'm doing
when 1 { .abc } # calls $y.abc
when 2 { .bcd } # calls $y.bcd
}
.baz; # back to self.baz
}
Why must anything special be done in the given block to allow .method if
it is always $_.method? Since I know $y is the topic in this block I know
to expect $y.abc to be called. There is no ambiguity. An error here
would just be confusing.
Now, for those who want .abc to call $?SELF.abc within the given block
then I think it would be clearer if they spelled out that intention with
something like
given $y { use dot '$?SELF'; # or just 'use dot' with suitable default
when 1 { .abc } # calls $?SELF.abc
}
--
Rick Delaney
[EMAIL PROTECTED]
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK! TOO MANY CHOICES!
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
I don't want to be using a language designed for idiots - I know
what I'm doing, and I like the power that perl 5 has given me.
How many times have you typed
map { chr }
map { lc }
grep { defined }
and then got bummed out that you can't have
grep { .is_moose }
since it's in a method.
That really sucks.
I'd rather have '.foo' not work on $?SELF at all than have that.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpBnxbN8NonX.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
Larry Wall skribis 2005-07-14 13:39 (-0700): On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. Thus it never means $?SELF.foo without $_ being the same thing, and thus it always means $_.foo, and thus there is no ambiguity about what .foo means, and .foo can mean $_.foo even if $_ isn't $?SELF, as $?SELF is never a factor in the decision what .foo means. Good, glad that's solved. We have normality. It's a little klunky but does localize the override rather visibly. Doubtless people will generally put the use dot at the front though. Doubtless if you really insist on this feature, Perl 6 will see its first fork very shortly after its release... But have no fear, because it will run all standard Perl 6 code too, as the thing that the fork introduces used to be an error. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: WTF? - Re: method calls on $self
Yuval Kogman skribis 2005-07-15 1:09 (+0300): use dot; If we have pragmas for the 99 Perl6's that every wacko wants to have, we won't have any readability. The syntax needs to be consistent and useful, even at the price of some danger. Agreed. I don't want to be using a language designed for idiots - I know what I'm doing, and I like the power that perl 5 has given me. Me too. I'd rather have '.foo' not work on $?SELF at all than have that. .foo never working on $?SELF is consistent with the initial design, the idea that the default variable is always $_ (as explained very well by Damian), and the design until a few days ago. I really do not understand why Larry has changed his mind about .foo, as the meaning of .foo has not been topic of discussion for a long time now. The syntax of ./foo did receive a lot of both negative and positive attention, and I could understand that ./foo, being found ugly by some people, would be pulled out of the language in favour of some yet to invent syntax, or perhaps without replacement. That, however, has nothing to do with .foo. Or at least HAD nothing to do with .foo, until Larry decided that if $_ := $?SELF, .foo would be special all of a sudden. If that is so, then lc without arguments would also need to be special, as that also defaults to $_, which would then be the same thing as $?SELF, which makes things special. lc without arguments would also need to be forbidden, following this way of thinking. We can only hope our dictator turns benevolent again, at least regarding the one thing we all agree about (and have agreed about for quite some time): that .foo must always mean $_.foo. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: branched off pdd03 changes
Leopold Toetsch [EMAIL PROTECTED] wrote: I'd be glad if folks can go through the failing tests (one exception tests hangs) and change old PASM call syntax to new. It's a drop in the ocean, but attached patch fixes one that's been missed. Here's the test output on Win32 with MSVC++ for the branch (with my patch). Failed Test Status Wstat Total Fail Failed List of Failed t\dynclass\foo.t 8 2048 98 88.89% 1-5, 7-9 t\library\yaml_parser_syck.t 11 100.00% 1 t\op\gc.t 1 256191 5.26% 13 t\op\spawnw.t 3 768 63 50.00% 4-6 t\perl\Parrot_IO.t 8 2048558 14.55% 23-29, 45 t\pmc\io.t311 3.23% 1 t\pmc\mmd.t6 1536306 20.00% 20-22, 24-25, 28 t\pmc\namespace.t 1 256151 6.67% 15 t\pmc\object-meths.t 1 256281 3.57% 11 t\pmc\objects.t5 1280627 11.29% 29-31, 53, 55-57 t\pmc\pair.t 1 256 31 33.33% 3 t\pmc\perlnum.t 551 1.82% 55 t\pmc\pmc.t1 256241 4.17% 5 t\pmc\ref.t 121 8.33% 6 t\pmc\threads.t7 1792117 63.64% 2-5, 7-9 t\src\compiler.t 1 256 11 100.00% 1 t\src\manifest.t 1 256 51 20.00% 3 4 tests and 81 subtests skipped. Failed 17/157 test scripts, 89.17% okay. 50/2658 subtests failed, 98.12% okay. NMAKE : fatal error U1077: 'c:\Perl\bin\perl.exe' : return code '0x2' Stop. However, a lot of tests are failing because of this:- # Can't spawn .\parrot.exe --gc-debug D:\Jonathan\hacking\parrot\branches\leo-ctx5\t\op\gc_13.pir: Bad file descriptor at lib/Parrot/Test.pm line 238. I've not been able to track down why that's happening yet. Thanks, Jonathan extend.diff Description: Binary data
Type::Class::Haskell does Role
Haskell has this very nice consistency I'll diverge into perl terms... The 'Show' role provides consistent stringification semantics for any type that does the role. It can even 'derive' the role, getting a method autogenerated. The 'Ord' role provides semantics for ordered types. A typical structure that uses this is the map - it is a sorted collection of stuff, and the key must do the 'Ord' role. And so on and so forth. Meanwhile in perl 5 land we have: * eq vs == * stringifying objects is rarely meaningful * there isn't a culture of functional programming like reuse - we do it on an entirely different level. Can this fit into perl 6? As I see it == is the generic comparison, and 'eq' is == with coercing parameters (in Haskell it'd be eq :: (Show a) = a - a - Bool or so... Isn't that lovely?) Anywho, my point is - there's lots we can borrow to make our Prelude.pm prettier, and our code a little more generic. Mechanical conversion from perl 5 can use the fully qualified instances of '==' and 'eq' in the Str and Num roles. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me beats up some cheese: neeyah! pgpPyzwXOLcxH.pgp Description: PGP signature
Optimization pipeline
I'd like to document the optimization pipeline thing I brought up in the hackathon... The intent is to plan how to balance throughput with responsiveness for a language that has such a broad range of dynamic to static typing as Perl 6 will is. With such behavior the amount of optimization you can do is limitless, but the amount you actually want to do varies... The runtime engine, environment variables, or whatever control this, it doesn't matter what the interface is, but the concept is: - optimizers stack on top of each other - the output of each one is executable - optimizers work in a coroutine, and are preemptable - optimizers are small - optimizers operate with a certain section of code in mind Basically you transform the PIL structures, or the byte code, or the resulting machine code if any, as it's going to be executed. This is old news. Optimizers get time slices to operate on code as it is needed. They get small portions - on the first run only simple optimizations are expected to actually finish. However, as code is re-executed, a proportion of the time it took to run it is spent on optimizing it, so that if code is rerun often eventually the optimizers will finish optimizing that bit of code. The goal is to achieve good responsiveness for tight edit/debug cycles, but achieve good performance for mod_perl like apps. With really crazy optimizations in a coupled compile+run environment (where parrot and the perl 6 compiler can talk to each other and rewrite code for each other) slow but busy code will eventually have enough time spent on it so that it's fast enough, but results are still available ASAP. The scenarios in which this is pleasing is high uptime, long running applications, and short scripts. Of course, the proportion of time, size of data structures, various policies should all be under control, but as a guiding principal I think that a JIT pipeline approach is the most balanced. Nothing should stop anyone from disabling everything, or pre-optimizing everything during compilation - it's just that the default trigger should the actual execution of chunks of code. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sushi-spin-kicks : neeyah pgp5PX0cYtS9G.pgp Description: PGP signature
Re: MML dispatch
Luke wrote:
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: Manhattan distance is
better.
That was never my *argument*, merely my statement-of-position. ;-)
Indeed, pure MMD will be ambiguous in more cases. If you think
narrowly, then it causes you to write many disambiguating cases which
*usually* end up being what a manhattan metric would give you anyway.
But you can get away from that terrible duplication by being more
precise about your types. You can define type classes using empty
roles[1], where you simply organize your type dag into abstractions
that make sense to your dispatcher. The upshot of all this is that it
forces you to think in a way so that the *usually* above becomes an
always. And it involves defining more (very small) types that make
sense to humans, not gratuitously many MMD variants which are pretty
hard to think about.
I don't see how this is a big win. You're still be forced to explicitly
disambiguate. Either by defining extra variants (which is tedious), or by
defining extra types (which is subtle).
You just made my primary argument against manhattan distance for me.
If you change something in the middle of the class hierarchy,
manhattan distance causes multimethods on the leaves to change
semantics. You say that pure MMD causes them to break when a change
occurs. Isn't that better than changing?
No. If the dispatch behaviour changes under a Manhattan metric, then it only
ever changes to a more specific variant. Since MMD is all about choosing the
most specific variant, that's entirely appropriate, in the light of the new
information. If you change type relationships, any semantics based on type
relationships must naturally change.
On the other hand, under a pure ordering scheme, if you change type
relationships, any semantics based on type relationships immediately *break*.
That's not a graceful response to additional information. Under pure ordering,
if you make a change to the type hierarchy, you have to *keep* making changes
until the dispatch semantics stabilize again. For most developers that will
mean a bout of evolutionary programming, where they try adding extra types
in a semi-random fashion until they seem to get the result they want. :-(
Perhaps I've made this argument before, but let me just ask a
question: if B derives from A, C derives from A, and D derives from
C, is it sensible to say that D is more derived from A than B is?
Now consider the following definitions:
class A { }
class B is A {
method foo () { 1 }
method bar () { 2 }
method baz () { 3 }
}
class C is A {
method foo () { 1 }
}
class D is C {
method bar () { 2 }
}
Now it looks like B is more derived than D is. But that is, of
course, impossible to tell. Basically I'm saying that you can't tell
the relative relationship of D and B when talking about A. They're
both derived by some amount that is impossible for a compiler to
detect. What you *can* say is that D is more derived than C.
Huh. I don't understand this at all.
In MMD you have an argument of a given type and you're trying to find the most
specifically compatible parameter. That means you only ever look upwards in a
hierarchy. If your argument is of type D, then you can unequivocally say that
C is more compatible than A (because they share more common components), and
you can also say that B is not compatible at all. The relative derivation
distances of B and D *never* matter since they can never be in competition,
when viewed from the perspective of a particular argument.
What we're really talking about here is how do we *combine* the compatibility
measures of two or more arguments to determine the best overall fit. Pure
Ordering does it in a take my bat and go home manner, Manhattan distance
does it by weighing all arguments equally.
In conclusion, the reason that manhattan distance scares me so, and
the reason that I'm not satisfied with use mmd 'pure' is that for
the builtins that heavily use MMD, we require *precision rather than
dwimmyness*. A module author who /inserts/ a type in the standard
hierarchy can change the semantics of things that aren't aware that
that type even exists. If you're going to go messing with the
standard types, you'd better be clear about your abstractions, and if
you're not, the program deserves to die, not dwim around it.
That *might* be an argument that builtins ought to do pure ordering
dispatch, but it isn't an argument in the more general case. Most people won't
be futzing around with the standard type hierarchy, except at the leaves,
where it doesn't matter. Most people will be using MMD for applications
development, on their own type hierarchies. Someone who's (for example)
building an image processing library wants to be able
Re: Optimization pipeline
Yuval Kogman wrote: - optimizers stack on top of each other - the output of each one is executable - optimizers work in a coroutine, and are preemptable - optimizers are small - optimizers operate with a certain section of code in mind ... Optimizers get time slices to operate on code as it is needed. They get small portions - on the first run only simple optimizations are expected to actually finish. ... A couple of thoughts spring to mind: in these coming times of ubiquitous multi-core computing with software transaction support, perhaps it would be realistic to place optimisation on a low-priority thread. So much code is single-threaded that anything we can do to make use of dual-cores is likely to improve system efficiency. The other thing that I thought of was the question of errors detected during optimisations. It is possible that an optimiser will do a more in-depth type inference (or dataflow analysis, etc.) and find errors in the code (e.g. gcc -O2 adds warnings for uninitialised variables). This would be a compile-time error that occurs while the code is running. If a program has been running for several hours when the problem is found, what do you do with the error? Would you even want to send a warning to stderr?
Re: Optimization pipeline
There may be some tie-in with STM here too, where a particular optimization doesn't commit if the optimization gives up in the middle, or is preempted before it gets done. But maybe it's all done with cooperative multitasking. (But maybe STM is how they cooperate...) Just a half-baked thought. It's just when you said an optimization completes I heard an optimization commits, which implied that an optimization could also roll back if it needed to. Larry
Re: Optimization pipeline
On Thu, Jul 14, 2005 at 06:06:24PM -0700, Dave Whipp wrote: : Yuval Kogman wrote: : : - optimizers stack on top of each other : - the output of each one is executable : - optimizers work in a coroutine, and are preemptable : - optimizers are small : - optimizers operate with a certain section of code in mind : : ... : Optimizers get time slices to operate on code as it is needed. They : get small portions - on the first run only simple optimizations are : expected to actually finish. : ... : : A couple of thoughts spring to mind: in these coming times of ubiquitous : multi-core computing with software transaction support, perhaps it would : be realistic to place optimisation on a low-priority thread. So much : code is single-threaded that anything we can do to make use of : dual-cores is likely to improve system efficiency. Yes, that's kind of what I was trying to say. : The other thing that I thought of was the question of errors detected : during optimisations. It is possible that an optimiser will do a more : in-depth type inference (or dataflow analysis, etc.) and find errors in : the code (e.g. gcc -O2 adds warnings for uninitialised variables). This : would be a compile-time error that occurs while the code is running. If : a program has been running for several hours when the problem is found, : what do you do with the error? Would you even want to send a warning to : stderr? Perl 6 already defines ways for dealing with interesting values of undef, so the particular case of an uninitialized variable is already something we know might happen, and if it does happen, we kind of ignore it unless you actually try to use the initialized variable. But I understand you're asking a more general question. So maybe what the optimizer wants to do is store such messages off in some kind of I could have told you that location and not bring it up unless you actually run into the problem, or you ask it to tell you what warnings it was sitting on somehow. If all else fails, some kind of log file maybe. On the other hand, if you aren't ready to deal with warnings on stderr, maybe you shouldn't be running an OS that supports it... Larry
Re: WTF? - Re: method calls on $self
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote: On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote: On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote: : So long as .foo (pretty please) means $_.foo all the time (with sugar on : top?). It means that all the time, but only when unambiguous. If you say use dot; I'd rather have '.foo' not work on $?SELF at all than have that. Um, that's what I was hoping for too. Let .foo mean $_.foo, and never $?SELF.foo, unless of course $_ happens to contain $?SELF at that moment. (sugar, anyone?) -kolibrie
Re: Type::Class::Haskell does Role
On Fri, Jul 15, 2005 at 02:38:22AM +0300, Yuval Kogman wrote:
As I see it == is the generic comparison, and 'eq' is == with
coercing parameters (in Haskell it'd be
eq :: (Show a) = a - a - Bool or so... Isn't that lovely?)
There is a new generic comparison operator known as ~~.
The dispatch for ~~ is governed by MMD that acts on the type classes --
I mean roles -- of both sides. I wonder if we can make eg:
role SmartMatchEq {
method sm_eq ($x: $y) { ... }
}
multi infix:~~ (SmartMatchEq $x, SmartMatchEq $y) {
$x.sm_eq($y)
}
Is that close to what you want?
Thanks,
/Autrijus/
pgp1mSARkrHxM.pgp
Description: PGP signature
Re: WTF? - Re: method calls on $self
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote: Nathan Gray skribis 2005-07-14 12:55 (-0400): Autrijus joked? about $?.method once (instead of ./method), in case we need any more bad alternatives for $?SELF.method. But I also trust @larry, or %larry, or even $larry, to make a decent choice that will serve the community well. Would this mean that $? is an alias for $?SELF, or only that $?. comes in ./'s stead? The former. But this is strictly a joke in response to nothingmuch's two characters shorthand criteria on #perl6; please don't hold it against me, or invoke the famed joke-turned-into-reality p6l device! :) Thanks, /Autrijus/ pgp3KX5cJZLGF.pgp Description: PGP signature
