Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-01

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:06 Zak joined #parrot
00:27 Andy joined #parrot
00:27 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:30 jrtayloriv but then after running them a second time (without running make clean/realclean), I start failing a bunch of them again.
00:43 Whiteknight yay! nondeterministic test failures
00:47 Whiteknight We'll get them nailed down though, this branch is important enough
00:47 Whiteknight NotFound: ping
00:47 dalek parrot: r40900 | whiteknight++ | branches/kill_parrot_cont:
00:47 dalek parrot: [kill_parrot_cont] Creating a patch to test and fix the patch provided by jrtayloriv++ in TT #926
00:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40900/
00:48 Whiteknight worst case?
00:48 purl it has been said that worst case is you do something like render() in http://poe.dyndns.org/~troc/tmp/fax/Fax.pm
00:50 Whiteknight Clang apparently was doing something about adding closures to C
00:50 Whiteknight really awesome, but no way in all of hell that Parrot's codebase would ever use them
00:52 japhb joined #parrot
00:54 AndyA joined #parrot
01:11 dalek parrot: r40901 | whiteknight++ | branches/kill_parrot_cont (18 files):
01:11 dalek parrot: [kill_parrot_cont] Apply patch from jrtayloriv++ in TT #926. Seeing failure in t/op/sprintf.t that is difficult to debug.
01:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40901/
01:37 bacek_at_work Whiteknight: http://en.wikipedia.org/wiki/Setcontext :)
01:41 TiMBuS joined #parrot
01:43 Whiteknight bacek_at_work: I didn't write those accessors tonight, got sidetracked
01:43 Whiteknight will do it tomorrow
01:43 Whiteknight ...if you can wait that long :)
01:43 bacek_at_work Whiteknight: no worries
01:43 Whiteknight okay, I'm going to bed now. Goodnight
01:47 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:50 bacek_at_work jrtayloriv: just attach more comments to original ticket.
01:51 jrtayloriv bacek_at_work, ok - thanks
01:53 bacek_at_work jrtayloriv: on which platform you are developing this?
01:53 jrtayloriv x86_64
01:54 rhr joined #parrot
01:54 jrtayloriv linux
01:54 bacek_at_work try to disable vdso and rebuild without optimise. It will simplify bugs hunting
01:55 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
01:56 bacek_at_work "echo 0 > /proc/sys/vm/vdso_enabled" (or something like this) to disable vdso
01:57 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...
01:58 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
01:59 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?
02:00 bacek_at_work --optimize not in default. But in your latest backtrace I did see optimised-out variables :)
02:03 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:04 bacek_at_work Heh. And effectively switch on optimisation :)
02:08 jrtayloriv bacek_at_work, should I do --> perl Configure.pl --optimize=O0
02:10 jrtayloriv hmmm, that just gave me all manner of errors.
02:10 jrtayloriv I've got Perl built with -O2 ... maybe that is why is is causing problems when I do that?
02:13 dukeleto 'ello
02:14 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
02:14 jrtayloriv ahhh ... ok -- bingo
02:15 chromatic You can add -g on the rhs if you like too.
02:17 dukeleto jrtayloriv: has anyone gotten back to you about https://trac.parrot.org/parrot/ticket/958 ? Looks like it can be applied and closed, yes?
02:19 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:22 jrtayloriv 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.
02:22 chromatic I do it to be sure that Parrot continues to work with full optimizations.
02:23 jrtayloriv chromatic, bacek_at_work was saying that disabling the optimizations would make it easier to debug.
02:24 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 ?
02:25 chromatic I don't know.
02:25 chromatic I *think* it's available somehow.
02:26 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:27 dukeleto perl Configure.pl --debug --maintainer --optimize=3
02:35 janus joined #parrot
03:20 donaldh joined #parrot
03:58 Andy joined #parrot
04:12 dalek rakudo: 9bcba63 | pmichaud++ | src/parser/grammar.pg:
04:12 dalek rakudo: "Statement not terminated properly" --> "Confused"  # TimToady++
04:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​bcba631a4c13f3608cb8657564612b96f96ad1d
04:22 davidfetter joined #parrot
04:56 ZeroForce joined #parrot
05:13 beta joined #parrot
05:21 kjeldahl joined #parrot
06:01 uniejo joined #parrot
06:25 iblechbot joined #parrot
06:26 bacek_at_work jrtayloriv: ping
06:26 jrtayloriv pong
06:27 bacek_at_work I read your comment in ticket. Looks like premature GCing of Continuation (or continuation's ATTRibutes)
06:28 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.
06:28 jrtayloriv bacek_at_work, np -- thanks for pointing me to that.
06:29 HG` joined #parrot
06:34 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:36 Zak joined #parrot
06:37 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:39 krunen joined #parrot
06:42 jrtayloriv OK. Thanks.
06:59 jrtayloriv 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 jrtayloriv yep -- just passed sprintf test
07:01 jrtayloriv sweet! -- passed all tests (except for pcre, which I am failing with trunk/ anyway), bacek++
07:03 cotto jrtayloriv, do you think it'd still be worthwhile to have a branch to work against?
07:05 jrtayloriv cotto, I don't understand the question, sorry. Are you asking if I think that there needs to be a separate branch?
07:06 jrtayloriv 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.
07:19 cotto jrtayloriv, do you know about our weekly meetings in #parrotsketch?
07:20 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 donaldh joined #parrot
07:24 jrtayloriv done and done
07:26 cotto That was speedy.
07:42 jrtayloriv coffee ... is ... wearing ... off ... ... ... bedtime soon
07:55 jrtayloriv 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.
07:55 jrtayloriv night night #parrot
07:56 rbaumer joined #parrot
08:00 chromatic joined #parrot
08:00 bacek joined #parrot
08:01 bacek o hai
08:05 rbaumer joined #parrot
08:09 MoC joined #parrot
08:14 jrtayloriv joined #parrot
08:30 Khisanth joined #parrot
08:53 MoC joined #parrot
09:05 allison joined #parrot
09:13 allison joined #parrot
09:13 allison left #parrot
09:18 masak joined #parrot
09:20 dukeleto bacek: good localtime()
09:21 bacek dukeleto: alloha! How is irssi proxy going? :)
09:21 rbaumer joined #parrot
09:22 dukeleto bacek: i did a lot of rtfm'ing, now I just need to set it up ;)
09:22 bacek That's good :)
09:23 dalek parrot: r40902 | bacek++ | branches/context_pmc3 (42 files):
09:23 dalek parrot: Reintroduce CURRENT_CONTEXT macro. Switch CONTEXT macro to return Parrot_Context structure back
09:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40902/
10:17 mikehh All tests PASS at r40902 (pre/post-config, smoke, nqp_test, fulltest) - Ubuntu 9.04 amd64 (g++)
10:20 dalek parrot: r40903 | bacek++ | branches/context_pmc3 (4 files):
10:20 dalek parrot: Add accessors to Regs_* structures. Move Parrot_Context definition into
10:20 dalek parrot: separated file to avoid circular dependencies.
10:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40903/
10:27 rbaumer joined #parrot
10:33 mikehh rakudo (9bcba63) builds on parrot r40902 - make test / make spectest (up to r28155) PASS - Ubuntu 9.04 amd64 (g++)
10:39 mikehh partcl r650 builds on parrot r40902 - make test PASS - Ubuntu 9.04 amd64 (g++)
10:42 mikehh decnum_dynpmcs r181 builds on parrot r40902 - make test PASS - Ubuntu 9.04 amd64 (g++)
10:44 bacek mikehh: Yay! Can you test latest context_pmc3 branch?
10:44 mikehh bacek: right on
10:45 bacek mikehh: wait few minutes. It's still dcommiting
10:45 bacek (Rakudo will not build with old patch)
10:46 mikehh ok I am at r40907
10:46 mikehh on the branch
10:46 dalek parrot: r40904 | bacek++ | branches/context_pmc3/src (2 files):
10:47 dalek parrot: Switch Context.inc_recursion_depth to postincrement to avoid assign -1 to UINTVAL.
10:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40904/
10:47 dalek parrot: r40905 | bacek++ | branches/context_pmc3/src/runcore/main.c:
10:47 dalek parrot: Remove meaningless assert.
10:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40905/
10:47 dalek parrot: r40906 | bacek++ | branches/context_pmc3 (6 files):
10:47 dalek parrot: Use Context Regs_* accessors
10:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40906/
10:47 dalek parrot: r40907 | bacek++ | branches/context_pmc3/incl​ude/parrot/interpreter.h:
10:47 dalek parrot: Finally remove CONTEXT_FIELD and CURRENT_CONTEXT_FIELD macros.
10:47 bacek mikehh: yes. r40907 is latest
10:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40907/
10:47 mikehh bacek: ok here goes
10:47 bacek mikehh: thanks!
10:50 bacek mikehh: after "realclean" codetest failure about c++ comments is expected.
10:58 mikehh bacek: builds ok - make test PASS running other tests now
10:59 bacek mikehh: ok. I'll prepare new version of patches for rakudo and lua.
11:05 mberends joined #parrot
11:09 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:13 bacek mikehh: ouch... It's svn related stuff (which isn't supported by git-svn). Just ignore it for now.
11:15 mikehh bacek: and manifest_tests fail - you need to run tools/dev/mk_manifest_and_skip.pl
11:16 bacek Which doesn't support git-svn yet :)
11:16 bacek But feel free to run it and commit changes in branch
11:17 mikehh otherwise looks good - but t/tools/parrot_debugger.t still gives a backtrace (although it passes) - does not in trunk anymore
11:21 bacek mikehh: yeah. But I'm trying to avoid merge from trunk before finishing all jobs. Merges in svn is pain...
11:21 donaldh joined #parrot
11:24 dalek parrot: r40908 | bacek++ | branches/context_pmc3/MANIFEST:
11:24 dalek parrot: [cage] Add context.h into MANIFEST
11:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40908/
11:25 nopaste "bacek" at 114.73.43.135 pasted "latest rakudo patch for mikehh++" (77 lines) at http://nopaste.snit.ch/17767
11:25 bacek mikehh: rakudo should build seamlessly on r40908 with nopasted patch.
11:29 sri joined #parrot
11:31 AndyA joined #parrot
11:34 dalek parrot: r40909 | mikehh++ | branches/context_pmc3 (2 files):
11:34 dalek parrot: set svn properties as per t/distro/file_metadata.t failures
11:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40909/
11:44 dalek parrot: r40910 | mikehh++ | branches/context_pmc3/include/parrot/context.h:
11:44 dalek parrot: fix svn properties on include/parrot/context.h
11:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40910/
11:44 dalek parrot: r40911 | mikehh++ | branches/context_pmc3/MANIFEST:
11:44 dalek parrot: run tools/dev/mk_manifest_and_skip.pl to fix manifest_tests failure
11:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40911/
11:46 mikehh and again from the newly added files - need to fix more properties :{ (mind you easy karma)
11:58 dalek parrot: r40912 | mikehh++ | branches/context_pmc3 (2 files):
11:58 dalek parrot: fix svn properties on src/pmc/context.pmc and t/pmc/context.t
11:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40912/
12:04 mikehh bacek - apart form src/jit/i386/jit_defs.c with c++ comments codetest now passes and manifest_tests - the rest PASS
12:07 mikehh how do you apply the patch specifically - not too sure of git patching
12:14 JimmyZ joined #parrot
12:26 Coke bacek: you can build parrot optimized with debug, at least with gcc: "Configure.pl --optimize --ccflags=-g"
12:26 Coke chromatic++
12:27 Coke Anyone want to fix my segfault before parrotsketch so my report is all hugs and puppies?
12:27 NotFound Coke: What segfault?
12:27 purl segfault is, like, http://xkcd.com/371/
12:29 Coke TT #960
12:30 ingy joined #parrot
12:30 mmpf joined #parrot
12:30 NotFound Coke: I no longer have that failures
12:31 payload joined #parrot
12:31 TimToady joined #parrot
12:32 Coke NotFound: hurm. any idea which revision fixed it?
12:32 Coke updating parrot to double check. (also, try running with --gc-debug)
12:33 NotFound Coke: r40897 was the last related change
12:34 Coke ok. I'm about six behind that; checking...
12:35 NotFound r40893 was the key
12:35 quek joined #parrot
12:35 Coke so, what, something got recycled, had a custom mark, and then that inappropriate mark got invoked when the new pmc was checked?
12:36 NotFound Looks like there was something like that, yes.
12:36 NotFound I'm thinking that we need a 'dead' PObj flag
12:37 NotFound For things that have been destroyed but aren't yet in a free list
12:39 NotFound BTW, I can't #ps today. My report is: fixing, fixing, fixing ;)
12:40 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 Coke NotFound++
12:40 NotFound Coke: don't have time today, feel free to close yourself
12:42 spinclad joined #parrot
12:43 Coke NotFound++
12:43 dalek TT #960 closed by coke++: segfaults in Parrot_String_mark
12:46 sri joined #parrot
12:46 dalek partcl: r651 | coke++ | wiki/ParrotIssues.wiki:
12:46 dalek partcl: this ticket's bug is fixed, just waiting on a test; we don't need to track it
12:46 dalek partcl: here.
12:46 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=651
12:57 dalek partcl: r652 | coke++ | trunk/runtime/builtin/info.pir:
12:57 dalek partcl: use more .const
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=652
12:57 dalek partcl: r653 | coke++ | trunk/runtime/builtin/info.pir:
12:57 dalek partcl: move 'body' inline
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=653
12:57 dalek partcl: r654 | coke++ | trunk/runtime/builtin/info.pir:
12:57 dalek partcl: make 'args' inline
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=654
12:57 dalek partcl: r655 | coke++ | trunk/src/macros.pir:
12:57 dalek partcl: Add macro for setting up an iterator.
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=655
12:57 dalek partcl: r656 | coke++ | trunk/config/PARROT_VERSION:
12:57 dalek partcl: There are many fewer segfaults here, NotFound++
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=656
12:57 dalek partcl: r657 | coke++ | trunk/runtime/builtin/info.pir:
12:57 dalek partcl: inline all the [info subcommands]; cleanup PIR.
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=657
12:57 dalek partcl: r658 | coke++ | trunk/runtime/ (25 files):
12:57 dalek partcl: PIR cleanup (also, more macros)
12:57 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=658
13:04 * Coke wonders why "# vim: ft=tcl :" isn't working.
13:08 quek left #parrot
13:13 ruoso joined #parrot
13:16 mikehh_ joined #parrot
13:22 TiMBuS joined #parrot
13:23 mikehh joined #parrot
13:27 bkuhn joined #parrot
13:33 mikehh bacek_at_work: ok rakudo passed make test and make spectest with the patch on parrot from the context_pmc3 branch
13:36 mikehh and partcl r658 PASSes make test for that matter (forgot to install trunk parrot) :-}
13:45 dalek rakudo: 4c08564 | mberends++ | src/setting/Temporal.pm:
13:45 dalek rakudo: [Temporal.pm] replace soon-to-be-deprecated int() with floor()
13:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​c08564108f7aaab568b72e1efa3d6b222cde837
13:46 Coke NotFound++
14:00 PacoLinux joined #parrot
14:04 whiteknight joined #parrot
14:15 Zak joined #parrot
14:17 Psyche^ joined #parrot
14:32 Coke NotFound++
14:37 Andy joined #parrot
14:40 jhorwitz joined #parrot
14:41 JimmyZ joined #parrot
14:41 mikehh All tests PASS at r40912 (pre/post-config, smoke, nqp_test, fulltest) - Ubuntu 9.04 amd64 (gcc)
14:42 mikehh partcl r658 builds on parrot r40912 - make test PASS - Ubuntu 9.04 amd64 (gcc)
14:43 mikehh (and also on the context_pmc3 branch)
14:54 mikehh rakudo (4c08564) builds on parrot r40912 - make test / make spectest (up to r28156) PASS - Ubuntu 9.04 amd64 (gcc)
14:57 mikehh decnum_dynpmcs r181 builds on parrot r40912 - make test PASS - Ubuntu 9.04 amd64 (gcc)
15:18 Coke NotFound: down to 8 segfaults in spectest, some of which were long standing.
15:20 Coke 2 of the segfaults have turned back into memory panics; but that reclaimed a lot of passing tests.
15:21 donaldh joined #parrot
15:24 dalek partcl: r659 | coke++ | wiki/SpecTestStatus.wiki:
15:24 dalek partcl: Unfudge a lot of tests after NotFound++'s segfault fix in parrot.
15:24 dalek partcl: Also, alphabetize a bit.
15:24 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=659
15:25 jrtayloriv PMC "headers" are an outdated concept related to when things used to be split into PMC and PMC_EXT right?
15:25 jrtayloriv Or is that term referring to something else?
15:26 frodwith joined #parrot
15:28 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:29 jrtayloriv oh -- nm, I see now that pmc_new is still using it :)
15:31 NotFound jrtayloriv: is just a name, if you have a better idea we can change it
15:32 payload joined #parrot
15:40 dalek TT #700 closed by doughera++: dynpmc/Makefile problem on Solaris 8/SPARC at r39040
16:02 cotto joined #parrot
16:15 whiteknight joined #parrot
16:17 cotto good mooring
16:17 darbelo joined #parrot
16:22 masak oh hai. Close seems like a really nice thing. is there some way I could contribute to it?
16:23 cotto seen austin
16:23 cotto oh noes.  the bot got eated.
16:24 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.
16:24 masak austin++
16:25 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))).
16:25 masak darbelo: :D
16:26 * 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.
16:27 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() ?
16:27 pmichaud can open a pipe
16:27 pmichaud to a process
16:28 chromatic joined #parrot
16:29 pmichaud http://github.com/rakudo/rakudo/bl​ob/9bcba631a4c13f3608cb8657564612b​96f96ad1d/src/builtins/system.pir
16:29 pmichaud oh, wait, that doesn't look right
16:29 pmichaud it's pretty close.  If you want to capture the output you need to open a pipe.
16:30 pmichaud Rakudo does that for the qx{...} term
16:30 mokurai joined #parrot
16:31 pmichaud http://github.com/rakudo/rakudo/blob/9bcba631a4c1​3f3608cb8657564612b96f96ad1d/src/builtins/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.
16:31 pmichaud then either of those should work :)
16:32 pmichaud #ps in 118
16:45 ash_ joined #parrot
16:53 kjeldahl joined #parrot
17:06 * Coke hopes he can finish this spec test run before parrotsketch.
17:06 Coke 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 #parrot
17:12 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:14 moritz I haven't seen segfaults in rakudo in the last two weeks (when tracking parrot HEAD)
17:14 theory joined #parrot
17:17 dalek partcl: r660 | coke++ | wiki/SpecTestStatus.wiki:
17:17 dalek partcl: missed one constraint failure.
17:17 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=660
17:18 Coke moritz: not surprised if we're tickling (HA) different core errors.
17:20 Coke 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:21 Coke (that's a new record of passing tests)
17:22 Coke (up from 2972 on 6/13 of last year.)
17:22 Coke NotFound++
17:22 Coke NotFound++
17:22 Coke NotFound++
17:23 Coke Now if I can get patrick to look at that PGE ticket, I can get about 400 more tests counted... =-)
17:23 Coke <- greedy
17:24 Coke (er, 6/13 earlier this year.)
17:26 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!
17:26 whiteknight If Coke is happy for once, let him be!
17:27 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 Coke mikehh++
17:27 mikehh that's down from 3 yesterday - which was an improvement
17:28 Coke mikehh: and we should have added a bunch of new ones.
17:28 Coke s/ones/tests that run to completion/
17:29 mikehh all other tests repoort or are skipped
17:29 Coke added it to the skip list for next time.
17:29 Coke 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.)
17:30 mikehh I make ir #ps in one hour
17:32 dalek partcl: r661 | coke++ | wiki/SpecTestStatus.wiki:
17:32 dalek partcl: missed one segfault (mikehh++ for pointing it out.)
17:32 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=661
17:34 Zak joined #parrot
17:39 Coke ps?
17:42 AndyA joined #parrot
17:49 Util #ps in 41
17:53 Coke http://partcl.blogspot.com/2009/09/n​ow-passing-3363-tcl-spec-tests.html
17:54 jonathan Coke++ # nice :-)
17:54 moritz aye
18:00 joeri joined #parrot
18:06 dalek TT #961 created by coke++: segfault in Parrot_oo_find_vtable_override
18:10 dalek partcl: r662 | coke++ | wiki/SpecTestStatus.wiki:
18:10 dalek partcl: link to ticket.
18:10 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=662
18:16 eternaleye joined #parrot
18:18 AndyA joined #parrot
18:21 dalek rakudo: 39c3f4b | (Solomon Foster)++ |  (5 files):
18:21 dalek rakudo: infix:</>(Int, Int) creates a Rat, infix:<div>(Int, Int) an Int, as per latest S03
18:21 dalek rakudo: Also fix depending code, namely Temporal.pm
18:21 dalek rakudo: Fix Rat.perl to return "N/M" rather than "Rat.new(N,M)".
18:21 dalek rakudo: 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.
18:21 dalek rakudo: Patch mostly by colomon++, with some minor contributions and cleanups by moritz
18:21 dalek rakudo: See RT #68898 for discussion.
18:21 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​9c3f4b6d5f2a702f336d33e79d23391adf36980
18:21 dalek rakudo: 4b9cd2d | moritz++ | docs/ChangeLog:
18:21 dalek rakudo: [docs] ChangeLog updates
18:21 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​b9cd2db307d19d7f7c9b84b39448982be4c5dbb
18:35 Coke mikehh: ww?
18:37 mikehh Coke am running make spectest again - up to parse
18:39 Tene joined #parrot
18:49 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 jrtayloriv whiteknight, I'm passing all tests on x86_64 linux now.
18:49 whiteknight jrtayloriv: I won't be able until I get home unfortunately
18:50 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:52 whiteknight yes, I did see that, just haven't had a chance to work on it
18:58 purl joined #parrot
18:59 bacek joined #parrot
19:00 dalek TT #962 created by coke++: segfault in Parrot_Object_assign_pmc
19:04 * whiteknight would be very happy to see SVN properties disappear
19:04 cotto clock?
19:04 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 /
19:05 cotto good morning, bacek
19:05 * duk3leto would be very happy to see SVN disappear
19:05 chromatic We can't get rid of SVN any time soon, but I'd like to get rid of the properties.
19:05 duk3leto chromatic: I can live with that.
19:06 duk3leto +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.
19:06 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
19:06 japhb yes, I would favor that -- assuming that getting rid of them won't result in svn being stupid.
19:06 whiteknight they have provided me no benefit whatsoever
19:07 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.
19:07 japhb allison asked to log here that she was in favor of exploring server-side hooks
19:07 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
19:07 Coke that should be enabled for all non-binary files.
19:08 Coke and I'm pretty sure we can set a hook and forget it.
19:10 Util I am willing to tackle the server-side hooks. What access do I need?
19:11 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.
19:11 Coke (or we get you access to the VMware box running the parrot.org stuff )
19:11 Coke chromatic: oh, right, make them do the work.
19:11 Coke +1
19:11 purl 1
19:12 Util Coke: will do (research/plan)
19:15 dalek partcl: r663 | coke++ | wiki/SpecTestStatus.wiki:
19:15 dalek partcl: Edited wiki page through web user interface.
19:15 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=663
19:20 Coke whiteknight: also look at lightning.
19:20 chromatic Lightning is definitely an inspiration.
19:20 whiteknight yes, I intend to look closely at lightning, libJib, LLVM, etc
19:20 whiteknight I think an ideal solution would be a pluggable API that supports all of these
19:20 donaldh joined #parrot
19:21 moritz aye; but don't overdesign ;-)
19:24 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)
19:24 japhb duk3leto, I'd honestly look at the developer wikis for the free web browsers
19:25 duk3leto japhb: good tip, thanks
19:25 moritz V8, tracemonkey might be worthy to look at
19:26 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)
19:27 whiteknight Coke: fastcore is the best in profile numbers I've seen
19:28 Coke is there a way to make it the default core in a) built parrot and b) fakecutables?
19:28 chromatic Fakecutables, easy.
19:28 chromatic Built Parrot, possible.  Do you mean globally or as a configurable default?
19:29 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
19:29 whiteknight like what our exec core was supposed to be, I think
19:29 chromatic There's another core we could probably yank....
19:29 whiteknight "probably should" FTFY
19:30 uri joined #parrot
19:30 jonathan I think if you yank the jit core you pretty much have to yank the exec one with it.
19:30 japhb FTFY?
19:30 whiteknight fixed that for you
19:30 whiteknight jonathan: probably
19:30 Coke added 2 segfaults to trac...
19:30 japhb whiteknight, heh
19:30 uri left #parrot
19:32 Topic for #parrotis now http://www.parrot.org | Improve test coverage for Array and NameSpace / Fix Segfaults for Coke / Merge Stable Branches for 1.6 SOON
19:33 Topic for #parrotis now http://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:34 duk3leto the Factor language has some interesting things to say about JIT: http://factor-language.blogspot.com/search?q=JIT
19:35 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.
19:35 particle it might help to improve our test coverage by starting on the most frequently used pmc types
19:36 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
19:36 whiteknight no more having to make symetric edits to keep things lined up
19:36 mikehh pmichaud: ping
19:36 pmichaud pong
19:36 chromatic Namespace is in the list.  I put Array in there because other array types extend it.
19:37 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
19:37 * treed kibbitzing
19:37 chromatic I think it extends Array too.
19:38 treed Oh, wait, this is #parrot not #parrotsketch
19:38 pmichaud mikehh: I don't think I've seen the patch yet
19:38 mikehh pmichaud: I was just wondering how do we maintain backward compatibility say with 1.5
19:39 pmichaud mikehh: I don't understand
19:39 pmichaud 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
19:40 pmichaud you can make a branch of Rakudo master and apply the patch there
19:40 pmichaud but until the context_pmc3 branch lands in Parrot trunk, Rakudo master can't/shouldn't build against it
19:40 mikehh pmichaud: http://nopaste.snit.ch/17767
19:40 pmichaud (i.e., we don't want Rakudo master to be tracking a Parrot branch)
19:41 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.
19:42 pmichaud mikehh: that's no problem (more)
19:42 pmichaud it's already the case that Rakudo head doesn't build against Parrot 1.5
19:42 pmichaud that usually happens just a few days after release anyway
19:42 mikehh ah - ok I see that now
19:43 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
19:43 mikehh I was just worried that the latest wouldn't build against earlier parrots
19:43 pmichaud that's already the case.  Rakudo development still has a higher velocity than Parrot's monthly release cycle
19:44 cotto chromatic, I don't think anything extends Array.
19:44 chromatic Maybe it's FixedPMCArray they extend.
19:44 particle nothing uses Array, just Fixed*Array
19:45 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
19:45 pmichaud and MultiSub extends ResizablePMCArray, iirc
19:45 eternaleye joined #parrot
19:45 Topic for #parrotis now http://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
19:46 whiteknight who is releasing 1.6, particle?
19:46 particle FixedIntegerArray is used in every pcc call
19:46 particle yep, me
19:47 Coke particle: I had a macro that dumped how many pmcs were allocated, but we don't know what types.
19:48 pmichaud (release targeting)  but so far Rakudo hasn't been able to go for very long based on a Parrot release (more)
19:49 pmichaud 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.
19:49 pmichaud And feature XYZ in Parrot is blocking on a deprecation cycle
19:49 pmichaud actually, let's put actual dates here
19:49 pmichaud suppose Rakudo development is blocking on XYZ
19:49 pmichaud and XYZ is blocking because it requires us to give a deprecation notice in January 2010
19:50 pmichaud 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
19:50 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
19:51 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
19:51 pmichaud blocking 10 months on Parrot is not a viable option for us.
19:51 Coke mikehh: woot.
19:52 * whiteknight is relatively unhappy with the current deprecation policy, but won't fight about it
19:52 pmichaud some for me, but s/relatively//
19:52 pmichaud *same
19:52 mikehh I think chromatic is too :-}
19:52 Coke I think having /a/ policy is sane; i think our current version over-estimates our user base.
19:52 mikehh moi aussi
19:53 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 whiteknight 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
19:53 mikehh cardinal users are v. upset at the moment
19:53 whiteknight mikehh: upset about what?
19:54 whiteknight 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.
19:54 Coke note that, in general, deprecation blocks removals and incompatible updates, not new things.
19:54 pmichaud Coke: it blocks refactors.
19:54 pmichaud and some new things depend on refactors
19:54 Coke depending on what's been exposed, sure.
19:54 whiteknight Coke: it's been blocking enough new things that it's worth reconsideration
19:54 moritz who controls http://cardinal2.rubyforge.org/?
19:54 moritz it's very out of date
19:55 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
19:55 Coke mikehh: ah, just like me. =-)
19:55 Coke 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.
19:55 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
19:56 whiteknight yeah, the branches merging this month were more disuptive then normal
19:56 mikehh I think treed is the principal at the moment
19:56 whiteknight of course, they are making some seriously-necessary changes
19:56 moritz purl: cardinal?
19:56 purl i heard cardinal was http://mail.freesoftware.fsf​.org/pipermail/cardinal-dev/ or the Ruby-on-Parrot project. or http://xrl.us/uyz3
19:57 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
19:57 mikehh there is a #cardinal on this server just /join cardinal
19:57 pmichaud particle: I disagree.
19:58 Coke particle: can you show us any downstream users taking advantage of this stability?
19:58 particle i don't track any user stats
19:59 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
19:59 pmichaud "api only changes in 6 month cycles" is as yet a myth
19:59 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)
19:59 particle pmichaud: yes, due to a late merge of a branch
19:59 pmichaud particle: even if it had been an early merge, Rakudo would've been hosed in the same way
19:59 particle that's a policy that's under review
19:59 mikehh quite a few persons have developed an HLL on parrot and then come back to it later an it don't work anymore
20:00 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.
20:01 Coke (adding new things) (ok, it SHOULD be easy, but I'm not saying that it really is.)
20:02 particle pmichaud: you don't need to use a supported release
20:02 particle that's a policy for you, as rakudo dev, to set
20:02 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.
20:02 pmichaud particle: that's Parrot's official recommendation as to what users (including HLL developers) should be doing, however.
20:02 chromatic I think the problem is the biannual releases, not the six month cycle per se.
20:03 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
20:04 pmichaud and the claim that this "increases stability" is not thus far borne out by actual experience
20:05 pmichaud 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
20:05 whiteknight okay, we've all trashed the current policy enough. The question now is, what is the way to fix it?
20:05 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.
20:05 whiteknight mikehh: we do need it to be a lot more comprehensive then it is
20:06 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
20:07 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.
20:07 mikehh in rakudo's case it wouldn't even build at first
20:07 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
20:07 japhb .oO( The less sleep I get, the more visual my metaphors become ...)
20:07 eternaleye_ joined #parrot
20:08 japhb pmichaud, nodnod
20:10 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
20:11 duk3leto pmichaud: all ears
20:11 pmichaud from bacek's context_pmc patch for Rakudo:
20:11 mikehh +1
20:11 purl 1
20:11 pmichaud -    Parrot_Context *ctx         = CONTEXT(interp)->caller_ctx;
20:11 pmichaud +    PMC     *ctx         = Parrot_pcc_get_caller_ctx(interp, CURRENT_CONTEXT(interp));
20:12 pmichaud 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
20:12 pmichaud (yes, context_pmc3, thanks)
20:12 pmichaud if someone says "oh, Rakudo was using internal data structures there", the answer is that there wasn't any other API available
20:13 pmichaud 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 pmichaud sorry, *February 2010*
20:13 Coke I thought allison's answer was 'do it both ways until we can rip out the old one.'
20:13 hercynium joined #parrot
20:13 pmichaud if we say "oh, Parrot needs to support the old API", I don't see any way to reasonably do that
20:14 whiteknight pmichaud: we can add an API anytime, we don't need to wait for a deprecation point
20:14 whiteknight so if you want an API, ask and ye shall receive
20:14 mikehh as long as we can test and patch - until we are really *stable* we still need to move forward
20:14 pmichaud whiteknight: okay, in this case we need an API that preserves the Parrot_Context structure
20:14 pmichaud but the point of the branch is to eliminate the Parrot_Context structure
20:14 whiteknight pmichaud: replace it with a Context PMC with the same functionality
20:15 pmichaud whiteknight: that doesn't work for
20:15 pmichaud 20:11 <pmichaud> -    Parrot_Context *ctx         = CONTEXT(interp)->caller_ctx;
20:15 pmichaud note that ctx is *not* a PMC
20:15 whiteknight so are you arguing for or against the branch?
20:15 pmichaud let's be clear, I'm very much in favor of the branch
20:15 whiteknight ok
20:15 jonathan #defone Parrot_Context PMC /* hey solved */
20:16 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
20:16 pmichaud whiteknight: but the problem is that we *do*
20:16 Coke can't we #define CONTEXT(interp)->caller_ctx to do something?
20:16 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
20:16 pmichaud whiteknight: I agree we should have one.  Parrot didn't.
20:17 pmichaud whiteknight: at this point, Parrot still doesn't.
20:17 whiteknight no argument, but it will
20:17 chromatic Can't we argue over whether the color scheme of our website is offensive?
20:17 donaldh_ joined #parrot
20:17 whiteknight DAMNIT I HATE GREEN
20:17 Coke so i would argue that poking directly into struct guts is experimental.
20:17 pmichaud Coke: I'm fine with that.
20:17 whiteknight Coke: agreed 100%
20:17 Coke then it's a win win.
20:17 pmichaud However, the current claim is that the context_pmc3 branch can't land because existing applications depend on the old "API"
20:18 whiteknight wrong, there was no old API
20:18 Coke "poking into structs is not an API"
20:18 Coke I think that's a reasonable argument to make.
20:18 pmichaud Coke: that's fine with me also
20:18 japhb Coke, Also a good slogan for a t-shirt or coffee mug
20:18 chromatic "Poking into structs" appears *nowhere* in the "What we consider valid deprecation targets" section of our support policy.
20:18 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
20:18 Coke japhb: not very catchy. kids'll never by it.
20:18 Coke "buy"
20:18 pmichaud but afaict that is not what bacek++ has been told
20:19 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?
20:19 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.
20:19 * whiteknight just  made himself more angry
20:19 mikehh whiteknight: works fine on amd64 :-}
20:20 whiteknight mikehh: really? in the JIT core?
20:20 japhb whiteknight, I'm still in favor of Bessie.
20:20 whiteknight Bessie?
20:20 japhb whiteknight, no JIT core on amd64.  ;-)
20:20 japhb (the rifle)
20:20 mikehh of course - I run everything :-} ha ha
20:20 whiteknight oh right right, there is no JIT on x64
20:20 chromatic What happens when Everyone But Allison agrees on an idea?
20:20 pmichaud I'm simply saying that there appear to be times when Parrot cannot simultaneously adopt a new API and support an old one
20:21 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
20:21 mikehh which
20:21 Coke chromatic: except for the "everyone but coke", I agree with you.
20:22 whiteknight Allison seemed more amenable to the idea last I talked to her
20:22 whiteknight I don't want to speak for her, of course
20:22 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
20:23 pmichaud (less if they choose to target monthly releases instead of supported releases, but it's still a 1-5 month delay)
20:23 pmichaud er, 1-6 month delay
20:23 dalek rakudo: 0d6c42b | moritz++ | src/setting/Rat.pm:
20:23 dalek rakudo: fix infix:</>(Int, Rat)
20:23 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​d6c42bcf0cc5ab01fa439fbfffa021b8360bcef
20:23 chromatic Right.  That's why I never liked and still don't like the biannual releases.
20:24 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
20:24 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.
20:24 pmichaud Coke: suppose that CONTEXT(...)  had been an actual API
20:24 Coke then it would have been a function call.
20:25 pmichaud Coke: the problem is not the macro, it's the fact that it relies on the Parrot_Context structure
20:25 pmichaud so suppose that Parrot_Context is an actual API
20:25 pmichaud 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
20:26 mikehh well there are published api's and internal ones
20:27 mikehh maybe those should be dpi's
20:27 whiteknight we've never actually published a comprehensive API that we do support
20:27 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.
20:27 pmichaud chromatic: I agree fully.  I'm fine with that.
20:27 whiteknight and it does seem weird that we support an API that we've never defined
20:27 duk3leto chromatic++
20:27 pmichaud chromatic: I'm not fine with trunk having to wait until January before it can get rid of the old API.
20:27 chromatic Exactly.
20:27 pmichaud (and get the new ones)
20:27 duk3leto (supporting undefined APIs)--
20:27 Coke chromatic++ for restating my point more cogently.
20:28 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.
20:28 pmichaud I'm not fine with trunk having to wait until after January before it can get the new API
20:28 jonathan Just because Rakudo pokes into them doesn't mean it's a supported API.
20:28 pmichaud I agree.
20:28 jonathan It just means Rakudo pokes into them.
20:28 pmichaud I agree.
20:29 chromatic I haven't read anyone disagreeing with that here now.
20:29 japhb Is anyone disagreeing at this point?
20:29 mikehh not at all
20:29 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.
20:29 whiteknight That I am aware of, the only thing blocking the context_pmc3 branch from merging is the JIT failure
20:29 Coke there are 4 items in the support policy that we have to worry about. this isn't one of them.
20:30 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
20:30 Coke =item * bytecode changes (opcode or core PMC removals, renames)
20:30 Coke =item * PARROT_API function changes
20:30 Coke =item * PIR or PASM syntax changes
20:30 Coke =item * API changes in the compiler tools
20:30 pmichaud whiteknight: let me review the thread
20:30 whiteknight pmichaud: please do
20:30 japhb whiteknight, seriously, make --runcore=jit do --runcore=fast, and get on with our lives.  That suggestion was not in jest.  :-)
20:30 Coke (with the possible caveat that any PARROT_API items that return or take a struct are, for now, "experimental")
20:31 pmichaud http://lists.parrot.org/pipermail/​parrot-dev/2009-August/002746.html
20:31 chromatic Right.  Pointers returned from PARROT_API functions are *opaque*.
20:31 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
20:31 pmichaud "Keep backward compatibility with the CONTEXT(interp) macro, by having it
20:31 pmichaud return the data struct of the Context PMC. Introduce a new function
20:31 pmichaud 'Parrot_pcc_get_current_context' that returns the PMC (it's a clearer
20:31 pmichaud name anyway), and we'll deprecate the old macro for 2.0. ...
20:31 pmichaud ---
20:31 pmichaud I don't think this is possible.  Perhaps I'm wrong.
20:31 whiteknight japhb: I agree 100%.
20:32 Coke kkkkkkkkkkkkkkkkkkkkkkkkkk1G:q!
20:32 chromatic It's incompatible with the 1.6 milestone of struct review.
20:33 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:34 pmichaud 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 pmichaud *bacek
20:34 pmichaud and that this should be done before the branch is merged.
20:34 moritz same here
20:35 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.
20:35 pmichaud I'll be happy to be proved wrong.
20:36 chromatic Okay, hold on one moment then.
20:38 Util cotto: ping
20:40 cotto Util, pong
20:41 chromatic Okay.  Now everyone can be mad at me.
20:41 whiteknight chromatic: I could never be mad at you!
20:42 whiteknight (and why should we be?)
20:42 chromatic r40913
20:44 dalek parrot: r40913 | chromatic++ | trunk/docs/project/support_policy.pod:
20:44 dalek parrot: [docs] Clarified Parrot components not subject to our deprecation policy.
20:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40913/
20:44 pmichaud that doesn't make me at all angry.
20:45 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
20:45 pmichaud (I include myself in the majority that agrees with that aspect of the deprecation policy)
20:45 duk3leto chromatic++ for adding scary language to the support policy
20:45 jonathan +1
20:45 purl 1
20:45 Util chromatic++
20:46 chromatic Now about that --runcore=fast idea....
20:46 japhb chromatic++
20:46 whiteknight I would love to do that
20:46 whiteknight keeps functionality the same as far as the user is concerned, improves performance, and brings "JIT" to all supported platforms
20:47 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
20:47 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.
20:48 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?
20:49 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
20:50 nopaste "pmichaud" at 72.181.176.220 pasted "just to make sure my position is clear" (29 lines) at http://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."
20:50 whiteknight After the runcore branch lands (ETA on that?) We should start a proof-of-concept branch to replace --runcore=jit with the fastcore
20:52 moritz Util: are you also 'Util' on github?
20:52 chromatic Trivial after the runcore branch lands.
20:53 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
20:53 whiteknight my point being that it's easier to argue for particular semantics when you have a patch in hand that implements them
20:54 Util moritz: Yes, thanks.
20:54 moritz Util: done
20:54 chromatic A benchmark that demonstrates that the fast core is faster than the JIT core wouldn't hurt either.
20:54 Util Thanks!
20:54 * pmichaud hugs moritz++
20:57 pmichaud whiteknight: how hard would it be to come up with a patch that removes the JIT core ?
20:58 whiteknight pmichaud: in terms of changing --runcore=jit to use the fastcore instead, trivia
20:58 pmichaud oh wait, scratch that
20:58 whiteknight trivial
20:58 pmichaud yes, that's the patch I'm thinking of
20:58 pmichaud if we changed --runcore=jit to use fastcore, would that resolve the remaining issue with the context_pmc3 branch?
20:58 whiteknight in terms of actually removing the JIT system wholesale, it will be more "fun" and less "work"
20:58 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.)
20:58 whiteknight pmichaud: yes it should
20:59 pmichaud and it wouldn't introduce any other visible stability issues?
20:59 pmichaud (other than things might become much more stable, that is :)
21:00 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
21:00 pmichaud look, I have a good JIT versus non-JIT benchmark -- my desktop is currently running i386
21:00 pmichaud and I can certainly run a rakudo spectest both with and without jit
21:00 pmichaud and rakudo spectest exercises a *lot* of Parrot
21:00 pmichaud we can also time 'make test'
21:01 pmichaud 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 MoC joined #parrot
21:01 bacek joined #parrot
21:02 japhb +1
21:02 purl 1
21:02 chromatic Excellent.
21:02 whiteknight agreed
21:02 duk3leto pmichaud++
21:02 whiteknight land the runcore branch first, then the switch will be easy
21:02 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
21:02 chromatic pmichaud, does the Rakudo spectest suite use the fakecutable or execute Parrot directly?
21:03 pmichaud and at that point we can ask ourselves "is this really worth it?"
21:03 pmichaud chromatic: it currently uses the fakecutable, but it's an easy patch (env setting, I think) to get it to use Parrot instead
21:03 pmichaud checking
21:04 pmichaud export HARNESS_PERL="parrot_install/bin/parrot perl6.pbc";   make spectest   # should work
21:04 pmichaud testing
21:04 pmichaud yes, it works.
21:04 pmichaud oh, wait, it appears to still be using the fakecutable
21:05 chromatic Patch forthcoming.
21:05 pmichaud oh, it's hardcoded in t/harness
21:07 nopaste "chromatic" at 72.87.39.97 pasted "-t" (12 lines) at http://nopaste.snit.ch/17771
21:07 pmichaud changing line 59 of t/harness seems to do it
21:08 * 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?
21:08 whiteknight then we can forget about all this "fakecutable" nonsense
21:08 whiteknight pmichaud: yes
21:08 pmichaud okay.
21:09 pmichaud 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?
21:10 whiteknight I have objections to not doing it
21:10 whiteknight 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
21:10 whiteknight but in the interim an increase of 10x should do it
21:10 chromatic Let me give you a quick benchmark then.
21:11 whiteknight I'm about to sign off and go home from work
21:11 whiteknight msg them to me?
21:11 purl Sorry, I've never seen them before.
21:11 japhb whiteknight, when you say pool sizes the same,
21:11 whiteknight I mean number of PMCs
21:11 whiteknight not size in bytes
21:11 japhb do you mean same number of PMCs in pool?
21:11 japhb ah yes, that's what I thought
21:11 * whiteknight was too ambiguous
21:11 japhb good $commute
21:12 whiteknight later
21:14 bacek Good morning
21:14 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
21:14 darbelo Tested the context_pmc3 branch on OpenBSD getting a segfault on t/pmc/context.t is this a known issue?
21:14 darbelo Heh. That was good timing.
21:14 bacek darbelo: :)
21:15 pmichaud is there an easy way to verify that I'm running Parrot with the jit core?
21:15 pmichaud (e.g., from PIR)
21:15 bacek darbelo: it shouldn't fail... It's just creating new Context PMC...
21:16 bacek pmichaud: "running core" isn't exposed into PIR afaik
21:16 pmichaud not even in the interpreter object?
21:16 darbelo Wait a sec, I just noticed something... Let me get back to you in a sec.
21:16 japhb Hmmm, for some reason I thought it was exposed through interpinfo or something.  Or maybe we just discussed that last year ....
21:17 duk3leto pmichaud: sounds like there should be but isn't
21:17 japhb .macro_const INTERPINFO_CURRENT_RUNCORE 14
21:17 japhb There you go.
21:17 chromatic Yep, it's in interpinfo.
21:19 mikehh darbelo: it doesn't fail for - it passes no problemo
21:21 mikehh there should be a me before the -
21:21 pmichaud is there a list of the interpinfo runcore values somewhere?
21:21 pmichaud I'm getting back a value of 0
21:22 * japhb wonders if the key exists but no one is home (meaning INTERPINFO_CURRENT_RUNCORE never gets set)
21:23 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 :)
21:23 pmichaud okay, so 'parrot' defaults to the slow core even when jit is available?
21:23 chromatic Yes.
21:24 pmichaud 16 looks like the jitcore then
21:24 pmichaud and then, fwiw, Rakudo appears to segfault when run with the jitcore
21:24 pmichaud (on my system)
21:24 japhb \o/
21:25 pmichaud so no chance of --runcore=jit being much improvement for Rakudo :0|
21:26 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 :)
21:26 moritz broken = terminates very soon ;-)
21:26 pmichaud no, it still takes a bit of time to terminate
21:26 japhb moritz, heh
21:27 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 ...."
21:27 japhb LOL
21:27 japhb OK, I think that's pretty much conclusive evidence right there, pmichaud.
21:28 nopaste "pmichaud" at 72.181.176.220 pasted "rakudo timings for fast, slow, and jit cores" (19 lines) at http://nopaste.snit.ch/17772
21:29 bacek yak....
21:29 japhb Interesting how little the fast runcore helps you there.
21:29 pmichaud most of the cost is startup
21:29 jonathan bwahaha...
21:29 chromatic The more bytecode, the slower our "JIT" will run.
21:30 darbelo The fast core *finishes* faster than the JIT *segfaults*.
21:30 jonathan 13 seconds extra just to generate a segfault :-)
21:30 darbelo That is seriously broken.
21:30 jonathan but...but...this is the jit that ran a micro-benchmark faster than gcc -O3! ;-)
21:31 japhb darbelo, which is exactly what we've been trying to tell Allison at #ps today
21:31 japhb s/we've/we had/
21:31 pmichaud running Parrot's "make test" for comparison
21:31 darbelo I wasn't paying attention to #ps today, just now started reading the logs.
21:32 japhb darbelo, No worries ... I was just confirming.
21:33 chromatic I think that microbenchmark would run even faster now.
21:33 chromatic ... but that's because of startup time improvements, not JIT improvements.
21:34 japhb "Runs so fast it strips tiles off the space shuttle!  (Wait, what?  That's *bad*?  Oh, crap.)"
21:34 japhb Must ... dial ... back ... fist ... of ... death ....
21:35 pmichaud stripping tiles off the space shuttle is bad only for re-entry
21:35 pmichaud once it's landed, stripping tiles is a good thing :)
21:36 darbelo Both points are irrelevant if the JIT explodes during take off :)
21:38 dalek rakudo: ba10463 | last.of.the.careless.men@gmail.com++ | src/setting/Rat.pm:
21:38 dalek rakudo: Move Rat.Str to new standard, add Rat.nude.
21:38 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
21:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​a10463f51e252cb7d7d383c7a925ef2697e5fd1
21:40 japhb Nude Rats? OKAY ....
21:40 pmichaud thankfully *that's* not the Perl 6 mascot :)
21:41 nopaste "pmichaud" at 72.181.176.220 pasted "make test timings for fast, slow, and jit core" (15 lines) at http://nopaste.snit.ch/17773
21:42 pmichaud that's not really as valid a test as rakudo spectests might be, though.
21:42 pmichaud because it's a bit biased against the jit
21:42 japhb Interesting ... though I suspect that's a matter of Parrot tests overemphasizing native types.
21:43 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
21:43 chromatic The slow core runs a lot more tests.
21:44 darbelo bacek: I'm still getting the failure.
21:44 bacek darbelo: nopaste backtrace?
21:45 bacek darbelo: (but Context PMC created very often... So I can't even imagine why it can fail...)
21:45 jrtayloriv join #parrotsketch
21:45 jrtayloriv oops -- sorry :)
21:45 pmichaud oh, looks like 'make testj' doesn't run the NQP tests
21:45 bacek jrtayloriv: too late :)
21:45 jrtayloriv bacek, just wanted to see topic
21:45 mikehh try testb
21:46 darbelo nopaste?
21:46 purl i guess nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo
21:47 bacek darbelo: http://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 http://nopaste.snit.ch/17774
21:47 darbelo bacek++
21:48 darbelo bace--
21:48 darbelo there, now that karma is where it belongs.
21:49 mikehh just look what posting about g++ does for g's karma
21:49 moritz g--
21:50 darbelo (g++)--
21:51 mikehh karma g
21:51 purl g has karma of 620
21:52 darbelo mikehh: you and NotFound are to blame for most of that :)
21:52 joeri left #parrot
21:52 mikehh for someone not here he/she/it is doing very well
21:53 g I have lots of karma. WHEE!
21:53 g all your karma is belong to me.
21:54 mikehh see if you took it with you :-}
21:54 bacek darbelo: yay! Good catch for Context.
21:55 treed So, was it ever determined whether the get_pmc_keyed thing was StringIterator breaking again?
21:55 bacek darbelo++ # using some strange architecture
21:55 dalek parrot: r40914 | bacek++ | branches/context_pmc3 (2 files):
21:55 dalek parrot: [cage] Don't mark non-initialised Context. darbelo++
21:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40914/
21:55 darbelo Catch what? I have no clue why that pointer is NULL.
21:55 bacek treed: Yes. After merge keys_revamp branch
21:56 bacek 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 http://nopaste.snit.ch/17775
21:56 treed bacek: Is that actually breakage, or was something deprecated out?
21:57 bacek pmichaud: looks suspicious.
21:57 japhb fast and slow are within .5% of the same?  That sounds swamped by startup time or so.
21:57 pmichaud agreed
21:57 bacek treed: something that wasn't covered in test suite. So, actual breakage.
21:57 treed Ah. Is there an issue assigned?
21:57 chromatic The difference between fast and slow is that slow does bounds checking of the program counter.  That's about it.
21:57 treed (Or is the fix expected soon/already in?)
21:57 bacek treed: it should be fixed already.
21:57 treed k
21:58 * 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?
21:58 japhb chromatic, I thought "fast" also picked the fastest variant of switch, cg, cgp, etc.?
21:58 japhb Or is that out of date?
21:59 bacek treed: if it still broken - create ticket and assign to me. I'll fix it tonight.
21:59 treed bacek: k
21:59 chromatic I don't believe it does.
22:00 nopaste "pmichaud" at 72.181.176.220 pasted "NQP make test timings for fast, slow, and jit core" (24 lines) at http://nopaste.snit.ch/17776
22:01 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:02 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 japhb But then you can't make a minimized test to demonstrate the problem ....
22:02 japhb er "Throw some"
22:08 darbelo bacek++ # context_pmc3 shows "All tests successful" on OpenBSD amd64.
22:08 treed bacek: Yeah, still borked. I'll make a ticket.
22:09 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.
22:09 treed There's also a warning printed during tests about double free.
22:09 treed Which isn't related (AFAIK), but might be worth looking into.
22:09 bacek String or StringIterator?
22:10 treed It's String, but as far as I know, we don't even call get_pmc_keyed on String ourselves.
22:10 treed The last time I got that error message, I tracked it down to StringIterator.
22:10 mikehh bacek: that's in trunk - with the context_pmc3 branch there are a loads of failures in make test
22:11 bacek mikehh: it's not good...
22:12 whoppix joined #parrot
22:13 treed Actually, this doesn't even look like it's anything in Cardinal.
22:13 treed The failure comes after a long list of parrot-compiler stuff.
22:13 treed get_pmc_keyed() not implemented in class 'String'
22:13 treed current instr.: 'parrot;POST;Compiler;pir_children' pc 9678 (src/POST/Compiler.pir:81)
22:14 treed The only cardinal thing in the whole traceback is the top-level main.
22:14 treed Which instantiates an HLL Compiler and uses it.
22:15 treed 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
22:17 bacek mikehh: ah. it explains why it fais
22:17 bacek fails
22:17 nopaste "bacek" at 66.215.91.229 pasted "Backtrace" (17 lines) at http://nopaste.snit.ch/17777
22:17 treed er
22:17 darbelo mikehh: what happens if you "make realclean" both trees and then only 'perl Configure.pl' the one you want to test?
22:17 treed I misunderstood what -n means, I guess.
22:17 treed That was me.
22:18 mikehh bacek: only just noticed now
22:18 bacek Hey. I didn't paste it!
22:18 treed I know, I did.
22:18 treed Sorry.
22:18 treed I thought that was the "pasted for" option for some reason.
22:18 Whiteknight joined #parrot
22:19 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:20 treed make realclean more or may not actually capture everything
22:20 treed s/more/may/
22:20 * treed really should just remove the Makefile build system.
22:21 mikehh using respectively ../g.parrot, ../parrot or ../config_pmc3
22:21 Whiteknight treed: How is cardinal doing today? Still experiencing failures?
22:22 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.
22:22 mikehh yeah - it seems to retain the make test run directory
22:22 treed There are three such failures in the test suite.
22:23 treed And one instance of parrot(6895) malloc: *** error for object 0xe27ba0: double free
22:23 treed *** set a breakpoint in malloc_error_break to debug
22:23 treed That doesn't actually cause bailout.
22:23 treed Or any failure in Cardinal's test suite.
22:23 Whiteknight hmmm, weird
22:23 treed But the get_pmc_keyed failure causes the compiler itself to fail.
22:23 treed So I can't actually run those three test files.
22:24 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
22:25 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
22:26 darbelo I looked arround and it's used all over the place. Is there any 'standard replacement' for it?
22:26 whoppix joined #parrot
22:26 mikehh treed - I'll make a note of it
22:26 treed k
22:26 treed I'll probably yank the Makefile system soon.
22:27 bacek treed: fixed. dcommiting
22:27 bacek r40915
22:27 treed What's fixed?
22:27 purl fixed is probably handy
22:27 dalek parrot: r40915 | bacek++ | trunk (2 files):
22:27 dalek parrot: [cage][t] Add String.get_pmc_keyed and tests for keyed access to string.
22:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40915/
22:28 treed Ah.
22:28 * treed repulls.
22:30 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:38 bacek treed: any luck?
22:39 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?
22:39 treed bacek: Running test:all now.
22:40 treed mikehh: How are you invoking the rakefile?
22:40 bacek treed: ok
22:40 treed bacek: It takes about 8 minutes to run it to completion on my laptop.
22:40 Whiteknight darbelo: I don't know
22:40 bacek darbelo: why do you need C-string?
22:41 treed bacek: Still failing, looks like.
22:41 darbelo I want to kill strstart with fire. But it's used all over the place.
22:41 jonathan darbelo: imo, using strstart is poking into string guts, which I suspect is very wrong.
22:42 darbelo jonathan: That's why I want to kill it :)
22:42 rg1 joined #parrot
22:42 jonathan Ah, good...when I read the question at first I thought you were debating which to use for some new code. ;-)
22:43 jonathan Any cleanup we can do to avoid looking at ->strstart outside of the strings subsystem is surely progress though.
22:45 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:46 jonathan darbelo: It's surely the wrong way to get at a c string though.
22:46 jonathan For one, you don't know the encoding...
22:47 mikehh treed: rake cardinal
22:48 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
22:48 treed or you can export it beforehand
22:48 treed rake reads that environment variable
22:48 treed if it's not set, it just uses the one from $PATH
22:49 treed (This won't actually accur if build.yaml already exists, since that's the cache for that info.)
22:49 treed occur
22:49 treed You could also manage build.yaml yourself with pointers to the various parrot_configs as you want or whatever.
22:51 treed 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:55 whoppix joined #parrot
22:55 mikehh I am starting to make stupid mistakes - I look at it after I sleep some - bbl
22:56 treed k
22:56 darbelo bacek: ping
22:57 bacek darbelo: pong
22:58 darbelo Would the use of auto_attrs benefit the Context PMC?
22:58 bacek darbelo: yes, absolutely.
22:58 bacek But after merge in next branches
22:59 darbelo Ok, I was just looking arround and it made me curious.
23:00 darbelo Oh, wait. You branched from trunk before auto_attrs landed, right?
23:00 bacek you can help with finishing Continuation.
23:00 darbelo Continuation? Where?
23:00 purl continuation is builded inside the opcode, there is no way to pass a differente location.
23:00 bacek No, I branched after. But it's too much changes for single branch.
23:01 bacek darbelo: jrtayloriv working on Continuations
23:02 darbelo Ah, sorry I thought you meant on the same branch. I'll bother him when he's arround :)
23:03 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:04 jrtayloriv 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 :)
23:04 jrtayloriv pretty much *done*, that is
23:06 bacek jrtayloriv: ok.
23:06 jrtayloriv bacek, I'm passing all tests on context_pm3 (r40915) on Linux x86_64 btw ;)
23:07 bacek jrtayloriv: it's... expected :)
23:07 jrtayloriv cool -- just didn't know if you had any tests for it lately.
23:09 darbelo bacek: If all tests pass, what's holding back the merge?
23:10 bacek mikehh++ tested it on x86_64, darbelo++ on openbsd.
23:10 bacek darbelo: JIT
23:11 beta joined #parrot
23:11 darbelo Oh, *that* is what triggered the JIT-bashing today.
23:11 bacek :)
23:11 * darbelo wants to see a kill_JIT_with_fire branch.
23:11 treed bacek: Yeah, still failing on the same three files, same backtrace.
23:11 kid51 joined #parrot
23:12 bacek treed: yak...
23:12 * bacek wants to see make_sane_jit branch instead...
23:13 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:14 bacek jrtayloriv: which line? which branch?
23:14 jrtayloriv context_pmc3 line 43
23:14 jrtayloriv oh nm -- I see
23:14 darbelo bacek:  make_sane_jit depends on kill_insane_jit ;)
23:14 bacek jrtayloriv: leftover. Many of this functions can be removed now
23:17 bacek treed: it's strange. I've implemented exactly this method in String...
23:17 treed Huh.
23:18 treed Maybe I didn't get your revision with that svn up?
23:18 Whiteknight jrtayloriv
23:18 purl jrtayloriv is using r40849
23:18 Whiteknight has anybody committed those patches of yours?
23:18 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?
23:19 treed Huh.
23:19 * treed just got an ssh error trying to svn up.
23:19 jrtayloriv Whiteknight, nope, don't think so
23:19 Whiteknight okay, I'm on it now
23:19 jrtayloriv Whiteknight, thanks :)
23:20 Whiteknight so that's the latest two patches need a'committin'?
23:20 bacek japhb: +1 for this sequence.
23:21 donaldh joined #parrot
23:21 bacek bacek ~~ $dayjob
23:23 whoppix joined #parrot
23:23 jrtayloriv Whiteknight, yes
23:23 Whiteknight Okay, testing the first one now
23:26 dalek parrot: r40916 | whiteknight++ | branches/kill_parrot_cont (2 files):
23:26 dalek parrot: [kill_parrot_cont] remove the new_continuation and new_ret_continuation function. Patch from jrtayloriv++
23:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40916/
23:27 Whiteknight ...and testing the second
23:31 treed purl: msg bacek The error is now: Method 'lineof' not found for invocant of class 'String'
23:31 purl Message for bacek stored.
23:33 dalek parrot: r40917 | whiteknight++ | branches/kill_parrot_cont/​src/pmc/continuation.pmc:
23:33 dalek parrot: [kill_parrot_cont] fix a GC bug that was causing a test failure. Courtesy jrtayloriv++
23:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/40917/
23:34 chromatic Whiteknight, doesn't Parrot_custom_mark_destroy_SETALL also the active destroy flag?
23:35 Whiteknight chromatic: I have no idea. Seems like it should, but probably doesn't
23:36 Whiteknight I usually see the two set together
23:36 Whiteknight (I'm also not entirely clear what the difference is)
23:36 jrtayloriv chromatic, IIRC one of them says " I have a custom mark()" the other says I have custom destroy()
23:36 chromatic See include/parrot/pobj.h:358
23:36 jrtayloriv I honestly don't remember which is which.
23:38 jrtayloriv chromatic, oh I see -- I must have read about custom_mark and active_destroy, and accidentally put custom_mark_destroy, which does both.
23:39 jrtayloriv 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:40 chromatic I like the idea.
23:41 Whiteknight the active_destroy flag can probably disappear completely
23:41 Whiteknight the auto_attrs work has left it mostly useless
23:42 darbelo Whiteknight: Not all PMCs have auto_attrs set, and some still need custom destruction.
23:43 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
23:43 Whiteknight doesn't matter if it has auto_attrs or not
23:43 darbelo Wait. The flag is ignored?
23:44 chromatic I'm not a fan of that.
23:45 Whiteknight that I am aware of, yes
23:46 Whiteknight There are ways we could avoid unnecessary VTABLE calls without using the flag
23:46 Whiteknight if we want to avoid them
23:46 darbelo Whiteknight: Parrot_pmc_destroy only calls VTABLE_destroy if PObj_active_destroy_TEST(pmc) is true.
23:47 darbelo Hell, if the VTABLE starts getting called unconditionally then decnum-dynpmcs will start segfaulting again.
23:48 Whiteknight oh, does it? I thought that had changed
23:48 Whiteknight maybe
23:48 Whiteknight NotFound unchanged it
23:51 darbelo Also, not calling VTABLE_destroy() is the only available workarround for TT#956 that I can think of.
23:52 chromatic I think the right answer to that is don't use a custom destroy there.
23:52 chromatic Or don't make them a singleton.
23:56 darbelo Well, I need it to be a singgleton, and not using a custom destroy "leaks" the memory.
23:57 chromatic That's not how singletons work.
23:58 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:59 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
23:59 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.

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

Parrot | source cross referenced