% particl1 has left particl1!~particle@c-24-22-165-145.hsd1.mn.comcast.net % particle has joined #parrotsketch % mdiep_ has left mdiep_!~mdiep@c-71-205-39-103.hsd1.mi.comcast.net % kjs has joined #parrotsketch % pmichaud has joined #parrotsketch % jhorwitz has joined #parrotsketch % kjs has left kjs!~IceChat7@221.218.214.101 % Andy has joined #parrotsketch Are we not sketching? % jisom has joined #parrotsketch I'm here to sketch i'll take the helm today, since coke and chromatic seem absent. who's here to report? present it's a light week due to yapc::eu okay, then. andy, wanna start things up? OK EOR Next? jhorwitz: what's new? a plethora of updates to mod_parrot to remove deprecated ops and more importantly migrate to pdd15 objects all tests pass once again looking forward to nqp enhancements EOR okay, i'll go ~ some cleanup commits this week, more reading than anything else ~ reading on tree ssa form, thinking about optimizing passes for pct ~ #perl6 now has an evalbot for pugs, kp6, nqp, and perl6 (moritz++ and rhr++) ~ considering a LOGO implementation once we have hll->nci bindings .end pmichaud? I didn't pre-type my report today, so on-the-fly we've got time :) * Issued the 0.4.15 release, that went fairly smoothly * More updates to NQP, many from perlDreamer++ * I've been working on handling namespaces in PAST/POST/NQP * Also have been explaining why the 'return' statement has to be handled as an exception :-) EOR anybody not having fun? anybody blocking? my only block is energy. :-( we'll try to move you somewhere hotter :) heh, no thanks. That's probably what has been zapping my energy :-) okay. comment/question time. anyone? I upgraded my system so my dvd drive doesn't work and I broke debuggging, and jit s/doesn't/does/ which jit? amd64, just changed my system software, not parrot odd. well, 64-bit jit hasn't worked for me yet (but I'm intel) i'd *love* to get 64bit parrot working on win32 still having miniparrot segfaults then i can help with 64bit jit tried more than one compiler? no, i haven't. i dunno about other 64bit compilers for win32 just msvc pro (can't use the free one for 64bit) pmichaud: would implementing warnings be any easier than implementing returns? i know they're both exceptions, but the handlers are in a different place particle: what sort of warnings? eg. deprecated perl 5 syntax you mean at a compile-time level? isn't that just basically a resumable exception i don't want 'die' behavior. what behavior do you want? You want to be able to throw/catch an exception? like perl 5's use warnings so, yes. I'm lost -- I don't see the relationship with returns if we can enable/disable warnings lexically, it's a step closer to returns in my mind (but perhaps i'm incorrect) { no warnings 'foo'; generate_foo_warning; } say "ok"; { no warnings 'foo'; } generate_foo_warning; say "ok"; tests like that I still don't understand... but perhaps this answers your question: the issue with returns/exceptions has nothing to do with the display of warning messages essentially, PAST has to have a way for a lexical sub to be able to catch an exception of type 'return' the exception payload has to have a return value, which the lexical sub can then return to its caller (via a Parrot .return statement) if a lexical sub catches an exception that isn't of type 'return', it has to re-throw it or pass it to its outer handler PAST also has to have a way for a lexical scope to catch an exception of type 'warning'. the payload is a message, and execution resumes at the throw point. i see in this some of the pieces needed for returns PAST already has the ability to do try/catch blocks okay, so warnings are already implementable at the past level. cool. we just need to add an Exception class that can represent the various types of exceptions we'll have in PAST (off-the-cuff list: return, warn, die, next, last, redo) goto? i think it's about time we extend the exception model to allow subs as handlers, rather than only labels would that help here? not really -- labels works out easier for me i guess i'm missing the bit that's hard. it's not the payload. it's not the throw. it's the api it's the defining of the exception class ah, okay. now i see. i'd be happy to talk that out with you on #parrot or via email right -- I just want to get the namespaces stuff resolved first it's not particularly hard, just time consuming np (and people's initial thought for implementing "return" is to try to translate it directly to a PIR .return statement, which doesn't work for most HLLs. Although Coke repeatedly explains how Tcl does it the way it's supposed to be done :-) oh, by way of update, parrot 64bit on win32 no longer segfaults with miniparrot. now it segfaults when building pge. yes, tcl uses exceptions for return, so there's probably something useful there :) oh, good to see ptc working on coverity. i need to get an account, so i can do more than watch. anything else this week? if not, see you next week. see you all next week or on #parrot % jhorwitz has left #parrotsketch % jisom has left jisom!~jisom@74-134-230-123.dhcp.insightbb.com % Coke has joined #parrotsketch % Andy has left #parrotsketch % Coke has left #parrotsketch % PerlJam has left PerlJam!duff@feather.perl6.nl % leo has left leo!lt@feather.perl6.nl % pmichaud has left pmichaud!pmichaud@feather.perl6.nl % tewk has left tewk!~tewk@72.8.94.63 % tewk has joined #parrotsketch % contingencyplan has joined #parrotsketch