"Tuesday at 20:30 UTC"
Set by moderator on 25 June 2010.
03:29 contingencyplan joined 05:14 cotto joined 07:30 tcurtis joined 11:24 contingencyplan joined 12:13 bluescreen joined 13:04 mikehh joined 17:09 tcurtis joined 18:08 eternaleye joined 18:14 NotFound joined 18:58 ash_ joined 19:10 khairul joined 19:31 chromatic joined
chromatic I worked on the new STRING API for Rakudo, but it's no performance improvement as far as I can see. 19:32
I will... do not much, as I am moving offices this week.
19:34 wknight8111_ joined 19:42 Chandon joined
tcurtis What I did: 19:59
* Implemented min_depth and descend_until options for Tree::Pattern.transform.
- Wrote tests and docs for this.
* Updated some of the docs for my GSoC project.
* Worked on more constant folding for PIRATE.
* Blog post: 20:00
- parrot.org/content/seven-days-pirat...rn-hacking
* Fixed some bugs in Tree::Pattern.
* Wrote a tail-call elimination optimization for the simple case where there's a "return" statement.
- Doesn't work because Tree::Transformer doesn't yet traverse attributes, so my top priority is to add traversal of some attributes.
- I would prefer to not add traversal of all attributes because that would require some cycle-detection logic that would complicate things a bit and require modifying the API.
What I will do:
* Implement traversal of at least some attributes.
* Get the tail-call optimization working.
* Continue to work on optimizations for PIRATE.
* Continue to work on docs.
* Possibly make Tree::Transformer no longer derive from Tree::Walker.
- It defines its own versions of the Tree::Walker multi-subs anyway.
* Other refactoring.
* Improve tests.
* Another blog post.
eor.
q1q
NotFound What I did: 20:01
-parrot
* Deprecated is_tty methods in favour of isatty
* Added function Parrot_dlsym_str
* Some more PMC tests
-winxed
* Heredocs
* Simplify sub params handling
* More tailcall optimization
* Evaluate some predefs at compile time when arguments are const
* Some fixes and improvements in example Mysql
* Minor fixes and cleaning
What I will do:
No plan
EOR
particle reminder: next week is mid-terms for gsoc. students and mentors, get your reports in
20:13 plobsing_work joined
plobsing_work What I Did: 20:14
* minor fixes on dynop_mapping
What I Plan:
* get testing on dynop_mapping (more platforms, HLLs)
* create PackfileBytecode pmc (PackfileRawSegment no longer valid for bytecode segments)
* use PackfileBytecode pmc to fix make_hello_pbc.pir example
Blockers:
* life 20:15
EOR
20:16 darbelo joined
cotto_work .#did: 20:20
- not much (4th of July FTW)
#will do:
- finish linear scan register allocator in PIRATE
- deprecation policy work
- lots of other random stuff
#eor
Chandon Done:
-gsoc_threads
* Got alarms and timers working.
* Implemented version of pre-emptive green thread scheduling that is both wrong *and* broken.
Will do:
END
ash_ What I Did: 20:21
* Started wider testing of NCI updates
* Found and fixed a pointer related bug in my NCI changes
What I Plan:
* Start work on a proof of concept llvm-ir run core by doing some basic translation of bytecode to llvm-ir
Blockers:
* Understanding parrot bytecode
END
20:22 eternaleye_ joined
khairul did: 20:22
.finished up instrumenting gc.
.added tests for EventDispatcher.
.added tests for InstrumentGC.
.initial cut of InstrumentVtable.
.blog post @ parrot.mangkok.com/?p=122
will do:
.finish up InstrumentVtable.
.add support for methods.
.start on usage documentation.
eor
20:23 bubaflub joined
darbelo DONE 20:24
- Freeze/thaw support.
- Added some documentation.
- Hated the packfile code.
TODO
- Get the transcoding issues sorted out.
- Add tests.
EOR.
Util ## Done: 20:27
* Nothing material
# Plan to do:
* Perl6book examples
* Fix Win32 Rakudo problems
# Blockers:
* $WORK
* Roof.new
.end
20:30 allison joined
allison - Reviewed chromatic's security plans for Lorito. 20:32
- Discussed Lorito and future parrot plans with chromatic.
- Drafted 20 ops for lowest level of Lorito.
EOR
chromatic won't make it today (wedding preparations)
who's here today?
cotto_work hi 20:33
darbelo o/
tcurtis Hi.
Chandon Hi
Util Hi
allison let's get started 20:34
how did we do on weekly priorities?
how is gc_massacre doing? 20:35
Coke ~~ 20:36
allison how about deprecations? 20:37
ticket closing?
Coke I would like to go through DEPRECATED.pod this week for the next (supported) release in 2weeks and figure out which experimental stuff is getting promoted. 20:38
don't need to do it now. Will probaly send out a separate email for each one to track any feedback.
NotFound BTW closing some tickets depends on experimental things.
allison then for next week, I suggest a weekly priority of "review experimental features for promotion or removal" 20:39
Coke (though there is a lot of them, may just encourage comments on tickets instead.)
allison are there any other items we'd like to have as weekly priorities for next week? 20:41
Coke I need to fix 'make html'
anyone wants to pitch in, great, ping me.
tcurtis Documentation for users of Parrot perhaps? 20:42
Or just docs in general.
allison ah, yeah, I saw your post to pod-people (I'm assuming that's related), need to reply
Coke tcurtis: yes.
allison I'll add 'make html' to weekly priorities
Coke I think we're pretty much at the cutoff for anything major going in.
allison yes, very true 20:43
Coke (only 2 weeks left to get things tested before a supported release.)
I'll send out an email to the list tonight.
wknight8111_ agreed 20:44
Util Coke, is there a ticket or wiki page you are using for your `make html` bugs?
Coke Util: no, because I'm the only one working on it. =-)
(there are tickets that are driving it, but I'm in the middle of rewriting the mechanism entirely)
Util ok, thanks 20:45
Coke if folks are interested, I can spend time divvying up tasks.
otherwise it's not a good use of my time.
allison it's easy enough for you to give someone who asks a task without spending time writing up a task list 20:47
(which is to say, if anyone wants to help Coke, just talk to him)
Coke ;) 20:48
allison how about questions?
Coke please, lots of testing in anticipation of release. now's a great time to setup a smoke server if youhaven't already.
allison q1c
Coke (client, I mean.)
allison good point
on as many platforms as possible 20:49
tcurtis q1q
allison tcurtis: go ahead
tcurtis: what's your question? 20:52
(or any other questions?)
tcurtis bacek has asked chromatic and myself about merging my branch into trunk soon for pirate. Alternately, he also suggested moving it to a separate repo and using it as an external project(like we do with NQP, if I understand what he means correctly). Can I do that? If we merge it before 2.6, I would like it marked experimental, though, since there are still some API changes that might be necessary.
allison When you say "can I do that?" do you mean move it to an external repo? 20:53
talk a little more about pirate and how it integrates with current Parrot
is it pretty independent?
and, how fast is it changing? 20:54
and how much does it depend on a particular release of Parrot?
tcurtis "Can I do that?" was referring to either merge it into to trunk or move it to an external repository.
Coke I don't mind if we add something experimental and mostly unused-currently to trunk, but : see also pirc.
allison yes, you can certainly do one or the other
wknight8111_ +1
allison (i.e. will people always have to update pirate when they update to a new version of Parrot?) 20:55
tcurtis My question was asking about merging my GSoC branch, not PIRATE.
wknight8111_ (I would prefer mergeback to an extern repo)
allison merging your branch so pirate can use it? 20:56
not merging a branch that contains pirate?
cotto_work PIRATE as Parrot's primary PIR compiler is still a ways off.
tcurtis allison: Right.
allison tcurtis: then review my questions, substituting "your branch" for "pirate" 20:57
it's the same basic problem
tcurtis It is pretty independent of Parrot. It doesn't depend particularly much on particular versions of Parrot, although changes to PCT might necessitate changes in it. 20:58
cotto_work We can ask bacek to post his long-term plans to parrot-dev. 20:59
tcurtis It still changes frequently, but less so than earlier on, and most of these are now bugfixes.
allison sounds like it's changing fast enough that the parrot deprecation policy wouldn't be appropriate 21:00
(hence the desire for labeling it "experimental")
cotto_work goes afk
allison would it be easy to install as a module? 21:01
wknight8111_ the optimizers are an optional tool that people using NQP-based compilers can easily make use of if they opt in
Coke I don't know that /anything/ is currently easy to install as a module, izzit?
wknight8111_ plumage is back up and running again, I think. But I don't think many people use it
NotFound plumage is working well right now. 21:02
wknight8111_ (as obvious from nobody noticing when plumage broke horribly)
tcurtis It would probably be easy to install as a module, yes.
japhb <rez>SIGH ...</rez>
NotFound wknight8111_: too much things were horribly broken to have time to worry about plumage. 21:03
allison okay, then the last and most important question is: which would you prefer?
particle i don't think we should a gsoc branch into a supported release halfway through the gsoc program
wknight8111_ NotFound: true
particle i'm not certain it's had enough eyes
tcurtis particle: I'd agree with that. 21:04
Coke bacek is the only one that's asking for this.
particle let's target pre-2.9 for potential gsoc branch merges
Coke I'll add this to the list of release issues and let him champion it if he wants.
allison particle: definitely after 2.6 if it merged
wknight8111_ particle: it's hit a stable point, and it's being used (at least experimentally) by several projects already
particle aye, i meant post-2.6. silly me
allison tcurtis: I'd lean toward external module, really, it gives you the most flexibility 21:05
Coke I gotta run. Any concerns about the release this month, you know where to find me.
allison we can talk about it more in #parrot or on the mailing list 21:06
tcurtis allison: I would like that better, as well.
wknight8111_ I would like to see tcurtis' work available immediately. If we can't merge it back to trunk for whatever reason I think it should be made available as an external module (and then I suggest we include it in ext/ for the 2.6 release)
allison other questions? 21:07
then food for thought for the week: 21:09
In my report I mentioned talking with chromatic about "Lorito and future Parrot". We started talking about refactor plans for Lorito, OO, MMD, GC, etc. and I had a) a sinking feeling thinking about another 3 years of refactors, and b) a realization that they're really all just one refactor, Lorito.
so, rather than starting a host of refactors for 3.0, I'm suggesting that we focus on Lorito, and build the lessons we've learned into it from the start. 21:10
wknight8111_ no
(I think my client has a lot of delay. That "no" was in response to "other questions?")
allison wknight: elaborate as you have time, I'll keep typing too
ah, right
The most painful parts of the past 3 years of refactors, and also the most horrible code left in Parrot is at the junctions between old and new. 21:11
where we can't rip out X because Y depends on it, and the chain of dependencies is too great
So we treat Lorito like another system refactor, where both can coexist for a while, and then we eventually drop the old. 21:12
But, instead of a partial subsystem refactor, it's a main.c refactor. 21:13
i.e. a wholesale replacement for the parrot executible
starting with a tiny prototype executable with 20 opcodes
something we can develop quickly, and start experimenting with
I started drafting that list of 20 opcodes, I'll send it to the list today. 21:14
wknight8111_ It may be worthwhile to get back to defining exactly what Lorito is then. I was under the impression it was basically a microcode layer. If you're suggesting it will encompass changes to GC, OO, and MMD, etc, maybe it's more than that
allison Lorito is whatever we make it. But yes, what we're talking about here is a total replacement. 21:15
tcurtis wknight8111_: I think the plan is to be able to rewrite at least some of what's currently in the core of Parrot in C in the microcode layer.
allison yes, the Lorito plans already had ops and PMCs moving to being written in the microcode layer 21:16
which is, effectively, the whole interpreter
Think about it for a week, save up your thoughts and well talk about them more. 21:18
Particularly in the next virtual developer summit.
any more thoughts, comments, questions before we wrap up for the week? 21:20
Call it a week then. Thanks everybody! 21:23
21:28 NotFound left 21:36 Chandon left 22:03 chromatic joined 22:14 chromatic left 22:18 darbelo left

Powered by Cro and the Raku® Programming Language.

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

Thank you!