Vision for 2.0: Production Users | Priority for 1.8: Testing Sprint | Priority for this week: close RT tickets | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 20 November 2009.
04:52 davidfetter joined 04:54 rin1024 joined 05:28 davidfetter left 12:27 bluescreen joined 12:56 davidfetter joined
japhb DONE: 16:48
* Keep up with pmichaud's NQP-rx improvements (and push for more :-)
* Keep up (mostly) with fperrad's bug reports and metadata updates
* Various Glue.pir improvements
* A few more tests
WIP:
* Big refactoring of main "brains" to OO classes
* Document refactored code
* About 50% done with planned refactors before next feature push 16:49
MAD PROPZ:
* fperrad++ # Copious metadata updates, suggestions, and bug reports
* pmichaud++ # NQP-rx feature-o-rama
* dukeleto++ # Initial pass at qx() tests
NEXT UP:
* More of the big refactoring. I'm currently thinking the depsolver next.
BLOCKERS:
* I think I've got enough unblocked tasks to use all my tuits this week.
* By next week IWBNI NQP-rx had full hash constructor syntax; there are several subprojects that are blocked on this feature.
EOR
Tene I seem to be recovering enough from being sick to do some work again. Poked a little bit at rakudo-ng. KTHXBAI 16:55
16:56 Util joined
Util has nothing to report, will miss the meeting today, and has negative tuits until Monday. 16:56
17:26 NotFound joined 17:51 pmichaud joined 18:04 darbelo joined
cotto_work # Done: 18:09
* Continued converting pprof2cg to nqp.
* npq syntax is nicer than perl syntax. For string processing and efficiency, not so much.
* It's still incomplete but it's way slower than the perl version (9:00 vs 1:30 for same input)
* Note to self: there may be some sort of profiling tool out there that can be used to narrow the gap.
# Will do:
* Eat turkey.
* Finish pprog2cg port and be even more disappointed about how slow it is.
* Start profiling that sucker.
# Blockers: 18:10
* Turkey.
eor
18:12 whiteknight joined
NotFound What I did: 18:13
- parot
* A few fixes and test coverage improvements.
* Improve X11 library search in Xlib example module.
- Winxed
* Big refactor: the compiler written in C++ is now a 'stage 0' compiler,
and the compler driver is now a winxed program, able to be compiled
to .pbc and pbc_to_exe'd. This clears the path towards a self-hosting
compiler.
* Backward incompatible syntax change: now the new operators uses
parentheses for his arguments, and can't be omitted for winxed classes.
* Lots of improvements in parser example, the future 'stage 1' compiler.
Now is able to generate code for some simple programs, and allow
float (N registers) variables, which the stage 0 doesn't.
What I will do:
* No fixed plan.
EOR
whiteknight WHAT I DID: 18:15
(pla) some miscellaneous tweaks and improvements to the test suite
(matrixy) pass more tests, fixes from the messy merge.
(matrixy) Improved and reorganized test suite
(parrot) started work on a new "mystery project". Details to come eventually.
WHAT I WILL DO:
* More cleanup work on Matrixy and Parrot-Linear-Algebra
* I have some ideas for improvements to nqpTAP that I want to try 18:16
* Work on the :call_sig stuff more
* Work on my mystery project
WHAT I AM BLOCKING ON:
* Ongoing computer problems
EOR
18:21 mikehh joined 18:23 kj joined
mikehh What I did in the last week: 18:26
* building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
* fixing tests
* checking skipped test for passes or able to TODO
What I intend to do in the next week:
* testing and fixing
* continue working on checking skipped tests
.eor
18:32 Coke joined
Tene MEETING TIME 18:34
cotto_work HELLO
NotFound hola
mikehh hi there
Tene It's many-people-are-absent day today, so... anyone have questions or reports to give?
Turkey to share? 18:35
Coke Belated report: pmichaud started on partcl-nqp; hacking on that.
whiteknight hello 18:36
cotto_work This could be the shortest #ps ever.
Tene I seem to be alive again, and I've got a lot of spare time during the long weekend, so if anyone has any tasks they'd like me to work on, please harass me. 18:37
whiteknight Who's driving this train? 18:38
Tene Me!
whiteknight go for it
Tene Well, I did. Everyone has reported, nobody has questions... 18:39
Am I missing anything?
Coke priorities for the next week? I vote "turkey"
darbelo Roadmap review?
whiteknight more optimizing 18:40
Tene Oh, right, there actual plans. Man, I'm an incompetent leader today.
Tene reads topic link
cotto_work Could you re-set that? It's blank for me.
moderator Vision for 2.0: Production Users | Priority for 1.8: Testing Sprint | Priority for this week: close RT tickets | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 18:40
cotto_work Thanks 18:41
Tene okay, there's a bunch of HLL items on the roadmap... there's been no progress on those recently.
NotFound Looks like "close RT tikcets" is no longer a priority ;)
Coke (thanks to everyone who worked on that!)
Tene I didn't see japhb around... anyone else want to talk about seed libraries?
parrot_debugger? 18:42
Priorities? 18:43
We've got one vote for turkey, and one vote for optimization.
NotFound I had plans to take some looks on parrot_debugger after pcc refactor, but Winxed has distracted me. 18:44
mikehh kid51++ removed a load of RT references in parrot
cotto_work I like optimization. 18:45
whiteknight optimization++
cotto_work -Oturkey
Tene Oh, right, 1.8 was released, so we're looking at 1.9 milestones too.
Who's working on bytecode tools?
mikehh but don't forget the big caveat
darbelo A too optimized turkey can outrun you? 18:46
Tene How did the testing sprint mentioned in the topic go? Do we have better tests?
mikehh Util I think 18:47
Tene There's a documentation sprint on the roadmap... is there a list of underdocumented places? 18:48
mikehh a couple but there did not seem to be that much enthuasiam
whiteknight a list of documents needing improvement would be good
allison the tasklist is coming together on trac.parrot.org/parrot/wiki/DocsTasklist
whiteknight (don't have one to my knowledge)
mikehh darbelo: how about get it workin' first
Tene turns the meeting over to allison. 18:49
NotFound A list of documents that doesn't need improvement will be a lot shorter.
allison specific tasks are easier to pick off than "improve X file" 18:50
that is, pretty much any documentation file could be improved in some way
mikehh a prioritizeed list perhaps
whiteknight test all example cod
code
Tene Coke said that the AST documentation was sorely lacking.
I'm not quite sure what's missing there. 18:51
Coke (all example code) it's already mostly tested.
allison start with a goal, for 2.0, "improve user documentation"
mikehh some examples don't work - need fixin'
allison we're getting a lot of reports lately of trouble with the "getting started" tutorials
Coke Tene: something for people who are starting from scratch.
allison: exactly. =-)
allison right, examples that don't work
whiteknight allison: yes, and the make_language_shell.pl utility 18:52
NotFound Someone is working on, or using, SDL?
allison whiteknight: yup
whiteknight Notfound: SDL?
NotFound whiteknight: runtime/parrot/library/SDL 18:53
Tene Is there an index of the various "getting started" tutorials scattered around the internet?
allison Tene: no, and that would be a good place to start
Tene: pulling them into one place inside the Parrot repository 18:54
Tene: (at least where we can)
Tene That's always been one of my worries about docs out on wikis, etc.
NotFound We can list only the ones we know someone is trying to keep up to date.
Tene mk_language_shell is rather out of date, I believe, and really needs to be fixed.
allison Tene: supposedly it can be replaced by fperrad's tool, but for backward compatibility we still need mk_language_shell to work for now 18:55
Coke and once it's fixed, it probably needs to be updatd to nqp-rx.
allison do we have a ticket for that?
pmichaud (back) 18:56
allison okay, so need a ticket for mk_language_shell 18:57
Tene I'd love it if we had a tool that generates configs that support 'make install' and includes plumage metadata.
NotFound Also a tool that checks plumage metadata will be helpful. 18:58
allison Tene: that'd be a good extension to the language shell generators
pmichaud my intent is to create a new language shell generator in nqp. Not sure when it will happen, but should be before the 1.9 release.
(since the procedure for creating a language in nqp-rx is somewhat different from the previous language shell generators) 18:59
allison we may be looking at a replacement then. 19:00
whiteknight is that covered under the deprecation policy?
allison depends on if you consider utility scripts part of the public interface
pmichaud the nqp-rx tool will likely live (initially) in ext/nqp-rx 19:01
it can of course be moved somewhere else :-)
allison for 2.0 it's fine if mk_language_shell only works on the old NQP, but it should work
pmichaud q1q
NotFound I think that programs intended only for interactive usage must not be under deprecation policy. 19:02
allison I'd agree they aren't part of the official deprecation policy 19:03
but, they also shouldn't lie around broken
so, either work or be removed
NotFound Provided that no one will make things like adding an option called --help that does an rm -rf, of course ;)
allison :)
on roadmap review: what are the chances of calling the hll-interop done by 2.0? 19:04
pmichaud allison: good
I've made a lot of progress on it this week
allison excellent
prune c data structures we've made good progress, and I'd be willing to drop it off "roadmap" and down into "ongoing cleanup" 19:05
Tene I plan to do a lot of work on hll interop as well.
pmichaud also, hll-interop documentation is a deliverable for my hague grant :)
allison documentation sprint has been going, I've seen good progress on it
pmichaud: also good
the debugger documentation looks like a good addition to the docs tasklist 19:06
ENOdukeleto for an update on his task 19:07
work on that task
okay, questions
pmichaud?
pmichaud not a question so much as a pointer to a very interesting item 19:09
last week chromatic did some analysis of compilation using pct
the thread is at
irclog.perlgeek.de/parrot/2009-11-20#i_1751189 # for those who wish to go back and read
but the line I wish to point out
chromatic 88.81% of the execution time is *marking* Capture.
the takeaway from the discussion was that GC is killing us 19:10
also, it's not the creation of short-lived objects that is the time eater
it's the long-lived ones that hurt
in particular, this run resulted in 3.2 million PMCs being created due to subroutine/method calls
allison we do have an intensely primitive GC at the moment 19:11
japhb bak ... I see some plumage highlights in the backlog, let me know if there are any outstanding questions
pmichaud but those 3.2 million PMCs only accounted for about 30K marks
allison sounds like the GC refactor just got bumped up in priority
pmichaud the 24K Context PMCs (the point of the compilation) resulted in 500K marks
19:11 dukeleto joined
dukeleto is late but here. for a bit. 19:11
pmichaud in short, we at one time were concerned that switching contexts to PMCs would hurt GC pressure (more) 19:12
NotFound BTW I think that currently we have a problem instantiating PMC.
pmichaud that appears to not be the case -- they're short-lived, and the GC pressure only comes when we do a gc run, and then what matters is the number of live contexts, not the number of contexts that had been created
but gc runs on long-lived data structures are really problematic
allison dukeleto: just wanted a quick update on parrot_debugger documentation, what's done and still needs to be done. You can add it to trac.parrot.org/parrot/wiki/DocsTasklist if that's better
NotFound The PMC are not instnatiated directly, a pmcproxy is created in the cases I checked.
pmichaud (and 24K PMCs is not really a lot of PMCs in the overall scheme of things.) 19:13
allison the pmcproxies do need to go
NotFound That may mean millions of uneeded proxies for simple tasks.
allison NotFound: actually, only one proxy is created for each PMC type
NotFound: so, no more than 100 total 19:14
pmichaud (at one time there was a bug that caused multiple proxies to be created for various PMC types... I cleared those up late spring 2009)
allison but, they're only actually used during subclassing operations, so, could be left off the rest of the time
NotFound allison: one proxy for type, one proxy instance for object.
pmichaud NotFound++ is correct that every instance of a class also gets a proxy instance 19:15
(iiuc)
NotFound No, I talk about plain and simple parrot PMC
allison should be one proxy for Class and one for Object
pmichaud oh, that would be wrong then.
NotFound Very wrong.
I looked at tapir2.ro.vutbr.cz/cover/cover-resu...n-pmc.html 19:16
pmichaud anyway, back to my "question" (which got hijacked) -- I just wanted to point out that chromatic's analysis indicates that 4/5ths of compiler execution is spent in GC. 19:17
NotFound The init_pmc has no coverage on value null, but the test must exercise it.
It doesn't, because is instantiated via pmcproxy
pmichaud I'm hoping we can dedicate some effort to improve that.
(or at least verify that the 88% figure is erroneous somehow) 19:18
eoq
NotFound pmichaud: well, if we are creating a lot of unneeded pmc, stop creating them will mean a lot less pressure on the gc.
pmichaud NotFound: you missed my point.
allison NotFound: the GC is slow, there's no question about that 19:19
pmichaud the point is not how many pmcs are created
allison and, yes this is an important priority
pmichaud the point is that 24K pmcs were sufficient to completely bog down processing, and 24K is not a large number.
allison it's helpful to have more details on where the problem in PCT is 19:20
pmichaud it's not PCT
I guarantee that PCT isn't the issue.
the pmcs in question are just the parse, PAST, and POST nodes 19:21
allison well, that's what I mean, "what is it that causes the compiler to be slow?" is a question we've been asking for a while now
pmichaud ...unless you're suggesting we shouldn't be using trees :)
whiteknight it's not just GC being slow. Specifically it's GC mark
allison if it's GC, at least we have something concrete to fix 19:22
whiteknight that's the part that's hard to avoid
pmichaud if chromatic++'s analysis is correct, what is causing the compiler to be slow is the fact that a long-lived data structure (the parse and ast trees) causes gc to be slow
whiteknight we can be judicious with how much we sweep, but we need to acurately mark things
allison this argues for generational GC
whiteknight my conclusion exactly
allison that is, we shouldn't be sweeping those long-lived PMCs so often
certainly not on every mark run 19:23
pmichaud and although we can perhaps do things to improve the data structure a bit, the point is that trees with a total of 24K nodes isn't all that big for any sort of program
whiteknight It's not sweeping, it's marking that's the problem
according to chromatic (and I need to verify) ~80% of execution time was spent in Capture.mark
pmichaud yes, verification of the result would also be helpful.
whiteknight if we marked the Capture PMCs less, we would also have to mark fewer of their children. A lot of stable things could be grandfathered in 19:24
pmichaud I have trouble believing it, myself, but I trust chromatic more than my own intuition on this point :)
whiteknight increasing pool size yet again might reduce the number of mark+sweep phases we need to trigger for basic operation
pmichaud fwiw, this particular profile showed 92 GC runs 19:25
anyway, I'll leave it at that and hope it prompts some conversation/design work :)
allison sounds like something we can get excited about
pmichaud speeding up compilation by a factor of 4 would get me excited, yes :) 19:26
heck, even a factor of 2 would be nice :)
allison indeed :)
any other questions?
alright, for those in turkey territory, enjoy the festivities, and the rest of us, have a good week! 19:27
japhb oh, for anyone still wondering about the plumage + mk_language_shell stuff,
fperrad has been doing a lot of work on autogenerating plumage infor and setting up project shells. 19:28
Tene japhb: link about that?
japhb Also, I have it as a task item for Plumage (during all this refactoring) to write a stronger verifier for plumage metadata. One that can eventually be considered canonical.
Tene, sorry, I only know about it because he's been talking a lot about it in his numerous personal emails this last week. 19:29
Tene Ah. :)
I look forward to seeing it.
japhb (He's pounding on Plumage pretty hard, finding lots of issues.)
cotto_work I'm verifying that mark number. It should be ready soon.
japhb I think a lot of it is checked in to the parrot repo, just not "advertised" well.
Anyone else have any plumage-related questions for me? I've got to run again pretty soon. 19:30
Also, Allison, we need to pull in the discussion from last week about API docs into DocsTasklist. If you don't get to it by this afternoon, let me know, and I'll try to throw some tuits at it.
(summarizing that discussion to the wiki page, I mean) 19:31
allison japhb: ok, thanks, yes, that would be helpful 19:32
japhb allison: will try
OK, I'll assume no more plumage questions, anyone ask me on #parrot if you think of something, I'll backlog there. 19:33
afk
19:44 PacoLinux left
cotto_work The meeting seems to have fizzled out. 19:49
Tene 12:27 < allison> alright, for those in turkey territory, enjoy the festivities, and the rest of us, have a good week! 19:50
cotto_work oh
gg then
19:51 NotFound left 19:52 pmichaud left 20:43 bluescreen joined 20:52 Coke left 21:41 simcop2387 joined 21:42 darbelo left 23:24 davidfetter joined 23:44 mariano joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!