Re: [perl #27003] bytecode (header?) problem in tru64/alpha
-J Jarkko, I never got a response from anyone. How would you feel about closing this bug? I don't think it can be closed until at least another big-endian 64-bit platform (like IRIX 64 is/was) has been used to verify that things work. -J
Re: [perl #37339] AutoReply: [BUG] Parrot 0.3.0 tru64 t/pmc/perlstring.t #44
The latest changes by Leo seem to have fixed this one, and similarly #37338 and #37337.
[PATCH] Re: [perl #37334] AutoReply: [PATCH] Parrot 0.3.0 does not compile in Tru64 because of missing socklen_t
Jarkko Hietaniemi wrote:
Jarkko Hietaniemi wrote:
io/io_unix.c does not compile because socklen_t is not defined.
According to the standards, sys/socket.h is needed to get socklen_t.
One could try including that the right way into io/io_unix.c, but I do
not know enough of Parrot conventions. Instead, the below patch helps:
--- io/io_unix.c.dist 2005-10-03 20:54:25.0 +0300
+++ io/io_unix.c2005-10-03 20:56:51.0 +0300
@@ -832,7 +832,7 @@
newio = PIO_new(interpreter, PIO_F_SOCKET, 0, PIO_F_READ|PIO_F_WRITE);
if ((newsock = accept(io-fd, (struct sockaddr *)newio-remote,
- (socklen_t *)newsize)) == -1)
+ newsize)) == -1)
{
fprintf(stderr, accept: errno=%d, errno);
/* Didn't get far enough, free the io */
Please ignore that patch, it doesn't work since socklen_t is a long,
not an int, and in Tru64 one shall not mix those.
Please ignore the ignore :-) It seems that it depends how long the
socklen_t is in Tru64, and with cxx (the C++ compiler) and the flags
Parrot compilation uses, int is fine. So the above patch is fine for
now. In the long run the newsize really should be socklen_t. Getting
that to be defined seems to be little tricky with cxx, so please don't
change that right now... in the meanwhile, I found another bug in the
IO code, bug report coming soon.
The culprit seems to be that for tru64 cxx not all the POSIX APIs and
types are visible by default as they are for cc, and one of those
missing with -D_XOPEN_SOURCE=500 is the socklen_t.
--- config/init/hints/dec_osf.pl.dist 2005-10-05 20:29:30.0 +0300
+++ config/init/hints/dec_osf.pl2005-10-05 20:31:25.0 +0300
@@ -6,6 +6,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
+# Request all POSIX visible (not automatic for cxx, as with cc)
+$ccflags .= ' -D_XOPEN_SOURCE=500';
+}
Configure::Data-set(
ccflags = $ccflags,
);
Test::Builder proposed enhancement
From Schwern's comment: I'll consider putting in some more information into the Test::Builder-details so information like the file and line number where the test occured can be gotten without scraping. I'd really like to have this as well. Current projects could really use it. --- Joe M.
Re: Spurious CPAN Tester errors from Sep 23rd to present.
On Oct 5, 2005, at 11:38 AM, Michael G Schwern wrote: I'm done talking about this until I see some attempt at fixing Test::Builder::Tester. It could have been done by now. I'll do it tomorrow unless someone else already has. --- Joe M.
Re: Spurious CPAN Tester errors from Sep 23rd to present.
Some more test failures confirmations... Test::Exception is uninstallable. Test::SubCalls is uninstallable. Test::Pod is uninstallable. Test::Warn is uninstallable. test_fail() which is the problem in TB::Tester was really only a convenience function for test_diag( Failed at ... ). Pretty much every single use of test_diag was for that purpose. So Test-URI which does that directly is definitely broken. Fixing TB::Tester won't fix this case. So Test-URI needs to be repaired as well. LWP will not be installable by anyone with Test::More 0.61 installed until it is fixed. So you probably need to rerelease LWP as well to force a dependency of the test Test-URI version, once it's out. And it would appear BDFOY's 3 other Test:: modules are also dead. Schwern, it isn't going to be JUST TB::Tester that needs fixing it's going to be a ton of things. And since test_fail() was a shortcut since so many people did test_diag( Failed at... ) on their own, you are probably also breaking a ton of testing modules out there in corporate land as well. Either directly because of test_diag, or because of their use of test_fail() we are going to need to fix the following modules which are currently broken with 0.61 Acme-Test-Buffy MARKF File-Random BIGJ HTTP-WebTestILYAM Test-Block ADIE Test-Data BDFOY Test-EnvBDFOY Test-File BDFOY Test-Files PHILCROW Test-HTML-Tidy PETDANCE Test-HTTP-Server-Simple GLASSER Test-ISBN BDFOY Test-LongString RGARCIA Test-ManyParams BIGJ Test-Memory-Cycle PETDANCE Test-Number-Delta DAGOLDEN Test-PodPETDANCE Test-Pod-Coverage PETDANCE Test-Prereq BDFOY Test-Role JFITZ Test-Spelling ITUB Test-Struct YVES Test-Tail-Multi MCMAHON Test-URIBDFOY Test-VersionPARTICLE Test-Warn BIGJ Test-XML-Valid MARKSTOS Could the authors of all of these modules please upgrade their packages to fit the output format of the new Test::More output format. Actually, those using test_diag directly are going to need to either test differently depending on whether you are installing with Test::More 0.61 or lower. In fact, since scraping is not supported, you may need to stop doing test_diag testing and port to something other than Test::Builder::Tester. I'm sure Schewrn will suggest a suitable alternative to port to. Or more likely port to test_fail()... once someone fixes it. Once Test-URI is upgraded, we are going to need to make sure the newest version is installed, so could the authors of the following modules please note you will need to do a new release to update this dependency. AmethystSHEVEK Apache-ACEProxy MIYAGAWA Apache-DoCoMoProxy KOBAYASI Apache-Gallery LEGART Apache-No404Proxy MIYAGAWA Apache-ProxyRewrite CGILMORE AxKit-App-Gallery NIKC Biblio-Citation-Parser MJEWELL Bio-ProspectREECE Bot-CPANFOX Business-BancaSella EBRUNI CGI-Application-MailPageWONKO CGI-Application-Plugin-LinkIntegrityMGRAHAM CGI-SSI JAMES CGI-TestMSHILTONJ CPAN-Mini RJBS CPAN-YACSmoke RRWO CatalystMRAMBERG Catalyst-Plugin-Session-CGISession TSHINNIC Catalyst-Plugin-Session-FastMmapMRAMBERG Catalyst-Plugin-Session-FlexRCONOVER Chess-Games-DotCom TBONE DBIx-TextSearch SRPATT DWH_FileSUMUS DynaPage-Apache2DANPEDER Email-Folder-POP3 CWEST Email-FolderType-NetCWEST Feed-Find BTROTT Finance-Bank-NatwestKNEW Finance-Bank-Norisbank JMASTROS Flickr-API IAMCAL FramesReady DERHAAG HTML-Location ADAMK HTML-MobileConverterJKONDO HTML-SimpleLinkExtorBDFOY HTML-StickyQueryIKEBE HTML-WikiConverter DIBERRI HTTP-Handle PSIONIC HTTP-OAITIMBRODY HTTP-Parser DBROBINS HTTP-Size BDFOY HTTP-WebTestILYAM Hoobot BSMITH IO-Ftp MIKEB JSAN-Client ADAMK JavaScript-LibrarianADAMK LWP-Protocol-virtualRPAUL Link_Controller MIKEDLR Logfile-Access DTIBERIO Logfile-EPrints TIMBRODY MKDoc-Core BPOSTLE Mac-AppleEvents-Simple CNANDOR Mail-BoxMARKOV Mail-ListDetector MSTEVENS Mail-SPF-Query FREESIDE Mail-SpamAssassin-SpamCopURIEAK MasonX-WebApp DROLSKY Maypole-FormBuilder DAVEBAIRD Maypole-Plugin-Authentication-Abstract SRI Maypole-Plugin-QuickTable DAVEBAIRD MetaVELTZER Module-Release-Extras NIKC Net-Amazon MSCHILLI Net-Blogger ASCOPE Net-DAV-Server BRONG Net-DPAP-Client LBROCARD Net-HTTPServer REATMON Net-OpenID-Consumer BRADFITZ Net-OpenID-Server BRADFITZ Net-RVP DBROBINS Net-SMS-Web AWRIGLEY OAI-Harvester ESUMMERS OpenFrame-Segment-ApacheLBROCARD OpenFrame-Segment-Apache2 LBROCARD PAppMLEHMANN POE-Component-Client-HTTP RCAPUTO PanglossSPURKIS ProspectREECE RDF-Service JONAS RDF-Sesame MNDRIX RT-Atom AUTRIJUS RT-Client AUTRIJUS Rose-URIJSIRACUSA SRU BRICAS Scraper GLENNWOOD
Re: [PATCH] Re: [perl #37334] AutoReply: [PATCH] Parrot 0.3.0 does not compile in Tru64 because of missing socklen_t
--- config/init/hints/dec_osf.pl.dist 2005-10-05 20:29:30.0 +0300
+++ config/init/hints/dec_osf.pl2005-10-05 20:31:25.0 +0300
@@ -6,6 +6,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
+# Request all POSIX visible (not automatic for cxx, as with cc)
+$ccflags .= ' -D_XOPEN_SOURCE=500';
+}
Configure::Data-set(
ccflags = $ccflags,
);
So the above patch should be applied so that Tru64 is happy, and works,
but as was pointed out to me in private email, the (socklen_t*) cast
should most probably be removed, too (and the newsize made socklen_t
instead of int), because the
(socklen_t*)newsize
when newsize is not a socklen_t, is simply asking for trouble
(misalignment and/or memory corruption).
[perl #37358] [TODO] tests - cleanup use of temp files
# New Ticket Created by Joshua Hoblitt # Please include the string: [perl #37358] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37358 Many of the tests write temp files into the current working dir. Even worse, some of these files many not get cleaned up if the tests exit prematurely. Tests should be converted to use File::Temp where ever possible. -J -- pgpbOQJVRmRLy.pgp Description: PGP signature
Re: [perl #36098] Solaris - Large number of tests fail under jit
On Wed, Oct 05, 2005 at 01:45:24AM -0700, Peter Sinnott via RT wrote:
On Tue, Oct 04, 2005 at 09:04:57PM -0700, Joshua Hoblitt via RT wrote:
I do not have access to the same machine any longer so I have retested
with solaris 2.8 , gcc 3.2.1 and the 2005-10-05_071500 parrot
snapshot. This fails during make with the following
perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? 8;'
dynclasses
make[1]: Entering directory `/tmp/parrot/dynclasses'
perl /tmp/parrot/build_tools/pmc2c.pl --dump matchrange.pmc
Can't write 'classes/default.dump' at /tmp/parrot/build_tools/pmc2c.pl
line 664.
pmc2c dump failed (512)
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/parrot/dynclasses'
make: *** [dynclasses.dummy] Error 2
I do not have time to look at it now but will try to take a look
latter on today or tomorrow.
pmc2c.pl was broken (by yours truely) for a few hours last night. Can
you try again with r 9350?
Thanks,
-J
--
pgpnbO7cuAJ1e.pgp
Description: PGP signature
Re: Spurious CPAN Tester errors from Sep 23rd to present.
On 10/5/05, Michael G Schwern [EMAIL PROTECTED] wrote: On Wed, Oct 05, 2005 at 11:22:40PM +1000, Adam Kennedy wrote: Please ignore these bad reports. I've contacted Schwern to get that specific change to Test::More backed out ASAP. These problem, if you get any, should go away shortly. Given that the repair alternatives are to backout the Test::More change and increment the T:B:Tester Test::More version to the newest (or at least, NOT the current) or to change all 26 other modules, backing out seems the sanest option at this point I'm disinclined to back this change out. See the bug for reasoning. http://rt.cpan.org/NoAuth/Bug.html?id=14936 To sum up: * There was ample warning. * You shouldn't be relying on screen scraping. I think you're right but Isn't that the basis of TBT? (and the version that's been ported to Perl 6 incidentally). * The fix to Test::Builder::Tester is trivial. And will result in yet more screen scraping. * Rolling back the change is a pain in my ass. The bug for this in Test::Builder::Tester is here: http://rt.cpan.org/NoAuth/Bug.html?id=14931 -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Stabbing you in the face for your own good.
Re: Spurious CPAN Tester errors from Sep 23rd to present.
Once Test-URI is upgraded, we are going to need to make sure the newest version is installed, so could the authors of the following modules please note you will need to do a new release to update this dependency. Amethyst SHEVEK Apache-ACEProxy MIYAGAWA Apache-DoCoMoProxyKOBAYASI Apache-GalleryLEGART Apache-No404Proxy MIYAGAWA [...the long list of modules continues...] This list came from CPANTS, right? I think there's something screwy with the way it's following dependencies. It looks like a lot of these modules require URI, not Test::URI. In fact, I haven't yet found one that requires Test::URI. Michael --- Michael Graham [EMAIL PROTECTED]
Re: Spurious CPAN Tester errors from Sep 23rd to present.
Just grab the previous stable tarball, unroll it, change the version to a higher one, and release. If it's a bitch to backout that one path, backout the entire stable release to the previous one. Did you see the number of bug fixes between 0.60 and 0.61? No, I'm not rolling back the entire release. I did see the number. And yet 11 days ago 1000 other CPAN modules worked fine and it wasn't a huge problem they were only in a devel release, and now many of them will be broken, and they are going to stay broken. Regressing those bugs for a short time pales in comparison to the problems our our current situation. Just upgrading TB::Tester isn't going to be enough, because then it needs to be forced to upgrade everywhere, which means we actually have to change 27 distributions. And in the mean time CPAN is badly broken. Unless you are suggesting I... a) Go fix someone elses testing module b) Take upload permissions by force c) Upload their package. d) Contact the authors of all 26 modules e) Get them to increment and release f) Go increment all the ones I can't contact for them g) Take upload permissions by force from all 26 - $responsive h) Upload ALL of those packages ... I don't see any other way to fix a badly broken CPAN and fix it today. Or you can roll back some bug fixes that have only been visible to the world for 10 days, until we can do a more fine-grained backout, and then deal with the larger situation. If you have any other alternatives to fix CPAN _today_, I'd like to hear them. Adam K
Re: Spurious CPAN Tester errors from Sep 23rd to present.
I'm disinclined to back this change out. See the bug for reasoning. http://rt.cpan.org/NoAuth/Bug.html?id=14936 To sum up: * There was ample warning. * You shouldn't be relying on screen scraping. * The fix to Test::Builder::Tester is trivial. * Rolling back the change is a pain in my ass. The bug for this in Test::Builder::Tester is here: http://rt.cpan.org/NoAuth/Bug.html?id=14931 Normally I'd completely agree. But in this case regardless of whether it was right or wrong to do so, it has worked just fine for people for over 3 years and at this point 1/3rd of CPAN gets caught in the dependency chain, so it means practically every single Perl install is deemed broken. Whereas with the backout we only have 10 days worth of upgraders who are considered broken. If we start with everything broken and try to gradually fix it, we're going to have little errors here and there for a long time. If we can back the change out for 6 months or so, there's time to get all the potential scrapers audited for problems, add anything else they need to work properly, update the dependencies on the 26 modules that use it, and then put the change back in again. But in the mean time, while we are fixing it, everything will still work and people will still be able to install modules. Which they can't do now without either forcing all the installs that fail, or manually installing an old version of Test-Simple. At the present time you cannot install anything of consequence onto a fresh Perl install. One of the first dependencies to install is Test-Simple, which will work, followed by Test::Buidler::Tester (since almost everything needs it), which will fail. Adam K
Re: Exceptuations
On Wed, Oct 05, 2005 at 13:00:55 -0600, Luke Palmer wrote: I don't think it was a how is this possible, but more of a what business does it have?. And as far as I gathered, they're saying pretty much what you've been saying, but in a different way. It's about the continuation boundary; that is, if you're outside a module, you have no say in how the module does its business. You can continue only at the module boundary, replacing a return value from its public interface. As I see it this is the usefulness of exceptions being handled by distant code. The code in the module inverts it's interface by calling code it doesn't know with a certain parameter, accepting a certain parameter back. That way encapsulation is not broken, but errors that happen deep inside a call chain can be dealt with by code that can interact with the user. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgp3KEiHvN25y.pgp Description: PGP signature
Re: Exceptuations
On Wed, Oct 05, 2005 at 13:41:37 -0700, Dave Whipp wrote:
Reading this thread, I find myself wondering how a resumable exception
differs
from a dynamically scropted function. Imagine this code:
This is sort of like what I mean, except that there is no
encapsulation breakage, since the interface is inverted.
The advantage of this approach is that error handling code in a
submodule can benefit from generic, reusable exception handling code
that is provided by it's caller.
temp sub FileNotWriteable( Str $filename ) {
With an exception handler and continuable exceptions you don't have
to know what the error handler is, or make sure that the module
actually throws the error.
The exception handler instead deals with the type of the exception
in a generic manner (it doesn't care when the exception was actually
generated).
The module doesn't need to throw the error it just needs to fail (or
delegate a fail), until the failure crosses into a 'use fatal'
scope.
That way both the catching code and the throwing code are reusable
and orthogonal when they are unrelated, but the possibility of
coupling handling code with throwing code is still there.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!
pgpNXhPo5zWZK.pgp
Description: PGP signature
Re: [PATCH] Add BROKEN.pod
On Wed, Oct 05, 2005 at 03:01:35PM -0700, chromatic wrote: On Mon, 2005-10-03 at 17:05 -1000, Joshua Hoblitt wrote: I'm wondering if this wouldn't be better split up into RT tickets similar to the way TODOs are handled. Having everything in one coherent document is great but I suspect that significantly lowers the odds of the individual items being kept up to date. Maybe so. The difference between this and a list of bugs is that these are higher-level problems that prevent various people from making progress on important things. Generating this list out of RT is probably fine though, if it's quick and easy. I attempted to mechanize Pod generation from RT tickets this morning and ran into what I suspect is a bug in the RT client. Why don't we just commit BROKEN as is, make a note about it in RELEASE_INSTRUCTIONS, and plan on moving towards it being generated from RT in the future? Cheers, -J -- pgprFXx3UlJLz.pgp Description: PGP signature
Re: [perl #36200] Parrot on Linux/m68k test failures
On Wed, Oct 05, 2005 at 09:22:34PM -0700, Joshua Juran via RT wrote:
Parrot itself builds successfully, but 'make' fails here:
...
./parrot -o runtime/parrot/library/Stream/Sub.pbc
runtime/parrot/library/Stream/Sub.imc
./parrot -o runtime/parrot/library/Stream/Writer.pbc
runtime/parrot/library/Stream/Writer.imc
./parrot -o runtime/parrot/library/YAML/Parser/Syck.pbc
runtime/parrot/library/YAML/Parser/Syck.imc
/usr/bin/perl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $?
8;' dynclasses
make[1]: Entering directory `/home/jjuran/src/parrot/dynclasses'
/usr/bin/perl /home/jjuran/src/parrot/build_tools/pmc2c.pl --dump
match.pmc
Can't write 'classes/default.dump' at
/home/jjuran/src/parrot/build_tools/pmc2c.pl line 664.
pmc2c dump failed (512)
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jjuran/src/parrot/dynclasses'
make: *** [dynclasses.dummy] Error 2
Thanks for retesting. pmc2c.pl was broken briefly yesterday night. Can
you try yet again with a revision 9350?
-J
--
pgpS5JpjoL9lL.pgp
Description: PGP signature
Re: [PATCH] Re: [perl #37334] AutoReply: [PATCH] Parrot 0.3.0 does not compile in Tru64 because of missing socklen_t
On Thu, Oct 06, 2005 at 08:20:22AM +0300, Jarkko Hietaniemi wrote:
--- config/init/hints/dec_osf.pl.dist 2005-10-05 20:29:30.0 +0300
+++ config/init/hints/dec_osf.pl2005-10-05 20:31:25.0 +0300
@@ -6,6 +6,10 @@
if ( $ccflags !~ /-pthread/ ) {
$ccflags .= ' -pthread';
}
+if ( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
+# Request all POSIX visible (not automatic for cxx, as with cc)
+$ccflags .= ' -D_XOPEN_SOURCE=500';
+}
Configure::Data-set(
ccflags = $ccflags,
);
So the above patch should be applied so that Tru64 is happy, and works,
but as was pointed out to me in private email, the (socklen_t*) cast
should most probably be removed, too (and the newsize made socklen_t
instead of int), because the
(socklen_t*)newsize
when newsize is not a socklen_t, is simply asking for trouble
(misalignment and/or memory corruption).
Since I don't think anyone else can test this on tru64, would you mind
consolidating all of the fixes discussed in this thread into a single
patch?
Thanks,
-J
--
pgpudu2tVDayG.pgp
Description: PGP signature
Re: [perl #37308] Parrot gobbles up all the memory
Andy Dougherty wrote: On Tue, 4 Oct 2005, Leopold Toetsch via RT wrote: Anyway, does: p = (struct Parrot_Context *) ( (char *) p + ALIGNED_CTX_SIZE ); help, or better is it more correct? While this does indeed replace the warning by a different warning (cast increases required alignment of target type), it doesn't fix the problem -- parrot still panics. (And since we're not accessing the memory through a (char *), I'm not sure it should make any difference. I'm not a language lawyer, and I haven't read the standard closely.) Sh... Another idea: The context (struct Parrot_Context) is almost only accessed by the CONTEXT() macro. When now this pointer (ctx.rctx) is declared being 'void *' it should be compatible with any other pointer to a structure. Anyway, the current code is an intermediate step only towards variable sized register frames. I have to reactivate the alloction code present also in inter_create.c, when CHUNKED_CTX_MEM is defined as true. This will very likely also need a split of ctx union into 2 distinct pointers: ctx.bp (register base pointer) and ctx.rctx (pointer to Parrot_Context). The allocation will still be like sketched in inter_create.c:79, i.e. as one block, just the addressing of the 2 items will be split. It would be great, if some folks with a stronger C-fu, then I have, could have a look at it. ... I'd appreciate it if someone with a faster machine and/or a deeper understanding of what the code is actually trying to do could hunt it down. Yep. My Athlon 800 also needs ages to compile it. leo
Re: Test::Builder proposed enhancement
On 10/5/05, Joe McMahon [EMAIL PROTECTED] wrote: From Schwern's comment: I'll consider putting in some more information into the Test::Builder-details so information like the file and line number where the test occured can be gotten without scraping. I'd really like to have this as well. Current projects could really use it. For me the correct way to check line number and file is to not check them at all, they're a moving target and lead to things like the line_num() function. A more useful thing to check is the perceived stack depth - that is (actual stack depth) - $Test::Builder::Level because this is what determines whether line num and file will be correct or not. Better still it should be the same for every test. Of course if you're just trying to output the line num and file then it's not useful, F
Re: [perl #27003] bytecode (header?) problem in tru64/alpha
On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote: -J Jarkko, I never got a response from anyone. How would you feel about closing this bug? I don't think it can be closed until at least another big-endian 64-bit platform (like IRIX 64 is/was) has been used to verify that things work. sparcv9/Solaris should be able to cover that... except I can't seem to build a 64-bit Parrot on Solaris. I tried changing my smoke scripts cflags so gcc would emit 64bit code but Configure.pl dies with linker errors. ld: fatal: file test.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to test collect2: ld returned 1 exit status I've double checked that the correct ld is being used and setting the ldflags to force 64 object code didn't resolve it. So either there's something wrong with the 64bit env on this box or Configure.pl is invoking CC at some point without the proper cflags. I'll try to into it tomorrow. Cheers, -J -- pgp1CEuOW53Fz.pgp Description: PGP signature
Re: [perl #36098] Solaris - Large number of tests fail under jit
On Thu, Oct 06, 2005 at 02:03:45AM -0700, Joshua Hoblitt via RT wrote: On Wed, Oct 05, 2005 at 01:45:24AM -0700, Peter Sinnott via RT wrote: On Tue, Oct 04, 2005 at 09:04:57PM -0700, Joshua Hoblitt via RT wrote: I do not have access to the same machine any longer so I have retested with solaris 2.8 , gcc 3.2.1 and the 2005-10-05_071500 parrot snapshot. This fails during make with the following pmc2c.pl was broken (by yours truely) for a few hours last night. Can you try again with r 9350? Retested make test results in Failed Test Stat Wstat Total Fail Failed List of Failed --- t/examples/japh.t1 256151 6.67% 12 t/op/trans.t 1 256191 5.26% 13 (1 subtest UNEXPECTEDLY SUCCEEDED), 6 tests and 103 subtests skipped. Failed 2/167 test scripts, 98.80% okay. 2/2730 subtests failed, 99.93% okay. I think t/examples/japh.t has been mentioned before but can not find a bug for it. t/examples/japhNOK 12 # Failed test (t/examples/japh.t at line 56) # got: 'set_integer_keyed() not implemented in class 'PerlInt' # current instr.: '(null)' pc 2 (/tmp/parrot/t/examples/japh_12.pasm:6) # ' # expected: 'Just another Parrot Hacker # ' # './parrot --gc-debug /tmp/parrot/t/examples/japh_12.pasm' failed # with exit code 1 t/examples/japhok 15/15# Looks like you failed 1 test of 15. t/examples/japhdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 12 Failed 1/15 tests, 93.33% okay t/op/trans.t looks like the same bug as #36835 (Cygwin) and #34549 (openbsd). t/op/trans.NOK 13 # Failed test (t/op/trans.t at line 307) # got: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ok 10 # ok 11 # ok 12 # ok 13 # ok 14 # ok 15 # ok 16 # not 0.00ok 17 # ' # expected: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ok 10 # ok 11 # ok 12 # ok 13 # ok 14 # ok 15 # ok 16 # ok 17 # ' t/op/trans.ok 19/19# Looks like you failed 1 test of 19. t/op/trans.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 13 Failed 1/19 tests, 94.74% okay make testj results in the same failures so it looks like this bug can be closed now Thanks, -J -- -- Our mission is to efficiently supply professional information to allow us to authoritatively leverage other's interdependent methods of empowerment because that is what the customer expects
Re: [perl #27003] bytecode (header?) problem in tru64/alpha
On Thu, 6 Oct 2005, Joshua Hoblitt wrote: On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote: Jarkko, I never got a response from anyone. How would you feel about closing this bug? I don't think it can be closed until at least another big-endian 64-bit platform (like IRIX 64 is/was) has been used to verify that things work. sparcv9/Solaris should be able to cover that... except I can't seem to build a 64-bit Parrot on Solaris. I tried changing my smoke scripts cflags so gcc would emit 64bit code but Configure.pl dies with linker errors. ld: fatal: file test.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to test collect2: ld returned 1 exit status I've double checked that the correct ld is being used and setting the ldflags to force 64 object code didn't resolve it. So either there's something wrong with the 64bit env on this box or Configure.pl is invoking CC at some point without the proper cflags. I'll try to into it tomorrow. I think this bug can be closed. I just got those tests to pass on Sparc/Solaris 8 with gcc -m64 -mcpu=v9. (Mind you lots of other tests fail, but that's a separate problem.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #37308] Parrot gobbles up all the memory
Leopold Toetsch wrote: ... When now this pointer (ctx.rctx) is declared being 'void *' it should be compatible with any other pointer to a structure. I've now rewritten the questioanable code to use a (void*) allocation pointer. I hope it's better now. Could you please try r9367, and report success ;-) - thanks. leo
Re: [perl #36098] Solaris - Large number of tests fail under jit
On Thu, 6 Oct 2005, Peter Sinnott wrote: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/examples/japh.t1 256151 6.67% 12 t/op/trans.t 1 256191 5.26% 13 t/op/trans.t looks like the same bug as #36835 (Cygwin) and #34549 (openbsd). t/op/trans.NOK 13 Yup, it is. See the section about IEEE-754 in config/init/hints/solaris.pl for more details. -- Andy Dougherty [EMAIL PROTECTED]
Re: zip: stop when and where?
On 10/5/05, Damian Conway [EMAIL PROTECTED] wrote:
Luke wrote:
I'm just wondering why you feel that we need to be so careful.
Because I can think of at least three reasonable and useful default behaviours
for zipping lists of differing lengths:
# Minimal (stop at first exhausted list)...
for @names ¥ @addresses - $name, $addr {
...
}
# Maximal (insert undefs for exhausted lists)...
for @finishers ¥ (10..1 :by(-1)) - $name, $score {
$score err next;
...
}
# Congealed (ignore exhausted lists)...
for @queue1 ¥ @queue2 - $server {
...
}
Which means that there will be people who expect each of those to *be* the
default behaviour for unbalanced lists.
Perhaps that makes sense. That certainly makes sense for other kinds
of constructs. Something makes me think that this is a little
different. Whenever somebody asks what Y is on #perl6, and I tell
them that it interleaves two lists, a follow-up question is *always*
what does it do when the lists are unbalanced. Now, that may just
be a behavior of #perl6ers, but I'm extrapolating. It means that
there isn't an assumption, and if they weren't #perl6ers, they'd RTFM
about it.
When I learned Haskell and saw zip, I asked the very same question[1].
I was about as comfortable writing Haskell at that point as beginning
programmers are with writing Perl, but it still took me about ten
seconds to write a test program to find out. The rest of Perl doesn't
trade a reasonable default behavior for an error, even if it *might*
be surprising the first time you use it. It doesn't take people long
to discover that kind of error and never make that mistake again.
If we make zip return a list of tuples rather than an interleaved
list, we could eliminate the final 1/3 of those errors above using the
typechecker. That would make the for look like this:
for @a Y @b - ($a, $b) {...}
An important property of that is the well-typedness of the construct.
With the current zip semantics:
my A @a;
my B @b;
for @a Y @b - $a, $b {
# $a has type A (+) B
# $b has type A (+) B
}
With tuple:
my A @a;
my B @b;
for @a Y @b - ($a, $b) {
# $a has type A
# $b has type B
}
Which is more correct. No... it's just correct, no superlative
needed. It also keeps things like this from happening:
for @a Y @b - $a, $b {
say $a ; $b
}
# a1 b1
# a2 b2
# a3 b3
# ...
Oh, I need a count, says the user:
for @a Y @b Y 0... - $a, $b { # oops, forgot to add $index
say $a ; $b
}
# a1 b1
# 0 a2
# b2 1
# ...
Luke
[1] But I didn't need to. The signature told me everything:
zip :: [a] - [b] - [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a b unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] - [b] - [(Maybe a, Maybe b)]
Anyway, that's just more of the usual Haskell praise.
Re: zip: stop when and where?
Luke Palmer wrote:
zip :: [a] - [b] - [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a b unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] - [b] - [(Maybe a, Maybe b)]
Anyway, that's just more of the usual Haskell praise.
Given that my idea about using optional binding for look-ahead didn't
fly, maybe it would work here, instead:
@a Y @b - $a, $b { ... } # stop at end of shortest
@a Y @b - $a, ?$b { ... } # keep going until @a is exhaused
@a Y @b - ?$a, ?$b { ... } # keep going until both are exhaused
I think we still need a way to determine if an optional arg is bound.
Can the Cexists function be used for that (if exists $b {...})?
Dave.
Re: Exceptuations
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call
chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what type it should return and how to construct it? The innocent
foo() caller shouldn't bother about a quux() somewhere down the line
of command. Much less of its innards.
Well said.
No! Not well said at all!
Sorry, I misread that. I thought I was agreeng with how does a higher
level exception catcher know what to change in order to make resuming the
continuation useful?, especially in the light of Piers saying that the
bottom-most exception should be the one resumed.
The highest level exception is the only one a caller has any right to deal
with, but even then it doesn't really know what will happen if it resumes
some random continuation attached to the exception.
CATCH {
when some_kind_of_error {
$!.continue($appropriate_value_for_some_kind_of_error)
}
}
That just gives me the willies, I'm afraid.
--
Peter Haworth [EMAIL PROTECTED]
Disconcerting Haworth Fortress Unicycling Melody Gundam
-- http://www.channel4.com/4later/bits/manga.html
Re: zip: stop when and where?
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
If we make zip return a list of tuples rather than an interleaved
list, we could eliminate the final 1/3 of those errors above using the
typechecker. That would make the for look like this:
for @a Y @b - ($a, $b) {...}
I like it (I think). I'm not sure about the syntax though. Is this one
of those places where round brackets are equivalent to square brackets?
I.e., would this be the same:
for @a ¥ @b - [$a,$b] { ... }
?
Also, it seems like this syntax would almost always require the brackets
to be correct. Most of the time people will see and expect for loops
that look like this:
for MUMBLE - $a, $b { ... }
Except now they've probably got a semantic error when MUMBLE contains ¥
or is prefixed by zip. This type of error mayn't be so easy to detect
depending on what they're mumbling about.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
partcl command line options, etc.
A few more commands are inlined (including [for]). I've begun to
unify the three different compilers that are currently available: the
compreg'd version, the internal version for code, and the internal
version for expressions. All now use the same mechanism to ultimately
compile the PIR code they generate.
I also just added (mostly untested) support for two new command line
options for partcl:
For leo, you can now do oneliners with partcl:
../../parrot tcl.pbc -e=puts {hello world}
For debugging, you can now dump the PIR we're using instead of
executing it (works with or without -e):
./../parrot tcl.pbc --dump -e=puts {Hello, World}
.include languages/tcl/lib/returncodes.pir
$P1 = new .String
$P1=Hello, World
.local pmc command
dynamic_command1:
$P2 = new .String
$P2=puts
$S3=$P2
$S3 = . $S3
push_eh bad_command3
command = find_global Tcl, $S3
clear_eh
if_null command, bad_command3
$P3 = command($P1)
goto resume3
bad_command3:
$S3=$P2
$S3=concat invalid command name \ ,$S3
$S3.=\
.throw($S3)
resume3:
done_command1:
This is still not quite a standalone program, but contains most of
the good bits.
Re: zip: stop when and where?
Dave Whipp skribis 2005-10-06 9:57 (-0700):
Given that my idea about using optional binding for look-ahead didn't
fly, maybe it would work here, instead:
@a Y @b - $a, $b { ... } # stop at end of shortest
@a Y @b - $a, ?$b { ... } # keep going until @a is exhaused
@a Y @b - ?$a, ?$b { ... } # keep going until both are exhaused
I think we still need a way to determine if an optional arg is bound.
Can the Cexists function be used for that (if exists $b {...})?
Y isn't something that is specific to for loops, or to sub invocation,
so this cannot be a solution.
Also remember that Y creates a single flattened list by definition, and
that the given sub's arity determines how many items of that list are
used.
It's perfectly legal and possibly even useful to say
for @foo, @bar, @baz - $quux, $xyzzy { ... }
And even though
for @foo Y @bar Y @baz - $quux, $xyzzy { ... }
is something you will probably not see very often, it's still legal
Perl, even though it looks asymmetric. This too makes finding the
solution in arguments a non-solution.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: zip: stop when and where?
On 10/6/05, Juerd [EMAIL PROTECTED] wrote:
for @foo Y @bar Y @baz - $quux, $xyzzy { ... }
is something you will probably not see very often, it's still legal
Perl, even though it looks asymmetric. This too makes finding the
solution in arguments a non-solution.
Don't be silly. There's no reason we can't break that; it's not an
idiom anybody is counting on. If you still want the behavior:
for flatten(@foo Y @bar Y @baz) - $quux, $xyzzy {...}
But your point about Y returning a list and therefore not being
for-specific is quite valid.
Luke
$value but lexically ...
Cbut properties get attached to a value, and are available when the
value is passed to other functions/ etc. I would like to be able to
define a property of a value that is trapped in the lexical scope where
it is defined. The example that set me thinking down this path is
sub foo( $a, ?$b = rand but :is_default )
{
...
bar($a,$b);
}
sub bar( $a, ?$b = rand but :is_default )
{
warn defaulting \$b = $b if $b.is_default;
...
}
It would be unfortunate if the is_default property attached in foo
triggers the warning in bar. So I'd like to say somthing like
sub foo( $a, ?$b = 0 but lexically :is_default ) {...}
or
sub foo( $a, ?$b = 0 but locally :is_default ) {...}
to specify that I don't want the property to the propagated.
Re: Exceptuations
On Thu, Oct 06, 2005 at 18:11:38 +0100, Peter Haworth wrote:
The highest level exception is the only one a caller has any right to deal
with, but even then it doesn't really know what will happen if it resumes
some random continuation attached to the exception.
But then we gain nothing
CATCH {
when some_kind_of_error {
$!.continue($appropriate_value_for_some_kind_of_error)
}
}
That just gives me the willies, I'm afraid.
Why?
when i can't open a file and $! tells me why i couldn't open, i
can resume with an alternative handle that is supposed to be the
same
when I can't reach a host I ask a user if they want to wait any
longer
when disk is full I ask the user if they want to write somewhere
else
when a file is unreadable i give the user the option to skip
These handlers are progressively more knowlegable of the code
they're dealing with, but they don't touch the actual guts - that's
the whole merit of continuable exception, because otherwise you
might aswell just start over.
These are 100% reusable in the first exception handler, and not
reusable but still applicable to an opaque call at the last handler.
It doesn't matter who opens the file file, the exception handler
will produce the same effect but in a different way.
CATCH {
when Error::IO::... {
open ...
}
when MyApp::Timeout {
ask_user_to_continue_or_abort();
}
...
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpPY05BQiTGl.pgp
Description: PGP signature
Re: $value but lexically ...
On 10/6/05, Dave Whipp [EMAIL PROTECTED] wrote:
sub foo( $a, ?$b = rand but :is_default )
{
...
bar($a,$b);
}
sub bar( $a, ?$b = rand but :is_default )
{
warn defaulting \$b = $b if $b.is_default;
...
}
It would be unfortunate if the is_default property attached in foo
triggers the warning in bar. So I'd like to say somthing like
sub foo( $a, ?$b = 0 but lexically :is_default ) {...}
or
sub foo( $a, ?$b = 0 but locally :is_default ) {...}
to specify that I don't want the property to the propagated.
This came up before when I proposed lexical properties. That was
before we knew that a property was just a role. So you can do a
lexical property like so:
{
my role is_default {} # empty
sub foo($a, ?$b = 0 but is_default) {...}
}
{
my role is_default {}
sub bar($a, ?$b = rand but is_default) {...}
}
If this turns out to be a common want, I can see:
sub bar($a, ?$b = rand but my $is_default) {
warn Defaulted to $b if $b.does($is_default);
}
But I don't think it will be, and the empty role is easy enough.
Luke
Re: Exceptuations
On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote: when i can't open a file and $! tells me why i couldn't open, i can resume with an alternative handle that is supposed to be the same when I can't reach a host I ask a user if they want to wait any longer when disk is full I ask the user if they want to write somewhere else when a file is unreadable i give the user the option to skip I'm not bashing your idea, because I think it has uses. But I'll point out that all of these can be easily accompilshed by writing a wrapper for open(). That would be the usual way to abstract this kind of thing. Luke
[perl #37369] [TODO] empty lines in here docs
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #37369] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37369 Hi Jonathan, I've added test 22 in imcc/t/syn/const.t, which is currently failing. Could you have a look at it. It looks like empty lines a lost in here documents. If the intended behavior is different, I'll adapt the test. CU, Bernhard
Re: $value but lexically ...
Luke Palmer skribis 2005-10-06 14:23 (-0600):
my role is_default {} # empty
sub foo($a, ?$b = 0 but is_default) {...}
Would this work too?
0 but role {}
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: $value but lexically ...
On 10/6/05, Juerd [EMAIL PROTECTED] wrote:
Luke Palmer skribis 2005-10-06 14:23 (-0600):
my role is_default {} # empty
sub foo($a, ?$b = 0 but is_default) {...}
Would this work too?
0 but role {}
Most certainly, but you would have no way to refer to that role later,
so it is questionable how useful that construct is. No, it's not
questionable. That is a useless construct.
Luke
Re: [perl #37369] [TODO] empty lines in here docs
Bernhard Schmalhofer (via RT) [EMAIL PROTECTED] wrote: I've added test 22 in imcc/t/syn/const.t, which is currently failing. Could you have a look at it. It looks like empty lines a lost in here documents. If the intended behavior is different, I'll adapt the test. The test is right. There was a stupid bug in my code - sorry. It's fixed now. Thanks for reporting, Jonathan
Type annotations
Autrijus convinced me that we have to really nail down the semantics
of type annotation without use static. Let's first nail down what
I meant by semantics in that sentence. Basically, when do various
things get checked? Run time or compile time (not coercion; I have a
proposal for that coming).
Oh, I'm asking p6l here, not Larry in particular. This part of the
language is yet-undesigned, so some arguments one way or the other
would be nice to hear.
So we're in line one of a Perl program, with static typing/inference
disabled (or at least inference *checking* disabled; perl may still
use it for optimization). When do the following die: compile time
(which includes CHECK time), run time, or never?
my Array $a = 97; # dies eventually, but when?
my Int $b = 3.1415; # dies at all?
sub foo (Int $arg) {...}
foo(hello); # should die at the latest when foo() is called
sub bar (Int $arg -- Str) {...}
foo(bar(42));
sub static (Code $code, Array $elems -- Array) {
[ $elems.map:{ $code($_) } ]
}
sub dynamic ($code, $elems) {
[ $elems.map:{ $code($_) } ]
}
static({ $_+1 }, dynamic(notcode, [1,2,3,4,5]));
dynamic(notcode, static({ $_+1 }, [1,2,3,4,5]));
That should cover most of the interesting cases.
Luke
Re: Type annotations
On Thu, Oct 06, 2005 at 17:44:10 -0600, Luke Palmer wrote:
Autrijus convinced me that we have to really nail down the semantics
of type annotation without use static. Let's first nail down what
I meant by semantics in that sentence. Basically, when do various
things get checked? Run time or compile time (not coercion; I have a
proposal for that coming).
Oh, I'm asking p6l here, not Larry in particular. This part of the
language is yet-undesigned, so some arguments one way or the other
would be nice to hear.
So we're in line one of a Perl program, with static typing/inference
disabled (or at least inference *checking* disabled; perl may still
use it for optimization). When do the following die: compile time
(which includes CHECK time), run time, or never?
my Array $a = 97; # dies eventually, but when?
my Int $b = 3.1415; # dies at all?
Both die at compile time, because the user explicitly contradicted
him/herself. This is like saying
my int = $x :: float;
since they're constants and their types are very well known.
sub foo (Int $arg) {...}
foo(hello); # should die at the latest when foo() is called
Immediately, at compile time, for every caller of foo unless 'no
static' or whatever is active for that scope.
However, no inferencing is made - this is just 1 level deep.
sub bar (Int $arg -- Str) {...}
foo(bar(42));
Since -- is explicit I'm not sure if it means infer this even if
we're not globally inferring.
I lean towards compile time error here since I think it would be
nice to have that, but there are some disadvantages.
Perhaps this should infer only in the lexical scope that 'sub bar'
was defined in, to make sure that error reporting does not confuse
naive users of the module that defines foo, without asking for
compile time inference.
sub static (Code $code, Array $elems -- Array) {
[ $elems.map:{ $code($_) } ]
}
sub dynamic ($code, $elems) {
[ $elems.map:{ $code($_) } ]
}
static({ $_+1 }, dynamic(notcode, [1,2,3,4,5]));
dynamic(notcode, static({ $_+1 }, [1,2,3,4,5]));
This is only with full inferencing, either lexically enabled as a a
pragma (in the scope that invokes), or if enabled globally.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does a karate-chop-flip: neeyah!!
pgpJOaaHMZ2rN.pgp
Description: PGP signature
Re: Exceptuations
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote: On 10/6/05, Yuval Kogman [EMAIL PROTECTED] wrote: when i can't open a file and $! tells me why i couldn't open, i can resume with an alternative handle that is supposed to be the same when I can't reach a host I ask a user if they want to wait any longer when disk is full I ask the user if they want to write somewhere else when a file is unreadable i give the user the option to skip I'm not bashing your idea, because I think it has uses. But I'll point out that all of these can be easily accompilshed by writing a wrapper for open(). That would be the usual way to abstract this kind of thing. Stylistically I would tend to disagree, actually. I think it's cleaner to use exception handling for this. Also, this implies that you know that the errors are generated by open. This is OK for open(), but if the errors are generated from a number of variants (MyApp::Timeout could come from anywhere in a moderately sized MyApp), then wrapping is not really an option. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me groks YAML like the grasshopper: neeyah!! pgp5YNqHCrALu.pgp Description: PGP signature
Re: Type annotations
On 10/6/05, Luke Palmer [EMAIL PROTECTED] wrote:
So we're in line one of a Perl program, with static typing/inference
disabled (or at least inference *checking* disabled; perl may still
use it for optimization). When do the following die: compile time
(which includes CHECK time), run time, or never?
This is just my opinions as a Perl programmer in the trenches. I would
expect Typed variables to auto-coerce themselves, but not impose
fatality. Predictable auto-coercion would be nifty in quick-and-dirty
programs.
Ignore my advice at will -- nobody's required to use Types in their
own code, so there's no need for them to be universally valuable.
However, since I expect builtins and all standard functions to have
fully declared Type signatures, consider how these decisions would
affect _every_ program, before ordering the summary execution of
everyone's poor little Perl script.
my Array $a = 97; # dies eventually, but when?
Runtime -- cannot coerce Int value to Array
my Int $b = 3.1415; # dies at all?
Doesn't die, $b == 3. Int scalars should coerce anything which can be
prefix:+'d.
sub foo (Int $arg) {...}
foo(hello); # should die at the latest when foo() is called
$arg should be undef but Exception::InvalidInteger(Str value 'hello'
cannot be coerced to an Int at $?LINE)
sub bar (Int $arg -- Str) {...}
foo(bar(42));
If bar returns a Str ~~ /Perl6::Grammar::Int/, it gets coerced;
otherwise, undef but Exception
sub static (Code $code, Array $elems -- Array) {
[ $elems.map:{ $code($_) } ]
}
sub dynamic ($code, $elems) {
[ $elems.map:{ $code($_) } ]
}
static({ $_+1 }, dynamic(notcode, [1,2,3,4,5]));
die Str value 'notcode' cannot be called as a Sub reference -- have
you asked Larry how to make a symbolic function call, lately?;
dynamic(notcode, static({ $_+1 }, [1,2,3,4,5]));
Same.
Just my 2¢
Ashley Winters
Re: Exceptuations
Peter Haworth [EMAIL PROTECTED] writes:
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call
chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what type it should return and how to construct it? The innocent
foo() caller shouldn't bother about a quux() somewhere down the line
of command. Much less of its innards.
Well said.
No! Not well said at all!
Sorry, I misread that. I thought I was agreeng with how does a higher
level exception catcher know what to change in order to make resuming the
continuation useful?, especially in the light of Piers saying that the
bottom-most exception should be the one resumed.
I'm sorry, we appear to have lost some kind of context, the original example
given only had one exception thrown, but it got propagated up through a long
call chain. At no point did anything catch the original exception and
rethrow. If they had, you're absolutely correct in asserting that by default
things should resume from the point of the outermost rethrow. A brave exception
catcher (or more likely programmer with a debugger) might want to crack that
exception open and examine its inner exceptions, but in general that's not
going to be safe.
The scary syntax proposed above is, again, the sort of thing that might be
useful in a debugger I don't really care about the inner workings of these
helper functions, I just want 'open' to return this mocked handle. (actually
in that case, being able to do $!.caller(open).continue(MockIO.new), where
'caller open' looks up the call chain for the lowest call to open and returns
that continuation would be rather neat)
The highest level exception is the only one a caller has any right to deal
with, but even then it doesn't really know what will happen if it resumes
some random continuation attached to the exception.
Oh stop with the 'rights'. And it's not dealing with a 'random' continuation,
if it's going to resume it should be damned careful about which exceptions it
resumes from; you don't just go around doing CATCH {...; $!.continue(...)}, you
do CATCH SomeSpecificKindOfResumableException { ...; $!.continue(...)}. And, in
general, you don't do that either, because in the average program you catch the
exception at a point where you can simply return a sensible default to your
caller. Resumable exceptions come into their own, however, when you're
debugging. I can envisage doing:
perl6 -debug::on::error some_script
And have it run along happily until an exception gets propagated up to the top
level, at which point the debugger swings into action and uses the continuation
to tunnel back to the point at which the exception was thrown so the programmer
can inspect the program state, possibly fix things up, return something
sensible and carry on.
CATCH {
when some_kind_of_error {
$!.continue($appropriate_value_for_some_kind_of_error)
}
}
That just gives me the willies, I'm afraid.
It doesn't amuse me that much, unless whatever generates
$appropriate_value_for_some_kind_of_error is very, very smart indeed. But, as
I've said above, that's not really where resumable exceptions shine.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
