www.parrot.org | planet.parrot.org | 1.5.0 "TEH PARROTZ!" Released! | Feature freeze over, coders start your engines!
Set by moderator on 18 August 2009.
mikehh testr FAIL, All others PASS (pre/post-config, smoke, nqp_test, rest of fulltest) at r40724 - Ubuntu 9.04 amd64 (g++) (see TT #939) 00:02
the test t/dynpmc/foo.t passes testr on i386 - on amd64 it fails test 6 & 7 00:03
chromatic mikehh, did you bisect the failures? 00:04
mikehh not exactly but it passed at r40676 but failed at r40685 00:07
and since
chromatic I don't know if anyone will fix it accidentally. If you can pinpoint it to one commit, we may have a better time of things. 00:08
mikehh I am not exactly sure how to bisect from there
chromatic Check out r40680 and see if it passes.
mikehh ok I try that 00:09
00:12 kid51 joined, pyrimidine joined
mikehh actually I will do it a bit later - I need some sleep before I start doing something really stupid 00:13
00:21 cotto joined 00:25 pyrimidine joined 00:31 quek left
dalek rdinal: f34c51f | (Joeri Samson)++ | src/parser/ (2 files):
Removes two unused rules from grammar
 00:46
rrot: r40725 | whiteknight++ | branches/pmc_sans_unionval (2 files):
[pmc_sans_unionval] Found the source of the test failure, it was the fixed-size allocator. Disabled that for now, will examine it more in a different venue. This branch is ready to merge into trunk now
 00:55
Whiteknight stupid alligator 00:57
dalek rrot: r40726 | whiteknight++ | failed to fetch changeset:
[pmc_sans_unionval] merge this branch into trunk. Resolves TT #549
 01:20
Whiteknight and with that monkey off my back, I can get to focusing on the alligator 01:21
(#parrot has just turned into zoobooks)
01:30 pyrimidine joined
dalek rrot: r40727 | NotFound++ | trunk/src/gc/mark_sweep.c:
[cage] fix c++ build
 01:33
kid51 I have one test failure for r40726 on Darwin/PPC: t/dynpmc/foo.t 01:47
smolder.plusthree.com/app/public_pr...ails/26464 01:48
smolder.plusthree.com/app/public_pr...ails/26463 is a successful smolder for Linux/i386.
nopaste "kid51" at 67.240.249.240 pasted "t/dynpmc/foo.t failure on Darwin/PPC after merge of pmc_sans_unionval branch" (25 lines) at nopaste.snit.ch/17644 01:51
kid51 Whiteknight ping 01:54
nopaste "GeJ" at 202.22.227.62 pasted "Similar error as reported by kid51. (platform is FreeBSD amd64)" (23 lines) at nopaste.snit.ch/17645 01:55
Whiteknight kid51: pong
kid51 Looks like a very impressive merge, but there's one little test that isn't making it.
Have any ideas? 01:56
Whiteknight I saw that t/dynpmc/foo.t error, fiddled some stuff, and it disappeared
so it must be intermittant
kid51 or OS-specific?
Whiteknight let me take a look, I might be able to kill it with fire
kid51 Could it be an endian problem? 01:58
GeJ I'd go for OS-specific. Running prove -v t/dynpmc/foo.t 6 times in a row consistently reports 6 segfaults.
Whiteknight hmm, I didn't see the same error that either of you are seeing 02:00
I saw the same test fail but for a different reason
okay, I just saw the same error that GeJ saw. I can only get it to appear about 1/4 times 02:01
02:03 pyrimidine joined
Whiteknight ...and the backtrace is hideous 02:04
kid51 I get it consistently on Darwin PPC. Note 'endianness' is an OS-specific thing. My Darwin is bigendian; my Linux is not.
GeJ is FreeBSD bigendian? 02:05
Gej: Your paste shows skip on test 6 and failure on test 7. I have failure on 6 and pass on 7. 02:06
GeJ kid51: yes, sorry, I realized too late that it wasn't the same error. 02:07
Sorry for the confusion.
kid51 np
Whiteknight these horrible calling conventions data structures 02:08
it's all as confusing and convoluted as possible
endianness is a hardware-specific thing 02:09
GeJ question, what's needed to enable BigInt and BigNum features ? 02:10
kid51 I suspect it's a library you install with your packaging system.
I probably installed it years ago just so I could get some Parrot tests to not skip. 02:11
Whiteknight GMP 02:12
Whiteknight has to go now, will have to fix this problem tomorrow 02:13
kid51 Yes, GMP is the library 02:14
GeJ Aaaah. let's build that then. 02:19
kid51 make fulltest passes on Linux/i386. 02:20
IIRC, GMP is one of those things that you want to use your packaging system for rather than compiling from scratch.
but that was > 2years ago. YMMV 02:21
GeJ under FreeBSD packaging system pretty much means compiling from scratch. Except that someone pretty much figured all the problems and made removed the rough corners for you. 02:23
02:28 TiMBuS joined
GeJ new smoke test uploaded. BigInt and BigNum tests seem to pass now (test number increased by ~140). The segfault in t/dynpmc/foo.t remains. 02:31
smolder.plusthree.com/app/public_pr...ails/26468 02:32
02:35 janus joined 02:36 patspam joined
kid51 must sleep 02:47
purl $kid51->sleep(8 * 3600);
03:05 pyrimidine joined 03:14 michel joined 03:16 quek joined 03:21 theory joined 03:59 mokurai joined 05:02 szabgab joined
Tene allison: your most-recent pcc commit adds five new failures to t/op/calling.t for me 05:33
allison Tene: the reversion? 05:35
Tene: or fetching an integer value instead of a PMC value 05:36
the latter was a fix for a warning about casting a pointer to an integer, because it was fetching a PMC value and storing it in an INTVAL variable 05:37
(but then, the variable was never used, so could have been deleted, but I left it figuring it was probably going to be used for the slurpy modifications) 05:38
if it was the reversion, then it's a false positive
named arguments should never be stored in the positional array
so, if storing a named argument in the positional array fixes a failing test, it's just working around another bug elsewhere 05:39
I'm working on "Null PMC access in get_string_keyed_str()" in Test;Builder 05:40
probably actually somewhere in the I/O subsystem, since it doesn't happen until after the 'puts' method is called on a FileHandle object 05:41
Tene allison: it was the latter, afaict. 05:51
although, they're not failing i nmy current checkout, so i guess maybe I fixed it? 05:52
regardless, don't worry about it.
05:58 beta joined
dalek rrot: r40728 | tene++ | branches/pcc_arg_unify (2 files):
[pcc] Fail on too many params. Update more error tests.
 06:05
allison Tene: which test file are you working on? 06:15
Tene t/op/calling.t
purl well, t/op/calling.t is failing in trunk?
allison Tene: okay, it's t/src/extend.t that I know still has unconverted functions 06:16
(not related)
Tene: the fix I just committed finally allows the PIR test files to run 06:18
dalek rrot: r40729 | allison++ | branches/pcc_arg_unify/src/call/pcc.c:
[pcc] Delay vtable function on PMC until after null check on the PMC.
 06:19
allison Tene: some of the PIR test files that were failing before now pass all tests successfully 06:20
Tene: some of them reveal more problems. I killed t/op/annotate.t after it reported 60000+ successful tests out of 33 planned tests 06:21
Tene heh
allison Tene: it's playing with exceptions and annotations, so there's a good chance this is one of those infinite exception loops (throwing an exception while in the middle of handling an exception) 06:23
Tene I can probably fix it tomorrow. Going to bed shortly.
allison Tene: exactly what I was going to say 06:24
Tene but yes, I agree.
add a pop_eh before the 'elements' call
to see the real issue. 06:25
allison Tene: inside the handlers? yes 06:26
Tene line 42 of annotate.t
allison it's a multiple dispatch error "No applicable methods" 06:28
which means it's probably attempting to dispatch on the wrong PMC 06:29
(not passed correctly somewhere along the line) 06:30
it's actually 'is($I0, 0...' that's borking 06:37
06:38 cono joined
allison well, that's fair, since 'is' is declared as a :multi, and isn't declared with a "Integer, Integer" variant 06:40
so, it's autoboxing again
06:57 kjeldahl joined
ttbot Parrot trunk/ r40726 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/75513.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 07:30
Parrot trunk/ r40727 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/75514.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
07:32 ilbot2 joined
moderator www.parrot.org | planet.parrot.org | 1.5.0 "TEH PARROTZ!" Released! | Feature freeze over, coders start your engines!
08:06 quek left 08:15 michel joined
mikehh magnet.llarian.net irc - looks like it just died - even purl 08:35
08:36 Tene joined 08:52 Eevee joined 08:53 Ron joined 09:08 chromatic joined 09:36 MoC joined 10:00 flh joined 10:01 confound joined, TiMBuS joined, cotto joined, particle joined, solarion joined, TimToady joined, nopaste joined, Aisling joined, spinclad joined, ingy joined, basic joined, s1n joined, magnachef joined, silug joined, purl joined, mmpf joined 10:35 bacek joined 10:46 kjeldahl joined
dalek TT #942 created by MoC++: GCC 4.4 complains about invalid C90 syntax 10:48
10:51 Whiteknight joined
MoC Hi Whiteknight. Could you please take a look at this: trac.parrot.org/parrot/ticket/942? It still worked yesterday and since I know from your blog posts that you are involved in the GC development I thought I'd ask you directly.. 10:58
Whiteknight good morning MoC 10:59
okay, fixed 11:01
sorry about that, some code got out of order in the merge last night
MoC No problem, thanks for fixing it promptly :) 11:02
dalek rrot: r40730 | whiteknight++ | trunk/src/gc/mark_sweep.c:
[gc] fix a problem with mixed declarations and code for TT #942. MoC++
 11:04
bacek Whiteknight: hi 11:07
nopaste "bacek" at 122.110.46.106 pasted "context_pmc3 shenanigans..." (21 lines) at nopaste.snit.ch/17648
bacek Whiteknight: any ideas about what the heck happens in nopaste.snit.ch/17648
?
Whiteknight bacek: is that in trunk? 11:09
bacek context_pmc3
Whiteknight oh, nevermind
let me lok
look*
that test passes on my system 11:10
Linux x86_64
bacek it passed on my if I just rename file :/
Whiteknight that's weird 11:11
bacek indeed... 11:12
purl indubitably
bacek botsnack
purl thanks bacek :)
Whiteknight bacek: I merged the pmc_sans_unionval branch a few hours ago, I hope that doesn't mess up any of the context_pmc stuff 11:13
mikehh Whiteknight: I have been getting failures with make testr (as part of fulltest) since r40680 - do you also get these failures?
Whiteknight mikehh: intermittently. I didn't see it before I merged
I'm starting to look at it now
bacek Whiteknight: I can clean any mess. I just need to understand why exceptionhandler test failing... 11:14
Whiteknight mikehh: t/dynpmc/foo.t?
purl t/dynpmc/foo.t is failling even with a fresh check out
Whiteknight thanks purl
mikehh Yes - I just wanted to confirm this - I don't get the error on i386 just amd64 11:15
Whiteknight so it works fine on i386? 11:16
bacek: no idea, I can't reproduce
mikehh also I fail test 6 on a build without optimize and test 6-7 with --optimize
bacek Whiteknight: and your system is...? 11:17
Whiteknight bacek: Linux x86_64
Ubuntu 9.04 if you need specifics
mikehh thats on Ubuntu 9.04 amd64 - it passes on Ubuntu 9.04 i386
bacek Whiteknight: erm... Mine is Linux/i386. 11:18
mikehh see tt #939 11:19
Whiteknight okay, so somewhere in Parrot-land we have a problem between these two systems that is causing two separate failures
that makes me happy
except it makes me sad
mikehh only on amd64 and .pbc 11:20
Wightknight: me too :-{
Whiteknight okay, I think I have at least some of it figuredo ut 11:32
...okay, my "fix" causes the problem to appear 100% of the time instead of being intermittent 11:36
mikehh it just now failed in smolder (t/dynpmc.foo.t - test 7 that is) 11:40
at r40730
11:40 Austin joined
Austin Hello, #parrot. 11:41
Whiteknight good morning Austin 11:43
Austin I just upgraded. :(
On the plus side, the build was totally clean. No more symlink problems. 11:44
On the minus side, my close compiler now consumes all available memory and dies when killed by (I think) a kernel rlimit. 11:46
Whiteknight well, that's good 11:51
at least it's something
Austin "Something" is a good description. 11:52
Naturally, I thought of garbage collection when the PVM got up to ~700m ... 11:53
Whiteknight naturally
Austin Has something changed in the GC? I didn't see any mention in the NEWS file...
mikehh We seem to have a problem here with t/dynpmc.t
test 7 fails in smolder, test 6 in testb, test 6-7 in testC, passes testf, testg, testr, fails test6-7 in testS 11:58
bacek seen NotFound
purl NotFound was last seen on #parrot 22 hours, 19 minutes and 19 seconds ago, saying: fperrad: maybe just by mistake, let me check...
mikehh thats at r40730 on Ubuntu 9.04 amd64
Whiteknight Austin: yes, the GC changed pretty substantially last night
I merged in a branch 11:59
bacek msg NotFound can you check Capture.init. Looks veeeery suspicious.
purl Message for notfound stored.
Austin Whiteknight: aha. Time to bisect, I guess.
Whiteknight yeah, I'm working on it
bacek msg NotFound Ignore me. It's just brand new auto_attrs 12:01
purl Message for notfound stored.
dalek rrot: r40731 | whiteknight++ | trunk/src/gc/api.c:
[gc] fix one issue where a PMC has metadata that wasn't getting marked. This fixes one intermittent failure, but now I am seeing another intermittent failure that happens less frequently
 12:10
12:14 HG` joined
mikehh BTW smolder passed at r40729 but there were other problems with fulltest 12:17
12:22 HG`` joined
Whiteknight yeah 12:26
Austin yeah? 12:27
mikehh testing r40731 now
Whiteknight yeah!
this last failure is a beast, the backtrace is evil 12:28
Austin yeah?!
Whiteknight segfault is happening inside the hideous argument-passing code
Austin Oh.
Whiteknight in the deepest, darkest dungeon of Parrot hell
Austin Mine's pretty simple.
"Killed"
purl "Killed" is, like, southern for "martyred"
Austin I think one problem with the argument passing is how it's (not) done. 12:29
But 'ey. That's why we've got you.
mikehh well smolder PASSes 12:30
Whiteknight allison is refactoring all this nonsense in her branch, so she might bring some sanity to this bullshit
Austin LOL. Rots of ruck with that. 12:31
Holy crap. According to the news, Greece is on fire. 12:32
There's a pun there, I'm sure.
dalek TT #942 closed by whiteknight++: GCC 4.4 complains about invalid C90 syntax 12:43
12:44 kjeldahl joined
mikehh at r40731 t/dynpmc/foo.t fails testC and testS - failed test 6-7 and testr - failed test 7 - All other tests PASS (pre/post-config, smolder, nqp_test, rest of fulltest) - Ubuntu 9.04 amd64 (g++) 12:46
Whiteknight I can't figure out why this test is failing in any special way 12:48
or why other tests like these wouldn't be failing too 12:49
bacek Whiteknight: try valgrind 12:50
dalek rrot: r40732 | bacek++ | branches/context_pmc3/src/pmc/context.pmc:
[pmc] Add small description to Context PMC.
 12:51
rrot: r40733 | bacek++ | branches/context_pmc3/src/interp/inter_create.c:
[core] Restore set on initial recursion_depth to -1.
rrot: r40734 | bacek++ | branches/context_pmc3/include/parrot/interpreter.h:
[core][docs] Add small docs about new Context related macros.
Whiteknight bacek: ping
bacek Whiteknight: pong
Whiteknight bacek: where is the code for a PMC MULTI generated? 12:52
I think I found the solution, but it's a fix in the generated code
bacek lib/Parrot/Pmc2c
Give me diff for generated code and I'll fix pmc2c
dalek rrot: r40735 | bacek++ | branches/context_pmc3/src/jit_defs.c:
[cage] Remove accidentally commited generated file.
 12:54
Whiteknight I think I have it
rebuilding now
bacek ok 12:55
Whiteknight mikehh: ping 12:57
mikehh Whiteknight: pong
dalek rrot: r40736 | whiteknight++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[gc] I think I've fixed the error that we're seeing. I'm still not entirely certain what's happening internally that messes this up, but this fixes it.
 12:58
Whiteknight mikehh: I think I've got a fix. Can you test it out on r40736?
works on my system, but the last 24 hours shows that's not good enough criteria
mikehh doing it now (gcc)
Whiteknight thanks!
fulltest is cranking right along for me 13:02
yeah, fulltest passes for me perfecfly 13:08
so that's a good sign
13:12 joeri joined
Whiteknight somewhere along the line, the current PCC refactor requires that PMC** results arguments point to a valid, initialized PMC 13:12
er, the current PCC system
that value is never used anywhere, but somehow the GC is getting it's hands on it and is throwing a fit 13:13
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40736 - Ubuntu 9.04 amd64 (gcc) 13:17
Whiteknight yay! 13:20
mikehh Whiteknight - that has been bugging (;-}) me for a couple of days now - I just couldn't figgure why it was failing in testr (originally) 13:21
Whiteknight which core is testr?
13:21 quek joined
Whiteknight (I can never remember the names of those stupid make targets 13:22
13:22 masak joined
mikehh I've no idea - it compiles to pmc and the runs the .pmc file 13:22
13:22 kid51 joined
mikehh argh .pbc 13:23
Whiteknight okay 13:24
mikehh I think I will test with g++ to see if that's ok and then try rakudo again (it failed to build on r40729)
Whiteknight mikehh++ 13:25
so many cleanups to do...
mikehh and prtobably close TT #939 now
Whiteknight yeah 13:26
bacek: ping 13:30
dalek TT #939 closed by whiteknight++: t/dynpmc/foo.t FAILs testr with Segmentation fault
13:34 quek joined 13:46 braceta joined
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40736 - Ubuntu 9.04 amd64 (g++) 13:52
Whiteknight awesome 13:53
13:53 uniejo joined
mikehh rakudo fails to build on parrot r40736 (gcc or g++) - p6opaque.c:275: error: ‘PMC’ has no member named ‘pmc_ext’ 13:53
kid51 Whiteknight: At r40736, prove -v t/dynpmc/foo.t passes all tests 13:54
on darwin/ppc, that is.
... fixing last night's problem.
Whiteknight awesome
thanks kid51++ 13:55
kid51 starts smolder test
Whiteknight karma g?
purl g has karma of 547
mikehh from g++ i take it
Whiteknight yeah
moritz karma g++ 13:57
purl g++ has neutral karma
Whiteknight what's the Configure incantation to build with g++? 14:00
moritz purl, g++ configure? 14:01
purl moritz: bugger all, i dunno
Whiteknight purl configure g++?
purl i haven't a clue, whiteknight
Whiteknight you're worthless purl
mikehh how can you pick on a poor bot like that? 14:02
Whiteknight I think it was like perl Configure.pl --ccxx="g++" --cc="g++" --link="g++"
I'll show you how: Purl, you're retarded
mikehh I use perl Configure.pl --optimize --test --cc=g++ --cxx=g++ --link=g++ --ld=g++ --configure_trace
Whiteknight what does --configure-trace do? 14:03
moritz purl, g++ configure is perl Configure.pl --cc=g++ --cxx=g++ --link=g++ --ld=g++
kid51 Whiteknight: Ask the man who wrote it! 14:04
Whiteknight ...who wrote it?
kid51 Yo
mikehh got go to the store - bbl
Whiteknight kid51: what does --configure-trace do?
kid51 To oversimplify, it logs the growth of the Parrot::Configure object over the course of the configuration steps. 14:05
It's useful if you're trying to debug configuration problems, but plays no role once you've got your Makefile.
It records the state of the P::C object at each step and places that in a Storable file hidden in your topdir. 14:06
perldoc lib/Parrot/Configure/Trace.pm
Whiteknight ah, so probably nothing that I need to be thinking about 14:07
kid51 There's a post-configuration test (run with --test or --test=build) which tests whether that module is working properly.
Whiteknight ok
kid51 No, you don't.
It's very stable and only very obsessive testers like mikehh and kid51 and the release manager need worry about it. 14:08
But if someone were to propose new configuration steps, then it would be useful.
My Smolder test on Darwin/PPC was good: smolder.plusthree.com/app/public_pr...ails/26489 14:09
And on Linux: smolder.plusthree.com/app/public_pr...ails/26490 14:10
masak I'm getting this trying to build Rakudo HEAD: 14:22
p6opaque.c:275: error: 'struct PMC' has no member named 'pmc_ext'
Austin Interestingly, I find a partial failure at 40656. 14:23
kid51 Austin: There's been a big branch merge and some debugging since r40656. 14:24
We're at r40736.
Austin Kid51: Yeah. I'm bisecting looking for where a problem started to occur. 14:25
I just upgraded from 40290, and everything went to hell.
(Which, come to think of it, was pretty much the same thing that happened when I upgraded into 1.4 as well.. :( 14:26
moritz in theory, should rakudo need to change in any way after the auto_attrs merge? 14:27
14:27 Psyche^ joined
kid51 moritz: I don't see a branch called 'auto_attrs' 14:30
moritz Date: Tue Aug 18 17:24:24 2009 +0000 merge auto_attrs branch into trunk 14:31
oh, and there was another merge
Date: Sun Aug 23 01:18:17 2009 +0000 [pmc_sans_unionval] merge this branch into trunk. Resolves TT #549
maybe that's the offensive one
when trying to build Rakudo with latest parrot I get 14:32
p6opaque.c: In function ‘Parrot_P6opaque_clone’:
p6opaque.c:275: error: ‘PMC’ has no member named ‘pmc_ext’
14:32 AndyA joined
kid51 Whiteknight: Can you do an svn rm on the pmc_sans_unionval branch now? 14:37
s1n , is there an opcode that calls Parrot_setenv? 14:38
i see a reference in the changelog to new ops, but i don't see the op anywhere in ops (though i do see sleep, referenced on the same changelog entry) 14:46
masak ok, Rakudo builds on Parrot r40719. possible later revisions as well. 14:47
s/ble/bly/
14:47 quek left
Whiteknight kid51: i've got a few branches that can probably disappear now 14:47
I don't normally like to delete things immediately in case we need to rollback, but I think we're good at this point
bacek:ping 14:48
moritz: no, Rakudo should not have to change after auto_attrs 14:49
it was an internal-only change
s1n i see t/pmc/env.t uses Env, is that what i should be looking at? 14:50
dalek rrot: r40737 | whiteknight++ | branches/pmc_sans_unionval:
[pmc_sans_unionval] remove this branch, it's been merged into trunk and all failures that Ive seen have been sorted out by now
 14:51
14:54 Ron joined
dalek rrot: r40738 | whiteknight++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc] we don't need to parse the need_ext flag in PMCs anymore, after the auto_attrs branch. No harm in having it, but not necessary
 14:55
tracwiki: v6 | japhb++ | ModuleEcosystem 14:59
tracwiki: fix missing word
tracwiki: trac.parrot.org/parrot/wiki/Module...ction=diff
rrot: r40739 | whiteknight++ | trunk/src/pmc (48 files):
[pmc] we don't need need_ext anymore, so BALEETED
 15:05
15:06 confound joined 15:15 kjeldahl joined
dalek rrot: r40740 | whiteknight++ | trunk (8 files):
[pmc] remove more references to need_ext and PMC_EXT
 15:21
Whiteknight NotFound: ping 15:23
NotFound Whiteknight: pong
Whiteknight NotFound, the function free_pmc_in_pool in src/gc/mark_sweep.c. Shouldn't it always call VTABLE_destroy? 15:24
Also, shouldn't that free the attrs?
NotFound Whiteknight: supposedly it must check the active destroy flag, but now Default has a do-nothing destroy, so is safe to always call it. 15:25
Whiteknight ok 15:26
but shouldn't it still free the PMC_data?
NotFound The attrs must be freed after calling destroy,
But only if the attrs_size is not zero.
15:27 theory joined
Whiteknight right, but should it happen in that function? 15:28
it isn't currently
NotFound Don't know, I don't looked yet at the changes of the merge. 15:30
Whiteknight okay, I just want to make sure we aren't leaking memory here 15:32
dalek rrot: r40741 | whiteknight++ | trunk/src (5 files):
[pmc] remove more references to PMC_EXT, mostly comments
jonathan ...pmc_ext is gone? 15:35
Whiteknight dead and buried 15:38
murdered even
jonathan Whiteknight: "Rakudo should not have to change" - the build is broken. 15:39
Or so I'm told.
Whiteknight hmm, that's weird
actually, probably not. I know you do a lot of stuff in C 15:40
masak takes a note of jonathan's way to elicit a response from the Parrot devs
moritz p6opaque.pmc line 257
masak I said this 80 minutes ago. :) 15:41
Whiteknight sorry masak, I was AFK 80 minutes ago
masak ok. np.
Whiteknight I can patch it up probably, but I don't have commit access 15:42
(don't want it either, I don;t know git and would break things)
jonathan Whiteknight: That'd be awesome; if you just nopaste me a diff I'll apply it. 15:43
moritz applying patches is easily done.
jonathan Or moritz or masak or whoever.
Whiteknight okay, awesome
jonathan There's a bunch of us who can.
moritz just removed that and the next line and is spectesting now
mikehh reported it a couple of hours ago
jonathan I know pmichaud++ wants to do PGE stuff and that means Rakudo is going to need to track Parrot trunk even more closely than usual. 15:44
mikehh it started failing at around r40729 with that error
jonathan So build breakages are going to be quite painful. 15:45
mikehh that was here of course, not in #perl6
15:45 mokurai joined
Whiteknight This is just a bad month for it because so many big changes and branches are landing 15:47
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40740 - Ubuntu 9.04 amd64 (gcc)
jonathan Whiteknight: Yeah, it's unfortunate timing.
Whiteknight okay, I have the patch. How do I take a diff in git? 15:48
jonathan git diff
purl git diff is 1700 lines
Whiteknight nopaste?
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
nopaste "Whiteknight" at 69.249.176.251 pasted "fix for pmc_ext breakage for jonathan++" (14 lines) at nopaste.snit.ch/17649 15:49
Whiteknight PMC_EXT doesn't exist anymore, all it's fields are in PMC now 15:50
jonathan Whiteknight: Did anyone yet check if that gets us some memory / performance win, out of curiosity? 15:51
mikehh moritz mentioned that he was testing a fix
Whiteknight jonathan: definite memory win, should be a performance win but we have lots of benchmarks that we need 15:52
jonathan Whiteknight: Aye. I'm just thinking that we need to allocate one less thing now. :-)
Rakudo uses properties a decent bit, so removing an indirection for getting at those will surely be a win, even if a small one. 15:53
Whiteknight it gets rid of an entire GCable item pool, decreases the amount of memory allocated per PMC, reduces the need to make two allocations per PMC (PMC and PMC_EXT), removes a number of "if(pmc->pmc_ext)" checks, etc
so it's a definite win, I just don't know how much
jonathan Right, makes sense.
I don't see any immediate downsides.
Whiteknight combine that with some of the other work lately (fixes to Sub PMC attributes, the auto_attrs work, etc) and 1.6.0 is going to be notably faster then 1.5.0 was 15:54
a signficant decrease in the number of malloc calls, if nothing else
15:56 kjeldahl joined
dalek rdinal: c6d9334 | (Danius Michaelides)++ | (3 files):
Array#nitems() has been removed from 1.9.
 15:57
rdinal: a2b5f4d | (Danius Michaelides)++ | (3 files):
Implement Array#count() - new to ruby 1.9.
rdinal: f33b494 | (Danius Michaelides)++ | (3 files):
Implement Array#select.
15:59 Ron_ joined
Whiteknight I love watching commits come rolling in 16:00
moritz jonathan, Whiteknight: testing Whiteknight's patch now
16:00 uniejo joined
Whiteknight thanks! moritz++ 16:00
jonathan Whiteknight: ah, thanks for beating me to it. :-)
erm
gah
moritz: See what I just mis-fired at Whiteknight :-) 16:01
moritz jonathan: ;-)
jonathan brb
Whiteknight I'm spectesting too, but that will take forever
moritz having a new Test::Harness and multiple cores helps 16:02
mikehh yeah - it used to take an hour on my old system 16:06
16:10 rblasch__ joined 16:21 kid51 joined
jonathan back 16:27
moritz: How's the spectests looking with the patch?
moritz jonathan: just finished as I saw your hilight here 16:28
so I'm pushing now.
jonathan moritz++, Whiteknight++ # thanks!
dalek kudo: e2b5e8f | moritz++ | (2 files):
re-enable building on latest parrot. Also bump PARROT_REVISION
 16:31
kid51 r 40736 passed make fulltest on Linux i386 16:37
dalek rrot: r40742 | whiteknight++ | trunk/src/gc/mark_sweep.c:
[gc] a small fix to the fixed-size allocator that *likely* is the source of errors on Win32 using this tool. Hasn't fixed the issue with Complex.t, however
 16:40
MoC Hm. Now, I don't know wether Rakudo or Parrot is responsible for this, but Rakudo has problems during compilation because backslashes are removed from the directory path (on Win32): 16:41
C:\\GnuTools\\MSYS\\home\\MoC\\Parrot\\bin\\pbc_to_exe.exe perl6.pbc
Can't read 'C:GnuToolsMSYShomeMoCParrot/lib/parrot/1.5.0-devel/include/config.fpmc' : No such process
moritz MoC: what does `parrot_config prefix` return? 16:42
MoC C:\\GnuTools\\MSYS\\home\\MoC\\Parrot 16:43
moritz then it could very well be a Rakudo problem 16:44
MoC parrot_config actually isn't consistent with the usage of \\ and / in the path values, some contain \\ some /, some a mixture of both.
moritz MoC: could you please nopaste the generated Makefile?
MoC Ok
jonathan fwiw, currently doing a build on Win32 of latest 16:46
MoC Look at #perl6 for the makefile link.
moritz seen it, thanks 16:47
there seem to be some inconsitencies about what is double backslashed and what not
under CLEANUP it's all double backslashed
most other things are not 16:48
jonathan Builds for me; MS VC++ / WinXP. 16:53
MoC >_>
moritz great.
MoC I'll try make realclean...
jonathan MoC: Ah, I guess you're using a different compiler and toolchain. 16:54
moritz it looks like cygwin
MoC Yes, MinGW4.4
jonathan MoC: So it's possible there's a bug somewhere that affects that.
moritz oh
MoC: if your problem persists, please file a bug report
MoC However I don't use sh to compile it, it's just that I also cloned into my MSYS home folder 16:55
jonathan MoC: The output of parrot_config --dump could be interesting to see in your bug report too.
MoC And I should file this as rakudo bug? Because it's pbc_to_exe which emits the error... (I don't know if it resolved that path itself or it was hardcoded within the pbc) 16:56
moritz MoC: yes, rakudobug 16:57
purl hmmm... rakudobug is mailto:rakudobug@perl.org
16:57 joeri joined
MoC Can I attach files to that mail? Or does it have to be inline? 16:58
Ok, has to wait until later, anyway, lunchtime now.
moritz MoC: attachments are fine 16:59
17:03 chromatic joined
dalek kudo: e781e94 | mberends++ | tools/test_summary.pl:
tools/test_summary.pl: remove the almost redundant 'test' report column
 17:17
kudo: c4c67da | mberends++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
 17:18
Whiteknight NotFound: ping 17:19
NotFound Whiteknight: pong
Whiteknight NotFound: I think r40742 should fix the fixed-size allocator in Windows (TT #940). Could you give it a test? 17:20
Whiteknight has to go away now and can't test it quite yet 17:21
NotFound Whiteknight: too hot now to power on one more laptop ATM, I'll try later
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40742 - Ubuntu 9.04 amd64 (g++) 17:22
MoC moritz: rakudobug submitted. 17:25
mikehh rakudo (c4c67da) builds on parrot r40742 - make test / make spectest (up to 28050) PASS - Ubuntu 9.04 amd64 (g++) 17:38
bbl
17:40 dalek joined 17:57 davidfetter joined 19:17 Ron joined 19:59 chromatic joined
chromatic Hm, the Rakudo benchmark is 4.98% slower with Parrot trunk than before the unionval branch landed. 20:19
If I re-enable the fixed-size allocator, it's 3.08% slower. 20:20
jonathan chromatic: "the Rakudo benchmark"? 20:21
chromatic Hello, world! in Perl 6.
jonathan chromatic: Ah, OK.
chromatic: So mostly a measure of our startup time.
chromatic Yes. 20:22
jonathan Our startup time is loooong.
A lot of it is because of our signature building stuff.
chromatic I can fix some of that with pmichaud's isa-STRING-PMCProxy patch.
20:23 nillo joined
jonathan Well, what also should happen is that signature construction should get vastly cheaper. 20:23
I'm planning to completely re-do signatures in the space of the next 2-2.5 months.
20:23 kid51 joined
jonathan Performance improvements will be one of the things I design for. 20:24
All of that said, signature construction ATM is really not much different from object construction elsewhere in Rakudo.
So any wins made to that are overall wins still.
chromatic If you can give me a short PIR benchmark, I'll do what I can. 20:25
jonathan chromatic: tbh, I'm more inclined to hold out and see what the profiler ays. 20:26
*says
Why I guess we maybe cheat a little on signatures, object construction overall is a fairly complex process. 20:27
chromatic Fair enough.
jonathan So I'd rather know where we're slow in that area from data rather than guess. :-)
Whiteknight chromatic: you think the unionval actually caused a slowdown?
"unionval stuff"* 20:28
chromatic Something did.
Whiteknight the fixed-size allocator has a bug that I'm trying to track down
the lazy allocator has a bug too that I'm also looking at 20:29
actually, i don't think it has a bug anymore :) 20:31
moritz it'll be the first bug-free piece of software in human history ;-) 20:33
dalek rrot: r40743 | whiteknight++ | trunk/src/gc (3 files):
[gc] enable the lazy allocator. Fix one bug in the lazy allocator where a new arena can potentially be allocated before the last arena has been completely allocated. Also, some cleanups for the fixed-size allocator (though that still is disabled by default)
 20:35
Whiteknight not bug-free, but that last bug is gone
jonathan Whiteknight: Did that have a fail on Windows?
(fixed-size al..)
Whiteknight ah yes, it did
I think I fixed that issue but I haven't tested it satisfactorily yet
jonathan Whiteknight: I'm on Windows.
Whiteknight (i knew I was supposed to wait for something) 20:36
jonathan Whiteknight: MS VC++ / WinXP is that's an interesting combination.
Whiteknight I'm about to load up my win32 machine too
jonathan s/if/is/
oh arse
s/if/is/
:-)
Anyway, if you want me to run a build, just let me know what to do to enable it and I can give it a try. 20:37
Whiteknight jonathan: it's enabled in r40743, so just svn up && make 20:38
20:38 Aisling joined
jonathan realcleans to be safe 20:39
Whiteknight jonathan: no, it's a different problem. I'm getting confused 20:46
MoC Fresh win23 smoke report at: smolder.plusthree.com/app/public_pr...ails/26503 20:47
s/Fresh/Recent/
Whiteknight the problem on Win32 is the fixed-size allocator not working (which is disabled globally). The thing I just fixed is the lazy-allocator mode
jonathan Whiteknight: Ah, OK. 20:48
20:55 cotto joined 20:57 braceta joined
Whiteknight these stupid fixed-size errors are killing me 20:58
21:02 joeri left, skv_ joined 21:29 theory joined 21:31 rhr_ joined 22:18 hachi joined 22:27 braceta left 22:40 rg1 joined
mikehh chromatic: ping 22:42
Whiteknight: ping 22:43
chromatic pong
Whiteknight pong
mikehh chromatic: I am getting a codetest failure in src/gc/gc_ms.c (space before parens) which I am not sure how to fix 22:45
if ((!pool->free_list || pool->num_free_objects < pool->replenish_level)
#if GC_USE_LAZY_ALLOCATOR
&& !pool->newfree
#endif
)
as in last line - any ideas on that? 22:46
without repeating the statement
what would be the policy on a statement like that? 22:47
Whiteknight that's my edit, I'll fix it 22:49
chromatic You could move that check into its own conditional in the block. 22:50
Whiteknight yeah 22:51
dalek rrot: r40744 | whiteknight++ | trunk/src/gc/gc_ms.c:
[gc] fix codestd failure, and other small things
 22:52
22:53 cotto joined 23:06 bacek joined 23:23 mokurai joined 23:24 patspam joined
Coke Whiteknight: question - is need_ext still valid syntax for a PMC that just does nothing? 23:27
23:27 mokurai left
Whiteknight it is still valid that I am aware of, just does nothing 23:27
NotFound There are no error for invalid flags, they just get ignored. 23:28
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40744 - Ubuntu 9.04 amd64 (gcc) 23:33
23:35 mokurai joined
mikehh rakudo (c4c67da) builds on parrot r40744 - make test / make spectest (up to 28054) PASS - Ubuntu 9.04 amd64 (gcc) 23:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!