"Tuesday at 20:30 UTC"
Set by moderator on 2 June 2010.
00:26 tcurtis joined 04:35 integral joined 04:51 tcurtis_ joined 05:13 eternaleye joined 11:00 whiteknight joined 15:45 contingencyplan joined 16:42 tcurtis joined 17:00 NotFound joined 17:09 cotto_work joined
NotFound What I did: 17:13
-parrot
* Added a bunch of tests, near 100% coverage of ...Array PMCs.
* Fixed some tests that were failing because of dynops, not of the feature
being tested.
* Modify some PMC vtable functions to reduce complexity, simplifying its
coverage.
* Deleted do-nothing custom mark in StringBuilder.
-winxed
* Minor refactors.
* Predef constants true and false. 17:14
* Improved example ajax.
What I will do:
No plan
q2q
EOR
Coke Done: 17:23
- resurrected partcl
- Sneakiest breakage was result of TT #389 fix - you can no longer
put subs or their children into a namespace unless you declare them
in PIR and add the :nsentry flag. This means you cannot DYNAMICALLY
without the PIR compreg. Aooga.
Will Do:
- Now, partcl-nqp is broken. something is eating a CONTROL_RETURN exception
when it didn't used to.
EOR
*DYNAMICALLY /add/ them.
17:29 bubaflub joined 17:46 whiteknight joined 17:50 tcurtis_ joined 18:27 darbelo joined 18:37 mikehh joined 19:04 chromatic joined
chromatic I read some commits and replied to some messages and that's really all. 19:05
19:05 PacoLinux joined 19:52 khairul joined 19:53 allison joined
allison My time this week was still absorbed by exams. Finished the last one yesterday, so will have time again starting this week. 20:00
EOR
pmichaud + Fixed up 'exit' opcode, added CONTROL_EXIT exception type. 20:06
+ Modified PAST so that it can generate symbolic pasm constants in PIR output.
+ Applied bacek++ patches, nqp-rx now supports multisubs and multimethods
+ Fixed sigspace handling on nqp-rx ** quantifier in regexes
+ Added \\e to nqp strings
+ Worked out use of inversion lists for charclass lists in regexes
+ Fixed some substr-out-of-range errors in Regex.match
EOR
cotto_work khairul, ping 20:13
mikehh What I did since my last report:
* building and testing parrot on amd64/i386, with gcc/g++
* various fixes
cotto_work ww
mikehh * branch testing and some fixes
What I intend to do in the next week:
* testing and fixing
.eor
cotto_work #did: 20:18
- helped khairul with some questions
- moved bacek's linked list code in gc_massacre into a place that's more amenable to reuse
- pinged OSU about getting a trac/git test site; no reply
- worked on LoritoRoadmap
#will do:
- get trac/git set up
#blockers: 20:19
- OSUOSL responsiveness
20:19 smash joined
cotto_work #eor 20:19
q3q
Util # Done:
* Edited Perl6book.
# Plan to do:
* Write Perl6book section on currying.
* TT#1302 (PIR todo() is frequently misused).
# Blockers:
* $WORK
.end
darbelo DONE 20:22
- Various cleanups and some added functionality to NFG. Various parts of the STRING API are now more graceful in their handling of grapheme tables. concat still isn't.
- Got myself a windows dev environment for my birthday. In retrospect, I should have gotten some teeth pulled...
- Some windows testing.
TODO
- Stay on schedule.
- Tackle concatenation and COW issues.
- Blog post for this week is coming later today.
EOR.
khairul Done: 20:26
- Had some fun exploring dynop loading process (parrot.mangkok.com/?p=94)
- Added some tests for the Instrument dynpmc.
- Made codetest slightly happier.
Will Do:
- Finish up reworking runtime library.
- Write synopsis for week 2.
- Explore making loading dynops a stop the world event like GC.
EOR
tcurtis What I did: 20:27
* Mostly implemented PAST::Pattern.
- Can match on types, children, and attributes,
- Can match based on iseq to a constant,
- Can match based on true result from a closure, and
- Can match based on anything with an ACCEPTS method.
- Can't match globally yet.
- Can't transform a PAST where it matches yet.
* Forgot to post a blog post last week.
- Posted one yesterday.
What I will do: 20:28
* Finish implementing PAST::Pattern.
* Start writing optimizations using PAST::Pattern.
* Not forgot my blog post this week.
* Write some documentation.
* Start working on adding optimizations to PCT compilers.
* Also start working on some example optimizations.
bubaflub Done: 20:32
* Almost finished Parrot configure on RTEMS
Will Do:
* Switch to use perl or autoconf for the last step
Blockers:
repaste:Blockers: 20:34
* Work, Makefile limitaitons
EOR
chromatic Anyone else?
Let's begin then. 20:35
How did we do on last week's goals?
dukeleto Did:
* Worked on PL/Parrot and PL/Perl6
* GSoC stuff
Will do:
* GSoC stuff
Blocking on:
* Unable to load perl6.pbc from PIR: trac.parrot.org/parrot/ticket/1675
.EOR 20:36
dukeleto says hello
what were the goals?
NotFound Hola 20:37
darbelo Hi.
chromatic Dynops breakage, for one.
The gc_massacre branch for two. 20:38
What's the status of dynops and trunk and clean test runs?
mikehh there is only 1/4 failing test in make corevm/make coretest now - make corevm/make coretest - t/pmc/io.t - Failed tests: 25, 27, 29, 31 20:40
it's related to loading io/ops 20:41
chromatic Who's working on them?
cotto_work plobsing last I checked 20:42
chromatic Any objections to keeping that as a priority for this week? 20:43
(as we have a release next week)
NotFound chromatic: Fixing the tests or fixing the problem? 20:44
chromatic Ideally the latter.
NotFound +100
cotto_work I don't know if it's solvable by then
particle i suggest updating tutorials/docs as a priority this week, we're preparing for the R* release 20:45
squaak is broken
mikehh the error in all the subtests - error:imcc:loadlib directive could not find library `io_ops' 20:46
chromatic Do we have a volunteer to coordinate fixing the IO problem/tests?
mikehh which I think is in dynopslib which has not been built yet in make corevm
I'll be working on it - I think it might involve moving the subtests out of t/pmc into dynopslib or something 20:48
chromatic Okay.
Anyone else for reviewing and updating documentation?
Util +1 20:49
NotFound mikehh: I agree, there is no login in testing some dynops in t/pmc
s/login/logic
mikehh if I have time I'll work on documentation as well 20:50
chromatic Okay, any other suggestions for the week?
Util Does Rakudo have any special needs from Parrot, in prep for R* ? 20:51
NotFound There was some talk about the need for a ByteBuffer or something like that.
cotto_work They're working on their own dynpmc. It may later be replaced by a yet-unwritten core PMC. 20:53
pmichaud I don't believe we have any specialized needs for R*.
We may be adding a few past-related items in the next 3-4 days, but nothing that should affect core PMCs or functionality
NotFound I like the idea of that PMC, I can write it this week. 20:54
chromatic Last chance to get bug requests in....
pmichaud at the moment I don't know of any bugs that are blockers for us
the one I found this past week (exit opcode) was easily fixed, and if we had to we could've worked around it rather than fixing it
NotFound Someone has a better name than ByteBuffer?
pmichaud most of the bugs seem to be in that category these days
mikehh the last time I tested rakudo against trunk - it passed all tests - just some TODO's passing (earlier today) 20:55
20:55 bacek joined
bacek yawns 20:55
chromatic Alright, it sounds like we're on track then. 20:56
Let's go to questions.
mikehh bacek: too early for you :-}
chromatic NotFound?
pmichaud I'll run a final test on saturday-ish and raise alarm bells if I think of anything.
NotFound chromatic: one has been answered by allison on #parrot, the other is the ByteBuffer
chromatic Do you know enough to make a test implementation? 20:57
NotFound I think so.
chromatic Okay, cotto_work has three questions. 20:58
cotto_work What's the eta on the gc_massacre merge? I'd like to get the linked list code into trunk for khairul soonish.
bacek cotto_work, not before after 2.5...
mikehh got to pass all tests first - it hangs on me 20:59
bacek But we can cherry-pick list code into trunk.
cotto_work ok. In that case I may end up trying to get the list code into trunk without a full merge.
chromatic Does khairul need it before next Wednesday?
cotto_work nafaik 21:00
khairul no its no hurry.
cotto_work I'll wait for it to be merged then.
eoq1
to people interested in Lorito: is there anything obviously missing from trac.parrot.org/parrot/wiki/LoritoR...ritoDesign , especially from the primary issues?
spinclad (send answers back to #parrot?) 21:02
cotto_work wfm
chromatic Last question? 21:03
cotto_work next q:
I want to get Lorito's design process started in earnest. The issues that need to be resolved are listed in approximate order of depencence on LoritoRoadmap.
I'd like to get volunteers to start wiki pages similar to the PDDs. Once these are somewhate complete, we can use them as a starting point for further discussion about how Lorito will work.
any volunteers?
chromatic I can take on a couple. 21:04
cotto_work ok. which ones?
chromatic purpose and balance 21:05
21:05 whiteknight joined
cotto_work anyone else? 21:05
allison I'll help 21:06
I haven't looked at details yet, so won't put my name on a specific task yet
cotto_work Thanks. More volunteers are welcome. 21:08
eoq
mikehh cotto_work: It is definately something I am interested in
chromatic Any other questions? 21:09
Anything else? Roadmap review? 21:10
mikehh Just want to check on the policy regarding what is in corevm regarding dynops/dynoplibs
cotto_work That'd be good to clarify.
allison I'm out of touch on the GC work 21:11
so, the gc_massacre update is the roadmap review
chromatic Needs polish. 21:12
Perhaps a tiny bit faster than trunk.
NotFound Forgot one question.
bacek A lot of polish.
mikehh string bits need implementation 21:14
NotFound The printerr problem. Now we don't have any mean to write to stderr without loading dynops other that the stdhandle method, wich is experimental.
Tene I'd rather bring in getstderr than printerr. 21:15
allison agreed
dukeleto q1q
bacek I did bring getstd* opcodes back already 21:16
NotFound bacek: yeah, but I ask what is the desirable long term solution. 21:17
Tene Then can't you call the 'print' method on the result of getstderr?
allison NotFound: $P0 = getstderr; print $P0, "foo"
NotFound So the get/set std are going to be in core permanently? 21:18
allison yes 21:19
NotFound eoq then
chromatic dukeleto
dukeleto chromatic: yes! my question: 21:20
Does anybody know what is going on with my error on loading perl6.pbc ? 21:21
Also, is anyone against getting rid of the open/close opcodes after 2.6 is released? Can I add them to DEPRECATED? 21:22
Tene shouldn't you be using load_lang for that, or was that abandoned with the other hll api changes?
NotFound dukeleto: +1
dukeleto trac.parrot.org/parrot/ticket/1675 is the error I get when loading perl6.pbc from PIR and from C 21:23
chromatic Sounds like some difference between :onload and :init somewhere in perl6.pbc.
dukeleto chromatic: do you have any idea about how "parrot perl6.pbc" is different? Because that actually works. It may have something to do with packfiles 21:24
chromatic I can never remember which of :onload or :init happens when or under which circumstances, but I bet pmichaud could give a guess about what perl6.pbc does. 21:26
This makes me want to remove both, enforce that packfiles have some sort of "When I get compiled!" method, and pass in some sort of "Here's the context of how you were compiled!" object for them to do what they want. 21:27
tcurtis :load is "Run this subroutine when loaded by the load_bytecode op", :init is "Run the subroutine when the program is run directly" according ot PDD19.
chromatic If my suspicion is correct, you should be able to produce the same error with parrot some_file.pir which loads perl6.pbc inside. 21:28
Anything else? 21:30
Let's call it a week then. Fix bugs, everyone. 21:32
21:32 bubaflub left 21:35 darbelo left 21:36 NotFound left 21:41 PacoLinux left 22:20 eternaleye joined 22:40 cotto_work left 23:31 eternaleye 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!