Vision for 2.0: Production Users | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 2 February 2010.
00:02 particle joined 12:17 mikehh joined 13:57 Coke_ joined 14:44 bluescreen joined 15:24 allison joined
allison (Land about 10 minutes before #parrotsketch today, hope for wifi in the airport.) 15:24
Last week:
- Working on reports of incorrect line numbers in error messages.
Next week:
- Travel done, settling in to work.
16:17 bluescreen joined 18:23 bubaflub joined 19:27 NotFound joined
mikehh What I did since my last report: 19:28
* building and testing parrot on amd64/i386, with gcc/g++
* got Ubuntu 10.04 amd64 beta up and running - some tests there
* at the moment all tests up to fulltest pass (r45408)
* some fixes
* unfortunately had some serious $work problems over Easter which I had intended to devote to parrot
What I intend to do in the next week:
* testing and fixing 19:29
* continue looking at integrating nqp into codetests
.eor
moritz What I did last week: tried to act as a bridge between #parrot and #perl6 when necessary. Will try to do that next week too. EOR.
NotFound What I did: 19:42
-parrot
* Moved initializtion of paths from main to interpreter initialization.
* Fix init_int in FPA, added Parrot_pmc_new_constant_init_int, and change
* init usages to init_int in a lot of places.
* Several minot fixes.
-winxed
* Use init_int for fixed size arrays.
* Minor refactors.
What I will do;
No plan
EOR
19:43 bluescreen joined
Coke partcl - 19:44
- eliminated most of the PIR in the NQP version: Austin++
- update [foreach]
rakudo -
- very minor ticket wrangling. Claimed a ticket that requires some parrot
work...
.
(I will probably miss the meeting today)
19:50 cotto_work joined 19:53 chromatic joined
chromatic bacek and I fixed the GC performance regression. 19:54
I poked at a few things.
I'll work on improving line numbers in annotations and helping bacek get the constant string cache performance back to SUPERFAST. 19:55
19:59 bluescreen joined 20:23 darbelo joined
cotto_work #did: * reviewed and rated some gsoc proposals * not much else #will do: * whatever looks shiny and/or helpful #closed TTs: #eor 20:24
#did:
* reviewed and rated some gsoc proposals
* not much else
#will do:
* whatever looks shiny and/or helpful 20:25
#closed TTs:
#eor
darbelo DONE:
* GSoC proposal sent.
* Knee-deep in string internals.
* Learned a whole lot about Unicode. 20:26
TODO:
* Brib people to get int GSoC
* Do some work on strings.
EOR.
20:27 allison joined
NotFound hola 20:30
mikehh hello
darbelo hi
bubaflub hello
chromatic Hello everyone. 20:31
Do we have any last minute reports?
allison hi
bubaflub whoops, one sec 20:32
DONE:
* closed some old TTs
TODO:
* close some more old TTs
* submit proposal to GSoC to port parrot to RTEMS
EOR.
chromatic Anyone else?
Okay. Let's review last week's big tasks. 20:33
Rakudo performance: fixed.
HLL bugs? TT #389 and #1040? Whiteknight?
Anyone know any status on those? 20:34
No status. Okay. How are we doing on prioritizing Rakudo needs? 20:36
Coke? allison? particle?
allison looking at the tickets, but looks like no progress
particle i can say the rakudo folks are happy with the reduced memory footprint
allison (that was an answer to the previous question)
particle there is still work remaining on other tasks, i think allison is on the next-most-important, line numbering 20:37
chromatic Should we make line numbering our big priority for the week then?
allison I need more examples from the Rakudo folks there
particle chromatic++ 20:38
line-numbering test infra would be particularly helpful going forward
this problem seems to bite us frequently 20:39
moritz allison: every perl 6 program that calls die() is an example...
chromatic I think we can demonstrate the program even at the PIR level.
NotFound What's the problem? HLL line number annotations?
allison moritz: thanks, that's useful
cotto_work The profiling runcore tests could be easily adapted to check for line numbers too.
chromatic If we had a harness with which we could run arbitrary PIR programs and dump them with line numbers as recorded by the annotations, we'd find a lot of bugs easily. 20:40
cotto_work The profiling runcore tests almost do that.
chromatic Can we start there, then see where things go weird for Rakudo and HLLs? 20:41
cotto_work Fine by me. I'll add some documentation to runtime/parrot/library/ProfTest/*.nqp this week. 20:42
chromatic Any takers on making the harness and a list of failing files?
NotFound We have a imcc problem: there is no way to set an annotation at the .sub start other than put it at the end of the previous sub 20:43
chromatic I'm pretty sure how to fix most of the annotation problems in IMCC once I know what they are.
cotto_work Great.
Coke returns. 20:44
NotFound That problem is: the first annotation of the sub body is set after get params
chromatic Do we have volunteers for the rest? Allison? cotto? NotFound?
cotto_work That'll make the profiling runcore much more useful.
allison sounds like it's covered, what's left? 20:45
NotFound chromatic: I can look at it, but don't have much avalable time
cotto_work What exactly needs to happen? Do we just need a stub test that demonstrates how to test PIR-level annotations?
to which more tests can be added as needed? 20:46
chromatic The problem is that specific PIR constructs are off by one line one way or the other.
That means that we have to identify which PIR constructs have that problem.
Without knowing what they are, I can't trace their paths through the IMCC grammar and figure out where to fix up their numbers. 20:47
What really would help me is a test framework that can run every PIR/PASM file under t/ (for example) through some output mechanism in Parrot that dumps lines with their line numbers and compares those to actual line numbers.
cotto_work indeed 20:48
chromatic Stage two is doing something similar with HLL annotations.
NotFound chromatic: an improved -t1 ?
chromatic Yes, a better -t1 would work.
cotto_work I'll look at using the profiling tests for something like that. 20:49
chromatic Anything else on this subject? 20:50
allison what's the progress on the string segfaults?
NotFound I can add an option to packfile.winxed that emits a disassemble with the pir line numbers, maybe that will be easier.
chromatic The easier it is to find places where the annotations are incorrect (and to demonstrate that nothing else has changed), the easier to fix them. 20:51
darbelo allison: TT#???
chromatic In particular, any code that uses macros goes... way weird.
allison darbelo: reported by chromatic over the phone last week on a bad connection, I don't know if there is a TT 20:52
20:52 cotto_work2 joined
chromatic There's something weird in Parrot_str_append, I believe, but fixing COW problems seemed to help. 20:53
Let's move on. 20:54
allison that's good
chromatic Other priorities for the next week?
darbelo Urge SoC students to get their proposals in.
bubaflub heh.
chromatic Noted. Anything else? 20:55
particle don't just urge. help.
chromatic Let's move on to questions. Anyone? 20:56
In the absence of anyone else, I have one. 20:57
allison, there's lots of discussion of immutable strings. What do you think now?
allison ah, I have a lengthy reply to your last email that I haven't sent yet 20:58
it essentially boils down to: COW is supposed to be immutable, that's the whole point of it
chromatic We can keep shared buffers and immutable strings.
The question is whether a string can mutate its buffer in place.
allison we have a fundamental architecture problem in that COW requires creating multiple string headers before we actually write anything 20:59
just in case we might possibly write something at some point
20:59 cotto_work2 left
chromatic We'd have that problem without shared buffers too. 21:00
allison if we had real COW working, no string would ever need to modify the buffer in place
cotto_work afk
allison my concern with the current proposal for immutable strings is that it will actually increase the cost 21:01
chromatic Sure we would.
allison that is, instead of creating unnecessary string headers, we'd create unnecessary copies of string buffers
chromatic No, we wouldn't.
allison which isn't a big deal when the strings are small (function names, etc)
chromatic We can still use shared buffers with immutable strings.
allison but when the strings are entire files being parsed by NQP, it's a big deal
or, worse, entire files being generated by NQP 21:02
(a few characters at a time)
chromatic There is only one architectural change necessary to make immutable strings work. 21:03
It's still very compatible with shared buffers. 21:04
NotFound The obvious suggestion is: Don't do that.
chromatic It's likely to *decrease* the number of string headers we need, at least if we perform more reads of strings than writes (which is a good assumption).
allison NotFound: don't append to strings to build up strings?
changing append to return a string header I'm fine with
NotFound allison: don't write entire long files as strings char by char. 21:05
Coke (if you're creating a string, a join of an RPA might work better, especially if you can make that join smart.)
er, RSA
chromatic We should consider making a StringBuffer for that sort of thing, yes.
NotFound Write to a file, use lists of lines... whatever.
allison chromatic: I'm even fine with (later) eliminating "append" for only "concat" if we prove the performance is good enough 21:06
chromatic I don't think we have to remove Parrot_str_append. 21:07
The only philosophical change (and it doesn't affect much in the code) is removing the assumption in the C API that string modification functions modify their arguments in place.
allison if append returns a value, and the first argument isn't modified, then there's no difference between append and concat
chromatic First we have to break the unholy internal spaghetti alliance between those two functions, but yes. 21:08
allison if the difference is "the first argument *might* be modified", then it's a relevant distinction
chromatic The big question then is "What would make this worth experimenting with?" 21:09
allison down the road, we need to get real COW working
chromatic and the followup is "What would everyone like to see from the experiment to consider merging it?"
(also I don't understand what you mean by "real COW", because we have real COW, as real as C will let us get)
allison but, that requires the same extra level of indirection as copying GC, so is likely to happen anyway
no, we have COW that requires action early 21:10
(creating a duplicate string header)
real COW is lazy
*nothing* happens until the write
chromatic Unless you have [upvar] in C, that's not going to happen in C.
mikehh indirection 21:11
chromatic ... or else effective you have immutable strings anyway.
allison it's the extra level of indirection
and real COW is immutable strings
basically, I'm fine with experimenting with it
chromatic An extra level of indirection, in that we have a new parrot_cowable_string_t data structure which holds a pointer to parrot_string_t?
allison but I really want to see extensive profiling 21:12
what you need to make it work is the ability to reference the storage location of the string
so you can store a different string header in that storage location 21:13
chromatic The stack variable or register holding the string pointer?
*CPU* register?
allison (without changing any other locations that point to that string header)
neither
the container
chromatic This is C. Those are the containers you get.
allison i.e. the variable or register location
right, but if you have variable->stringheader->buffer, you can change the variable to point to a different string header 21:14
that's how COW works
we're wandering far afield here
chromatic If you're called from PIR yes, but not from C.
allison I'll send my longer email reply
chromatic Okay.
Anyone else have criteria or thoughts on this? 21:15
NotFound We have STRING * pointers, both in C functions and in parrot registers,
allison on your current question: yes, it's worth experimenting with immutable strings
chromatic Let's move design specifics to #parrot. 21:17
Any other thoughts on the viability of experimenting with this? Any +1, -1 from anyone else?
NotFound +1 21:18
darbelo bacek mentioned he was going to start some work on it soon.
+1 from me.
chromatic Right, I wanted to bring up the question to see whether it should be a fait accompli or an experiment first.
Let's move on to roadmap review. allison?
allison looking quickly over the 2.2 milestones, few are likely to make it to 2.3 21:19
so, we can work through a couple of them, then 2.3 milestones
(there's only so much we can do in one sitting)
21:19 bacek joined
allison first up is: Add Configure probes for LLVM 21:20
is this a roadmap task?
darbelo We have that in a branch.
allison I suggest dropping it from roadmap
NotFound +1 21:21
allison (I'm not saying it shouldn't be done, just that it's not a task for a specific release)
NotFound Agree
allison okay, changed
next: t/steps/auto/frames-01.t: Failures following pcc_reapply merge 21:22
This is about frame building 21:23
move it out?
is there a larger ticket for frame building we can attach it to and remove from the roadmap?
chromatic +1 to the larger ticket idea 21:24
None of those tests should be roadmap items.
allison okay, removed from roadmap 21:25
made a note to self to find/create a ticket for the framebuilder this week
that's enough of 2.2, on to 2.3, to make sure we're on top of things for the release 21:26
HLL export conventions, what's the status/progress there?
darbelo ENOTENE 21:27
allison is it a priority for 2.3?
darbelo Sounds like it should be. 21:28
allison if our priority is Rakudo, then cross-HLL is lower
mikehh I don't think we are going to get it for a while
chromatic We need at least one other person working on it with Tene.
allison suggest dropping it from "critical" to "normal" and bumping to 2.6 21:29
21:29 Whiteknight joined
NotFound +1 21:30
darbelo wfm
spinclad Rakudo would like cross-HLL module 'use'; at least for Perl 5 and parrot
allison yes, but getting Rakudo working well is a higher priority 21:31
it looks like we already did the bump to 2.6 for the other HLL-interop tickets
chromatic Do we have a volunteer to get a list of prioritized use cases for "use" from Rakudo? 21:32
spinclad i hesitate to volunteer, but will if noone else 21:33
chromatic It's just a list, that much is useful on its own. 21:34
spinclad will talk on #perl6 to collect needs
allison thanks, spinclad
next, are there any more deprecations for ops/pmcs to go in before 2.3? 21:35
(TT #449 and #448)
sounds like a mailing list question, I'll post it there
next, sweep-free gc 21:36
is it a priority for 2.3?
is any work going into it?
should we move it out, and to when? or should we drop from roadmap?
it was originally offered up because GC was a goal for 2.3, and it seemed small 21:37
chromatic That should probably be a bigger priority than immutable strings, but it's also probably a larger task.
allison but, we've gotten a large amount of other good work in GC
I'd call the task of "work on GC for 2.3" complete, and sweep-free gc as an extra for later work 21:38
Propose dropping it from the roadmap: for/against? 21:39
chromatic Upper bound of GC improvement for sweep-free GC: 10% performance improvement.
NotFound allison: for
allison (again, that's not a proposal to drop the task, just that it's not tied to a particular release)
chromatic Let's bump it to after 2.3. 21:40
allison okay, 2.6 (we'll redistribute the 2.6 tasks to dev releases after 2.3)
next: subroutine leave semantics/exit handlers
chromatic ENOTENE 21:41
allison this is a Rakudo need
will leave at 2.3 for now, look for a status update next week 21:42
next: improved NCI/FFI
is this a roadmap task?
is this likely to happen in 2.3?
chromatic Unlikely; possibly a GSoC project.
allison okay, I propose to drop from roadmap 21:43
for/against?
(this is the last one)
NotFound for 21:44
chromatic for
NotFound do
darbelo while
allison :) 21:45
okay, dropped from roadmap
that's all, back to chromatic
chromatic Any final questions? Other than "Why are we so awesome?"
spinclad that's a good one
but better in #mirror, perhaps 21:46
chromatic Let's call this meeting over. Thanks, everyone. 21:48
spinclad c++ a++ all++
22:02 darbelo left 22:13 NotFound left 23:11 chromatic left 23:39 bacek 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!