Camelia, the Perl 6 bug

IRC log for #parrot, 2009-04-21

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 cotto LylePerl, I can confirm that rakudo builds fine on my system from a fresh checkout, but fails if there's old stuff.  It's definitely something make realclean is leaving behind.
00:06 Whiteknight All tests pass on my system, Ubuntu 9.04 x86_64
00:09 AndyA joined #parrot
00:09 LylePerl I've updated my ticket with the findings
00:09 LylePerl I have a new found hatred for realclean
00:10 LylePerl infinoid, I've tracked the problem down to realclean
00:10 LylePerl infinoid: I've updated the ticket. Seems those 2 files being dropped weren't such a red herring after all
00:10 Infinoid Subject: realclean is insufficiently real
00:12 LylePerl It's an issue with Rakudo's realclean, so I should take my frustrations out on #perl6 tomorrow, lol
00:12 Infinoid heh
00:12 Infinoid is there an ordering dependency between the rakudo/parrot realcleans to reproduce this?
00:12 Infinoid or will either order do?
00:13 cotto It's nice to know my commit only exposed existing brokenness instead of causing it.
00:13 LylePerl either will do as far as I know
00:14 cotto Does anyone know what time fperrad is planning on cutting the release?
00:14 Infinoid no idea.  I think he's in western europe, so probably pretty early by our standards
00:14 LylePerl To reproduce exactly what I had you'd need to build a pre r38030 parrot against a rakudo from 2 weeks ago
00:15 LylePerl then realclean and update both and try to build again
00:15 Infinoid I actually have the path "config/gen/makefiles/root.in" memorized by now.  I'm not proud of that
00:16 Infinoid LylePerl++  # but really I should see the "dll and ops files still exist" symptom with any checkout
00:17 LylePerl oh yeah, you'll get that with any checkout. But if you want that wierd build error...
00:18 LylePerl wierd = weird
00:18 Infinoid thanks, but I've already seen plenty of weird build errors :)
00:18 Infinoid thanks, you've given us something much more concrete
00:19 LylePerl Felt really bad that I'd wasted every ones time earlier, but I knew there was a problem somewhere...
00:19 LylePerl Hopefully this makes up for it :)
00:20 LylePerl Most importantly this version of Rakudo finally has the IIS CGI fix you did :)
00:20 Infinoid LylePerl++
00:20 bacek_ joined #parrot
00:20 Infinoid You've never stopped helping us, don't worry about it.
00:20 LylePerl Infinoid++
00:21 LylePerl time I went to bed. thanks everyone
00:22 Infinoid sleep wel
00:22 Infinoid l
00:33 mikehh looking at docs/book/ch09_pasm.pod - the failures seem to be incomplete .pasm
00:33 hudnix joined #parrot
00:34 mikehh and probably shouldn't have the =begin PASM /  =end PASM
00:49 darbelo left #parrot
01:07 silug joined #parrot
01:13 mikehh what is or was the find_type opcode?
01:17 Fayland_logger joined #parrot
01:20 jdv79 joined #parrot
01:23 wayland_ joined #parrot
01:50 LimbicRegion joined #parrot
01:50 kid51 mikehh:  find_type has ceased to be
01:50 kid51 ... though how long ago it went away, I couldn't say
01:53 mikehh ze problem being is dat it isa used in docs/book/ch09_pasm.pod in 5 places
01:54 mikehh and of course imcc doesn't like it
01:55 mikehh what would you use in it's place>
01:55 mikehh s/>/?/
01:57 kid51 I've no idea.
01:57 kid51 I'm grepping the log for it.  Definitely long gone.
01:58 kid51 Documentation bug, which definitely qualifies for a TT.
01:58 petdance joined #parrot
02:01 nopaste "kid51" at 70.85.31.226 pasted "svn log . | grep -C5 find_type" (171 lines) at http://nopaste.snit.ch/16343
02:05 Whiteknight There's a problem with chapter 09?
02:05 Whiteknight wasn't any last time I ran the tests
02:08 nopaste "kid51" at 68.237.8.99 pasted "pge_examples.t fails on make testj on Darwin/PPC (same as last night)" (28 lines) at http://nopaste.snit.ch/16344
02:08 dmknopp joined #parrot
02:09 mikehh and also 'newsub', 'new_pad', 'compile', 'classoffset'
02:09 kid51 In that same chapter?
02:10 mikehh yes - it fails 31 out of 121 tests
02:11 kid51 I'm snagging the entire log so that I can grep it for those terms.
02:11 kid51 Of course, grepping for 'compile' is probably not going to be fruitful.
02:11 kid51 Are those all supposed to be ops?
02:13 mikehh That's what it fails on eg error:imcc:syntax error, unexpected IDENTIFIER, expecting PARROT_OP ('compile')
02:13 rg have you tried trac search? that should include log messages
02:14 mikehh not all of the failures are ops though
02:14 mikehh hang on I'll paste it
02:15 dmknopp left #parrot
02:16 nopaste "kid51" at 70.85.31.226 pasted "new_pad opcode is long gone" (71 lines) at http://nopaste.snit.ch/16345
02:16 nopaste "mikehh" at 90.209.236.67 pasted "errors in perl t/examples/pod.t docs/book/ch09_pasm.pod" (326 lines) at http://nopaste.snit.ch/16346
02:17 Coke msg fperrad: that file had NO failures the last time I touched it. Everything was properly todo'd.
02:17 purl Message for fperrad stored.
02:17 Coke msg fperrad - still passes 100% here.
02:17 purl Message for fperrad stored.
02:18 Coke msg fperrad r38240.
02:18 purl Message for fperrad stored.
02:18 nopaste "kid51" at 70.85.31.226 pasted "newsub opcode is long gone" (272 lines) at http://nopaste.snit.ch/16347
02:18 nopaste "kid51" at 70.85.31.226 pasted "classoffset opcode is long gone" (90 lines) at http://nopaste.snit.ch/16348
02:20 Coke You can easily make chapter09 pass by converting the failures to PASM_INVALID blocks instead of PASM.
02:20 Coke (that will effectively skip them).
02:20 Coke Obviously, fixing up the sample code is better, but that might be tough to do in the time remaining.
02:21 mikehh for eg the first failure should not have =begin PASM / =end PASM and the last is due to 'find_type' opcode
02:26 mikehh I am working on it at the moment and will see how much I can fix in the next hour or so
02:42 janus joined #parrot
02:45 Coke danke. If you end up updating the pasm blocks, please give a shot at updating the surrounding text that refers to it where that makes sense.
02:57 eternaleye joined #parrot
03:04 mikehh There is a whole bunch of code under Inheritance starting at line 3091 which is incomplete, refering to stuff which comes before
03:11 mikehh actually even before that eg ok 113 - docs/book/ch09_pasm.pod:3073 is an inc P3 - which is meaningless on its own
03:16 mikehh some of the failures are due to code that would have set up in previous snippets and oters due to removed op-codes
03:16 mikehh s/oters/others/
03:17 mikehh should have said missing code
03:17 allison the code with setup in previous examples shouldn't be marked for auto testing
03:18 mikehh should I remove the =begin PASM / =end PASM there
03:27 japhb joined #parrot
04:17 tetragon joined #parrot
04:21 allison mikehh: yes, that seems to make the most sense
04:21 Infinoid hrm, I still can't reproduce LylePerl's realclean issue
04:26 eternaleye_ joined #parrot
04:29 eternaleye__ joined #parrot
05:00 cotto I thought we'd decided to drop Makefile.PL
05:03 nopaste "mikehh" at 90.209.236.67 pasted "Patch for docs/book/ch09_pasm.pod to get t/examples/pod.t working" (507 lines) at http://nopaste.snit.ch/16350
05:04 mikehh that gets perl t/examples/pod.t docs/book/ch09_pasm.pod to pass
05:04 cotto mikehh, wouldn't it be better to fix the code?
05:06 mikehh sure - but it would take longer than a couple of hours as a lot of the opcodes used have been removed
05:07 mikehh and we want it working for release - you might be able to do that quickly - but I couldn't
05:07 cotto it's worth a shot.  I should be able to at least get a couple working.
05:08 cotto Is t/examples/pod.t run by default for make test?
05:09 mikehh damn - I missed a failure in ch03_pir.pod - otherwise the rese op make examples_tests is ok
05:09 mikehh rest of
05:10 mikehh cotto: no - make examples_tests or make fulltest
05:11 cotto ok.  It'd be higer-priority if it caused make test failures, although it's still important.
05:11 cotto Have you filed a ticket?
05:12 mikehh no - because I wanted to see if I could fix them properly first - but not in time for the release
05:15 mikehh It would probably take me a day or two to get it sorted out properly
05:17 mikehh btw Failed test 'docs/book/ch03_pir.pod:1654'
05:17 mikehh error:imcc:syntax error, unexpected ADV_INVOCANT, expecting '\n' (':invocant')
05:18 mikehh from:   .param pmc item :invocant     # "self" is now called "item"  at line 1662
05:21 cotto I like that we have a formal way to ensure that all the code samples actually run.
05:21 cotto even if they don'y right now
05:21 cotto *don't
05:23 mikehh one of the problems in ch09_pasn,pod is that a lot of the later examples are not complete and depend on some of the earlier snippets
05:25 cotto That is a downside.
05:30 Theory joined #parrot
05:41 mikehh gotta take a break for a bit - bbl
05:51 dalek parrot: r38241 | cotto++ | trunk/docs/book/ch09_pasm.pod:
05:51 dalek parrot: [book] fix some code examples
05:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38241/
05:54 cotto Wow.  Some of that code has cobwebs.
05:55 cotto I don't think classoffset was valid when I started contributing to Parrot.
06:11 uniejo joined #parrot
06:44 amoc joined #parrot
06:53 iblechbot joined #parrot
07:11 tuxdna joined #parrot
07:23 he Hm...  src/call/pcc.c:2453: error: used struct type value where scalar is required
07:24 he That's ASSERT_ARGS in set_context_sig_returns_varargs(), when I try to build on NetBSD/alpha.
07:26 he And... that's probably the va_list returns which is "guilty".
07:35 he Apparently, there's no guarantee that va_list is a scalar or a pointer type.
07:36 salts joined #parrot
07:46 cotto particle-, ping
07:49 masak joined #parrot
07:54 pmichaud hello, all
07:54 moritz hi pmichaud
07:55 pmichaud is it too late to get some commits in prior to release?
07:55 pmichaud (wireless at hotel wasn't working lastnight/this morning)
07:55 moritz I think it's still a few hours until release, and I haven't see a "don't break things now" post :-)
07:56 pmichaud well, my commit won't break anything.  But I do need to test it on latest trunk before commit.
07:56 riffraff joined #parrot
07:57 riffraff hi everyone
07:57 purl Howdy, riffraff, you fantastic person you.
08:01 fperrad I'll start release after #ps
08:02 moritz so it's 11.5 hours still
08:02 pmichaud well, we'll see how many spectests I can get in before my airplane has to board.
08:03 pmichaud I wanted to do all of this last night, but the hotel network was kaput.
08:06 riffraff I as trying to use parrot-1.0.0 to write a small article about it, but when I execute perl tools/dev/mk_language_shell.pl it ends with
08:06 riffraff Can't open perl script "/usr/local/lib/parrot/1.0.0​/tools/dev/gen_makefile.pl": No such file or directory
08:06 riffraff Any ideas?
08:06 riffraff doe I need to run make install before everything works?
08:07 fperrad riffraff, make install-dev
08:07 nopaste "he" at 158.38.152.119 pasted "There's no guarantee va_list is integral or pointer, so don't do PARROT_ASSERT_ARG on it; found on NetBSD/alpha" (22 lines) at http://nopaste.snit.ch/16353
08:09 pmichaud riffraff: perhaps try  tools/dev/create_language.pl instead
08:09 pmichaud but if you did "make install"  or "make install-dev"  it might not be installed yet.
08:11 nopaste "he" at 158.38.152.119 pasted "Add NetBSD/sparc64 5.0 to the PLATFORMS list, ref. smoketest 20265" (12 lines) at http://nopaste.snit.ch/16354
08:15 riffraff ok I'll install
08:15 riffraff I just remembered I did not need to do it with the svn version :)
08:15 riffraff thanks everyone
08:16 cotto cla?
08:16 purl rumour has it cla is Contributor License Agreement or http://www.perlfoundation.org/​contributor_license_agreement or http://www.parrot.org/foundation/legal
08:16 cotto cla is also http://www.parrot.org/files/parrot_cla.pdf
08:16 purl okay, cotto.
08:19 riffraff I do not see create_language.pl anyway, even after make install-dev, maybe it is a post 1.0 addition?
08:20 bacek_ riffraff: it is. But 1.1 release is in less than 12 hours.
08:21 tuxdna joined #parrot
08:25 cotto karma darbelo
08:25 purl darbelo has karma of 3
08:26 riffraff ah I see thanks :)
08:27 particle joined #parrot
08:28 dalek rakudo: 0e73267 | pmichaud++ | docs/ChangeLog:
08:28 dalek rakudo: Update ChangeLog.
08:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​e73267078a0f9a2bde0ecf15cde2a857c09c55a
08:28 dalek rakudo: 69b3180 | pmichaud++ | src/ (2 files):
08:28 shorten dalek's url is at http://xrl.us/bepq7n
08:28 dalek rakudo: Restore prefix:<=> to provide a useful error message (moritz++)
08:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​9b31808f41b41ed34dc273500faccc7cd5fb8cb
08:28 shorten dalek's url is at http://xrl.us/bepq7p
08:51 bobke joined #parrot
08:51 pmichaud yay, got my commit in.
08:51 pmichaud time to board.
08:51 pmichaud see you all later.
08:52 moritz have a good flight
08:52 dalek parrot: r38242 | pmichaud++ | trunk/runtime/parrot/library/P6object.pir:
08:52 dalek parrot: [p6object]:  Adjust .ACCEPTS on protoobjects to handle junctions again.
08:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38242/
09:08 he joined #parrot
09:08 rblasch joined #parrot
09:12 dalek parrot: r38243 | fperrad++ | trunk/PLATFORMS:
09:12 dalek parrot: [PLATFORM]
09:12 dalek parrot: - update for MinGW gcc 3.4.5
09:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38243/
09:31 he Non-portable: #define PARROT_FLOATVAL_INF_POSITIVE  floatval_divide_by_zero(interp, 1.0)
09:31 he On alpha, doing that will land you a SIGFPE.
09:33 cotto darbelo?
09:33 purl darbelo is probably Daniel Arbelo Arrocha <mailto:dany.arbelo@gmail.com> or into bonding or mailto:arbelo@gmail.com
09:35 ascent_ joined #parrot
10:09 bsdz joined #parrot
10:29 Ademan joined #parrot
10:35 ascent_ joined #parrot
10:36 pjcj joined #parrot
11:38 iblechbot joined #parrot
12:05 Whiteknight joined #parrot
12:28 Infinoid joined #parrot
12:34 Coke_zzz msg cotto we still do cpan, so makefile.pl is still useful. (we could hide it or something, but still useful)
12:34 purl Message for cotto stored.
12:34 Coke msg cotto we still do cpan, so makefile.pl is still useful. (we could hide it or something, but still useful)
12:34 purl Message for cotto stored.
12:34 * Coke dislikes IRC.
12:35 * Coke ponders running an xmpp server at parrot.org :|
12:36 rg1 joined #parrot
12:38 wayland_ Coke: IRC is useful for drawing others into the conversation :)
12:47 Infinoid its user interface can vary a lot, but I don't think IRC itself is bad
12:49 LylePerl Infinoid: You couldn't re-create my realclean issue?
12:49 LylePerl Infinoid: on what machine? XP?
12:51 bsdz Re:IRC I've found mibbit invaluable when I'm behind a firewall or have no local client installed http://www.mibbit.com/
12:54 LylePerl bsdz: That's what I use :)
12:55 Infinoid LylePerl: winxp/strawberry/mingw, yes
12:55 Infinoid two different machines, but more or less the same software.
12:57 Infinoid I've tried various combinations of building everything, doing a realclean, and seeing whether blib/lib and src/ops/*.c still exist (they didn't)
12:59 Infinoid LylePerl: What is $RM_RF defined to in your makefile?
13:01 Infinoid hmm, looks like that's a call into ExtUtils::Command on all platforms
13:02 Infinoid For realclean to work, it needs to keep removing even if there are some arguments in the middle of the list which it can't find.
13:02 Infinoid It should be the very last command run by "make realclean".  Does it emit any error messages for you?
13:05 rg he++ # cross platform testing on rare hardware
13:06 gryphon joined #parrot
13:08 rg he: if 1.0 / 0.0 (with vars) doesn't work on alpha, how do you get an inf value? on x86 hardware, the floating point exceptions/interrupts are masked by default. maybe is there a way to do that on alpha aswell?
13:08 bsdz Probably unrelated but occasionally I've realcleaned after an svn update and configure.pl and it went off into an infinite loop. i think the trick was to realclean before reconfiguring.
13:09 tuxdna joined #parrot
13:09 he rg: #include <math.h>, and use INFINITY?
13:09 he NaNs also need special treatment.
13:11 he ...because if I do (f == 0.0) and f is a NaN, I get a SIGFPE as well.
13:11 rg he: it's also an indication that some math operations wouldn't work the same. I don't know if there are tests dividing by zero, but if there are, i'd suspect them to also give you a SIGFPE
13:12 rg so what we really want is to either ignore SIGFPE on alpha, or not have it signaled.
13:12 dalek parrot: r38244 | Infinoid++ | trunk/PLATFORMS:
13:12 dalek parrot: Add netbsd5.0-sparc64-gcc-4.1.3 to PLATFORMS, courtesy of he++
13:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38244/
13:12 he rg: yep.  Relying on that nothing happens if you divide by zero or do other stuff which I think gives undefined results is not portable.
13:13 Infinoid joined #parrot
13:13 he I'm re-running tests after having made my third or fourth patch to parrot 1.0.0 for the day.
13:13 he "We'll see"
13:16 Infinoid he: Are there any other nopastes?  I've just woken up, wondering if I missed anything.
13:16 Coke does rakudo currently work against an installed parrot?
13:16 he rg: or rather... what I wanted to say: parrot should not be doing anything which invokes undefined behaviour.
13:17 rg since parrot is just providing the means, i don't think we can do that
13:17 he Infinoid: No, I don't think I have anything outstanding.
13:18 he Infinoid: ...or... rather, I had one diff for NetBSD/alpha, but it was premature.  I'll return later with a more complete set if/when I get there.
13:18 * Coke checks the ticket report for 1.1 ...
13:18 Infinoid he: http://nopaste.snit.ch/16353 is ... interesting.  Those are autogenerated by "make headerizer" from the ARGIN/ARGMOD/ARGOUT tags in the function declaration
13:18 Infinoid Does the argument's type change?  If so, we might want to find a better fix for that.
13:18 tuxdna joined #parrot
13:19 Coke https://trac.parrot.org/parrot/query?stat​us=assigned&amp;status=new&amp;status=reo​pened&amp;group=status&amp;milestone=1.1 is pretty big. :(
13:19 shorten Coke's url is at http://xrl.us/beprnj
13:19 he It's not so much that it changes, "va_list" is an opaque type which is not guaranteed to be an intval or a pointer, and on NetBSD/alpha it's a struct.
13:19 Infinoid If it's always a pointer but is just not reliably non-null, we can add a _NULLOK suffix
13:20 Infinoid oh, ok.  hmm
13:20 he I obviously didn't know where that came from originally.
13:21 Infinoid Maybe we can hide that behind PARROT_VA_LIST and force parrot to pass around a pointer to it... but probably not in time for 1.1
13:22 he va_list is a little special, and care is needed to not do something which is undefined by the standard.
13:22 Infinoid yeah
13:24 he But at least as far as I can see from the std (iso C), taking a pointer to va_list and passing it around is allowed.
13:24 Infinoid did rurban leave?  if so, that's sad, but we probably need to steal his tickets
13:25 Infinoid he: If so, then we can probably make things a little more consistent.
13:25 Coke there are plenty of non-assigned tickets to work on. =-)
13:25 he Oh, one of the tests print (in addition to what's expected): parrot in free(): warning: page is already free.
13:25 dalek parrot: r38245 | fperrad++ | trunk/t/codingstd/c_function_docs.t:
13:25 dalek parrot: [t] fix this test on Windows
13:25 dalek parrot: previous r38236 was a bad idea (fperrad--)
13:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38245/
13:25 Infinoid true, but I tend to ignore the ones that someone else has already taken... out of sight = out of mind
13:25 Coke that's fine. fix all the unassigned ones first! =-)
13:26 Infinoid he: That sounds like a bug :)
13:26 rg uh duplicate free. i wonder where that comes from
13:26 he Infinoid: no kidding! :)
13:26 Infinoid he: does valgrind run on your platform?
13:26 he Infinoid: I'll try to track it down.
13:26 he Infinoid: not sure, doubtful.
13:26 Infinoid too bad, it's good at things like that.
13:27 he Gah: devel/valgrind/ is there, but ONLY_FOR_PLATFORM=      Linux-*-*
13:27 Infinoid I guess it has to explicitly emulate portions of the OS and CPU, so there's a high cost for porting it
13:29 Infinoid hmm, breakfast, what a wonderful idea.
13:35 dalek tracwiki: v146 | coke++ | ParrotRoadmap
13:35 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Par​rotRoadmap?version=146&amp;action=diff
13:35 shorten dalek's url is at http://xrl.us/bepro7
13:35 tuxdna joined #parrot
13:37 Coke Infinoid: was your #504 meant to be the roadmap ticket ?
13:37 Infinoid yes
13:38 Coke ok. on the roadmap it's assigned to jonathan.
13:38 Infinoid yes
13:38 Coke ok.
13:38 he Bah, when I try to separate out the part of the test which triggers the "already free" bug, I don't get it.  When the whole test is run under perl, the "already free" is printed.
13:38 he I get the feeling that one is going to be hard to debug.
13:38 Infinoid same command line arguments?
13:39 dalek tracwiki: v147 | coke++ | ParrotRoadmap
13:39 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Par​rotRoadmap?version=147&amp;action=diff
13:39 shorten dalek's url is at http://xrl.us/beprph
13:39 rg he: is parrot or perl printing the already free message?
13:39 he Part of it is I don't know how parrot is run.
13:39 he rg: oh, that I can find out.
13:39 * Infinoid suspects the perl harness is adding --gc-debug to the parrot command line
13:39 rg infinoid: it definitely is
13:40 Coke Infinoid: updated the (soon to disappear) roadmap to mark you as the owner, killed the duplicate I just opened.
13:40 Infinoid eew, responsibility
13:40 tuxdna joined #parrot
13:41 Coke when it disappears, your name is on the ticket, anyway.
13:41 he rg: it's parrot which prints it.
13:42 Infinoid he: When parrot is run with the --gc-debug argument, it will cause the GC to destroy everything the hard way.  this is very likely the cause of your error message
13:42 Infinoid or rather, --gc-debug found a GC bug on your platform
13:42 Infinoid which test is it?
13:42 rg infinoid: EXTRA_TEST_ARGS := --gc-debug --running-make-test
13:45 he Hmm, of course one of the tests is doing $N0 = 'Inf'; $N0 -= $N0 -> kaboom
13:46 Infinoid that's what tests are for :)
13:46 Infinoid Coke: I honestly don't think I can commit to getting the packfile roadmap item done right now.
13:47 Infinoid I was helping out with the pmcs portion of the task, but I haven't done any work on it in a long time
13:48 he "./parrot --gc-debug pared-down-testfile.pir" still didn't show the "already free" part.
13:48 Infinoid also, I was originally led to believe part of the task was reviewing/updating the pdd, but the wording seems to have changed since then.
13:48 Coke Infinoid: changed owner to jonathan.
13:48 Infinoid thanks
13:48 Infinoid he: which test was it?
13:48 he The one with "already free" is t/pmc/packfiledirectory.t
13:49 rg is running perl t/harness --gc-debug t/pmc/packfiledirectory.t printing it?
13:50 Infinoid (it doesn't here)
13:51 he rg: yep, both with and without --gc-debug prints it.
13:51 rg does running ./parrot  t/pmc/packfiledirectory.t print it?
13:54 he rg: doesn't work: error:imcc:syntax error, unexpected IDENTIFIER, expecting $end ('use'), in file 't/pmc/packfiledirectory.t' line 5
13:54 he (no surprise, really)
13:54 rg works here
13:54 rg oh but you're still on 1.0.0
13:55 Infinoid he: I think you must be using 1.0.0, not svn head
13:55 he Yep, still on 1.0.0.
13:55 rg there have been a lot of packfile changes on trunk
13:55 he (sorry, should have mentioned that)
13:55 he Ah, ok.
13:55 Infinoid yes, and those tests were translated to pir
13:55 rg you did, i just forgot, sorry
13:55 he ok, time to bring up svn on this test platform as well, I guess.
13:55 rg i wonder if we shouldn't just ignore it then. it may not even be happening anymore.
13:55 Infinoid he++
13:56 he For now, though, I'll nopaste the diffs I have so far.
13:56 Infinoid it was very likely fixed.  bacek++ did all of that work for the specific purpose of cleaning up this kind of problem
13:56 he They're not intended to be committed directly (although they could...).
13:59 nopaste "he" at 158.38.152.119 pasted "diffs for porting to NetBSD/alpha, 2 test failures remain" (95 lines) at http://nopaste.snit.ch/16363
14:02 nopaste "pacolinux" at 80.36.122.139 pasted "weird error building rakudo (gcc bug ? )" (35 lines) at http://nopaste.snit.ch/16364
14:02 PacoLinux Im having a very weird error building rakudo in my main machine that seems to be a gcc 4.1.3 bug - solved using --optimize while building parrot
14:02 rg i'd love to know if your include/parrot/datatypes.h isn't the better solution in general.
14:03 rg infinoid: can you test how well it would work on windows?
14:03 moritz PacoLinux: --optimize + rakudo stopped working for me shortly before the 1.0 release
14:05 PacoLinux moritz: without --optimize I cant build rakudo .. now runing spectest
14:06 moritz PacoLinux: did you try a 'make clean' in rakudo after building parrot?
14:06 tuxdna joined #parrot
14:07 PacoLinux moritz several times, and in several directories (new downloads)
14:07 moritz PacoLinux: please report the build failures (without --optimize) to rakudbug@perl.org, if you haven't already.
14:09 PacoLinux moritz: seem to be a lot of special case (I tried in several linux under virtualbox and the error is not reproducible)
14:09 PacoLinux I think is more a gcc problem than rakudo/parrot
14:17 he Say, if I wanted for this particular platform to set SIGFPE to SIG_IGN, where would I do that?
14:23 Infinoid rg: not for several hours, gotta go to work now
14:24 rg he: i don't know. for testing you could stick it right into main.c
14:24 bsdz joined #parrot
14:25 dalek tracwiki: v148 | Infinoid++ | ParrotRoadmap
14:25 dalek tracwiki: reassign packfile item to jonathan
14:25 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Par​rotRoadmap?version=148&amp;action=diff
14:25 shorten dalek's url is at http://xrl.us/beprvy
14:34 gariani joined #parrot
14:37 he Hmm, if I read correctly, ISO C mandates FP trapping or stopping be disabled on program startup.
14:37 danielgrafael joined #parrot
14:42 rg which seems to be what the other platforms are doing
14:43 Coke via something in the platform config/ ?
14:44 rg coke: no, the os does it.
14:45 NotFound he: note that strict iso compatibility may need some option in some compilers
14:46 PacoLinux moritz: reported
14:52 Coke Infinoid: ah, forgot the wiki.
14:52 Coke (I am trying to kill that page, so please forgive me. =-)
14:52 Infinoid Coke++ # using the features trac is good at
14:54 he rg: yep, setting SIGFPE to SIG_IGN made the arithmetic tests succeed.
14:55 rg with or without the patches you already had to work around the signal?
14:55 he oh, with them all.
14:55 he hrm, should try to revert some of them, I guess...
14:57 Infinoid hmm.  if config/gen/platform/netbsd/math.c had an init function that was called at parrot startup, this would be a great place to drop a SIGFPE=SIG_IGN workaround
14:58 rg infinoid: is there a place for platform specific startup? i haven't run across any yet.
14:58 he OK, trying to build now with most of the other fp-related patches out of the way, still with 1.0.0.  It'll take a while, though, and I'll leave for a couple of hours too.  Later, guys.
15:00 he left #parrot
15:00 Infinoid rg: src/global_setup.c looks like the right file for it, even though I can't point to a particularly relevant function
15:01 Infinoid ah, it calls Parrot_platform_init_code() when PARROT_HAS_PLATFORM_INIT_CODE is defined
15:01 Infinoid (currently only used by win32.)
15:10 rg good to know.
15:10 purl good to know. is there an ETA for dust starting to settle, or is it just finished when its finished?
15:10 rg purl: forget good to know
15:10 purl rg, I didn't have anything matching good to know
15:10 rg purl: forget good to know.
15:10 purl rg, I didn't have anything matching good to know
15:10 Infinoid rg++ # beat me to it
15:11 rg if only :(
15:11 Coke good to know.
15:11 Coke you just have to know how to talk to the girl.
15:14 * rg just doesn't understand women ;)
15:14 Infinoid Neither do they.
15:20 Infinoid has anyone else encountered the issue with strawberry perl on athlon xp machines, where libgmp was built with SSE2 instructions and it pops up a windows crash dialog during Configure.PL?  (RT #50212)
15:20 Infinoid I just found a workaround, rg++ for getting me to look at Parrot_platform_init_code()
15:21 * particle doesn't have any athlon machines
15:21 Infinoid I've been using one for parrot/mingw testing for a while.  It's slow.
15:29 * Coke wonders when the call for proposals began for yapc10
15:30 Coke (since the deadline is friday)
15:31 Coke ah, back in march, according to the website. Must have missed an email.
15:33 particle deadline friday! oot!
15:34 Coke guess I need to decide if I'm going.
15:34 eiro joined #parrot
15:35 * Coke is not liking the lack of information on the site. :|
15:38 nopaste "infinoid" at 75.140.33.106 pasted "RT #50212 workaround, will commit this after the release" (28 lines) at http://nopaste.snit.ch/16365
15:38 cognominal joined #parrot
15:48 uniejo joined #parrot
15:59 Theory joined #parrot
16:05 Coke Infinoid: would it make more sense to have all our c functions just call Parrot_platform_init_code ?
16:06 Infinoid it's per binary, not per function
16:06 Coke s/functions/tests/
16:06 Coke yah, I screwed up there.
16:06 Infinoid That probably wouldn't hurt, but it's a little more invasive than I intended
16:07 Coke perhaps there's a place for boilerplate already on the C stuff. Iunno.
16:08 Infinoid Maybe we could concatenate in config/gen/platform/win32/misc.c when generating the test .c file
16:08 Infinoid then all you'd have to do is call the function, without duplicating the init code
16:08 Infinoid I dunno.
16:10 Infinoid if we're talking about extending the init interface to trap SIGFPE on netbsd, it might be good to keep that code common, rather than adding win32-specific fixups directly
16:10 * LylePerl got caught up with £work£
16:13 LylePerl Infinoid: I'll check $RM_RF, I need to build parrot again first...
16:14 LylePerl cotto confirmed the same problem as me last night, but I'm not sure what system he was on
16:14 Infinoid LylePerl: Thanks, I've checked and I'm sure $RM_RF is set the same on all platforms, but I'd still like to know if it barfs on your machine
16:15 Infinoid it's actually just a call into a perl library
16:16 LylePerl I've got a Perl meet tonight, but when I get back I'll do tests on some other machines and write a proper bug report with steps to re-creating the issue
16:17 Infinoid thanks
16:25 uniejo joined #parrot
16:37 rdice joined #parrot
16:59 contingencyplan joined #parrot
17:20 kj joined #parrot
17:21 he joined #parrot
17:33 Infinoid fperrad: How are things looking for the release?  Does anything need work?
17:34 fperrad all seems ok except t/examples/pod.t
17:35 fperrad i don't think it's a blocker
17:36 Infinoid ok, good to hear.  I agree
17:41 Whiteknight joined #parrot
17:48 Coke fperrad: I can mark all those invalid ones invalid if you like.
17:48 Coke (and therefore skip them.)
17:49 uniejo joined #parrot
17:50 Coke fperrad: meh. not worth it for this release, ne'ermind
17:50 he ok, with SIGFPE set to SIG_IGN, now only the packfiledirectory.t test fails.  Now to try svn head.
18:04 allison_ joined #parrot
18:07 Infinoid he: Thanks.  I'm hatching an evil plan to make a config/gen/platform/netbsd/misc.c and put that in Parrot_platform_init_code() so it's called at init time (win32 has a similar fixup), was going to work on that this evening when I get home from $job
18:08 Infinoid You're welcome to beat me to it. :)
18:08 barney joined #parrot
18:08 he Infinoid: :)
18:09 Infinoid Is this a cpu-specific netbsd issue or does it occur on all cpu types?
18:09 he It's cpu-specific.
18:10 Infinoid Out of curiosity, which cpu?
18:11 he This is alpha.
18:11 Infinoid Judging from PLATFORMS, you're the first one to have tested on alpha in a while.  The fix might be valid on some other unices, too
18:12 he That's quite possible.
18:13 Infinoid You've increased our tested "extra platforms" list by 50%.  he++
18:17 davidfetter joined #parrot
18:19 dalek parrot: r38246 | fperrad++ | trunk/NEWS:
18:19 dalek parrot: [release] final NEWS
18:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38246/
18:21 masak joined #parrot
18:21 darbelo joined #parrot
18:24 he Hmm, another varargs fallout:
18:24 he ./src/pmc/class.pmc:338: error: incompatible type for argument 4 of 'Parrot_pcc_build_sig_object_from_varargs'
18:25 he "va_list isn't by necessity compatible with a pointer"
18:28 Infinoid no, but &va_list should be, perhaps we should convert that interface
18:28 Infinoid (if we want to pass NULL like that caller is doing)
18:28 he Yep.
18:28 he Hm, is src/call/pcc.c generated from something else?
18:29 Infinoid the stuff within the /* HEADERIZER BEGIN: static */ and /* HEADERIZER END: static */ comments is, otherwise no.
18:29 he ok.
18:30 Infinoid Hmm, changing the Parrot_pcc_build_sig_object_from_varargs interface would require a deprecation cycle, we probably couldn't change that interface until a few months from now
18:30 cotto LylePerl, I'm on Ubuntu Hardy i386
18:32 Infinoid allison, do you have any better suggestions?
18:32 darbelo_ joined #parrot
18:33 chromatic joined #parrot
18:33 allison we have to be able to pass pointers to varargs some distance, but it doesn't have to be far
18:33 allison (no more than 1 function call in the new model)
18:33 Infinoid is there something we can call that will get the same result as calling Parrot_pcc_build_sig_object_from_varargs with a NULL va_list?
18:33 Infinoid (since we're not actually passing any varargs, I have to wonder if there's a better function.)
18:33 moritz it's #ps time!
18:34 moritz ... and I'm late :/
18:34 allison well, if it's a null varags list, then we don't need to call it at all
18:34 Infinoid moritz: me too, thanks for mentioning it
18:34 Infinoid in that case, ./src/pmc/class.pmc:338 should hopefully be easy to fix
18:37 allison Infinoid: We'll likely want a singleton (PMCNULL_SIGNATURE) for subs that pass no arguments and return no values
18:38 allison Infinoid: PMCNULL would do for now, but it'd be nice to know it was intentional
18:39 Infinoid Ah, that makes sense
18:45 rblasch joined #parrot
18:47 darbelo joined #parrot
18:49 Util Coke, for future reference, you can use /NAMES to see everyone on the #ps channel.
18:49 Coke yes.
18:49 Coke I have a list of people in the channel. I don't have a list of committers. =-)
18:52 Util Oh, I see.
18:57 Infinoid Whiteknight++ # inciting peasant uprising
18:57 szabgab joined #parrot
18:58 Whiteknight I figured the suggestion wouldn't fly, but I do want everybody to start thinking seriously about major JIT changes
18:59 Whiteknight because we need a major rebirth of that system for Parrot to continue maturing in a reasonable way
18:59 Infinoid I'm worried that gsoc jit branches will quickly diverge from trunk to the point that they'll be as unmergeable as gc branches
18:59 chromatic One of the problems of the GC branch is that the current GC is entangled throughout the system.
19:00 chromatic If we'd had more encapsulation there, replacing it would have been easier.
19:00 he oh, lookie, it built.  Now to test.
19:00 pmichaud hello, everyone.
19:00 Infinoid is there anything we can do to improve JIT encapsulation to prepare for this?
19:00 moritz I think another problem is that it's simply a huge task, so it takes time, and much other stuff will happen in the mean time in trunk
19:00 Infinoid or is it just nci and a runcore and that's all we have to worry about?
19:01 Whiteknight encapsulation++
19:01 Whiteknight encapsulation++
19:02 allison It is encapsulated in the runcore
19:02 allison so, Util is right, anyone can make an alternate JIT runcore
19:02 Infinoid Ok, I won't worry about it then
19:02 cotto That's very good to hear.
19:03 NotFound We must also take into account jitted nci
19:05 Whiteknight My worry is that people will be complacent about keeping the current system if it works on their platform, when we really should be striving for more platform equality
19:05 Infinoid oh!
19:05 Whiteknight saying that it works on x86 and ppc is not the same as saying "it works"
19:06 Coke Whiteknight: it doesn't work on x86. =-)
19:06 allison the partially working JIT isn't the biggest obstacle to working on a new one, the biggest obstacle is that JITing is a non-trivial task
19:06 Whiteknight well, it does when we get all the cards stacked back up
19:06 chromatic Sure, and when I donate blood it doesn't work on silicon based lifeforms.
19:06 cotto Coke, You're welcome.
19:06 NotFound We must make it work even on platforms that are not designed yet ;)
19:06 Coke NotFound: yagni.
19:07 Whiteknight allison: yes, I don't want to downplay that. It is difficult. that's why I'm scraping and scrounging for motivation
19:07 Coke (!x86) I'm referring to darwin/x86, but as chromatic says, we're wierd.
19:07 Infinoid We had someone in here (hi LylePerl!) a couple weeks ago asking about redirecting stderr to a file, for debugging a CGI app under IIS.  We looked at the "setstderr" op, which worked fine for the PIO level, but it was useless for capturing the exception he was seeing.  But do we have any plans to override the stdio level stuff?
19:08 Whiteknight I want everybody to have JIT on the brain until we finally get a solid, working, portable version implemented
19:08 allison at the moment, any object that has the right methods can be a drop-in replacement for a "core" I/O object
19:08 Infinoid right, but that doesn't help for assertion failures and the like
19:08 allison Infinoid: I think I'd need a code example
19:09 Coke Whiteknight: finding someone to /work/ on JIT is probably more helpful than generic agitprop.
19:09 NotFound An assertion failed is a symptom of a big mistake in the code, we can't hope to be able to capture that
19:09 Infinoid allison: he was seeing an ASSERT_ARGS failure due to a NULL IO PMC, r37986 fixed it
19:09 dalek parrot: r38247 | chromatic++ | branches/headercleanup (5 files):
19:09 dalek parrot: [runcore] Moved a header out of src/runcore/ into parrot/include/.
19:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38247/
19:10 Infinoid If the answer is "make sure every possible C crash uses the right I/O routines to output their error messages", that's good enough for me.
19:10 Whiteknight Coke: We have people to work on it. What we don't have is the people to keep trudging through the mess of the current system everytime something breaks there
19:10 Whiteknight JIT broke on i386 when we removed that UnionVal stuff, and it took days to fix it
19:11 chromatic That's because the current approach to JITting is completely wrong.
19:11 NotFound Infinoid: my answer is: don't let it crash. Fix any branch in the code that leads to the crash, make it throw exceptions where appropiate
19:11 Infinoid Whiteknight: Hey, I did some trudging too :)
19:11 Whiteknight chromatic: Exactly! Exactly! What we have is wrong, we should clear it out and make way for bigger and better
19:11 chromatic Okay, let's apply that argument to the GC.
19:12 chromatic <crickets>
19:12 Infinoid NotFound: Happy to.  The problem is, it's a pain to debug such crashes to get said fixes.
19:12 Whiteknight it's like saying "I'll just wear these concrete shoes while I go swimming because they're my size"
19:12 allison Infinoid: setting STDIN to PMCNULL is an unusual solution
19:12 Whiteknight chromatic: GC isn't the big-ticket du jure anymore
19:12 Whiteknight :)
19:13 NotFound Infinoid: that is the reason to have such assertions: to avoid even painfull crashes
19:13 Infinoid allison: setting stdin to PMCNULL allows the stdout and stderr assignments to go through (and yes, there's a typo, fixed by r37990), so writing to stderr works later on
19:13 chromatic Okay, let's apply that argument to IMCC.
19:14 allison Infinoid: there is a separate exception path for failures when it's known that the regular file handles will be closed, or the failure will be too catastrophic to allow an exception to be caught
19:14 Whiteknight chromatic: IMCC and GC aren't optional systems, they can't be removed without killing parrot. JIT can be
19:14 Whiteknight it's apples and oranges
19:15 chromatic The problem with the JIT isn't the JIT.  It's everything around the JIT that makes the design of the JIT troublesome.
19:15 chromatic You can't remove all of that in one swell foop and have Parrot continue to work.
19:15 Infinoid allison: My question was about whether we're ever going to allow stdio level overrides, or if the solution is to use PIO for more error messages
19:15 dalek rakudo: e31a6f8 | pmichaud++ | src/ (2 files):
19:15 dalek rakudo: Remove obsolete fish operator ("=<>").  It didn't work anyway.
19:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​31a6f881356f0f5a217d84b39238727a2dc969f
19:15 dalek rakudo: 6ea0aa1 | pmichaud++ | src/classes/ (2 files):
19:15 shorten dalek's url is at http://xrl.us/beps64
19:15 dalek rakudo: More fixes to Match objects.
19:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​ea0aa164d0a6fab90a03974bc06215efb3823c1
19:15 shorten dalek's url is at http://xrl.us/beps66
19:16 Whiteknight I won't argue with that, but you pull out the JIT and you'll have much better access to the troublesome interface. You'll be able to fix individual problems without a cascade effect
19:16 allison Infinoid: it's to use PIO for more error messages
19:16 chromatic We'll never fix the JIT until we fix the underlying problem with ops and PMCs.
19:16 Whiteknight Work up a sane interface, and then build a sane JIT on top of that
19:16 Infinoid ok, thanks
19:16 Whiteknight chromatic: what's the underlying problem with Ops and PMCs that you're referring to?
19:16 chromatic Any JIT anyone writes, no matter how good their intentions, is doomed until we fix those problems.
19:17 Infinoid Can we remove the doom beforehand?
19:17 chromatic They're big wads of C code we have to translate manually to macroized platform-specific assembly code to JIT.
19:17 chromatic (or we compile *all* of Parrot, the whole thing, to LLVM bytecode and hope its whole program analysis can clean up some of the mess for us)
19:18 chromatic TimToady calls that the "Sweeping it under someone else's rug theory of optimization".
19:18 Whiteknight chromatic: on that note, I've been thinking more about your idea of using custom operations primitives to implement ops instead of writing them in C
19:19 pmichaud Coke:  #47970 hasn't been an issue for me for quite a while.  I think we can close it until it appears again.
19:19 Whiteknight And then a step in the build could translate them into C and JIT generators automatically
19:20 chromatic allison and I talked about that a while ago.
19:20 chromatic We seemed to agree that writing a self-hosted little language in which to write ops and PMCs was useful.
19:21 Whiteknight it would take some careful design to make a language that's powerful enough but doesn't require too complex a parser, but it's doable
19:21 chromatic Emit C code for now, but if in the future we have L1 ops to target, write a new emitter.
19:21 Whiteknight maybe not "in the future", maybe that's the next logical step for us in preparation of new PMC and JIT systems
19:22 allison chromatic: aye, but we're talking 3.0 here
19:22 allison or even 4.0
19:22 chromatic Which part?
19:22 darbelo joined #parrot
19:23 allison making parrot PMCs, JIT, etc, self-hosting on a little language
19:23 dalek parrot: r38248 | fperrad++ | trunk (12 files):
19:23 dalek parrot: [release] Changes to prepare for 1.1 release.
19:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38248/
19:23 allison (if it'll even work, needs prototyping first)
19:23 Coke Whiteknight: at some point, we have to pay for the choices made by earlier developers. if that means we have to keep the old JIT on life support until we have a new JIT, thems the breaks.
19:23 Whiteknight allison: what if it wasn't a separate little language, what if it was a small subset of PASM with some C interface thunking added?
19:23 Whiteknight Coke: Paying down that debt involves removing the mistakes and replacing them, not living with them
19:24 chromatic How about making PMCs and ops self-hosting and emit C now?
19:24 allison Whiteknight: doesn't matter what the language is
19:24 allison it's the "self-hosting" part that's hard, no matter what syntax we use (we're good at parsing syntax of any variety)
19:24 Coke Whiteknight: I think that might contradict our support policy.
19:24 Whiteknight Anything we do to reduce manual synchronization between /src/ops/* and src/jit/* would be a major win
19:25 allison sure, but there's long-term planning involved
19:25 allison first, develop the system, prove it works and can replace the existing system
19:25 allison then we plan the deprecation cycle to replace the existing system
19:26 allison chromatic's right, I think self-hosting has a lot of potential
19:26 NotFound If we create a new way of writing pmc, surely we can have it working in parallel with the current one until all pmc are converted.
19:27 allison NotFound: two different simultaneous systems is a world of pain
19:27 chromatic Replacing Perl 5 as part of the PMC/ops build process is on the roadmap too.
19:27 Coke chromatic: I question that roadmap item.
19:27 allison chromatic: exactly, we have to do it anyway
19:27 Whiteknight I think I do too, we have a lot of complex build-time parsing that won't be easy to do with a different language
19:28 allison Coke: it's not that hard, everything we're currently doing in Perl 5 could be done in PGE
19:28 Coke ... except that PGE needs parrot.
19:28 cotto the parrot and the egg
19:28 allison Coke: it's not even platform-dependent, so we could have the C generated versions checked into source control and included in the tarball
19:28 chromatic Not everyone who builds Parrot has yacc/bison lex/flex installed.
19:28 allison chromatic: exactly
19:28 NotFound A Configure system for languages based only in parrot will be a nice start
19:29 Whiteknight some of the generated C code relies on constants derived from the Perl-based configuration system
19:29 Coke If I see a plan that's more than handwaving "replace perl5", i'll give it more thought. =-)
19:29 NotFound Whiteknight: and that is a big obstacle in the road to cross-compiled parrot
19:29 Whiteknight I don't want to poo-poo the idea, but replacing Perl 5 is going to be a lot of work and conceptually I don't see where all the pieces fit yet
19:29 allison Coke: it's a pile of smaller plans, not one big plan (since we're using Perl 5 in a number of different ways, for different reasons)
19:30 chromatic 1) Write a PGE grammar that can parse existing .pmc files and emit the same C code that the Perl 5 parser does.
19:30 Whiteknight NotFound: good point.
19:30 allison if it helps any, I've entirely eliminated Perl 5 in Pynie
19:30 allison we just don't need it
19:30 chromatic 2) Write a PGE grammar that can parse existing .ops files and emit the same C code that the Perl 5 parser does.
19:30 he whee: "All tests successful."
19:30 chromatic 3) Specify a new language in which to write existing code in .pmc files which the parser written in #1 can emit as the same C code as now.
19:30 nopaste "he" at 158.38.152.63 pasted "Current set of diffs (main.c is scheduled to go) for NetBSD/alpha" (266 lines) at http://nopaste.snit.ch/16366
19:30 chromatic 4) s/pmc/ops/ from #3
19:31 chromatic 5) Write a new backend emitter which targets L1 ops for #3 and #4
19:31 Coke "L1 ops" ?
19:31 chromatic 6) Connect to the L1 op JITter
19:31 chromatic Shorthand for self-hosting opcodes.
19:31 NotFound chromatic: for bonus points, make it emit better C code that current ;)
19:31 allison I might put 5 before 3 & 4, but the general principle is sound
19:31 Coke what does "self-hosting opcodes" mean?
19:31 chromatic Imagine we had 128 opcodes which could replace every use of C in .pmc and .ops files.
19:31 Coke (also, please write this up on the wiki.)
19:32 allison Coke: chromatic has an idea for writing most of our ops in terms of a small set of jitted ops
19:32 chromatic Allocate/free a chunk of memory, call function, write to this chunk of memory, read from this chunk of memory, etc.
19:32 chromatic Those 128 opcodes are very, very easy to JIT.
19:32 allison Coke: think of it as changing most of our opcodes to be PIR functions
19:32 Coke allison: ok. so this depends on fixing jit on every core platform?
19:32 chromatic Now write the rest of our opcodes in terms of those Level 1 opcodes.
19:33 Whiteknight chromatic, I think we could do it in a lot fewer then 128 opcodes, if we used 3-argument commands that were type agnostic
19:33 allison Coke: actually, it doesn't, but it might make the JIT easier if we only had a very small number of opcodes written in C
19:33 chromatic Sure, it's probably more like 72 opcodes.
19:33 Whiteknight the generated C could would warn us about type mismatch insanity
19:33 allison Coke: and the rest were written in PIR (or some other simple language)
19:33 Coke (plan) Document plans.
19:34 allison Coke: the biggest problem now with the JIT is we have to write manual machine code for al 1,200+ opcodes
19:34 Whiteknight and we have to manually synchronize those definions with whats in src/ops/*
19:34 allison Coke: and this is not the official plan, or even close to it yet, but it's a good avenue for research and prototyping
19:34 chromatic The second biggest problem now with the JIT is that it *can't* improve performance for anything non-trivial.
19:34 Coke /is/ there an official plan, 'cause I don't know that one either. =-)
19:35 allison Coke: for the JIT?
19:35 Coke for the jit, for replacing perl5...
19:35 pmichaud I'm coming into the middle of this discussion (more)
19:35 Coke how jit would ever make something like "subclass" work...
19:35 Coke (er, work faster)
19:35 pmichaud but it occurs to me that most PCT things, and especially Rakudo, would benefit most from something that can do very fast method dispatch
19:35 pmichaud in particular, the number of opcodes that PCT tends to use is quite small.
19:36 Infinoid So, what can we do in the near term to reduce gsoc2009-llvm's chance of failure?
19:36 allison Coke: for replacing Perl 5, it's: Use PIR or HLL test files, write Test::Harness in PIR (or an HLL that runs on Parrot and can be compiled down to PIR)
19:36 * rg needs more time to catch up on the logs to see what has been said about the jit discussion, but really wants it noted that the existing jit is incomplete, broken in parts and not well maintained already. sorry if that has been said already.
19:36 pmichaud it would be very interesting (and not very difficult) to do an analysis of what opcodes are being used in the PIR generated for Rakudo itself.
19:36 Infinoid rg: Yeah, it ended up turning into a discussion about how to redesign parrot well enough that the next jit will work better
19:36 allison Coke: write PGE parsers for the custom bits of parsing we do with Perl 5, and check in the generated versions of the files
19:37 allison Coke: for the JIT, the official plan at this point is keep improving and fixing the existing one, do some R&D on alternate strategies
19:38 Whiteknight Infinoid: In my opinion to help gsoc-llvm, we need to make the JIT interface as sane as possible
19:38 Infinoid I thought removing it would make it about 100% more sane :)
19:38 Whiteknight with a sane interface and good encapsulation, it will be easier to write any JIT core that we want or need
19:40 rg allison: i'd disagree there. spending time on improving and fixing the existing jit could be much better spent elsewhere. (i'm certainly not going to do it)
19:40 Infinoid Whiteknight: If you run across any tasks that need a strong back and a weak mind, lemme know.  I've got some spare time in the next couple of weeks
19:40 Whiteknight Infinoid: If the task only requires a weak mind, I've got dibs :)
19:40 Infinoid heh
19:40 allison rg: then you should spend your effort on the R&D for alternate strategies :)
19:41 rg i might (or just fixing other bugs). the question then becomes what to do about the existing bugs.
19:41 Whiteknight allison: If you can think of any work that we could do to make the GSOC project run more smoothly, I think we have a few people here willing to work on it
19:41 Whiteknight Because I want that LLVM backend very badly
19:42 Coke chromatic: if we have opcodes that can be written in terms of other opcodes, wouldn't creating PIR syntax to generate the multiple simpler opcodes also be a viable strategy?
19:42 allison Whiteknight: that is a question for Kevin. But really GSOC is supposed to be an independent work. And we won't really know what needs to be done to core Parrot until he's made the experiments anyway.
19:43 chromatic I don't understand what "creating PIR syntax to generate the multiple simpler opcodes" means.
19:43 allison Whiteknight: that's what the project is about, experimenting
19:43 Coke PIR already has sugar to turn PIR into (multiple) opcodes, no?
19:43 allison chromatic: he means your "little bootstrapping language"
19:44 dalek rakudo: a76abb3 | (Moritz Lenz)++ | src/setting/Match.pm:
19:44 dalek rakudo: fix .value confusion in Match.caps
19:44 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​76abb3e95b45f3604e0ec99218f2c17cb370b45
19:44 shorten dalek's url is at http://xrl.us/beptbe
19:44 Coke say, .get_results() ?
19:44 allison Coke: yes, it does
19:44 chromatic Oh.
19:44 allison Coke: an, in a sense this is an extension of that strategy
19:44 allison and
19:45 Coke ok. I wonder why the extension is necessary. =-)
19:46 allison hmmmm... yes, you're right, the compilation could be integrated into IMCC, or PIRC
19:46 chromatic I'm still not following.
19:46 Coke chromatic: you're suggesting that we have an opcode FOO that could be written in terms of opcodes BAR and BAZ, yes?
19:46 allison chromatic: well, it would mean we don't need a separate compiler
19:46 Whiteknight chromatic: he's saying that if all ops can be written in terms of a subset of simpler ops, then we could just replace complex ops with those sequences in IMCC
19:47 allison chromatic: some opcodes would be "pure" JITed opcodes, and others would be constructed from the pure opcodes
19:47 chromatic Okay.  Sure, that can work.
19:47 particle sounds RISCy
19:47 allison it accomplishes the same thing, but with lower bootstrapping complexity
19:48 chromatic Except that it adds complexity if you want to define new ops as you go.
19:48 particle "as you go" == dynops?
19:48 allison depends on how the existing ops are created
19:48 allison it could be nothing more complex than ".sub myop :op"
19:48 chromatic They have to get registered with the compiler somehow.
19:48 allison and allow for dynamic extensions
19:49 allison that is, they're just simple subs, stored in some core namespace ('parrot'; 'ops')
19:49 particle an opcode segment in the bytecode?
19:49 allison or, at least some of them are
19:50 Coke if the PCC ever get fast enough, I will probably ditch dynops in partcl and just go for methods.
19:50 Infinoid_ joined #parrot
19:50 allison Coke: yes, that makes sense
19:50 chromatic The difference between dynops and methods is that you can always inline dynops.
19:50 chromatic At least, if they weren't big wads of C code.
19:52 Coke OOC, shouldn't inline op isne(out INT, invar PMC, invar PMC) just skip the check at the beginning and always call the VTABLE?
19:52 NotFound BTW, there is a real need for setstderr and such opcodes? I think that using interpreter methods can be good enough
19:52 Coke ah, the old opcode vs. method debate! =-)
19:54 NotFound Coke: vs. method and .vs pir directives. I won that in the HLL map case ;-)
19:55 Tene that wasn't an opcode, though
19:55 NotFound Was a pir directive
19:56 NotFound Uh, I mean "vs. opcodes and..."
20:03 dalek parrot: r38249 | chromatic++ | branches/headercleanup (5 files):
20:03 dalek parrot: [runcore] Absorbed src/runops_cores.h into include/parrot/runcore_api.h.
20:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38249/
20:05 gryphon joined #parrot
20:06 * allison going to catch a plane
20:10 bsdz joined #parrot
20:11 rg so i guess my answer on what to do about the existing jit bugs is "wait for someone to fix them properly"?
20:12 moritz well, it's always the same in open source - either you wait and hope, or do it yourself
20:12 rg well i have a workaround that just disables some of the existing code. a proper fix is way beyond my available time.
20:13 rg if that's not acceptable, i at least know what to focus my efforts on.
20:14 rg however some open source project prefer a working solution over a perfect fix.
20:15 chromatic It depends on the bug.
20:15 rg chromatic: in my case tt #530 and tt #551.
20:16 bsdz looking for some insight into pir inheritance issues. i notice that find_method looks though a pmc's methods but a lot of methods aren't methods and sit inside a namespace hash. here's a nopaste http://nopaste.snit.ch/16339 . should these multisubs be findable with find_method or are they not meant to be accesible to derived classes?
20:18 chromatic Ugh, I hate TT #530.
20:19 rg can you be more specific?
20:20 he Aand... Now lost the src/main.c diff, and still "All tests successful."
20:21 chromatic rg, I'm not sure not using float registers is the *right* approach, but in lieu of a better approach....
20:22 rg like i said, it's not the *right* approach. that would be to remove all mappings before calling c. but it's the only approach i can manage.
20:23 dalek parrot: r38250 | fperrad++ | tags/RELEASE_1_1_0:
20:23 dalek parrot: tagged release 1.1.0
20:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38250/
20:23 Infinoid Are we there yet? :)
20:24 rg and it's not that much of a hit, since c is called quite often.
20:25 chromatic If we document it and some thoughts on how to fix it the right way, if we ever get the chance, we'll know.
20:27 uniejo joined #parrot
20:31 Coke I would call c, but he changed his number after the stalking incident last yapc.
20:32 Coke ... you know, I really am not a fan of doing xml and text manipulation in Cold Fusion. :P
20:33 particle i know a language you can use to make that fun.
20:33 particle c!
20:35 pmichaud wow, running two sets of spectests in parallel really hits the battery
20:35 * pmichaud looks for a power port.
20:39 Infinoid I've yet to find a language in which xml manipulation was fun.
20:41 confound LOLCAT
20:42 * Infinoid shudders at the thought of doing xslt transforms in lolcode
20:43 chromatic You can remove "in lolcode" from that sentence and it's still true.
20:43 Infinoid Yeah, that's a big part of the problem.
20:43 dalek parrot: r38251 | chromatic++ | branches/headercleanup (6 files):
20:43 dalek parrot: [runcore] Moved src/runops_cores.c to src/runcore/cores.c and fixed up all
20:43 dalek parrot: references.  The API isn't quite solid yet, but this system is getting cleaner.
20:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38251/
20:43 HG` joined #parrot
20:46 he http://smolder.plusthree.com/app/pu​blic_projects/report_details/20292
20:46 shorten he's url is at http://xrl.us/beptjz
20:47 particle Infinoid: you obviously haven't been introduced to LOLPATH
20:48 Infinoid he: Very nice.  That's with the SIGFPE hack and nothing else?
20:48 rg also some varargs fixes
20:48 he Well, also with the workarounds for the assumption that va_args is integral or pointer.
20:48 Infinoid oh, ok
20:49 he Ref. the nopaste I gave a while earlier.
20:49 he I did the platform misc.c / misc.h dance instead of the tweak in main().
20:50 he sorry s/va_args/va_list/
20:50 he Changed prototype of Parrot_pcc_build_sig_object_from_varargs().  Is that one used by anything outside of parrot itself?
20:51 Infinoid Probably.
20:51 purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look  Because \ an asshole.
20:52 Infinoid allison mentioned a better approach to that problem, earlier.  I'll see if I can clean some of this stuff up tonight
20:53 Coke bsdz: I think you're conflating vtables and methods.
20:53 Coke (at a quick read of your email.)
20:56 bsdz Coke: i admit there might be some conflation but really don;t understand what that namespace has is all about and why it's sucking in my methods. not sure why the methods has doesn't have them either :(
20:56 bsdz s/has/hash/
20:58 bsdz funny looks like message has disappeared. may be i started pointing to an unsynced google news server :/
21:00 whoppix joined #parrot
21:03 bsdz must have been a strange google glitch. its come back
21:03 Whiteknight joined #parrot
21:05 chromatic Wow.  The .str cleanup in make prog-clean is awful.
21:05 dalek rakudo: 7c8346d | pmichaud++ | docs/spectest-progress.csv:
21:05 dalek rakudo: spectest-progress.csv update: 373 files, 10389 passing, 0 failing
21:05 dolmen joined #parrot
21:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​c8346df9fde58fae401d99e81cdc0d6621c3bcb
21:05 shorten dalek's url is at http://xrl.us/beptnw
21:06 * Coke wonders what prog-clean is.
21:06 Coke ah.
21:07 chromatic Fragile and broken, honestly!
21:07 * Coke wonders, ooc, if the ext utils understand "*/*/*.str"
21:08 chromatic Or, like my imminent checkin will prove, we already have a perfectly good way to refer to all generated .str files: $(STR_FILES)
21:08 Coke ... mmmhehehe.
21:09 dalek parrot: r38252 | chromatic++ | branches/headercleanup/con​fig/gen/makefiles/root.in:
21:09 dalek parrot: [config] Improved cleaning of generated .str files; now it gets them all.
21:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38252/
21:10 * particle notes root.in isn't a header
21:10 chromatic Sure, but it's only an issue right there because my header changes exposed breakage in that assumption.
21:11 chromatic It *may* be an issue on trunk, but that's only if people start moving around files with embedded CONST_STRINGs.
21:13 dalek parrot: r38253 | chromatic++ | branches/headercleanup (4 files):
21:13 dalek parrot: [runcore] Moved src/trace.c to src/runcore/trace.c and its header to
21:13 dalek parrot: include/parrot/runcore_trace.h.  These files exist only to support the tracing
21:13 dalek parrot: runcore, so they're there now.
21:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38253/
21:13 dalek rakudo: ad73895 | (Moritz Lenz)++ |  (2 files):
21:13 dalek rakudo: bump PARROT_REVISION to parrot-1.1 release
21:13 dalek rakudo: Also re-enable a test which was broken before by a parrot change
21:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​d738953efe34c6c5187498cebc24b621835ef33
21:13 shorten dalek's url is at http://xrl.us/bepto7
21:15 Topic for #parrotis now #parrot Parrot 1.1.0 Released | http://parrot.org/
21:16 dalek tracwiki: v65 | fperrad++ | WikiStart
21:16 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=65&amp;action=diff
21:16 shorten dalek's url is at http://xrl.us/beptpm
21:17 Infinoid fperrad++
21:20 fperrad fperrad needs help
21:20 fperrad on website www.parrot.org, I can't find "Create content" -> "Story"
21:20 fperrad just "Create content" -> "Scratch"
21:21 Infinoid there are 3 items in the Create content menu for me... Page, Scratch and Story
21:23 Infinoid One moment, I think I can fix this
21:23 Infinoid fperrad: try now?
21:23 particle you just gave fperrad editor?
21:23 Infinoid poster, actually
21:24 Infinoid judging from the access control page, poster has "create story content"
21:24 particle should add this requirement to the release manager guide
21:25 fperrad "Story" now available, thank
21:26 Infinoid wow, parrot.org has a ton of registered users.
21:27 * rg doesn't see it :(
21:28 chromatic fperrad, is it safe to commit to trunk now?
21:28 Whiteknight fperrad++
21:29 particle Infinoid: yeah, seems there's a bot registering users there
21:29 particle it's annoying
21:29 fperrad Yes, tag is created
21:29 chromatic Thanks.
21:30 Infinoid particle: as long as they aren't creating any spam content...
21:30 dalek parrot: r38254 | chromatic++ | branches/headercleanup (151 files):
21:30 dalek parrot: [headercleanup] Brought the headercleanup branch up to date with r38253.
21:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38254/
21:31 Coke chromatic: any issues with files changed after you moved them?
21:31 chromatic None.
21:31 chromatic That bothers me not a little.
21:31 Coke did the merge warn about anything skipped?
21:31 chromatic No.
21:32 Coke were one paranoid, one could run a double check.
21:33 chromatic Did I hear a volunteer?  Someone who ran the original check and knows what to look for?
21:33 chromatic 'cuz I read your diffs, but didn't entirely follow them.
21:33 Coke hurm?
21:33 purl Yes, Rorschach.
21:33 Coke now I'm confused. which diffs?
21:33 dalek parrot: r38255 | Infinoid++ | trunk/config/auto/gmp/gmp_c.in:
21:33 dalek parrot: [config] Work around RT #50212, by disabling the win32 crash dialog for the test.
21:33 dalek parrot: It's still a strawberry issue and not a parrot one, but now it doesn't affect us, so I think this makes it closeable.
21:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38255/
21:33 dalek parrot: r38256 | Infinoid++ | trunk/config (2 files):
21:33 dalek parrot: [jit] Apply patch from he++ to make sure platform assembler helper files are preprocessed on NetBSD, by using the .S extension instead of .s.
21:33 dalek parrot: NetBSD pkgsrc apparently uses compiler wrappers which make this unnecessary, but this change is needed to fix standalone builds.
21:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38256/
21:34 chromatic You made several commits to clean up things, some type and signature declarations.
21:34 Coke Presumably I knew what I was doing at the time.
21:35 Coke I can review them in your branch if you like, but now's a bad time.
21:35 chromatic Do you remember which tests you were trying to make pass?
21:35 allison joined #parrot
21:35 allison fperrad: ping
21:36 Coke if I had a revision number, I could probably tell you.
21:36 Coke or a file?
21:37 chromatic Coding standards tests, I think.
21:37 Topic for #parrotis now Parrot 1.1.0 Released | http://parrot.org/ | 332 RTs left
21:37 Coke oh, no doubt.
21:38 chromatic svn: Working copy path 'docs/book/appb_patch_submission.pod' does not exist in repository
21:38 chromatic Joy.
21:38 fperrad allison, have you receive my email ?
21:38 chromatic That's almost enough to make me want to put on leather pants and let Git hit me in the head with a baseball bat again.
21:38 allison fperrad: yes, that's why I hopped on IRC
21:38 allison fperrad: did you get it sorted?
21:39 Coke renaming files is, according to a core svn developer, something you really want to do on trunk. when you have no branches.
21:39 allison (it doesn't work for me either)
21:39 Coke s/core svn developer/someone I met on #subversion/
21:39 Coke I assumed he was a developer.
21:40 Coke chromatic: if you don't have a lot of commits, it /might/ be easier (given the renames) to just replay them against trunk.
21:40 allison fperrad: I'm at the airport and about to hop on a plane
21:40 Coke gotta run.
21:41 bacek good morning
21:41 fperrad allison, not sorted
21:42 particle maybe i can help? what's broke?
21:42 allison fperrad: okay, looking into it
21:42 allison particle: the password to the FTP server
21:42 particle ah, hrmm.
21:43 darbelo joined #parrot
21:43 allison particle: I sent him the one from my password database, but not working
21:43 particle 530 This FTP server is anonymous only.
21:44 allison particle: it's used via ssh, not ftp
21:44 particle sigh.
21:45 fperrad chromatic, do you have account information about ftp-osl.osuosl.org
21:45 particle fperrad: i get access denied, too
21:45 particle time for a support ticket, i suppose
21:47 kid51 joined #parrot
21:47 allison particle: much appreciated, I'd do it but will be in the air for the next 2 hours
21:47 particle i'm sending ticket, copying francois
21:49 * allison has to board
21:49 particle safe flight
21:49 allison particle: thanks!
22:00 dalek parrot: r38257 | cotto++ | trunk/src/pmc/exceptionhandler.pmc:
22:00 dalek parrot: [PMC] remove ExceptionHandler's destroy, as the inherited one does the same thing
22:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38257/
22:02 cotto chromatic, when are you planning on merging headercleanup?
22:02 chromatic If and when SVN lets me.
22:03 particle if you're using svn 1.5, it should be less painful
22:03 particle ...if it was also used to create the branch.
22:04 chromatic 1.5.1, yep
22:05 otto joined #parrot
22:05 particle svn merge --reintegrate https://svn.parrot.org/par​rot/branches/headercleanup
22:06 chromatic Trying that.
22:09 dalek website: fperrad++ | Parrot 1.1.0 "Half-moon Conure" Released!
22:09 dalek website: http://www.parrot.org/news/2009/Parrot-1.1.0
22:10 chromatic Some revisions have been merged under it that have not been merged into the reintegration target; merge them first, then retry.
22:10 chromatic This is clearly not something I'm going to accomplish before lunch.
22:15 fperrad Infinoid, on website,
22:15 fperrad I can't found "Publishing options"
22:15 fperrad See release_manager_guide item 10.d
22:15 fperrad I have no access to "Administer" -> "Site building" -> "URL Redirects"
22:15 fperrad See release_manager_guide item 10.e
22:17 otto I have some thoughts on versioning of modules as related to perl dist/mods/namespaces etc
22:17 otto see http://perlmonks.org/?node_id=758791
22:18 otto is it the responsiblity of parrot to read the bytes off disk prior to lexing'parsing?
22:18 dalek parrot: r38258 | cotto++ | trunk/src/pmc.c:
22:18 dalek parrot: [PMC] call a PMC's destroy VTABLE function before reusing it
22:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38258/
22:20 moritz otto: what part of parrot are you refering to?
22:20 moritz otto: compilers that use parrot as a backend may do everything they want
22:21 moritz though I think that PCT based compilers first read the whole string
22:21 otto is there a nice pic of where parrot fits in the process?
22:21 otto bottomline is if someone want to always calc a hash of the file that was being loaded, where would it be best done?
22:22 otto you're reading the bits to parse, why not calc the hash at that time?
22:22 moritz sure, that makes sense
22:23 otto issue leads to what is a 'version' of perl mods v. dist containing mod leads to why have a version on a mod part of dist
22:24 otto so then you simply want a good id of a mod, and something in the mod to get to the dist version which contained it
22:24 moritz I think that a single version for a distribution should be enough
22:24 otto so a hash of the mod is a good start, kinda like git
22:24 otto i agree on the single version number for a whole dist...
22:24 dalek parrot: r38259 | cotto++ | trunk/src/pmc.c:
22:24 dalek parrot: [PMC] shuffle statements around so comments still make sense (no functional changes)
22:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38259/
22:25 otto i started a discussion at http://perlmonks.org/?node_id=758791 and some related problems with versioning each mod
22:26 moritz and I answered, yes ;-)
22:26 otto ah thx
22:27 Infinoid fperrad: did that help?
22:30 fperrad Infinoid, thank, now, www.parrot.org is OK
22:31 Infinoid ok, great.  sorry about the delay, I'm still at work
22:32 moritz fperrad++ Infinoid++
22:32 Infinoid I can fix the release/current redirect if you want
22:33 bacek cotto: around?
22:34 fperrad Infinoid, yes
22:35 NotFound "For all the suggestions I've heard the past years to change the CPAN VERSION handling, yours is the most insane. By a long shot." --> Nice comment ;)
22:35 bacek purl: msg cotto Ignore my comment on #46703.
22:35 purl Message for cotto stored.
22:36 Infinoid fperrad: I will update it as soon as I see the new version on the ftp site
22:43 Infinoid particle: FYI, sounds like the release manager guide requires the drupal "poster" bit for most of it, the "editor" bit for section 10.d and the "admin" bit for 10.e
22:45 Limbic_Region joined #parrot
22:58 tetragon joined #parrot
22:58 dalek parrot: r38260 | cotto++ | trunk/src/pmc/string.pmc:
22:58 dalek parrot: [PMC] remove workaround that's no longer needed
22:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38260/
22:58 cotto bacek, will do
23:11 dalek parrot: r38261 | whiteknight++ | trunk/src (3 files):
23:11 dalek parrot: a fix for TT #218. Use elements() and get_pointer() VTABLEs in the sort() method, so that it can be properly used by subclasses. Also, modify the semantics of the get_addr opcode to consistently return the memory address of the PMC, instead of returning whatever value get_pointer was returning (which is not consistent for all PMCs)
23:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38261/
23:12 dalek rakudo: 50f6111 | (Moritz Lenz)++ | src/setting/Match.pm:
23:12 dalek rakudo: handle quantified captures in Match.perl
23:12 dalek rakudo: Actually this works only decently for named (and not positional) captures
23:12 dalek rakudo: because of another rakudobug (RT #64952).
23:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​0f6111550cdf341fee85e3ed0bd04f4dec936bf
23:12 shorten dalek's url is at http://xrl.us/bept7j
23:22 dalek rakudo: 581f573 | (Stephen Weeks)++ | src/parser/actions.pm:
23:22 dalek rakudo: Migrate actions.pm to use .ast instead of $()
23:22 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​81f5735e9271bbac8de8d229c7efbb26677bb55
23:22 shorten dalek's url is at http://xrl.us/bept8t
23:28 particle1 joined #parrot
23:33 Infinoid Is there any reason not to enable optimization for core_ops_*.c if the compiler is gcc?  Andy D has provided a patch (TT #571) which does so, and cleans up the (currently unhandled) core_ops_cgp.c case.
23:41 dalek parrot: r38262 | whiteknight++ | trunk/src (3 files):
23:41 dalek parrot: undo the last commit because it exposes an error elsewhere that I didn't see. Posted a message to TT #213 to explain the problem and propose a solution
23:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/38262/
23:44 dalek tracwiki: v9 | Infinoid++ | ParrotQuotes
23:44 dalek tracwiki: Moar quotes.
23:44 dalek tracwiki: https://trac.parrot.org/parrot/wiki/P​arrotQuotes?version=9&amp;action=diff
23:44 shorten dalek's url is at http://xrl.us/bepua5
23:47 dalek tracwiki: v10 | Infinoid++ | ParrotQuotes
23:47 dalek tracwiki: You missed a spot.
23:47 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=10&amp;action=diff
23:48 shorten dalek's url is at http://xrl.us/bepubu
23:58 dalek rakudo: 2665575 | (Stephen Weeks)++ | src/parser/actions.pm:
23:58 dalek rakudo: Fix actions.pm by replacing .ast() with .ast
23:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​66557519b67bd77107992ab0a08543a140141c2
23:58 shorten dalek's url is at http://xrl.us/bepucv
23:59 fperrad particle, we've an answer

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

Parrot | source cross referenced