"Tuesday at 20:30 UTC"
Set by moderator on 20 April 2010.
04:04 sorear joined 13:53 mikehh joined 15:06 plobsing joined
plobsing What I Did: 15:06
* various IMCC bugs/TTs
* ops_massacre branch (TT #449)
What I Plan:
* finish/merge ops_massacre branch 15:07
* reduce need for const op variants (20 subclass ops? really?) by adding appropriate smarts to IMCC
EOR
16:53 cotto_work joined 17:34 plobsing_work joined 18:24 tcurtis joined 18:43 NotFound joined
NotFound 2010-may-25 18:45
What I did:
-parrot
* Modified Parrot_str_unescape_flags to take a flags argument.
* Use Parrot_str_unescape_string to improve pir parsing of
encoded strings, with some tweaks to keep backward
compatibility of utf8.
* Modify PBC constant string storing to preserve encoding.
* Added some tests for conditions previously uncovered found
while doing the former.
* Minor fixes and cleanups.
-winxed
* Fix :named :slurpy problem, reported by plobsing++
* New predef bytelength.
* Predefs now can have with explicit void result.
* Experimental syntax to insert pir ops
* Minor fixes.
* Adde a simplified XMLHttpRequest class to examples.
What I will do:
No plan
EOR
Coke -Rakudo -- added some tests for Perl 6 2009 Advent Calendar to spec tests. 18:51
-Partcl -- trying to get partcl working again. current strategy - find most recent
version of parrot & partcl that played nice together and fast forward
from there. (future plan - run a continuous build so this never happens
again.) 18:52
-Parrot
-- hooked up dukeleto with pl.parrot.org -- adminy things.
-- tickety things.
EOR
19:01 smash_ joined 19:05 smash joined 19:13 Chandon joined
tcurtis What I did: 19:28
* Started working on my GSoC in branch gsoc_past_optimization.
* Implemented PAST::Walker and PAST::Transformer.
* Added examples and tests for PAST::Walker and PAST::Transformer.
- Including an example of constant folding of Integer addition.
* Fixed editor/pir-mode.el 's indent default to 4 in trunk.
* Wrote PAST is_equal vtable override(t/library/pastcompare.pir) for tests.
What I will do:
* Continue writing tests.
- Update existing tests
* Write a blog post talking about the status so far, complications, etc.
* Decide whether to walk attributes of PAST::Nodes that can contain other PASTs.
- If so, implement and test it.(Potential problem: cycles).
* Possibly write something to deeply copy PASTs. 19:29
* Start on PAST::Pattern if time allows.
* Meet with chromatic to determine if there's anything else I should do before PAST::Pattern.
EOR
dukeleto eta until ps? 19:30
19:32 bubaflub joined
Util 58 minutes, dukeleto 19:32
# Done: 19:33
* Changed todo() to skip() for tests that must currently remain commented out - old patch by bubaflub++ (TT #1302)
* Experimented with converting pbc_to_exe from PIR to NQP.
= Resulting version is more maintainable, but slower. No conclusions yet.
# Plan to do:
* More on TT#1302 (PIR todo() is frequently misused).
# Blockers:
* $WORK
.end
19:38 khairul joined
bubaflub Done: 19:48
* Begun work on Parrot on RTEMS for GSoC
Will Do:
* Blog post detailing plans for world domination
* Get parrot trunk cross-compiling for RTEMS
END
khairul * Started working in my branch, gsoc_instrument 19:52
- added instrument.pmc
- added beginnings of runtime library
- added simple example
* Had an online meeting with cotto
- Fixed weekly meetings with him
Will Do:
dukeleto What I did: 19:53
* GSoCy things
* Gave a talk about PL/Parrot at PGCon:
www.pgcon.org/2010/schedule/attachm...n_2010.pdf
* Worked on splitting PL/Parrot into a trusted/untrusted PL component (which has some evil bugs)
* Reporting this bug in load_bytecode via the embedding API: trac.parrot.org/parrot/ticket/1656
What I will do:
* GSoCy things
* Report more embedding API bugs that I still haven't reported
Blockers:
* Time and stuff 19:54
.EOR
mikehh What I did since my last report:
* building and testing parrot on amd64/i386, with gcc/g++
* various fixes
* branch testing and some fixes
* started looking at running tests against installed parrot
* need some serious tuits here
What I intend to do in the next week:
* testing and fixing
* continue looking at running tests against installed parrot
.eor
Chandon Done: 20:01
* Worked on attack strategy for hybrid threads GSoC project.
* Tried to figure out what Parrot is doing by reading the code.
* Wrote blog post.
Will do:
* More of the same.
* Bite burger from wrong angle, get hands covered in mustard.
EOR
cotto_work %did: 20:04
- implemented ops renumbering in ops_pct, got the branch ready to merge 20:05
- bacek++ took care of doing the actual merge; it's now in trunk
- made ops2c be noisy by default but quiet when used during the build (i.e. used with --quiet)
- made Ops::* go away
- ripped ops.num (and supporting code) out of opsc
- the patch is working but not committed
- the closest thing to a blocker is bytecode compatibility, but ops.num wasn't very good for that (and wasn't used anyway)
- will most likely commit this evening barring objections
- chatted with khairul
- did some basic code review, answered questions, pointed him at the OpLib PMC, other mentory stuff
%will do:
- get opsc into a state where nobody needs to care about it 20:06
- think about how awesome PIRATE will be
- assess git/trac possibilities
%eor
q1q if I'm around by the time we get there
20:07 chromatic joined, darbelo joined
chromatic I answered some questions and may have coding time this weekend. 20:08
darbelo DONE 20:17
- Finished up UCS-4. Could be merged backto trunk as is.
- Wrote a blog post to clear up some NFG points raised on IRC.
- Otherwise enjoyed the loooooong weekend. Bicentenials don't happen often ;)
TODO
- Merge ucs4_encoding too trunk.
- Start with NFG proper.
- Isould have a prototype grapheme table in two days tops.
EOR.
20:23 allison joined
bacek Done: 20:26
* merge ops_pct branch.
* minor speed improvements of opsc
* Re-start from scratch NQP/PCT based PIR parser/compiler
* Wrote proposal for refactoring GC.
Todo:
* Refactor GC to be ready for June release.
Blockers:
* None atm
allison One of the long-term goals of Pynie is to generate the parser directly from the Python 3.x grammar specification. Since we're in the process of ripping out old NQP anyway, and have to rewrite all the transformation rules, I went ahead and wrote a PEG-based EBNF parser this week. It's now completely parsing the Python grammar from the current py3k branch. 20:29
EOR
chromatic Anyone else? 20:30
pmichaud I did improvements to NQP (variable interpolation in regexes), autoprint from interactive REPL
next will be a full REPL that remembers lexicals from one line to the next
EOR
chromatic Let's talk about last week's milestones. 20:31
I see ops_pct has landed. Any comments?
NotFound Good work!
chromatic Any other milestones from last week to discuss? 20:32
mikehh I started looking at testing from installed parrot - needs more work 20:33
a lot I think
chromatic Do you have a list of tasks, or a list of tickets? 20:34
mikehh not yet - still investigating
chromatic Let's move on.
Suggestions for milestones this week?
bacek New shiny GC? 20:35
chromatic I'm game.
mikehh +1
pmichaud just a note that Rakudo * when it comes out in June will likely be based on the June Parrot release.
we're not specifically asking for anything from Parrot for this... but it might be worth being aware of 20:36
bacek That's main reason why I returned back to low-level stuff :)
particle it will certainly help direct our testing focus
chromatic Are you aware of any specific Parrot bugs or malfeatures you'd like us to address?
pmichaud No.
It's more a note not to add any bugs or malfeatures :) 20:37
bacek pmichaud, I have nqp-rx bug for you. Good one :)
Coke there's always the list at: trac.parrot.org/parrot/report/16
pmichaud bacek: I saw your note -- just need to come up with a smaller test case
bacek pmichaud, ok.
chromatic What should people who don't want to work on the GC work on? 20:38
bacek 1. Lorito. 20:39
darbelo Bugfixing?
bacek 2. Emit PBC from POST
plobsing_work ops_massacre might cause some minor compatibility issues when it lands. HLL people can have a go at that.
bacek By "Lorito" I mean HLL for ops.
chromatic Do we have a volunteer to coordinate efforts there?
particle documentation that rakudo users might need to know
NotFound There are conflicting goals here. Emiting pbc directly and delete some opcodes and made pir synthesize it goes on different directions. 20:41
bacek NotFound, not really. 20:42
cotto_work different but orthogonal
bacek Emitting PBC can start with current ops.
plobsing_work a PBC emitter shouldn't need to have hardcoded knowledge of what ops we have. 20:43
*note that IMCC fails hard in that respect
cotto_work OpLib can help us there. 20:44
(the PMC)
chromatic To make this work, we need a coherent plan and someone(s) to write said plan.
NotFound It can be done, but advances in both fields at the same time can lead to confusions.
allison which is the higher priority? 20:45
bacek HLL for ops
allison then do that one first
plobsing_work I'm pretty much done on the massacre. IIUC, the emitter is in planning phase. Little to no overlap as I see it.
bacek At the end of the day PBC emitter will require PIRATE
allison the bytecode emitter may even fall out of the HLL for ops
(since, the HLL for ops will be emitting... lower-level ops) 20:46
Coke when you say "HLL for ops", do you mean a special HLL just for ops, or nqp-rx, or an arbitrary hll, or?
bacek "arbitrary HLL"
even proper parsing of current "C-mess-mess" 20:47
allison we mean the part of Lorito that involves defining most of the ops we use in a higher-level language than the C-macros we're currently using
Coke are the lorito wiki pages up to date? 20:48
cotto_work LoritoRoadmap is the most recent
The rest haven't been touched in a while iirc. 20:49
though I'm the only one who's put much content there, so I don't know how well it reflects everyone else's thinking
Coke looks like the next step is "come up with a design". 20:50
allison cotto: the idea is still fairly green... yes, what Coke said
cotto: so your thoughts are just as good as anyone else 20:51
cotto_work but they'll get better when smarter people edit the page
allison cotto: sounds like a call for action 20:52
cotto_work That's my intent.
chromatic I repeat: who's in charge?
allison cotto: would you be willing to nominally drive it? 20:53
Coke of lorito? we've had several interested parties over the past year. chromatic, cotto, bacek are the 3 that I recall.
cotto_work I can poke people and contribute what I feel capable of, yes.
allison (with lots of help from the rest of us)
NotFound And the lorito goes to... 20:54
cotto_work Alright. This'll be fun.
chromatic Who's volunteering to coordinate Rakudo-related bugfixing?
Coke I'm happy to be a go between there, though moritz has been great on the rakudo side. 20:55
chromatic Who's volunteering to lead the GC fire?
Coke (bacek)
bacek me
cotto_work +1
chromatic That sounds like enough work for one week.
bacek GC will take couple of weeks. I'll do my best to make it ready for release. 20:56
chromatic I'll review your plan on the wiki.
Shall we move on to roadmap review?
dukeleto <plea>it would be nice if parrot mentors could blog about helping their gsoc students</plea>
allison the 3-month roadmap task is GC 20:58
chromatic Sounds like we're working on it then.
Question time.
allison we have one innovative idea for GC this week, the next step is prototyping
chromatic cotto_work?
cotto_work I'd like to drop ops.num in favor of a yet-unwritten release-based approach to bytecode compatibility 21:01
i.e. whenever a supported release is cut, the info necessary for bytecode compat is saved to a checked-in file.
allison sounds good in principle, let's work out the details of the replacement 21:02
cotto_work by a crummy coincidence, I also have to go to a meeting. I'll be back as soon as I can.
allison (and the migration strategy between the two)
Coke before that point, do we have to be compatible with bytecode in otherwise supported releases?
bacek iwbn...
Coke or at (say) 3.3, do we say "ok, now if you compile to PBC, we'll be able to use it 3.6" ? 21:03
use it *in
sorear let's use PIR as our "portable bytecode" 21:04
chromatic We already do.
bacek We need Lorito first with rock-stable ops set.
(For portable PBC) 21:05
NotFound And we'll probably need a way to store in the pbc the dynops used. 21:06
Coke I'm just making sure that we we start supporting older bytecodes, we have a clearly marked "but no further" point.
chromatic Sounds worthwhile to me. We've never promised bytecode compat.
Coke ... well, before 1.0 we /said/ we were going to, but yah, we never really did. =-) 21:07
allison we'll keep the right to deprecate bytecode formats, but will be very clear about it when we do
chromatic I don't mind supporting only the previous version of PBC in any supported release, if there's a migration tool. 21:08
mikehh once we start using that we definately need to keep track of older versions
chromatic Any other discussion on this suitable for #ps?
NotFound An external tool to read one bytecode format and convert to other is doable, and can solve most problems.
chromatic Any other questions? 21:10
NotFound Ideas for a better name to 'unroll' ? 21:11
chromatic end_handler? Don't know if that's better.
NotFound pmichaud said something about a possible usage non eh related. 21:12
Coke eh. it's experimental. we can rename it at will. =-)
sorear bacek: I'd like to sell you a data structure - it's a greylist implementation with 1.01 bits per object worst case memory usage and O(log log n) insert/delete-first/delete operations. Interested enough for me to attempt a prototype?
allison the original spec had an op named something like 'handle'
NotFound Coke: yes, but if we want to have it well tested for June we must start using it right now. 21:13
bacek sorear, yes!
chromatic Any final questions? 21:14
Coke WHAT ... is your favorite color?
NotFound Blue?
allison can I have a pony?
spinclad NotFound: Wrong! over you go!
Coke chromatic: guess not. =-) 21:15
chromatic Okay, you're all kicked out! Meeting adjourned.
21:41 darbelo left 21:52 NotFound left 21:55 Chandon left 22:05 whiteknight joined 22:07 smash left 22:27 spinclad joined 23:16 plobsing_work left 23:30 whiteknight 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!