HTTPS CERT EXPIRED | www.parrot.org | Add test after fixing bugs after context_pmc3 merge | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON
Set by moderator on 3 September 2009.
00:00 MoC joined
NotFound dukeleto: remember: never trust my looks at perl code X-) 00:00
dukeleto NotFound: now you tell me. i don't know how that broke the linux build. it does a check for $^O being darwin 00:01
NotFound dukeleto: unclosed paren
Mmmmm.... but the nopaste had it 00:02
dukeleto NotFound: my bad. git svn lost my commit because I had it pointed at the wrong branch somehow and i did a git reset . so I typed it again. should have used reflog 00:03
or tested it again. !facepalm 00:07
patch is in the tubes
NotFound You can say that it was a test for ttbot ;)
dalek rrot: r41022 | dukeleto++ | trunk/config/inter/libparrot.pm:
[cage] Unbreak the build
dukeleto NotFound: yeah, that's it!
NotFound dukeleto++
dukeleto ttbot++
jhelwig: i have a git branch in my old git-svn copy of parrot that I want to apply to my new copy. halp? git format patch something? 00:08
bacek dukeleto: cherry-pick? Or it's different repos? 00:09
NotFound bacek: do you have a patch for the parrot_debugger test? 00:10
nopaste "bacek" at 114.73.158.5 pasted "Next commit waiting in my queue for NotFound" (132 lines) at nopaste.snit.ch/17839 00:11
bacek I'm just do final test on Rakudo before dcommit 00:12
NotFound bacek: don't worry, I'm not going to steal your karma ;) 00:13
bacek Sic. Rakudo failing in S03-operators/arith.rakudo with "floating point exception"...
dukeleto bacek: different git svn repo's
bacek dukeleto: than probably format-patch. Or just git show rev|patch -p1
jhelwig dukeleto: format-patch would probably be the easiest.
NotFound bacek++ looks good 00:14
dukeleto jhelwig: git format-patch svn/trunk ?
jhelwig svn/trunk..
dalek TT #979 closed by dukeleto++: Invalid charset number '8' on darwin during PCT.pbc bytecode generation 00:15
Whiteknight this merge is MESSY
bacek Whiteknight: kill_cont? 00:16
Whiteknight bacek: yeah
GeJ Good morning everyone 00:18
bacek Whiteknight: I'd expected it. Maybe storing patch between branch and trunk-before-merge, than creating new branch, apply patch and fix it will be easier
Bah! Rakudo failing on trunk in same way. 00:19
Whiteknight bacek: that's my plan B. I just committed the merge from trunk. Has an error that I suspect will be easy to sort out
jrtayloriv: ping
bacek Whiteknight: Hey! He have commit bit and can fix it by himself :) 00:20
Whiteknight r41024
he has the bit now?
jrtayloriv pong
bacek For few hours already :)
Whiteknight jrtayloriv: I updated your branch from trunk in r41024 00:21
bacek Which is same as "for ages" nowdays
Whiteknight segfaults building PGE, so we need to sort that out before merge to trunk
please take a look at it and see if you can spot anything obvious. So many things have changed!
dalek rrot: r41023 | bacek++ | trunk/src (3 files):
[cage] Put asserts into accessing non-existing registers.

   * Initialise Context.pred_offset
   * Fix saving/restoring registers in parrot_fetch_args to preserve n_regs_used
   * Fix parrot_debugger to not set said registers.		 00:22
bacek look innocent around
Whiteknight dalek is broken 00:23
jrtayloriv Whiteknight, Thanks -- I'll take a look at it in a few minutes. Let me finish this up real quick.
Whiteknight bacek: #596. Can be closed now?
NotFound Hey, a rookie with his own branch! We don't have a policy against that? ;)
rrot: r41024 | whiteknight++ | failed to fetch changeset:
[kill_parrot_cont] merge -r40900:41020. Dumps core while builing PGE
rrot: r41025 | bacek++ | trunk (4 files):
[cage] Use UINTVAL for n_used_regs.
bacek Whiteknight: ah, yes
Whiteknight you deserve the karma for that! 00:24
bacek :)
Whiteknight NotFound: The policy is that the rookies need to do all the work :) 00:25
bacek will trade karma for beer
davidfetter has ~6 gallons of barley wine on hand
when will you be in oakland next? :)
bacek davidfetter: it probably will be "first" :) 00:26
davidfetter heh
Whiteknight 6 gallons? Why do you need that much?
dalek TT #596 closed by bacek++: garbage collectable contexts
davidfetter that's how much i make in a batch
<-- homebrewer
bacek I'm going to visit my sister in US next winter.
davidfetter whose winter?
bacek Erm. In June.
NotFound Can't you use the SI and forget the Empire?
davidfetter call it ~28l 00:27
but if you drink 2l, you may need to sit down and stay there awhile ;)
NotFound No problem, I have a comfortable chair 00:28
bacek Gentleman can't be called drunk while he can stay holding table leg firmly :) 00:29
mikehh hey NotFound they use different Gallons there in the US - NOT Imperial :-}
but how can you forget the Empire what
Whiteknight hah, fixed it 00:30
NotFound Next time I'll use femto squared-parsecs
davidfetter bacek, heh
NotFound I mean, cubic
mikehh mind you they still use feet and inches and such
jrtayloriv Whiteknight, kill_parrot_cont, you mean?
bacek anyway, shopping time.
see you!
NotFound I also use feet, but for wearing shoes 00:31
Whiteknight jrtayloriv: yes, what did I say?
jrtayloriv Whiteknight, "it"
mikehh yeah - me too - when I wear them that is
Whiteknight oh, sorry. I didn't realize that mr bigshot had multiple branches already :)
congrats on the bit, by the way 00:32
jrtayloriv :) -- thanks
Whiteknight okay, coretest in kill_parrot_cont passes for me. Doing a fulltest now and then merging to trunk if everything is awesome 00:33
NotFound plays Supertramp 'Give a little bit'
dalek rrot: r41026 | whiteknight++ | branches/kill_parrot_cont/src/pmc/continuation.pmc:
[kill_parrot_cont] fix that segfault, Continuation was marked auto_attrs but was still trying to free it's own attrs.
Whiteknight fulltest is going to take about 12min, so I get to spend some time searching for funny pictures on the internet 00:34
best way to spend a saturday night
mikehh It is 1h35 minutes into Sunday for me 00:35
NotFound Night is long
dalek rrot: r41027 | jrtayloriv++ | branches/gc-refactor (8 files):
Moved Arena function pointers into GC_Subsystem struct, and tidied up a bit in various places
 00:37
Whiteknight jrtayloriv: you're merging that next branch, so if it's messy, you're going to be stuck with it!
NotFound BTW 12:01 AM is one minute past M, isn't it?
jrtayloriv Whiteknight, deal :) -- thanks for doing kill_parrot_cont for me. 00:38
mikehh NotFound: Yes
NotFound I'll never understand that logic %-)
mikehh but then I tend to use a 24 hopur clock which would be 00:01 00:39
Whiteknight NotFound: I agree. Clocks were developed by people who weren't programmers. That's for sure 00:40
NotFound I use an analog clock stopped: it gives the hour with full precision two times a day.
mikehh NotFound: it is not logical - just tradition
dalek rrot: r41028 | whiteknight++ | branches/kill_parrot_cont/src (2 files):
[kill_parrot_cont] Fix last issues, including small codestd fix. All tests in fulltest pass
 00:43
mikehh When I went to school, we had to learn all sorts of weird things - it was in the era before currency decimalization here, they had Pounds, Shillings and Pence - 12 pence to the shilling and twenty shillings to the pound or even 21 to the guinea - I am not even sure how to spell that 00:45
NotFound I think I have a program for that in the Sinclair ZX-81 manual 00:48
mikehh have a look at www.victorianweb.org/economics/currency.html 00:49
NotFound At least you haven't to learn that Franco was the saviour of the occidental civilization 00:51
Whiteknight I can't merge. SVN is giving me grief 00:52
svn: REPORT of '/parrot/!svn/vcc/default': Could not read chunk size: Secure connection truncated (svn.parrot.org)
any ideas about what is broken?
NotFound mikehh: amazing 00:54
mikehh Yeah - but we had our own efforts, The British Empire and such, it was only after I left school that I learned any other European or World History - Oh we had some Roman and Greek stuff, but nothing modern
NotFound At least Robin Hood history is sexier than El Cid Campeador one ;) 00:55
mikehh depends on your orientation I suppose :-} 00:56
NotFound History, I said, not the male protagonists X-)
mikehh I am not even sure that Robin Hood even existed - They had a Sherrif of Nottiongham though 00:57
Nottingham
purl Nottingham is probably near as dammit London
mikehh Not if you have to get there 00:58
Whiteknight WHY IS MY SVN RETARDED?!?!?!
NotFound Nothing AM ?
Whiteknight: I had some problems like that because svn got confused with HTTP no-change response, due to my misunderstands on how to use the merge command 01:00
Whiteknight I'm using merge the same way I always do, I've never seen this before 01:01
NotFound I wasn't used merge the same way because I haven't used before
Whiteknight This is the command I am trying: 01:02
svn merge -r40900:HEAD svn.parrot.org/parrot/branches/kill_parrot_cont
and that's borking 01:03
mikehh are you trying to merge trunk with a branch or a branch into trunk?
Whiteknight branch into trunk
mikehh ok
Whiteknight specifically, kill_parrot_cont branch into trunk
I'll just do it the hardware if merge won't cooperate 01:05
kid51 reads scrollback
mikehh what does it complain about? 01:06
Whiteknight that's the exact error message above
svn: REPORT of '/parrot/!svn/vcc/default': Could not read chunk size: Secure connection truncated (svn.parrot.org) 01:07
NotFound Whiteknight: I'm trying that command, still not broke 01:08
Whiteknight yeah, rub it in
mikehh it seems like a connection error to me 01:09
NotFound After a while, same error 01:11
Whiteknight NotFound: you too? Good. That means I'm not just being crazy
NotFound Maybe we are both crazy
mikehh I just got a connection time-out from www.parrot.org - it reloaded ok though 01:14
Whiteknight so the server is borking? 01:15
kid51 reads scrollback 01:16
Whiteknight: would you like me to try that merge?
mikehh I am definately not getting a good response from the server 01:17
Whiteknight kid51
: sure, I don't care how it gets done at this point
I think all the hard work should be done 01:18
kid51 We're talking about kill_parrot_cont branch -- correct?
Whiteknight kid51: yes
svn merge -r40900:HEAD svn.parrot.org/parrot/branches/kill_parrot_cont 01:19
kid51 confirms problems: svn: Could not get content-type from response
... when trying to merge into a fresh sandbox of trunk
Whiteknight No!!! IM IN UR INTERNETZ, SLOWIN UR DEVELOPMENTZ
kid51 conducts net search 01:20
I wonder if this could be related to the https cert problem. Was this branch created prior to the expiration date? 01:23
kid51 thinks yes
first hits from internet search are not very helpful 01:25
Whiteknight yes, it was
but I just merged into the branch from trunk no problem
mikehh probably safer that way anyway 01:26
01:33 jrtayloriv joined
kid51 Attempt 2: Tried it on my ibook, where I have only been 't' temporarily accepting the cert status 01:33
got this response: svn: Server sent unexpected return value (304 Not Modified) in response to GET request for '/parrot/!svn/ver/41024/branches/kill_parrot_cont/src/hll.c'
svn: Error reading spooled REPORT request response
Could someone look at src/hll.c in the branch? 01:34
Whiteknight what about it? 01:35
NotFound The "Not modified" is the thing that happened to me I mentioned before
Whiteknight Coke: ping 01:36
particle: ping
anybody
NotFound Silly idea: insert an empty line on that file on the branch and commit it.
mikehh looks ok to me
what am I looking for 01:37
01:37 Andy joined
mikehh properties ok 01:38
Whiteknight well, all I wanted to do was merge, can't do it, so going to bed. 01:45
will try again in the morning, if nobody beats me to it
Tene 'night 01:46
mikehh the only difference I find with trunk is the header line
Whiteknight goodnight
kid51 And when I repeat the svn merge in my iBook, I get a 'C' in src/hll.c, then I get one file farther each time I repeat the process, then I get the failure message posted above at :34 01:47
01:48 rhr joined
jrtayloriv hopes he didn't do something stupid to break it ... 01:51
kid51 Let me try to create a branch, make an inconsequential change, and merge. 01:52
mikehh branch -> $Id: hll.c 41024 2009-09-06 00:20:10Z whiteknight $ 01:53
trunk -> $Id: hll.c 40958 2009-09-03 11:56:50Z bacek $
dalek rrot: r41029 | jkeenan++ | branches/minimal:
Creating branch to diagnose merge problem.
rrot: r41030 | jkeenan++ | branches/minimal/src/hll.c:
Add 1 line of whitespace.
 01:57
rrot: r41031 | jkeenan++ | trunk/src/hll.c:
Merge minimal branch into trunk. (Attempting to diagnose merge problem, but this is not reproducing the problem.)
 02:00
kid51 Well, 'svn merge' per se is not the problem. I was able to create a branch, do a modification therein, then merge the branch into (sandbox of ) trunk and commit from trunk.
Note: I am getting 'Could not get content-type from response' as error message to *this* command as well: svn diff svn.parrot.org/parrot/trunk@40900 svn.parrot.org/parrot/branches/kil..._cont@HEAD 02:03
Am retrying that 'svn diff' ... and am getting *enormous* output. 02:09
jrtayloriv kid51, what does 'svn diff | wc -l' say? 02:10
kid51 It will take me several minutes to run that :-) 02:11
jrtayloriv oh my :)
kid51 I just got a completed svn merge -- but with many conflicts!
Wait, that merge hasn't actually completed 02:12
jrtayloriv kid51, there should be a bunch of conflicts -- continuations are very tied up w/ contexts, and this was created before context_pmc3 merged into trunk
nopaste "kid51" at 71.247.40.83 pasted "svn merge output for kill_parrot_cont branch into trunk" (192 lines) at nopaste.snit.ch/17840 02:14
kid51 21 conflicts 02:15
02:17 Andy joined
mikehh you didn'#t get a conflict with src/hll.c this time 02:19
I really need sleep - bbl 02:22
kid51 I think the size of the diff is causing problems for the server. 02:23
There was a short window there when I was able to get a complete svn diff and a complete merge -- and both were enormous.
But now I'm getting the 'content-type from response' error again.
This is consistent with some of the things I gleaned from net search: happens on big commits; is intermittent 02:24
jrtayloriv kid51, can you try to do two or three files at a time then? 02:27
kid51 do *what* with 2 or 3 at a time?
02:27 rhr joined
jrtayloriv kid51, I thought you were saying that the problem might be trying to merge the entire thing at once, because it was too large. So, maybe merging them incrementally would work, since each commit wouldn't be as large. 02:28
kid51 Well, as the paste suggests, even if I were able to do that, we'd have the problem of the 21 files with conflicts 02:29
I'm not the person to resolve those conflicts.
When I was lucky enough to get that 'svn diff' to complete, I didn't think to redirect the output to a file. 02:30
If we can get the svn diff to a file, we have something for the branch authors to work with.
jrtayloriv kid51, OK -- I see.
kid51 So we have interlocking problems. 02:31
There *may* be server problems right now.
If so, they *may* be contributing the problems we are observing -- problems likely to be exacerbated by the size of the diff.
Now, it appears that in the course of this branch's development, there were many merges into branch from trunk. 02:32
kid51 heard a talk at $job yesterday saying that svk's smerge command handled this well ... 02:33
... but in general I have not had good results trying to refresh a branch with more recent changes from trunk.
02:35 janus joined
jrtayloriv kid51, I've never used SVN prior to working with Parrot. I'll do some reading tonight and see if I can figure out how to resolve the conflicts and do the merge myself in the morning. Thanks for your help with this. 02:37
nopaste "kid51" at 71.247.40.83 pasted "svn diff between trunk and branch for just one file" (631 lines) at nopaste.snit.ch/17841 02:38
kid51 631 line diff for just one file!
Even if our server and Subversion were able to handle this flawlessly, that has code smell for me. 02:39
(I was able to get that svn diff from what was still visible in my Terminal.)
... and that file had no conflicts! 02:40
It's getting late for me here and I'm making no more progress.
jrtayloriv That file looks like bacek's context_pmc work. 02:41
kid51 If someone would like to try the following command periodically and see if we succeed ...
svn diff svn.parrot.org/parrot/trunk@40900 svn.parrot.org/parrot/branches/kil..._cont@HEAD > some/file/for/pasting.txt
... then paste so that Whiteknight et al can at least look at the 'C' files tomorrow. 02:42
... that would be appreciated.
dalek rrot: r41032 | jkeenan++ | branches/minimal:
Branch no longer needed for diagnosing SVN problems.
 02:47
kid51 tries clutching at one last straw ... 02:48
dalek rrot: r41033 | jkeenan++ | branches/xkill_parrot_cont:
duping branch in attempt to diagnose merge problems.
 02:50
Tene kid51: allison's approach whenever she has a large or old branch is just to take the full diff of the branch, from where it was originally branched, and then re-apply it to a clean branch from the current trunk. 02:55
nopaste "kid51" at 70.85.31.226 pasted "svn diff between trunk and xkill_parrot_cont branch (where xkill_parrot_cont is dupe of kill_parrot_cont)." (16269 lines) at nopaste.snit.ch/17842 02:56
kid51 Tene: I understand that -- but we've had problems getting a clean diff to start with. 02:57
Tene orly?
purl YA RLY.
Tene I can get that for you.
if that would be helpful.
kid51 So, I just created a branch called 'xkill_parrot_cont' which was a dupe of 'kill_parrot_cont'
and I'm having good results with 'svn diff' and 'svn merge' for this branch. 02:58
(I think)
So paste 17842 should be a valid svn diff -- but we still have the problem of 21 files in conflict
Tene OK. Let me know if you need me to ask git for a diff.
kid51 Tene: Read last couple of hours of scrollback to see what we've attempted. Meanwhile ... 02:59
kid51 must sleep
purl $kid51->sleep(8 * 3600);
Tene 'night
jrtayloriv The changes I made to get rid of Parrot_cont were pretty small. Think it would be better if I were to just redo it, rather than trying to merge it into trunk, since there are so many things conflicting as a result of the context_pmc3 merge? 03:08
cotto I've got a patch that I'm testing right now. We'll see how make test fares. 03:09
If it works I'll nopaste it here for review and you can commit it if it looks good. (I'm leaving for a couple hours soon.) 03:10
I'm suspicious because there weren't any conflicts, but we'll see. 03:11
somehow, all tests pass
jrtayloriv cotto, there should have been a bunch of conflicts, I think.
nopaste "cotto" at 74.61.2.46 pasted "possible kill_parrot_cont patch for jrtayloriv++" (1292 lines) at nopaste.snit.ch/17843
cotto I know. That's why I'm suspicious.
jrtayloriv My changes are in there, as far as I can tell, but I don't know about bacek's -- I wasn't following what he did w/ context PMCs. 03:13
cotto should be easy to verify 03:14
just look for a few of his diffs
jrtayloriv cotto, ok -- will do. Thanks for taking the time to make the patch.
cotto afaict I just did what other people already tried, but here we are 03:15
bbs 03:16
jrtayloriv msg bacek We are trying to merge kill_parrot_cont into trunk, and cotto++ seems to have a patch that will merge the changes successfully. But we are suspicious, because there are not *any* conflicts. Could you take a look at nopaste.snit.ch/17843 and see if it looks like any of your work is missing? I'm going to go look at your diffs and see if I find any problems ... 03:19
purl Message for bacek stored.
03:26 bacek joined
jrtayloriv bacek, just it time :) 03:28
bacek who called my name? I didn't broke it! I swear!
jrtayloriv :-) -- nope -- I brokes it I think. Trying to merge the kill_parrot_cont branch into trunk, and were having trouble. 03:29
bacek lemmecheck 03:30
jrtayloriv cotto++ has that patch that I msg'ed you with, that he says is passing all tests, but there are no conflicts, which is really odd (it seems like at least *some* of the Context and Continuation stuff should have conflicted) ... 03:31
bacek Last commit "rerun headerizer" (in branch)?
jrtayloriv I haven't committed anything to that branch.
bacek ouch... I've got a lot of conflicts during merge branch to mast^W trunk. 03:32
And other way around. 03:33
purl other way around is probably not better
bacek Someone have to merge trunk into branch ad fix conflicts.
bacek looking for Whiteknight
jrtayloriv bacek, right -- that's what I thought -- seems like there should be conflicts. cotto said he didn't get any for whatever reason.
whiteknight's gone to sleep :) 03:34
bacek bacek@icering:~/src/parrot$ git status|grep -c unmerged
13
jrtayloriv: should PMC_cont continue to work? 03:36
jrtayloriv bacek, yes if I recall correctly -- I think I left it there, and made PMC_Cont(foo) just do the same as PARROT_CONTINUATION(foo) ... let me check. 03:38
bacek jrtayloriv: yes, correct.
I'm going to resolve conflicts leaving PMC_cont in place.
jrtayloriv bacek, yes -- I just checked. PMC_cont does as I said above. 03:42
bacek Ok, I'm committing in branch merged version. 03:48
(And I didn't even build it yet.)
Ouch... I forgot to run git svn rebase before merging. 03:50
Have to remerge again... 03:54
jrtayloriv: please recheck branch in few minutes (svn is slooow) 04:06
jrtayloriv will do. thanks. 04:07
r41034? 04:08
bacek yes
dalek rrot: r41034 | bacek++ | branches/kill_parrot_cont (15 files):
Merge trunk into branch.

  \tinclude/parrot/context.h
  \tinclude/parrot/register.h
  \tinclude/parrot/sub.h
  \tlib/Parrot/Pmc2c/PCCMETHOD.pm
  \tsrc/call/pcc.c
  \tsrc/debug.c
  \tsrc/gc/alloc_register.c
  \tsrc/ops/core.ops
  \tsrc/ops/pic.ops
  \tsrc/pic.c
  \tsrc/pmc/context.pmc
  \tsrc/pmc/continuation.pmc
  \tsrc/pmc/coroutine.pmc
  \tsrc/pmc/exception.pmc
  \tsrc/pmc/exceptionhandler.pmc
  \tsrc/pmc/retcontinuation.pmc
  \tsrc/sub.c
jrtayloriv bacek, failing at exception.pmc with "Badly balanced PMC source" 04:09
bacek Looks like I broke exception.pmc
fixed 04:11
jrtayloriv btw, are you interested in helping me w/ gc-refactor? I could really use some mentoring on the design.
dalek rrot: r41035 | bacek++ | branches/kill_parrot_cont/src/pmc/exception.pmc:
Unbroke exception.pmc
bacek jrtayloriv: (gc) yes, with pleasure 04:12
jrtayloriv bacek, Great :) I'd like to try to implement the get_raw_chunk() functions that your were talking about in the IRC conversation you pointed me to earlier. That seems like "low hanging fruit" that I might be able to do. 04:14
bacek jrtayloriv: Bad idea :)
jrtayloriv Seriously? Not as easy as it sounds?
bacek jrtayloriv: first step - expose current Small_Object_Pool functions via GC_subsystem
Just to decouple parrot from gc 04:15
jrtayloriv bacek, yes -- I've already gotten the functions out of Arenas structure, and was going to do the same for Small_Object_Pool next. 04:16
bacek++, btw -- branch just built successfully, running make test now 04:17
bacek let me check Arenas, I'm not sure what exposed in this objects
it passed test on my box too.
Which platform are you using?
jrtayloriv Linux x86-64 -- all tests passed. Nice :) 04:18
bacek ok. I'm on Linux/i386
We just need someone on different platform before merge 04:19
04:23 bacek_ joined
bacek_ Bah! 04:24
bacek_ blame internet connectivity
jrtayloriv: make fulltest failing... 04:28
jrtayloriv bacek, I'm running make fulltest now. One moment. 04:31
bacek jrtayloriv: jit... 04:34
jrtayloriv bacek, hmmm ... I've got all tests passing on mine ... let me try make realclean and do it again. 04:35
bacek jrtayloriv: jit isn't supported on amd64.
04:36 msmatsko joined
bacek jrtayloriv: Bah. Looks like I broke it. In trunk. Let me check 04:38
yes... It was me... 04:39
jrtayloriv bacek, I'm not trying to enable jit.
bacek jrtayloriv: because you can't enable it on x86_64... 04:43
jrtayloriv right
dalek rrot: r41036 | bacek++ | trunk/src/gc/alloc_register.c:
Temporary comment-out strict asserts on accessing registers in Context.

Commenting out just to merge kill_parrot_cont branch with clean "make fulltest" pass		 04:46
jrtayloriv bacek++ 04:47
bacek jrtayloriv: let me retest branch with this commit... 04:48
dukeleto cool, parrot builds on the OLPC: smolder.plusthree.com/app/public_pr...ails/26896 04:50
bacek wish OS/2 back... 04:51
dalek rrot: r41037 | bacek++ | branches/kill_parrot_cont/src/gc/alloc_register.c:
Temporary comment-out strict asserts on accessing registers in Context.

Commenting out just to merge kill_parrot_cont branch with clean "make fulltest" pass		 04:56
purl i already had it that way, dalek.
rrot: r41038 | bacek++ | branches/kill_parrot_cont/include/parrot/sub.h:
Rerun headerizer
bacek jrtayloriv: make testj passed.
jrtayloriv bacek, nice :)
bacek jrtayloriv: one comment - keep ATTRibutes indented. For example as in sub.pmc
jrtayloriv bacek, did I leave some ATTRs unindented somewhere? 04:58
bacek continuation.pmc :)
jrtayloriv hmm -- sorry about that. 04:59
bacek no worries, You can fix it later (after merge)
ok, green light 05:02
purl rumour has it green light is "Go!"
bacek Bah... conflicts...
bacek hate svn more and more 05:03
Ok, rerunning fulltest after merge. 05:07
05:21 quek joined 05:30 JimmyZ joined
bacek Here we go 05:32
cotto hio 05:33
bacek cotto: good... erm.. morning?
cotto can it be merging time now please?
2230
dalek rrot: r41039 | bacek++ | trunk (16 files):
Merge kill_parrot_cont branch into trunk.
bacek It's dcommitting time
bacek cotto: Saturday? 05:34
cotto Nice. Apparently the answer becomes "yes" if I ask enough.
yup
bacek heh, 1530, Sunday :)
cotto I'm behind the times. 05:35
bacek cotto: Or I'm ahead :)
cotto WELCOME TO THE WORLD OF TOMORROW 05:36
</futurama>
now I can sync pluggable_runcore 05:37
dalek rrot: r41040 | bacek++ | trunk/src/gc/alloc_register.c:
Revert "Temporary comment-out strict asserts on accessing registers in Context."

light.
cotto good idea
purl cotto: Good Idea: Taking a deep breath before jumping into a swimming pool. Bad Idea: Taking a deep breath after jumping into a swimming pool.
bacek cotto: need help with merging? :) 05:38
Did you ever sync branch with trunk?
cotto I'm syncing now. The merge should be pretty easy. 05:39
I want to make sure that I can profile Rakudo hello world before merging back.
bacek Ok. 05:40
dukeleto all this merging gets me excited
cotto It'd also be nice to get the profiling runcore reviewed. It's been on chromatic's todo list for a while, but he's a busy boy.
dalek rrot: r41041 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
[profiling] move a misplaced comment
bacek dukeleto: svn is way to simple... 05:41
cotto: which files required reviewing?
cotto mainly runops_profiling_core in src/runcore/cores.c and tools/dev/pprof2cg.pl 05:43
if chromatic's changes got anything wrong, the branch would break horribly
bacek cotto: looking 05:44
cotto thanks
jrtayloriv bacek, Do you know why we are keeping around all of the broken, old GMS code that is scattered throughout Parrot? 05:45
bacek jrtayloriv: because it's good task for rookie! :)
(to clean it all)
cotto It's stable (as in Augean) 05:47
bacek cotto: why you put check "if (argv && !Profiling_have_printed_cli_TEST(runcore)) " inside runops_profiling_core? Looks like it can be moved into _init.
jrtayloriv bacek, Do you mean clean it up as in get rid of it, or clean it up as in try to get it working?
bacek jrtayloriv: my current feelings - kill it all. 05:48
jrtayloriv: at least we shouldn't have ifdefed attributes in GC structures
cotto nope. init is run before that iglobal is initialized 05:49
jrtayloriv bacek, I've gotten rid of all of the #ifdefs for GMS (pretty sure I have at least), but there is still a lot of stuff (like the write barrier code) that is scattered around everywhere.
dukeleto purl, GMS ?
purl bugger all, i dunno, dukeleto
jrtayloriv Generational Mark and Sweep
dukeleto purl, GMS is Growling Mad Scientist or Generational Mark and Sweep 05:50
purl OK, dukeleto.
jrtayloriv :)
cotto if there are any :init subs, those run before it's initialized too
bacek jrtayloriv: get rid of it. We need pointers to write_barrier and read_barrier functions in GC_Subsystem
cotto: oh shi... ok.
jrtayloriv bacek, already got that done too -- I declared write_barrier hooks in GC_Subsystem, that is. Don't have any read_barrier functions in there yet though. 05:52
(good idea)
bacek jrtayloriv: ok. Just put comment in GC_Subsytem that "read_barrier should go here" 05:53
jrtayloriv Although, from what I've been reading, write barrier is a lot more efficient, since writes to heap are much less common than reads.
But I guess it's good to have flexibility anyways.
bacek jrtayloriv: yes, but not so flexible :) Comment inside structure will be enough 05:54
jrtayloriv ok
bacek cotto: looks good. CONTEXT macro is "deprecated" but it can be fixed later. 05:56
cotto ok. what's the proper replacement?
bacek Parrot_pcc_get_something 05:57
cotto the merge worked!
I only had to fix a few conflicts. 05:58
bacek Ignore it this functions for now. I'm going to add bunch Parrot_pcc_get_current_something which will use current Context.
dukeleto cotto++
bacek cotto++ #indeed
cotto so don't do anything? I can do that all day long!
bacek cotto: just merge it!
DO IT! 05:59
05:59 theory joined
bacek Anyone counting how many big branches were merged since 1.4? 05:59
cotto I think it's 5 (plus mine fairly soon) since 1.5 06:00
bacek erm. 5 in 2 weeks?
We can finish parrot development even before 2.0! 06:01
dalek rrot: r41042 | cotto++ | failed to fetch changeset:
sync pluggable_runcore with trunk
bacek Just need to continue this pace and remove DEPRECATED.pod from repo :) 06:02
cotto It'd be fun to fix freeze/thaw next.
I can't shake the feeling that Parrot would be much better off if we just ignored (or severely loosened) the deprecation policy until 2.0 or so. 06:03
bacek "Parrot 2.0 - with backjack and hookers!"
cotto That'd be the first name to get vetoed. 06:04
bacek *sigh*
cotto "Bendering Time" would make a great release name. 06:05
bacek anyway, looks like someone have to start gathering NEWS for 1.6. It will be freaking big list. 06:07
cotto If anyone's bored, removing the deprecated get_repr VTABLE function would help increase test coverage on FPA and Namespace. 06:08
bacek cotto: good idea.
purl bacek: Good Idea: Playing the piccolo in a marching band. Bad Idea: Playing the piano in a marching band.
bacek coverage? 06:09
purl hmmm... coverage is cv.perl6.cz
cotto let's see if Rakudo likes being profiled
bacek++ for the review
bacek cotto: I didn't check pprof2cg.pl, btw 06:14
should I?
cotto It wouldn't hurt.
bacek Noone including me? :) 06:15
cotto segfault on rakudo hello world 06:16
:(
bacek hmm... I'll try to check it 06:17
cotto: pprof2cg can be better...
Use 3-args "open" instead of 2-args. 06:18
cotto what's that do? 06:20
you mean open(FH, "<", $filename)?
bacek cotto: yes 06:21
dukeleto 2 arg open()'s ? THE HORROR 06:22
cotto thanks
dukeleto please check return values of open/close kthanxbai
cotto: just a general statement, not directed at you
cotto but I like silent and/or delayed failures 06:23
bacek cotto: especially GC related? :)
cotto I didn't know about checking close, though. I'll have to make a habit of that. 06:24
bacek cotto: personally I prefer to split process_line into smaller functions, one per each case. 06:25
cotto and use a dispatch table? 06:26
That's a good idea. The current iteration of the code was refactored from being functionless with many file-global variables. 06:27
bacek cotto: yes.
cotto I'll put that on my pre-merge todo list, right after making Rakudo hello world not explode 06:28
dukeleto cotto: checking close() ensures that your data is properly sync'ed to the hard drive.
cotto is close(FH) or die "..."; the right thing to do? 06:29
dukeleto cotto: also, open( my $fh, '<', $filename) is preferrable, but not a big deal
cotto: close(FH) or die $!;
bare filehandles are considered old-skool 06:30
bacek cotto: it can be "post-merge" 06:31
dukeleto cotto: i will take a look at the script with my critical eye after you merge, if you like
cotto bacek, sure 06:32
dukeleto, I appreciate that. I like writing modern Perl.
dukeleto cotto: i like reading it!
and i hear one of the other parrot devs likes it too... 06:33
bacek cotto: last 2 things: '$stats->{$file}{$ns}{$line}[$curr_op]' in get_gc_profile can be "cached" (for readability and performance sake)
cotto oh. The runcore segfaults on PIR hello world too.
dukeleto yay for caching 06:34
bacek cotto: little bit of docs about "$stats" storage format will help to understand it
Ah! And you missed "use warnings" :) 06:35
cotto not for long 06:36
dukeleto likes warnings 06:37
bacek In Soviet Russia warnings like YOU! 06:38
dukeleto they warn with an iron fist there
cotto there's the changes. Thanks a bunch dukeleto++ and 06:46
bacek++ for your suggestions
bacek cotto: need help with segfault?
cotto yes
bacek checking Parrot_Context_get_info 06:47
dalek rrot: r41043 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[pprof2cg] various improvements to make this script more modern and paranoid
 06:48
bacek cotto: done 06:50
dalek rrot: r41044 | bacek++ | branches/pluggable_runcore/src/runcore/cores.c:
Fix CONTEXT vs CURRENT_CONTEXT usage.
 06:51
cotto bacek++
I love you.
dukeleto sweet! i wrote a test that puts parrot into an infinite loop 06:52
cotto bacek, what's the difference? 06:53
bacek CONTEXT returns attributes of CURRENT_CONTEXT pmc
dukeleto can't tell if it is my fault yet
bacek cotto: one of... special ideas about deprecation policy... 06:54
dukeleto if i want to match the literal string foo with the test_more.pir like() function, i would give it a pattern of '<foo>', correct ?
dalek rrot: r41045 | bacek++ | branches/pluggable_runcore/src/sub.c:
[cage] Cache Sub PMC in Parrot_Context_get_info
 06:55
cotto I think that'd match the rule "foo"
sigh. Rakudo hello world explodes spectacularly when profiled. 06:56
bacek How "spectacularly"? Like as in nuclear bomb?
cotto MY COMPUTER ASPLODE 06:57
dukeleto cotto: interesting. that means that the test_more.pir function loops forever if you tell it to match a rule that doesn't exist. bug or feature?
cotto: how do I try to do a partial match of the string foo in the string bar? 06:58
cotto wait. What's it using for matching? PGE?
dukeleto cotto: yah
nopaste "cotto" at 74.61.2.46 pasted "rakudo asplode" (119 lines) at nopaste.snit.ch/17844 06:59
dukeleto cotto: while (my $line = <$in_fh>) will save you some newlines
cotto so it will 07:00
dukeleto cotto++ for modern paranoia
cotto dukeleto, I think a bare string without any funny characters will match itself
dukeleto cotto: hmmmm 07:01
dalek rrot: r41046 | jrtayloriv++ | branches/gc-refactor (7 files):
Moved structs out of gc_api.h and into gc_private.h, replaced some #if with if, minor updates to GC docs, reorganized for clarity
 07:02
dukeleto cotto: i can smell the rakudo flames from here
cotto I tried to run it with libefence, but I don't have enough memory. 07:03
dukeleto cotto: the like() tests use <[g]> to match the letter g in a string. is the [ ] a character class? I am not down with all the PGE coolness yet
cotto <[ ... ]> is the character class iirc. lemme double check
dukeleto cotto: like() seems to think i pass it the empty string if I give it a bare string to match 07:05
cotto nm. that's a non-capturing group
jrtayloriv bedtime -- later
dukeleto cotto: do I need to do some kind of .*foo.* ? 07:06
jrtayloriv; see you on the flip side
cotto Now I'm confused. S06 seems to say both that it's a noncapturing group and an enumerated character class 07:07
jrtayloriv, good night
dukeleto, svn.pugscode.org/pugs/docs/Perl6/Sp...-regex.pod . I'll probably just make you more confused. 07:08
bacek cotto: I can't spot why rakudo explode... 07:10
cotto bacek, did you intend to make those changes in pluggable_runcore?
It smells like memory corruption.
bacek which changes?
cotto r41045 [cage] Cache Sub PMC in Parrot_Context_get_info 07:11
bacek Ah, yes. I hope branch will be merged soon :) 07:12
cotto I'm trying a workaround. We'll see how that goes. 07:14
(I still want to find the real bug, of course)
bacek cotto: make realclean is workaround... 07:15
cotto that makes rakudo happy? 07:16
bacek cotto: yes
I did realclean in both of them
cotto ok
about 3.5m to profile Rakudo hello world 07:17
I also want to verify that make realclean fixes the explosion, but it's looking like I'll get to merge before going to bed! 07:18
bacek WOW! Rakudo's profile looks attractive! 07:20
cotto++!
SHIP IT! 07:21
cotto nope. it explodes again after make realclean
retrying after removing install dir and cleaning rakudo
bacek About 1/3 of Rakudo "Hello world" spend in OPTable;parse... 07:23
dukeleto can i catch a die() in parrot with an ExceptionHandler ? 07:24
ack: Unknown --type "pir" ! 07:25
the horror 07:26
bacek dukeleto: yes, you can
cotto crap. It exploded again.
bacek cotto: it works on my box! SHIP IT! :) 07:27
dalek TT #982 created by bacek++: [rfc][cage] Remove src/tsq.c from repo 07:31
cotto bacek, what are you running? 07:33
bacek parrot -Rprofiling perl6.pbc -e 'say "HELLO"' 07:34
cotto I mean your cpu, os, etc 07:35
bacek Linux/i386
Debian/Lenny
dalek rrot: r41047 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[pprof2cg] another modern fix and some caching to avoid repeated lookups
cotto Hmmm. basically same as me on Ubuntu 9.04/i386 07:36
dukeleto++ for those suggestions
That's really frustrating. 07:37
dukeleto i notice that none of the test_more.pir methods call each other. I was trying to implement pir_error_output_like in terms of like() . perhaps that is the problem?
cotto bacek, latest rakudo?
bacek cotto: looks like latest. I pulled it before kill_parrot_cont merging 07:38
cotto The branch clearly needs more testing. I'll hold off on merging until I either fix the problem on my end or find that several other people aren't having any problems. 07:43
bacek start cloning himself
All baceks vote for merging! 07:44
cotto If we had two or three more baceks Parrot would be *done* by 1.6.
bacek Unlikely. There is way too many things to fix... 07:46
cotto bacek, did pprof2cg complain at all about the rakudo hello world profile?
bacek We need at least 4 or 5
cotto: not at all
cotto Can you post a screenshot of kcachegrind showing "main" in the call graph window? 07:48
bacek With "Callee Map" tab?
cotto the Call Graph tab in another panel 07:49
bacek img-fotki.yandex.ru/get/3700/bacek....8a479_orig 07:51
cotto ok. mine's goofy then
07:52 Eevee joined
cotto thanks 07:52
bacek suspect that Rakudo/PCT recompile Perl6 grammar on startup 07:53
07:53 quek left
bacek ship it! :) 07:53
Ignore 2 faling tests in make fulltest. 07:54
failing
07:56 Zak joined
mikehh bacek: What's failing - do you need more testing - which branch? 07:57
bacek mikehh: trunk. I'm writing ticket now. 07:58
mikehh I don't get no fail;ures
bacek r41040
mikehh: JIT only.
mikehh failures
cotto mikehh, I'd appreciate it if you could check out pluggable_runcore, build rakudo with it and run parrot -Rprofiling perl6.pbc -e 'say "HELLO"' 07:59
bacek r41036 actually with explanations
mikehh ok - give it a try
cotto I'm going to bed soon, but please post here whether it worked or not. It'll be very obvious if it didn't work.
dukeleto ack is still on svn. yuck. i *was* going to add parrot support 08:00
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41047 - Ubuntu 9.04 amd64 (g++)
dukeleto ack svn seems to have the parrot filetype 08:02
cotto it has some parrot support already. Andy hangs out here sometimes and has a commit bit.
dukeleto but not the released version
cotto (for parrot)
dalek TT #983 created by bacek++: [bug] JIT code incorrectly access registers 08:04
dukeleto yay for ack --type=parrot 08:06
cotto I'm going to bed. Good night. 08:08
mikehh cotto: ok building now - will test rakudo after a trunk test 08:09
bacek cotto: Wait! Come back! Merge it to trunk!
dukeleto bacek: nice pretty pictures 08:10
bacek dukeleto: which one? Profiling? IT'S AWESOME :) 08:11
dukeleto bacek: yes, the profile pic. very cool. what other gui's are available/possible? i am on os x 08:15
purl well, on os x is there a file or something where once can add extra dirs to DYLD_FALLBACK_LIBRARY_PATH?
dukeleto purl, forget on os x
purl dukeleto: I forgot on os x
08:16 iblechbot joined
bacek dukeleto: no idea... 08:19
purl i guess no idea is jays.net/images/noidea.jpg
bacek But profile format is same as in valgrind 08:20
mikehh cotto - failed to build with g++ - builds ok with gcc, make test PASS
bacek So, any valgrind-compatible guis on macosx (if any) should work
mikehh: what is g++ error? 08:21
mikehh src/runcore/main.c: In function ‘void dynop_register_xx(parrot_interp_t*, size_t, size_t, op_lib_t* (*)(long int))’: 08:22
src/runcore/main.c:964: error: cast from ‘runcore_t*’ to ‘int’ loses precision
make: *** [src/runcore/main.o] Error 1
pluggable_runcore branch at r41047 - Ubuntu 9.04 amd64 08:23
dukeleto does the parrot vim highlighting often freak out for everyone else as well ? 08:24
bacek dukeleto: for PIR? Yes. 08:25
mikehh: what is Configure line to use g++? 08:26
dukeleto bacek: ok, i feel better now
bacek Ah! I've got similar question about GCC warning for "structure size is N bytes". 08:27
Is it only my problem?
(298 of 351): warning: size of ‘core_op_info_table’ is 55440 bytes 08:28
etc
mikehh bacek: perl Configure.pl --optimize --test --cc=g++ --cxx=g++ --link=g++ --ld=g++ --configure_trace --prefix="$HOME/install" 08:29
bacek mikehh: thanks
mikehh bacek: you probably don't need all that
bacek copy-paste ftw! :) 08:30
mikehh ok rakudo passes on trunk 08:31
rakudo (6e2104a) builds on parrot r41047 - make test / make spectest (up to r28193) PASS - Ubuntu 9.04 amd64 (g++) 08:33
dukeleto mikehh: what does --test do to Configure.pl ?
mikehh runs test before and after the configure
dukeleto mikehh++ 08:34
mikehh cotto: got some codetest failures
--test=configure Run tests of configuration tools before configuring 08:36
--test=build Run tests of build tools after configuring but before calling 'make' 08:37
--test Run configuration tools tests, configure, then run build tools tests
I generally call these pre and post-config tests 08:39
cotto: in testS -> t/pmc/threads.t - Failed tests: 2-3, 6, TODO passed: 13 08:45
bacek mikehh++ 08:47
mikehh also got codetest and manifest_tests failures - let me see 08:48
bacek mikehh: I'll fix codetest failures. 08:49
But I can't fix manifest...
dalek rrot: r41048 | bacek++ | branches/pluggable_runcore (3 files):
Store core id in runcore_t and use it dynop_register_xx
 08:50
08:53 chromatic joined
mikehh bacek - was fixin' those and will run tools/dev/mk_manifest_and_skip.pl 08:53
dalek rrot: r41049 | bacek++ | branches/pluggable_runcore/src/runcore/cores.c:
Fix codetest failures reported by mikehh++
mikehh which oftem picks more codetest failures
bacek mikehh: yeah... make codetest stopping on first fail in file 08:54
hmmm... Looks like Switch runcore always take first sub as :main even if there is special :main sub exists. 08:57
chromatic That shouldn't be. 08:58
bacek chromatic: pluggable_runcore branch :) 09:00
t/pmc/thread.t failure
line 277
chromatic That really shouldn't be.
bacek If I swap "check" and "main" test passed. Otherwise it output only one "ok"...
chromatic: hmm... Indeterministic failure. 09:03
dalek rrot: r41050 | mikehh++ | branches/pluggable_runcore/MANIFEST:
run tools/dev/mk_manifest_and_skip.pl
bacek Yay. Thread.join. Looks like output isn't flushed. 09:04
cotto bacek, no thread failure here
bacek cotto: go to bed! 09:05
<mikehh> cotto: in testS -> t/pmc/threads.t - Failed tests: 2-3, 6, TODO passed: 13
cotto oh, tests 09:06
There should also be some tests for the profiling runcore that output to /dev/null. 09:07
then people can avoid running that because it'll be so slow
bacek, I'd be asleep if I could be.
;) 09:08
bacek passing bottle of Sleeping Vodka to cotto.
Drink it! :)
cotto I have a bottle of cleaning vodka. 09:09
It's nice to have other people doing stuff in that branch. 09:13
bacek cotto: Just because I want return to Lorito. And we need pluggable runcores for it :)
cotto Lorito also needs design work figuring out what opcodes will be sufficient for implementing everything else. 09:15
Interesting. There's not a substantial difference in time between writing to a file and /dev/null.
and writing to a file was somehow faster 09:16
bacek Put fsync at the end :)
dalek rrot: r41051 | mikehh++ | branches/pluggable_runcore (2 files):
fix some codetest failures after MANIFEST fixes
 09:17
mikehh dammit missed one
cotto that'll slow it down nicely 09:18
mikehh chromatic: what is the Missing properly located perl coda for parrot source for tools/dev/pprof2cg.pl line 214 mean? 09:20
bacek mikehh: tail tools/dev/mk_manifest_and_skip.pl will give you idea :) 09:21
cotto mikehh, see the bottom of tools/dev/opsrenumber.pl for an example
(there are many examples)
mikehh, I'll add one now.
mikehh ok got it - I just remember I had that before and chromatic fixed it - I recall now 09:23
chromatic I'm glad YOU remember that, because I don't. 09:25
mikehh I was looking at the line number and trying to figure out what was wrong at that line
fix coda in mind ... fix code ... 09:26
bacek chromatic: you'll love TT#983 :) 09:27
dukeleto i am being plagued by Tests out of sequence. 09:31
09:33 mokurai left
cotto bacek, you should have gotten some kind of error profiling rakudo hello world. the pprof file didn't handle sub names with '}' in them. 09:34
chromatic JIT bugs, lovely.
I spent some time waiting at the bakery today explaining what's wrong with our current JIT and how I expect Lorito to help to my lovely companion. 09:35
bacek cotto: bacek@icering:~/src/rakudo.tt452$ time !!
time perl ../parrot/tools/dev/pprof2cg.pl parrot.pprof.6939
real\t0m12.533s
user\t0m8.973s
sys\t0m0.032s
cotto: no errors at all.
nopaste "dukeleto" at 69.64.235.54 pasted "out out sequence errors in test_more.pir" (178 lines) at nopaste.snit.ch/17845
dukeleto code review please: github.com/leto/parrot/commit/29cb3...9c7b65e466 (the nopaste is the test output) 09:36
cotto bacek, that's rakudo hello world?
bacek cotto: yes
cotto the file takes ~10m to process on my machine 09:37
chromatic Call a priest.
dukeleto hahahaha
purl LOLCON 4 reached.
bacek bacek@icering:~/src/rakudo.tt452$ ls -la parrot.pprof.6939
-rw-r--r-- 1 bacek bacek 3054119 2009-09-06 17:16 parrot.pprof.6939
bacek@icering:~/src/rakudo.tt452$ time perl ../parrot/tools/dev/pprof2cg.pl parrot.pprof.6939
real\t0m9.044s
user\t0m8.989s
sys\t0m0.008s
bacek@icering:~/src/rakudo.tt452$ 09:38
May be it's just silently fail.
cotto how big is the profile?
bacek 3054119
I just pasted it :)
cotto lines or bytes? 09:39
bacek -rw-r--r-- 1 bacek bacek 116183 2009-09-06 19:37 parrot.out.6939
bah.
Failed. Silently.
cotto ninja-style
dukeleto chromatic: you are familiar with testing test_more.pir, right? mind taking a look at my code review? it is short and totally baffling me
chromatic Will do tomorrow!
dukeleto ok
bacek dukeleto: you definitely missed pop_eh in handler" 09:40
handler:
dukeleto: after "get_results"
dukeleto bacek: thanks for catching that, but my test doesn't even invoke the handler, so that is not the issue. but I just added it and i still have the same problem :( 09:41
bacek which problem? 09:42
purl which problem is that?
bacek purl: forget which problem
purl bacek: I forgot which problem
dukeleto bacek: the number of my test comes out wrong
bacek erm. Can you nopaste example?
dukeleto dukeleto: if i run my test last, it is off by 2. if I run it first, it b0rks the ordering of the rest of the run
bacek: nopaste.snit.ch/17845 09:43
dalek rrot: r41052 | mikehh++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
add coda to tools/tools/dev/pprof2cg.pl
 09:44
bacek dukeleto: looks familiar...
dukeleto bacek: do tell
mikehh pluggable_runcore branch - rakudo (6e2104a) builds on parrot r41051 - make test / make spectest (up to r28193) PASS - Ubuntu 9.04 amd64 (g++) 09:45
sorry that was gcc
bacek dukeleto: I've got similar issue in pmc_pct branch. cotto did workaround, but we didn't fix original issue
dukeleto bacek: glad to know that I am not insane 09:46
bacek: what is the workaround?
purl the workaround is sweeping shitty behavior and code under the carpet
dukeleto botsmack
purl shoots up... ahhh 09:47
nopaste "bacek" at 114.73.156.240 pasted "Test::More patch for dukeleto" (17 lines) at nopaste.snit.ch/17846
dalek rrot: r41053 | cotto++ | branches/pluggable_runcore (2 files):
[profiling] enable the pprof format able to deal with silly names like ns:Associative[::T];postcircumfix:{ } should anyone choose to use them
bacek dukeleto: can you try nopasted patch?
cotto: no pprof2cg complains about uninitialised values A LOT 09:49
cotto: s/no/now/ 09:50
dukeleto bacek: error:imcc:The opcode 'get_hll_global_ic_pc_sc' (get_hll_global<3>) was not found. Check the type and number of the arguments 09:51
in file 'runtime/parrot/library/Test/More.pir' line 71
bacek: is that in your branch ?
cotto bacek, you'll have to regenerate any profiles
bacek dukeleto: in pluggable_runcore. But it doesn't matter... 09:52
cotto: Ah, ok
dukeleto bacek: the get_hll_global_ic_pc_sc opcode i mean
bacek: should that be there?
cotto and pprof2cg will catch such problems in the future
bacek dukeleto: it's just get_hll_global copied from ~10 lines below...
dukeleto dukeleto: you mean set_... ? 09:53
dalek rrot: r41054 | cotto++ | branches/pluggable_runcore/tools/dev/pprof2cg.pl:
[pprof2cg] be a little more paranoid about input checking
 09:54
bacek cotto: doesn't help... 117349 bytes in new profile
dukeleto bacek: oh, i think i see it
bacek: no, i still get a compile error with your path 09:55
patch, even 09:56
09:57 clinton joined
bacek dukeleto: it's... weird. 09:57
dalek rrot: r41055 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
[profiling] add a note about a workaround for an apparent memory corruption bug
dukeleto bacek: i got it to compile, but not working yet 09:58
mikehh cotto: ran the parrot -Rprofiling perl6.pbc -e 'say "HELLO"' - says HELLO then PROFILING RUNCORE: Wrote profile to parrot.pprof.11989 09:59
cotto mikehh, great. It works.
This is odd. The profile is now 10% the original size. 10:00
nopaste "dukeleto" at 69.64.235.54 pasted "odd test_more.pir issue" (178 lines) at nopaste.snit.ch/17847
cotto debugging this at 0300 is not a good idea. 10:01
time for attempt #2 at going to sleep
mikehh 74039 lines - 3031775 bytes
dukeleto bacek: github.com/leto/parrot/commit/73135...48a1bf0cce give me the output at nopaste.snit.ch/17847
cotto night
dukeleto cotto: take it easy
bacek dukeleto: erm... 10:04
dukeleto bacek: i think i applied your patch incorrectly. it didn't apply automagically
bacek dukeleto: can you nopaste git show 29cb35f71cc3a9b5265e23c8cc51be9c7b65e466 ? 10:06
(original patch)
nopaste "dukeleto" at 69.64.235.54 pasted "orig patch" (142 lines) at nopaste.snit.ch/17848 10:08
bacek msg cotto src/runcore/cores.c, lines 1148. Looks like off-by-one 10:09
purl Message for cotto stored.
dukeleto bacek: do test_diag and test_test count as separate tests?
bacek dukeleto: they should'n 10:10
dukeleto bacek: just askin'
bacek but looks like they are
dukeleto hmmm
bacek: only for my test?!
bacek: it still fails without the test_diag as well 10:11
happy pi time 10:14
in PDT at least
bacek dukeleto: Bah! 10:18
dukeleto sees a sheep run by
10:18 clinton joined
bacek dukeleto: just move test_pir_error_output_like after test_todo. 10:25
msg dukeleto just move test_pir_error_output_like after test_todo. 10:26
purl Message for dukeleto stored.
10:26 Whiteknight joined
Whiteknight good morning #parrot 10:30
bacek When someone fell asleep, someone else have to resolve merge conflicts and merge branches! 10:32
Whiteknight bacek++ and kid51++ for getting that branch merged
bacek Good morning, Whiteknight :)
Whiteknight I have no idea what my problem was last night 10:33
bu SVN said "no"
bacek because branch wasn't up-to-date with trunk...
Whiteknight I updated right before I merged
bacek Just another svn shenanigans... 10:34
Whiteknight ok
we done with context_pmc3 so I can delete it? 10:35
bacek Whiteknight: looks like it can be killed now 10:36
Whiteknight and xkill_parrot_cont too, I assume?
ok
dalek rrot: r41056 | whiteknight++ | branches/context_pmc3:
[context_pmc3] branch has been merged to trunk
 10:37
rrot: r41057 | whiteknight++ | branches/kill_parrot_cont:
[kill_parrot_cont] branch was merged by bacek++ and kid51++.
rrot: r41058 | whiteknight++ | branches/xkill_parrot_cont:
[xkill_parrot_cont] the kill_parrot_cont branch got merged, so this diagnostics branch is not needed
Whiteknight bacek: what's going on with orderedhash_revamp? 10:39
bacek Whiteknight: it's stalled. I forgot to put deprecation notice in 1.4. 10:40
Whiteknight ah, right.
bacek And I don't want to reproduce current behaviour about deleted keys...
Whiteknight and how are things going on context_attrs? 10:47
dalek rrot: r41059 | NotFound++ | trunk/src/debug.c:
[cage] some cleanups and refactoring in debugger functions
rrot: r41060 | NotFound++ | trunk/include/parrot/sub.h:
[cage] update headerizing
bacek Whiteknight: context_attrs are stuck with current GC. We can't allocate arbitrary chunk of memory easily... 10:49
But I'll try to do something tomorrow. 10:50
Whiteknight bacek: there are fixed-size allocation functions in there now that you can use 10:51
I assume for allocating the register arrays?
bacek Yes. 10:53
Let me check how I can use it
Whiteknight jrtayloriv: ping 10:54
purl msg jrtayloriv I want to make some cleanups to the fixed-size allocator. Is your gc-refactor branch touching that at all? 10:55
purl Message for jrtayloriv stored.
10:56 HG` joined
bacek Whiteknight: I can use fixed-size allocator. But it probably will not be very efficient. 11:00
Argh... No, I can't use it at all... 11:01
Whiteknight why not? 11:02
bacek "vtable->attrs_size" is dynamic for every Context
Whiteknight bacek: use Parrot_gc_allocate_fixed_size_storage 11:03
doesn't use vtable->attrs_size at all, just gives you a block
bacek It will be exactly same as current behaviour.
But I can replace mem_sys_allocate in Parrot_alloc_context with pool-based allocation 11:04
11:36 szabgab joined
Whiteknight that's probably going to be a small performance win 11:36
because the pool-based allocator will store freed items on a linked list for easy recycling
dalek rrot: r41061 | whiteknight++ | trunk/t/pmc/namespace.t:
[t] Add some documentation to namespace.t. Add a few tests involing VTABLE_string and HLL namespaces
 11:37
11:40 quek joined
Whiteknight if I have a namespace "Foo", I should be able to call new "Foo", right? 11:48
because a namespace should be a class
er, it should be related to a class
I have a namespace "Foo", and I call "new 'Foo'", and I get an error that Class "Foo" not found 11:49
bacek newclass 'Foo' 11:50
Whiteknight: PMC_Attribute_pool is suboptimal
Whiteknight bacek: yes, it needs tuning 11:51
bacek Let me rephrase. All GC is suboptimal :)
dalek rrot: r41062 | bacek++ | trunk (4 files):
Use fixed-size allocator for Parrot_Context
 11:57
12:01 kjeldahl joined
dalek rrot: r41063 | whiteknight++ | trunk/t/pmc/namespace.t:
[t] add a bunch more tests showing the relationship between NameSpaces, Classes and Objects
 12:01
bacek (78.15-75.18)/78.15 12:03
purl 0.0380038387715931
bacek Whiteknight: ~3% win 12:04
Whiteknight awesome! A win is a win 12:05
The only reason it's any good is because of fast recycling
bacek dream about Generational GC in parrot... 12:10
Whiteknight bacek: I was hoping to start working on a parallel GC system too 12:18
for systems with multiple cores, that would be ideal 12:19
dalek rrot: r41064 | whiteknight++ | trunk/t/pmc/namespace.t:
[t] Add some notes to namespace.t about what still needs to be tested. Add one easy test for behavior in PDD21
 12:21
bacek Whiteknight: make sense. 12:35
BTW, you forgot about pop_eh after catching exception in new tests
Whiteknight do you need to do that? 12:37
I was copying a lot of that logic from other tests
bacek Whiteknight: yes. It doesn't matter in small test files. But it's better to put it in as "Parrot best practice" example 12:38
Whiteknight ok
bacek Anyway, my turn to sleep 12:39
Good night! 12:40
dalek rrot: r41065 | whiteknight++ | trunk/NEWS:
[NEWS] Give a quick pass through the news this month
 12:44
12:45 quek left
bacek + Contexts are not garbage-collectable 12:45
Thank you very much! :( 12:46
:)
12:46 MoC joined
bacek + Removed PMC_Sync from PMC 12:46
It's not happened yet, afaik
bacek must sleep 12:47
purl $bacek->sleep(8 * 3600);
12:49 szabgab joined 12:50 Andy joined
jrtayloriv Good morning. 12:53
purl And good moroning to you, jrtayloriv.
jrtayloriv Whiteknight, I don't think anything that I'm doing should affect the fixed-size allocator, and I wasn't planning on doing anything with it, but I don't know much about it yet -- I'll make sure. 12:54
12:55 ruoso joined
Whiteknight okay, thanks 12:55
I have some cleanups I want to do, but don't want to step on your toes 12:56
jrtayloriv Whiteknight, I've moved a lot of stuff around (for example, moving some structs out of gc_api.h into gc_private.h and reordering things), but as long as I don't actually touch the parts related to the fixed size allocator, all of the stuff moving "around" it won't make it difficult to merge, correct? 12:57
Whiteknight I'l just hold off, most of my changes are aesthetic 12:58
12:59 kid51 joined 13:00 quek joined 13:06 Andy joined
dalek rrot: r41066 | whiteknight++ | trunk/src/pmc (2 files):
[cage] some misc cleanups relating to the recent changes to Context and Continuation pmcs
 13:07
Whiteknight purl msg bacek the API functions in src/call/context.c should probably all check that the PMC is a valid Context PMC.
purl Message for bacek stored.
jrtayloriv Is editing compilers/imcc/main.c::parseflags() the proper way to add a command-line switch, or is there something else that I should do to add them instead? 13:14
Basically, I want to create a flag that looks like --gc=MS, --gm=IMS, etc to set the GC engine when parrot is invoked. 13:15
dalek a: ceec3db | fperrad++ | src/lib/luapackage.pir:
remove languages/lua in LUA_PATH
 13:18
a: 8239b69 | fperrad++ | src/lib/luapackage.pir:
remove languages/lua in LUA_PBCPATH
Whiteknight jrtayloriv: that's probably the only place to add it, unfortunately 13:19
eventually the command-handling stuff needs to be refactored
jrtayloriv Whiteknight, ok -- thanks. 13:20
dalek rrot: r41067 | whiteknight++ | trunk/src/sub.c:
[cage] a few small cleanups to sub.c
jrtayloriv Whiteknight, is there any way to keep merging trunk into branch as I go along, so that I can make less conflicts when merge happens? 13:23
i.e. nm -- (wtf am I talking about...) 13:24
13:24 joeri joined
Whiteknight jrtayloriv: yes. When you merge, you merge a range of revisions 13:28
so if you keep track of which revisions you merge, you can do it bit by bit 13:29
svn merge -rX:Y ... and then svn merge -rY:Z ..., etc
13:30 quek left
jrtayloriv Whiteknight, OK -- so always just keep track of the end of the range of the last merge, and start from there? Thanks! Is there any reason not to do that -- i.e. are there any problems that might cause? 13:33
Whiteknight jrtayloriv: I don't know of any particular reason not to do that, no. I used to for some branches but got out of the habit 13:37
The best way to prevent problems is to make branches short-lived 13:38
13:38 Andy joined
jrtayloriv ok 13:38
NotFound I have a lot "Parrot_find_dynamic_padwas not declared in this scope" errors 13:43
kid51 jrtayloriv: Other things being equal, the fewer files you touch in your branch, the fewer files you're going to have conflicts in when you go to merge. 13:44
This is the spatial corollary to the temporal guideline Whiteknight just mentioned. 13:45
jrtayloriv kid51, ok, thanks
kid51 IMO part of the problem we got into yesterday was that the various branches were all targeting large numbers of files.
NotFound If you discover something that must be changed but is no strictly dependent on the branch, better change it in trunk and merge
kid51 Perhaps that was unavoidable for any given branch, but it added up to trouble at a time when we've got multiple branches targeting the same source files. 13:46
jrtayloriv kid51, ok -- sorry about the trouble it caused. Thanks for your help trying to get it merged. 13:47
dalek rrot: r41068 | NotFound++ | trunk/include/parrot/sub.h:
[cage] update headerizing
kid51 jrtayloriv: I'm not singling you out. I think it was the combination of all these branches landing at the same time that caused problems. 13:48
NotFound Yeah, we've made a lot of big merges these weeks 13:49
Whiteknight jrtayloriv: Oh and one more thing: Don't rename files in branches
SVN is retarded about that
kid51 We are not collectively trained to ask: "Can the scope of this branch be made smaller?" But increasingly I believe we should.
Whiteknight kid51: I agree 13:50
I've been purposefully trying to keep my own branches smaller in scope
kid51 Because of the layout of our files in SVN, we almost always are branching the whole of trunk when we create a branch. 13:51
One thing I've realized from $job is that if your repository module is set up in a different way, it is possible to create smaller branches.
But discovering that "different way" is not easy. 13:52
Whiteknight I think we're moving in that direction by creating separate folders for various subsystems 13:55
kid51 ... which means that before creating a branch that touches many source code files, a developer might want to write up a statement (for own use, at least) which says, "In this branch I need to touch these source files X Y Z for these reasons."
Whiteknight and increasing encapsulation for those system
kid51 Whiteknight True, but having all tests under 't/' imposes a limit on that.
Whiteknight: You might want to post to list on the various subsystem-specific subdirectories you envision us having. 13:56
Whiteknight kid51: yes, definitely
there was a planning page like that on the wiki somewhere 13:57
jrtayloriv: made most of my changes to the fixed-size allocator in r41069. Shouldn't affect your work
dalek rrot: r41069 | whiteknight++ | trunk (4 files):
[gc] Some fixes to the fixed-size allocator code. No real functional changes, just changed what happens where. Should be neutral performance-wise
 14:00
jrtayloriv Whiteknight, nope, none of that is conflicting w/ anything I'm doing. 14:05
Whiteknight okay, awesome
Whiteknight is going to disappear for a while and find food.
dalek a: 3261341 | fperrad++ | t/package.t:
fix test of package.pbcpath
 14:14
14:48 jan joined 14:53 ruoso joined 14:54 Psyche^ joined 14:57 tetragon joined
jrtayloriv I want to add a command-line switch that will affect the GC system's init routine, so I need the value to be available to make_interpreter() (so that it is available to Parrot_gc_initialize()) -- but parseflags() is called after interp has been created. Is there a way around this, or should I just initialize the GC system to default type, and then re-initialize it later somehow if a non-default GC core was set at the command li 14:57
ne?
purl ne is probably numeric though, isn't it?
15:03 Andy joined
dalek kudo: 09b9540 | (Solomon Foster)++ | src/setting/ (2 files):
Provide Any.sin, Any.cos, Complex.sin, and Complex.cos.
 15:11
rrot: r41070 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
[profiling] fix an off-by-one bug found by bacek++ which appears to solve the memory corruption bug noted earlier
 15:27
Whiteknight jrtayloriv: that's a very good question 15:36
that's probably a question for the mailing list 15:40
jrtayloriv Whiteknight, I was thinking that what might be needed is to have 2 seperate command-line arg processing functions. The first would run before Parrot_new, and would look for any args that are not imcc specific. All args that don't match the ones defined in that file would be passed on to the imcc-specific arg parsing function. If the arg is not found in the imcc arg parser, *then* an exception would be thrown about invalid args. 15:41
Does that make sense?
Whiteknight cotto had a function a few days ago that parsed argv into a ResizableStringArray PMC
NotFound I'll better completely remove command line args parsing from imcc 15:42
cotto I switched to using an environment variable
Whiteknight If we did that in main(), we could pass the RSA to IMCC and to make_interpreter
cotto: yes, but that function may be very worthwhile now
especially if we want to be doing more stuff with commandline args
jrtayloriv: for the time being you could use an environment variable too 15:43
NotFound imcc, and his replacements, must have an api for setting options and not toy with command line arguments.
jrtayloriv Whiteknight, OK -- I'll look into that. Thanks. 15:44
Whiteknight NotFound: Agree 100%
That might need to be a branch-task sooner rather then later 15:47
I've actually got a lot of changes and refactors I want to make in startup and IMCC 15:48
Whiteknight smells a blog post a-brewin' 15:49
jrtayloriv OK -- I'll just hold up on choosing GC at command line for now then.
Not really anything to choose between right now anyway :)
NotFound And BTW, imcc must not be needed at all just for loading and running a pbc file
cotto Whiteknight, absolutely. It'd be much better if there were a nice way to pass strings to Parrot subsystems from cli options. 15:50
btw, now that the off-by-one bug is fixed, I'll be merging pluggable_runcore as soon as I figure out where the mysterious 90% decrease in running time came from. 15:51
but now, church time
Whiteknight I don't want IMCC to be executing anything at all, directly. It should take a file and return a Sub 15:52
or, it should add Subs to the scheduler
dukeleto 'ello
Whiteknight hello dukeleto
Whiteknight needs to go shower. Later 15:53
dukeleto test_more.pir hates me 16:09
is there a way to tell what the current test number is from test_more.pir? i am chasing down test ordering/numbering bugs in test_more.pir 16:15
16:20 kid51 joined
dukeleto i figured it out 16:27
print'ing to stdout from within t/library/test_more.t confuses the TAP reader 16:28
i wasn't seeing the output with prove, but it is clear as day with ./parrot 16:29
16:32 payload joined 16:39 szabgab joined
dukeleto where do i got to learn the basics of PGE regexen ? 16:41
dalek lscript: 20ec319 | fperrad++ | wmls (4 files):
remove useless .loadlib
 16:42
lscript: e2c0afb | fperrad++ | src/wmlsstdlibs.pir:
remove useless prelude
lscript: a99bd85 | fperrad++ | src/script.pir:
remove useless .loadlib
lscript: 7809a4f | fperrad++ | (7 files):
refactor with the opcode load_language
lscript: 088043d | fperrad++ | config/makefiles/ (3 files):
fix target clean
lscript: 9f8e27f | fperrad++ | config/makefiles/ (3 files):
update target install
16:44 sri joined 16:54 theory joined
dalek rrot: r41071 | NotFound++ | trunk/config/auto (4 files):
[config] print yes or no instead of done in several auto probes result
 16:55
16:57 mokurai joined 17:06 paco joined
dalek rrot: r41072 | NotFound++ | trunk/t/pmc/fixedpmcarray.t:
[t] test get_repr in FPA
 17:15
dukeleto repo has a self-signed cert now? 17:17
NotFound dukeleto: firefox does not warn in www.parrot.org/ 17:19
Page info shows a cretificate from "Equifax Secure Certificate Authority" 17:21
dukeleto NotFound: svn warn's though :) 17:23
NotFound dukeleto: mine doesn't
dukeleto NotFound: my svn in ancient (1.4.4), perhaps that is why 17:24
NotFound dukeleto: go to the web site and verify the signature, just to be sure 17:25
jrtayloriv Whiteknight, ping
17:34 chromatic joined
Whiteknight pong 17:36
jrtayloriv Whiteknight, are there any cases where a GC subsystem would need to register different add_free_object/get_free_object/alloc_object functions for different Small_Object_Pools, or can I just move all of these into the GC_Subsystem struct, and assume there is only a single such function per GC system? 17:38
Whiteknight until recently, we did have different functions for different pools
we had a special PMC_EXT pool that used different functions 17:39
jrtayloriv Whiteknight, right, but that's not needed anymore right?
Whiteknight not with the current system, no. We can probably optimize out a lot of it now
chromatic PMCs with custom destruction need special handling.
jrtayloriv Is it OK for me to move those function pointers into the GC_subsystem struct then? 17:40
Whiteknight chromatic is right, the functions to free an object in a pool are different for different pools
dalek lscript: 5a856f7 | fperrad++ | (3 files):
explicit load stdlibs after load_language
 17:41
lscript: ac821c1 | fperrad++ | wmls2p (2 files):
typo
jrtayloriv OK.
Whiteknight Is there any major benefit to moving those functions?
PDD09 specifically mentions them, so we probably shouldn't change that without a big reason to
dalek rrot: r41073 | dukeleto++ | trunk (3 files):
[t] Added pir_error_output_like to test_more.pir
 17:42
Whiteknight with that in mind, if we were able to avoid indirect function calls for every single PMC header during sweep, that would be a huge benefit
chromatic Easy solution: don't run VTABLE_destroy() then. 17:44
Think about the linked list GC; we can't run it then.
The solution will come to you with proper meditation, padawan.
Whiteknight chromatic: worse then that, sweep involves iterating over pools with callback functions to perform sweeps
17:45 sri joined
Whiteknight header_pools_iterate_callback is terrible in that regard 17:45
and that function calls a function pointer for every item in every pool, not just the PMCs that need active destroy 17:46
chromatic: I don't think there is any way we can get rid of VTABLE_destroy for all PMC types 17:49
17:50 Tene joined
chromatic We can't get rid of it. We can call it from other places at other times. 17:51
Whiteknight ok 17:52
I think the sweep code could be wildly improved once we realize that it's core-specific code
dalek lscript: eee5889 | fperrad++ | wmlsi.pir:
remove useless load_stdlibs
Whiteknight whoever wrote it had the intention that it would be general-purpose code for multiple cores, and that's not reality 17:53
In fact, I'm going to try to inline all that code right now. 17:57
18:02 paco left 18:09 fperrad joined
Whiteknight no, that's not the right function. header_pools_iterate_callback is not what I said it was 18:10
this sweep code is so needlessly convoluted. I always forget how shitty this all is 18:13
mikehh i am getting a codetest failure on include/parrot/register.h: Parrot_pcc_calculate_context_size - 1 unused assert macros found in total.
no idea how to fix - hearerizer? 18:14
fperrad dukeleto, about r41073, pir_error_output_like is a bad name in test_more.pir 18:15
names must be close with P5 Test::* module equivalent
for example, Test::Warn has warning_is & warning_like
Test::Exception has throws_ok
NotFound mikehh: I'll do it, just one moment...
dukeleto fperrad: ok, i was just using the Parrot::Test name 18:16
fperrad dukeleto, throws_like is a good candidat 18:17
dalek rrot: r41074 | NotFound++ | trunk/src/gc/alloc_register.c:
[cage] ASSERT_ARGS in Parrot_pcc_calculate_context_size
 18:19
dukeleto fperrad: ok, will do 18:22
18:27 sri_ joined 18:41 kjeldahl joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41074 - Ubuntu 9.04 amd64 (g++) 18:41
dalek rrot: r41075 | dukeleto++ | trunk (2 files):
[t] Rename pir_error_output_like to throws_like, fperrad++
 18:49
cotto ATTENTION: I'm going to merge pluggable runcore. Please don't commit anything until I've got it merged. 18:51
nm. need to run make fulltest first 18:52
18:52 paco joined
mikehh rakudo (09b9540) builds on parrot r41074 - make test / make spectest (up to r28195) PASS - Ubuntu 9.04 amd64 (g++) 18:57
dukeleto cotto: still want us to hold off committing? 18:59
dalek rrot: r41076 | dukeleto++ | trunk/t/library/test_more.t:
[t] Add basic test to make sure that like() passes when matching literal strings
cotto dukeleto, yes 19:00
I saw a test failure
dukeleto, no, rather
go ahead while I figure this out
dukeleto cotto: ok, 10-4 19:01
purl 6
19:01 paco left 19:02 pac1 joined
cotto Like everything else in life, merging is just a primitive degenerate form of bending. 19:03
dukeleto cotto: merging is fun in git :) 19:05
mikehh cardinal - builds on parrot r41074 - rake test:all - same 3 failures - Ubuntu 9.04 amd64 (g++)
cotto dukeleto, you seem to have made some pir tests sad.
dukeleto cotto: oh noes, which ones? 19:06
mikehh decnum-dynpmcs r181 builds on parrot r41074 - make test PASS - Ubuntu 9.04 amd64 (g++)
cotto most of them
purl somebody said most of them was because of the stupid 01_request failure
19:06 ruoso joined
cotto object 'pir_error_output_like' not found in current namespace 19:06
are you seeing the failure in trunk? 19:08
dukeleto cotto: got it
cotto excellent 19:09
dukeleto cotto: fix is on it's way in the tubes
cotto: i didn't do a "make clean" so my test suite passed. when I switched git branches i started seeing the failure 19:10
dalek rrot: r41077 | dukeleto++ | trunk/runtime/parrot/include/test_more.pir:
[t] Fix exporting of throws_ok
dukeleto cotto: it kind of sucks that we have to list the export list of test_more in 2 places, but whatev
cotto You're welcome to work on a fix. 19:12
but you already knew that. ;)
now let's see if those tests magically fix themselves
19:13 Ron joined
cotto dukeleto, object 'throws_ok' not found in current namespace 19:15
dukeleto cotto: hmmmmmmm
cotto: i am running the full suite over here, as well, investimigating it
cotto: nopaste your error so I can compare to mine when it finishes? 19:16
cotto: t/op/annotate.t, right ? 19:17
cotto in trunk, yes
dukeleto cotto: fixed it, on it's way. sorry about making your merge more difficult 19:18
cotto don't worry about it. 19:19
dukeleto cotto; r41078 should be super-awesome for you 19:20
dalek rrot: r41078 | dukeleto++ | trunk/runtime/parrot/include/test_more.pir:
[cage] Spell throws_like correctly
dukeleto !facepalm 19:21
cotto amazingly awesome
dukeleto it is dangerous that running the tests via "prove" does not regenerate the test libraries, if they have changed
NotFound dukeleto: it's dangerous to not using make and assuming things are make'd ;) 19:23
dukeleto NotFound: indubiously
moritz that's why Rakudo supports 'make t/path/to/file.t'
dukeleto moritz: yeah, i like that. it makes working on one spec test very easy 19:24
moritz: that is how I usually write perl 6 spec tests. parrot has a different workflow ;)
moritz well, one can add that make magic to parrot too, I presume 19:25
(at least for GNU make)
cotto trunk make test passes. next is trunk fulltest, then branch fulltest, then it's mergering time
moritz is there anything I should spectest with rakudo before merging?
NotFound moritz: go merge! 19:27
moritz NotFound: I won't merge, cotto does
NotFound Whatever
dukeleto moritz: mikehh is best to ask, he has been running on the bleeding edge. rakudo (09b9540) builds on parrot r41074 - make test / make spectest (up to r28195)
NotFound We'll fix anything that fails after. 19:28
dukeleto cotto++
cotto moritz, I'll let you know if anything looks like it'll hold up the merge I'm working on. 19:29
moritz cotto: sure, will do
cotto I'm seeing failures in trunk, and the look like the same ones I saw in the branch 19:32
I'll ignore them for now since they're most likely not related. make test passes, so I'll be merging now. 19:35
moritz so far rakudo's spectest on top of the branch looks clean, but it's not through yet 19:36
cotto moritz, it's not likely that you'll see a significant change. The most interesting feature of the branch only happens when you pass -Rprofiling to parrot.
The runcore changes are very unlikely to mess anything up. 19:37
moritz sure, spectesting doesn't hurt though
NotFound Did you add a do-nothing runcore?
dalek rrot: r41079 | cotto++ | branches/pluggable_runcore (31 files):
sync branch to trunk in preparation for merging
cotto NotFound, I added a "do-everything" runcore. ;) 19:38
NotFound Will be nice to have a do-nothing runcore and check how many tests it pass.
cotto the fast runcore is as close to do-nothing as possible
mikehh cotto: ready for more tests on the branch 19:39
19:39 bacek joined
cotto I'm merging now, so tests would be best after then 19:39
argh
svn: REPORT of '/parrot/!svn/vcc/default': Could not read chunk size: Secure connection truncated (svn.parrot.org)
h8h8h8h8
mikehh that's what whiteknight was getting call in bacek++ 19:40
moritz uhm, could it be that the profiling runcore is *slow*? 19:42
mikehh hay bacek
cotto moritz, the profiling runcore isn't slow.
it's very slow
bacek yawning
cotto clock?
purl cotto: LAX: Sun 12:42pm PDT / CHI: Sun 2:42pm CDT / NYC: Sun 3:42pm EDT / LON: Sun 8:42pm BST / BER: Sun 9:42pm CEST / IND: Mon 1:12am IST / TOK: Mon 4:42am JST / SYD: Mon 5:42am EST /
bacek Yes...
cotto bacek, why are you even up?
bacek No idea... 19:43
purl no idea is jays.net/images/noidea.jpg
cotto passes Sleeping Vodka back to bacek
bacek It's too late for Sleeping Vodka. Or too early...
hi mikehh 19:44
dukeleto bacek: which tz are you in?
cotto How about the morning vodka then? ;)
dukeleto yay, pir has the .= operator 19:45
mikehh SYD above I think
moritz ok, a simple Perl 6 file with 18 tests produces 61M of profiling information
cotto btw, how did that patch I made work?
mikehh in otherwords it's before 6am
cotto moritz, that sounds plausible
moritz ok, what do I do with it? 19:46
cotto the current format is purposefully very inefficient
tools/dev/pprof2cg.pl and feed that file to kcachegrind
mikehh me I'm on LON/BST
cotto mikehh, are you in London? 19:47
mikehh no Aberdeen in Scotland
dukeleto is in PDT, for completeness 19:48
mikehh We span the globe
cotto better than spamming it 19:49
NotFound Spanalot
cotto svn--
svn.parrot.org--
Whiteknight svn is the worst 19:50
mikehh I think jonathan is in Tokyo or something like that at the moment
moritz he is, yes
Whiteknight cotto: what's the merge command you are using? I can see if it works here
NotFound Give my regards to Godzilla
Whiteknight (it didn't last night, so SVN owes me) 19:51
19:51 fperrad left
cotto Whiteknight, svn merge svn.parrot.org/parrot/branches/plu...le_runcore . 19:52
(from a co of trunk)
Whiteknight no -r? 19:53
cotto 1.5+ doesn't need it
MoC Re jonathan: Private visit or official business?
cotto (svn version, that is)
moritz MoC: afaict private, plus a bit visiting of asian Perl conferences, or so 19:54
MoC Ok
Whiteknight it's thinking....
svn REPORT error here too 19:55
damnit
cotto: did you update the branch from trunk>? 19:56
cotto yes
Whiteknight bacek! you still awake? 19:57
cotto I have a patch, but it loses all the metadata and doesn't add the files to the repo.
Whiteknight well that's no good
cotto I can make it work, but I'd much prefer a saner approach.
Whiteknight yeah 19:58
I had this exact same problem with a merge last night, and bacek fixed it after I went to sleep
said something about the branch needing to be updated
bacek Whiteknight: barelly
Whiteknight bacek: How to fix branch merge problem?
mikehh I got svn, version 1.5.4 (r33841) - compiled Aug 7 2009, 02:02:06
Whiteknight (and then you can go to sleep) 19:59
bacek Whiteknight: I just use git, merge everything locally, cleanup stuff, commit to svn
Whiteknight oh, okay
thanks
Whiteknight has to get git eventually 20:00
actually, I have git, but I don't have any idea how to use it
mikehh I got git but don't use git-svn
yet
cotto Can someone do the merge or should I go with the caveman approach of applying a patch and cleaning up the resultant mess? 20:01
bacek cotto: pluggable_runcore?
Whiteknight cotto: I just updated branch from trunk and a lot of properties and stuff changed
cotto (or is there a svn invocation that I should be using instead)
bacek, yes
bacek sigh
cotto orly?
purl YA RLY.
bacek git-svn isn't perfect in handling branches which was synced with trunk using svn. 20:02
cotto: did you sync branch with trunk already? 20:03
Whiteknight archives.devshed.com/forums/develop...03895.html
cotto bacek, yes 20:04
bacek ~10 conflicts on merging with trunk. Let me check it.
Whiteknight it looks like lots of other people on TEH INTERWEBZ are experiencing similar problems 20:05
cotto bacek, can you do the merge? 20:06
mikehh yeah but it doesn't give a solution 20:07
bacek cotto: in progress
cotto bacek, thanks a bunch.
mikehh bacek++ to the rescue
bacek I can dcommit merge, but it was few conflicts here. 20:11
japhb pmichaud, ping 20:12
cotto bacek, can't those be resolved? 20:13
bacek Ok. Let me run make test. If it passed - I'll dcommit merge. We can fix other failures later in trunk.
cotto: I resolved them already. But I'm not 100% sure about correctness of my resolution... 20:14
cotto ok
I
I'll check it out.
bacek cotto: "runcode_print_start_info" still exists in branch? 20:15
cotto it doesn't 20:16
bacek ok 20:17
Parrot_gc_profile_start?
and ..._end?
cotto start, no. end, yes 20:18
that sounds broken
bacek hmm... Why keep _end? 20:19
cotto I don't know.
It's probably accidental. There's only one instance in src/gc/gc_malloc.c
bacek Ooookey. Can I remove it?
cotto go for it. The file clearly isn't built or we'd see some linker errors. 20:20
bacek src/runcore/cores.c: In function ‘opcode_t* runops_switch_core(parrot_interp_t*, Parrot_runcore_t*, opcode_t*)’: 20:25
src/runcore/cores.c:1415: error: expected initializer before ‘->’ token
japhb pmichaud, Tene, jonathan: pinging an NQP hacker ...
bacek cotto: Bah. It was g++. Let me try with gcc. 20:26
treed I think Tene is AFK. 20:27
His IM says so, anyway.
Actually, he's offline for once.
bacek cotto: hmm... Same problem
cotto This is a lovely mess. 20:28
japhb treed, OK, thanks. Seems I caught everyone at the wrong time. :-( 20:30
Whiteknight I updated branch from trunk, changed a few properties. I'm going to try the merge again now 20:32
bacek cotto: shit... #line somewhere confused gcc
Whiteknight And I sent a message to the list about all this bullshit 20:33
pmichaud japhb: pong
dalek rrot: r41080 | whiteknight++ | branches/pluggable_runcore (9 files):
[pluggable_runcore] updated from trunk, which changed a few file properties
Whiteknight because development is going to be a complete pain in the ass if this problem doesn't get resolved soon
...no dice 20:34
damnit
japhb pmichaud, I've got the afternoon to work on Plumage ... I'm testing stuff now, but I wanted to know if any changes other than Tene's HLL interop eval() implementation got into NQP. Especially the private attributes.
bacek cotto: Found it.
japhb has been effectively away from Parrot for about 1.5 weeks ... 20:35
Hmmm, almost 2, actually, sigh.
pmichaud japhb: nothing significant since Tene++'s eval changes
bacek japhb: 2 weeks? It's equal to "for ages"! :)
pmichaud this week I've been fixing up some rakudo stuff in prep for doing the NQP changes
japhb pmichaud, OK, thanks, I'll work on other stuff
bacek: yes, sadly. I'm calling in favors just to get this time. :-(
bacek cotto: ok. It compiles.
purl Ship it!
japhb pmichaud, nodnod, cool beans 20:36
cotto bacek, does that mean it's merging time if make test passes? 20:37
bacek cotto: yes
Let's clean all mess later (if any)
make test passed. 20:38
nopaste "bacek" at 114.73.130.183 pasted "Final diff between trunk and pluggable_runcore" (39 lines) at nopaste.snit.ch/17849 20:39
cotto whatever. merge that sucker and let's get on with it! 20:40
bacek shipped 20:41
r41081
dalek rrot: r41081 | bacek++ | trunk (40 files):
Merge pluggable_runcore branch into trunk.
 20:42
cotto awesome. now it's nap time
japhb How do you iterate over a hash in NQP?
bacek is THE MERGE MASTER
japhb In particular, I'm trying to iterate over %VM, the Parrot config hash ...
bacek++ 20:43
20:45 chromatic joined
mikehh ok hittin' the test run 20:46
Whiteknight treed: ping
mikehh: me too
treed Yo.
Whiteknight treed: is parrot building for you again?
NotFound src/runcore/cores.c:1259: error: cast from ‘PMC*’ to ‘unsigned int’ loses precision 20:47
bacek Whiteknight: just add asserts in Parrot_pcc_* functions.
Whiteknight okay 20:48
bacek NotFound: g++?
Whiteknight I've got failures in t/pmc/thread.t
NotFound bacek: yes, in amd64
Whiteknight t/pmc/threads.t
treed Whiteknight: I haven't checked lately.
bacek cotto: Wake up! :)
Whiteknight treed: I think dukeleto fixed some configuration issues 20:49
japhb pmichaud, How do you iterate over a hash in NQP? If it matters, I'm trying to iterate over %VM, the Parrot config hash ... 20:50
dukeleto treed: you should get a warning during Configure.pl now if you have an installed parrot that will conflict with the build process
20:50 contingencyplan joined
Whiteknight t/pmc/threads.t fails with the switch core but looks fine on the slow core 20:51
bacek Whiteknight: 2-3, 7?
Whiteknight bacek: 3 only 20:52
bacek: why arent you back in bed now?
bacek Whiteknight: try add "print ''" after thread.'join'()
Whiteknight: it's too late for bed... 20:53
20:54 darbelo joined
treed dukeleto: Is that what the problem was? 20:54
dalek rrot: r41082 | mikehh++ | trunk (3 files):
fix svn properties
treed I've been able to build Parrot without any problems.
My build issues were on cardinal.
NotFound Do you expect that op_time requires a long long?
treed Where it was failing to build because parrot_config doesn't work. 20:55
See iss #977.
dukeleto treed: the parrot build scripts were not giving proper warning on darwin when an installed parrot would give odd errors during the build, because of the order or included library directories 20:56
treed During which build?
Parrot depends on an installed parrot while building?
dukeleto treed: so my build was failing because it was using an installed parrot during the build
treed I don't think I was having that problem. 20:57
My parrot built fine and passed make test.
dukeleto treed: if you have an installed parrot already with the same version number as the one you are building, during the build process, you will be using the installed parrot instead of the one in your build directory
treed: it looked like a similar issue, but I guess it wasn't
chromatic That should only be a problem when we change bytecode compatibility. 20:58
dukeleto treed: i couldn't build parrot for 2 days until I figured out my installed parrot was borking my build. someone added warnings to the build scripts, but they didn't check for the proper shared library extensions on darwin
bacek chromatic: no. It's not PBC vs PBC. It's .so vs .so 20:59
nopaste "NotFound" at 213.96.228.50 pasted "Fixes after r41802" (36 lines) at nopaste.snit.ch/17850
Whiteknight bacek: that fixed it (but is remarkably hackish) 21:00
chromatic The problem I had was PBC versus PBC.
NotFound Some objection to that fixes?
bacek Whiteknight: nopasted patch? I have no idea about how profiling works... 21:01
treed dukeleto: Ah.
Whiteknight bacek I added print '' after thread.'join'() 21:02
it only fails on the -S core 21:03
bacek Whiteknight: yeah... Some problem with IO flushing. I didn't dig in it.
Whiteknight urg
dalek rrot: r41083 | NotFound++ | trunk/src/runcore/cores.c:
[cage] fix c++ errors, warnings, and cstring freeing
 21:05
Whiteknight this branch did bump my coretest time from ~38s to ~42s 21:07
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41082 - Ubuntu 9.04 amd64 (gcc) 21:12
ttbot Parrot trunk/ r41082 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/83834.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
mikehh now I can try with g++ - NotFound++ 21:13
dukeleto ttbot found "CLOCK_PROF' undeclared" 21:15
Whiteknight: were any coretests added in the branch? 21:20
Whiteknight none that I know of
bacek Anyway, merge commit require close reviewing. I'm not sure that I resolved all conflicts properly. 21:22
Can we switch to git? Pleeeaase. I've lost most of Sunday in merging branches :/ 21:25
dalek kudo: 205733f | moritz++ | build/PARROT_REVISION:
bump PARROT_REVISION to a value later than the pluggable_runcores merge
 21:27
ttbot Parrot trunk/ r41083 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/83849.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41083 - Ubuntu 9.04 amd64 (g++) 21:30
Tene bacek: iirc, chromatic has some serious complaints about git. You might start the conversation with him. 21:32
bacek passing baseball bat to chromatic :)
Tene: he already use it for MBP, btw. 21:33
Tene chromatic: what is your ci alias for git?
chromatic Now it's 'git commit'.
Leto or Schwern suggested 'git commit -a', which wasn't what I wanted for git-svn. 21:34
Provided that the default workflow for git is easy to explain (and I think it can be), I have no technical objections to using Git for Parrot.
I wouldn't consider migrating until after 2.0 at the earliest though. 21:35
bacek Hooray!
Coke dukeleto: "parrot is faster than perl 5 for many things". Can you name one?
Whiteknight I'm happy to use git if I can learn how to use it adequately 21:36
nopaste "bacek" at 114.73.130.183 pasted "Fast parrot for Coke++ :)" (31 lines) at nopaste.snit.ch/17851
mikehh rakudo (09b9540) builds on parrot r41083 - make test / make spectest (up to r28195) PASS - Ubuntu 9.04 amd64 (g++) 21:37
dukeleto coke: i have some euler_bench benchmarks to back that up in github.com/notbenh/euler_bench/tree/master
bacek Whiteknight: just read "Git book"
dukeleto progit.org is really good
chromatic You really do have to understand how Git tracks content to appreciate it.
Coke bacek: given that those two things generate different output, I'm hesitant to believe you. =-)
dukeleto i am more than willing to help everyone learning git. git-svn is so much worse than just plain git :)
bacek Coke: Bah! Off by one :) 21:38
Tene also volunteers.
Coke bacek: also, counting is a pretty lame comparison. =-)
Whiteknight bacek: I've read it. It's full of all sorts of stuff that I don't care about
Coke I know of no HLL's that can deal with raw nums.
but ok, that's one thing. =-) 21:39
dukeleto i would highly suggest for everyone to read the first commit to git.git by Linus. it conveys the core structure of git and is heavily commented with elucidating design decisions
bacek Whiteknight: than just "google://git magic". It was very good set of articles with this title.
Whiteknight I don't care anything about the philosophy or design decisions that went into the program. I only care about doing the equivalent of svn checkout, svn commit, svn update and svn merge 21:40
chromatic Whiteknight, the realization that made Git click for me is how it uses SHA-1 to identify individual components within a commit as well as commits themselves.
NotFound If we switch to git, I don't care about design decision or philosophy, just need no know how to use it.
Coke cotto: 1.5s vs. 4m15s ... you got the original to run in under two second?!?!?! =-)
Whiteknight NotFound: agreed
dukeleto git keeps track of "blobs" of content, which it represents by sha1's. repeated blobs are stored as references to the same sha1, which is why git is so damn space-efficient 21:41
Coke are folks still having SVN trouble?
moritz NotFound: thing is, at some point you have to understand the design to work with git efficiently
Coke (the ssl cert was updated today)
chromatic I don't care about space efficiency, but a file with identical contents is the same no matter what commit graph you use to create it.
Whiteknight Coke: we haven't tried another branch merge since last time
dukeleto git gc is the command to allow git to rearrange it's internals for faster access
moritz NotFound: I thought I could avoid it, but I couldn't
dukeleto git repack as well 21:42
Coke bacek: why do your commit messages have the "conflicts" section?
if there are conflicts, don't merge, if you fixed them, don't leave them in the commit message... 21:43
bacek Coke: just to be sure, that I can review commit after.
NotFound moritz: if that is true then my vote is against the switch
bacek Coke: and they are in branches only.
Whiteknight I'm with NotFound. There are only a handful of operations that I want to be able to do, and do without worry 21:44
Coke (branches only) fair enough
moritz well, you can do a few operations without understanding the architecture
chromatic Cheap and easy branching and merging with Git finally convinced me.
Tene NotFound: Please note that moritz included "efficiently" 21:45
moritz: Everyone at my office uses git regularly, and only two of us really understand gits internals.
NotFound Please don't use buzzwords }:)
dukeleto coke: i am pretty sure that the first few, very simple euler project problems in the euler_bench repo all have parrot above perl5. i can do a test run and send you the results if you like
Tene So I very much disagree that you need to understand it to use it competently.
Coke dukeleto: as long as you measured them, I believe you. 21:46
NotFound I'm not interested in doing bisections or having one hundred branchs in parallel, for example.
Coke Working in partcl has made me very suspicious of speed claims. =-)
dukeleto coke: that was months ago. parrot is probably even faster now :)
bacek morning duties and $dayjob time
See you!
dukeleto coke: there is a lot of slowness in being an HLL still. rakudo is way slower than ruby still. but parrot itself is pretty fast 21:47
Coke dukeleto: ... parrot got much slower after recent branch merges.
dukeleto: Yes, but that doesn't help.
since most of the final comparisons are going to be HLL's versus other HLLs.
dukeleto coke: this is why we are trying to hook euler_bench up to the parrot repo, so we can see performance changes with each merge/etc
Coke if we have all this overhead to make FOO on parrot work like FOO, then it doesn't matter that parrot itself is faster.
NotFound Easy solution: use a language that doesn't have a non-parrot version for compraisons X-) 21:48
Coke (except insofar as it makes foo on parrot less slow)
dukeleto: relative speed tracking ++, though. 21:49
dukeleto coke: there are erlang solutions in euler_bench
Coke wonders if he can run the profiler on feather (linux) and somehow get a pretty cachegrind picture back to his windows or mac boxes. 21:50
dukeleto it should be possible to install kde libs on darwin, right ?
Coke ups parrot and kicks off another spec test run. 21:51
dukeleto euler_bench, for example, would be good at telling us if parrot trunk is much slower than parrot 1.5.0 21:53
mikehh Coke: we seem to be getting segfaults again after the latest merge - in make test in partcl 21:59
Coke mikehh: P(*#&$(@*#&$ 22:00
mikehh: could you do me a favor and open tickets for them in partcl?
partcl?
purl partcl is tcl on parrot or code.google.com/p/partcl
Coke (then I can grab the backtraces and open parrot tickets for them and assign them to the (*#&@$# commiters that (*&#$# merged them. =-) 22:01
Coke is glad he didn't post the "hey, things are getting better" post to partcl's blog.
22:03 tetragon joined
chromatic The universe always punishes *you* for hubris with irony. 22:03
Whiteknight is leaving. Laterz
dalek rrot: r41084 | NotFound++ | trunk/src/runcore/cores.c:
[cage] some more cstring free fixes
 22:06
22:07 theory joined
dalek rrot: r41085 | tene++ | trunk/ext/SQLite3 (3 files):
Minor ext/SQLite3 fixes
 22:13
nopaste "darbelo" at 190.3.155.110 pasted "[PATCH] Kill another strstart use." (21 lines) at nopaste.snit.ch/17852 22:14
Coke doesn't hear back from mikehh++ so kicks off a spectest of his own.
darbelo can someone on a JIT-enable platform test nopaste.snit.ch/17852 for sanity. 22:15
jrtayloriv chromatic, what is your opinion on the names Var_Size_Obj_Pools and Fixed_Size_Obj_Pools, as a replacement for Small_Obj_Pools and Memory_Pools respectively? I ran the names by whiteknight a day or two ago, and he seemed to like them, but I wanted to get more opinions, and you seem to have done a lot with the GC system. 22:16
I'm trying to come up with a consistent naming scheme for things in the GC system, so that it is easier to see what is going on. 22:17
Coke wow. while.test has slowed down from 50s (chromatic's recent fixes) to 1m10s, and now ends with a segfault.
I think we should add "run partcl's spectest" to the pre-merge checklist. :| 22:18
jrtayloriv chromatic, oops -- var_sized for Memory and fixed_size for small_obj ... you know what I meant :)
Coke hesitantly kicks off a full run. :|
chromatic I find Variable_sized_pool and Fixed_size_pool clearer still. 22:22
nopaste "darbelo" at 190.3.155.110 pasted "[PATCH] Kill another strstart use (improved)." (41 lines) at nopaste.snit.ch/17853 22:23
NotFound There is some reason to Eval extends Sub ?
darbelo Actually it would be better for people with JIT to test test nopaste.snit.ch/17853 which make that same change to another file as well. 22:24
jrtayloriv chromatic, Ok -- the reason I chose var is for long function names like initialize_var_size_obj_pools vs. initialize_variable_size_obj_pools -- so you would just remove the "obj" and change it to use the full word "variable"? 22:25
chromatic Yes.
jrtayloriv ok, thanks.
chromatic I don't know that obj adds any clarity. 22:26
jrtayloriv Yes, it's kind of unnecessary. "Objects" is about is uninformative as you can get.
chromatic Anyone working that deep in the GC should know what a pool contains already. The important part is what's in the pool. 22:27
Hm, 15% slower in the past day. 22:28
Hang on, that's not right. 22:29
3% slower. That's better. Not okay, but better. 22:30
We're running the garbage collector more often. 22:31
25.4% more often. There's the slowdown.
Parrot_gc_mark gets called more often, but is that the problem or a symptom? 22:33
Hm. 22:36
Tene yay, segfault when trying to wrap sqlite! The segfault is in sqlite code, so likely not a parrot issue. 22:37
dukeleto tene: passing an invalid pointer? 22:42
22:42 rg joined
ttbot Parrot trunk/ r41085 cygwin-thread-multi-64int make error tt.ro.vutbr.cz/file/cmdout/83965.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 22:46
NotFound partcl is having segfaults at Eval.destroy 22:47
mikehh Coke: had to take the dog out - a bit better at r41085 - not as many failures in make test
NotFound++ 22:49
NotFound mikehh: Do you have an idea? 22:55
mikehh NotFound: looking 22:56
there has been no recent change in eval.c that I can see
last changed by you at r40760 22:57
japhb OK, I'm clearly going blind. Why are other denizens of compilers/ being installed, but not compilers/json/? As far as I can tell, it's mentioned in the same ways in Makefile and MANIFEST as, for example, pge. But there's clearly something missing, because it's clearly not installed ... 23:00
dukeleto japhb: is it in MANIFEST.generated ?
that is where installed files live 23:01
japhb yes
dukeleto or the locations of them, anyway
japhb erm, but pge isn't.
Hum.
dukeleto japhb: perhaps the install script is filtering them out for some reason 23:02
japhb oh, nm
WTF? compilers/nqp and compilers/json are mentioned in MANIFEST.generated, but not pge or tge 23:03
This is still not making any sense to me
I can't see anything in tools/dev/install{_dev,}_files.pl that would filter json out 23:04
moderator www.parrot.org | Add test after fixing bugs after context_pmc3 merge | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON 23:05
japhb AH, wait 23:05
default for 'packages' is hardcoded. Searching ... 23:06
OK, I think I see it. /me tries a fudging 23:07
darbelo Hm. Is pirc functional and/or tested? 23:10
japhb darbelo, Last I heard it was unfinished, but I have not checked status in a month or two 23:13
dalek rrot: r41086 | cotto++ | branches/pluggable_runcore:
pluggable_runcore has been merged so delete the branch
darbelo I just spotted some ->strstart there, was wondering if it was worth diving in for a fix. 23:14
jrtayloriv chromatic, any reason for me not to delete this paragraph from docs/memory_internals.pod? -- pastebin.com/d5400f93e 23:15
chromatic Go ahead.
jrtayloriv cool, thanks
dukeleto darbelo: there is a git repo for pirc 23:16
darbelo: github, that is
darbelo How does it differ from compilers/pirc/ in the parrot tree?
dukeleto darbelo: take a look github.com/bacek/pir/tree/master 23:18
Tene japhb: if you intend to get compilers/json/ to work as an installed language, you'll need to lowercase JSON.pbc to json.pbc
japhb Tene, step one is even getting the damn file copied into place during installation in the first place 23:19
or are you saying that install_dev_files.pl will ignore uppercased files? 'cause that would kinda suck. 23:20
Tene japhb: I have no idea how the install process works. I tried to work it out for json earlier, but failed.
japhb Hmmm, uppercase files are installed for PCT, PGE, and TGE, so that can't be it
Tene japhb: the issue is that HLL stuff is currently broken with names that contain uppercase letters, if you want to use them in the standard way 23:21
japhb Tene, nodnod. We should probably improve that.
Tene Yes, we should, and there's a ticket, but nobody cares enough yet.
there are a few things that do lowercase everything, like the .HLL directive, and a few things that don't, so there ends up being a mismatch. 23:22
japhb
.oO( Dang it, three hours of precious, precious hacking time *wasted* on this damn install problem ... )
Tene japhb: I would personally just stick something in runtime/parrot/languages/json/ 23:23
japhb Tene, it has to be fixed at some point. And since I'm working on an install tool, I bloody well need to understand how our installation is broken. ;-)
Tene japhb: yes, but from what I understand of what the different directories are for, it probably should be in languages/ anyway 23:24
but, yes, you're certainly right. 23:25
japhb Tene, things under compilers/ get moved to languages/ during install.
darbelo dukeleto: That's not the one I meant :) the pirc in "compilers/pirc/" is the (unfinished) IMCC replacement. 23:26
Tene japhb: looks like the difference between PGE and json is in MANIFEST
dukeleto darbelo: i thought that was what that was 23:27
jrtayloriv chromatic, As far as struct Arenas, I was thinking about renaming it to Memory_Pools, since that's what it holds. Since I'm renaming Memory_Pool to Var_Size_Pool, there should be no confusion (and Memory_Pools is in the plural anyway). The pools actually do contain arenas, so the Small_Object_Arenas would be still be called Fixed_Size_Arenas, etc. Does that make sense to you as well?
japhb Tene, nopaste? I thought I had (mentally) reconciled all the differences there ...
Tene japhb: if your model disagrees with mine, trust yours.
japhb trying a new build right now
chromatic jrtayloriv, I can't visualize that for some reason. 23:28
Lack of concentration on my part, I'm sure.
jrtayloriv chromatic, Would you like me to rephrase it, or is now just not a good time?
japhb HAH! OK, got the damn file installed. Now to deal with uppercase/lowercase problem ... 23:29
Tene, where is the problem? (What file do I need to try to hack?) 23:30
chromatic Now's apparently not a good time... but the words are all pretty confusing.
jrtayloriv ok, no problem.
Tene japhb: there are several different places that do it, and I can't remember them all. 23:31
japhb Tene, tsk tsk. You're supposed to have perfect recall! ;-)
Tene .HLL is the big one, I think compreg might do it, you'll need to check HLLCompiler...
load_language, maybe 23:32
I don't think so, but maybe.
japhb oh dear. That's a lot of places for the same bug. OK, searching
Tene japhb: it was part of the design, originally, and then we tried to use it and discovered that it sucks. 23:33
japhb heh
Tene japhb: also, if you fix it, any HLL that uses a .HLL with uppercase letters might break.
I think TCL used to, don't remember if I changed it or not.
rakudo did until I fixed it.
japhb Tene, I was going to have a "1. Try exact case match. 2. If fail, try lowercase." 23:34
Tene I don't *think* pynie does...
japhb: oh. That won't quite work. Even things like namespaces are involved.
japhb oh, frack.
Tene if I say ".HLL 'FOO'", it puts things in the 'foo' root namespace. 23:35
I think.
Like I said, I don't quite remember exactly where the few places that lowercased things are.
but the big issue comes down to:
japhb Most calls to compreg use mixed case, not lowercase
Tene If I want to eval something in the 'JSON' language, I need to 1) load_language 'JSON', which will look for languages/JSON/JSON.pbc 23:36
which won't work right now anyway, because it's in an lcase dir
and then the 'eval' function needs to know to call compreg with a lowercased argument 23:37
which is bad, because then when we fix it, eval and inter-hll library loading will break.
So I don't do it.
japhb bleah 23:38
Tene see why I said "just make everything lowercase"?
japhb Yes, I do.
Tene :)
japhb But we need to bite the bullet at some point, and this kind of thing is why we declared the whole mess 'experimental'. 23:39
Tene trac.parrot.org/parrot/ticket/777
NotFound If we convert all to lowercase, later we can fix the issues without risk of breaking something
nopaste "dukeleto" at 69.64.235.54 pasted "parrot trunk build failure related to hires timers on darwin-x86" (70 lines) at nopaste.snit.ch/17854
dukeleto parrot trunk currently does not compile for me 23:40
Tene I'm more concerned about fixing trac.parrot.org/parrot/ticket/150 23:41
NotFound Tene: did you see the patch I nopasted yesterday?
Tene NotFound: what patch about what? 23:42
(that is to say, probably not)
NotFound Tene: one moment....
darbelo dukeleto: It looks like darwin doesn't have a a clock_gettime function. 23:43
dukeleto makes a sad face
darbelo That *sucks*.
23:43 ilbot2 joined
moderator www.parrot.org | Add test after fixing bugs after context_pmc3 merge | Improve test coverage for FixedPMCArray and NameSpace / Fix Segfaults for Coke / Port Tests to PIR / Merge Stable Branches for 1.6 SOON
NotFound Tene: this one 23:43
purl this one is bugged too now
Tene NotFound: I didn't see that. Does it work?
darbelo dukeleto: clock_gettime is needed by the profiling runcore, but I don't know of any ways to not build it. You'll have to ask cotto about this one. 23:44
NotFound Tene: at least it doesn't break parrot, but I don't checked the ticket, was unable to find it
Tene NotFound: if it works on those examples, then yes, that should be good to commit. Ideally, we need a way to register PMCs in a specific HLL, but this is a good workaround for now. 23:45
dukeleto darbelo: perhaps gettimeofday() should be used on darwin ? 23:46
NotFound Tene: I'll try it tomorrow, now is too late for me.
Tene where "for now" means "until there's a demand for that"
japhb Tene, When I look in parrot_install/lib/1.5.0-devel/languages/ , all of the directories are lowercase, and all the .pir files are uppercase *except* nqp.pir and parrot.pir. Am I correct in assuming that this means only nqp and parrot work with load_language? 23:47
NotFound Anyway, the way to register pmc must be independent on the context where the load_bytecode is executed
darbelo dukeleto: I guess you could fake it that way, yes. I'll have a look. 23:48
dukeleto darbelo: it is only 1 microsecond ticks, but that is what Devel::NYTProf2 does
Tene japhb: I haven't confirmed that nqp works with load_language, but I'd be shocked if the others did, so you're probably correct.
dukeleto darbelo: thanks, I would like to compile parrot :) i may work on making the profiling stuff optional in Configure.pl 23:49
japhb gets past one block only to hit another ... 23:50
"load_bytecode" couldn't find file 'compilers/json/JSON/grammar.pbc' 23:51
Which is because that didn't get switched to languages/
Tene japhb: I suspect that JSON hasn't been worked on in ages, iirc.
japhb Tene, not surprised
Tene Oh, wow, there's an apparently-working patch for tt#757, which I was blocking on to make threading work in rakudo... 23:52
I should attempt to review it.
... after more sqlite stuff. :)
dukeleto darbelo: NYTProf.xs in the Devel::NYTProf code has a lot of good links with explanations about gettimeofday/get_clocktime 23:55
japhb Tene, looks like asciiville join #perl6 a bit less than an hour ago ... he might be able to explain why he didn't use the existing SQLite code in Parrot ... 23:57
mikehh Coke: I am getting different make test results when I rerun the test 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!