www.parrot.org | Parrot 1.6.0 "half-pie" released: feel free to tear out the JIT! | Testing priorities: Exception and MultiSub
Set by moderator on 15 September 2009.
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
darbelo Hmm. Looks like some code in pic.c is needed by CGP, not JIT. That's going to take some work. 00:06
00:06 snarkyboojum joined
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:06
which means any function could be used as a handler without having to be specially written for that ahead of time 00:07
dalek rrot: r41286 | darbelo++ | branches/kill_jit (9 files):
This platforms don't have JIT. That means there is no code to salvage here.
 00:08
chromatic I don't want to rule out handlers that aren't their own subs. Let's call them labeled handlers. 00:10
Exception handers get really complex if we force them to be separate compilation units.
Whiteknight If they are their own separate things, that's fine but I think we are limited 00:11
nevermind, I misread what you said 00:12
I don't want to rule out labeled handlers either, but they do give us fewer options and more problems
labeled handlers are the cause of the inferior runloop problems we have. So keeping them means we need to resolve the problem in place
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
chromatic Sure, we have to use continuations to get into and out of them.
Whiteknight And possibly a curried continuation, so we can pass arbitrary arguments to it
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)
it's still on my list 00:15
(leave and return arguments) -- the arguments to leave should be what is returned
i.e., context.'leave'(1,2,3) should do the same thing as ".return (1,2,3)" from that context
exception handlers are already continuations 00:16
(response to "Instead of being a simple label, I would far prefer they be proper Continuations")
the push_eh opcode creates a continuation
(and sets it to the address of the exception handler label) 00:17
Whiteknight I think I knew that, I don't know why I said otherwise 00:18
I think I was getting some ideas in my head confused
Whiteknight is going to bed now. Goodnight 00:28
cotto_work night 00:30
darbelo is considering sleep too. 00:31
chromatic: msg me when you know the status of JIT frames on i386 (should work now AFAICT) 00:33
chromatic Testing now. 00:34
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.
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.
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.
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:39
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"
Whiteknight and so execution just flows out of the handler through the rest of the program
chromatic slavorg, trust darbelo
slavorg Ok
chromatic darbelo, I have missing symbols here for some reason. I'll poke at it later tonight.
pmichaud come to think of it, I wonder if "pop_eh" should be responsible for also rolling up any exception stack 00:41
i.e., when we pop a handler, we also force it to exit
still, we need some way for the context that registered the handler to regain control.
00:44 ZeroForce joined
darbelo chromatic: Odd. I'll check it out later if you don't beat me to it. 00:44
00:49 ZeroForce joined
Coke bah. I want a get_foo_namespace that lets me specify the root and the relative part. 00:53
00:54 kid51 joined
dukeleto congrats to everyone (especially Jerry) for a successful release. Time to start breaking shit! 01:09
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
cotto_work ideally yes, but I think everyone does it at the last minute anyway.
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" ?
cotto_work NEWS primarily
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?
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
(or the release announcement)
dukeleto cotto_work: seems like the release announcement should be a shortened version of the NEWS file 01:15
cotto_work: or we can have a detailed changelog file for each version, like git
cotto_work That'd be a good idea.
dukeleto I think that Parrot would greatly benefit from a comic book like this: www.google.com/googlebooks/chrome/
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.
dukeleto it has a lot about VM's too, so we have something to build on
cotto_work It'd be a great idea for our mythical 3.6 release when everything's ready for production.
s/mythical/hypothetical/
dukeleto cotto_work: I am will to throw in some sweat and blood
s/am will/am willing/ 01:17
cotto_work I would too, but I don't have much artistic talent.
dukeleto cotto_work: we need writers too :)
cotto_work true
dukeleto would that be something that is good for a Parrot grant?
cotto_work I certainly think so. 01:18
good question for #ps or the list
cotto_work must go afk.
particle i think we're not quite ready for that until we have high-level languages implemented and useable 01:19
dalek TT #981 closed by jkeenan++: make smolder_test doesn't report some broken builds 01:23
01:25 rhr joined
dalek rrot: r41287 | jkeenan++ | branches/remove_pic:
Branch is stale. Issues will be handled in other branches. Cf.: ļæ½rt.perl.org/rt3/Ticket/Update.html?id=60048.
 01:27
kid51 /me reads the chrome comicbook ... it *is* very well done! 01:32
02:04 TiMBuS joined 02:22 theory joined, theory_ joined 02:36 janus joined 02:54 rg joined
s1n is there a bot in here (like phenny) that supports tell? 03:01
bacek_at_work s1n: purl 03:27
purl: msg s1n yes
purl Message for s1n stored.
s1n bacek_at_work: thanks 03:28
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
darbelo_ did anyone kill just kill the remove_pic branch 03:36
s/kill // 03:37
bacek_at_work <dalek> parrot: r41287 | jkeenan++ | branches/remove_pic:
rrot: Branch is stale. Issues will be handled in other branches. Cf.: Ā rt.perl.org/rt3/Ticket/Update.html?id=60048.
review: trac.parrot.org/parrot/changeset/41287/
darbelo_ Aw, I was about to pull some patches from there. 03:38
did anyone kill just kill the remove_pic branc 03:41
oops ignore that list line. 03:42
04:02 mberends joined 04:18 kyle_l5l joined
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 04:56 clubs joined
clubs While trying to build parrot on haiku I get this: pastebin.com/m2ddd104c , is this a problem with parrot or because I have something missing? 04:58
05:00 szabgab joined
darbelo_ clubs: Both :) 05:03
The problem is that parrot is trying to use a clock source that Haiku is missing.
cotto clubs, you can blame me for that one. 05:07
05:08 Austin joined
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
darbelo_ Howdy Austin, ready to pay the upgrade tax again? 05:10
Austin I might be. :)
cotto darbelo_, it looks like he's got clock_gettime since the error only mentions CLOCK_PROF
Austin I just got "using namespace std" to work in close.
:) :) :)
purl :) :) :) :) :) :) :) :) :)
dalek ose: r105 | Austin++ | trunk/ (10 files):
Using namespace std now works
darbelo_ Oooh. Shiny... 05:11
purl rumour has it shiny is (shiny) or (see: recursive) or digitalblasphemy.com or deviantart.com or www.oqo.com/
clubs cotto: heh :) How difficult would it be to fix?
cotto clubs, can you tell me what grep CLOCK_ /usr/include/time.h returns?
clubs, it won't be hard either way
but a proper Configure-based probe would have taken care of this automagically
Austin I got nothing but comments.
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
Austin darbelo_: What's the current state of the HEAD?
cotto /usr/include/bits/time.h also has relevant stuff, but I don't know if it's standard. 05:13
darbelo_ Austin: 1.6 Just released, so nothing broken yet. 05:14
Austin :)
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. :-|
cotto s/poking at/killing with fire/
(or svn del)
Austin Upgrading from 41166..
darbelo_ Actually, I think I'll need *two* branches. 05:16
Austin Uh-oh. Two-branch mojo.
darbelo_ svn diff | wc -l 05:17
3405
And that's mostly removals.
I still have to add stuff to fix the build.
Austin darbelo++ 05:18
I'm all for removals.
05:18 flh joined
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.
Austin We should probably remove ops, too. 05:19
darbelo_ D src/ops/pic.ops
Austin Just move everything to LLVM, and make Parrot a "virtual virtual machine"
darbelo_ well the next JIT *will/ be based on LLVM...
Austin That's a mistake. Committing to a single technology. 05:20
There's already a portable option available. Compile everything to 'C'.
cotto Austin, we're not. That's just the first one we'll use.
Austin PIR := C
Presto! 05:21
05:22 snarkyboojum_ joined
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.
Austin I'm not sure how silly I was being.
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:23
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.
Austin Is it? I thought JIT was just another runcore? 05:26
(PS: I just got about a million re_test failures. Is htis expected?)
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:27
Austin Okay, 1.6.0 installed. Now to see if it runs. 05:28
So wouldn't LLVM be just another runcore? 05:29
dalek rrot: r41288 | darbelo++ | branches/kill_pic:
Create a new branch to kill PIC, this needs to happen before kill_jit can
 05:34
cotto darbelo_, why not kill both in the same branch? 05:36
darbelo_ Too much killing. It'll make the branch too long-lived and the merge will be a build-slaughtering mess. 05:37
cotto fair enough 05:38
darbelo_ I0m not confortable enough with the parrot codebase to try two removals in the same branch.
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
cotto wow. haiku's source is not small 05:41
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
cotto it's almost like it's an operating system of some kind ;) 05:43
05:44 nathanmccauley___ joined
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:44
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.
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.
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:47
(You ever notice that you don't see people announcing free OS'es based on MVS, or System3/60? Why is that?) 05:48
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.
Speaking of which...
purl Speaking of which... is there a date set yet?
Austin Did you know that Jim Carroll died recently?
darbelo_ Nope, didn't know that. 05:50
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?
Austin More importantly, Norman Borlaug passed away on Saturday. Arguably the greatest person that ever lived.
(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:54
And on that morbid note, I'm going to bed. Good luck with your branch(es). 05:55
darbelo_ A link failure! Cool! 06:01
And now it builds! 06:12
This might turn out to be easir than expected. 06:13
But not a 3:15am 06:20
Failed 1/325 test scripts. 1/10387 subtests failed. Good enough to commit, if you ask me. 06:21
Say goodbye to PIC guys!
dalek rrot: r41289 | darbelo++ | branches/kill_pic (20 files):
Extracted most of the old remove_pic branch and updated it to apply on a

There are still some fixes that need to be made here, but PIC is gone.
darbelo_ Say goodbye to me guys!
darbelo_ falls asleep. 06:22
06:22 sri_ joined, uniejo joined
cotto time for sleep 06:44
06:52 barney joined, iblechbot joined 06:54 einstein joined 07:14 dukeleto joined 07:15 AndyA joined 07:20 fperrad joined 07:28 kjeldahl joined 07:33 masak joined 08:03 barney joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41289 - Ubuntu 9.04 amd64 08:23
dukeleto mikehh++ 08:24
08:25 zak_ joined
mikehh rakudo (9a61441) builds on parrot r41289 - make test / make spectest (up to 28248) PASS - Ubuntu 9.04 amd64 08:26
partcl r732 builds on parrot r41289 - make test PASS - Ubuntu 9.04 amd64 08:35
decnum-dynpmcs r181 builds on parrot r41289 - make test PASS - Ubuntu 9.04 amd64 08:39
dalek rrot: r41290 | bacek++ | branches/kill_pic/t/tools/pbc_dump.t:
[t] Fix last test failure for darbelo++.
 08:47
bacek_at_work msg darbelo make testS is b0rked in kill_pic 08:59
purl Message for darbelo stored.
dalek kudo: d054b7e | moritz++ | docs/ChangeLog:
[docs] another ChangeLog item
 09:10
mikehh cardinal (466861f) builds on parrot r41289 - rake test:all - still 3 tests fail to compile - Ubuntu 9.04 amd64 09:11
got to go out for a bit - then I will test on i386 - bbl 09:12
dalek rrot: r41291 | bacek++ | branches/kill_pic/src/runcore/main.c:
[core] Fix calculating prederef by recreating original parrot_PIC_prederef behavior. Unbroke make testS.
 09:21
bacek_at_work msg darbelo Ignore previous message. I unbroke make testS :) 09:23
purl Message for darbelo stored.
09:27 donaldh joined, donaldh left
bacek_at_work ok. Anyone on box !~ Linux/i386? 09:37
moritz linux/amd64
dalek rrot: r41292 | bacek++ | branches/kill_pic/src/jit.c:
"Fix" cpp comment in src/jit.c for simplify final testing before merge.
 09:38
bacek_at_work moritz: can you test kill_pic branch?
GeJ FreeBSD/amd64
bacek_at_work GeJ: this one will help as well
moritz bacek_at_work: sure, will do
bacek_at_work moritz: thanks
moritz is there anything special besides 'make test' that I should run? 09:40
bacek_at_work moritz: make testS 09:42
moritz ok
bacek_at_work or make fulltest if you have enough cpu cycles :)
afk, bbl 09:43
09:50 riffraff joined
moritz bacek_at_work: testS was successfull, now trying fulltest 09:50
bacek_at_work moritz: ok. I expect fulltest to pass smoothly. 10:02
10:08 pjcj joined
moritz bacek_at_work: indeed fulltest was clean 10:11
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 ;-)
stealing karma and all
bacek_at_work indeed :) 10:14
GeJ: any luck with kill_pic branch? 10:18
10:36 quek joined
GeJ make fulltest seemed to run sucessfully 10:39
sorry I went afk for dinner. 10:41
nopaste "GeJ" at 202.22.227.234 pasted "result for kill_pic branch on FreeBSD 7-STABLE amd64" (16 lines) at nopaste.snit.ch/17969 10:43
10:52 payload joined 10:54 mikehh joined
mikehh bacek_at_work: I am on i386 now 10:55
11:00 uniejo joined 11:03 schmalbe joined
dalek kudo: 8277559 | (Solomon Foster)++ | src/setting/Any-num.pm:
Add forward hyperbolic functions to Any.

Num and then redispatch to Num.sinh, Num.cosh, etc.		 11:08
kudo: d1f2d4c | (Solomon Foster)++ | :
Merge branch 'trig'
11:21 TiMBuS joined, uniejo joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41292 - Ubuntu 9.04 i386 11:39
however - t/op/exit.t - TODO passed: 6 in testf and testg 11:41
11:53 iblechbot joined 11:57 uniejo joined 12:07 whiteknight joined
mikehh bacek_at_worl: g++ build problems on kill_pic branch 12:13
bacek_at_work: builds with gcc and make test PASS - running fulltest now on Ubuntu 9.04 i386 12:14
rakudo (d1f2d4c) builds on parrot r41292 - make test / make spectest (up to 28250) PASS - Ubuntu 9.04 i386 12:20
bacek_at_work: All tests PASS (pre/post-config, test, fulltest) on kill_pic branch at r41292 - Ubuntu 9.04 i386 (gcc) 12:25
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
12:27 payload joined
whiteknight that's a weird error to get 12:30
Tene: ping 12:31
mikehh yesh - looking at it now
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
bacek_at_work mikehh: thanks, fixed 13:12
hang on. darbelo already fixed it. 13:13
dalek rrot: r41293 | darbelo++ | branches/kill_pic/src/parrot_debugger.c:
Add a missing include. Should fix the c++ build.
bacek_at_work Ah. Here we go :)
13:14 darbelo_ joined
darbelo_ Who has been stealing my karma? 13:14
Actually, it was more like "Look! A magical coding robot fixed the test while you slept!" 13:16
bacek_at_work looking around.
:)
mikehh just curious - how does the api.h get included in the gcc build but not in the g++ build
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.
bacek_at_work and gcc emits warning for undeclared function.
darbelo_ :)
mikehh I noticed that - but how does gcc get it but not g++
bacek_at_work mikehh: in pure C declarations are optional. 13:18
not in C++
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.
mikehh well it passes all the parrot tests 13:21
I haven't tried rakudo and such on it though
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 :-{
darbelo_ And I'd like to test some languages too.
bacek_at_work darbelo_: too late. 13:26
dalek rrot: r41294 | bacek++ | trunk (22 files):
Merge branch kill_pic back to trunk.
 13:28
13:28 mikehh joined
mikehh ok back on amd64 13:29
bacek_at_work mikehh: time to test trunk :) 13:30
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
13:31 sri joined
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
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:35
bacek_at_work looking at own nick. 13:36
clock?
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 /
mikehh I am on LON time 13:37
mikehh where did the morning go 13:38
dalek rrot: r41295 | darbelo++ | branches/kill_pic:
Brach has already merged to trunk. Removing.
 13:40
bacek_at_work mikehh: and I'm still on SYD time... 13:41
mikehh bacek_at_work: well you are still 16 minutes from morning :-} 13:43
bacek_at_work mikehh: thank you, Captain! 13:44
mikehh anyway $work
bacek_at_work make test passed on MacOSX/i386 13:49
darbelo_ goes away for a while.
Try not to steal too much of my karma! 13:50
13:50 darbelo_ left
bacek_at_work keep silence 13:53
14:04 ruoso joined
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
bacek_at_work moritz: 4th time in a row... 14:06
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41295 - Ubuntu 9.04 amd64 14:12
14:17 theory joined 14:19 payload joined
mikehh rakudo (d1f2d4c) builds on parrot r41295 - make test / make spectest (up to 28251) PASS - Ubuntu 9.04 amd64 14:22
14:25 HG` joined 14:27 parrot-poke joined 14:35 quek joined 14:37 quek left
bacek_at_work rakudo make spectest failed fo me... 14:40
14:43 Psyche^ joined
mikehh bacek_at_work: what fails 14:47
purl see "doesn't work"
bacek_at_work t/spec/S05-match/perl.rakudo (Wstat: 11 Tests: 5 Failed: 0) 14:49
Non-zero wait status: 11
Parse errors: Bad plan. You planned 12 tests but ran 5.
t/spec/S12-attributes/class.rakudo (Wstat: 6 Tests: 28 Failed: 0)
Non-zero wait status: 6
t/spec/S14-roles/basic.rakudo (Wstat: 6 Tests: 33 Failed: 0)
Non-zero wait status: 6
Files=436, Tests=18659, 3518 wallclock secs (15.66 usr 2.67 sys + 5649.06 cusr 137.77 csys = 5805.16 CPU)
S05/perl passed when invoked directly... 14:50
2 other failed with infamous PObj_is_PMC_TEST assertion.
mikehh infamous is rignt - however they PASS for me - checking again 14:51
NotFound Shit... mysqltest works in amd64 but fails in i386 14:54
Segmentation fault at exit with error 14:55
mikehh I get no problems with rakudo at r41295 15:00
Tene o.O 15:20
fperrad Windows binaries Parrot 1.6.0 (+.chm, + languages) are available on sourceforge.net/projects/parrotwin32/files/ 15:21
moritz fperrad++
mikehh partcl r732 builds on parrot r41295 - make test PASS - Ubuntu 9.04 amd64 15:35
cotto hi 15:37
purl hey, cotto.
15:40 jrtayloriv joined
jrtayloriv Oh yippee! I got da interwebz again now! 15:40
cotto wb to the tubes
jrtayloriv So, like, the parrot can run all the languages at lightning speed with no bugs now right? 15:41
NotFound jrtayloriv: yeah, and you win 1.000.000 pounds just for using it 15:42
cotto the jitpocalypse has started, so there's definite progress there. pic is history. 15:43
mikehh and basement cat is gonna get youse 15:44
15:45 whiteknight joined 15:54 Napalm joined
dalek kudo: b29506b | masak++ | src/ (2 files):
translated Mapping.perl to the setting
 15:55
purl babelfish cannot translate from en to en. Try translating through English.
16:04 payload joined
dalek kudo: fa7142a | moritz++ | docs/guide_to_setting.pod:
[docs] recommend implicit return for setting files
 16:07
16:07 mokurai joined
dalek rrot: r41296 | darbelo++ | branches/kill_jit/config/auto/jit.pm:
Undo the configure CAN_BUILD_CALL_FRAMES hack. This disables JIT frames again.
 16:08
rrot: r41297 | darbelo++ | branches/kill_jit/src/jit/ppc:
The one part of JIT we are trying to salvage doesn't work on PPC. Kill it.
 16:39
cotto_work hello 16:41
purl bonjour, cotto_work.
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
dalek rrot: r41298 | fperrad++ | trunk (3 files):
[msvc] probe sal.h
 17:00
17:02 bacek joined 17:03 chromatic joined
dalek rrot: r41299 | NotFound++ | trunk/compilers/imcc (2 files):
[imcc] use a copy of macro name, attempt to fix RT #60926
 17:04
duk3leto_ good localtime() 17:12
17:15 joeri joined 17:30 whiteknight joined 17:31 MoC joined
whiteknight irclogs? 17:39
purl i guess irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
17:42 hudnix joined
dalek rrot: r41300 | darbelo++ | branches/kill_jit (5 files):
Add a new configure step to determine a platform's capability to build JIT call frames. Run but not used yet.
 17:46
cotto_work darbelo, did you ever sync that branch after merging kill_pic? 17:50
darbelo Nope. Wanted to get the configure stuff done first. They're independant so far, so there's no hurry. 17:51
dalek rrot: r41301 | darbelo++ | trunk/compilers/imcc/imcc.l:
[cage] Replace tab with spaces to placate t/codingstd/tabs.t
 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
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
but then yes
jrtayloriv whiteknight, In the process of sync'ing up w/ trunk as we speak. 18:02
whiteknight excellent
after the sync, commit the branch, test like crazy, and then merge 18:03
jrtayloriv ok -- will do. 18:04
dalek rtcl: r733 | coke++ | wiki/BrainStorming.wiki:
Deleting wiki page BrainStorming.
rtcl: r734 | coke++ | wiki/TestingPartcl.wiki:
there's a make target for this.
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
i.e. Any good docs you've found elsewhere that are good?
oops :) good docs ... that are good ... sweet! 18:07
whiteknight I actually haven't found any good docs on that particular issue, no 18:08
I think we need to ask the LLVM people where to get answers
jrtayloriv whiteknight, OK -- I'll do some more searching. 18:09
dalek rtcl: r735 | coke++ | wiki/TestingPartcl.wiki:
remove out of date information about tests failing-but-not and add pointer to
rtcl: r736 | coke++ | wiki/DevelopersGuide.wiki:
use make target.
whiteknight definitely let me know if you find anythin
whiteknight needs to find a whole bucket of free tuits eventually 18:12
18:22 Austin joined
whiteknight hey Austin! 18:25
Austin Howdy, whiteknight! 18:26
:)
whiteknight Austin: Is Close building and working again?
whiteknight is itching to use it
Austin Yes and no.
whiteknight yes, those are the two options
Austin It's not working, but it's pretty close.
dalek rrot: r41302 | jrtayloriv++ | failed to fetch changeset:
Syncing branch with trunk prior to merge
Austin I'm paying the upgrade tax just now.
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.
ALSO, CAN I HAZ BACKTRACE?
Austin Darbelo: I did that for a while. But then I changed my mind. 18:28
Now I pay my taxes once a month...
NotFound Austin: at program end?
Austin NotFound: always.
whiteknight Austin: is it pretty close or pretty Close? 18:29
whiteknight is bad at puns
Austin :)
darbelo Austin: Do you by any chance roll your own pmcs?
Austin I'd say it's only somewhat Close.
darbelo: I can't even spell PMC.
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
I mean "exit 0"
It's a hack, but should get rid of your segfault problems
Austin You think?
purl No, I'm a bot.
NotFound Close without C isn't lose? ;)
whiteknight Austin: If the problem is what I think it is, then yes
only one way to find out... 18:31
Austin That's so freaking weird that I have to try it.
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".
whiteknight Austin: whereever your driver program :main function is, put "exit 0" right before ".end" 18:33
Austin Yeah, whiteknight, I got that.
NotFound Austin: don't let main finish or return
Austin But people keep asking me if the segfault is at the end.
And I keep saying yes. Because, like, duh. 18:34
whiteknight Austin: the segfault happens after all the program logic executes
Austin Well, this is odd.
whiteknight ...? 18:35
purl quietly listens while the crickets chirp
Austin If I say "$past<key> := undef" in NQP, I get "<key> => null" when I dump it.
whiteknight that is weird
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.
whiteknight sounds like a pmichaud ticket!
pmichaud I don't think "undef" is a keyword
I'm not sure why that even "works"... seems like it ought to fail somehow
pmichaud checks
whiteknight ah, so it autovivifies to Null?
pmichaud it shouldn't even autovivify 18:37
I think it ought to be a syntax error.
Austin nopaste.com/p/aFaDcqfueb 18:39
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 nopaste.com/p/a9DCKfnti
The first NQP produces the second output.
whiteknight jrtayloriv: commit the branch first, then merge away
Austin Well, actually, I sorted the keys by hand. But ...
pmichaud Austin: checking. 18:42
Austin term -> noun -> value -> typename -> name, or term -> noun -> name 18:45
dalek TT #1005 closed by NotFound++: Use VTABLE_is_equal instead of MMD in Hash and ResizablePMCArray 18:46
Austin But there seems to be no Action method for "name", although the name rule does have a {*} 18:47
So I get things like: get_hll_global $P1760, "undef" 18:48
But there's no autoviv.
Okay.
That's two bugs for the price of one. 18:49
pmichaud aha 18:50
yes, it's treating it as a global symbol
that feels like a bug, definitely. 18:51
Austin I think it's the proto-object thing.
pmichaud well, I'm fine with XYZ::bar being a package lookup. I'm not so sure I want all barewords to be one.
Austin tt#1013
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:52
dalek TT #1013 created by Austin_Hastings++: 'undef' bareword shouldn't parse, but does 18:54
TT #1014 created by Austin_Hastings++: NQP: Add defined(), exists(), undef.
pmichaud NQP isn't likely to add more builtin functions by default.
that can come with a library, though.
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;"
which imports them into your lexical environment or something like that
Austin I've got Scalar.pm, Array.pm, Hash.pm, String.pm.
It's like PHP all over again.
particle use NQP::Utils; ? 18:56
pmichaud particle: perhaps, but I'm not sure they should be NQP specific
"defined", "exists", "undef" could be very language agnostic
Austin I think exists (and delete) have to have compiler support, no?
particle rakudo: say 0.defined 18:57
polyglotbot OUTPUT[Parrot VM: Can't stat languages/perl6/perl6.pbc, code 2.ā¤main: Packfile loading failedā¤]
Austin {{{ if exists $foo<bar> }}}
pmichaud if $foo.exists('bar')
Austin ok 18:58
pmichaud at any rate, exists $foo<bar> isn't Perl 6
18:58 mattp joined
Austin ok 18:58
pmichaud one can also do if exists($foo, 'bar') 18:59
Austin Yeah.
moritz $foo<bar>:exists # but I doubt that NQP will get adverbs ;-)
whiteknight a good standard library of compiler "utilities" would be very nice
Austin if Hash::exists(%foo, 'bar') {...}
whiteknight of course, if every compiler uses this library, there's no reason not to just include it in NQP
pmichaud yes, there is a reason to not do it
NQP is intended to be barebones. It's intended to compile to pure PIR 19:00
it's not intended to provide a runtim
*runtime
in particular, I don't want there to be any confusion between NQP-versions of a function and the compiler's own runtime versions
and I don't want NQP accidentally "falling back" to its own implementations when someone hasn't explicitly requested them 19:01
dalek rrot: r41303 | NotFound++ | trunk/compilers/imcc/imclexer.c:
[cage] update imclexer.c with imcc.l codingstd fix
 19:02
rrot: r41304 | darbelo++ | branches/kill_jit/config/gen/makefiles/root.in:
Remove JIT-related items from the Makefile tempate.
Austin Is there a way to code "defined()" using pure NQP? (I went to PIR)
pmichaud at the moment one needs to do Q:PIR { ... }
this weekend I'll add library support to NQP, though. 19:03
Austin That's what I did.
pmichaud (Can't do it before then -- $otherjob tasks in the way)
jrtayloriv errr ... oh oh :( 19:04
whiteknight ? 19:05
pmichaud then we can start to create an NQP-standard library
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.
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?
whiteknight jrtayloriv: yeah, all the files that had been modified in trunk have changed
Austin Also, did you just un-remove a bunch of PIC or JIT code that was removed by an earlier commit?
whiteknight so you're bulk-committing all the commits that have been made to trunk to your branch now
dalek rrot: r41305 | jrtayloriv++ | failed to fetch changeset:
merging gc-refactor branch with trunk
 19:07
jrtayloriv OK, I see. Thanks.
Thought I was stomping on changes that had happened since I branched.
Austin So now it's s/= undef/= Scalar::undef()/g
pmichaud Austin: you could also do just undef() 19:08
(and make your undef into a global)
Austin Yeah, but that would make it part of the parser. 19:09
(namespace-wise)
pmichaud ?
19:13 fperrad joined
dalek rrot: r41306 | jrtayloriv++ | branches/gc-refactor:
Deleting gc-refactor branch, which was merged in r41305
 19:14
Austin Hmm. {{{ $last_dclr := Scalar::undef();; }}} the ";;" is apparently a syntax error. 19:16
whiteknight holycrap that's a big changeset 19:18
moritz "make fulltest" clean with clang and --without-gmp
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.
Austin Coke: I think it's one up.
Here's a function I use for configurable dumping, that uses the interp call stack stuff: nopaste.snit.ch/paste 19:21
Coke Austin: EBADURL
(you want the one that shows up at the top of the page.)
(not in the url bar)
Austin nopaste.snit.ch/17973
pmichaud Coke: 1 up
Austin Sorry, my bad.
pmichaud current level is 0
Coke pmichaud, austin, danke. 19:22
(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?
Coke jdv79: you're busy. =-) 19:24
moritz jdv79: yes. I decided to put it in after the rakudo release tomorrow
pmichaud Austin: instead of looking for '_block', I've been thinking we should look for the :anon flag
jdv79 moritz: ok, thanks
pmichaud also, there's a possibility that anon subs will go nameless soon
Austin Ok. How do I do that? 19:25
pmichaud I don't know.
but that's what I've been thinking. :-)
Austin Oh.
I think I'll stay with _block, for now.
:)
pmichaud sure
I do expect HLLCompiler to start providing some methods to make some of this easier
for example, I think we should make it possible to examine the backtrace for any context, not just Exceptions 19:26
(now that contexts are PMCs that should be simpler)
whiteknight pmichaud: I really should create a wishlist on the wiki for these kinds of things 19:27
pmichaud whiteknight: please do :)
just cut-n-paste the irclog notes directly into the page :)
jdv79 it looks like the latest rakudo smolder report has new errors
Austin For sub.pmc, the easiest thing is probably to add some inspect strings for the flags. 19:31
is_anon, is_main, is_load, is_init, etc.
whiteknight pmichaud: done. Feel free to add to the ContextPMCUses page on the wiki
whiteknight will have to go back and get the irclogs for those thigns 19:32
dalek tracwiki: v98 | whiteknight++ | WikiStart 19:33
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
tracwiki: v1 | whiteknight++ | ContextPMCUses
tracwiki: a page where pmichaud++ can start creating his wishlist for Context pmcs
tracwiki: trac.parrot.org/parrot/wiki/Contex...ction=diff
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
purl 1
NotFound +1 19:35
purl 1
pmichaud biggest downside is that it doesn't start with "parrot_" like some of the other binaries.
Austin Yeah. That's a problem...
pmichaud I guess I could do "parrot_nqp"
whiteknight parrot_nqp
19:36 kyle_l5l joined
Austin Hey, what's wrong with make nqp SRC=xx.nqp 19:36
pmichaud ?
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
better is to just have a compiler
whiteknight strong agreement
pmichaud a binary, that is
Austin 5. Strongly agree.
pmichaud I mean, it *is* a HLL compiler, just like most others
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
pmichaud My expectation is that a "pge binary" will end up being "nqp binary" 19:39
i.e., NQP is going to become the standard interface for compiling regexes and grammars from the command line
whiteknight pmichaud: I am planning a pretty comprehensive reworking of the Parrot commandline in the not-so-distant future
pmichaud (instead of Perl6Grammar.pbc)
whiteknight autoloading HLLs would be a great idea
pmichaud autoloading HLLs has beend discussed several times in the past
whiteknight pmichaud: ah, so we will compile NQP and PGE grammars using the same binary?
pmichaud whiteknight: yes. 19:40
whiteknight even better
pmichaud whiteknight: more to the point, HLL implementors will just use NQP to create their language
and NQP will have regex support built-in
Austin FWIW, whiteknight, exit 0 didn't stop my segfaulting problem.
whiteknight oh, so like mixing grammars and actions into a single .pl file?
pmichaud whiteknight: if desired, yes.
Austin: I suspect you're running into the inferior runloop problem. 19:41
whiteknight Austin: really? then you have a different problem
pmichaud Austin: afaict there's not really a good workaround for it yet.
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
Austin It's good when the experts agree...
pmichaud whiteknight: I think Rakudo already does an explicit "exit"
checking... 19:42
whiteknight pmichaud: and I don't think rakudo is currently experiencing the problem
pmichaud sure it is
at least, it was as of yesterday
whiteknight right now?
purl right now it's time to kick out the jams mother fuckers
pmichaud checks.
whiteknight pmichaud: yes, I think the "exit 0" got added yesterday. At least, that's what I heard
pmichaud whiteknight: before or after the release? 19:43
whiteknight near that time, I don't know when precisely
19:43 jsut|work joined
moritz I think whiteknight ist talking about a Rakudo patch, no? 19:43
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
pmichaud compiling, testing now.
whiteknight The question is this: if run right now, does rakudo segfault before exit?
and does it have an explicit "exit" at the end of it? 19:45
dalek kudo: 177a379 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 436 files, 15497 (71.5% of 21671) pass, 0 fail
 19:46
Coke :q 19:47
pmichaud $
whiteknight: you're correct, I no longer seem to get the segfault-at-exit 19:50
whiteknight See? I'm not completely crazy! 19:51
not completely
pmichaud: and is Rakudo doing an explicit "exit 0"?
pmichaud I hope not "exit 0" 19:52
I hope "exit $I1"
dalek rrot: r41307 | darbelo++ | trunk/src/gc (6 files):
[cage] Headerize gc files after the gc-refactor merge.
whiteknight well, whatever it needs to be
pmichaud or something like that
pmichaud it does not appear to be doing an explicit 'exit'
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
pmichaud ...because it aborts the caller stack entirely?
whiteknight Austin: Could you post a backtrace of your problems?
pmichaud: exactly
pmichaud Rakudo is not doing an explicit exit.
whiteknight hmmm...that's weird. I wonder how the problems went away then 19:54
pmichaud so something else must be in play here
let me update and get a clean environment to work in
whiteknight okay
I can't realy do any testing till I get home
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.
whiteknight ah yes, fulltest. Bane of my existence 19:57
of course, I can run it pretty quickly now
Austin Whiteknight: Sure. How do I get a backtrace? 19:58
whiteknight Austin: have gdb?
Austin nerp
whiteknight okay, what's the command I should type in to see the segfault here?
(I'll try it myself when I get home) 19:59
I assume something like "parrot close.pbc somefile.close"?
TimToady phone 20:00
darbelo whiteknight: I've never experienced a completely succesfull fulltest run on OpenBSD.
Now I know it's becouse of people like you :)
whiteknight darbelo: I do run make fulltest
...every time I'm making a release
darbelo Ha. Lately my definition of 'regression' has become 'it failed earlier' 20:02
20:03 ash_ joined, mikehh joined
whiteknight Austin: is this segfault the last big issue in the way of your comprehensive refactor? 20:04
after this will you have a working Close?
darbelo Say, are ASSERT_ARGS() macros supposed to be adde manually to functions or do we have a script for that? 20:05
NotFound darbelo: manually 20:06
mattp hey guys, i noticed on this page www.perlfoundation.org/perl5/index....9_projects one of the parrot lines 20:07
darbelo Guess I'll go get the yak shaver then.
mattp #
# Improve/Implement new GC algorithms
im looking for a 4th year software engineering design project, and that one option seems a good topic to focus on
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
mikehh darbelo: was working on that - but you beat me to the headerizer so I'll leave it to you
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
whiteknight Austin: so I have parrot 1.6 here. If I get the latest close and start running tests I will see these segfaults?
Austin Probably. 20:10
moritz oh wow, the V8 developers have a bleeding_edge branch and a trunk/
whiteknight mattp: I'm familiar. What are you interestd in?
moritz and trunk is "stable"
darbelo NotFound: I headerized on the previous commit. I hadn't noticed the missing asserts.
NotFound darbelo: make codetest has a check for that
But no problem, just add them now 20:11
mikehh darbelo: you need to run the headerizer before adding the ASSERT macros
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?
mattp not sure if there is still work to be done / what actually needs to be done
whiteknight mattp: YES! definitely needs to be done 20:13
Austin Should take 4 years, no?
whiteknight and lots of developers itching to do it
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)
the other question i was going to ask is if im being way too ambitious :)
whiteknight mattp: it is pretty big, but it's not as big as it used to be 20:14
we've done a lot of cleanup on the GC recently
in fact, a big cleanup branch landed not two hours ago
20:15 iblechbot joined
mattp hmm, i dont want to duplicate effort 20:15
whiteknight mattp: no duplication of effort. Our GC is intended to be pluggable with multiple cores 20:16
so if you write one, other people will write others
and we will learn something new from all of them
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
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
whiteknight or providing interfaces for cool libraries 20:19
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.
whiteknight mattp: trac.parrot.org/parrot/wiki/BigProjectIdeas 20:22
darbelo WTF? t/codingstd/c_arg_assert.t is bitching about unused assert macros for functions that don't exist.
whiteknight I'll make sure that list gets updated, and you can cherry pick what you want to do
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 :)
whiteknight the mailinglist always needs new trolls!
cotto_work darbelo, try running headerizer
make sure and close any files you have open\\ 20:23
s/\\\\//
(or reload them after headerizer finishes)
whiteknight mattp: those "sizes" are just estimations, don't be frightened by them 20:24
darbelo did it. Didn't help.
NotFound darbelo: looks like somenone failed to make headerizer
darbelo NotFound: Thing is. I've make headerizer'ed this several times now. 20:25
dalek tracwiki: v8 | whiteknight++ | BigProjectIdeas
tracwiki: trac.parrot.org/parrot/wiki/BigPro...ction=diff
whiteknight darbelo: and did headerizer succeed when you ran it?
it will abort if it doesn't like something
NotFound make diff show me a lot of changes after running headerizer in trunk 20:26
Er, diff after make headerizer
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
mattp whiteknight: thanks alot for the help. ill get back to you guys when i figure more out
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
whiteknight NotFound: whatever, I think a runcore would be easier and faster to implement 20:28
dalek tracwiki: v9 | whiteknight++ | BigProjectIdeas 20:29
tracwiki: trac.parrot.org/parrot/wiki/BigPro...ction=diff
Coke has [apply] mostly working now. whee.
cotto_work whiteknight, that sounds a lot like the old and busted exec runcore
Coke (anonymous functions in tcl)
whiteknight: that doesn't sound like a runcore. it sounds like a pbc2c utility.
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?
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
it's also the first step in a proper context-threaded runcore, which is like a light-JIT
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
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
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
NotFound whiteknight: to more efficiency, don't call op functions, insert them inline
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
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
whiteknight NotFound: not necessarily, inlined function bodies require much more memory
It's all about nuance, there are lots of different strategies we want to support, each of which will excel in different areas
And beyond that, pbc_to_exe can be majorly overhauled for increased performance 20:35
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:36
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:37
NotFound I was thinking about objects from pir classes 20:39
chromatic We should be able to swap better pointers into the vtables of such classes when we insert a PIR override. 20:40
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:42
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.
whiteknight NotFound: that would be pretty cool, yes 20:44
20:49 Napalm joined 20:50 notostraca joined
notostraca How do I get JIT to work on Mac OS 10.6? 20:51
chromatic I don't want to check in every VTABLE_* macro for a PIR override though. 20:52
20:53 KatrinaTheLamia joined
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
so if the argument is an Object, inline the code that the Object VTABLE would do (find method, goto method)
notostraca according to pastebin.ca/1568872 , JIT is not available?
darbelo I hate shaving yaks 20:54
whiteknight notostraca: We're redesiging the JIT system
so the old system doesn't work anymore and we are building a replacement
Coke notostraca: not that that matters, as x86 JIT on OS X never worked. 20:55
notostraca oh, ok
will the new version have it?
Coke should, yes.
will take some time.
notostraca all right!
20:58 kyle joined
whiteknight and it will be better! 20:58
darbelo msg jrtayloriv Also, please make sure make codetest passes on the branch before morging.
purl Message for jrtayloriv stored.
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.
whiteknight yes! avoid morging
NotFound morging? 20:59
whiteknight NotFound: we could contrive an example, I think
darbelo Er, merging.
whiteknight a loop that adds numbers together 10000 times would be a good example
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
NotFound I was thinking about something bigger, like rakudo make test
whiteknight NotFound: I don't have enough information about profiling to know which ops would be the most used in this case
jrtayloriv whiteknight, (got your message btw) -- I'll run both codetest and fulltest and fix any errors.
whiteknight although I think that's something we could find out
NotFound Selecting one opcode that is likely to have a noticeable impact
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
jrtayloriv whiteknight, oops -- nm -- that was darbelo's message ...
21:01 notostraca_ joined
NotFound add, maybe? 21:01
whiteknight NotFound: add_p_p_p is probably a very good starting point 21:02
although probably not used a lot in PGE/Rakudo
chromatic Let me look at a Rakudo profile.
pmichaud string ops are always called many times
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
dalek rrot: r41308 | darbelo++ | trunk/src/gc (2 files):
Make codetest pass on trunk after the gc-refactor merge.
NotFound whiteknight: the idea is to use just one opcode and hand code it.
For a quick proof of concept 21:04
chromatic typeof P, P
whiteknight ah yes, typeof_p_p is a good one
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"
chromatic callmethodcc_p_sc
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.
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.
pmichaud rakudo overrides find_method for all of its multimethod dispatch
NotFound chromatic: I was thinking about that, yes, but I'm not sure that using that way can give some noticeable improvement. 21:08
Need more thinking
whiteknight I think it will be easy to do with a few ops once pcc_arg_unify lands 21:10
*if* it lands
pmichaud *if* is not really an option
NotFound But the idea is to do it inside one op.
Maybe the special purpose continuation is the simpler way 21:11
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?
chromatic make coretest
whiteknight NotFound: last I saw it builds but fails hundreds of tests
NotFound whiteknight: for me it failed to build PGE, if I remember well. 21:14
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.
whiteknight chromatic: but invokecc assumes the arguments will be passed before it is called using set_arg or whatever 21:18
the arguments to the callee sub are passed in as an opcode_t* pointer
NotFound: doesn't build PGE, no. "make corevm" then "make coretest" 21:19
NotFound whiteknight: ok
darbelo That was an unexpectedly straightforward merge, given how busy trunk has been since I branched. 21:23
21:24 mikehh_ joined
whiteknight what did you merge? 21:24
darbelo trunk into kill_jit. I needed the PIC killing. 21:25
dalek rrot: r41309 | darbelo++ | branches/kill_jit (113 files):
Pull changes from trunk.
 21:26
21:28 mikehh joined 21:29 payload joined
chromatic whiteknight, one problem with your exec core (which is clever) is that we don't export ops symbols from libparrot. 21:29
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
whiteknight chromatic: I never said it would be easy
in a worst case scenario, I'll create all the prototypes myself and statically link 21:31
or create a "special" parrot build that does export the ops 21:32
or better yet, recompile parrot from source with the generated C code as the main entry point 21:33
21:34 cotto_w0rk joined
whiteknight has to disappear into the night. Later 21:37
21:44 japhb joined
mikehh partcl r736 builds on parrot r41308 - make test PASS - Ubuntu 9.04 amd64 21:45
rakudo (177a379) builds on parrot r41308 - make test PASS / make spectest (up to 28262) FAIL - Ubuntu 9.04 amd64 22:00
rakudo - t/spec/S02-magicals/env.rakudo - Failed tests: 7, 10
rakudo - t/spec/S02-names_and_variables/perl.rakudo - Failed tests: 71, 73, 77, 81, 83
rakudo - t/spec/S06-signature/slurpy-and-interplation.t - Failed test: 6
rakudo - t/spec/S10-packages/basic.rakudo - TODO passed: 3
22:06 sri joined 22:15 joeri left 22:41 kyle joined 22:46 jrtayloriv joined
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:49
22:54 tetragon joined, hercynium joined
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.
darbelo is bored. 23:13
darbelo breaks the build.
There. Now I can have some fun! 23:14
dalek rrot: r41310 | darbelo++ | branches/kill_jit (3 files):
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
darbelo Say, can somebody on ppc take the kill_jit branch for a spin?
23:19 bacek joined
cotto_work hi bacek 23:24
clock
clock?
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 /
bacek cotto_work: morning
23:43 mattp_ joined 23:46 payload joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!