Parrot 0.9.0 "From Outer Space" Released | parrot.org/ | svn transition complete-ish
Set by moderator on 29 January 2009.
00:02 AndyA joined
Whiteknight I may be missing something, but on i386 systems is there a difference between "return(0);" and "__asm__("ret")"? 00:08
TiMBuS you'd need to put 0 in eax 00:09
Whiteknight I mean, besides the fact that "return(0)" is going to null out EAX?
Okay, so I'm not missing any other differences? I feel like I'm going crazy over here
TiMBuS if the function requires some stack fixing up there might be a difference, but the compiler should fix that 00:10
theres also the leave opcode or something.
Whiteknight I'm trying to get rid of the cpu_ret opcode, which uses the __asm__("ret"). I want to replace it with the end opcode which does return(0)
and if the translation is as straight-forward as I seem to think it is, this should be very easy. 00:11
00:12 Andy joined
Coke I have resurrected my power ppc darwin box for the evening. 00:31
Coke wonders if rurban is about.
irclogs 00:33
irclogs?
purl irclogs is probably irclog.perlgeek.de/parrot/today
Coke is reminded AGAIN it would have been quicker to rsync with a local copy of the repository than it would have been to do an svn checkout. 00:34
Coke hopes this laptop is only so slow running configure.pl because he's also running software update for the first time in a year. 00:49
chromatic Also it's haunted. 00:58
01:01 kj joined 01:02 altious joined 01:04 kid51 joined 01:28 particle joined 01:38 Tene_ joined 02:31 ask_ joined 02:41 Andy joined
Coke laptop was haunted; after software update, it won't reboot. 02:45
kid51 Let me guess: Ubuntu 8.10? 02:46
Coke: Any feedback on these TTs? 107 109 255 108 107 02:48
Coke 107?? 02:54
ah.
for some reason, trac showed me 170.
I just commented on 107. 02:55
dalek rrot: r36180 | coke++ | trunk/DEPRECATED.pod:
track TT #109
 02:57
Coke #255: no commment
You had 107 on there 2x. 03:00
I commented on the rest.
kid51 Saw your comments. Fixed one patch but taking no other action pending deprecation decisions. 03:06
Coke wonders what the point of trac.parrot.org/parrot/wiki/BuildStatus is. 03:16
Don't we have tickets for things that break the build?
I could see having a BuildWarnings page, as those don't need tickets.
Infinoid ...especially when it lists issues with tickets that have since been closed... 03:19
Coke adds one.
kid51 And 2/3 of the info is out-of-date. t/shootout was fixed by chromatic and has been running smoothly for months. t/stm/* doesn't exist anymore.
Coke feel free to kill the page, then. 03:21
(it's linked to from the front page of the wiki) 03:22
kid51 How does one actually kill a wiki page? 03:23
kill -9 ?
purl REALLY dirty AND bad-mannered
Tene_ a wiki tire iron?
kid51 It's a secret: Hit the button that says "Delete page' 03:24
kid51 now has Wiki blood on his hands! 03:25
Coke trac.parrot.org/parrot/changeset/35977 is slooooooow 03:34
dalek rrot: r36181 | coke++ | trunk/compilers/imcc/optimizer.c:
eliminate reference to rejected TODO ticket.
 03:48
rrot: r36182 | coke++ | trunk/compilers/imcc/optimizer.c:
remove reference to obsolete ticket.
 03:50
kid51 must sleep 03:53
purl $kid51->sleep(8 * 3600);
dalek rrot: r36183 | coke++ | trunk/compilers/imcc/optimizer.c:
remove confusing bit of function doc and reference to rejected ticket.
Whiteknight Coke, pic_callr__ is still used in JIT 03:55
I think I can come up with a workaround for it, but I don't have one yet
Coke except that there's an item in the ticket to remove it. 03:56
so there's no point to keeping a ticket to fiddle with it.
Whiteknight when is the remove_pic branch trying to land? 03:58
Coke 2 releases ago.
the only thing holding it up is that jit invocation.
04:13 Theory joined
dalek rrot: r36184 | coke++ | trunk:
Welcome to the shadowy underworld of a file... that does not exist.
 04:14
moderator Parrot 0.9.0 | parrot.org/ | 566 RTs left. 04:16
Coke msg jonathan if you could remove Data::Escape from dotnet, that'd be helpful. 04:22
purl Message for jonathan stored.
rg coke: unfortunately a simple perl rt account can't close old tickets. 04:25
04:43 ChrisDavaz joined 04:47 Theory_ joined 05:16 clunker3__ joined 05:33 ChrisDavaz left 05:39 Theory joined 06:08 cognominal joined 06:13 Zaba_ joined
dalek rrot: r36185 | petdance++ | trunk/src/pmc/resizablebooleanarray.pmc:
removed unused variable
 06:39
Tene_ Coke: was it you who cared about throwing exceptions from within an EH? 06:55
dalek rrot: r36186 | petdance++ | trunk/src/io/unix.c:
consting, removed an unused return
 07:00
rrot: r36187 | petdance++ | trunk/src/ops/set.ops:
removed unused var
 07:01
rrot: r36188 | petdance++ | trunk/src/pmc/packfiledirectory.pmc:
consting
 07:02
purl i guess consting is even more dire now that I got GCC's flags the way I want 'em.
Andy purl, forget consting
purl Andy: I forgot consting
Tene_ Oh, argh, nevermind, that won't work. 07:03
07:26 iblechbot joined 07:41 rurban_ joined 08:09 riffraff joined 08:15 HG` joined
Tene_ ARGH PARROT 08:36
I'm running out of ideas here. I'm looking for a way for an exceptionhandler to determine if an exception was thrown from itself.
08:46 MagnusShortwave joined
TiMBuS Tene_, set up an exception handler.. in your handler? 09:27
Tene_ TiMBuS: right now in parrot if you throw an exception from within an exception handler, that same handler catches that exception 09:29
TiMBuS really? even if you push a new handler? 09:30
Tene_ well, no, not if you pushed a new handler.
if you pushed a new handler from the handler, the new handler would catch it.
The issue is that you can get infinite loops when an EH catches an exception thrown from itself and doesn't know what to do with it or it causes some other sort of error, so another exception, etc. 09:31
TiMBuS well an exception thrown from a handler should only be caused by unexpected errors in a handler shouldnt they? 09:32
Tene_ That's right.
So the general answer right now is "Just be careful" 09:33
TiMBuS well, i dunno if its unexpected you can't tell what it is, so maybe set up handlers that only deal with specific error codes otherwise they rethrow
Tene_ Right.
The issue is that Parrot should probably at least do something helpful in that case instead of an infinite loop. 09:34
TiMBuS orr, put a handler in your handler that will mark a 'handler exception' that is ignored by handlers or something
Tene_ Sure.
TiMBuS thats a terrible way to fix it :/
Tene_ i'm not looking for workarounds. I'm trying to figure out how i can get Parrot itself to detect this case and do something helpful.
09:36 riffraff joined
TiMBuS that difficult. id assume people sometimes want to throw an exception from a handler? 09:36
Tene_ Nobody currently wants to do that.
lathos There's no real reliable way to detect an infinite loop, rather than just a very deep loop. 09:37
Tene_ Occasionally people have run into this situation by accident.
TiMBuS yeah i have
called die from inside an error handler
Tene_ lathos: there *should* be a way for the EH to detect that the exception is being thrown from the EH, though.
lathos Why would an EH ever throw an exception that it can't handle? 09:38
Tene_ dunno
TiMBuS well say you try to perform an operation on a pmc that cant be done..
in your handler. 09:39
lathos Yes. You get an exception. Which you handle.
Tene_ {handler:\\n$I0 = 1/0} (approximately) will infinite loop in Parrot. 09:40
TiMBuS but you arent really expecting that kind of error since the handler was likely set up for a different reason? at least thats where i expect infinite loops to form
lathos Tene_: Yes, but that would be an unwise thing to do.
TiMBuS: But if you're not expecting that error, you pass it (I'm assuming you *can* pass it down the stack.) 09:41
TiMBuS but it shouldnt loop forever =/
Tene_ lathos: more commonly, you write a generic catchall handler only expecting a single specific type of exception. If a different type of exception comes in and you try to operate on it, you might run into problems.
if any of those operations fail, infinite loop
moritz in assembler you can simply loop with `dec EIP' 09:42
lathos Tene_: Then you need to manage your expectations better.
Tene_ lathos: Sure.
TiMBuS i dont think you're allowed to dec eip are you?
lathos If you don't code an *exception handler* - of all things - with the expectation that things might go wrong, you probably deserve the infinite loop.
TiMBuS you have to do a short jmp -5 or something
moritz TiMBuS: I never actually tried it :/ 09:44
Tene_ sleep 09:47
09:55 alvar joined 10:05 altious joined 10:34 AndyA joined 10:35 AndyA joined 11:07 barney joined 11:08 Ademan joined 11:36 jan_ joined 12:01 MagnusShortwave joined
dalek rrot: r36189 | fperrad++ | trunk:
[perldoc] fix RT #62920
 12:06
12:07 schmalbe joined
dalek rrot: r36190 | barney++ | trunk/README:
[docs] Use the regukar char for underlining
 12:12
cotto It is very dark. Zcode is likely to be eaten by a grue. 12:15
12:29 rg joined
rg tene_: that was me with the exceptions. reading logs now. 12:31
dalek rrot: r36191 | barney++ | trunk/docs/gettingstarted.pod:
[docs] s/svn.perl/svn.parrot/
 12:32
rrot: r36192 | barney++ | trunk/docs/gettingstarted.pod:
[doc] Add link to ParrotDeveloperGuide
rg i think it's totally valid code to throw an exception from an exception handler. 12:39
i'm thinking of the usual try/.catch cenario here.
like this: try { try { <code throwing exception> } catch { handler throwing exception> } } catch { <handler supposed to catch the inner handler's exception> } 12:41
message tene please try and ping me if you're going to work on exception handlers 12:47
purl Message for tene stored.
rg (actually anyone really ;))
cotto rg, noted 12:49
Is there anything I should be especially cognizant of? 12:50
rg for one, the example i just gave should be doable ;)
dalek rrot: r36193 | barney++ | trunk:
[docs] s/parrotcode.org/parrot.org/
 12:51
rrot: r36194 | barney++ | trunk/docs/gettingstarted.pod:
[docs] refer to submissions.pod for submitting patches and reporting
rg cotto: are you planning to work on exceptions? 12:54
cotto nothing more involved than updating some code to use ATTRs. 12:55
iirc Exceptions already use them, but ExceptionHandlers still have some PMC_x_val instances. 12:56
12:56 altious joined
rg i don't think that touches on the problem i'm trying to figure out. 12:58
cotto Probably not, but I've created two (known) obscure bugs so far in converting other PMCs. 13:00
dalek rrot: r36195 | rurban++ | trunk/t/native_pbc/number.t:
[test] TT #254. mark as TODO for big-endian numval transform.

Note: intval transform in darwin/PPC works okay (endianness-transform), but the numvalsize is equal and fails on the endianness-transform.		 13:27
rurban message kid51 can you please commit a t/native_pbc/number_2.pbc for darwin/PPC so that I can test the failing numval transformer. 13:28
purl Message for kid51 stored.
rurban anyone with darwin/ppc around?
anyone with a big-endian machine around? 13:42
13:59 masak joined
schmalbe cia.vc/stats/project/parrot in now polling the new svn repository, 14:04
however some commits were skipped
bbl 14:06
14:09 Whiteknight joined 14:11 flh joined 14:17 altious joined 14:18 contingencyplan joined 14:22 altious joined 14:26 kid51 joined
dalek rrot: r36196 | whiteknight++ | trunk/docs/book/ch02_getting_started.pod:
[Book] Add some notes about some of our development requirements. Thanks to an email from fperrad++ for the information
 14:38
masak www.parrotcode.org/docs/roadmap.html is _empty_. if it's superceded by another page, I think it should at least contain a link to the new page. it's still very easy to end up there with a google search.
14:50 altious joined
dalek rrot: r36197 | whiteknight++ | trunk/docs/book/ch03_pir_basics.pod:
[Book] A few updates to chapter 3. Talk more about creating new classes, create a section for an indepth discussion of vtables, and remove some erroneous whitespace
 14:51
rrot: r36198 | fperrad++ | trunk/lib/Parrot/Distribution.pm:
[lib] find more Perl files
 14:56
rrot: r36199 | fperrad++ | trunk/config/gen:
[codingstd] fix Perl coding standard in template files.
 14:58
rrot: r36200 | fperrad++ | trunk:
[configure] rename a Perl template & fix coding standard
 15:01
rurban kid51: can you please commit a t/native_pbc/number_2.pbc for darwin/PPC so that I can test the failing numval transformer. see tt #254 15:11
15:22 Limbic_Region joined
dalek rrot: r36201 | fperrad++ | trunk/t/codingstd:
[t] no need to skip generated files
 15:28
15:40 rurban_ joined
nopaste "kid51" at 71.247.39.207 pasted "number_2" (17 lines) at nopaste.snit.ch/15468 15:56
kid51 rurban: Is that what you were looking for?
rurban kid51: no, I'd need the n.pbc 15:57
best commit it as number_2.pbc
t/native_pbc/number_2.pbc exactly 15:58
kid51 I don't understand what you mean by "commit" it. It's in SVN: 36200 35854 chromatic t/native_pbc/number_2.pbc 15:59
rurban yes, but pdump cannot read it. we need to update it with every byteocde version change
kid51 So what do I have to do next? 16:00
rurban mv n.pbc t/native_pbc/number_2.pbc
svn commit t/native_pbc/number_2.pbc
and as commit message: "TT #254, PPC double float 32 bit BE opcode_t" 16:01
kid51 Well, I committed it before I saw the commit message you wanted. 16:02
dalek rrot: r36202 | jkeenan++ | trunk/t/native_pbc/number_2.pbc:
Committing latest n.pbc.
rurban not problematic, thanks
I'll document the format in number.t 16:03
kid51 BTW, t/native_pbc/number.t just passed for me on Darwin/PPC. 16:05
16:05 Tene joined
rurban Great. it fails in the same way as yours, so I can fix it, in one way at least. 16:05
dalek rrot: r36203 | rurban++ | trunk/t/native_pbc/number.t:
Add the "PPC double float 32 bit BE opcode_t" test as 2nd. r36202.
 16:11
Whiteknight rurban, where do you want me to send my .pbc files? 16:25
I have the two you asked for in the email, and I posted my results from pdump to the ticket
kid51 Now, t/native_pbc/number. t fails again on Darwin/PPC, i.e., after r36203 16:26
Should I have rebuilt Parrot? 16:27
bbl 16:29
rurban Whiteknight: to parrot-dev probably 16:32
Whiteknight rurban: Okay! I'll attach them and send out an email now
rurban kid51: no, parrot rebuild is not necessary
kid51: I'll fix the bug in parrot first, then I'll adapt the tests. wait a sec... 16:34
dalek rrot: r36204 | fperrad++ | trunk/config/gen/config_pm.pm:
[configure] use a more standard header in Generated.pm
 16:41
16:48 lathos joined
rurban ok, I found the packfile reader bug, It assumed a IEEE-754 8 byte double was 12 bytes long 16:49
Whiteknight that fixes the problem for integer.t also? 16:53
rurban No. I'm just testing the double problem first. 16:54
Whiteknight oh, ok
rurban Anyone has a system with long double also?
Whiteknight what file are you looking in, src/packfile.c?
rurban my fix is in src/packfile/pf_items.c:623 16:55
! pf->header->floattype => pf->header->floattype
Whiteknight ah, I see it now
rurban it converts a 12-byte long double to a 8-byte double
but the stream advance was wrong 16:56
12 mixed up with 8
I inverted it and now it works fine
Whiteknight how do I set up the build to use a long double?
rurban ?? if I know I would have done it :)
Floattype 1 = x86 little endian 12 byte long double is the problematic one 16:58
nopaste "rurban" at 212.183.63.195 pasted "tt254-floattype1-bug.patch" (32 lines) at nopaste.snit.ch/15469 17:03
17:06 LimbicRegion joined
Whiteknight perl Configure.pl --floatval="long double" 17:06
I'm building with that right now 17:07
rurban Interesting. I'd like to hear the results. you can easily test it with number_1.pbc and number_2.pbc. I attached my fix also to the ticket. 17:08
Whiteknight didn't even build. 17:10
rurban what makes me wonder is that Floattype 1 = little endian only
looks like some very special case here 17:11
I'm testing on more platforms now, and apply my fix then.
17:14 Theory joined
rurban kid51: can you test the failing integer.t with this patch: trac.parrot.org/parrot/attachment/...-bug.patch 17:18
shorten rurban's url is at xrl.us/beefz7
rurban kid51: we have a minor problem with your number_2.pbc. it was based on number_2.pasm, not number_1.pasm 17:27
can you rebuild it on darwin?
17:36 chromatic joined
rurban Whiteknight: excellent. your two files have the untested **need** opcode transform. all works for me. 17:36
dalek rrot: r36205 | rurban++ | trunk/src/packfile/pf_items.c:
Fix the failing t/native_pbc/number.t tests in TT #254.

Fixes the pf_item floatval reader if a conversion is requested, and floatval is a normal IEEE-754 8 byte double. The bug was a wrong advance of 12 byte on
   (NUMVAL_SIZE == 8 && ! pf->header->floattype)		 17:41
chromatic It's not possible to say rurban++ enough for that. 17:42
17:42 PacoLinux joined
rurban chromatic; we'd need more native pbc's. little-endian 64-bit tru64, big-endian 64-bit irix, ... 17:44
I wanted to get that fixed before 1.0
chromatic I'm not sure we have hackers on those platforms, let alone successful builds.
I've fixed as much as I can of Jarkko's Tru64 problems, but I'm sure others remain. 17:45
He suggested finding a picky Sparc somewhere.
rurban I see. Do you have any idea where the strange floattype 1 "x86 little endian 12 byte long double" came from?
This is special cased. 17:46
lathos DOn't forget that things like qemu let you make funny computers for free.
rurban I know. But setting up those beasts needs a lot of time. My Solaris 10 (sun5 64bit) image still misses a c compiler 17:47
dtrace is working ok though.
chromatic I have no idea about 12 bytes. 17:49
17:50 alvar joined
dalek rrot: r36206 | rurban++ | trunk/t/native_pbc:
t/native_pbc/*_3.pbc:

  - darwin/ppc pbc's need to be regenerated (as _2)		 17:58
18:01 kid51 joined
rurban Hi kid51, I need you again :) 18:01
kid51 ?
rurban your number_2.pbc was based on number_1.pasm, not number_1.pasm, so we'll get wrong results. 18:02
And getting an updated integer_2.pbc would also be nice.
Should I send you instructions?
kid51 ok. I don't know much about this area and so I'm proceeding blindly. Yes, send instructions (or paste). 18:03
rurban ... your number_2.pbc was based on number_1.pasm, not number_2.pasm, so we'll get wrong results.
kid51 Am now rebuilding after svn up to r36206. 18:05
Whiteknight rurban++
nopaste "rurban" at 212.183.63.195 pasted "for kid51: on darwin/ppc" (13 lines) at nopaste.snit.ch/15470 18:08
kid51 Will integer_2.pbc and number_2.pbc be present after just 'make'? 18:11
chromatic You'll have to rebuild them explicitly. 18:12
kid51 And the best way to do that is ... ? (I was running t/op/number.t earlier.)
rurban kid51: see nopaste.snit.ch/15470 18:13
kid51 So that's what happens with ./parrot -o ? 18:14
rurban yes. brute-force
kid51 K. waiting on 'make', which is slow on this iBook 18:15
rurban great! thanks
dalek rrot: r36207 | barney++ | trunk/config/gen/makefiles/dynpmc_pl.in:
[codingstd] perlcritic.t
 18:17
rrot: r36208 | barney++ | trunk/languages/pipp:
[Pipp] add support for lone semicolons
Whiteknight rurban: I'm still getting failures in both those tests after a realclean and an update 18:30
is there anything else I need to do on my end? 18:31
do I need to regenerate those .pbc files?
kid51 rurban: I got this: ./parrot -o t/native_pbc/number_2.pbc t/op/number_1.pasm
Error reading source file t/op/number_1.pasm.
Looks like I'll have to run t/op/number.t first. 18:32
rurban yes, sorry
nopaste "kid51" at 71.247.39.207 pasted "Another try at pbc" (257 lines) at nopaste.snit.ch/15471 18:37
kid51 rurban Take a look at that before I commit. 18:38
rurban yes, both look good. please commit 18:39
with the integer.pbc we have now an interesting test for - as filename. tools/util/dump_pbc will not like it :) 18:40
dalek rrot: r36209 | jkeenan++ | trunk/t/native_pbc:
Fix #254: regenerate darwin/ppc native_pbc tests as _2
rurban jkeenan++ thanks
and another one for kid51++ 18:41
kid51 So, do you have more work to do before the tests will pass on all OSes?
rurban I believe it should pass now, but we will see tomorrow
litlle-endian integer 64-bit would be interesting 18:42
can you try x86_64 with ICC? 18:43
nopaste "kid51" at 71.247.39.207 pasted "t/native_pbc/*.t on Darwin/PPC after r36209" (15 lines) at nopaste.snit.ch/15472
rurban great. looks like this was the only bug. I remove now the todo's from the tests 18:44
kid51 rurban: I don't have x86_64 w/ICC ... IIRC that was infinoid.
No , not infinoid ... dmajnem2 (See irclog.perlgeek.de/parrot/2009-01-30 at 01:50) 18:47
be back later tonight. 18:48
18:49 ask_ joined 18:59 davidfetter joined 19:00 rindolf joined
rindolf Hi all. 19:00
I'm having trouble with my parrot svn working copy: 19:01
svn: Repository moved temporarily to 'svn.parrot.org/parrot/trunk'; please relocate
moritz rindolf: well, relocate :-)
rindolf moritz: I did that.
moritz rindolf: there's an announcment on parrot.org
rindolf moritz: but it still warns me.
rurban how did you relocate? 19:02
rindolf rurban: svn switch --relocate
moritz that worked for me
rurban there are two args missing
from to
rindolf rurban: well - svn switch --relocate 'svn.perl.org/parrot/' 'svn.perl.org/parrot/' - is the complete command 19:03
rurban do you have https:// in your . svn/entries ?
most likely it's https:// vs http:// 19:04
moritz rindolf: it might be easiest to do a new checkout
rurban oh no. you have to switch from perl to parrot. svn switch --relocate svn.perl.org svn.parrot.org
moritz (and if you have local changes, safe them to a patch first) 19:05
rindolf rurban: oh, I see.
dalek rrot: r36210 | fperrad++ | trunk/config/gen:
[configure] update the generation of config_lib.pasm

  - rename template
  - more standard header		 19:10
rrot: r36211 | rurban++ | trunk/t/native_pbc:
[test] native_pbc: remove todo's for new darwin/ppc pbc's.

  - Add missing headers for ppc and x86_64		 19:11
rrot: r36212 | fperrad++ | trunk/MANIFEST:
rename file, so update MANIFEST
rrot: r36213 | fperrad++ | trunk/editor:
svn:ignore pir.vim (generated file)
 19:13
rrot: r36214 | fperrad++ | trunk/lib/Parrot/Configure/Compiler.pm:
[configure] remove vim ft generation
 19:16
Tene rg: ping 19:31
rg pong 19:37
tene: did you read what i said earlier today? 19:38
Tene rg: just the hilights where you mentioned my name. If there's more I'll go back and read. 19:40
rg: the problem is in differentiating between an exception thrown earlier in the same PIR sub and an exception thrown from the handler part of that sub. 19:42
rg my main point is to get this to work: try { try { <code throwing exception> } catch { <handler throwing exception> } } catch { <handler supposed to catch the inner handler's exception> } 19:43
Tene rg: that *can* work if you're careful about setting what types of exceptions can be caught.
19:44 iblechbot joined
rg to trigger the problem let's assume it's the same e3xception (or simply a catch all) 19:44
Tene try { try { <throw IOexception> } catch IOException { <throw SomeOtherException> } } catch { ... }
Right. 19:45
I'm just not sure that it's possible for the EH to detect whether the exception was thrown from earlier in the PIR sub or from the handler itself.
.sub 'foo'; push_eh handler; throw exception; pop_eh; .return (); handler:; throw secondexception; .end 19:46
rg i don't think you have to. in pir you can just pop_eh your handler after getting your exception
Tene If you're the top-level handler 19:47
rg: you can also inspect the exception and choose to rethrow it, which doesn't run into this problem.
I can detect if it was thrown from the same PIR sub by comparing the from_context of the resume continuation in the exception against the context of the EH. 19:49
rg but won't the first handler be called again when a new throw happens in the next handler?
Tene But that would match in both of the cases in that example.
rg: I think so, yes. I'm not certain. 19:50
rg that's what i have to avoid
Tene Out of curiosity, what's the reason you're throwing from an EH anyway? 19:51
rg just an exceptional condition i'd like to handle with a more global handler. i find that quite common in java for example. 19:52
Tene why is the more global handler throwing more exceptions?
rg no, the more specific handler is throwing the exception
Tene I think I'm confused. 19:54
rg sorry ;)
let's go back to the try/catch example.
the inner (more specific) handler caught an exception and decides "well there's nothing i can do about it here, let's throw a new exception". none of the hlls i know have a rethrow. 19:56
Tene Rakudo handles it by generating code to check the 'handled' attribute and rethrow if it's not set. 19:58
rg of course it doesn't want to handle that exception again, it needs to go to an outer handler
Tene fwiw
rg i don't think rakudo has it right, either. but that may be me not knowing enough perl6 yet ;)
Tene It probably doesn't.
Anyway, you've satisfied my curiosity. 19:59
My next goal is to try looking in the backtrace of the exception for clues.
rg try running this in rakudo (but not by polyglotbot, it's an ionfinite loop):
try { die("dead"); CATCH { say "handler: $_"; die("deader"); } }
Tene Yes, that will loop.
rg is that intentional?
Tene I'm not sure. Probably not. 20:00
rakudo: try { try { die("dead"); CATCH { say "inner handler: $_"; }} CATCH {say "outer handler: $_"; }}
polyglotbot OUTPUT[Statement not terminated properly at line 1, near "CATCH {say"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤called from Sub 'parrot;Perl6;Grammar;eat_terminator' pc 32164 (src/gen_grammar.pir:3388)␤called from Sub 'parrot;Perl6;Grammar;statementlist'
..pc 30812 (src/gen_grammar.pir:2855)␤called from...
Tene Anyway, I agree that this needs to work. 20:01
I just don't know how I can even detect this case at all yet.
If all EHs were in their own subs instead of labels, I could make it work now. 20:02
I don't know if that works in Parrot or not.
rg i'm wondering if any skipped or called handler should be removed from the stack
but i don't know enough about continuations yet to know if that could work. 20:03
Tene they're removed from an iterator that the exception holds to use for rethrow.
rg so imagine they were really removed from the stack. rethrow differs from throw only for noting the stack trace. what would happen? 20:04
20:05 geof joined
Tene how would they get restored when you invoke the resume continuation? 20:05
rg either the continuation has a copy of the (exception) stack at the point of the throw or it keeps the list of removed handlers 20:06
Tene That solution feels very wrong to me. I'm not completely convinced, but it's my inclination. 20:07
I'll think about it.
rg i'm not sure it's the way to go, either. i'm just tossing out ideas ;)
do you know an example where an eh would want to catch an exception it throws itself? 20:08
Tene I don't. I agree that this is probably the way it should work. I'm just having issues with the implementation. 20:11
rg sorry, i haven't made my way through the parrot code far enought to be of help. but i'll keep reading ;) 20:12
maybe you can help me understand something related. i've read that a hll return statement is also implemented using exceptions. how does that fit in? 20:18
moritz the sub or method from which return() returns installs an exceptoin handler 20:19
Tene grep CONTROL_RETURN runtime/parrot/include/except_types.pasm
moritz and return() throws the corresponding exception
Tene that EH is set up with a filter to only catch CONTROL_RETURN exceptions
and ignore all others
rg and do my own ehs automatically ignore CONTROL_RETURN exceptions? are they removed from the stack? 20:21
Tene your own ehs won't ignore control_return unless you ask for it.
rg how do i do that? and will they be removed from the stack when a return happens? 20:23
Tene eh = new 'ExceptionHandler'; set_addr eh, handler; eh.'handle_except'(.CONTROL_RETURN); push_eh eh
and yes, removed from the stack when a return happens. 20:24
rg ah. good. thanks.
Tene bbl, errands. 20:25
Whiteknight rakudo: say $x; 20:28
polyglotbot OUTPUT[Scope not found for PAST::Var '$x' in ␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤called from Sub 'parrot;PAST;Compiler;post_children' pc 2075 (src/PAST/Compiler.pir:410)␤called from Sub 'parrot;PAST;Compiler;call' pc 4312
..(src/PAST/Compiler.pir:1094)␤called from Sub 'parrot;PAST;Compiler;post_chil...
Whiteknight rakudo: my $x; say $x;
polyglotbot OUTPUT[Use of uninitialized value␤␤]
Whiteknight rakudo: my $x = 5; { say OUTER::$x; } 20:41
polyglotbot OUTPUT[Statement not terminated properly at line 1, near "::$x; }"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤called from Sub 'parrot;Perl6;Grammar;eat_terminator' pc 32164 (src/gen_grammar.pir:3388)␤called from Sub 'parrot;Perl6;Grammar;statementlist' pc
..30812 (src/gen_grammar.pir:2855)␤called from Su...
Whiteknight rakudo: my $x = 5; { say OUTER::$x; };
polyglotbot OUTPUT[Statement not terminated properly at line 1, near "::$x; };"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤called from Sub 'parrot;Perl6;Grammar;eat_terminator' pc 32164 (src/gen_grammar.pir:3388)␤called from Sub 'parrot;Perl6;Grammar;statementlist'
..pc 30812 (src/gen_grammar.pir:2855)␤called from S...
Whiteknight rakudo: my $x = 5; { say $OUTER::x; };
polyglotbot OUTPUT[Use of uninitialized value␤␤]
Whiteknight rakudo: my $x = 5; do { say $OUTER::x; }; 20:42
polyglotbot OUTPUT[Use of uninitialized value␤␤]
Whiteknight rakudo: $x = 5; do { say $OUTER::x; };
polyglotbot OUTPUT[Scope not found for PAST::Var '$x' in ␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤called from Sub 'parrot;PAST;Compiler;post_children' pc 2075 (src/PAST/Compiler.pir:410)␤called from Sub 'parrot;PAST;Compiler;call' pc 4312
..(src/PAST/Compiler.pir:1094)␤called from Sub 'parrot;PAST;Compiler;post_chil...
particle doesn't matter how many times you shout it, OUTER isn't implemented. 20:51
20:53 mberends joined
Whiteknight ah, that would be my problem 21:01
thanks for the notice
21:10 Tene joined 21:34 clunker9 joined 21:47 Theory joined 21:56 idemal joined 22:03 cognominal joined 22:19 alvar joined 22:32 altious joined 22:49 jrockway joined, altious joined 23:20 Eevee joined 23:24 Theory joined 23:40 rurban_ joined 23:50 kid51 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!