www.parrot.org | BoD purchasing a new cert. Thank you for your patience.
Set by moderator on 31 August 2009.
00:06 Zak joined 00:27 Andy joined
jrtayloriv hmmm ... that's weird -- I was failing about 6 different test groups, and then after 'make realclean' and rebuilding, all I'm failing is the sprintf tests. 00:27
but then after running them a second time (without running make clean/realclean), I start failing a bunch of them again. 00:30
Whiteknight yay! nondeterministic test failures 00:43
We'll get them nailed down though, this branch is important enough 00:47
NotFound: ping
dalek rrot: r40900 | whiteknight++ | branches/kill_parrot_cont:
[kill_parrot_cont] Creating a patch to test and fix the patch provided by jrtayloriv++ in TT #926
Whiteknight worst case? 00:48
purl it has been said that worst case is you do something like render() in poe.dyndns.org/~troc/tmp/fax/Fax.pm
Whiteknight Clang apparently was doing something about adding closures to C 00:50
really awesome, but no way in all of hell that Parrot's codebase would ever use them
00:52 japhb joined 00:54 AndyA joined
dalek rrot: r40901 | whiteknight++ | branches/kill_parrot_cont (18 files):
[kill_parrot_cont] Apply patch from jrtayloriv++ in TT #926. Seeing failure in t/op/sprintf.t that is difficult to debug.
 01:11
bacek_at_work Whiteknight: en.wikipedia.org/wiki/Setcontext :) 01:37
01:41 TiMBuS joined
Whiteknight bacek_at_work: I didn't write those accessors tonight, got sidetracked 01:43
will do it tomorrow
...if you can wait that long :)
bacek_at_work Whiteknight: no worries
Whiteknight okay, I'm going to bed now. Goodnight
jrtayloriv bacek_at_work, as far as writing tickets for the kill_parrot_cont branch, should I just continue to attach comments to TT #926, or should I create a new ticket with a title like "kill_parrot_cont branch fails sprintf tests"? 01:47
bacek_at_work jrtayloriv: just attach more comments to original ticket. 01:50
jrtayloriv bacek_at_work, ok - thanks 01:51
bacek_at_work jrtayloriv: on which platform you are developing this? 01:53
jrtayloriv x86_64
01:54 rhr joined
jrtayloriv linux 01:54
bacek_at_work try to disable vdso and rebuild without optimise. It will simplify bugs hunting
jrtayloriv bacek_at_work, do you mean GCC -O flags? or Configure.pl --optimize flag? 01:55
bacek_at_work Configure flags to build without optimise
"echo 0 > /proc/sys/vm/vdso_enabled" (or something like this) to disable vdso 01:56
jrtayloriv bacek_at_work, my kernel does not have vdso support built into it. 01:57
bacek_at_work jrtayloriv: hmm... Then failures should be deterministic...
jrtayloriv bacek_at_work, maybe I'm not looking at the correct kernel config option then (CONFIG_COMPAT_VDSO) 01:58
bacek_at_work COMPAT_VDSO for 32 bits afaik
jrtayloriv it wasn't in /proc/sys/vm/ either ... I'll browse around and see what I can find as far as Gentoo and VDSO (maybe Gentoo does something weird with it) ... but as far as --optimize, that is not on by default right? 01:59
bacek_at_work --optimize not in default. But in your latest backtrace I did see optimised-out variables :) 02:00
jrtayloriv bacek_at_work, I didn't perl Configure.pl with --optimize, maybe that is GCC ... I do have -02 enabled by default in my Gentoo config files 02:03
bacek_at_work Heh. And effectively switch on optimisation :) 02:04
jrtayloriv bacek_at_work, should I do --> perl Configure.pl --optimize=O0 02:08
hmmm, that just gave me all manner of errors. 02:10
I've got Perl built with -O2 ... maybe that is why is is causing problems when I do that?
dukeleto 'ello 02:13
bacek_at_work jrtayloriv: perl Configure.pl --ccflags="-O0" 02:14
chromatic perl Configure.pl --maintainer --optimize && perl -pi -e 's/-DDISABLE_GC_DEBUG=1 -DNDEBUG -O2 /-O3 /' Makefile
jrtayloriv ahhh ... ok -- bingo
chromatic You can add -g on the rhs if you like too. 02:15
dukeleto jrtayloriv: has anyone gotten back to you about trac.parrot.org/parrot/ticket/958 ? Looks like it can be applied and closed, yes? 02:17
jrtayloriv dukeleto, I haven't heard anything about it since my last post. I recall someone earlier saying that they wanted whiteknight to take a look at it, but I don't think he has had the time to do so. So, honestly, I don't know whether they should be applied or not -- I was waiting for someone more knowledgable to make that decision. 02:19
chromatic, I see that this enables GC debugging / debugging, but don't I want to reduce the optimization level like bacek said? Doesn't what you wrote there increase the optimization from O2 to O3? Why do I want to do that? 02:22
chromatic I don't know why you might.
I do it to be sure that Parrot continues to work with full optimizations.
jrtayloriv chromatic, bacek_at_work was saying that disabling the optimizations would make it easier to debug. 02:23
chromatic I haven't noticed that myself. 02:24
dukeleto chromatic: do we currently keep track of which flags parrot was built with on smolder/taptinder ?
chromatic I don't know. 02:25
I *think* it's available somehow.
dukeleto chromatic: also, what about adding a flag to Configure.pl so that you don't have to perl -pi the Makefile? would that be useful? 02:26
perl Configure.pl --debug --maintainer --optimize=3 02:27
02:35 janus joined 03:20 donaldh joined 03:58 Andy joined
dalek kudo: 9bcba63 | pmichaud++ | src/parser/grammar.pg:
"Statement not terminated properly" --> "Confused" # TimToady++
 04:12
04:22 davidfetter joined 04:56 ZeroForce joined 05:13 beta joined 05:21 kjeldahl joined 06:01 uniejo joined 06:25 iblechbot joined
bacek_at_work jrtayloriv: ping 06:26
jrtayloriv pong
bacek_at_work I read your comment in ticket. Looks like premature GCing of Continuation (or continuation's ATTRibutes) 06:27
jrtayloriv bacek_at_work, so a problem with how I implemented mark()? 06:28
bacek_at_work jrtayloriv: probably. I can't review it right now.
jrtayloriv bacek_at_work, np -- thanks for pointing me to that.
06:29 HG` joined
jrtayloriv bacek_at_work, And later, when you've got more time, could you explain to me how you figured that out? i.e. what gave you the hint that something related to Continuation is being GCed prematurely? 06:34
06:36 Zak joined
bacek_at_work jrtayloriv: I'm not 100% sure that it GCed prematurely. But in most cases such errors caused by memory access errors. Which mean premature GCing of something. 06:37
06:39 krunen joined
jrtayloriv OK. Thanks. 06:42
bacek_at_work++, just got it, I think -- it had to do with freeing the to_ctx of the continuation in the destroy() VTABLE, which I shouldn't have been doing (although I don't understand why I have to free the from_ctx, but not the to_ctx) ... thanks for the help again :) 06:59
yep -- just passed sprintf test
sweet! -- passed all tests (except for pcre, which I am failing with trunk/ anyway), bacek++ 07:01
cotto jrtayloriv, do you think it'd still be worthwhile to have a branch to work against? 07:03
jrtayloriv cotto, I don't understand the question, sorry. Are you asking if I think that there needs to be a separate branch? 07:05
cotto, WhiteKnight created it, so I would ask him -- I don't know what the best thing to do here is. 07:06
cotto nm. I thought he hadn't created a branch yet.
jrtayloriv, do you know about our weekly meetings in #parrotsketch? 07:19
jrtayloriv cotto, yes, but I've honestly never sat in -- I'll have to do so. Thanks for reminding me -- I'll actually go browse through the logs in a moment, once I post my patch up, and see what goes on in there. 07:20
07:20 donaldh joined
jrtayloriv done and done 07:24
cotto That was speedy. 07:26
jrtayloriv coffee ... is ... wearing ... off ... ... ... bedtime soon 07:42
purl: msg whiteknight -- kill_parrot_cont is passing all tests now on x86_64 linux. btw -- if you have a few minutes later, could you review the docs/ patches I made in TT #958 07:55
purl Message for whiteknight stored.
jrtayloriv night night #parrot
07:56 rbaumer joined 08:00 chromatic joined, bacek joined
bacek o hai 08:01
08:05 rbaumer joined 08:09 MoC joined 08:14 jrtayloriv joined 08:30 Khisanth joined 08:53 MoC joined 09:05 allison joined 09:13 allison joined, allison left 09:18 masak joined
dukeleto bacek: good localtime() 09:20
bacek dukeleto: alloha! How is irssi proxy going? :) 09:21
09:21 rbaumer joined
dukeleto bacek: i did a lot of rtfm'ing, now I just need to set it up ;) 09:22
bacek That's good :)
dalek rrot: r40902 | bacek++ | branches/context_pmc3 (42 files):
Reintroduce CURRENT_CONTEXT macro. Switch CONTEXT macro to return Parrot_Context structure back
 09:23
mikehh All tests PASS at r40902 (pre/post-config, smoke, nqp_test, fulltest) - Ubuntu 9.04 amd64 (g++) 10:17
dalek rrot: r40903 | bacek++ | branches/context_pmc3 (4 files):
Add accessors to Regs_* structures. Move Parrot_Context definition into
 10:20
10:27 rbaumer joined
mikehh rakudo (9bcba63) builds on parrot r40902 - make test / make spectest (up to r28155) PASS - Ubuntu 9.04 amd64 (g++) 10:33
partcl r650 builds on parrot r40902 - make test PASS - Ubuntu 9.04 amd64 (g++) 10:39
decnum_dynpmcs r181 builds on parrot r40902 - make test PASS - Ubuntu 9.04 amd64 (g++) 10:42
bacek mikehh: Yay! Can you test latest context_pmc3 branch? 10:44
mikehh bacek: right on
bacek mikehh: wait few minutes. It's still dcommiting 10:45
(Rakudo will not build with old patch)
mikehh ok I am at r40907 10:46
on the branch
dalek rrot: r40904 | bacek++ | branches/context_pmc3/src (2 files):
Switch Context.inc_recursion_depth to postincrement to avoid assign -1 to UINTVAL.
rrot: r40905 | bacek++ | branches/context_pmc3/src/runcore/main.c:
Remove meaningless assert.
rrot: r40906 | bacek++ | branches/context_pmc3 (6 files):
Use Context Regs_* accessors
rrot: r40907 | bacek++ | branches/context_pmc3/include/parrot/interpreter.h:
Finally remove CONTEXT_FIELD and CURRENT_CONTEXT_FIELD macros.
bacek mikehh: yes. r40907 is latest
mikehh bacek: ok here goes
bacek mikehh: thanks!
mikehh: after "realclean" codetest failure about c++ comments is expected. 10:50
mikehh bacek: builds ok - make test PASS running other tests now 10:58
bacek mikehh: ok. I'll prepare new version of patches for rakudo and lua. 10:59
11:05 mberends joined
mikehh bacek: I also got t/distro/file_metadata.t fails on src/call/context.c and t/op/inf_nan.t (svn properties) 11:09
bacek mikehh: ouch... It's svn related stuff (which isn't supported by git-svn). Just ignore it for now. 11:13
mikehh bacek: and manifest_tests fail - you need to run tools/dev/mk_manifest_and_skip.pl 11:15
bacek Which doesn't support git-svn yet :) 11:16
But feel free to run it and commit changes in branch
mikehh otherwise looks good - but t/tools/parrot_debugger.t still gives a backtrace (although it passes) - does not in trunk anymore 11:17
bacek mikehh: yeah. But I'm trying to avoid merge from trunk before finishing all jobs. Merges in svn is pain... 11:21
11:21 donaldh joined
dalek rrot: r40908 | bacek++ | branches/context_pmc3/MANIFEST:
[cage] Add context.h into MANIFEST
 11:24
nopaste "bacek" at 114.73.43.135 pasted "latest rakudo patch for mikehh++" (77 lines) at nopaste.snit.ch/17767 11:25
bacek mikehh: rakudo should build seamlessly on r40908 with nopasted patch.
11:29 sri joined 11:31 AndyA joined
dalek rrot: r40909 | mikehh++ | branches/context_pmc3 (2 files):
set svn properties as per t/distro/file_metadata.t failures
 11:34
rrot: r40910 | mikehh++ | branches/context_pmc3/include/parrot/context.h:
fix svn properties on include/parrot/context.h
 11:44
rrot: r40911 | mikehh++ | branches/context_pmc3/MANIFEST:
run tools/dev/mk_manifest_and_skip.pl to fix manifest_tests failure
mikehh and again from the newly added files - need to fix more properties :{ (mind you easy karma) 11:46
dalek rrot: r40912 | mikehh++ | branches/context_pmc3 (2 files):
fix svn properties on src/pmc/context.pmc and t/pmc/context.t
 11:58
mikehh bacek - apart form src/jit/i386/jit_defs.c with c++ comments codetest now passes and manifest_tests - the rest PASS 12:04
how do you apply the patch specifically - not too sure of git patching 12:07
12:14 JimmyZ joined
Coke bacek: you can build parrot optimized with debug, at least with gcc: "Configure.pl --optimize --ccflags=-g" 12:26
chromatic++
Anyone want to fix my segfault before parrotsketch so my report is all hugs and puppies? 12:27
NotFound Coke: What segfault?
purl segfault is, like, xkcd.com/371/
Coke TT #960 12:29
12:30 ingy joined, mmpf joined
NotFound Coke: I no longer have that failures 12:30
12:31 payload joined, TimToady joined
Coke NotFound: hurm. any idea which revision fixed it? 12:32
updating parrot to double check. (also, try running with --gc-debug)
NotFound Coke: r40897 was the last related change 12:33
Coke ok. I'm about six behind that; checking... 12:34
NotFound r40893 was the key 12:35
12:35 quek joined
Coke so, what, something got recycled, had a custom mark, and then that inappropriate mark got invoked when the new pmc was checked? 12:35
NotFound Looks like there was something like that, yes. 12:36
I'm thinking that we need a 'dead' PObj flag
For things that have been destroyed but aren't yet in a free list 12:37
BTW, I can't #ps today. My report is: fixing, fixing, fixing ;) 12:39
Coke NotFound: I can no longer duplicate the segfault; feel free to claim the ticket and close it and give yourself a cookie! 12:40
NotFound++
NotFound Coke: don't have time today, feel free to close yourself
12:42 spinclad joined
Coke NotFound++ 12:43
dalek TT #960 closed by coke++: segfaults in Parrot_String_mark
12:46 sri joined
dalek rtcl: r651 | coke++ | wiki/ParrotIssues.wiki:
this ticket's bug is fixed, just waiting on a test; we don't need to track it
 12:46
rtcl: r652 | coke++ | trunk/runtime/builtin/info.pir:
use more .const
 12:57
rtcl: r653 | coke++ | trunk/runtime/builtin/info.pir:
move 'body' inline
rtcl: r654 | coke++ | trunk/runtime/builtin/info.pir:
make 'args' inline
rtcl: r655 | coke++ | trunk/src/macros.pir:
Add macro for setting up an iterator.
rtcl: r656 | coke++ | trunk/config/PARROT_VERSION:
There are many fewer segfaults here, NotFound++
rtcl: r657 | coke++ | trunk/runtime/builtin/info.pir:
inline all the [info subcommands]; cleanup PIR.
rtcl: r658 | coke++ | trunk/runtime/ (25 files):
PIR cleanup (also, more macros)
Coke wonders why "# vim: ft=tcl :" isn't working. 13:04
13:08 quek left 13:13 ruoso joined 13:16 mikehh_ joined 13:22 TiMBuS joined 13:23 mikehh joined 13:27 bkuhn joined
mikehh bacek_at_work: ok rakudo passed make test and make spectest with the patch on parrot from the context_pmc3 branch 13:33
and partcl r658 PASSes make test for that matter (forgot to install trunk parrot) :-} 13:36
dalek kudo: 4c08564 | mberends++ | src/setting/Temporal.pm:
[Temporal.pm] replace soon-to-be-deprecated int() with floor()
 13:45
Coke NotFound++ 13:46
14:00 PacoLinux joined 14:04 whiteknight joined 14:15 Zak joined 14:17 Psyche^ joined
Coke NotFound++ 14:32
14:37 Andy joined 14:40 jhorwitz joined 14:41 JimmyZ joined
mikehh All tests PASS at r40912 (pre/post-config, smoke, nqp_test, fulltest) - Ubuntu 9.04 amd64 (gcc) 14:41
partcl r658 builds on parrot r40912 - make test PASS - Ubuntu 9.04 amd64 (gcc) 14:42
(and also on the context_pmc3 branch) 14:43
rakudo (4c08564) builds on parrot r40912 - make test / make spectest (up to r28156) PASS - Ubuntu 9.04 amd64 (gcc) 14:54
decnum_dynpmcs r181 builds on parrot r40912 - make test PASS - Ubuntu 9.04 amd64 (gcc) 14:57
Coke NotFound: down to 8 segfaults in spectest, some of which were long standing. 15:18
2 of the segfaults have turned back into memory panics; but that reclaimed a lot of passing tests. 15:20
15:21 donaldh joined
dalek rtcl: r659 | coke++ | wiki/SpecTestStatus.wiki:
Unfudge a lot of tests after NotFound++'s segfault fix in parrot.
 15:24
jrtayloriv PMC "headers" are an outdated concept related to when things used to be split into PMC and PMC_EXT right? 15:25
Or is that term referring to something else?
15:26 frodwith joined
jrtayloriv Or, rather: since get_new_pmc_header() from src/pmc.c is not being used anywhere, can we just remove it? Aren't we always just using the pmc_new_* functions now? 15:28
oh -- nm, I see now that pmc_new is still using it :) 15:29
NotFound jrtayloriv: is just a name, if you have a better idea we can change it 15:31
15:32 payload joined
dalek TT #700 closed by doughera++: dynpmc/Makefile problem on Solaris 8/SPARC at r39040 15:40
16:02 cotto joined 16:15 whiteknight joined
cotto good mooring 16:17
16:17 darbelo joined
masak oh hai. Close seems like a really nice thing. is there some way I could contribute to it? 16:22
cotto seen austin 16:23
oh noes. the bot got eated.
masak "step 1. get ahold of austin", it seems. good to know he's on IRC. 16:24
cotto yup. austin is Close's primary developer.
masak austin++
darbelo Maybe someone finally got fed up with purl an killed her. 16:25
rg (14:40:20) purl left the room (quit: Killed (warewolf (reconnect to a server that isn't going down purl))).
masak darbelo: :D
darbelo wanted to a few times. 16:26
masak I couldn't help but notice that the README file, updated two months ago, refers to two files in docs/ that aren't there yet. so I thought maybe I could help with that.
rg looks like purl needs a bit of a push to reconnect (or be told a different server) 16:27
darbelo Say, does PIR have anything like system() ?
pmichaud can open a pipe
to a process
16:28 chromatic joined
pmichaud github.com/rakudo/rakudo/blob/9bcba...system.pir 16:29
oh, wait, that doesn't look right
it's pretty close. If you want to capture the output you need to open a pipe.
Rakudo does that for the qx{...} term 16:30
16:30 mokurai joined
pmichaud github.com/rakudo/rakudo/blob/9bcba...ins/io.pir (the !qx sub) 16:31
darbelo Hmm, Thinking better about it, I don't really care about the output, just want to run a program.
pmichaud then either of those should work :)
#ps in 118 16:32
16:45 ash_ joined 16:53 kjeldahl joined
Coke hopes he can finish this spec test run before parrotsketch. 17:06
pmichaud: I was having a lot of segfaults before notfound's recent work; were these not affecting you, or have you been slow to track parrot revs?
17:07 iblechbot joined
Coke (I've been trying to update more frequently after 1.5.0, as I've had a bunch of different problems, and each step forward has resulted in other breakages, so I have to keep moving forward. =-) 17:12
moritz I haven't seen segfaults in rakudo in the last two weeks (when tracking parrot HEAD) 17:14
17:14 theory joined
dalek rtcl: r660 | coke++ | wiki/SpecTestStatus.wiki:
missed one constraint failure.
 17:17
Coke moritz: not surprised if we're tickling (HA) different core errors. 17:18
whee. all the spec tests we can run (whether or not any tests pass) are now up 93 test files, 7397 individual tests, passing 3363, in 6651 seconds. 17:20
(that's a new record of passing tests) 17:21
(up from 2972 on 6/13 of last year.) 17:22
NotFound++
Now if I can get patrick to look at that PGE ticket, I can get about 400 more tests counted... =-) 17:23
<- greedy
(er, 6/13 earlier this year.) 17:24
mikehh Coke: seem to get 1 - !! child died with signal 11, without coredump - mathop - after ==== mathop-24.2 FAILED 17:26
whiteknight mikehh: stop bearing bad news!
If Coke is happy for once, let him be!
Coke no, that's fine; thanks. confirmed. Missed that one in the spec test list. (so, it ran it, it failed, and it wasn't counted at all; it just made the test run slower but doesn't impact any of the other numbers.) 17:27
mikehh++
mikehh that's down from 3 yesterday - which was an improvement
Coke mikehh: and we should have added a bunch of new ones. 17:28
s/ones/tests that run to completion/
mikehh all other tests repoort or are skipped 17:29
Coke added it to the skip list for next time.
next step is to make sure there are parrot tickets for each of the remaining segfaults. (except perhaps binary, which is one of the few places we use C code in partcl.)
mikehh I make ir #ps in one hour 17:30
dalek rtcl: r661 | coke++ | wiki/SpecTestStatus.wiki:
missed one segfault (mikehh++ for pointing it out.)
 17:32
17:34 Zak joined
Coke ps? 17:39
17:42 AndyA joined
Util #ps in 41 17:49
Coke partcl.blogspot.com/2009/09/now-pas...tests.html 17:53
jonathan Coke++ # nice :-) 17:54
moritz aye
18:00 joeri joined
dalek TT #961 created by coke++: segfault in Parrot_oo_find_vtable_override 18:06
rtcl: r662 | coke++ | wiki/SpecTestStatus.wiki:
link to ticket.
 18:10
18:16 eternaleye joined 18:18 AndyA joined
dalek kudo: 39c3f4b | (Solomon Foster)++ | (5 files):
infix:</>(Int, Int) creates a Rat, infix:<div>(Int, Int) an Int, as per latest S03

Fix Rat.perl to return "N/M" rather than "Rat.new(N,M)". Switch GCD routine to use % instead of -, for a vast performance increase on widely mismatched numbers. Add Rat * Int, Int * Rat, Rat / Int, and Int / Rat overloads. Patch mostly by colomon++, with some minor contributions and cleanups by moritz See RT #68898 for discussion.		 18:21
kudo: 4b9cd2d | moritz++ | docs/ChangeLog:
[docs] ChangeLog updates
Coke mikehh: ww? 18:35
mikehh Coke am running make spectest again - up to parse 18:37
18:39 Tene joined
jrtayloriv whiteknight, If you've got a few minutes later, can you 'make test' and commit (assuming everything works for you too) the changes I made to kill_parrot_cont branch, so I can continue working on it? 18:49
whiteknight, I'm passing all tests on x86_64 linux now.
whiteknight jrtayloriv: I won't be able until I get home unfortunately
jrtayloriv whiteknight, no prob -- I'm in no rush, just wanted to let you know I've got the patches added to the ticket. 18:50
whiteknight yes, I did see that, just haven't had a chance to work on it 18:52
18:58 purl joined 18:59 bacek joined
dalek TT #962 created by coke++: segfault in Parrot_Object_assign_pmc 19:00
whiteknight would be very happy to see SVN properties disappear 19:04
cotto clock?
purl cotto: LAX: Tue 12:04pm PDT / CHI: Tue 2:04pm CDT / NYC: Tue 3:04pm EDT / LON: Tue 8:04pm BST / BER: Tue 9:04pm CEST / IND: Wed 12:34am IST / TOK: Wed 4:04am JST / SYD: Wed 5:04am EST /
cotto good morning, bacek 19:05
duk3leto would be very happy to see SVN disappear
chromatic We can't get rid of SVN any time soon, but I'd like to get rid of the properties.
duk3leto chromatic: I can live with that.
+1 to making it so that a developer doesn't need to manually set svn properties after adding a new file 19:06
chromatic Or at least shuffle them off to where they're not easily forgettable busy work that cause more busywork test failures than the test failures we originally added them to prevent.
whiteknight In my time with Parrot, the only interactions I've had with properties is forgetting to set them and being yelled at for the test failures
japhb yes, I would favor that -- assuming that getting rid of them won't result in svn being stupid.
whiteknight they have provided me no benefit whatsoever
duk3leto the only use for properties I have had is setting certain files to binary so that "svn diff" doesn't throw garbage on my screen 19:07
chromatic There are a couple of IO tests that need platform-specific newlines. That's the only case where I can think of that we need SVN properties.
japhb allison asked to log here that she was in favor of exploring server-side hooks
mikehh what about the svn:keywords - they put the latest info at the top of the file - or is there some other way of doing that
Coke that should be enabled for all non-binary files.
and I'm pretty sure we can set a hook and forget it. 19:08
Util I am willing to tackle the server-side hooks. What access do I need? 19:10
Coke do the research, come up with a plan, have someone with ssh access pull the the trigger? 19:11
chromatic I think just file a bug with OSU, once you have something you think will work.
Coke (or we get you access to the VMware box running the parrot.org stuff )
chromatic: oh, right, make them do the work.
+1
purl 1
Util Coke: will do (research/plan) 19:12
dalek rtcl: r663 | coke++ | wiki/SpecTestStatus.wiki:
Edited wiki page through web user interface.
 19:15
Coke whiteknight: also look at lightning. 19:20
chromatic Lightning is definitely an inspiration.
whiteknight yes, I intend to look closely at lightning, libJib, LLVM, etc
I think an ideal solution would be a pluggable API that supports all of these
19:20 donaldh joined
moritz aye; but don't overdesign ;-) 19:21
duk3leto can anybody recommend some introductory JIT reading materials? 19:24
japhb Note that the browser people have done a metric ton of work on JIT over the last couple years, so they have fresh eyes on the problem (and are seriously kicking butt, I might add)
duk3leto, I'd honestly look at the developer wikis for the free web browsers
duk3leto japhb: good tip, thanks 19:25
moritz V8, tracemonkey might be worthy to look at
Coke I wonder if I should be using a different core to speed up partcl work. 19:26
japhb moritz, and Nitro (aka SquirrelFish Extreme)
whiteknight Coke: fastcore is the best in profile numbers I've seen 19:27
Coke is there a way to make it the default core in a) built parrot and b) fakecutables? 19:28
chromatic Fakecutables, easy.
Built Parrot, possible. Do you mean globally or as a configurable default?
Coke I just want to have the fastest core running when I say "parrot" 19:29
whiteknight A good JIT system would allow us to build proper binaries too, not fakecutables
like what our exec core was supposed to be, I think
chromatic There's another core we could probably yank....
whiteknight "probably should" FTFY
19:30 uri joined
jonathan I think if you yank the jit core you pretty much have to yank the exec one with it. 19:30
japhb FTFY?
whiteknight fixed that for you
jonathan: probably
Coke added 2 segfaults to trac...
japhb whiteknight, heh
19:30 uri left
moderator www.parrot.org | Improve test coverage for Array and NameSpace / Fix Segfaults for Coke / Merge Stable Branches for 1.6 SOON 19:32
moderator www.parrot.org | Improve test coverage for Array and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON 19:33
duk3leto the Factor language has some interesting things to say about JIT: factor-language.blogspot.com/search?q=JIT 19:34
particle did somebody once have a script that displayed the type of pmc's used in a program, and how many were created? 19:35
chromatic My thought for Lorito is that a tracing JIT is the way to go, especially if we can do aggressive inlining.
particle it might help to improve our test coverage by starting on the most frequently used pmc types
whiteknight my big "killer feature" for lorito is that we can write ops definitions once and generate the C code and JIT defs automatically from that 19:36
particle i gather those are FixedIntegerArray, Hash, Key, Sub, and Namespace
whiteknight no more having to make symetric edits to keep things lined up
mikehh pmichaud: ping
pmichaud pong
chromatic Namespace is in the list. I put Array in there because other array types extend it.
treed What about ResizablePMCArray? 19:37
mikehh pmichaud: I was testing the context_pmc3 branch for bacek++ and he had a patch to make rakudo pass all tests
treed kibbitzing
chromatic I think it extends Array too.
treed Oh, wait, this is #parrot not #parrotsketch 19:38
pmichaud mikehh: I don't think I've seen the patch yet
mikehh pmichaud: I was just wondering how do we maintain backward compatibility say with 1.5
pmichaud mikehh: I don't understand 19:39
if you're asking if we can apply the patch to existing Rakudo, and the patch causes us to no longer build against Parrot, then the answer is that we can't
you can make a branch of Rakudo master and apply the patch there 19:40
but until the context_pmc3 branch lands in Parrot trunk, Rakudo master can't/shouldn't build against it
mikehh pmichaud: nopaste.snit.ch/17767
pmichaud (i.e., we don't want Rakudo master to be tracking a Parrot branch)
mikehh no - the patch works in the branch - if the branch is merged what happend if you build the latest rakudo against say 1.5 19:41
cotto particle, I had something like that.
pmichaud mikehh: that's no problem (more) 19:42
it's already the case that Rakudo head doesn't build against Parrot 1.5
that usually happens just a few days after release anyway
mikehh ah - ok I see that now
pmichaud that's why we have the PARROT_REVISION marker; it allows Rakudo finer control over the exact version of Parrot being used to build it (in the common case) 19:43
moritz aye, only Rakudo releases target parrot releases
mikehh I was just worried that the latest wouldn't build against earlier parrots
pmichaud that's already the case. Rakudo development still has a higher velocity than Parrot's monthly release cycle
cotto chromatic, I don't think anything extends Array. 19:44
chromatic Maybe it's FixedPMCArray they extend.
particle nothing uses Array, just Fixed*Array
pmichaud eventually we hope that things will slow down enough that Rakudo development can only target Parrot monthly releases (and then eventually just Parrot supported releases) 19:45
particle which Resizeable*Array extends
pmichaud and MultiSub extends ResizablePMCArray, iirc
19:45 eternaleye joined
moderator www.parrot.org | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON
whiteknight who is releasing 1.6, particle? 19:46
particle FixedIntegerArray is used in every pcc call
yep, me
Coke particle: I had a macro that dumped how many pmcs were allocated, but we don't know what types. 19:47
pmichaud (release targeting) but so far Rakudo hasn't been able to go for very long based on a Parrot release (more) 19:48
I suspect this is due to the deprecation policy itself. Suppose that Rakudo development is blocking on feature XYZ in Parrot. 19:49
cotto particle, it'd be pretty easy to edit include/parrot/vtable.h to add some code to the VTABLE_init and VTABLE_init_pmc macros. IIRC that's what I did.
pmichaud And feature XYZ in Parrot is blocking on a deprecation cycle
actually, let's put actual dates here
suppose Rakudo development is blocking on XYZ
and XYZ is blocking because it requires us to give a deprecation notice in January 2010
which means doesn't exist until the January 2010 release 19:50
mikehh Coke: partcl make spectest - all test now either complete of are skipped
pmichaud that means that if we say that Rakudo is tied to working against monthly releases, the earliest we could make use of XYZ is February 2010
chromatic That only gets PMCs which use those vtables, not the ones that go through instantiate instead. 19:51
pmichaud if we say that Rakudo is tied to working against supported Parrot releases, the earliest we can make use of XYZ is July 2010
blocking 10 months on Parrot is not a viable option for us.
Coke mikehh: woot.
whiteknight is relatively unhappy with the current deprecation policy, but won't fight about it 19:52
pmichaud some for me, but s/relatively//
*same
mikehh I think chromatic is too :-}
Coke I think having /a/ policy is sane; i think our current version over-estimates our user base.
mikehh moi aussi
whiteknight I'm not sure what to replace it with, we do need somekind of policy so we don't rip the rug out from under our users 19:53
but waiting 6 months for major developments, when so many of our current systems are in need of major refactoring if not complete replacement as soon as humanly possible, is not good
mikehh cardinal users are v. upset at the moment
whiteknight mikehh: upset about what?
or, what specifically 19:54
pmichaud anyway, I've been told that revisiting the deprecation policy is not really open for discussion, so I'll drop it here.
Coke note that, in general, deprecation blocks removals and incompatible updates, not new things.
pmichaud Coke: it blocks refactors.
and some new things depend on refactors
Coke depending on what's been exposed, sure.
whiteknight Coke: it's been blocking enough new things that it's worth reconsideration
moritz who controls cardinal2.rubyforge.org/?
it's very out of date
Coke But I suspect that we could come up with a way to add something new without removing the old. 19:55
mikehh test failures with cardinal which were passing fine before some brach merges
Coke mikehh: ah, just like me. =-)
if we have to make something pluggable to support both the old and the new, make the old the default until the deprecation point, athen change the default, then rip out hte old stuff, that seems like it should be possible.
pmichaud Coke: (1) doing that seems to slow down our development significantly, and (2) we don't have a good success rate even when we've attempted to do that
whiteknight yeah, the branches merging this month were more disuptive then normal 19:56
mikehh I think treed is the principal at the moment
whiteknight of course, they are making some seriously-necessary changes
moritz purl: cardinal?
purl i heard cardinal was mail.freesoftware.fsf.org/pipermail...dinal-dev/ or the Ruby-on-Parrot project. or xrl.us/uyz3
pmichaud Coke: per the situation I just gave before, if "rip out the old stuff" can't occur until after January 2010, then projects wanting to target "supported releases" are blocked until July 2010. 19:57
particle slowing down our development has improved our product stability
mikehh there is a #cardinal on this server just /join cardinal
pmichaud particle: I disagree.
Coke particle: can you show us any downstream users taking advantage of this stability? 19:58
particle i don't track any user stats
pmichaud particle: I know that for the 1.4 release I had to make emergency changes to Rakudo in order for its July release to be able to build against 1.4 19:59
particle if our api only changes in 6 month cycles, then it's more stable than it was
pmichaud "api only changes in 6 month cycles" is as yet a myth
Coke pmichaud: sure. I'm saying adding new things should not be blocked by removing old things, (I'm not saying it should be easy)
particle pmichaud: yes, due to a late merge of a branch
pmichaud particle: even if it had been an early merge, Rakudo would've been hosed in the same way
particle that's a policy that's under review
mikehh quite a few persons have developed an HLL on parrot and then come back to it later an it don't work anymore
Coke particle: I'm not disagreeing that it is /theoretically/ more stable; but that doesn't really help anyone I know developing against parrot. =-) 20:00
pmichaud and if we were following the "use a supported release policy" today, it would mean that Rakudo couldn't have a working 'make install' target until January 2010.
Coke (adding new things) (ok, it SHOULD be easy, but I'm not saying that it really is.) 20:01
particle pmichaud: you don't need to use a supported release 20:02
that's a policy for you, as rakudo dev, to set
japhb It's the refactor problem -- (I gather) Parrot is in need of much refactoring before adding new things is easy. But the refactoring is part of what is conflicting with deprecation policies.
pmichaud particle: that's Parrot's official recommendation as to what users (including HLL developers) should be doing, however.
chromatic I think the problem is the biannual releases, not the six month cycle per se.
pmichaud particle: you're correct that I can choose to ignore that recommendation, but that introduces impedance mismatch between Parrot and the needs of its (HLL) users 20:03
particle yes, clearly there is an impedance mismatch
pmichaud and the claim that this "increases stability" is not thus far borne out by actual experience 20:04
what it really does is "reduce volatility" by imposing delays on Rakudo developers. We still have huge changes, but they're spread out over long periods of time 20:05
mikehh what we need is a stable and "comprehensive" test suite that parrot needs to pass - then we can make changes etc and it *MUST* pass the test suite
whiteknight okay, we've all trashed the current policy enough. The question now is, what is the way to fix it?
japhb pmichaud, while I agree with you in general, do remember that a lot of committers are still learning how to work within a project that has this kind of deprecation cycle -- I would expect the first couple cycles to be a bit messy even if the policy was perfect.
whiteknight mikehh: we do need it to be a lot more comprehensive then it is
pmichaud japhb: I'm looking at the patch that mikehh showed me, and I see no way that the existing mechanism could possibly work 20:06
mikehh just look at recent merges - make test/fulltest PASSed but rakudo, partcl cardinal had failures
japhb pmichaud, fair enough -- I just doubt that impossibility applied to all of the places Rakudo had to jump the spinning knives of death 20:07
chromatic We need better Parrot test coverage, for one.
mikehh in rakudo's case it wouldn't even build at first
pmichaud I'm not claiming it applies to all Rakudo development, only that it applies to enough of Rakudo development to be a significant blocker for us
japhb
.oO( The less sleep I get, the more visual my metaphors become ...)
20:07 eternaleye_ joined
japhb pmichaud, nodnod 20:08
pmichaud shall I shut up now, or would it be worthwhile to look at a very specific change that I think really exemplifies the problem? 20:10
whiteknight pmichaud: do tell
duk3leto pmichaud: all ears 20:11
pmichaud from bacek's context_pmc patch for Rakudo:
mikehh +1
purl 1
pmichaud - Parrot_Context *ctx = CONTEXT(interp)->caller_ctx;
+ PMC *ctx = Parrot_pcc_get_caller_ctx(interp, CURRENT_CONTEXT(interp));
the context_pmc branch is changing the very API that is used to get at context information 20:12
mikehh that's for the context_pmc3 branch
pmichaud (yes, context_pmc3, thanks)
if someone says "oh, Rakudo was using internal data structures there", the answer is that there wasn't any other API available
if someone says "Rakudo should've waited until an API became available", the answer is that apparently won't appear until January 2010 20:13
sorry, *February 2010*
Coke I thought allison's answer was 'do it both ways until we can rip out the old one.'
20:13 hercynium joined
pmichaud if we say "oh, Parrot needs to support the old API", I don't see any way to reasonably do that 20:13
whiteknight pmichaud: we can add an API anytime, we don't need to wait for a deprecation point 20:14
so if you want an API, ask and ye shall receive
mikehh as long as we can test and patch - until we are really *stable* we still need to move forward
pmichaud whiteknight: okay, in this case we need an API that preserves the Parrot_Context structure
but the point of the branch is to eliminate the Parrot_Context structure
whiteknight pmichaud: replace it with a Context PMC with the same functionality
pmichaud whiteknight: that doesn't work for 20:15
20:11 <pmichaud> - Parrot_Context *ctx = CONTEXT(interp)->caller_ctx;
note that ctx is *not* a PMC
whiteknight so are you arguing for or against the branch?
pmichaud let's be clear, I'm very much in favor of the branch
whiteknight ok
jonathan #defone Parrot_Context PMC /* hey solved */
pmichaud jonathan: and PMC's have a caller_ctx element? 20:16
whiteknight pmichaud, you should never need to see Parrot_Context, take a reference to it, use it's fields directly, etc
pmichaud whiteknight: but the problem is that we *do*
Coke can't we #define CONTEXT(interp)->caller_ctx to do something?
whiteknight You should have a proper API that obscures all those things and provides you access to the data without concerning you over the structure of that data
pmichaud whiteknight: I agree we should have one. Parrot didn't.
whiteknight: at this point, Parrot still doesn't. 20:17
whiteknight no argument, but it will
chromatic Can't we argue over whether the color scheme of our website is offensive?
20:17 donaldh_ joined
whiteknight DAMNIT I HATE GREEN 20:17
Coke so i would argue that poking directly into struct guts is experimental.
pmichaud Coke: I'm fine with that.
whiteknight Coke: agreed 100%
Coke then it's a win win.
pmichaud However, the current claim is that the context_pmc3 branch can't land because existing applications depend on the old "API"
whiteknight wrong, there was no old API 20:18
Coke "poking into structs is not an API"
I think that's a reasonable argument to make.
pmichaud Coke: that's fine with me also
japhb Coke, Also a good slogan for a t-shirt or coffee mug
chromatic "Poking into structs" appears *nowhere* in the "What we consider valid deprecation targets" section of our support policy.
pmichaud in which case let's merge the branch and be done with it and not worry about trying to maintain backwards compatibility in this case
Coke japhb: not very catchy. kids'll never by it.
"buy"
pmichaud but afaict that is not what bacek++ has been told
whiteknight we can't merge the branch yet, there's a test failure on the JIT core 20:19
japhb Coke, what, you mean like the 'Geek.', 'code poet', and binary DAD t-shirts I own?
Coke chromatic: might be worth adding it to a new "don't you even think about it" section. or at least a section that apologize for the lack of an API.
whiteknight just made himself more angry
mikehh whiteknight: works fine on amd64 :-}
whiteknight mikehh: really? in the JIT core? 20:20
japhb whiteknight, I'm still in favor of Bessie.
whiteknight Bessie?
japhb whiteknight, no JIT core on amd64. ;-)
(the rifle)
mikehh of course - I run everything :-} ha ha
whiteknight oh right right, there is no JIT on x64
chromatic What happens when Everyone But Allison agrees on an idea?
pmichaud I'm simply saying that there appear to be times when Parrot cannot simultaneously adopt a new API and support an old one
chromatic The same as if Everyone But Patrick or Everyone But Coke or Everyone But chromatic agree on an idea? 20:21
mikehh whuich if we gonna use it we need something new
which
Coke chromatic: except for the "everyone but coke", I agree with you.
whiteknight Allison seemed more amenable to the idea last I talked to her 20:22
I don't want to speak for her, of course
pmichaud and when we cannot simultaneously adopt a new API and support an old one, we impose a 7-12 month delay on the downstream users that are depending on (features depending on) the new API
(less if they choose to target monthly releases instead of supported releases, but it's still a 1-5 month delay) 20:23
er, 1-6 month delay
dalek kudo: 0d6c42b | moritz++ | src/setting/Rat.pm:
fix infix:</>(Int, Rat)
chromatic Right. That's why I never liked and still don't like the biannual releases.
Coke I would tend to argue that if we had an actual API to change, we could support both. 20:24
mikehh that's just to fit in with upstream distros etc - not sure I agree
japhb The biannual releases might make sense for a project that is considerably more mature than Parrot is ... but this is too early. I partly blame the "need" to stamp "1.0" on it.
pmichaud Coke: suppose that CONTEXT(...) had been an actual API
Coke then it would have been a function call.
pmichaud Coke: the problem is not the macro, it's the fact that it relies on the Parrot_Context structure 20:25
so suppose that Parrot_Context is an actual API
one can claim that it's not a good API, and that's fine, but I posit that we have other APIs that are similarly flawed
mikehh well there are published api's and internal ones 20:26
maybe those should be dpi's 20:27
whiteknight we've never actually published a comprehensive API that we do support
chromatic Poking into structs is not an API, and any language that does that will have to follow trunk carefully until we have an API which obviates the need to poke into structs.
pmichaud chromatic: I agree fully. I'm fine with that.
whiteknight and it does seem weird that we support an API that we've never defined
duk3leto chromatic++
pmichaud chromatic: I'm not fine with trunk having to wait until January before it can get rid of the old API.
chromatic Exactly.
pmichaud (and get the new ones)
duk3leto (supporting undefined APIs)--
Coke chromatic++ for restating my point more cogently.
pmichaud I'll rephrase 20:28
chromatic Applying our deprecation policy to support backwards compatibility for poking into structs works against the goal of backwards compatibility.
pmichaud I'm not fine with trunk having to wait until after January before it can get the new API
jonathan Just because Rakudo pokes into them doesn't mean it's a supported API.
pmichaud I agree.
jonathan It just means Rakudo pokes into them.
pmichaud I agree.
chromatic I haven't read anyone disagreeing with that here now. 20:29
japhb Is anyone disagreeing at this point?
mikehh not at all
pmichaud I'll agree with anything that means that we can get new features into Parrot without having to wait 6 months to do it.
whiteknight That I am aware of, the only thing blocking the context_pmc3 branch from merging is the JIT failure
Coke there are 4 items in the support policy that we have to worry about. this isn't one of them.
japhb Well OK then. So the branch can land? (And any other branches holding on the same sort of non-API?) 20:30
whiteknight and I can't even really fix and test it, because I don't have JIT on my system
Coke =item * bytecode changes (opcode or core PMC removals, renames)
=item * PARROT_API function changes
=item * PIR or PASM syntax changes
=item * API changes in the compiler tools
pmichaud whiteknight: let me review the thread
whiteknight pmichaud: please do
japhb whiteknight, seriously, make --runcore=jit do --runcore=fast, and get on with our lives. That suggestion was not in jest. :-)
Coke (with the possible caveat that any PARROT_API items that return or take a struct are, for now, "experimental")
pmichaud lists.parrot.org/pipermail/parrot-d...02746.html 20:31
chromatic Right. Pointers returned from PARROT_API functions are *opaque*.
duk3leto It seems that if we had a way of running a script on the codebase of a parrot-based HLL, which would complain loudly and bitterly about things that are in DEPRECATED.pod or which poke directly into internals, we would be in a nice position to warn people downstream of impending changes that brake their code
pmichaud "Keep backward compatibility with the CONTEXT(interp) macro, by having it
return the data struct of the Context PMC. Introduce a new function
'Parrot_pcc_get_current_context' that returns the PMC (it's a clearer
name anyway), and we'll deprecate the old macro for 2.0. ...
---
I don't think this is possible. Perhaps I'm wrong.
whiteknight japhb: I agree 100%.
Coke kkkkkkkkkkkkkkkkkkkkkkkkkk1G:q! 20:32
chromatic It's incompatible with the 1.6 milestone of struct review.
pmichaud the fact that bacek's patch is asking Rakudo to get rid of its uses of the CONTEXT(...) macro tells me that bacek hasn't been able to do it yet, and that the branch is blocking on more than just JIT 20:33
It's clear to me that allison is asking backe to continue to support the API that was provided by the CONTEXT() macro. 20:34
*bacek
and that this should be done before the branch is merged.
moritz same here
pmichaud so we can all say "Parrot_context struct isn't part of the supported API", but this message appears to me to indicate otherwise. 20:35
chromatic That was my interpretation too.
pmichaud I'll be happy to be proved wrong.
chromatic Okay, hold on one moment then. 20:36
Util cotto: ping 20:38
cotto Util, pong 20:40
chromatic Okay. Now everyone can be mad at me. 20:41
whiteknight chromatic: I could never be mad at you!
(and why should we be?) 20:42
chromatic r40913
dalek rrot: r40913 | chromatic++ | trunk/docs/project/support_policy.pod:
[docs] Clarified Parrot components not subject to our deprecation policy.
 20:44
pmichaud that doesn't make me at all angry.
whiteknight chromatic: that commit makes me very happy with you 20:45
pmichaud I think it accurately codifies our majority expectations for how things work
(I include myself in the majority that agrees with that aspect of the deprecation policy)
duk3leto chromatic++ for adding scary language to the support policy
jonathan +1
purl 1
Util chromatic++
chromatic Now about that --runcore=fast idea.... 20:46
japhb chromatic++
whiteknight I would love to do that
keeps functionality the same as far as the user is concerned, improves performance, and brings "JIT" to all supported platforms
pmichaud Now I await to see if r40913 has any hope of making context_pmc3 land quicker, or if we still end up having to support CONTEXT() 20:47
whiteknight I see no downside, besides the disappointment that a feature might not internally be implemented in a way that it's name suggests
chromatic The only reason I can think of to keep the JIT around is to say "We have a JIT", which is a bad reason because it's mostly a lie.
whiteknight It's definitely a lie. I've never had it 20:48
Util Coke: 174 minutes for Partcl's `make spectest`. Is this time roughly normal?
japhb whiteknight, we can easily tell people in the release notes that --runcore=jit is now a (more intentional) lie, and we can tell them why -- because we don't want existing scripts and/or habits to break while we rewrite the JIT engine, which is true and happy-making. 20:49
whiteknight it's certainly a less disruptive change then having the PASM1 compiler throw an exception and do nothing else
nopaste "pmichaud" at 72.181.176.220 pasted "just to make sure my position is clear" (29 lines) at nopaste.snit.ch/17770 20:50
japhb "We're about to frob the guts so seriously we can't avoid breaking things if we still had --runcore=JIT run the old core, so we won't -- you'll just be happy and stable until we get to the Better Place."
whiteknight After the runcore branch lands (ETA on that?) We should start a proof-of-concept branch to replace --runcore=jit with the fastcore
moritz Util: are you also 'Util' on github? 20:52
chromatic Trivial after the runcore branch lands.
Util moritz: Yes 20:53
moritz Util: would you like commit access to perl6-examples? you currently fork it, and I don't know how attentive the maintainers are
whiteknight my point being that it's easier to argue for particular semantics when you have a patch in hand that implements them
Util moritz: Yes, thanks. 20:54
moritz Util: done
chromatic A benchmark that demonstrates that the fast core is faster than the JIT core wouldn't hurt either.
Util Thanks!
pmichaud hugs moritz++
whiteknight: how hard would it be to come up with a patch that removes the JIT core ? 20:57
whiteknight pmichaud: in terms of changing --runcore=jit to use the fastcore instead, trivia 20:58
pmichaud oh wait, scratch that
whiteknight trivial
pmichaud yes, that's the patch I'm thinking of
if we changed --runcore=jit to use fastcore, would that resolve the remaining issue with the context_pmc3 branch?
whiteknight in terms of actually removing the JIT system wholesale, it will be more "fun" and less "work"
japhb chromatic, any benchmark that causes core switching when run with JIT and doesn't just devolve to native int and num manipulation should do. (Mind you, I'm still in the "broken == infinitely slow" camp on this one.)
whiteknight pmichaud: yes it should
pmichaud and it wouldn't introduce any other visible stability issues? 20:59
(other than things might become much more stable, that is :)
japhb I would volunteer to write said benchmark, but I'm valiantly trying to progress against @dayjob_deadlines at the moment,. 21:00
whiteknight that I am aware of, no
pmichaud look, I have a good JIT versus non-JIT benchmark -- my desktop is currently running i386
and I can certainly run a rakudo spectest both with and without jit
and rakudo spectest exercises a *lot* of Parrot
we can also time 'make test'
so, since I appear to be in an irascible(sp?) mood anyway, I propose we run the timings, and then jfdi with the switch from --runcore=jit to --runcore=fastcore 21:01
21:01 MoC joined, bacek joined
japhb +1 21:02
purl 1
chromatic Excellent.
whiteknight agreed
duk3leto pmichaud++
whiteknight land the runcore branch first, then the switch will be easy
pmichaud if anyone complains, then we know it's time to see what we need to do to fix the JIT capability to work with the new features that are landing
chromatic pmichaud, does the Rakudo spectest suite use the fakecutable or execute Parrot directly?
pmichaud and at that point we can ask ourselves "is this really worth it?" 21:03
chromatic: it currently uses the fakecutable, but it's an easy patch (env setting, I think) to get it to use Parrot instead
checking
export HARNESS_PERL="parrot_install/bin/parrot perl6.pbc"; make spectest # should work 21:04
testing
yes, it works.
oh, wait, it appears to still be using the fakecutable
chromatic Patch forthcoming. 21:05
pmichaud oh, it's hardcoded in t/harness
nopaste "chromatic" at 72.87.39.97 pasted "-t" (12 lines) at nopaste.snit.ch/17771 21:07
pmichaud changing line 59 of t/harness seems to do it
whiteknight dreams of the day when we can generate a real executable from a functional JIT system 21:08
pmichaud does --runcore=fastcore passed to Parrot suffice to select the core I want to use?
whiteknight then we can forget about all this "fakecutable" nonsense
pmichaud: yes
pmichaud okay.
let me set up some timings here locally and I'll report back 21:09
chromatic whiteknight, any objections to bumping up initial PObj pool sizes by an order of magnitude?
whiteknight I have objections to not doing it 21:10
I suggest we pick a more sane number then X / sizeof(PMC), because we want pool sizes to be the same on x86 and x86_64
but in the interim an increase of 10x should do it
chromatic Let me give you a quick benchmark then.
whiteknight I'm about to sign off and go home from work 21:11
msg them to me?
purl Sorry, I've never seen them before.
japhb whiteknight, when you say pool sizes the same,
whiteknight I mean number of PMCs
not size in bytes
japhb do you mean same number of PMCs in pool?
ah yes, that's what I thought
whiteknight was too ambiguous
japhb good $commute
whiteknight later 21:12
bacek Good morning 21:14
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
darbelo Tested the context_pmc3 branch on OpenBSD getting a segfault on t/pmc/context.t is this a known issue?
Heh. That was good timing.
bacek darbelo: :)
pmichaud is there an easy way to verify that I'm running Parrot with the jit core? 21:15
(e.g., from PIR)
bacek darbelo: it shouldn't fail... It's just creating new Context PMC...
pmichaud: "running core" isn't exposed into PIR afaik 21:16
pmichaud not even in the interpreter object?
darbelo Wait a sec, I just noticed something... Let me get back to you in a sec.
japhb Hmmm, for some reason I thought it was exposed through interpinfo or something. Or maybe we just discussed that last year ....
duk3leto pmichaud: sounds like there should be but isn't 21:17
japhb .macro_const INTERPINFO_CURRENT_RUNCORE 14
There you go.
chromatic Yep, it's in interpinfo.
mikehh darbelo: it doesn't fail for - it passes no problemo 21:19
there should be a me before the - 21:21
pmichaud is there a list of the interpinfo runcore values somewhere?
I'm getting back a value of 0
japhb wonders if the key exists but no one is home (meaning INTERPINFO_CURRENT_RUNCORE never gets set) 21:22
chromatic 0 is the slow core. 21:23
darbelo I remember somebody saying here that string->strstart was TEH EVILZ! What should be used in it's place? 'cause evil or not, it's pretty damm convenient :)
pmichaud okay, so 'parrot' defaults to the slow core even when jit is available?
chromatic Yes.
pmichaud 16 looks like the jitcore then 21:24
and then, fwiw, Rakudo appears to segfault when run with the jitcore
(on my system)
japhb \\o/
pmichaud so no chance of --runcore=jit being much improvement for Rakudo :0| 21:25
japhb ... which brings us back to "broken == infinitely slow" 21:26
darbelo Somebody should talk Coke into trying JIT on partcl, see how many segfaults it adds :)
moritz broken = terminates very soon ;-)
pmichaud no, it still takes a bit of time to terminate
japhb moritz, heh
pmichaud the fastcore finishes much quicker than it takes the jit core to terminate 21:27
japhb "We now finish the benchmark *much* sooner than before. Too bad that's because it dies partway in ...."
LOL
OK, I think that's pretty much conclusive evidence right there, pmichaud.
nopaste "pmichaud" at 72.181.176.220 pasted "rakudo timings for fast, slow, and jit cores" (19 lines) at nopaste.snit.ch/17772 21:28
bacek yak.... 21:29
japhb Interesting how little the fast runcore helps you there.
pmichaud most of the cost is startup
jonathan bwahaha...
chromatic The more bytecode, the slower our "JIT" will run.
darbelo The fast core *finishes* faster than the JIT *segfaults*. 21:30
jonathan 13 seconds extra just to generate a segfault :-)
darbelo That is seriously broken.
jonathan but...but...this is the jit that ran a micro-benchmark faster than gcc -O3! ;-)
japhb darbelo, which is exactly what we've been trying to tell Allison at #ps today 21:31
s/we've/we had/
pmichaud running Parrot's "make test" for comparison
darbelo I wasn't paying attention to #ps today, just now started reading the logs.
japhb darbelo, No worries ... I was just confirming. 21:32
chromatic I think that microbenchmark would run even faster now. 21:33
... but that's because of startup time improvements, not JIT improvements.
japhb "Runs so fast it strips tiles off the space shuttle! (Wait, what? That's *bad*? Oh, crap.)" 21:34
Must ... dial ... back ... fist ... of ... death ....
pmichaud stripping tiles off the space shuttle is bad only for re-entry 21:35
once it's landed, stripping tiles is a good thing :)
darbelo Both points are irrelevant if the JIT explodes during take off :) 21:36
dalek kudo: ba10463 | last.of.the.careless.men@gmail.com++ | src/setting/Rat.pm:
Move Rat.Str to new standard, add Rat.nude.
 21:38
japhb Nude Rats? OKAY .... 21:40
pmichaud thankfully *that's* not the Perl 6 mascot :)
nopaste "pmichaud" at 72.181.176.220 pasted "make test timings for fast, slow, and jit core" (15 lines) at nopaste.snit.ch/17773 21:41
pmichaud that's not really as valid a test as rakudo spectests might be, though. 21:42
because it's a bit biased against the jit
japhb Interesting ... though I suspect that's a matter of Parrot tests overemphasizing native types.
moritz how many tests are skipped in 'make testj'? more than in the other cores? 21:43
pmichaud well, jit should show better performance with loops and the like, and I suspect the Parrot test suite doesn't have many of those
chromatic The slow core runs a lot more tests.
darbelo bacek: I'm still getting the failure. 21:44
bacek darbelo: nopaste backtrace?
darbelo: (but Context PMC created very often... So I can't even imagine why it can fail...) 21:45
jrtayloriv join #parrotsketch
oops -- sorry :)
pmichaud oh, looks like 'make testj' doesn't run the NQP tests
bacek jrtayloriv: too late :)
jrtayloriv bacek, just wanted to see topic
mikehh try testb
darbelo nopaste? 21:46
purl i guess nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo
bacek darbelo: nopaste.snit.ch/parrot will save you few milliseconds :) 21:47
nopaste "darbelo" at 200.49.154.172 pasted "backtrace for bace++." (83 lines) at nopaste.snit.ch/17774
darbelo bacek++
bace-- 21:48
there, now that karma is where it belongs.
mikehh just look what posting about g++ does for g's karma 21:49
moritz g--
darbelo (g++)-- 21:50
mikehh karma g 21:51
purl g has karma of 620
darbelo mikehh: you and NotFound are to blame for most of that :) 21:52
21:52 joeri left
mikehh for someone not here he/she/it is doing very well 21:52
g I have lots of karma. WHEE! 21:53
all your karma is belong to me.
mikehh see if you took it with you :-} 21:54
bacek darbelo: yay! Good catch for Context.
treed So, was it ever determined whether the get_pmc_keyed thing was StringIterator breaking again? 21:55
bacek darbelo++ # using some strange architecture
dalek rrot: r40914 | bacek++ | branches/context_pmc3 (2 files):
[cage] Don't mark non-initialised Context. darbelo++
darbelo Catch what? I have no clue why that pointer is NULL.
bacek treed: Yes. After merge keys_revamp branch
darbelo: I have :) 21:56
nopaste "pmichaud" at 72.181.176.220 pasted "make test timings for fast, slow, and jit core (revised)" (24 lines) at nopaste.snit.ch/17775
treed bacek: Is that actually breakage, or was something deprecated out?
bacek pmichaud: looks suspicious. 21:57
japhb fast and slow are within .5% of the same? That sounds swamped by startup time or so.
pmichaud agreed
bacek treed: something that wasn't covered in test suite. So, actual breakage.
treed Ah. Is there an issue assigned?
chromatic The difference between fast and slow is that slow does bounds checking of the program counter. That's about it.
treed (Or is the fix expected soon/already in?)
bacek treed: it should be fixed already.
treed k
treed is pulling down parrot svn now 21:58
particle you can switch from slow core to trace core, can you do that from fast core?
japhb chromatic, I thought "fast" also picked the fastest variant of switch, cg, cgp, etc.?
Or is that out of date?
bacek treed: if it still broken - create ticket and assign to me. I'll fix it tonight. 21:59
treed bacek: k
chromatic I don't believe it does.
nopaste "pmichaud" at 72.181.176.220 pasted "NQP make test timings for fast, slow, and jit core" (24 lines) at nopaste.snit.ch/17776 22:00
pmichaud anyway, take those for whatever they're worth. It's a bit disappointing that we can't do a similar test with Rakudo. (sigh) 22:01
japhb pmichaud, that's one of the things that drives me mad about the current JIT -- for simple to medium stuff, it can be coerced to work. Through some real meat and it, and *boom*. 22:02
But then you can't make a minimized test to demonstrate the problem ....
er "Throw some"
darbelo bacek++ # context_pmc3 shows "All tests successful" on OpenBSD amd64. 22:08
treed bacek: Yeah, still borked. I'll make a ticket.
mikehh bacek: cardinal has three failed to compile tests with error - get_pmc_keyed() not implemented in class 'String' 22:09
treed mikehh: Yeah, that's what I was just talking about.
There's also a warning printed during tests about double free.
Which isn't related (AFAIK), but might be worth looking into.
bacek String or StringIterator?
treed It's String, but as far as I know, we don't even call get_pmc_keyed on String ourselves. 22:10
The last time I got that error message, I tracked it down to StringIterator.
mikehh bacek: that's in trunk - with the context_pmc3 branch there are a loads of failures in make test
bacek mikehh: it's not good... 22:11
22:12 whoppix joined
treed Actually, this doesn't even look like it's anything in Cardinal. 22:13
The failure comes after a long list of parrot-compiler stuff.
get_pmc_keyed() not implemented in class 'String'
current instr.: 'parrot;POST;Compiler;pir_children' pc 9678 (src/POST/Compiler.pir:81)
The only cardinal thing in the whole traceback is the top-level main. 22:14
Which instantiates an HLL Compiler and uses it.
All three failures have that same traceback. 22:15
mikehh bacek: it builds using home/mhh/context_pmc3/parrot and the tries to run the tests with /nome/mhh/parrot/parrot
bacek mikehh: ah. it explains why it fais 22:17
fails
nopaste "bacek" at 66.215.91.229 pasted "Backtrace" (17 lines) at nopaste.snit.ch/17777
treed er
darbelo mikehh: what happens if you "make realclean" both trees and then only 'perl Configure.pl' the one you want to test?
treed I misunderstood what -n means, I guess.
That was me.
mikehh bacek: only just noticed now 22:18
bacek Hey. I didn't paste it!
treed I know, I did.
Sorry.
I thought that was the "pasted for" option for some reason.
22:18 Whiteknight joined
mikehh I always do a make realclean, git pull, perl Configure.pl --parrot-config={{parrot_dir whatever}}/parrot_config, make, make test for cardinal 22:19
treed make realclean more or may not actually capture everything 22:20
s/more/may/
treed really should just remove the Makefile build system.
mikehh using respectively ../g.parrot, ../parrot or ../config_pmc3 22:21
Whiteknight treed: How is cardinal doing today? Still experiencing failures?
darbelo mikehh: That realcleans Cardinal, I meant "realclean both parrot chechouts" , so that there's no 'parrot' executable to confuse cardinal. 22:22
treed Whiteknight: The trace just posted under bacek's name is actually from me.
mikehh yeah - it seems to retain the make test run directory
treed There are three such failures in the test suite.
And one instance of parrot(6895) malloc: *** error for object 0xe27ba0: double free 22:23
*** set a breakpoint in malloc_error_break to debug
That doesn't actually cause bailout.
Or any failure in Cardinal's test suite.
Whiteknight hmmm, weird
treed But the get_pmc_keyed failure causes the compiler itself to fail.
So I can't actually run those three test files.
darbelo Whiteknight: Was it you that denounced the evil that string->strstart has brough upon this world? 22:24
mikehh I have about 7 or 8 different versions of parrot (+ whatever I sudo make install-dev) on my system at any one time
Whiteknight darbelo: probably not originally, but I certainly agreed 22:25
treed mikehh: The appropriate rake version of that is: rake clobber, git pull, PARROT_CONFIG={{parrot_dir whatever}}/parrot_config rake cardinal, rake test:all
darbelo I looked arround and it's used all over the place. Is there any 'standard replacement' for it? 22:26
22:26 whoppix joined
mikehh treed - I'll make a note of it 22:26
treed k
I'll probably yank the Makefile system soon.
bacek treed: fixed. dcommiting 22:27
r40915
treed What's fixed?
purl fixed is probably handy
dalek rrot: r40915 | bacek++ | trunk (2 files):
[cage][t] Add String.get_pmc_keyed and tests for keyed access to string.
treed Ah. 22:28
treed repulls.
darbelo I'm looking for something to do now GSoC is over and removing some of the struct-poking looked like a nice incremental task to take on while I wait for my ideas on big numbers to solidify a bit more. 22:30
bacek treed: any luck? 22:38
mikehh treed: it's still picking up the wrong parrot for me - I'll look into it later - let me try bacek's revision and then I must sleep 22:39
darbelo Whiteknight: Is it reasonable to just use Parrot_str_to_cstring() instead of strstart? Or would the allocation and freeing introduce an unwanted overhead?
treed bacek: Running test:all now.
mikehh: How are you invoking the rakefile? 22:40
bacek treed: ok
treed bacek: It takes about 8 minutes to run it to completion on my laptop.
Whiteknight darbelo: I don't know
bacek darbelo: why do you need C-string?
treed bacek: Still failing, looks like. 22:41
darbelo I want to kill strstart with fire. But it's used all over the place.
jonathan darbelo: imo, using strstart is poking into string guts, which I suspect is very wrong.
darbelo jonathan: That's why I want to kill it :) 22:42
22:42 rg1 joined
jonathan Ah, good...when I read the question at first I thought you were debating which to use for some new code. ;-) 22:42
Any cleanup we can do to avoid looking at ->strstart outside of the strings subsystem is surely progress though. 22:43
darbelo jonathan: In some places, like interfaces to external libraries, cstrings are pretty much mandatory. I think strstart might have been introduced as an (premature) optimization for those uses. 22:45
jonathan darbelo: It's surely the wrong way to get at a c string though. 22:46
For one, you don't know the encoding...
mikehh treed: rake cardinal 22:47
darbelo All other ways to get at a cstring have an (posibly unwanted) overhead, and the cannonical one (Parrot_str_to_cstring) involves memmory allocation/freeing. 22:48
treed PARROT_CONFIG=/path/to/my/parrot_config rake cardinal
or you can export it beforehand
rake reads that environment variable
if it's not set, it just uses the one from $PATH
(This won't actually accur if build.yaml already exists, since that's the cache for that info.) 22:49
occur
You could also manage build.yaml yourself with pointers to the various parrot_configs as you want or whatever.
You can tell if it picked up the env variable by the first line, which will say either "Provided parrot_config reports..." or "Detected parrot_config reports..." 22:51
22:55 whoppix joined
mikehh I am starting to make stupid mistakes - I look at it after I sleep some - bbl 22:55
treed k 22:56
darbelo bacek: ping
bacek darbelo: pong 22:57
darbelo Would the use of auto_attrs benefit the Context PMC? 22:58
bacek darbelo: yes, absolutely.
But after merge in next branches
darbelo Ok, I was just looking arround and it made me curious. 22:59
Oh, wait. You branched from trunk before auto_attrs landed, right? 23:00
bacek you can help with finishing Continuation.
darbelo Continuation? Where?
purl continuation is builded inside the opcode, there is no way to pass a differente location.
bacek No, I branched after. But it's too much changes for single branch.
darbelo: jrtayloriv working on Continuations 23:01
darbelo Ah, sorry I thought you meant on the same branch. I'll bother him when he's arround :) 23:02
jrtayloriv bacek, I'm passing all tests at this point. The next thing I was going to start working on, after the current patches are merged, is to see if I can move new_ret_continuation logic out of sub.c and into init() vtable for RetContinuation PMC 23:03
But I'm pretty much for now as far as Continuation PMC itself is concerned (I think) 23:04
bacek jrtayloriv: I'm not across this branch. But looks like darbelo can help with it :)
jrtayloriv pretty much *done*, that is
bacek jrtayloriv: ok. 23:06
jrtayloriv bacek, I'm passing all tests on context_pm3 (r40915) on Linux x86_64 btw ;)
bacek jrtayloriv: it's... expected :) 23:07
jrtayloriv cool -- just didn't know if you had any tests for it lately.
darbelo bacek: If all tests pass, what's holding back the merge? 23:09
bacek mikehh++ tested it on x86_64, darbelo++ on openbsd. 23:10
darbelo: JIT
23:11 beta joined
darbelo Oh, *that* is what triggered the JIT-bashing today. 23:11
bacek :)
darbelo wants to see a kill_JIT_with_fire branch.
treed bacek: Yeah, still failing on the same three files, same backtrace.
23:11 kid51 joined
bacek treed: yak... 23:12
bacek wants to see make_sane_jit branch instead...
jrtayloriv bacek, why is the conditional in mark_context_start() in sub.c? Why do you need to check if it is 0? Why not just do context_gc_mark = 1, and skip the check? 23:13
bacek jrtayloriv: which line? which branch? 23:14
jrtayloriv context_pmc3 line 43
oh nm -- I see
darbelo bacek: make_sane_jit depends on kill_insane_jit ;)
bacek jrtayloriv: leftover. Many of this functions can be removed now
treed: it's strange. I've implemented exactly this method in String... 23:17
treed Huh.
Maybe I didn't get your revision with that svn up? 23:18
Whiteknight jrtayloriv
purl jrtayloriv is using r40849
Whiteknight has anybody committed those patches of yours?
japhb OK, so where are we now? It sounds like we need to merge the runcore/profiling branch, then twiddle --runcore=jit to be --runcore=fast, then merge context_pmc3?
treed Huh. 23:19
treed just got an ssh error trying to svn up.
jrtayloriv Whiteknight, nope, don't think so
Whiteknight okay, I'm on it now
jrtayloriv Whiteknight, thanks :)
Whiteknight so that's the latest two patches need a'committin'? 23:20
bacek japhb: +1 for this sequence.
23:21 donaldh joined
bacek bacek ~~ $dayjob 23:21
23:23 whoppix joined
jrtayloriv Whiteknight, yes 23:23
Whiteknight Okay, testing the first one now
dalek rrot: r40916 | whiteknight++ | branches/kill_parrot_cont (2 files):
[kill_parrot_cont] remove the new_continuation and new_ret_continuation function. Patch from jrtayloriv++
 23:26
Whiteknight ...and testing the second 23:27
treed purl: msg bacek The error is now: Method 'lineof' not found for invocant of class 'String' 23:31
purl Message for bacek stored.
dalek rrot: r40917 | whiteknight++ | branches/kill_parrot_cont/src/pmc/continuation.pmc:
[kill_parrot_cont] fix a GC bug that was causing a test failure. Courtesy jrtayloriv++
 23:33
chromatic Whiteknight, doesn't Parrot_custom_mark_destroy_SETALL also the active destroy flag? 23:34
Whiteknight chromatic: I have no idea. Seems like it should, but probably doesn't 23:35
I usually see the two set together 23:36
(I'm also not entirely clear what the difference is)
jrtayloriv chromatic, IIRC one of them says " I have a custom mark()" the other says I have custom destroy()
chromatic See include/parrot/pobj.h:358
jrtayloriv I honestly don't remember which is which.
chromatic, oh I see -- I must have read about custom_mark and active_destroy, and accidentally put custom_mark_destroy, which does both. 23:38
chromatic, and is there any reason not to rename active_destroy to custom_destroy, so that the connection between it and custom_mark is obvious? 23:39
chromatic I like the idea. 23:40
Whiteknight the active_destroy flag can probably disappear completely 23:41
the auto_attrs work has left it mostly useless
darbelo Whiteknight: Not all PMCs have auto_attrs set, and some still need custom destruction. 23:42
chromatic But it can be rarer. 23:43
Whiteknight darbelo: VTABLE_destroy() is called on all PMCs now, those without custom destruction just call the empty Default PMC version
doesn't matter if it has auto_attrs or not
darbelo Wait. The flag is ignored?
chromatic I'm not a fan of that. 23:44
Whiteknight that I am aware of, yes 23:45
There are ways we could avoid unnecessary VTABLE calls without using the flag 23:46
if we want to avoid them
darbelo Whiteknight: Parrot_pmc_destroy only calls VTABLE_destroy if PObj_active_destroy_TEST(pmc) is true.
Hell, if the VTABLE starts getting called unconditionally then decnum-dynpmcs will start segfaulting again. 23:47
Whiteknight oh, does it? I thought that had changed 23:48
maybe
NotFound unchanged it
darbelo Also, not calling VTABLE_destroy() is the only available workarround for TT#956 that I can think of. 23:51
chromatic I think the right answer to that is don't use a custom destroy there. 23:52
Or don't make them a singleton.
darbelo Well, I need it to be a singgleton, and not using a custom destroy "leaks" the memory. 23:56
chromatic That's not how singletons work. 23:57
Whiteknight The issue is order-of-destruction. The GC finalizer should be smart enough to understand the dependency between Library PMCs and the dynpmcs they contain 23:58
chromatic The right fix is probably to perform one final GC run, collect all PMCs with custom destruction, then order that graph according to heuristics we know in advance. 23:59
Whiteknight At the very least, in the final sweep run, it should not free Library PMCs, but save them for another step to free them together at the end
darbelo If singletons live "forever" then the leak isn't one. But the 'immortatlity' of the singleton is not documented as a feature anywhere, so I'd rather not depend on it.

Powered by Cro and the Raku® Programming Language.

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

Thank you!