Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-04-06

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary