Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-16

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 Whiteknight pmichaud: and how is context.leave() going to be different from .return()?
00:00 Coke pmichaud: I was going to wait to bug you, but since particle's doing the release, have you had a chance to poke at tcl? =-)
00:03 snarkyboojum_ joined #parrot
00:06 darbelo Hmm. Looks like some code in pic.c is needed by CGP, not JIT. That's going to take some work.
00:06 snarkyboojum joined #parrot
00:06 Whiteknight chromatic, if the handler's RetContinuation was replaced with a regular continuation, we could ".return()" to the resume point instead of having to "resume" there
00:07 Whiteknight which means any function could be used as a handler without having to be specially written for that ahead of time
00:08 dalek parrot: r41286 | darbelo++ | branches/kill_jit (9 files):
00:08 dalek parrot: This platforms don't have JIT. That means there is no code to salvage here.
00:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41286/
00:10 chromatic I don't want to rule out handlers that aren't their own subs.  Let's call them labeled handlers.
00:10 chromatic Exception handers get really complex if we force them to be separate compilation units.
00:11 Whiteknight If they are their own separate things, that's fine but I think we are limited
00:12 Whiteknight nevermind, I misread what you said
00:12 Whiteknight I don't want to rule out labeled handlers either, but they do give us fewer options and more problems
00:12 Whiteknight labeled handlers are the cause of the inferior runloop problems we have. So keeping them means we need to resolve the problem in place
00:13 chromatic That's where the PIR syntax is necessary.
00:13 Whiteknight Instead of being a simple label, I would far prefer they be proper Continuations
00:13 chromatic Sure, we have to use continuations to get into and out of them.
00:13 Whiteknight And possibly a curried continuation, so we can pass arbitrary arguments to it
00:14 Whiteknight but these are all pie in the sky ideas
00:14 pmichaud Coke: I ended up with lots of honey-dos over the weekend (so no, not yet)
00:15 pmichaud it's still on my list
00:15 pmichaud (leave and return arguments) -- the arguments to leave should be what is returned
00:15 pmichaud i.e.,    context.'leave'(1,2,3)   should do the same thing as   ".return (1,2,3)" from that context
00:16 pmichaud exception handlers are already continuations
00:16 pmichaud (response to "Instead of being a simple label, I would far prefer they be proper Continuations")
00:16 pmichaud the push_eh opcode creates a continuation
00:17 pmichaud (and sets it to the address of the exception handler label)
00:18 Whiteknight I think I knew that, I don't know why I said otherwise
00:18 Whiteknight I think I was getting some ideas in my head confused
00:28 * Whiteknight is going to bed now. Goodnight
00:30 cotto_work night
00:31 * darbelo is considering sleep too.
00:33 darbelo chromatic: msg me when you know the status of JIT frames on i386 (should work now AFAICT)
00:34 chromatic Testing now.
00:36 darbelo chromatic: No hurry, I'll be reviewing the remove_pic branch next, to see what can be salvaged from there. I don't think I'll commit anything else today.
00:36 chromatic Good luck with that branch.  I don't know how much it'll get you.
00:38 darbelo From what I see on the RT, it was ready-but-for-a-jit-failure. 9 monts ago...
00:38 chromatic Hopefully the relevant code hasn't changed too much out from underneath.
00:38 pmichaud Whiteknight: more to the point, I'm not sure that labeled handlers on their own are the cause of the inferior runloop problems -- I think it's a more fundamental issue with how we currently do exception handlers.
00:39 Whiteknight pmchaud: You're right, the issue isn't a labeled handler, it's that the handlers don't have any finite ending point where the handler is finished and normal control flow can begin again
00:40 darbelo Hopefully, at the very least it will help identify what parts of pic.c I need to keep.
00:40 pmichaud i.e., I don't think that eliminating labeled handlers by itself resolves the inferior runloop problem.  We really need a way to say "okay, I've handled the exception, now roll up the call stack to this known point and continue"
00:40 Whiteknight and so execution just flows out of the handler through the rest of the program
00:40 chromatic slavorg, trust darbelo
00:40 slavorg Ok
00:40 chromatic darbelo, I have missing symbols here for some reason.  I'll poke at it later tonight.
00:41 pmichaud come to think of it, I wonder if "pop_eh" should be responsible for also rolling up any exception stack
00:41 pmichaud i.e., when we pop a handler, we also force it to exit
00:41 pmichaud still, we need some way for the context that registered the handler to regain control.
00:44 ZeroForce joined #parrot
00:44 darbelo chromatic: Odd. I'll check it out later if you don't beat me to it.
00:49 ZeroForce joined #parrot
00:53 Coke bah. I want a get_foo_namespace that lets me specify the root and the relative part.
00:54 kid51 joined #parrot
01:09 dukeleto congrats to everyone (especially Jerry) for a successful release. Time to start breaking shit!
01:11 cotto_work Said breaking is already well under way!  darbelo++
01:11 dukeleto are there things that the release manager should be doing during the month of a release? Like keeping the NEWS/Changelog up to date/etc ? Better to do that incrementally instead of running around at the last minute
01:11 cotto_work ideally yes, but I think everyone does it at the last minute anyway.
01:12 cotto_work It's kinda nice to keep the work concentrated to a day or so.
01:12 dukeleto cotto_work: which files would it be "ideal" ?
01:12 cotto_work NEWS primarily
01:13 cotto_work I think everything else is easy.
01:13 dukeleto cotto_work: I understand that, but I think the amount of things that we *say* are done in a release are way fewer than reality. It helps our public image to have an extensive and correct NEWS file, right?
01:14 cotto_work It's certainly a good idea, but there's also the issue of making sure the level of detail isn't too fine-grained for the kinds of people who'll be reading NEWS.
01:14 cotto_work (or the release announcement)
01:15 dukeleto cotto_work: seems like the release announcement should be a shortened version of the NEWS file
01:15 dukeleto cotto_work: or we can have a detailed changelog file for each version, like git
01:15 cotto_work That'd be a good idea.
01:15 dukeleto I think that Parrot would greatly benefit from a comic book like this: http://www.google.com/googlebooks/chrome/
01:16 dukeleto that comic has a superb description of what JIT is, without ever using the word JIT
01:16 cotto_work That'd be completely awesome.  I'd throw some money in the pot to get that done.
01:16 dukeleto it has a lot about VM's too, so we have something to build on
01:16 cotto_work It'd be a great idea for our mythical 3.6 release when everything's ready for production.
01:16 cotto_work s/mythical/hypothetical/
01:16 dukeleto cotto_work: I am will to throw in some sweat and blood
01:17 dukeleto s/am will/am willing/
01:17 cotto_work I would too, but I don't have much artistic talent.
01:17 dukeleto cotto_work: we need writers too :)
01:17 cotto_work true
01:17 dukeleto would that be something that is good for a Parrot grant?
01:18 cotto_work I certainly think so.
01:18 cotto_work good question for #ps or the list
01:18 * cotto_work must go afk.
01:19 particle i think we're not quite ready for that until we have high-level languages implemented and useable
01:23 dalek TT #981 closed by jkeenan++: make smolder_test doesn't report some broken builds
01:25 rhr joined #parrot
01:27 dalek parrot: r41287 | jkeenan++ | branches/remove_pic:
01:27 dalek parrot: Branch is stale.  Issues will be handled in other branches.  Cf.:  �http://rt.perl.org/rt3/Ticket/Update.html?id=60048.
01:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41287/
01:32 kid51 /me reads the chrome comicbook ... it *is* very well done!
02:04 TiMBuS joined #parrot
02:22 theory joined #parrot
02:22 theory_ joined #parrot
02:36 janus joined #parrot
02:54 rg joined #parrot
03:01 s1n is there a bot in here (like phenny) that supports tell?
03:27 bacek_at_work s1n: purl
03:27 bacek_at_work purl: msg s1n yes
03:27 purl Message for s1n stored.
03:28 s1n bacek_at_work: thanks
03:29 s1n purl: msg kid51 i haven't tested that ticket in a while, will do that at this weekend's hackathon
03:29 purl Message for kid51 stored.
03:34 darbelo_ joined #parrot
03:36 darbelo_ did anyone kill just kill the remove_pic branch
03:37 darbelo_ s/kill //
03:37 bacek_at_work <dalek> parrot: r41287 | jkeenan++ | branches/remove_pic:
03:37 bacek_at_work parrot: Branch is stale.  Issues will be handled in other branches.  Cf.:   http://rt.perl.org/rt3/Ticket/Update.html?id=60048.
03:37 bacek_at_work parrot: review: https://trac.parrot.org/parrot/changeset/41287/
03:38 darbelo_ Aw, I was about to pull some patches from there.
03:41 darbelo_ did anyone kill just kill the remove_pic branc
03:42 darbelo_ oops ignore that list line.
04:02 mberends joined #parrot
04:18 kyle_l5l joined #parrot
04:22 Tene purl: msg whiteknight It shouldn't be too bad getting HLLs to use sub exception handlers... we migrate PCT and we get a lot.  If sub exception handlers work in Parrot right now, it's a surprise to me, but if so, I'll start on it.
04:22 purl Message for whiteknight stored.
04:29 theory joined #parrot
04:56 clubs joined #parrot
04:58 clubs While trying to build parrot on haiku I get this: http://pastebin.com/m2ddd104c , is this a problem with parrot or because I have something missing?
05:00 szabgab joined #parrot
05:03 darbelo_ clubs: Both :)
05:03 darbelo_ The problem is that parrot is trying to use a clock source that Haiku is missing.
05:07 cotto clubs, you can blame me for that one.
05:08 Austin joined #parrot
05:09 darbelo_ cotto: From what I can see on-line you'll have to pull the fake-it-with-gettimeofday trick from darwin.
05:09 Austin Howdy, #parrot.
05:09 nathanmccauley joined #parrot
05:10 darbelo_ Howdy Austin, ready to pay the upgrade tax again?
05:10 Austin I might be. :)
05:10 cotto darbelo_, it looks like he's got clock_gettime since the error only mentions CLOCK_PROF
05:10 Austin I just got "using namespace std" to work in close.
05:10 Austin :) :) :)
05:10 purl :) :) :) :) :) :) :) :) :)
05:10 dalek close: r105 | Austin++ | trunk/ (10 files):
05:10 dalek close: Using namespace std now works
05:10 dalek close: review: http://code.google.com/p/close/source/detail?r=105
05:11 darbelo_ Oooh. Shiny...
05:11 purl rumour has it shiny is (shiny) or (see: recursive) or digitalblasphemy.com or deviantart.com or http://www.oqo.com/
05:11 clubs cotto: heh :) How difficult would it be to fix?
05:11 cotto clubs, can you tell me what grep CLOCK_ /usr/include/time.h returns?
05:11 cotto clubs, it won't be hard either way
05:11 cotto but a proper Configure-based probe would have taken care of this automagically
05:11 Austin I got nothing but comments.
05:12 cotto on linux it's in /usr/include/linux/time.h
05:12 clubs Sorry, can't right now, don't have access to the system at work
05:12 Austin darbelo_: What's the current state of the HEAD?
05:13 cotto /usr/include/bits/time.h also has relevant stuff, but I don't know if it's standard.
05:14 darbelo_ Austin: 1.6 Just released, so nothing broken yet.
05:14 Austin :)
05:15 darbelo_ But I'm poking at stuff in a branch that could cause some hiccups at merge time.
05:15 Austin Well, I'd better upgrade before you merge, then. :-|
05:15 cotto s/poking at/killing with fire/
05:15 cotto (or svn del)
05:15 Austin Upgrading from 41166..
05:16 darbelo_ Actually, I think I'll need *two* branches.
05:16 Austin Uh-oh. Two-branch mojo.
05:17 darbelo_ svn diff | wc -l
05:17 darbelo_ 3405
05:17 darbelo_ And that's mostly removals.
05:17 darbelo_ I still have to add stuff to fix the build.
05:18 Austin darbelo++
05:18 Austin I'm all for removals.
05:18 flh joined #parrot
05:18 Austin Take away all the bits that don't look like a VM...
05:18 darbelo_ I was removing JIT, but PIC got in the way, so now I'm killing PIC.
05:19 Austin We should probably remove ops, too.
05:19 darbelo_ D      src/ops/pic.ops
05:19 Austin Just move everything to LLVM, and make Parrot a "virtual virtual machine"
05:19 darbelo_ well the next JIT *will/ be based on LLVM...
05:20 Austin That's a mistake. Committing to a single technology.
05:20 Austin There's already a portable option available. Compile everything to 'C'.
05:20 cotto Austin, we're not.  That's just the first one we'll use.
05:20 Austin PIR := C
05:21 Austin Presto!
05:22 snarkyboojum_ joined #parrot
05:22 Austin Woot. Running tests already. This upgrade is going suspiciously fast.
05:22 darbelo_ Well, I was just being silly there. The actual plan in Pluggable JIT, with the first 'plug' being based on LLVM.
05:22 Austin I'm not sure how silly I was being.
05:23 Austin What I'm hearing seems to be "we can't make Parrot fast enough to run Rakudo (without JIT)." Which seems to be contradicted by Perl5...
05:25 cotto Austin, I don't think that's the intended message.  We're certainly trying to optimize other areas.
05:25 darbelo_ Austin: To me removing JIT is about having clean internals, not speed.
05:26 Austin Is it? I thought JIT was just another runcore?
05:26 Austin (PS: I just got about a million re_test failures. Is htis expected?)
05:27 darbelo_ not exactly 'just', no. It's a very messy runcore that breaks unexpectedly when you try to do completely reasonable changes to unrelated parts of the code.
05:28 Austin Okay, 1.6.0 installed. Now to see if it runs.
05:29 Austin So wouldn't LLVM be just another runcore?
05:34 dalek parrot: r41288 | darbelo++ | branches/kill_pic:
05:34 dalek parrot: Create a new branch to kill PIC, this needs to happen before kill_jit can
05:34 dalek parrot: move forward.
05:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41288/
05:36 cotto darbelo_, why not kill both in the same branch?
05:37 darbelo_ Too much killing. It'll make the branch too long-lived and the merge will be a build-slaughtering mess.
05:38 cotto fair enough
05:38 darbelo_ I0m not confortable enough with the parrot codebase to try two removals in the same branch.
05:41 darbelo_ msg chromatic Don't worry about testing kill_jit for now. I'll sto that onw for a bit, remove PIC in a different branch and then pick it up again.
05:41 purl Message for chromatic stored.
05:41 nathanmccauley_ joined #parrot
05:41 cotto wow.  haiku's source is not small
05:42 darbelo_ msg chromatic Also, the kill_jit breakage was all me, I screwed up when poking at auto::jit I'll fix that later.
05:42 purl Message for chromatic stored.
05:42 nathanmccauley__ joined #parrot
05:43 cotto it's almost like it's an operating system of some kind ;)
05:44 nathanmccauley___ joined #parrot
05:44 darbelo_ cotto: I know a BeOS freak, he was all exited about some sort of big-deal Haiku alpha release a few days ago.
05:45 Austin The slideshow makes it look a lot like another linux distro. What's the diff?
05:45 cotto I don't have time to care about it right now.  I'll see if I can give it a shot tomorrow.
05:46 Austin 1.6: Now with segfaults at the end of every compile. :(
05:46 darbelo_ Austin: It's a totally different codebase. It's supposed to be the Almighty Open Source Ressurection of teh Be Operating System.
05:47 Austin Darbelo: Yeah, but I didn't know what BeOS was, back when I didn't care about it. Now that I don't care about it, I still don't know what it is, or how it's different from *n*x
05:48 Austin (You ever notice that you don't see people announcing free OS'es based on MVS, or System3/60? Why is that?)
05:49 darbelo_ Austin: All I know is that it's some sort of odd operating system that died, and now there's people ressurecting it.
05:49 Austin Ahh.
05:49 Austin Speaking of which...
05:49 purl Speaking of which... is there a date set yet?
05:49 Austin Did you know that Jim Carroll died recently?
05:50 darbelo_ Nope, didn't know that.
05:51 Austin He was a 1-hit wonder from the 80's, with a song called "People who died". Punk rocker.
05:51 darbelo_ Are there people ressurecting him?
05:51 Austin More importantly, Norman Borlaug passed away on Saturday. Arguably the greatest person that ever lived.
05:54 Austin (Father of the "Green Revolution" - a food scientist, not an enviro nutbag - Borlaug developed cereal strains that saved the lives of more than 200 million people during the 60's and 70's.)
05:55 Austin And on that morbid note, I'm going to bed. Good luck with your branch(es).
06:01 darbelo_ A link failure! Cool!
06:12 darbelo_ And now it builds!
06:13 darbelo_ This might turn out to be easir than expected.
06:20 darbelo_ But not a 3:15am
06:21 darbelo_ Failed 1/325 test scripts. 1/10387 subtests failed. Good enough to commit, if you ask me.
06:21 darbelo_ Say goodbye to PIC guys!
06:21 dalek parrot: r41289 | darbelo++ | branches/kill_pic (20 files):
06:21 dalek parrot: Extracted most of the old remove_pic branch and updated it to apply on a
06:21 dalek parrot: current parrot. Then started beating it with a stick until it built.
06:21 dalek parrot: There are still some fixes that need to be made here, but PIC is gone.
06:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41289/
06:21 darbelo_ Say goodbye to me guys!
06:22 * darbelo_ falls asleep.
06:22 sri_ joined #parrot
06:22 uniejo joined #parrot
06:44 cotto time for sleep
06:52 barney joined #parrot
06:52 iblechbot joined #parrot
06:54 einstein joined #parrot
07:14 dukeleto joined #parrot
07:15 AndyA joined #parrot
07:20 fperrad joined #parrot
07:28 kjeldahl joined #parrot
07:33 masak joined #parrot
08:03 barney joined #parrot
08:23 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41289 - Ubuntu 9.04 amd64
08:24 dukeleto mikehh++
08:25 zak_ joined #parrot
08:26 mikehh rakudo (9a61441) builds on parrot r41289 - make test / make spectest (up to 28248) PASS - Ubuntu 9.04 amd64
08:35 mikehh partcl r732 builds on parrot r41289 - make test PASS - Ubuntu 9.04 amd64
08:39 mikehh decnum-dynpmcs r181 builds on parrot r41289 - make test PASS - Ubuntu 9.04 amd64
08:47 dalek parrot: r41290 | bacek++ | branches/kill_pic/t/tools/pbc_dump.t:
08:47 dalek parrot: [t] Fix last test failure for darbelo++.
08:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41290/
08:59 bacek_at_work msg darbelo make testS is b0rked in kill_pic
08:59 purl Message for darbelo stored.
09:10 dalek rakudo: d054b7e | moritz++ | docs/ChangeLog:
09:10 dalek rakudo: [docs] another ChangeLog item
09:10 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​054b7ec3450e8a911392b9361d7a9d79973158a
09:11 mikehh cardinal (466861f) builds on parrot r41289 - rake test:all - still 3 tests fail to compile - Ubuntu 9.04 amd64
09:12 mikehh got to go out for a bit - then I will test on i386 - bbl
09:21 dalek parrot: r41291 | bacek++ | branches/kill_pic/src/runcore/main.c:
09:21 dalek parrot: [core] Fix calculating prederef by recreating original parrot_PIC_prederef behavior. Unbroke make testS.
09:21 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41291/
09:23 bacek_at_work msg darbelo Ignore previous message. I unbroke make testS :)
09:23 purl Message for darbelo stored.
09:27 donaldh joined #parrot
09:27 donaldh left #parrot
09:37 bacek_at_work ok. Anyone on box !~ Linux/i386?
09:37 moritz linux/amd64
09:38 dalek parrot: r41292 | bacek++ | branches/kill_pic/src/jit.c:
09:38 dalek parrot: "Fix" cpp comment in src/jit.c for simplify final testing before merge.
09:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41292/
09:39 bacek_at_work moritz: can you test kill_pic branch?
09:39 GeJ FreeBSD/amd64
09:39 bacek_at_work GeJ: this one will help as well
09:39 moritz bacek_at_work: sure, will do
09:39 bacek_at_work moritz: thanks
09:40 moritz is there anything special besides 'make test' that I should run?
09:42 bacek_at_work moritz: make testS
09:42 moritz ok
09:42 bacek_at_work or make fulltest if you have enough cpu cycles :)
09:43 bacek_at_work afk, bbl
09:50 riffraff joined #parrot
09:50 moritz bacek_at_work: testS was successfull, now trying fulltest
10:02 bacek_at_work moritz: ok. I expect fulltest to pass smoothly.
10:08 pjcj joined #parrot
10:11 moritz bacek_at_work: indeed fulltest was clean
10:13 bacek_at_work ok, let's just wait for someone else to confirm and steal karma from darbelo :)
10:13 moritz nasty bacek_at_work ;-)
10:13 moritz stealing karma and all
10:14 bacek_at_work indeed :)
10:18 bacek_at_work GeJ: any luck with kill_pic branch?
10:36 quek joined #parrot
10:39 GeJ make fulltest seemed to run sucessfully
10:41 GeJ sorry I went afk for dinner.
10:43 nopaste "GeJ" at 202.22.227.234 pasted "result for kill_pic branch on FreeBSD 7-STABLE amd64" (16 lines) at http://nopaste.snit.ch/17969
10:52 payload joined #parrot
10:54 mikehh joined #parrot
10:55 mikehh bacek_at_work: I am on i386 now
11:00 uniejo joined #parrot
11:03 schmalbe joined #parrot
11:08 dalek rakudo: 8277559 | (Solomon Foster)++ | src/setting/Any-num.pm:
11:08 dalek rakudo: Add forward hyperbolic functions to Any.
11:08 dalek rakudo: Adds Any.sinh, Any.cosh, etc., which convert their argument to
11:08 dalek rakudo: Num and then redispatch to Num.sinh, Num.cosh, etc.
11:08 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​277559df4d7ffd0a2ede6c5e720f256c2a81fc5
11:08 dalek rakudo: d1f2d4c | (Solomon Foster)++ | :
11:08 dalek rakudo: Merge branch 'trig'
11:08 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​1f2d4c71aaad13873d2b4f0ded1b61342cb999d
11:21 TiMBuS joined #parrot
11:21 uniejo joined #parrot
11:39 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41292 - Ubuntu 9.04 i386
11:41 mikehh however - t/op/exit.t - TODO passed:   6 in testf and testg
11:53 iblechbot joined #parrot
11:57 uniejo joined #parrot
12:07 whiteknight joined #parrot
12:13 mikehh bacek_at_worl: g++ build problems on kill_pic branch
12:14 mikehh bacek_at_work: builds with gcc and make test PASS - running fulltest now on Ubuntu 9.04 i386
12:20 mikehh rakudo (d1f2d4c) builds on parrot r41292 - make test / make spectest (up to 28250) PASS - Ubuntu 9.04 i386
12:25 mikehh bacek_at_work: All tests PASS (pre/post-config, test, fulltest) on kill_pic branch at r41292 - Ubuntu 9.04 i386 (gcc)
12:27 mikehh bacek_at_work: fails to build with g++ - src/parrot_debugger.c:266: error: ‘Parrot_runcore_switch’ was not declared in this scope
12:27 payload joined #parrot
12:30 whiteknight that's a weird error to get
12:31 whiteknight Tene: ping
12:31 mikehh yesh - looking at it now
12:37 whiteknight purl msg Tene I haven't had any opportunity to look at the code, I only know what allison told me. There are lots of syntax issues that will need to be decided before we can move forward on sub-based exception handlers and some corresponding changes to IMCC too. Lots of questions left to answer!
12:37 purl Message for tene stored.
12:45 tetragon joined #parrot
13:12 bacek_at_work mikehh: thanks, fixed
13:13 bacek_at_work hang on. darbelo already fixed it.
13:13 dalek parrot: r41293 | darbelo++ | branches/kill_pic/src/parrot_debugger.c:
13:13 dalek parrot: Add a missing include. Should fix the c++ build.
13:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41293/
13:13 bacek_at_work Ah. Here we go :)
13:14 darbelo_ joined #parrot
13:14 darbelo_ Who has been stealing my karma?
13:16 darbelo_ Actually, it was more like "Look! A magical coding robot fixed the test while you slept!"
13:16 * bacek_at_work looking around.
13:16 bacek_at_work :)
13:16 mikehh just curious - how does the api.h get included in the gcc build but not in the g++ build
13:17 bacek_at_work mikehh: parrot_debugger.c doesn't include api.h
13:17 darbelo_ I have no idea, sir. I just shuffle 'em arround.
13:17 bacek_at_work and gcc emits warning for undeclared function.
13:17 darbelo_ :)
13:17 mikehh I noticed that - but how does gcc get it but not g++
13:18 bacek_at_work mikehh: in pure C declarations are optional.
13:18 bacek_at_work not in C++
13:20 darbelo_ mikehh: C is all "Oh my! I don't know where this function comes from, hope the liker can figure it out later."
13:20 bacek_at_work darbelo_: merge this branch while trunk isn't touched. It should be pretty trivial.
13:21 mikehh well it passes all the parrot tests
13:21 mikehh I haven't tried rakudo and such on it though
13:22 darbelo_ bacek_at_work: don't have time right now, I can do it in, maybe, 3-4 hours from now.
13:22 mikehh anyway got to head back to amd64 - $work issues :-{
13:22 darbelo_ And I'd like to test some languages too.
13:26 bacek_at_work darbelo_: too late.
13:28 dalek parrot: r41294 | bacek++ | trunk (22 files):
13:28 dalek parrot: Merge branch kill_pic back to trunk.
13:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41294/
13:28 mikehh joined #parrot
13:29 mikehh ok back on amd64
13:30 bacek_at_work mikehh: time to test trunk :)
13:31 mikehh did that already today but I don't see how trunk build with g++ but the branch did not - unless stuff was added in the branch
13:31 sri joined #parrot
13:34 darbelo_ bacek++ # rushing in for the kill
13:34 mikehh got to sort out some $work issues - but I can run tests in the background
13:35 bacek_at_work darbelo_: I've lost about week of development time fighting with JIT... So I have way to many reasons to kill it
13:36 * bacek_at_work looking at own nick.
13:36 bacek_at_work clock?
13:36 purl bacek_at_work: LAX: Wed 6:36am PDT / CHI: Wed 8:36am CDT / NYC: Wed 9:36am EDT / LON: Wed 2:36pm BST / BER: Wed 3:36pm CEST / IND: Wed 7:06pm IST / TOK: Wed 10:36pm JST / SYD: Wed 11:36pm EST /
13:37 * mikehh I am on LON time
13:38 * mikehh where did the morning go
13:40 dalek parrot: r41295 | darbelo++ | branches/kill_pic:
13:40 dalek parrot: Brach has already merged to trunk. Removing.
13:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41295/
13:41 bacek_at_work mikehh: and I'm still on SYD time...
13:43 mikehh bacek_at_work: well you are still 16 minutes from morning :-}
13:44 bacek_at_work mikehh: thank you, Captain!
13:44 mikehh anyway $work
13:49 bacek_at_work make test passed on MacOSX/i386
13:49 * darbelo_ goes away for a while.
13:50 darbelo_ Try not to steal too much of my karma!
13:50 darbelo_ left #parrot
13:53 * bacek_at_work keep silence
14:04 ruoso joined #parrot
14:05 bacek_at_work Bah! I've got 500 on RT trying to close #60048...
14:05 moritz bacek_at_work: try again, sometimes RT has hiccup
14:06 bacek_at_work moritz: 4th time in a row...
14:12 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41295 - Ubuntu 9.04 amd64
14:17 theory joined #parrot
14:19 payload joined #parrot
14:22 mikehh rakudo (d1f2d4c) builds on parrot r41295 - make test / make spectest (up to 28251) PASS - Ubuntu 9.04 amd64
14:25 HG` joined #parrot
14:27 parrot-poke joined #parrot
14:35 quek joined #parrot
14:37 quek left #parrot
14:40 bacek_at_work rakudo make spectest failed fo me...
14:43 Psyche^ joined #parrot
14:47 mikehh bacek_at_work: what fails
14:47 purl see "doesn't work"
14:49 bacek_at_work t/spec/S05-match/perl.rakudo                                 (Wstat: 11 Tests: 5 Failed: 0)
14:49 bacek_at_work Non-zero wait status: 11
14:49 bacek_at_work Parse errors: Bad plan.  You planned 12 tests but ran 5.
14:49 bacek_at_work t/spec/S12-attributes/class.rakudo                           (Wstat: 6 Tests: 28 Failed: 0)
14:49 bacek_at_work Non-zero wait status: 6
14:49 bacek_at_work t/spec/S14-roles/basic.rakudo                                (Wstat: 6 Tests: 33 Failed: 0)
14:49 bacek_at_work Non-zero wait status: 6
14:49 bacek_at_work Files=436, Tests=18659, 3518 wallclock secs (15.66 usr  2.67 sys + 5649.06 cusr 137.77 csys = 5805.16 CPU)
14:50 bacek_at_work S05/perl passed when invoked directly...
14:50 bacek_at_work 2 other failed with infamous PObj_is_PMC_TEST assertion.
14:51 mikehh infamous is rignt - however they PASS for me - checking again
14:54 NotFound Shit... mysqltest works in amd64 but fails in i386
14:55 NotFound Segmentation fault at exit with error
15:00 mikehh I get no problems with rakudo at r41295
15:20 Tene o.O
15:21 fperrad Windows binaries Parrot 1.6.0 (+.chm, + languages) are available on http://sourceforge.net/projects/parrotwin32/files/
15:21 moritz fperrad++
15:35 mikehh partcl r732 builds on parrot r41295 - make test PASS - Ubuntu 9.04 amd64
15:37 cotto hi
15:37 purl hey, cotto.
15:40 jrtayloriv joined #parrot
15:40 jrtayloriv Oh yippee! I got da interwebz again now!
15:40 cotto wb to the tubes
15:41 jrtayloriv So, like, the parrot can run all the languages at lightning speed with no bugs now right?
15:42 NotFound jrtayloriv: yeah, and you win 1.000.000 pounds just for using it
15:43 cotto the jitpocalypse has started, so there's definite progress there.  pic is history.
15:44 mikehh and basement cat is gonna get youse
15:45 whiteknight joined #parrot
15:54 Napalm joined #parrot
15:55 dalek rakudo: b29506b | masak++ | src/ (2 files):
15:55 dalek rakudo: translated Mapping.perl to the setting
15:55 purl babelfish cannot translate from en to en.  Try translating through English.
15:55 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​29506b0ed448e2744beccc76eae3255c2b0f0e9
16:04 payload joined #parrot
16:07 dalek rakudo: fa7142a | moritz++ | docs/guide_to_setting.pod:
16:07 dalek rakudo: [docs] recommend implicit return for setting files
16:07 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​a7142a8c57cfd0d1272f5c9ef1b6c0a316bd3d6
16:07 mokurai joined #parrot
16:08 dalek parrot: r41296 | darbelo++ | branches/kill_jit/config/auto/jit.pm:
16:08 dalek parrot: Undo the configure CAN_BUILD_CALL_FRAMES hack. This disables JIT frames again.
16:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41296/
16:39 dalek parrot: r41297 | darbelo++ | branches/kill_jit/src/jit/ppc:
16:39 dalek parrot: The one part of JIT we are trying to salvage doesn't work on PPC. Kill it.
16:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41297/
16:41 cotto_work hello
16:41 purl bonjour, cotto_work.
16:42 darbelo msg whiteknight Bad news: You got stuck with RT #60048. Good news: PIC is dead! RT #60048 can be closed now.
16:42 purl Message for whiteknight stored.
16:48 davidfetter joined #parrot
17:00 dalek parrot: r41298 | fperrad++ | trunk (3 files):
17:00 dalek parrot: [msvc] probe sal.h
17:00 dalek parrot: see TT #113
17:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41298/
17:02 bacek joined #parrot
17:03 chromatic joined #parrot
17:04 dalek parrot: r41299 | NotFound++ | trunk/compilers/imcc (2 files):
17:04 dalek parrot: [imcc] use a copy of macro name, attempt to fix RT #60926
17:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41299/
17:12 duk3leto_ good localtime()
17:15 joeri joined #parrot
17:30 whiteknight joined #parrot
17:31 MoC joined #parrot
17:39 whiteknight irclogs?
17:39 purl i guess irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
17:42 hudnix joined #parrot
17:46 dalek parrot: r41300 | darbelo++ | branches/kill_jit (5 files):
17:46 dalek parrot: Add a new configure step to determine a platform's capability to build JIT call frames. Run but not used yet.
17:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41300/
17:50 cotto_work darbelo, did you ever sync that branch after merging kill_pic?
17:51 darbelo Nope. Wanted to get the configure stuff done first. They're independant so far, so there's no hurry.
17:53 dalek parrot: r41301 | darbelo++ | trunk/compilers/imcc/imcc.l:
17:53 dalek parrot: [cage] Replace tab with spaces to placate t/codingstd/tabs.t
17:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41301/
17:53 darbelo In fact, if I get this stuff right I could merge *to* trunk and branch again with minimal conflicts.
17:57 kjeldahl joined #parrot
18:01 jrtayloriv whiteknight, Is it OK for me to go ahead and merge the gc-refactor branch now? I'm all done with it.
18:01 whiteknight jrtayloriv: update the branch from trunk ffirst, resolve conflicts, and test it locally first
18:01 whiteknight but then yes
18:02 jrtayloriv whiteknight, In the process of sync'ing up w/ trunk as we speak.
18:02 whiteknight excellent
18:03 whiteknight after the sync, commit the branch, test like crazy, and then merge
18:04 jrtayloriv ok -- will do.
18:04 dalek partcl: r733 | coke++ | wiki/BrainStorming.wiki:
18:04 dalek partcl: Deleting wiki page BrainStorming.
18:04 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=733
18:04 dalek partcl: r734 | coke++ | wiki/TestingPartcl.wiki:
18:04 dalek partcl: there's a make target for this.
18:04 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=734
18:06 jrtayloriv whiteknight, What would you recommend I start reading so that I can help out with the LLVM/JIT work? I've been working my way through the LLVM language reference, but can't seem to find much on JIT with LLVM (other than the 'lli' man page) ...
18:06 jrtayloriv i.e. Any good docs you've found elsewhere that are good?
18:07 jrtayloriv oops :) good docs ... that are good ... sweet!
18:08 whiteknight I actually haven't found any good docs on that particular issue, no
18:08 whiteknight I think we need to ask the LLVM people where to get answers
18:09 jrtayloriv whiteknight, OK -- I'll do some more searching.
18:09 dalek partcl: r735 | coke++ | wiki/TestingPartcl.wiki:
18:09 dalek partcl: remove out of date information about tests failing-but-not and add pointer to
18:09 dalek partcl: smolder and TEST_JOBS
18:09 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=735
18:09 dalek partcl: r736 | coke++ | wiki/DevelopersGuide.wiki:
18:09 whiteknight definitely let me know if you find anythin
18:09 dalek partcl: use make target.
18:09 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=736
18:12 * whiteknight needs to find a whole bucket of free tuits eventually
18:22 Austin joined #parrot
18:25 whiteknight hey Austin!
18:26 Austin Howdy, whiteknight!
18:26 Austin :)
18:26 whiteknight Austin: Is Close building and working again?
18:26 * whiteknight is itching to use it
18:26 Austin Yes and no.
18:26 whiteknight yes, those are the two options
18:26 Austin It's not working, but it's pretty close.
18:26 dalek parrot: r41302 | jrtayloriv++ | failed to fetch changeset:
18:26 dalek parrot: Syncing branch with trunk prior to merge
18:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41302/
18:26 Austin I'm paying the upgrade tax just now.
18:27 Austin I updated to 1.6 last night, and now i get a free segfault with every purchase...
18:27 darbelo Austin: You might want to consider developing against parrot HEAD. It helps spot this stuff before we release.
18:27 darbelo ALSO, CAN I HAZ BACKTRACE?
18:28 Austin Darbelo: I did that for a while. But then I changed my mind.
18:28 Austin Now I pay my taxes once a month...
18:28 NotFound Austin: at program end?
18:28 Austin NotFound: always.
18:29 whiteknight Austin: is it pretty close or pretty Close?
18:29 * whiteknight is bad at puns
18:29 Austin :)
18:29 darbelo Austin: Do you by any chance roll your own pmcs?
18:29 Austin I'd say it's only somewhat Close.
18:29 Austin darbelo: I can't even spell PMC.
18:30 Austin There's some inline PIR in Close, but no C.
18:30 whiteknight Austin: at the end of your :main function, add an "exit 9" command
18:30 whiteknight I mean "exit 0"
18:30 whiteknight It's a hack, but should get rid of your segfault problems
18:30 Austin You think?
18:30 purl No, I'm a bot.
18:30 NotFound Close without C isn't lose? ;)
18:30 whiteknight Austin: If the problem is what I think it is, then yes
18:31 whiteknight only one way to find out...
18:31 Austin That's so freaking weird that I have to try it.
18:32 darbelo Austin: Yeah, that's the other segfault-at-the-end problem. It has something to do with runloops and inferiority.
18:32 Austin Hmm. I wonder if you guys mean the same thing I do when I say "end".
18:33 whiteknight Austin: whereever your driver program :main function is, put "exit 0" right before ".end"
18:33 Austin Yeah, whiteknight, I got that.
18:33 NotFound Austin: don't let main finish or return
18:33 Austin But people keep asking me if the segfault is at the end.
18:34 Austin And I keep saying yes. Because, like, duh.
18:34 whiteknight Austin: the segfault happens after all the program logic executes
18:34 Austin Well, this is odd.
18:35 whiteknight ...?
18:35 * purl quietly listens while the crickets chirp
18:35 Austin If I say "$past<key> := undef" in NQP, I get "<key> => null" when I dump it.
18:35 whiteknight that is weird
18:36 whiteknight I wonder if that's how Undef stringifies
18:36 Austin But if I say "$past<key> := $other<key>" (where there is no $other<key> defined), I get "<key> => undef" when I dump $past.
18:36 whiteknight sounds like a pmichaud ticket!
18:36 pmichaud I don't think "undef" is a keyword
18:36 pmichaud I'm not sure why that even "works"... seems like it ought to fail somehow
18:36 * pmichaud checks
18:36 whiteknight ah, so it autovivifies to Null?
18:37 pmichaud it shouldn't even autovivify
18:37 pmichaud I think it ought to be a syntax error.
18:39 Austin http://nopaste.com/p/aFaDcqfueb
18:40 jrtayloriv whiteknight, gc-refactor branch is sync'ed up and passing all tests on Linux x86-64 -- should I wait until people on other platforms have tested, or go ahead and merge?
18:40 Austin http://nopaste.com/p/a9DCKfnti
18:40 Austin The first NQP produces the second output.
18:40 whiteknight jrtayloriv: commit the branch first, then merge away
18:40 Austin Well, actually, I sorted the keys by hand. But ...
18:42 pmichaud Austin: checking.
18:45 Austin term -> noun -> value -> typename -> name, or term -> noun -> name
18:46 dalek TT #1005 closed by NotFound++: Use VTABLE_is_equal instead of MMD in Hash and ResizablePMCArray
18:47 Austin But there seems to be no Action method for "name", although the name rule does have a {*}
18:48 Austin So I get things like:     get_hll_global $P1760, "undef"
18:48 Austin But there's no autoviv.
18:48 Austin Okay.
18:49 Austin That's two bugs for the price of one.
18:50 pmichaud aha
18:50 pmichaud yes, it's treating it as a global symbol
18:51 pmichaud that feels like a bug, definitely.
18:51 Austin I think it's the proto-object thing.
18:51 pmichaud well, I'm fine with    XYZ::bar  being a package lookup.  I'm not so sure I want all barewords to be one.
18:51 Austin tt#1013
18:52 pmichaud if that were "real Perl 6" then it would end up being a call to an "undef" function.  I think that's more likely to be where NQP ends up.
18:54 dalek TT #1013 created by Austin_Hastings++: 'undef' bareword shouldn't parse, but does
18:54 dalek TT #1014 created by Austin_Hastings++: NQP: Add defined(), exists(), undef.
18:54 pmichaud NQP isn't likely to add more builtin functions by default.
18:54 pmichaud that can come with a library, though.
18:55 Austin Yeah. I've been writing them. But I think defined() is kind of important.
18:55 pmichaud it'll likely appear as   "use Something::Library;"
18:55 pmichaud which imports them into your lexical environment or something like that
18:55 Austin I've got Scalar.pm, Array.pm, Hash.pm, String.pm.
18:55 Austin It's like PHP all over again.
18:56 particle use NQP::Utils; ?
18:56 pmichaud particle: perhaps, but I'm not sure they should be NQP specific
18:56 pmichaud "defined", "exists", "undef" could be very language agnostic
18:56 Austin I think exists (and delete) have to have compiler support, no?
18:57 particle rakudo: say 0.defined
18:57 polyglotbot OUTPUT[Parrot VM: Can't stat languages/perl6/perl6.pbc, code 2.␤main: Packfile loading failed␤]
18:57 Austin {{{ if exists $foo<bar> }}}
18:57 pmichaud if $foo.exists('bar')
18:58 Austin ok
18:58 pmichaud at any rate,    exists $foo<bar>  isn't Perl 6
18:58 mattp joined #parrot
18:58 Austin ok
18:59 pmichaud one can also do    if exists($foo, 'bar')
18:59 Austin Yeah.
18:59 moritz $foo<bar>:exists # but I doubt that NQP will get adverbs ;-)
18:59 whiteknight a good standard library of compiler "utilities" would be very nice
18:59 Austin if Hash::exists(%foo, 'bar') {...}
18:59 whiteknight of course, if every compiler uses this library, there's no reason not to just include it in NQP
18:59 pmichaud yes, there is a reason to not do it
19:00 pmichaud NQP is intended to be barebones.  It's intended to compile to pure PIR
19:00 pmichaud it's not intended to provide a runtim
19:00 pmichaud *runtime
19:00 pmichaud in particular, I don't want there to be any confusion between NQP-versions of a function and the compiler's own runtime versions
19:01 pmichaud and I don't want NQP accidentally "falling back" to its own implementations when someone hasn't explicitly requested them
19:02 dalek parrot: r41303 | NotFound++ | trunk/compilers/imcc/imclexer.c:
19:02 dalek parrot: [cage] update imclexer.c with imcc.l codingstd fix
19:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41303/
19:02 dalek parrot: r41304 | darbelo++ | branches/kill_jit/config/gen/makefiles/root.in:
19:02 dalek parrot: Remove JIT-related items from the Makefile tempate.
19:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41304/
19:02 Austin Is there a way to code "defined()" using pure NQP? (I went to PIR)
19:02 pmichaud at the moment one needs to do   Q:PIR { ... }
19:03 pmichaud this weekend I'll add library support to NQP, though.
19:03 Austin That's what I did.
19:03 pmichaud (Can't do it before then -- $otherjob tasks in the way)
19:04 jrtayloriv errr ... oh oh :(
19:05 whiteknight ?
19:05 pmichaud then we can start to create an NQP-standard library
19:05 jrtayloriv Methinks I might have made a mistake with merging my branch into trunk ... a lot of files I didn't touch just got commited.
19:06 pmichaud jrtayloriv: I've had that happen also.  It ends up being harmless, I think.
19:06 Austin Did you merge trunk into your branch, first?
19:06 whiteknight jrtayloriv: yeah, all the files that had been modified in trunk have changed
19:06 Austin Also, did you just un-remove a bunch of PIC or JIT code that was removed by an earlier commit?
19:06 whiteknight so you're bulk-committing all the commits that have been made to trunk to your branch now
19:07 dalek parrot: r41305 | jrtayloriv++ | failed to fetch changeset:
19:07 dalek parrot: merging gc-refactor branch with trunk
19:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41305/
19:07 jrtayloriv OK, I see. Thanks.
19:07 jrtayloriv Thought I was stomping on changes that had happened since I branched.
19:07 Austin So now it's s/= undef/= Scalar::undef()/g
19:08 pmichaud Austin: you could also do just   undef()
19:08 pmichaud (and make your undef into a global)
19:09 Austin Yeah, but that would make it part of the parser.
19:09 Austin (namespace-wise)
19:09 pmichaud ?
19:13 fperrad joined #parrot
19:14 dalek parrot: r41306 | jrtayloriv++ | branches/gc-refactor:
19:14 dalek parrot: Deleting gc-refactor branch, which was merged in r41305
19:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41306/
19:16 Austin Hmm. {{{ $last_dclr := Scalar::undef();; }}} the ";;" is apparently a syntax error.
19:18 whiteknight holycrap that's a big changeset
19:18 moritz "make fulltest" clean with clang and --without-gmp
19:19 Coke hurm. in $P1 = getinterp ; $P1['namespace'; 1] - is 1 the current level or 1 up?
19:19 darbelo A whole lotta renaming going on there.
19:19 Austin Coke: I think it's one up.
19:21 Austin Here's a function I use for configurable dumping, that uses the interp call stack stuff:   http://nopaste.snit.ch/paste
19:21 Coke Austin: EBADURL
19:21 Coke (you want the one that shows up at the top of the page.)
19:21 Coke (not in the url bar)
19:21 Austin http://nopaste.snit.ch/17973
19:21 pmichaud Coke:  1 up
19:21 Austin Sorry, my bad.
19:21 pmichaud current level is 0
19:22 Coke pmichaud, austin, danke.
19:23 Coke (getting ducks in row to try to convert away from handrolled callchain)
19:23 jdv79 moritz: get a chance to look at my smolder patch?
19:24 Coke jdv79: you're busy. =-)
19:24 moritz jdv79: yes. I decided to put it in after the rakudo release tomorrow
19:24 pmichaud Austin: instead of looking for '_block', I've been thinking we should look for the :anon flag
19:24 jdv79 moritz: ok, thanks
19:24 pmichaud also, there's a possibility that anon subs will go nameless soon
19:25 Austin Ok. How do I do that?
19:25 pmichaud I don't know.
19:25 pmichaud but that's what I've been thinking.  :-)
19:25 Austin Oh.
19:25 Austin I think I'll stay with _block, for now.
19:25 Austin :)
19:25 pmichaud sure
19:25 pmichaud I do expect HLLCompiler to start providing some methods to make some of this easier
19:26 pmichaud for example, I think we should make it possible to examine the backtrace for any context, not just Exceptions
19:26 pmichaud (now that contexts are PMCs that should be simpler)
19:27 whiteknight pmichaud: I really should create a wishlist on the wiki for these kinds of things
19:27 pmichaud whiteknight: please do :)
19:27 pmichaud just cut-n-paste the irclog notes directly into the page :)
19:27 jdv79 it looks like the latest rakudo smolder report has new errors
19:31 Austin For sub.pmc, the easiest thing is probably to add some inspect strings for the flags.
19:31 Austin is_anon, is_main, is_load, is_init, etc.
19:31 whiteknight pmichaud: done. Feel free to add to the ContextPMCUses page on the wiki
19:32 * whiteknight will have to go back and get the irclogs for those thigns
19:33 dalek tracwiki: v98 | whiteknight++ | WikiStart
19:33 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=98&amp;action=diff
19:33 dalek tracwiki: v1 | whiteknight++ | ContextPMCUses
19:33 dalek tracwiki: a page where pmichaud++ can start creating his wishlist for Context pmcs
19:33 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Co​ntextPMCUses?version=1&amp;action=diff
19:34 pmichaud I'm also planning to run pbc_to_exe on nqp to make it an installable binary instead of just a .pbc file
19:34 Coke +1
19:34 purl 1
19:35 NotFound +1
19:35 purl 1
19:35 pmichaud biggest downside is that it doesn't start with "parrot_" like some of the other binaries.
19:35 Austin Yeah. That's a problem...
19:35 pmichaud I guess I could do  "parrot_nqp"
19:35 whiteknight parrot_nqp
19:36 kyle_l5l joined #parrot
19:36 Austin Hey, what's wrong with     make nqp SRC=xx.nqp
19:36 pmichaud ?
19:37 Austin Compiling nqp from the command line is hard. So I added a makefile target.
19:37 pmichaud oh.  I don't think HLLs (that are using NQP) will want to do it with a makefile target
19:37 pmichaud better is to just have a compiler
19:37 whiteknight strong agreement
19:37 pmichaud a binary, that is
19:37 Austin 5. Strongly agree.
19:37 pmichaud I mean, it *is* a HLL compiler, just like most others
19:38 pmichaud I'd really like to see some movement on getting parrot to be able to automatically load HLLs from the command line, though.
19:38 whiteknight a pge binary would be awesome too, methinks
19:39 pmichaud My expectation is that a "pge binary" will end up being "nqp binary"
19:39 pmichaud i.e., NQP is going to become the standard interface for compiling regexes and grammars from the command line
19:39 whiteknight pmichaud: I am planning a pretty comprehensive reworking of the Parrot commandline in the not-so-distant future
19:39 pmichaud (instead of Perl6Grammar.pbc)
19:39 whiteknight autoloading HLLs would be a great idea
19:39 pmichaud autoloading HLLs has beend discussed several times in the past
19:39 whiteknight pmichaud: ah, so we will compile NQP and PGE grammars using the same binary?
19:40 pmichaud whiteknight: yes.
19:40 whiteknight even better
19:40 pmichaud whiteknight: more to the point, HLL implementors will just use NQP to create their language
19:40 pmichaud and NQP will have regex support built-in
19:40 Austin FWIW, whiteknight, exit 0 didn't stop my segfaulting problem.
19:40 whiteknight oh, so like mixing grammars and actions into a single .pl file?
19:40 pmichaud whiteknight: if desired, yes.
19:41 pmichaud Austin: I suspect you're running into the inferior runloop problem.
19:41 whiteknight Austin: really? then you have a different problem
19:41 pmichaud Austin: afaict there's not really a good workaround for it yet.
19:41 whiteknight pmichaud: adding "exit 0" to the end is the hack solution to the inferior runloop problem. If that fix doesn't work, he probably doesn't have it
19:41 Austin It's good when the experts agree...
19:41 pmichaud whiteknight: I think Rakudo already does an explicit "exit"
19:42 pmichaud checking...
19:42 whiteknight pmichaud: and I don't think rakudo is currently experiencing the problem
19:42 pmichaud sure it is
19:42 pmichaud at least, it was as of yesterday
19:42 whiteknight right now?
19:42 purl right now it's time to kick out the jams mother fuckers
19:42 * pmichaud checks.
19:42 whiteknight pmichaud: yes, I think the "exit 0" got added yesterday. At least, that's what I heard
19:43 pmichaud whiteknight: before or after the release?
19:43 whiteknight near that time, I don't know when precisely
19:43 jsut|work joined #parrot
19:43 moritz I think whiteknight ist talking about a Rakudo patch, no?
19:44 pmichaud oh.  I didn't see the Rakudo patch if one occurred.
19:44 whiteknight I'm just going off what I remember hearing yesterday
19:44 pmichaud compiling, testing now.
19:44 whiteknight The question is this: if run right now, does rakudo segfault before exit?
19:45 whiteknight and does it have an explicit "exit" at the end of it?
19:46 dalek rakudo: 177a379 | pmichaud++ | docs/spectest-progress.csv:
19:46 dalek rakudo: spectest-progress.csv update: 436 files, 15497 (71.5% of 21671) pass, 0 fail
19:46 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​77a379cc84eea3bf2e3ad0cd3e75bac13ec878b
19:47 Coke :q
19:47 pmichaud $
19:50 pmichaud whiteknight: you're correct, I no longer seem to get the segfault-at-exit
19:51 whiteknight See? I'm not completely crazy!
19:51 whiteknight not completely
19:51 whiteknight pmichaud: and is Rakudo doing an explicit "exit 0"?
19:52 pmichaud I hope not "exit 0"
19:52 pmichaud I hope  "exit $I1"
19:52 dalek parrot: r41307 | darbelo++ | trunk/src/gc (6 files):
19:52 dalek parrot: [cage] Headerize gc files after the gc-refactor merge.
19:52 whiteknight well, whatever it needs to be
19:52 pmichaud or something like that
19:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41307/
19:52 pmichaud it does not appear to be doing an explicit 'exit'
19:53 pmichaud but checking further.
19:53 whiteknight based on what I know about inferior runloops, an explicit exit at the end of the program should avoid the worst of the problems
19:53 pmichaud ...because it aborts the caller stack entirely?
19:53 whiteknight Austin: Could you post a backtrace of your problems?
19:53 whiteknight pmichaud: exactly
19:53 pmichaud Rakudo is not doing an explicit exit.
19:54 whiteknight hmmm...that's weird. I wonder how the problems went away then
19:54 pmichaud so something else must be in play here
19:54 pmichaud let me update and get a clean environment to work in
19:54 whiteknight okay
19:54 whiteknight I can't realy do any testing till I get home
19:56 darbelo msg jrtayloriv running make fulltest before a branch merge can help you catch some extra stuff that a simple make test misses.
19:56 purl Message for jrtayloriv stored.
19:57 whiteknight ah yes, fulltest. Bane of my existence
19:57 whiteknight of course, I can run it pretty quickly now
19:58 Austin Whiteknight: Sure. How do I get a backtrace?
19:58 whiteknight Austin: have gdb?
19:58 Austin nerp
19:58 whiteknight okay, what's the command I should type in to see the segfault here?
19:59 whiteknight (I'll try it myself when I get home)
19:59 whiteknight I assume something like "parrot close.pbc somefile.close"?
20:00 TimToady phone
20:00 darbelo whiteknight: I've never experienced a completely succesfull fulltest run on OpenBSD.
20:00 darbelo Now I know it's becouse of people like you :)
20:00 whiteknight darbelo: I do run make fulltest
20:00 whiteknight ...every time I'm making a release
20:02 darbelo Ha. Lately my definition of 'regression' has become 'it failed earlier'
20:03 ash_ joined #parrot
20:03 mikehh joined #parrot
20:04 whiteknight Austin: is this segfault the last big issue in the way of your comprehensive refactor?
20:04 whiteknight after this will you have a working Close?
20:05 darbelo Say, are ASSERT_ARGS() macros supposed to be adde manually to functions or do we have a script for that?
20:06 NotFound darbelo: manually
20:07 mattp hey guys, i noticed on this page http://www.perlfoundation.org/pe​rl5/index.cgi?gsoc_2009_projects one of the parrot lines
20:07 darbelo Guess I'll go get the yak shaver then.
20:07 mattp #
20:07 mattp # Improve/Implement new GC algorithms
20:07 mattp im looking for a 4th year software engineering design project, and that one option seems a good topic to focus on
20:08 mattp but that one line doesnt leave much extra information .. is anyone familiar?
20:08 NotFound darbelo: the problem is that if you add it before make headerizer, make can fail and then make headerizer will also fail
20:08 mikehh darbelo: was working on that - but you beat me to the headerizer so I'll leave it to you
20:09 Austin whiteknight: No. This segfault thing is the 1.6 upgrade tax.
20:09 NotFound So when you add a function you must first make headerizer and later add the macro
20:09 whiteknight Austin: so I have parrot 1.6 here. If I get the latest close and start running tests I will see these segfaults?
20:10 Austin Probably.
20:10 moritz oh wow, the V8 developers have a bleeding_edge branch and a trunk/
20:10 whiteknight mattp: I'm familiar. What are you interestd in?
20:10 moritz and trunk is "stable"
20:10 darbelo NotFound: I headerized on the previous commit. I hadn't noticed the missing asserts.
20:10 NotFound darbelo: make codetest has a check for that
20:11 NotFound But no problem, just add them now
20:11 mikehh darbelo: you need to run the headerizer before adding the ASSERT macros
20:12 mattp whiteknight: well, I'm definitely interested in working on parrot, in particular what i mentioned above
20:12 whiteknight mattp: could end up being a big project though. How big is a 4th year project supposed to be?
20:12 mattp not sure if there is still work to be done / what actually needs to be done
20:13 whiteknight mattp: YES! definitely needs to be done
20:13 Austin Should take 4 years, no?
20:13 whiteknight and lots of developers itching to do it
20:13 mattp whiteknight: its 2 semesters (8 months), with around 2-3 months for pure implementation (there is other time for requirements doc design doc and all that other stuff)
20:13 mattp the other question i was going to ask is if im being way too ambitious :)
20:14 whiteknight mattp: it is pretty big, but it's not as big as it used to be
20:14 whiteknight we've done a lot of cleanup on the GC recently
20:14 whiteknight in fact, a big cleanup branch landed not two hours ago
20:15 iblechbot joined #parrot
20:15 mattp hmm, i dont want to duplicate effort
20:16 whiteknight mattp: no duplication of effort. Our GC is intended to be pluggable with multiple cores
20:16 whiteknight so if you write one, other people will write others
20:16 whiteknight and we will learn something new from all of them
20:18 whiteknight there are at least a handful of new collectors that we currently want, and the more we have the better our pluggability interface is going to be
20:18 whiteknight mattp: but there are also lots of other projects in Parrot that you could do too. Creating new runcores for instance would be fantastic
20:19 bluescreen joined #parrot
20:19 whiteknight or providing interfaces for cool libraries
20:21 mattp im definitely too ignorant to commit to anything right now (need to research), but doing something actually useful for parrot for my project would be pretty badass
20:21 cotto_work mattp, I'm sure you'd have no trouble finding a mentor.
20:22 whiteknight mattp: https://trac.parrot.org/pa​rrot/wiki/BigProjectIdeas
20:22 darbelo WTF? t/codingstd/c_arg_assert.t is bitching about unused assert macros for functions that don't exist.
20:22 whiteknight I'll make sure that list gets updated, and you can cherry pick what you want to do
20:22 mattp Is there any wiki areas for discussion of those things you mentioned whiteknight, or am i going to need to troll the mailinglists .. nevermind :)
20:22 whiteknight the mailinglist always needs new trolls!
20:22 cotto_work darbelo, try running headerizer
20:23 cotto_work make sure and close any files you have open\
20:23 cotto_work s/\\//
20:23 cotto_work (or reload them after headerizer finishes)
20:24 whiteknight mattp: those "sizes" are just estimations, don't be frightened by them
20:24 darbelo did it. Didn't help.
20:24 NotFound darbelo: looks like somenone failed to make headerizer
20:25 darbelo NotFound: Thing is. I've make headerizer'ed this several times now.
20:25 dalek tracwiki: v8 | whiteknight++ | BigProjectIdeas
20:25 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Big​ProjectIdeas?version=8&amp;action=diff
20:25 whiteknight darbelo: and did headerizer succeed when you ran it?
20:25 whiteknight it will abort if it doesn't like something
20:26 NotFound make diff show me a lot of changes after running headerizer in trunk
20:26 NotFound Er, diff after make headerizer
20:26 whiteknight I would like to see a runcore that takes in a stream of PBC and outputs C code suitable for compiling into a standalone binary
20:26 mattp whiteknight: thanks alot for the help. ill get back to you guys when i figure more out
20:27 whiteknight mattp: let us know f you have any questions! We would love to have you doing cool things on Parrot
20:27 NotFound whiteknight: I think a standalone utility will be better
20:28 whiteknight NotFound: whatever, I think a runcore would be easier and faster to implement
20:29 dalek tracwiki: v9 | whiteknight++ | BigProjectIdeas
20:29 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Big​ProjectIdeas?version=9&amp;action=diff
20:29 * Coke has [apply] mostly working now. whee.
20:29 cotto_work whiteknight, that sounds a lot like the old and busted exec runcore
20:29 Coke (anonymous functions in tcl)
20:29 Coke whiteknight: that doesn't sound like a runcore. it sounds like a pbc2c utility.
20:30 whiteknight for each incoming op, we could output fprintf(.., "label_%x: Parrot_op_%s(interp, pc++);\n", pc, interp->op_lib[*pc]->name);
20:30 Coke whiteknight: ... at that point, why not just use the (future) JIT?
20:31 whiteknight Coke: a slightly different strategy of the same idea. But generating C could would allow cross-compilation to platforms that Parrot supports but JIT doesnt
20:31 whiteknight it's also the first step in a proper context-threaded runcore, which is like a light-JIT
20:32 cotto_work what is a context-threaded runcore?
20:32 whiteknight there isn't just "JIT" and "not JIT", it's a continuum with lots of different strategies
20:33 whiteknight cotto: it's like a JIT in a sense, where it generates machinecode to call each op function. It aligns Parrot's pc with the processors pc and gains like 100% pipeline efficiency
20:33 whiteknight the beauty of this is that we have pointers to the functions in C, so we can generate the machine code for the function calls very very cheaply, much cheaper then a full JIT engine could
20:33 NotFound whiteknight: to more efficiency, don't call op functions, insert them inline
20:34 mikehh darbello: it finds the ASERTS in the header files and says I don't have a matching ASSERT macro being used - you need to locate the use
20:34 dalek tracwiki: v35 | cotto++ | ParrotQuotes
20:34 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=35&amp;action=diff
20:34 whiteknight NotFound: not necessarily, inlined function bodies require much more memory
20:34 whiteknight It's all about nuance, there are lots of different strategies we want to support, each of which will excel in different areas
20:35 whiteknight And beyond that, pbc_to_exe can be majorly overhauled for increased performance
20:36 NotFound Talking about ideas, having a way to call a vtable function that checks if the pmc is an object and has a vtable override and finds a way to execute it directly may be a speed improvement in a lot of ops.
20:37 whiteknight NotFound: definitely. Anywhere that we know 100% the type of a PMC, we should make a direct call to the VTABLE function instead of calling through a function pointer
20:39 NotFound I was thinking about objects from pir classes
20:40 chromatic We should be able to swap better pointers into the vtables of such classes when we insert a PIR override.
20:42 NotFound Yes, but I was thinking about avoiding C calls, using some type of continuation that puts the result in the out register and jumps to the next opcode
20:43 chromatic If we can do that, so much the better.
20:43 NotFound Just a idea, I don't planned a way to implement it.
20:44 whiteknight NotFound: that would be pretty cool, yes
20:49 Napalm joined #parrot
20:50 notostraca joined #parrot
20:51 notostraca How do I get JIT to work on Mac OS 10.6?
20:52 chromatic I don't want to check in every VTABLE_* macro for a PIR override though.
20:53 KatrinaTheLamia joined #parrot
20:53 whiteknight We could probably see some major benefits if we updated the individual ops that were nothing more then a call to a VTABLE
20:53 whiteknight so if the argument is an Object, inline the code that the Object VTABLE would do (find method, goto method)
20:53 notostraca according to http://pastebin.ca/1568872 , JIT is not available?
20:54 darbelo I hate shaving yaks
20:54 whiteknight notostraca: We're redesiging the JIT system
20:54 whiteknight so the old system doesn't work anymore and we are building a replacement
20:55 Coke notostraca: not that that matters, as x86 JIT on OS X never worked.
20:55 notostraca oh, ok
20:55 notostraca will the new version have it?
20:55 Coke should, yes.
20:55 Coke will take some time.
20:55 notostraca all right!
20:58 kyle joined #parrot
20:58 whiteknight and it will be better!
20:58 darbelo msg jrtayloriv Also, please make sure make codetest passes on the branch before morging.
20:58 purl Message for jrtayloriv stored.
20:58 NotFound whiteknight: Do you have some idea about what opcode can give the greater improvement with that? I can do a try by manually doing the insert with it.
20:58 whiteknight yes! avoid morging
20:59 NotFound morging?
20:59 whiteknight NotFound: we could contrive an example, I think
20:59 darbelo Er, merging.
20:59 whiteknight a loop that adds numbers together 10000 times would be a good example
21:00 jrtayloriv darbelo, Will do -- didn't know about codetest. Sorry about that. Is codetest part of fulltest?
21:00 whiteknight any time that we can avoid creating a new runloop should be a big win
21:00 NotFound I was thinking about something bigger, like rakudo make test
21:00 whiteknight NotFound: I don't have enough information about profiling to know which ops would be the most used in this case
21:00 jrtayloriv whiteknight, (got your message btw) -- I'll run both codetest and fulltest and fix any errors.
21:00 whiteknight although I think that's something we could find out
21:00 NotFound Selecting one opcode that is likely to have a noticeable impact
21:01 darbelo jrtayloriv: yes, but fulltest is rather long, it can run for several minutes before dying on a trailing space.
21:01 whiteknight ask pmichaud about that
21:01 jrtayloriv whiteknight, oops -- nm -- that was darbelo's message ...
21:01 notostraca_ joined #parrot
21:01 NotFound add, maybe?
21:02 whiteknight NotFound: add_p_p_p is probably a very good starting point
21:02 whiteknight although probably not used a lot in PGE/Rakudo
21:02 chromatic Let me look at a Rakudo profile.
21:02 pmichaud string ops are always called many times
21:03 NotFound The idea is not to select one tha is highly used, but that is overrided by lots of classes
21:03 whiteknight NotFound: we might need to wait for pcc_arg_unify to land, so we have a reasonable way to pass arguments without recursing runcores
21:03 dalek parrot: r41308 | darbelo++ | trunk/src/gc (2 files):
21:03 dalek parrot: Make codetest pass on trunk after the gc-refactor merge.
21:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41308/
21:03 NotFound whiteknight: the idea is to use just one opcode and hand code it.
21:04 NotFound For a quick proof of concept
21:04 chromatic typeof P, P
21:04 whiteknight ah yes, typeof_p_p is a good one
21:05 whiteknight NotFound: how are you going to pass arguments to the sub from the op body?
21:05 pmichaud I don't quite understand "override op by lots of classes"
21:05 chromatic callmethodcc_p_sc
21:06 NotFound pmichaud: an op that does just an vtable call, and that vtable is frequently overrided
21:06 chromatic Lots of VTABLE_find_method overriding there.
21:06 kyle could somebody look at Parrot_default_{freeze,thaw,visit}, and see if they look sane?  I'm having trouble, where visit() never thaws the metadata.
21:06 pmichaud rakudo overrides find_method for all of its multimethod dispatch
21:08 NotFound chromatic: I was thinking about that, yes, but I'm not sure that using that way can give some noticeable improvement.
21:08 NotFound Need more thinking
21:10 whiteknight I think it will be easy to do with a few ops once pcc_arg_unify lands
21:10 whiteknight *if* it lands
21:10 pmichaud *if* is not really an option
21:10 NotFound But the idea is to do it inside one op.
21:11 NotFound Maybe the special purpose continuation is the simpler way
21:13 whiteknight NotFound: a continuation or a sub or whatever are both good options. Only problem right now is passing arguments to it
21:13 NotFound Is the pcc branch working? Last time I tried it doesn't build. Or I must just compile parrot and execute test manually?
21:13 chromatic make coretest
21:13 whiteknight NotFound: last I saw it builds but fails hundreds of tests
21:14 NotFound whiteknight: for me it failed to build PGE, if I remember well.
21:15 NotFound In any case, I need to look at it instead or before elaborating more the idea.
21:15 chromatic You could almost call Parrot_invokecc_p directly in the body of one of these checks.
21:18 whiteknight chromatic: but invokecc assumes the arguments will be passed before it is called using set_arg or whatever
21:18 whiteknight the arguments to the callee sub are passed in as an opcode_t* pointer
21:19 whiteknight NotFound: doesn't build PGE, no. "make corevm" then "make coretest"
21:19 NotFound whiteknight: ok
21:23 darbelo That was an unexpectedly straightforward merge, given how busy trunk has been since I branched.
21:24 mikehh_ joined #parrot
21:24 whiteknight what did you merge?
21:25 darbelo trunk into kill_jit. I needed the PIC killing.
21:26 dalek parrot: r41309 | darbelo++ | branches/kill_jit (113 files):
21:26 dalek parrot: Pull changes from trunk.
21:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41309/
21:28 mikehh joined #parrot
21:29 payload joined #parrot
21:29 chromatic whiteknight, one problem with your exec core (which is clever) is that we don't export ops symbols from libparrot.
21:30 chromatic Also we'd need either to freeze all subs and global symbols or compile the code anyway without executing it.
21:30 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41308 - Ubuntu 9.04 amd64
21:30 whiteknight chromatic: I never said it would be easy
21:31 whiteknight in a worst case scenario, I'll create all the prototypes myself and statically link
21:32 whiteknight or create a "special" parrot build that does export the ops
21:33 whiteknight or better yet, recompile parrot from source with the generated C code as the main entry point
21:34 cotto_w0rk joined #parrot
21:37 * whiteknight has to disappear into the night. Later
21:44 japhb joined #parrot
21:45 mikehh partcl r736 builds on parrot r41308 - make test PASS - Ubuntu 9.04 amd64
22:00 mikehh rakudo (177a379) builds on parrot r41308 - make test PASS / make spectest (up to 28262) FAIL - Ubuntu 9.04 amd64
22:00 mikehh rakudo - t/spec/S02-magicals/env.rakudo - Failed tests:  7, 10
22:00 mikehh rakudo - t/spec/S02-names_and_variables/perl.rakudo -   Failed tests:  71, 73, 77, 81, 83
22:00 mikehh rakudo - t/spec/S06-signature/slurpy-and-interplation.t - Failed test:  6
22:00 mikehh rakudo - t/spec/S10-packages/basic.rakudo - TODO passed:   3
22:06 sri joined #parrot
22:15 joeri left #parrot
22:41 kyle joined #parrot
22:46 jrtayloriv joined #parrot
22:49 mikehh I don't think the rakudo failures are a parrot problen - I re-installed parrot r41295 on which rakudo had previously PASSed make spectest and it gives the same failures
22:54 tetragon joined #parrot
22:54 hercynium joined #parrot
23:03 pmichaud message whiteknight after rebuilding and re-testing, I'm still seeing the segfaults on exit in Rakudo.
23:03 purl Message for whiteknight stored.
23:13 * darbelo is bored.
23:13 * darbelo breaks the build.
23:14 darbelo There. Now I can have some fun!
23:15 dalek parrot: r41310 | darbelo++ | branches/kill_jit (3 files):
23:15 dalek parrot: Actually use the data gathered by auto::frames to conditionally build the frame builder. Next we'll move Parrot_jit_build_call_func and dependencies into the src/frame_builder.c and kill the x86 JIT for good.
23:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41310/
23:15 darbelo Say, can somebody on ppc take the kill_jit branch for a spin?
23:19 bacek joined #parrot
23:24 cotto_work hi bacek
23:24 cotto_work clock
23:24 cotto_work clock?
23:24 purl cotto_work: LAX: Wed 4:24pm PDT / CHI: Wed 6:24pm CDT / NYC: Wed 7:24pm EDT / LON: Thu 12:24am BST / BER: Thu 1:24am CEST / IND: Thu 4:54am IST / TOK: Thu 8:24am JST / SYD: Thu 9:24am EST /
23:24 bacek cotto_work: morning
23:43 mattp_ joined #parrot
23:46 payload joined #parrot

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

Parrot | source cross referenced