Camelia, the Perl 6 bug

IRC log for #parrot, 2009-02-11

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:08 AndyA joined #parrot
00:09 * Whiteknight can't wait to be done with this stupid branch
00:18 Coke-really-afk chromatic: I cannot reproduce it right now because fperrard broke the PGE build on feather, so I can't do anything with valgrind.
00:19 Coke msg chromatic I cannot reproduce it right now because fperrard broke the PGE build on feather, so I can't do anything with valgrind.
00:19 purl Message for chromatic stored.
00:20 chromatic thanks
00:26 Coke ah, hi.
00:26 Coke sorry.
00:45 dalek parrot: r36563 | whiteknight++ | branches/vtable_morph_change:
00:45 dalek parrot: [vtable_morph_change] update to trunk r36562. Fixes all errors I had. Preparing to merge back to trunk
00:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36563/
00:55 dalek parrot: r36564 | chromatic++ | trunk:
00:55 dalek parrot: [PMC] Removed a check in NameSpace PMC which prevented the addition of Subs to
00:55 dalek parrot: a namespace if they were declared in PIR with :anon, even when inserting them
00:55 dalek parrot: with a name directly later with set_global.  See TT #56.  Now you can insert
00:55 dalek parrot: them in a namespace later.
00:55 Limbic_Region joined #parrot
00:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36564/
01:11 dalek parrot: r36565 | cotto++ | trunk/t/benchmark/benchmarks.t:
01:12 dalek parrot: [gc] redo clobbered DOD->GC name change
01:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36565/
01:13 dalek parrot: r36566 | cotto++ | trunk:
01:13 dalek parrot: [gc] rename Parrot_shared_DOD_(un)?block to Parrot_shared_gc_(un)?block
01:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36566/
01:16 Whiteknight stupid piece of shit SVN won't let me merge my branch into trunk
01:16 chromatic It's haunted.
01:17 kid51 Why not? Conflicts?
01:17 * kid51 has to give a talk about SVN branching and merging at $job tomorrow.
01:17 Whiteknight svn: working copy path t/src/embed.t does not exist in the repository
01:17 kid51 What was your merge command?
01:17 Whiteknight svn merge -r36396:HEAD --force https://svn.parrot.org/parrot​/branches/vtable_morph_change
01:18 kid51 I'm not familiar with that syntax.
01:18 Whiteknight what syntax should I use? I'm a relative SVN newbie
01:19 Whiteknight of course, it's always worked for me in the past
01:19 Whiteknight and in either case, t/src/embed.t does exist everywhere that I look for it
01:19 kid51 This is 'svn merge' variant #3 in 'svn merge --help' -- correct?
01:20 Whiteknight I guess
01:20 chromatic You probably need to merge from trunk again.
01:20 Whiteknight craptastic
01:20 chromatic We commit too much.
01:20 cotto I'll hold off any commits until you've got the merge, if that helps,
01:21 cotto s/,$/./
01:21 Infinoid Whiteknight: t/src/embed.t is renamed from t/src/compiler.t, if it helps
01:21 * kid51 has never used the --force option to svn merge
01:22 cotto the force is not with kid51
01:23 Whiteknight I only tried --force because it wasnt working otherwise
01:23 kid51 cotto:  Too true
01:23 dalek parrot: r36567 | whiteknight++ | branches/vtable_morph_change:
01:23 dalek parrot: [vtable_morph_change] another update
01:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36567/
01:24 kid51 Whiteknight:  do you want we to do a 'svn co' of branch and try to merge?
01:24 Whiteknight no, it's personal for me now
01:24 * Whiteknight WANTS BOOD
01:24 Whiteknight or blood
01:25 kid51 In that case, kid51 will start making dinner!
01:25 Whiteknight urg, same error
01:25 chromatic Did t/src/embed.t get renamed?
01:25 chromatic Or do you have local changes?
01:25 Whiteknight apparently it did
01:25 Infinoid usually with svn merges, I eventually just give up, get a clean export and rsync that into a fresh trunk checkout
01:26 Whiteknight yeah, i'm doing a clean checkout now
01:26 kid51 Coke:  Re https://trac.parrot.org/parrot/ticket/310 :  didn't we have an RT about that once upon a time?
01:26 Infinoid it's especially ridiculous because you already *did* the merge (r36563)
01:29 Whiteknight same error on a clean checkout. I give up for tonight
01:29 Whiteknight if anybody else has stronger SVN-foo then me, you're welcome to give it a chance
01:29 Infinoid will do.
01:30 Whiteknight t/src/embed.t exists in both repositories
01:31 dalek parrot: r36568 | cotto++ | trunk/include/parrot/thread.h:
01:31 dalek parrot: [gc] apparently, capitalization matters in function names
01:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36568/
01:31 Whiteknight so I don't know what it's saying doesn't exist where
01:31 Infinoid from svn's perspective, it was renamed *twice*, so its having trouble finding the base to merge from
01:31 Infinoid it's just stupid.
01:31 Infinoid I won't even bother with "svn merge", one rsync coming up.  (don't worry, I won't clobber more recent trunk changes)
01:32 Whiteknight okay, it makes me feel better that it's not some easy solution
01:33 Infinoid feel free to submit bug reports in their tracker, of course :)
01:35 kid51 More likely:  When I was writing tests for the config steps, I probably asked why one would want to manually specify PMCs.
01:36 kid51 And I probably went to some length to write a test that demonstrates that one can, indeed, specify individual PMCs to configure with via that option.
01:40 Fayland joined #parrot
01:44 kid51 Ah:  here's what I was thinking of:  first post in http://rt.perl.org/rt3/Tic​ket/Display.html?id=43172
01:44 Infinoid Whiteknight: was r36567 a pure merge, or were there any local changes?
01:44 dalek parrot: r36569 | Infinoid++ | trunk:
01:44 dalek parrot: Merge vtable_morph_change branch changes back into trunk.  Whiteknight++, svn--, rsync++.
01:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36569/
01:49 Infinoid Looks like I reverted some stuff by accident.  One moment.
01:53 dalek parrot: r36570 | Infinoid++ | trunk:
01:54 dalek parrot: Revert "Merge vtable_morph_change branch changes back into trunk."
01:54 dalek parrot: r36563 is not a valid merge point, it doesn't contain all the changes to trunk.
01:54 dalek parrot: I'll redo the merge, this time the hard way.
01:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36570/
01:58 Whiteknight Thanks Infinoid++
01:59 Whiteknight I'm going to bed now, too angry at computers to do any more coding
01:59 Infinoid Gives me an excuse to abuse git-svn :)
01:59 Infinoid good night
02:06 Infinoid svn.parrot.org seems much faster than svn.perl.org
02:07 * Infinoid just did 9 branch exports in 2 minutes flat
02:15 bacek joined #parrot
02:43 kid51 Infinoid: 'branch exports':  Is that git-speak?
02:49 Infinoid no, that's "svn export"
03:03 Infinoid msg whiteknight Was https://trac.parrot.org/parrot/changeset/3​6517/branches/vtable_morph_change#file187 intentional?  It snuck into an otherwise clean merge commit.
03:03 purl Message for whiteknight stored.
03:03 shorten Infinoid's url is at http://xrl.us/beftdq
03:19 Infinoid cherrypicked merge successful. \o/  now to test it
03:22 tetragon joined #parrot
03:26 Util_away purl, seen sahadev?
03:26 purl sahadev was last seen on purl 3 years, 219 days, 11 hours, 13 minutes and 17 seconds ago, saying: <private message>  [Jul  7 16:12:49 2005]
03:36 janus joined #parrot
03:44 dalek parrot: r36572 | Infinoid++ | trunk/src/io/win32.c:
03:44 dalek parrot: [cage] Trim whitespace to pass c_parens.t.
03:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36572/
03:54 kid51 dalek:  Why haven't you posted 36573 yet?
03:54 Infinoid dalek has been having some trouble in the last couple of days.  It's on my list.
03:56 nopaste "Infinoid" at 75.28.75.73 pasted "Test failures in merged vtable_morph_change tree" (11 lines) at http://nopaste.snit.ch/15579
03:56 nopaste "Infinoid" at 75.28.75.73 pasted "BigInt segfault in merged vtable_morph_change tree (attempt to access "bi" ATTR through NULL data pointer)" (22 lines) at http://nopaste.snit.ch/15580
03:56 nopaste "Infinoid" at 75.28.75.73 pasted "Summary patch for vtable_morph_change branch merge. (Applies cleanly to r36572)" (946 lines) at http://nopaste.snit.ch/15581
03:56 Infinoid msg Whiteknight I didn't apply the merge results to trunk, as I got some bigint-related test failures.  See http://nopaste.snit.ch/15579 and http://nopaste.snit.ch/15580.  git pull git://squawk.glines.org/merg​e-branch-vtable_morph_change or apply http://nopaste.snit.ch/15581 to get the merge results.
03:56 purl Message for whiteknight stored.
03:56 Infinoid There, now on to dalek.
04:03 kid51 Infinoid:  thanks
04:03 * kid51 must sleep
04:03 purl $kid51->sleep(8 * 3600);
04:32 contingencyplan joined #parrot
04:37 ask joined #parrot
04:37 basic Infinoid: we've got another student working on it, i think he's making progress (email2trac).  I've got a really busy week and don't have much time to work on getting it working, it's still really close last i checked, some issue with permissions between postfix and apache.  We can test that in house though, so no need to send more test emails for now
04:37 Infinoid Ok, thanks for the update, hope your week goes well
04:49 tetragon joined #parrot
04:58 dalek joined #parrot
04:58 Infinoid that should fix the partcl parser, and hopefully make the parrot parser no longer skip any revisions.
04:58 dalek partcl: r326 | wcoleda++ | trunk/src/ (4 files):
04:58 dalek partcl: Track rename of string_length
04:58 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=326
04:59 dalek allison@perl.org | Debian/Ubuntu chroot Environment Setup:
04:59 dalek link: http://www.perlfoundation.org/parrot/index.​cgi?debian_ubuntu_chroot_environment_setup
04:59 shorten dalek's url is at http://xrl.us/beesjm
04:59 Infinoid uh, that wasn't a new partcl rev, dalek
05:16 jimmy joined #parrot
05:20 jimmy left #parrot
06:05 Tene joined #parrot
06:08 iblechbot joined #parrot
06:13 mikehh joined #parrot
06:43 rurban_ joined #parrot
07:04 Andy joined #parrot
07:14 uniejo joined #parrot
08:21 iblechbot joined #parrot
08:48 bacek joined #parrot
09:09 masak joined #parrot
09:14 dalek parrot: r36574 | rurban++ | trunk/t:
09:14 dalek parrot: [t] Fix the last mingw smoke errors. TT#313
09:14 dalek parrot: by accepting the print -0 => 0 quirks for now.
09:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36574/
09:15 alvar joined #parrot
09:28 riffraff joined #parrot
09:38 bacek joined #parrot
09:41 dalek parrot: r36575 | chromatic++ | trunk/t:
09:41 dalek parrot: [t] Marked -0.0 tests as TODO instead of failing on MSWin32 and OpenBSD, per
09:41 dalek parrot: comments on TT #313.  This reverts and supersedes r36574.
09:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36575/
10:13 AndyA joined #parrot
10:33 dalek rakudo: 7b4118d | jnthn++ | Configure.pl:
10:33 dalek rakudo: [config] Configure needs to translate forward slashes in makefile to backwards ones for Win32, as Parrot's Configure did. Otherwise the build silently misses a bunch of important bits!
10:33 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​b4118d0c0023862bd88e9c578cfbbe9d24c580e
10:33 shorten dalek's url is at http://xrl.us/beft37
10:48 mikehh perl Configure --optimize --test is failing tests after configure as at r36575
10:50 mikehh specifically t/tools/pmc2cutils/00-qualify Failed test:  5
10:50 mikehh t/tools/pmc2cutils/04-dump_pmc  Failed test:  63
10:51 mikehh t/tools/ops2pm/00-qualify Failed tests:  8-9
10:55 mikehh and prove fails on these tests after the build - make world
11:00 mikehh running make test now
11:04 mikehh ok make test passes
11:06 kid51 joined #parrot
11:37 dalek rakudo: d668ca9 | jnthn++ | src/classes/ClassHOW.pir:
11:37 dalek rakudo: Fixes to make sure dispatches on proto-objects work correctly; resolves RT#62894.
11:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​668ca982f17170b2301c7da37475c98b8b1cbcf
11:37 shorten dalek's url is at http://xrl.us/beft6u
11:42 dalek parrot: r36576 | fperrad++ | trunk/languages/pipp/config/makefiles/root.in:
11:42 dalek parrot: [Pipp] add a target 'codetest'
11:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36576/
11:44 dalek parrot: r36577 | fperrad++ | trunk/languages/pipp:
11:44 dalek parrot: [Pipp] fix some coding standards
11:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36577/
11:47 Gerd joined #parrot
11:52 dalek rakudo: 59024e0 | jnthn++ | src/classes/Object.pir:
11:52 dalek rakudo: Fix .clone to deref ObjectRefs properly by calling !DEREF, which follows chains. Resolves RT#62828.
11:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​9024e09809f3c671d2dc08d0dfc5f3c7c5db7d4
11:53 shorten dalek's url is at http://xrl.us/beft7a
12:11 dalek parrot: r36578 | jkeenan++ | branches/update_pod/t/doc/pod.t:
12:12 dalek parrot: In the middle of modifications.  Not stable.
12:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36578/
12:31 rg1 joined #parrot
12:57 dalek parrot: r36579 | rurban++ | trunk/t:
12:57 dalek parrot: TT #313 win32 (mingw + msvc)
12:57 dalek parrot: - split tests into todo and working
12:57 dalek parrot: - fix complex todo error introduced by r36575
12:57 dalek parrot: - clarify "inf is not platform-independent" for win32 msvc only, todo added
12:57 dalek parrot: All win32 arithmetic tests should pass now
12:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36579/
13:01 dalek rakudo: 1beabec | jnthn++ | src/ (3 files):
13:01 dalek rakudo: We need to call .clone() rather than just using Parrot's clone vtable method fairly generally, I expect. This does that in a couple of places, which in turn resolves RT#63002 and gets an integration test passing.
13:02 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​beabec188ca2effe3770c96faa0f93d71643f04
13:02 shorten dalek's url is at http://xrl.us/befubr
13:05 Whiteknight joined #parrot
13:10 iblechbot joined #parrot
13:16 Infinoid Oh spam, how I love you so.  When you order a new internet connection, you can always tell when it's gone live because you start getting SMTP connections.
13:16 Infinoid It's like the cosmic internet background radiation.
13:19 Whiteknight Infinoid, how did that branch merge go last night?
13:19 * Infinoid thinks Whiteknight just got ambushed with purl messages
13:19 Whiteknight yeah, I'm going through them now
13:19 Infinoid :)
13:20 Whiteknight so....what happened?
13:21 Infinoid I'm sitting on the patches here hoping we can resolve the bigint failures first
13:21 Whiteknight stupid bigint failures
13:22 Whiteknight I'll have to take a look at them tonight unfortunately
13:24 Infinoid I've got a little time before work today, so I'm hoping to make some progress soon
13:24 Whiteknight this whole thing is such a damn mess
13:24 Infinoid Also, I've tweaked dalek again.  Please yell at me if you notice any more commits being dropped
13:25 Whiteknight okay, will do
13:27 Whiteknight I must have missed that one commit during one of the merges
13:27 Whiteknight stupid merges
13:28 Infinoid Now that I've got it in git, it'll be easier to track trunk
13:29 Whiteknight I guess I really need to get git now. This isn't the first problem I've had with sloppy SVN merging behavior, and certainly won't be the last
13:29 Whiteknight not with the rate that I create branches
13:29 szbalint svn--
13:30 Infinoid well, git doesn't always help much directly with svn branches, but it is damned nice for cleaning up the result
13:53 Coke (missing file t/src/embed.t) be very careful when doing svn merges on renamed files, or you can easily lose changes.
13:54 Coke (rename file in branch a. edit file in branch b. merge file from a to b. commit; lose changes you made in b)
13:55 Whiteknight yeah, found that out the hard way
13:56 Coke Infinoid: what shoudl fix partcl's what?
13:57 tetragon joined #parrot
14:02 gryphon joined #parrot
14:02 Infinoid Coke: dalek's partcl rss parser had a problem when the commit covered multiple files.  e.g. http://irclog.perlgeek.de/​parrot/2009-02-09#i_895579
14:02 Infinoid I fixed that, hopefully.
14:02 Infinoid googlecode's formatting for those things is weird
14:06 dalek rakudo: fba805c | jnthn++ | src/parser/grammar.pg:
14:06 dalek rakudo: Add panic on malformed declaration, as seen in STD.pm (with note on our little difference against STD.pm). Also we accidentally parsed/passed a private method test; add something to mitigate that to keep the spectests clean.
14:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​ba805cd171fbde507c47aaf55db2d8a2ac0e5a4
14:06 shorten dalek's url is at http://xrl.us/befufa
14:07 pmichaud good morning
14:08 knewt joined #parrot
14:09 knewt before i start going looking, anyone know off the top of their head what the current state of documentation is like?
14:11 moritz knewt: whiteknight was looking for readers/reviewers
14:11 moritz and the status as always is "needs more work"
14:11 Whiteknight documentation in some places is pretty good
14:11 Whiteknight docs/book/ is in decent shape now. Some of the other miscellaneous docs are out of date though
14:12 alinbsp joined #parrot
14:12 jonathan morning pmichaud
14:14 pmichaud (clone)  I'm thinking that for language interop we need to bias towards the Parrot ops instead of the methods.
14:15 jonathan Hmm. True.
14:15 jonathan Didn't we decide that we would catch those and re-dispatch to the methods, though?
14:15 pmichaud yes.
14:15 pmichaud I think.
14:15 jonathan It's a tad tricky for clone...
14:15 jonathan But we can do that somehow I expect.
14:15 pmichaud that's what I tend to do for most vtable methods on Rakudo objects
14:15 jonathan We still need access to Object PMC's clone...
14:16 pmichaud anyway, we don't need to change/fix anything immediately
14:16 pmichaud that's just my general bias at the moment.
14:16 jonathan Sure. I think if we can get .clone() working right, then later on we should be able to work the re-dispatch into it.
14:16 pmichaud right
14:16 jonathan BTW, do you agree that in general we should favor calling .clone() within Rakudo over the Parrot op?
14:17 pmichaud depends on what you mean by "within Rakudo"
14:17 jonathan I've fixed a bug by doing that...since our clone understands that it needs to deref.
14:17 jonathan OK, in things like postfix:++ that does a clone.
14:17 pmichaud right, that's what I was referring to.  I'm thinking that in general we should favor the Parrot op
14:17 pmichaud for language interop reasons.
14:18 jonathan Well, if that will just re-dispatch to .clone() then we may as well, in the ops, just call .clone()
14:18 jonathan IMHO
14:18 pmichaud foreign objects won't redispatch to .clone, though.
14:18 jonathan Ah, true...
14:18 pmichaud foriegn objects might not have a .clone
14:19 jonathan Yes.
14:19 jonathan Grr.
14:19 pmichaud anyway, it's something we can worry about later
14:19 jonathan Sure.
14:19 jonathan Working first, then better interop. :-)
14:19 jonathan Can I point you at a copule of tickets?
14:19 pmichaud I just didn't want us to start doing a wholesale "change vtable to methods" switch throughout the codebase only to discover we need to switch them all back.
14:19 pmichaud sure.
14:19 jonathan http://rt.perl.org/rt3/Tic​ket/Display.html?id=58676
14:20 jonathan I think that this now dos the type-check it should.
14:20 jonathan However, Foo.new ~~ Foo dies (Foo.new("") ~~ Foo works though)
14:21 pmichaud I'll be having to re-do .new on Match/Grammar objects
14:21 pmichaud right now it's using PGE's .new, which was a long-time-ago guess as to how things would work
14:21 pmichaud (and PGE's .new requires an argument, I think)
14:22 jonathan OK
14:22 pmichaud I'm fine with closing #58676 -- the issue there has been resolved.
14:22 jonathan But since the ticket is saying it should do a type-check...right, that was my feeling.
14:22 jonathan Also, masak gave me a list of tickets that mattered most to him. Two were already fixed, I fixed the rest apart from one today.
14:22 jonathan Which is http://rt.perl.org/rt3/Tic​ket/Display.html?id=62704
14:23 jonathan I figured you'd have a good idea on what it should do, etc. :-)
14:23 pmichaud well, technically $/ _is_ returning a Match object.
14:23 pmichaud it's just not a Rakudo Match.
14:25 jonathan OK. I'll leave the ticket/responding etc with you. :-)
14:26 pmichaud yes, that's fine.  The spec isn't very clear on the relationship between Match objects and Grammars
14:27 Infinoid Whiteknight: Oh, I figured it out.  Your VTABLE_get_integer addition to class.pmc doesn't work for bigints, because get_integer() has special meaning for integer types.  When default.morph() tries to get the integer from the BigInt class object, it thinks you're trying to get the value of the bigint, but since the class object doesn't have an attr array, bam, segfault.
14:28 Infinoid (20 frames down the stack, the code in question was originally trying to upgrade an integer due to a modulus() call that involved some bigints.)
14:28 Coke rant: our pmc internals suck.
14:28 Coke modulus - ooh, i wonder if that's related to my occasional 2%0 errors.
14:28 Coke (in partcl)
14:28 gryphon joined #parrot
14:29 Coke I am wondering why we don't just use Hash for our attrs.
14:29 pmichaud Because that would be too much like Perl.
14:29 Infinoid We do, internally.
14:29 dalek rakudo: 1b7a3e3 | jnthn++ | src/parser/grammar.pg:
14:29 dalek rakudo: A few more panics on malformed code from STD.pm. Resolves RT#59828.
14:29 Infinoid Oh, the other attrs
14:29 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​b7a3e35c99006dc77e797405ce44cc71b532ca1
14:29 shorten dalek's url is at http://xrl.us/befug2
14:29 Coke the GET_ATTR stuff is hitting actual struct members, no?
14:30 Coke (which are auto-gened when the pmc is built?)
14:30 Infinoid Yeah, I was thinking of the prop hash, which is different
14:30 Coke pmichaud: perl, which works, and doesn't segfault quite so much? =-)
14:30 pmichaud Coke:  I don't agree with the reason; I just suspect that _is_ the reason.
14:31 Infinoid Coke: I kinda doubt the partcl is related... I'm debugging the vtable_morph_change branch, the code hasn't hit trunk yet
14:31 Infinoid err, the partcl issue you're seeing
14:33 Coke fair enough. I have a modulus related segfault that's been open for months, was just hoping.
14:33 * Coke is >this close< to just reverting fperrad's change that broke PGE on feather.
14:33 Infinoid Okay, I'm game.  Got a ticket and/or a backtrace?
14:34 pmichaud 10 characters apart?  That doesn't seem very close.  :-)
14:34 Coke Infinoid: https://trac.parrot.org/parrot/ticket/66
14:34 Coke pmichaud: yah, that's why I haven't done it yet. :P
14:35 Coke is the tcl one.
14:35 Coke the PGE one is:
14:35 Coke trac is also slow
14:35 purl okay, Coke.
14:35 Coke trac is also REALLY slow
14:35 purl okay, Coke.
14:36 Coke https://trac.parrot.org/parrot/ticket/261
14:36 Coke (for Infinoid, pge/feather segfault)
14:36 Infinoid Yeah, modulus bugs sound a lot less intimidating to me than PGE bugs do
14:36 pmichaud note that the failure to build PGE is _not_ a PGE bug.
14:37 Coke given that it's a segfault, it pretty much couldn't be.
14:37 Coke Infinoid: of those two bugs, I suspect the one that's stopping PGE is easier to fix.
14:37 Coke (because you don't need all of tcl)
14:37 Coke I was unable to whittle down #66 to a small test case.
14:37 pmichaud what was fperrad's change that broke PGE on feather?
14:38 Coke pmichaud: it's in the ticket. moment.
14:38 Whiteknight Infinoid: good catch. The morph vtable should only be taking Class PMCs, not just any random joe schmoe pmc
14:38 pmichaud oh, r36176
14:38 Coke "Looks like the segfault started happening in r36176."
14:38 Coke <       set P0["has_exec_protect"], "1"
14:39 Coke is probably the culprit (it's no longer present in the config after that change)
14:39 Infinoid Whiteknight: The caller is VTABLE_morph(interp, dest, SELF->vtable->pmc_class);  (bigint.pmc:1143)
14:39 jonathan pmichaud: Parsing/precedence question. Should these two be the same:
14:39 jonathan ok (my Num::Multiple $d = 10), "creating a new Num::Multiple";
14:39 Infinoid that should be a Class PMC, right?
14:39 jonathan ok my Num::Multiple $d = 10, "creating a new Num::Multiple";
14:39 pmichaud jonathan: yes, but Rakudo doesn't know how to do item assignment yet.
14:39 jonathan OK.
14:39 Whiteknight Infinoid: I believe it should be
14:39 pmichaud s/do/parse/
14:39 jonathan I thought so.
14:40 Whiteknight although for a built-in type like BigInt, it might not be
14:40 Infinoid Right, so that class object has overridden a vtable it shouldn't have
14:40 jonathan The test is actually testing someone else, rather than that, and will pass if it put in the parens.
14:40 jonathan *if I
14:40 Infinoid Whiteknight: Well, you know this stuff far better than I :)
14:40 pmichaud I'm fine with adding the parens to the test.  Reads better, also.
14:40 Whiteknight can you replace that line with pmc_reuse(interp, dest, SELF->vtable->base_type, 0);    ?
14:40 Infinoid will do, one moment
14:41 Whiteknight thanks Infinoid++
14:41 Whiteknight I'm wondering why I didn't see that failure myself on this machine
14:42 Infinoid Whiteknight: ok, that crashed in a different place
14:42 Whiteknight yay!
14:42 Whiteknight can you email me the patches you have and I can just play with it locally?
14:42 Whiteknight because apparently there is much more work to do
14:42 Infinoid in fact, it got a *lot* farther
14:43 Infinoid Can do.  Expect an Official-Looking Stgit Patch Series
14:45 rurban_ joined #parrot
14:50 * Coke ponders highlighting a ticket each week in TWIP
14:51 rg like perl's todo of the week?
14:51 rg i was wondering if they had any success with that
14:51 moritz they had some (limited) success
14:52 Infinoid Whiteknight: sent.
14:52 Infinoid bbl &
14:52 Whiteknight thanks!
14:55 dalek rakudo: cad0468 | jnthn++ | src/classes/Grammar.pir:
14:55 dalek rakudo: Implement .parsefile method on Grammar.
14:55 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​ad04688480404aa6af8e582318c413477b867b7
14:55 shorten dalek's url is at http://xrl.us/befujz
14:59 Coke rakudo folks: just moved 61744 into your queue.
15:02 pmichaud Coke:  Thanks.  I suspect it's just a build problem that has since been fixed.
15:05 Topic for #parrotis now Parrot 0.9.0 | http://parrot.org/ | 468 RTs remain
15:17 NotFound joined #parrot
15:17 NotFound hi
15:17 purl salut, NotFound.
15:21 dalek rakudo: 8b8095c | jnthn++ | src/classes/Grammar.pir:
15:21 dalek rakudo: Avoid an infinite exception handler loop by popping a handler before calling Rakudo's 'die'. Resolves RT#62700.
15:21 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​b8095cf5953071f91353a3978222c26043def88
15:21 shorten dalek's url is at http://xrl.us/befuno
15:23 dalek rakudo: 1a2f50c | jnthn++ | t/spectest.data:
15:24 dalek rakudo: Add S05-grammar/parse_and_parsefile.t to spectests.
15:24 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​a2f50c39d3e5fa5e9fd6ef5ed80e9690a408bd0
15:24 shorten dalek's url is at http://xrl.us/befunq
15:27 Whiteknight I like having all the rakudo commits coming through here. It's cool to see what other people are doing
15:27 iblechbot joined #parrot
15:28 * jonathan tries to decide if 8b8095c reveals a Parrot bug or not...
15:28 szabgab jonathan, pmichaud ping
15:28 pmichaud szabgab: pong (more)
15:28 szabgab hmm, why do I ping when you are here talking?
15:29 pmichaud szabgab: I received your email -- will write a reply soon
15:29 szabgab great
15:30 jonathan szabgab: Same here.]
15:30 pmichaud szabgab: my talk abstracts are http://www.perlworkshop.no/npw2009/talk/1741  and  http://www.perlworkshop.no/npw2009/talk/1742
15:30 szabgab just wanted to say that if you want to discuss it on chat that's great too, I am here
15:31 jonathan pmichaud: In 63154 did you mean to change RT ticket status to rejected?
15:31 pmichaud jonathan: is that the :lang(Perl6) ticket?
15:31 jonathan pmichaud: aye
15:31 jonathan szabgab: I will upload my slides from Bulgarian Perl Workshop soon.
15:31 pmichaud jonathan: no, I'm going to leave it open for now, so that I'll remember to do the PGE/HLL stuff.
15:31 jonathan Essentially though, one of them is basically a kinda Perl 6 tutorial.
15:32 jonathan Though more in the "run-through of lots of cool stuff" than the "hands on" sense. But it essentially goes from the basics through lots of stuff.
15:32 pmichaud I think having a one-day Perl 6 training course would be excellent.
15:32 szabgab those two of pmichaud don't seem to have much overlap with what I would teacg
15:33 szabgab maybe the the tutorials of jonathan
15:33 pmichaud and no, my talks would not overlap.  Since jonathan was already doing "cool things with Perl 6" I didn't submit that
15:33 pmichaud jonathan: how long is your tutorial talk for NPW?
15:33 jonathan Checking...
15:33 szabgab I am not sure I would (or even can) do cool things with Perl 6
15:33 szabgab just simple tasks
15:34 jonathan It's different lengths in various places I'm giving it!
15:34 jonathan Duration: 90 minutes
15:34 purl i think 90 minutes is a long time
15:34 pmichaud anyway, I think there's room for both a one day tutorial and a shorter 90-minute talk
15:34 jonathan szabgab: My talk is not hands on at all.
15:34 pmichaud but yes, there'd be some overlap.
15:34 pmichaud jonathan: I'm eager to see your talk slides, btw.
15:35 jonathan I'm not even trying to give people time to try stuff - I just want to cover too much ground etc.
15:35 szabgab yeah I am quite sure, on the other hand I have more material than what I need for one day
15:35 szabgab or I'll have more by that time
15:35 pmichaud my frozen perl slides are    http://www.pmichaud.com/2009/pres/fp-perl6
15:35 szabgab so I can skip stuff jonathan already covers
15:35 jonathan szabgab: I expect we'd overlap a lot, but the audience may be different.
15:35 jonathan People who want to sit down and play with Perl 6 and be able to have time to try lots of stuff during the tutorial, would be better served by what you're doing.
15:36 jonathan Mine is more, "here's lots of the cool stuff that you can do today in Rakduo"
15:36 pmichaud yes, that's what mine was.
15:36 pmichaud I did things with hyperoperators and reduction operators and the like.
15:36 pmichaud oh, and hash sorting/output :-)
15:36 jonathan But I do go through basic syntax-y stuff too.
15:37 jonathan Basically so people can follow what comes later.
15:37 jonathan I'll get the slides off my laptop and uploaded later on today...
15:37 szabgab so I think what I can do is really give them lots of hands-on time with short explanations
15:37 pmichaud oh, would this tutorial be during the hackathon?
15:37 szabgab yes, it would be one of the days
15:38 pmichaud because one of the purposes of my talk is to get people up-to-speed on hacking on Rakudo itself
15:38 pmichaud (that's also why it's 90 mins :-)
15:38 jonathan If szabgab's thing is more exploratory then it'd perhaps get people to the hackathon to learn and play with Perl 6 more, who wouldn't come if it was just being sold as a "hacking on the guts" event, perhaps.
15:39 pmichaud it would be better if a Perl 6 tutorial occurred on the first day of the hackathon, then, since by that time I expect we'll be writing settings (prelude) in P6
15:39 szabgab yeah so I thought to do it on the first day so they can go a lot deeper in Perl 6 and then let them out to the hackathon for the 2 other days
15:39 Coke for the cool stuff talk, would be nice if the abstract said "and here's how you can have an up to date copy of perl6 on your laptop while you're sitting in here watching me type."
15:39 jonathan Coke: I did try this before, but people found it was more a distraction, in a fast-paced talk like the one I was giving.
15:40 szabgab I'll cover that in the hands-on
15:40 jonathan Right.
15:40 szabgab I might even hand out virtual box images ready made with everything
15:40 jonathan Nice!
15:41 pmichaud speaking of "have an up-to-date copy" -- anyone have any more thoughts about our recommended "get a copy of parrot" procedure should be for Rakudo?
15:41 Coke (virtual box images) that's a todo for jhorwitz at some point.
15:41 Coke pmichaud: fix parrot so that you can build rakudo from an installed parrot.
15:42 pmichaud Coke: I have my doubts that this will happen in a timely manner.
15:42 szabgab I can prepare such virtual box right now
15:42 szabgab in fact I'll need those next week already
15:42 particle1 szabgab: https://trac.parrot.org/parro​t/wiki/ParrotVirtualAppliance
15:42 Coke barring that, either doing it as a subdir of parrot or having parrot as a subdir of rakudo is fine.
15:42 Coke (though I would just pick one.)
15:43 pmichaud Coke: yes, but I'm thinking more of "how does one get parrot", not "where does it go"
15:43 szabgab they won't even need to know that as their already configured IDE will run their code :-)
15:44 Coke pmichaud: provide a make target that does an svn checkout of the version you want, along with a diagnostic output if someone doesn't have the svn command line (like for tortoise)
15:44 szabgab let me see how much of that virtual box I can prepare till GPW
15:44 pmichaud Coke: but in general I don't have a Makefile until _after_ we have a built Parrot
15:44 particle aargh. -0 changes to fix again.
15:44 jonathan -O ?
15:44 purl well, -O is the logging info
15:45 jonathan Oh, -0.
15:45 purl -0
15:45 pmichaud szabgab: if you could write up a procedure (or script) that describes how to create the virtual box, we could possibly do virtual box versions as part of Rakudo releases.
15:45 Coke pmichaud: then make it part of your Config process?
15:45 Coke "I see you don't have parrot... grabbing a copy..."
15:45 szabgab pmichaud, I'll do that as much as I can
15:46 pmichaud maybe it should be  --grab-parrot   option to Configure
15:46 Coke if parrot's not in the expected location, die and suggest that option?
15:46 pmichaud yeah, that works.
15:47 Coke if it is in the expected place, perhaps optionally check that 'svn info' is what you expect.
15:47 Coke (I'd just make that a warning, though.)
15:47 pmichaud I'll probably check the 'revision' value of parrot_config
15:48 Coke as long as you don't mind building parrot before checking the version is right, that works.
15:48 pmichaud we have to build parrot before we can complete Configure, yes.
15:48 pmichaud but yes, we could do the check before building parrot.
15:49 Coke can always do the easy parrot_config check now and make it check earlier if folks complain.
15:51 pmichaud jonathan:  is Configure.pl working now for you on Win?
15:51 pmichaud jonathan: i.e., can I chop out the 'reconfigure.pl' commented-out stuff?
15:51 jonathan pmichaud: Yes.
15:51 jonathan And yes.
15:51 pmichaud excellent.
15:52 jonathan Took a couple of small patches.
15:52 jonathan rakudo: our $x = 42; eval('our $x; say $x;')
15:52 polyglotbot OUTPUT[42␤]
15:55 Coke rakudo: our $x = 42; eval('say $x')
15:55 polyglotbot RESULT[undef]
15:55 Tene joined #parrot
15:55 jonathan rakudo: module Foo { our $x = 42; eval('our $x; say $x;') }
15:55 polyglotbot OUTPUT[Use of uninitialized value␤␤Null PMC access in set_pmc_keyed()␤current instr.: 'eval' pc 17000 (src/builtins/control.pir:338)␤called from Sub 'parrot;Foo;_block20' pc 129 (EVAL_20:59)␤called from Sub 'parrot;PCT;HLLCompiler;evalpmc' pc 888 (src/PCT/HLLCompiler.pir:494)␤called from Sub
15:55 polyglotbot ..'parrot;PCT;HLLCompiler;compile' pc 428 (src/PCT/HLLCo...
15:55 Coke rakudo: our $x = 42; eval('our $x = 3.14'); say $x
15:55 polyglotbot OUTPUT[3.14␤]
16:01 pmichaud wow, $800 round trip airfare to Oslo.
16:01 pmichaud I think I should probably book now.  :-)
16:03 jonathan Wow!
16:04 jonathan That's almost cheaper than a beer in Oslo. ;-)
16:04 Whiteknight rakudo: say  (1, 2, 3, 4, 5, 6) >>+>> (10, 20);
16:04 polyglotbot OUTPUT[112223242526␤]
16:04 pmichaud I can't imagine that the fares will go much lower than that.
16:05 Whiteknight so a hyper operator on the sharp side will extend the last element in the array outward?
16:05 Whiteknight rakudo: say  (1, 2, 3, 4, 5, 6) <<+<< (10, 20);
16:05 polyglotbot OUTPUT[Non-dwimmy hyperoperator cannot be used on arrays of different sizes or dimensions.␤current instr.: 'die' pc 16844 (src/builtins/control.pir:204)␤called from Sub '!HYPEROP' pc 15991 (src/builtins/assign.pir:373)␤called from Sub '_block14' pc 137 (EVAL_15:56)␤called from Sub '!UNIT_START' pc
16:05 polyglotbot ..18229 (src/builtins/guts.pir:321)␤called from Su...
16:06 * Coke wonders if polyglotbot would look nicer if it actually rendered [NL] as a newline.
16:06 jonathan Whiteknight: Yes. We also have a ticket for that last bug there. :-)
16:06 Coke (perhaps only if there was more than one in the send)
16:07 pmichaud it's kind of nice that    .say for 1..20  doesn't produce 20 lines of flood, though.
16:07 pmichaud rakudo:   .say for 1..10
16:07 polyglotbot OUTPUT[1␤2␤3␤4␤5␤6␤7␤8␤9␤10␤]
16:11 bkuhn joined #parrot
16:14 particle rurban: ping
16:14 particle i may need to create a new vm and install msvc6.
16:16 dalek rakudo: 45cf376 | jnthn++ | src/builtins/op.pir:
16:17 dalek rakudo: ++ and -- in both their prefix and postfix forms now use infix:<=>, which means they do read-only checking properly. This corrects RT#60380, but does cause some failures in for.t since <-> is not implemented, but accidentally worked before; will fix that in my next commit.
16:17 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​5cf3768ac4fa4119b55848c3236d324385ce3a1
16:17 shorten dalek's url is at http://xrl.us/befurf
16:21 dalek rakudo: c66322e | pmichaud++ | src/builtins/match.pir:
16:21 dalek rakudo: Add 'make' function (partial RT #63152, chrisdolan++)
16:21 dalek rakudo: Patch courtesy Chris Dolan <chris  at chrisdolan.net>
16:22 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​66322ec857f23a18f37f0cc64c52b0498300a47
16:22 shorten dalek's url is at http://xrl.us/befuru
16:25 davidfetter joined #parrot
16:25 rurban particle: yes
16:27 kj joined #parrot
16:28 pmichaud oh, the hackathon went to three days?
16:28 pmichaud I thought it was only two.
16:28 jonathan Me too
16:29 pmichaud oh well, I'm missing the third day now.
16:29 pmichaud since I just booked my flight to return on the 20th.
16:29 jonathan Ah.
16:29 jonathan I thought it was only 2, but didn't book a flight yet...
16:31 pmichaud 2 days of hackathon is probably all I can handle anyway.  :-P
16:31 jonathan Exhaustion is good, no? ;-)
16:31 szabgab sjn, you should send email to everyone that the hackathon is 3 days long!
16:35 particle rurban: seems you've marked todo some passing tests with msvc. i have a feeling it's msvc6-only that they should be skipped on
16:35 particle i'm working on a patch, but would appreciate a sanity check
16:36 particle rurban: can you tell me how t/op/arithmetics.t failed for Inf?
16:44 rurban https://trac.parrot.org/parrot/changeset/36579/ ? msvc6 perl Configure.pl && nmake test
16:46 rurban But it's enterily msvcrt.dll specific (the shared libc on windows)
16:46 nopaste "particle" at 76.121.106.245 pasted "rurban: arith patch for msvc6 testing" (78 lines) at http://nopaste.snit.ch/15582
16:47 rurban You think it's the compiler version, not msvcrt? will check
16:47 particle yes, those were todo-passes here
16:48 rurban I saw your change enabling the failing -0 in r36173
16:48 rurban I'll check both, the compiler version and the msvcrt version. If we have to workaround the print -0 we have to get at the msvcrt version on Configure anyway.
16:48 particle yes, because it didn't fail :)
16:49 particle yeah, right.
16:49 particle thank you.
16:49 dalek rakudo: bb2cdb7 | jnthn++ | src/ (2 files):
16:49 rurban but you had a newer msvc or msvcrt
16:49 particle i'll review the shared blib patch
16:49 dalek rakudo: Implement <-> (lambda that makes things rw), which gets S04-statements/for.t passing again.
16:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​b2cdb7a37236d6e8b8d5168812cf6d8d42a4d05
16:49 shorten dalek's url is at http://xrl.us/befuvd
16:49 rurban I have to buy some food for 20 mins
16:49 particle yes, i'm sure i do, running vista x64 and msvc2008
16:49 particle ~~
16:50 pmichaud jonathan: does the <-> affect only those parameters that don't already have an 'is' decl?
16:51 Infinoid Whiteknight: I'm working through the bigint failures by applying the same fix to other places in bigint.pmc, it's going pretty easily.
16:51 Whiteknight that's good. It should be pretty smooth
16:51 Theory joined #parrot
16:51 rurban particle, I remember now: It canot be the msvc6 comnpiler because I get the very same results for mingw also
16:51 jonathan pmichaud: No, all...
16:51 jonathan Hmm.
16:52 particle ah, hrmm. msvcrt it is, then. that should be fun to fix :(
16:52 jonathan pmichaud: Though we don't have a way to differentiate the two.
16:52 jonathan (In the signature, we always pass along :readtype('readonly')
16:52 pmichaud how do you mean?
16:52 mikehh joined #parrot
16:52 Infinoid I'm starting to wonder if I should just do a search and replace all instances in this file, though.  That way I won't have to worry about incomplete test coverage
16:52 pmichaud anyway, that's why I hadn't implemented <-> yet.
16:52 jonathan OK
16:53 pmichaud we should at least add a (failing) test for that so we come back and fix it.
16:53 jonathan I only did it because for.t started failing. ;-)
16:53 jonathan (After I fixed ++ and --)
16:53 jonathan Yeah, let me see what other tests we have...
16:53 pmichaud right-- that's why I hadn't done that fix for ++/-- yes
16:53 pmichaud *yet
16:53 jonathan Heh, it's one big heap of avoidance. ;-)
16:54 pmichaud well, I didn't really like the approach of "make everything rw"
16:54 jonathan It's closer than "do nothing". :-)
16:54 pmichaud agreed.
16:55 pmichaud (phone)
16:55 jonathan hmmm...I figured we'd have some tests explicitly for pointy blocks somewhere...
16:55 jonathan Hmm, maybe not
16:56 Infinoid Whiteknight: Would fixing Parrot_default_morph() to use base_type be reasonable?  Or would it break other things?
16:57 Whiteknight maybe. If it's a Class, it should use the class type. Otherwise it could probably use the basetype
16:58 NotFound Calling 'abort' will be the most reasonable way X-)
16:58 Infinoid Yeah.  Because crashing gracefully is so much more important than *working* :)
16:59 NotFound Interesting concept of 'gracefully"
17:00 Infinoid if you're gonna segfault, you might as well do it on purpose
17:00 particle you're checking base_type rather than isa or can or does?
17:00 particle HCF
17:02 NotFound particle: checking what? isa Cloneable?
17:03 particle just making sure it's correct. base_type was historically used for things it shouldn't have been
17:03 NotFound isa Morphable?
17:04 NotFound What things do that? Some PMC?
17:05 particle it was in imcc and in pmcs, yes
17:05 particle much has been rewritten and improved, though. hopefully corrected, too :)
17:05 NotFound Then the correct way IMHO is to override morph in that PMCs to throw "Cannot morph" or something
17:05 Infinoid in this case, I'm using it to get the Class object for bigint and rational PMCs.
17:07 Infinoid ask Whiteknight why :)
17:07 NotFound Whiteknight: why?
17:07 NotFound I'm obedient X-)
17:07 kj nopaste?
17:07 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
17:07 purl well, nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others)
17:07 NotFound why?
17:08 nopaste "kjs" at 193.1.104.7 pasted "nmake realclean && perl Configure.pl && nmake: no good here." (31 lines) at http://nopaste.snit.ch/15583
17:08 NotFound purl: why is 42
17:09 kj I have a link error on windows, I think because there's spaces in the folder name.
17:09 NotFound Silly not
17:09 NotFound bo
17:09 NotFound kj: I think that this problem is already reported
17:09 kj NotFound: oki
17:09 kj just wanted to check here
17:10 NotFound And the answer is: autotools have problems too, we're not alone!
17:11 jonathan pmichaud: Got something that I think will fix it, as well as a test case...smoking.
17:16 rurban particle: we should really write a Configure check for the print -0.0 win32 issue
17:17 NotFound There is some reason for the several Parrot_str_not_equal(....) == 0 or they are just an artifact of search and replace?
17:17 rurban kj: sorry. double quoting introduced again
17:17 jonathan The latter, I believe.
17:18 Infinoid I'm getting negative zero failures on linux in trunk, now.
17:18 pmichaud jonathan: if you don't end up with an easy fix, I think I can get to it.  I'm thinking perhaps we shouldn't default readtype when no read trait is set.
17:19 pmichaud afk for a bit
17:19 bacek joined #parrot
17:20 nopaste "rurban" at 212.183.57.78 pasted "test msvc fix tt276-msvc-linking.patch" (157 lines) at http://nopaste.snit.ch/15584
17:20 jonathan pmichaud: That's what I've done, and it seems to work. Passed all S06...
17:21 Infinoid rurban: r36579 gives me failures in t/op/arithmetics.t on linux/x86-64, was this expected or should I provide more info?
17:21 Whiteknight the whole morph thing is a mess   <---- That's why
17:21 rurban nope, not expected
17:21 rurban Infinoid, can you nopaste?
17:22 nopaste "Infinoid" at 96.238.213.50 pasted "t/op/arithmetics.t output on x86-64 linux" (62 lines) at http://nopaste.snit.ch/15585
17:24 rurban whoa! attempt to access code outside of current code segment. that was not me!
17:24 Infinoid reverting it causes the test to pass
17:25 rurban the failing test 8 is my failure
17:25 Infinoid maybe the test was rewritten in a way to reveal some other issue, I dunno
17:25 rurban ok. so it�s mine. wait a sec
17:25 Infinoid I'm clueless about negative zero
17:25 dalek rakudo: 2e70f2d | jnthn++ | src/ (2 files):
17:25 dalek rakudo: Improve handling of <-> so any traits explicitly set in the signature are not overridden with rw.
17:25 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​e70f2dc7eb31ba2214ee9261dc64a0a64f797ea
17:25 shorten dalek's url is at http://xrl.us/befuy9
17:25 rurban It's a posix math thingy. We require to print -0.0 as -0
17:26 jonathan OK, I need to take a break...back later.
17:26 * NotFound thinks about developping a floating point format with negative NaN
17:26 Infinoid how could you tell the difference between that and positive NaN?
17:27 NotFound Infinoid: that's the beauty of that design
17:27 Infinoid you could use negative NaN the way some perl 5 code uses "0 but true"
17:28 NotFound Will look nice: a = NaN but negative :)
17:28 Infinoid "They're just like normal NaN!  Except they're EVIL."
17:28 NotFound Wait, NaN is already evil enough :D
17:29 Infinoid Well, this is the anti-NaN
17:29 Infinoid It looks just like normal NaN.  Except you spell it in reverse
17:29 NotFound SuperNaN, the number of steel
17:32 NotFound not ok 7 - negate -0.0 not ok 8 - negate a native number
17:32 pmichaud jonathan++  # excellent 'is rw' patch
17:33 rurban particle: see http://smolder.plusthree.com/app/pu​blic_projects/report_details/17922 for the same mingw error in the -0 test. so it's not compiler specific.
17:33 shorten rurban's url is at http://xrl.us/befuz6
17:34 rurban Infinoid: you are not alone, win32 reports the same error on smolder
17:36 davidfetter joined #parrot
17:40 mikehh I just did a svn up from r36575 to r36579
17:41 rurban particle: did you see my tt238-install-devel.patch  for you?
17:41 * particle is back
17:41 mikehh Query do I need to do anything re make or such as the only files affected are in t and languages/pipp
17:41 rurban just make
17:42 particle Infinoid, rurban: that failing test is missing some code, and an 'end' statement, so you fall off the code segment
17:42 rurban oops
17:42 particle my previously nopasted patch fixes that
17:42 rurban ah, I see!
17:45 rurban I'll write the configure check now to finalize this mess. What should the HAVE_PRINT_NEG_ZERO name be?
17:47 particle HAS_NEGATIVE_ZERO?
17:47 rurban okay
17:48 particle think that can fit in with an existing configure step?
17:48 dalek rakudo: d44d19c | pmichaud++ | src/parser/grammar.pg:
17:48 dalek rakudo: Add parsing of $/ as a param_var (RT #63152).
17:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​44d19c58e246e7bef99461afaa3953c3bb9e745
17:48 shorten dalek's url is at http://xrl.us/befu3h
17:51 Infinoid particle: somehow I think that needs a "CAN_" prefix
17:52 Infinoid CAN HAS NEGATIVE ZERO?
17:52 * moritz had the same idea, but managed to keep quiet ;-)
17:53 * Infinoid often fails at that.
17:53 davidfetter QUIET FAIL
17:53 rurban look at config_lib.pasm: there are just HAS_stuff definitions
17:54 particle you'll need to check LOLCONFIG.pasm
17:54 Infinoid Whiteknight: Ok, tests are passing and I think this is ready to merge.  Are you fiddling with the patch series I sent you, or can I commit?
17:55 rurban I'm more for lowercase, like has_socklen_t: has_neg_zero or has_neg_0
17:55 Whiteknight you can commit if you're comfortable with it
17:55 Whiteknight thanks Infinoid++
17:56 particle has_negative_zero is perfectly clear
17:57 particle and does match has_dynamic_linking etc
17:57 rurban and the .pm would be auto:neg_0
17:57 Infinoid merge complete in r36585.
17:58 dalek parrot: r36580 | Infinoid++ | trunk/src:
17:58 dalek parrot: Apply r36396 from vtable_morph_change branch.
17:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36580/
17:59 dalek parrot: r36581 | Infinoid++ | trunk/src:
17:59 dalek parrot: Fix some fallout from r36396, related to upgrading data types through morphing, bigint pmcs and rational dynpmcs.
17:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36581/
17:59 particle i'd prefer auto::neg_zero to not confuse people with o, O, and 0
17:59 dalek parrot: r36582 | Infinoid++ | trunk:
18:00 dalek parrot: Apply r36514 from vtable_morph_change branch.
18:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36582/
18:00 dalek parrot: r36583 | Infinoid++ | trunk/src/pmc/undef.pmc:
18:00 dalek parrot: Apply non-merge portion of r36517 from vtable_morph_change branch.
18:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36583/
18:01 dalek parrot: r36584 | Infinoid++ | trunk/src/pmc:
18:01 dalek parrot: Apply r36540 from vtable_morph_change branch.
18:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36584/
18:02 dalek parrot: r36585 | Infinoid++ | trunk/src/pmc:
18:02 dalek parrot: Apply r36562 from vtable_morph_change branch.
18:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36585/
18:03 moritz is that manually merging single commits from a branch?
18:04 Infinoid svn updating the branch against trunk screwed things up entirely, so I had to cherrypick it.  After that, I kept the patches separate in stgit, because it makes them easier for me to understand.
18:06 Infinoid I realize committing them separately is not the normal procedure, but I really *really* hate when I'm doing a bisect to find some issue and end up staring at some huge incomprehensible branch-merge commit
18:06 Infinoid if it bothers people, I can summarize in the future.
18:07 Whiteknight it's fine by me
18:07 Whiteknight I'm just happy to have the damn thing merged
18:07 Infinoid now we can move on to breaking bigger and better things :)
18:08 rg infinoid: usually you still have the separate commits in the branch, but i admit they're harder to find and probably even harder for bisect to figure out.
18:09 Infinoid rg: Yeah, it basically means you have to start bisecting all over
18:14 Phurl joined #parrot
18:14 Phurl hey all
18:15 Phurl i have started to branch the parror/pipp into http://code.google.com/p/rdfintrospector/sou​rce/browse/#svn/trunk/parrot/languages/pipp
18:15 shorten Phurl's url is at http://xrl.us/befu6g
18:15 Phurl so I can make changes
18:17 Phurl but is it just the xslt
18:18 Coke .
18:20 particle Phurl++
18:20 Phurl :)
18:20 NotFound Someone is planning to make something with ecmascript?
18:20 Coke last change to suggest a name more clever than "apl-parrot"
18:20 Infinoid A Parrot Language
18:21 Coke "invalid project name"
18:21 Phurl hey, how many of these parrot languages have an xml interface?
18:21 NotFound Coke: don't liked my sugggestion of some days ago?
18:21 Phurl is is possible to program parrot directly from xml?
18:21 Coke NotFound: resend?
18:21 purl resend is probably the thingy that handles incoming messages to the list.
18:21 NotFound Coke: apalot
18:22 Coke hurm. no. =-)
18:23 Phurl so my idea is quite simple
18:23 Phurl to have an xml interface to write parrot code
18:23 Phurl at the lowest level
18:23 Phurl basically an xml assembler
18:23 NotFound http://travelingluck.com/Asia/Philippi​nes/Ilocos+Norte/_1730411_Apalot.html
18:23 shorten NotFound's url is at http://xrl.us/befu78
18:24 Coke I think that's a hammer in search of a nail.
18:24 Phurl Coke: yes of course
18:24 Infinoid Phurl: ok, so you use xml instead of pir?
18:24 Whiteknight Coke, where you moving apl to? Squawk?
18:24 Phurl in a way
18:24 Coke but you could certainly do that.
18:24 NotFound Coke: seems that's a beautiful place
18:24 Phurl right now there is an xslt from phc to something
18:24 Coke Whiteknight: no, I'm creating a new repository for it. I don't like the idea of squawk. =-)
18:24 Whiteknight Coke: Well it doesn't like you either
18:25 Coke (it's not that hard to setup an individual project on googlecode)
18:25 * Coke proffers: "par apl egic".
18:25 Phurl It generates an XML representation of a PAST data structure.
18:25 Phurl according to the docs
18:25 Infinoid Coke: hah!
18:25 Phurl and the XML from the PAST is then transformed to perl or something
18:26 Phurl i just think it would be good to have an native standard xml for parrot
18:26 particle coke++
18:26 Infinoid APLeptic
18:26 Phurl we can talk about this wehn I have a better example
18:26 Coke Infinoid: parapleptic is a word too.
18:26 Infinoid ooo
18:26 particle P
18:26 NotFound Phurl: no need to be declared as standard to be done.
18:26 particle maybe that's what i'll call the parrot port of R
18:26 particle (which is an open-source version of S)
18:27 Infinoid someone else can have Q
18:27 NotFound And the we can add a Q&A
18:27 NotFound then
18:27 Whiteknight particle: you should call it ArrrrR, and the icon can be a picture of a pirate with a parrot on his shoulder
18:27 * Coke goes with paraplegic.
18:27 kj ArrrrR++
18:28 Infinoid Coke: it seems unlikely that anyone else would have taken it :)
18:28 NotFound apl plus enhanced professional edition
18:28 Infinoid APL2009
18:28 NotFound apl vista
18:29 particle pipp svn?
18:29 Coke http://code.google.com/p/paraplegic/
18:29 particle pipp repo?
18:29 particle hrmm, we need to move pipp out someday
18:29 Whiteknight aplsaus
18:29 particle i guess that's waiting to follow rakudo's lead
18:29 particle partcl?
18:29 purl rumour has it partcl is tcl on parrot or http://code.google.com/p/partcl or slow and a memory pig and pretty much not usable
18:31 Whiteknight haha, purl is pretty negative about partcl
18:31 particle november?
18:31 purl november is at http://www.november-wiki.org/ or http://use.perl.org/~masak/journal/37212 or http://github.com/viklund/november/
18:31 ask joined #parrot
18:32 Phurl NotFound: well lets take a look at this
18:32 particle perl6-examples?
18:32 Phurl http://code.google.com/p/rdfintrospecto​r/source/browse/trunk/parrot/languages/​pipp/src/phc/past_xml_to_past_nqp.xsl
18:32 shorten Phurl's url is at http://xrl.us/befu9d
18:32 Phurl this is the past xml standard
18:33 Phurl "It generates a PIR-script that creates
18:33 Phurl a PAST data structure and runs it with the help of a PCT::HLLCompiler."
18:33 Phurl i mean the transformation
18:33 Phurl so it would be nice to either :
18:33 Phurl 1. have a native parrot xslt language
18:33 Phurl 2. have the ability to write this past directly as a language input and not use xslt
18:33 Phurl just an idea i had today
18:34 Phurl plus you can see it is very primitive
18:34 Phurl the xslt is 50 lines
18:34 particle prophet?
18:34 purl well, prophet is a distributed property database or http://fsck.com/~jesse/talks/​2008/yapc.asia.08-prophet.pdf or http://syncwith.us
18:34 NotFound Phurl: looks like egypcic hyaerogliphs to me
18:35 Phurl haahh
18:38 * particle has set up an ubuntu vm with mod_parrot parrot perl6-examples pugs sd november partcl prophet rakudo repositories
18:41 Phurl http://code.google.com/p/rdfintrospector​/source/browse/trunk/mediawiki/trunk/pha​se3/includes/parser/Parser.php/past.out
18:41 shorten Phurl's url is at http://xrl.us/befva9
18:41 Phurl here is the past created atm
18:41 Phurl it is just perl
18:41 Phurl i am working on porting the mediawiki parser to parrot
18:41 Phurl so that we dont need to deal with this gawdauwfull php
18:42 Phurl so, i think that when parrot has a very optimized repreentation of the program
18:43 Phurl we should be able to emit c and then compile that again using a profile driven compiler for more optimization
18:43 particle parrot doesn't emit c
18:43 Phurl not yet
18:43 particle i don't know that it ever will
18:43 Phurl ok
18:43 Coke (partcl) most of those factoids came from me.
18:44 Phurl who is particle?
18:44 particle particle?
18:44 purl The most abundant particle in the universe is the moron. or spin 1/2, charge 2/3 or jerry gay or a boson. or a bozon. or a bogon or one bad mobo. or full of lies or mailto:jerry.gay@gmail.com or thinking that others are boring
18:44 Phurl are you a person or bot?
18:44 particle not a bot
18:44 Phurl good
18:45 * particle pets purl
18:45 * purl bites!
18:45 particle bots don't like me.
18:45 Infinoid I am not a bot, no matter how many perl scripts I may be running.
18:45 Phurl i just think that in the end, any jit or runtime could be optimized again with profile driven compilation
18:46 particle yes, when we finally have profiling tools
18:47 rurban Interesting, first write of has_negative_zero check works okay on all platforms. need a test now
18:47 Coke or a jit.
18:47 * Tene is a bot.
18:48 Coke tene, fix my partcl bugs. :P
18:48 particle sheena is a punk rocker
18:48 * Tene svn rm partcl
18:48 Phurl ok
18:48 particle that's a big hammer!
18:48 Phurl well lets just get first things first
18:49 * jonathan back from nomming and shopping
18:52 * Coke has a nagging suspicion jonathan has an RT ticket that is closable.
18:53 * jonathan has closed a double figure number of them today. ;-)
18:54 jonathan Maybe just not in the queue you're thinking of.
18:54 Coke yah, this was a parrot bug. ah well, it'll come to me.
18:55 nopaste "Infinoid" at 96.238.213.50 pasted "4 places in the bigint pmc and the rational dynpmc sources that are not properly tested (if tested they would have crashed during the morph vtable branch stuff)" (45 lines) at http://nopaste.snit.ch/15586
18:56 jonathan Coke: Got an ID?
18:56 jonathan Or you just want me to review those that were assigned to me?
18:56 Infinoid In the above nopaste, those changes were committed along with r36581, but I had to use grep to find them, because make test didn't hit them.
18:57 * particle steps away for yet another interview &
19:00 dalek parrot: r36586 | whiteknight++ | trunk/docs/book/ch03_pir_basics.pod:
19:00 dalek parrot: [Book] More detail about filehandle PMCs and their methods.
19:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36586/
19:01 Infinoid ooh, release in 6 days.
19:01 dalek parrot: r36587 | Infinoid++ | branches/vtable_morph_change:
19:01 dalek parrot: This branch was merged back into trunk; kill it.
19:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36587/
19:01 Whiteknight Infinoid++. I can't say that enough today
19:02 Whiteknight I would so much rather be writing code then fighting with revision control software
19:02 Infinoid Whiteknight: I don't mind, but in this case, I did it now only because I forgot earlier
19:04 Whiteknight this kind of stuff always makes me hesitant to create new branches
19:05 Infinoid I usually just branch locally.  It's part of my overarching strategy of pretending git-svn (and by extension, svn) don't really exist.
19:05 Whiteknight Well la de da mr super computer man
19:07 Coke jonathan: no, I don't have an id.
19:07 jonathan Coke: OK.
19:07 jonathan Will glance over my assigned tickets later on.
19:07 Coke but yes, please review any parrot ones you have assigned. =-)
19:07 Coke (even if only to give them up if you're not going to get back to them.)
19:14 dalek tracwiki: v50 | coke++ | WikiStart
19:14 dalek tracwiki: https://trac.parrot.org/parr​ot/wiki/WikiStart?version=50
19:14 dalek tracwiki: v1 | coke++ | SmolderTaskList
19:15 dalek tracwiki: https://trac.parrot.org/parrot/​wiki/SmolderTaskList?version=1
19:15 shorten dalek's url is at http://xrl.us/befvfd
19:19 rurban_ joined #parrot
19:20 Infinoid driving around today is like halfway between playing spy hunter and playing asteroids
19:23 rurban BTW: adougherty came with two more floattypes to support for cross-platform native_pbc. I found also one more. 0-6 for now. See https://trac.parrot.org/parrot/ticket/308
19:25 Infinoid Yeah.  Wouldn't it be nice if pbc had a standard type, so you only had to worry about converting to and from that, instead of worrying about converting from 5 other platform types to your own?
19:25 Coke ... isn't that whatever's in $N ?
19:26 rurban stringification might be needed
19:26 Infinoid That works for me.  Picking the highest precision type and using that works too
19:26 rurban but maybe stringification only as fallback when not on the same platform
19:26 rurban too keep the reader speed.
19:26 Infinoid Wouldn't that mean you have to store both the native type and the stringified one when you generate the .pbc file?
19:27 rurban yes
19:27 Infinoid ok.
19:27 rurban just an idea.
19:27 Infinoid It works
19:27 rurban For now I just print a "unsupported floatval conversion" error or such
19:27 pmichaud Coke:  I'd like a commitbit for APL.
19:28 Infinoid I'm not an expert in floating point stuff anyway, I would just prefer converting to/from a "standard" type rather than converting from *every* type
19:28 NotFound BTW, what if a pbc contains an 64 bit INTVAL that does not fit in 32 bits and we are converting to a 32 bit INTVAL platform?
19:30 Infinoid If any of the high bits were set, converting it to a bigint would seem nicer than hacking off the extra bits
19:30 Infinoid I don't know what's currently done.
19:30 NotFound Converting to a big int a thing assigned to an integer register is not a possibility.
19:31 dalek rakudo: 4367761 | jnthn++ | src/ (2 files):
19:31 dalek rakudo: If optional parameter not supplied, don't do type checks. Resolves RT#61528 and RT#63048.
19:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​3677616c0c21df5252ee269759c4a62bcada103
19:31 shorten dalek's url is at http://xrl.us/befvh4
19:31 dalek rakudo: 50a61ae | jnthn++ | src/parser/grammar.pg:
19:31 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
19:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​0a61ae399a3b1bded42d0711a8afef6354a08c3
19:31 shorten dalek's url is at http://xrl.us/befvh6
19:33 jonathan commit message fail
19:35 Coke NotFound++
19:35 rurban currently we fetch the 64bit in the right endian style, and pick it apart, to get our native IEEE 754 number
19:35 rurban In true libc-hacker style. Hard to support
19:35 chromatic joined #parrot
19:36 rurban see sr/packfile/pf_items.c
19:36 rurban well, 64bit not yet, but you get the idea.
19:37 NotFound 32 bit must ne enough for everyone X-)
19:38 Coke rurban: you might be a good person to look at:
19:38 Coke http://rt.perl.org/rt3/Tic​ket/Display.html?id=44317
19:40 rurban Ah, thanks. This maybe explain some weird alignment problems
19:40 rurban I steal it.
19:44 maettu joined #parrot
19:44 dalek parrot: r36588 | coke++ | trunk/DEPRECATED.pod:
19:45 dalek parrot: Add another notice so we can rip this out before 1.0
19:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36588/
19:47 rurban I also want to rename readbc and loadbc to pbc_read pbc_load, to be added to DEPRECATED.pod. Who decides this?
19:48 rurban https://trac.parrot.org/parrot/ticket/266
19:49 Coke consensus decision.
19:49 Coke not Parrot_pbc_* ?
19:50 Eevee joined #parrot
19:51 Coke rurban: you also might want 41893
19:51 Infinoid PDD13 means those are going to change at some point anyway
19:52 Infinoid Parrot_pbc_* +1
19:52 Coke pmichaud: ping.
19:52 Coke or jonathan: ping
19:52 jonathan Coke: pong
19:52 Coke (is http://rt.perl.org/rt3/Tic​ket/Display.html?id=43419 closable now?)
19:52 Coke (and the corresponding TT)
19:53 rurban yes, we can close RT#41893 soon.
19:53 dalek parrot: r36589 | allison++ | branches/kill_pccinvoke:
19:53 rurban But I'll test it with the release
19:53 dalek parrot: [pcc] Bringing the kill_pccinvoke branch up-to-date with trunk r36588.
19:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36589/
19:53 jonathan Coke: I'll let pmichaud confirm it, but given it now has a trac ticket, one would guess so...
19:54 rurban its the same as the FHS ticket I submitted. RT#56996
19:54 Coke if it's a duplicate, we can merge the tickets.
19:54 Coke jonathan: just because there's a TT doesn't mean the issue is resolved.
19:55 rurban not yet, it's a little bit different
19:55 jonathan Coke: OK, but if there's a TT tracking it instead, do we keep it in both ticket systems?
19:55 rurban and allison changed a bit lately so it became fragile. I really want to test it properly
19:55 Coke I'd rather just confirm it's closed and close it in both places. =-)
19:56 jonathan Coke: OK. Well, pmichaud can answer that more than I can since he filed it originally. :-)
19:56 rurban But now my big negative_zero changes cause other tests to fail. I'll nopaste.
20:00 nopaste "rurban" at 212.183.50.58 pasted "HAS_NEGATIVE_ZERO print fails with -0, why?" (28 lines) at http://nopaste.snit.ch/15587
20:00 rurban I'll disassemble this...
20:02 pmichaud Coke: checking RT #43419
20:02 dalek parrot: r36590 | whiteknight++ | trunk/src/multidispatch.c:
20:02 dalek parrot: [MMD] Tweak the tuple generation code to accept invocant adverbs, in anticipation of some Parrot_PCCINVOKE unifications
20:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36590/
20:02 pmichaud Let's close it.  I did re-run the test program and it appeared to work. (more)
20:02 pmichaud if I run into more issues, I'll file a new ticket with more details.
20:04 dalek parrot: r36591 | coke++ | trunk:
20:05 dalek parrot: Move bug report from RT here in preparation for operation LeaveTheNest
20:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36591/
20:06 dalek rakudo: b2e7ac9 | jnthn++ | src/parser/actions.pm:
20:06 dalek rakudo: If we use is also, we need to check the class we're trying to extend already exists.
20:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​2e7ac91ab01bc8bc874bf2f00a84c9c478c6b28
20:06 shorten dalek's url is at http://xrl.us/befvqw
20:07 Coke pmichaud: danke.
20:08 jonathan pmichaud: Think getting down to 250 tickets is within reach now. :-)
20:09 jonathan (Not today, but soonish.)
20:09 pmichaud jonathan: excellent.  I have a batch to attack also, as soon as I can get the build process back up to speed.
20:10 jonathan perl6: role A::B {}; A
20:10 polyglotbot OUTPUT[invoke() not implemented in class 'NameSpace'␤current instr.: '_block14' pc 59 (EVAL_19:38)␤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)␤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)␤called from Sub 'parrot;PCT;HLLCompiler;evalfiles'
20:10 polyglotbot ..pc 1275 (src/PCT/HLLCompiler.pir:688)␤called fr...
20:10 rurban Parrot_pbc_: Okay, now I only have to check how to properly deprecate a func (macro I know)
20:10 jonathan pmichaud: What should happen here?
20:11 dalek parrot: r36592 | fperrad++ | trunk/compilers/pirc:
20:11 pmichaud jonathan: I don't know -- I'm thinking we need a spec clarification.
20:11 jonathan Right.
20:11 dalek parrot: [pirc] svn ignore pirc.exe
20:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36592/
20:11 pmichaud however, it should be smart enough to recognize 'A' as a namespace instead of a listop.
20:12 pmichaud and thus treat it as a term
20:12 jonathan pmichaud: STD.pm recognizes it as an undefined name but that's a warning...
20:12 jonathan Aye.
20:12 jonathan Invoking it is wrong.
20:12 jonathan But that'd mean we probably need to register it or detect it in some way.
20:12 Coke rurban; open a ticket if one doesn't exist already. Add an entry to deprecated.pod pointing back to the ticket.
20:13 jonathan (But we don't want to treat it as a type name, so that won't fly.)
20:13 rurban The ticket is TT#266
20:13 * jonathan writes to p6l
20:14 rurban Didn't want to note the old name also somewhere?
20:14 ask joined #parrot
20:15 ask_ joined #parrot
20:15 * Coke hopes tt #316 is a duplicate.
20:15 jonathan pmichaud: Written.
20:15 Coke rurban: your note should mention the old one that is going away and the new one that is replacing it.
20:16 Coke For bonus points, we should add the new one NOW and make the old one just invoke the new one.
20:16 Coke that eases the upgrade pain slightly.
20:16 rurban #316 is mine. I'm just working on the fix.
20:16 Coke (presuming of course that there's consensus in the first place.)
20:17 NotFound rurban: take ownership, then
20:18 * jonathan yawns and ponders that perhaps that's enough bugs quashed for one day
20:19 rurban I'll fix the symptom now first.
20:22 NotFound I'm looking at TT #300 but don't see any clear path to work on it. It is easy to mark the exception handler as been in the process of catching, but don't know how to unset it. Any ideas?
20:22 NotFound s/been/being
20:22 dalek parrot: r36593 | rurban++ | trunk/t/op/arithmetics.t:
20:23 dalek parrot: [t] Fix the previous syntax error (forgot end) and the wrong test.
20:23 dalek parrot: Closes TT#316. More to be done in TT#313.
20:23 dalek parrot: Change print to say.
20:23 purl dalek: that doesn't look right
20:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36593/
20:23 dalek parrot: r36594 | whiteknight++ | trunk:
20:24 rurban p_u_r_l: what does not look right there?
20:24 dalek parrot: [DEPRECATED] Add note about deprecating .HLL_map so we can have it ripped out by 1.0
20:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36594/
20:25 Infinoid Change purl to broken.
20:25 purl Infinoid: that doesn't look right
20:25 Infinoid Funny, looks good to me.
20:26 rurban who knows this beast?
20:28 Infinoid purl, owner?
20:28 purl i think owner is Masque
20:28 rg notfound: i still think raising an exception should remove all handlers up to and including the called one from the handler stack
20:29 Infinoid rurban: t/op/arithmetics....ok
20:29 chromatic prove -l t/op/arithmetics.t
20:29 rg i've discussed this with tene some time ago, but i guess he never got around to doing anything.
20:29 chromatic Sorry, I mean prove -v t/op/arithmetics.t
20:29 NotFound rg: given that the handler is the continuation that does the handling, removing then before his usage is not easy
20:29 Tene rg: if you remove the exception handlers, how would they be added back when someone resumes that exception?
20:30 Tene We even use exceptions for warnings...
20:31 Tene Should a warning wipe out all exception handlers in place?
20:31 rg imho the continuation would have to know about that. my problem is i don't know the code, just what i think would be right.
20:31 rurban I just attached my big neg_0 patch to TT# 313. https://trac.parrot.org/parrot/attach​ment/ticket/313/tt313-add-neg_0.patch
20:31 shorten rurban's url is at http://xrl.us/befvw2
20:31 Tene rg: I've looked into it quite a bit, but I haven't been able to come up with a non-horrible solution.
20:32 NotFound rg: to know about what?
20:32 rg the continuation that is stored with the exception would need to know which exception handlers need to be restored
20:32 rg tene: do you know any other language that has resumable exceptions?
20:33 NotFound rg: the continuation is not stored with the exception, as far as I know
20:33 Tene NotFound: it is.
20:33 Tene exception['resume']
20:34 NotFound Do we talk about the ExceptionHandler continuation or about the resume continuation?
20:34 rg the resume continuation. is the handler implemented as a continuation aswell?
20:34 Tene rg: I have no idea how to construct a continuation that can do that.
20:35 Tene Maybe a special subclass of continuation, possibly...
20:35 NotFound Most languages don't have resumable exceptions because they want to avoid to care about all those things.
20:36 Tene We also use exceptions for loops.  Those EHs are called repeatedly without resuming, so the resume continuation can't be what does it.
20:36 NotFound The ExceptionHandler isa Continuation
20:37 Tene Unless we require every handler there to know about every other handler inside it and generate code to reconstruct it every time it catches something.
20:37 NotFound pmclass ExceptionHandler extends Continuation need_ext {
20:37 Tene Which is absurd.  We shouldn't require EHs to reconstruct other EHs just to not break.
20:38 rg i'm getting the impression we're using exceptions for too many things
20:38 Infinoid ETOOUSEFUL
20:39 Tene They're the generic mechanism for handling exceptional flow control.
20:39 jonathan http://use.perl.org/~Jonath​anWorthington/journal/38463 # rakudo day report
20:39 NotFound A possible hackish solution: store a pointer to the ExceptionHandler in the Exception, and mark it as finished when getting the 'resume' (assuming that is getted in order to invoke it)
20:39 Tene 'return' is a special case of exception
20:39 rg return, break, continue and a number of other things, i know :/
20:40 NotFound Maybe we must rename ExceptionHandler as TaskHandler, or something
20:40 Tene tasks are different
20:40 Tene erm.. nm
20:40 NotFound Because a lot of the things it does are not exceptional at all.
20:41 NotFound ThingHandler X-)
20:41 rg FlowHandler maybe?
20:41 Tene they're exceptions to normal program flow
20:42 Coke control flow exceptions
20:42 rurban hmm: mingw x == -0.0 uses fucompp. FPU code, looks okay to me.
20:43 Coke Doesn't need a rename, IMO.
20:43 dalek parrot: r36595 | allison++ | trunk:
20:43 dalek parrot: [pcc] Merging the kill_pccinvoke branch into trunk for r36508 to r36588. Simple
20:43 dalek parrot: file restructuring for greater maintenance sanity.
20:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36595/
20:43 NotFound I don't see his exceptionality, they are continuations like almost any other part or parrot flow control.
20:44 maettu left #parrot
20:44 Tene I'm still not sure exactly how rg is wanting things to work.
20:44 rurban my -0.0 error is earlier, not in print.
20:44 dalek parrot: r36596 | allison++ | branches/kill_pccinvoke:
20:45 Tene All of his proposals seems vague to me, and the interpretations I come up with seem to break many things.
20:45 dalek parrot: Removing calling conventions refactor branch from the repository
20:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36596/
20:45 Tene rg: can you create some example PIR with explanations of how you would want it to work?
20:45 Tene What you're needing to do?
20:45 rg still i believe any handler that is being skipped in the search for the handler of the current exception (be that flow control, user or internal exceptional condition) is not relevant to any exception thrown later on, so it can be removed from the search/stack. the only problem we're having is what to do with the exception's continuation
20:46 Tene if you remove it, what will put it back?
20:46 dalek parrot: r36597 | allison++ | branches/pcc4:
20:46 rg if we disregard the continuation: nothing ever.
20:46 dalek parrot: Creating branch for refactoring calling conventions, removing the old PCCINVOKE and streamlining the rest.
20:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36597/
20:48 Tene I really think that having an exception mutate its call stack is a bad idea.
20:48 Tene Still thinking, though.
20:49 rg i could try to find the time to come up with some examples, but it could be hard to do in pir.
20:50 NotFound Probably will make more sense to kill the handler stack entirely, not just until the current.
20:51 rg notfound: no, you don't want an exception inside a handler terminate your whole script ;)
20:51 NotFound rg: handler stacks are contextual, not for the whole script
20:51 rurban I see that ruby uses it own vsnprintf.c for this win32 -0.0 issue: http://redmine.ruby-lang.org/issues/show/6
20:52 rg oh so you meant the current context's stack. that may be ok.
20:53 NotFound But the problem is that this way will complicate the resume
20:54 Tene NotFound: resume isn't the only case.  also look at loops.
20:54 Tene you don't want "next" to remove your loop handlers.
20:55 rg actually i think you might.
20:55 NotFound You will need to re-push them... doable, but surely slower.
20:55 rg you definitely want it for break and return, therefor for next you could just jump *before* the push_eh
20:56 Tene That's horrible.
20:56 rg s/break/last/ to stay in perl lingo ;)
20:56 Tene And what if you have a loop inside of a try block?
20:57 rg what about that?
20:57 Tene you'll remove that EH too?
20:57 NotFound Tene: there are noy such things at pir level, they aren't?
20:58 Tene NotFound suggested removing all EHs in the call chain.
20:58 Tene NotFound: it's just another EH.
20:58 rg if you throw an exception that would make you leave the loop, you definitely want the loop's handlers removed. for a next you wouldn't get as far as your custom exception handler, so it won't be removed.
20:58 NotFound Tene: if is in an inner sub, they have his own context
21:00 Tene so you're removing all the handlers in the current PIR sub?  So refactoring an inner loop in PIR into a separate sub will change the behavior of the outer EH?
21:00 NotFound If I understand well, the wat to implment that type of things in HLL will be that the try block handlers and the loop handlers will be in different levels of inners
21:01 NotFound s/wat/way
21:03 NotFound Anyway I don't like much that approach, just say that will be cleaner to remove the whole context handlers rather than just until the current.
21:03 Tene This sounds horrible and hackish to me, and rather significantly breaks resumable exceptions.
21:03 Tene And "Many langauges don't use resumable exceptions" isn't a very good argument to me for breaking it.
21:04 NotFound Yes, we have it and we must handle it well.
21:04 rg can anyone point me at some documentation how continuations work? i.e. what happens when a continuation is passed to (and called in) a different context?
21:04 NotFound It continuates ;)
21:05 Tene There's a related problem right now in that when you return a continuation and invoke it later, the EHs aren't there anymore.
21:06 rg so you're saying it already doesn't work right? ;)
21:06 Tene I had a vague idea once for fixing that with a significant refactor, but I don't remember it anymore.
21:06 Tene rg: so your solution is to break it even more?
21:06 rg no, just in a different way
21:06 NotFound Tene: there is some test for that?
21:07 Tene NotFound: I think that rg posted an example to the list a while back that helped me notice that while fixing it.  I'm not sure if it's in a test.
21:07 rg but no, i'm not suggesting to break it
21:08 rg rather i'm thinking the fix may be the same for both problems
21:09 Tene But you're not actually proposing a fix thought, right?  Just suggesting that there might be one?
21:09 rg all i did so far was write a short example here in irc, sorry.
21:09 Tene Not trying to be confrontational.  I just don't much trust my memory.  Trying ot keep things straight.
21:10 Coke tickets are cheap. open one.
21:10 * rg wonders if there wasn't one already
21:13 * rg can't find one.
21:13 pmichaud Coke:  ping
21:13 NotFound I'll try the hackish way of storing a pointer to the current handler in the exception
21:14 Tene NotFound: "current handler"?  Explain more?
21:14 Coke pmichaud: pong
21:14 NotFound Tene: The ExceptionHandler that is running
21:14 Tene NotFound: where are you going to get that information?
21:15 NotFound Tene: storing it while throwing
21:15 Tene NotFound: from the throw opcode, where are you going to get the "current handler"?
21:16 Tene it's not in the interpreter, it's not in the context, it's not stored anywhere afaict.
21:16 NotFound Tene: will be shorter to write and show the code than to explain it ;)
21:16 rg i was also thinking that HLLs could maybe use pushmark/popmark to keep track of their handlers, but i didn't get around to checking that and it assumes that the generated code is correct (i.e. won't help when coding the HLL)
21:16 Tene If you can get the "current handler", it would be easier to just modify exceptionhandler.pmc's can_handle to decline to do anything if it's the "current handler"
21:17 NotFound Tene: yes, and precisely because I don't have it in any part, I must to store it somewhere
21:18 Tene NotFound: but where are you going to get it from to store it?
21:18 NotFound Tene: the code that choose the handler know the exception and the handler it selects.
21:19 Tene NotFound: do you mean that when you decide to invoke a handler with an exception as its argument, you'll store the handler in that exception?
21:19 Tene That won't help.
21:19 rg notfound: what are you working on?
21:19 Tene The problem is when we throw a *new* exception.
21:19 NotFound rg: I look for a fix to TT #300
21:19 Tene try { throw A; } CATCH { throw B; }
21:19 pmichaud Coke:  are you moving pynie out of the parrot repo?  if so, I think I'd like to move it to github.
21:20 Tene Storing the handler in A doesn't help when we're throwing B
21:21 rg notfound: yes, but what do you need that for? can you wait for a more general solution?
21:21 NotFound Tene: It needs to help in that case?
21:21 Tene NotFound: there are no problems with rethrowing an exception.
21:21 NotFound rg: sure, I can wait for a few seconds...
21:22 NotFound Timeout X-)
21:22 Tene NotFound: in that case, A stores the same iterator that was originally used when looking for a handler, and just picks up where it left off.
21:22 rg :P
21:22 Tene but when we throw B, it looks in the same place that A first looked at.
21:23 NotFound Tene: I don't have any problem with that, the problem I'm trying to fix now is TT #300
21:23 Tene it's the *second* throw that has problems.
21:23 * Tene looks
21:24 Tene Yes, exactly!
21:24 purl i guess exactly! is it not awesome?
21:24 Coke pmichaud: nope. that was just so I could close the RT.
21:24 Coke feel fre.
21:24 Coke e.
21:24 Tene you'd be storing a reference to the catchall: handler in $P0
21:25 Tene but then the handler does something broken, and get_results makes a *NEW* exception to throw
21:25 Tene this new exception isn't the same as the one stored in $P0
21:25 Tene Putting the reference in the exception stored in $P0 doesn't help.
21:26 NotFound Tene: yes, but the problem is that I need a way to know the handler at exception resume time, in order to clear the way used to mark it as active.
21:26 NotFound Without that, fixin TT #300 break a lot of other things
21:27 Tene ... what?
21:27 * purl quietly listens while the crickets chirp
21:27 Tene ... oh.
21:28 Tene so you're disabling it... and then reenabling it when the resume continuation is invoked?
21:28 NotFound A less hackish approach will be better, but I'm not found one for the moment.
21:28 NotFound Tene: that is the way I'm about to try, yes
21:28 Tene I don't see how you could even do that.  Are you creating a subclass of continuation that enables a handler when it's invoked?
21:29 Tene You resume like: resume = exception['resume']; resume()
21:29 Tene the resume continuation is just a continuation.  It doesn't know anything about the exception it was stored in.
21:30 NotFound Tene: no, the simpler idea is marking the handler as inactive when asked for 'resume'. If that works, we can think how to make it less hackish and more robust.
21:30 Tene you mean mark it active again.
21:31 NotFound Eh, yes
21:31 Tene and what about when the exception has been rethrown?  It won't work there either...
21:31 Tene Does this issue actually come up often enough to justify this hack?
21:32 Tene Is it causing pain for anyone?
21:32 NotFound Tene: IMO yes. When it fails, it takes lots of time to figure how, why, and where
21:34 NotFound At least on all tickets I looked at that were related, it tooked
21:35 Tene have you tried looking in the exception's backtrace yet?
21:36 NotFound Mmmm...... no. I'll look at it.
21:38 cotto seen whiteknight
21:38 purl whiteknight was last seen on #parrot 2 hours, 32 minutes and 14 seconds ago, saying: Well la de da mr super computer man
21:38 * pmichaud wonders if we'll someday have "Rakudo Python."
21:38 Tene EHs *should* appear in the backtrace.  (If they don't now, it's probably wrong, IMO)
21:45 Tene the solution I was thinking about before was something like making a clone of the contexts some undefined way up the stack, and storing that alternate chain of contexts in the continuation instead of the "real" one, so that when the EHs were freed from the real contexts through pop_eh, they'd still be referenced by the cloned contexts in the continuation.  Something like that.
21:45 Tene doing that for continuations in general, not just for exceptions.
21:45 Tene No idea what the consequences of that would be.  It wasn't really fully thought out yet.
21:47 rg is it possible that there's not much documentation about continuations anyway?
21:50 rg not many tests either :(
21:51 davidfetter joined #parrot
21:56 * Coke ponders a seen update for purl that provides fuzzy time.
21:57 Coke "about 2.5 hours ago..."
21:57 Coke masque?
21:57 purl masque is figuratively speechless. or COOL WITH BURRITOS EVEN IF MINE DON'T SAY TOMMY HILBURRITO or Masquenfusion on AIM - USE THIS TO FIND HIM, IRC SUCKS or totally in love with warningsToBrowser, but forgetting to turn that off is something I fear. or awake. or Masquenfusion and Euqsam. or DJ Fresh Catnip or pleased with Masque's copy. or (see masque 2) or fond of used things that work. or a herring
21:57 cotto "less than a month ago"
21:57 Coke a leeeetle less fuzzy than that.
21:57 Coke masque 2?
21:57 purl masque 2 is You sass that hoopy Masque? There's a frood who really knows where his towel is. or hellyeah sysop IIRC (or knows who is) or avocado-powered, baby
21:58 cotto That absolutely didn't make anything clearer.
21:58 cotto except that last one
22:01 Coke ok, tickets are cheap, but they're not as cheap as your mom.
22:01 Coke (search before opening, just to be nice.)
22:01 Coke (apologies for obligatory mom joke)
22:02 allison joined #parrot
22:09 GeJ good morning everyone
22:10 davidfetter evenin', GeJ
22:10 GeJ heya davidfetter. Congrats on the latest set of releases.
22:11 davidfetter ?
22:12 GeJ wasn't there some postgresql releases a few days ago?
22:13 dalek parrot: r36598 | cotto++ | trunk/src/global.c:
22:13 dalek parrot: [pcc] revert an apparently unintentional commit from r36594
22:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36598/
22:13 allison cotto++
22:14 allison (had just reached the same conclusion myself, after a binary search)
22:14 dalek parrot: r36599 | cotto++ | trunk:
22:14 dalek parrot: [gc] change pt_DOD_* to pt_gc_*
22:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36599/
22:15 GeJ allison: do you know who's in charge in handling PaFo's CLA applications?
22:16 allison GeJ: yes, the board handles them. emailing the address on the CLA will get you a reply from anyone in the board (myself included)
22:18 Tene allison: can you look at the discussion earlier about EHs?  specifically rg's request and NotFound's proposed workaround?
22:18 allison Tene: will check the Piper-log. is there a ticket?
22:19 Tene https://trac.parrot.org/parrot/ticket/300 is the ticket NotFound was producing a workaround for.
22:19 GeJ allison: Oh, ok. Just to say that I sent one a few weeks back per suggestions of several people in here. But unfortunately, I can already predict that my contributions to Parrot will be very limited for some time as $job doesn't seem to be willing to allow me some free time.
22:19 Tene I don't know if there's a ticket for the EH stuff.
22:19 NotFound Tene: I'm not sure having proposed a workaround for something :?
22:19 dalek parrot: r36600 | cotto++ | trunk:
22:19 dalek parrot: [gc] change interp->DOD_registry to gc_registry
22:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36600/
22:20 Tene NotFound: your "mark the handler inactive, then mark it active again when someone asks for the resume attribute from an exception" thing?
22:20 allison GeJ: the CLA is just a legal document to cover your contributions to Parrot, it doesn't matter how many or few you make
22:20 Infinoid cotto++ # my git-svn only updates once every 10 minutes, you're hard to keep up with
22:20 NotFound Tene: ah, yes, but that is not for rg request, is for TT #300
22:21 Tene NotFound: that's related to what rg was asking about.
22:21 GeJ I was wondering, would anyone be interested in having a Data::Dumper that returns data instead of just dumping it on STDOUT?
22:21 NotFound Tene: but I asked first ;)
22:21 Infinoid GeJ: definitely
22:21 Tene NotFound: eh?
22:21 NotFound No matter
22:22 Infinoid (returning a string)++
22:22 NotFound Can't you just use a StringHandler?
22:23 rg i don't think there is (i couldn't find one a few minutes ago). i'll try and write a new ticket one of these days unless someone beats me to it ;)
22:23 NotFound And dumping on a handler, not in hardcoded stdout, of course
22:23 Tene I'll make one now.
22:24 Infinoid NotFound: returning a string would make it as useful as the perl5 version of the module
22:24 GeJ Infinoid: ok, well, I'll give it a try. Can I forward you patches for review as I make progress? (as I said earlier, don't expect a constant flow of them for the foreseeable future)
22:24 Infinoid You don't *always* want to print it directly.  Maybe you want to print it more than once, or compress it and send it over a network, or whatever.
22:24 cotto Infinoid, should I hold off for a while?
22:25 Infinoid GeJ: No problem.  In return, I can't promise to respond with particularly useful messages :)
22:25 Infinoid cotto: No, it was a compliment.  By all means, keep kicking ass.
22:25 NotFound Infinoid: a StringHandler is printing it to a string, no loss of functionality
22:25 Infinoid Yeah.  Or you could just return it, the easy way.
22:25 cotto roger
22:26 allison Tene: in general, TT #300 is just an example of legacy exception handlers. The first thing every exception handler should do is check if the exception is one it can handle. If it can't handle the exception, it should rethrow it.
22:26 NotFound Infinoid: but slower and memory hungry when you want to use a Handler
22:26 Whiteknight joined #parrot
22:27 Tene That's what I thought.
22:27 GeJ For the record, the idea came to me while pursuing my Perl-to-PIR tests conversion quest. Some tests use Data::Dumper to output data structures, and  I couldn't figure out a way to catch that in a string and use it in a is() call.
22:27 allison Tene: we don't remove exception handlers, ever (that's what the old code did, and it was fundamentally broken)
22:27 NotFound GeJ: there is a way: redirect stdout to a stringhandler
22:27 rg allison: can you elaborate? i find the current aproach fundamentally broken aswell.
22:27 allison Tene: exception handlers live in the context, so when you leave the context you don't see them anymore
22:28 allison rg: with resumable exceptions, you can't remove handlers, because you may resume within the scope of an existing handler (in which case deleting the handler would produce the wrong semantics)
22:29 GeJ NotFound: I think I tried it at the time and failed. I probably did it wrong or things have improved since then. If you have a working syntax to recommend me, I'd be happy to apply it to the tests I'm trying to convert.
22:29 allison rg: instead, you leave handlers in place, but scoped to the context rather than scoped globally
22:29 nopaste "NotFound" at 213.96.228.50 pasted "Redirect strout to a StringHandle" (35 lines) at http://nopaste.snit.ch/15588
22:29 allison rg: so they naturally pass out of scope when you leave the scope
22:30 chromatic Or Data::Dumper could just not print by default, instead of building up a string and then printing it.
22:30 rg allison: how do you propose to solve the exception inside the handler results in recursion problem?
22:30 NotFound GeJ: I wrote that test some days ago
22:30 allison rg: that's caused by old exception handlers that aren't properly checking the type of the exception they're passed
22:31 allison by default, in Parrot, and exception handler will examine all exception types
22:31 allison s/and/an/
22:31 dalek parrot: r36601 | whiteknight++ | branches/rename_pccinvoke:
22:31 dalek parrot: Creating a branch to rename the Parrot_PCCINVOKE function and unify it with Parrot_pcc_invoke_method_from_c_args
22:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36601/
22:31 allison rg: most HLLs declare an exception handler for a specific type or set of types it can handle
22:32 allison rg: calling the same exception handler multiple times isn't a problem if that exception handler actually knows how to handle the exception
22:33 allison rg: the problem we're getting is exception handlers trying to handle exceptions of the wrong type
22:33 NotFound allison: the problem is when the exceptionhandler accidentally throws something it can handle
22:33 allison rg: so, the code makes assumptions about the exception it's passed, which turn out to be wrong, and cause exceptions
22:33 NotFound And does it before doing a pop_eh
22:34 allison NotFound: no, that's fine, if the handler actually know how to handle it
22:34 allison knows
22:34 NotFound allison: yes, in a perfect world... in the current world, is a bud difficult to catch
22:34 NotFound bug
22:35 allison NotFound: I'd generally argue it's a case of user error, but sometimes it's possible to change syntax in order to discourage a common user error
22:36 allison NotFound: what if... the default answer to "can_handle" were "No" instead of "Yes", and defining an exception handler *required* declaring what types it can handle?
22:36 chromatic ... and the exception handler dispatcher checked those types before dispatching to exception handlers, instead of requiring exception handlers to get this right themselves?
22:37 NotFound allison: I'm trying to find a way to catch current problems faster, short term
22:37 allison NotFound: it makes declaring exception handlers more verbose, but it means people don't run into these problems unless they explicitly ask for them
22:37 allison chromatic: in fact, it already checks them, just no one is bothering to set them
22:37 NotFound Call them legacy if you want
22:37 Tene allison: rakudo uses them
22:38 Tene allison: PCT uses them for handling 'return'
22:38 allison Tene: that's good. Progress
22:38 chromatic I'm sure PCT could set them.
22:38 Tene pct-generated loops use them
22:38 Tene rakudo's gather/take
22:38 Tene rakudo's CONTROL
22:38 Tene cardinal uses them
22:39 rg pct is not doing to well with the try/catch, though
22:39 rg s/to/too/
22:39 Tene defaulting to 'no' would be fine with me.
22:40 Tene allison: the problem with defaulting to 'no' is exceptions without any type set.  Should we disallow that too?
22:40 Tene Or just "don't do that"?
22:40 chromatic We could warn.
22:40 allison Tene: yup, make the answer to 'can_handle' false if the handler doesn't have a type set
22:41 allison Tene: and maybe even warn on initialization if no type is set
22:41 Tene allison: this will need a deprecation cycle, yes?
22:41 allison though, type is often set in a subsequent call
22:41 allison Tene: yes, and it will break all the legacy exception handlers in the system
22:41 Tene allison: we can warn on throw if there's no type set.
22:42 rg that might work. at least there wouldn't be as much recursion.
22:42 allison Tene: so, big code update (or at least scattered update, touching many files)
22:42 Tene It can happen in a branch.
22:42 allison Tene: yes
22:42 allison Tene: if we deprecate it now, it can still get in before 1.0
22:43 Tene It can go in after the Feb. release?
22:43 NotFound So we are going to deprecate push_eh LABEL ?
22:44 allison NotFound: no
22:44 Tene allison: are we requiring type, or type|severity?
22:45 Tene allison: if we default to no, then EH's created by push_eh LABEL will never catch anything.
22:45 NotFound Tene: well, at least that will completely solve #300 :D
22:47 allison Tene: I'd require type, with severity optional
22:48 Tene "catch all warnings" seems like a reasonable sort of handler.
22:48 allison Tene: good point on push_eh LABEL, so it would need to be "push_eh LABEL, INT"
22:48 NotFound allison: so we're deprecating it and cretaing a new one
22:49 allison Tene: yes, we need special virtual types for "all exceptions" and "all warnings"
22:49 allison NotFound: yes, but mainly keeping the shortcut of a label (where the actual exception handler object is created for you behind the scenes)
22:50 NotFound That is how is implemented the current version
22:51 allison NotFound: aye, that abstraction was changed in the big exception refactor (I just kept the same interface)
22:52 NotFound TT #295 is a recent example of bugs caused for that thing. I catched it fast just because I was working at related problems and know what to search for
22:55 NotFound Well, not caused for it, but without clean diagnostic because of it.
22:58 allison NotFound: yes, it seems that people *expect* their exception handlers to only handle the specific exception they're looking for, and not try to handle every exception
22:58 allison NotFound: so, perhaps we can make it behave more like they expect
22:59 NotFound allison: yes, but even in that case you can be actually trying to catch the same type of exception you accidentally throws.
23:00 rg i don't think this will quite solve the try { throw a; } catch { throw b; } case, but maybe we can get pct to help with that?
23:01 allison NotFound: if your handler is designed to handle those types of exceptions, then it shouldn't be a problem
23:01 allison rg: that's all about scope
23:02 allison rg: parrot doesn't currently support scopes smaller than a .sub
23:02 NotFound allison: if the excption handler is perfect no problem, but I'm talking about mistakes that lead to difficult to catch bugs
23:02 allison NotFound: no virtual machine can prevent users from making errors
23:03 allison NotFound: the best you can hope for is discouraging them
23:04 NotFound allison: a way to discouraging completely is that a handler does not catchs exceptions thrown inside himself.
23:05 allison NotFound: but with exceptions as labels within the scope of the sub, all handlers set within the sub semantically belong to that code
23:06 NotFound allison: then skip the sub and search handlers outside, no problem
23:06 allison NotFound: and if you make a special exception for a handler at the bottom of the chain, what if the problem is actually with a handler farther out the chain?
23:07 allison NotFound: that is, the same problem can occur if you're invoking a handler 5 levels outside the current sub
23:07 NotFound Same thing, search for handlers in the outside
23:07 Tene NotFound: with handler-as-label, you also can't detect the difference between an exception thrown outside of the handler and inside it.
23:07 allison NotFound: because the invocation context for the handler is the point where the exception was thrown
23:08 NotFound Tene: actually not, that's the reason why I was looking for one.
23:08 allison (a handler is just a sub)
23:08 rg i thought parrot didn't support a real sub as a handler yet
23:08 allison NotFound: arbitrarily deciding to skip the first handler doesn't eliminate recursive handlers, it just bumps it back a level
23:09 allison rg: exception handlers are continuations, which are subs
23:09 NotFound allison: not the first, the handler that is running
23:09 allison NotFound: all that does is screw up your exception hierarchy
23:10 allison exception handler hierarchy
23:10 rg which gets me back to the lack of documentation on continuations *sigh*
23:11 TiMBuS joined #parrot
23:11 allison rg: hey, the best person to write it is the person who doesn't understand it yet :)
23:11 allison (writing documentation is an *excellent* way to learn)
23:11 allison (possibly the best)
23:15 dalek parrot: r36602 | cotto++ | trunk:
23:15 rg ah there, whiteknight++ did it already. we really need an online version of docs/book ;)
23:15 dalek parrot: [gc] change all occurances of "early_DOD" to "early_gc"
23:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36602/
23:18 dalek parrot: r36603 | cotto++ | trunk:
23:19 dalek parrot: [gc] change all occurances of "high_priorty_DOD" to "high_priorty_gc"
23:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36603/
23:22 dalek parrot: r36604 | cotto++ | trunk:
23:22 dalek parrot: [gc] change DOD_flags to gc_flags
23:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36604/
23:30 * rg is trying to wrap his head around the scope definition.
23:31 rg is it possible to push_eh a handler that doesn't have itself in scope?
23:32 Whiteknight rg: we DO need an online version of docs/book/, I've been bitching and moaning about that for a while now
23:32 dalek parrot: r36605 | cotto++ | trunk:
23:32 dalek parrot: [gc] rename PROF_DOD_* to PROF_GC_*
23:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36605/
23:32 Whiteknight but yeah, the book has lots of surprises. If you have any questions about anything, that's a good starting point
23:33 NotFound rg: you can push_eh anything that is an ExceptionHandler
23:34 rg whiteknight: i was avoiding it because my perldoc was complaining about a lot of markup in there. what do i need to install to get that right?
23:35 chromatic Pod::PseudoPod
23:37 dalek parrot: r36606 | whiteknight++ | branches/rename_pccinvoke/src/global.c:
23:37 dalek parrot: [rename_pccinvoke] make the first change, everything compiles. That's a good start.
23:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36606/
23:38 rg notfound: sure, but can i set_addr something that is a different scope?
23:40 cotto What's the difference between DOD_RUNS and COLLECT_RUNS?
23:41 cotto and would it be accurate to change DOD_RUNS to GC_RUNS?
23:41 rg and also, what can i do at the end of that handler if i don't want to call the return continuation
23:41 Tene you can do whatever you want.
23:42 Tene another common choice is .return()
23:42 Tene or goto
23:42 rdice joined #parrot
23:44 dalek parrot: r36607 | allison++ | branches/load_language:
23:44 dalek parrot: Creating branch for testing the load_language opcode.
23:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36607/
23:46 nopaste "tene" at 97.117.56.92 pasted "sub exception handler example for rg" (30 lines) at http://nopaste.snit.ch/15589
23:46 Tene the first two 'say's are lies that I was too lazy to change.
23:47 NotFound rg: you mean in pir? You even not have access to labels out of scope.
23:47 Tene That example works fine.
23:47 Tene Is there not a test of that?
23:49 rg tene: thank you, i was just trying to get that to work
23:49 Tene rg: no problem
23:49 NotFound Ah, you mean a sub. That makes more sense.
23:49 rg now let's try that with .return() ;)
23:49 Tene I don't think it's quite the right way to do it, with find_name and such.
23:51 NotFound And if we have a nice implementation of invoke, we can even use an ExceptionHandler object as his own handler sub
23:52 * chromatic is tempted to reject all tickets about failing tests which don't provide the diagnostics of those tests.
23:53 NotFound And gives his senders to the Spanish Inquisition
23:53 Tene If that was the only way to do EHs, it's a pretty simple patch to give you the "don't catch exceptions thrown from the EH" behavior you want.
23:54 Tene I'm certainly not going to be the one to migrate all existing use of EHs, though.
23:54 Tene ;)
23:56 rg aha, .return() returns to the calling sub, not quite unexpected.
23:56 dalek parrot: r36608 | allison++ | trunk/src/call:
23:56 dalek parrot: [cage] Adding svn:ignore property for .str files.
23:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/36608/
23:58 rg tene/allison: how would we deprecate that in a backwards compatible way anyway?
23:58 Tene rg: we wouldn't.
23:59 NotFound What 'that'? The push_eh LABEL unconditional?
23:59 Tene NotFound: using labels instead of subs for EHs.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced