Camelia, the Perl 6 bug

IRC log for #parrotsketch, 2010-02-02

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

All times shown according to UTC.

Time Nick Message
00:14 TimToady joined #parrotsketch
01:31 cotto_work joined #parrotsketch
02:56 PacoLinux_ joined #parrotsketch
02:58 Tene_ joined #parrotsketch
02:59 PerlPilot joined #parrotsketch
03:00 japhb_ joined #parrotsketch
03:01 ascent_ joined #parrotsketch
03:03 wagle joined #parrotsketch
03:03 TimToady joined #parrotsketch
03:04 tewk_ joined #parrotsketch
03:04 integral joined #parrotsketch
03:12 cotto_w0rk joined #parrotsketch
03:22 ilbot2 joined #parrotsketch
03:22 Topic for #parrotsketchis now 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: http://irc.pugscode.org/
03:30 cotto_working joined #parrotsketch
03:35 wagle joined #parrotsketch
03:40 Util joined #parrotsketch
03:42 PacoLinux_ joined #parrotsketch
03:44 integral joined #parrotsketch
03:44 ascent joined #parrotsketch
13:09 kid51 joined #parrotsketch
13:10 kid51 kid51's report
13:11 kid51 * Created tt1393_retcon branch to explore a one-line fix in src/pmc/retcontinuation.pmc to address GC-related problem.
13:12 kid51 * Would appreciate smoke reports and review by GC experts, posted to http://trac.parrot.org/parrot/ticket/1393.
13:12 kid51 EOR
14:37 rdice joined #parrotsketch
15:18 davidfetter joined #parrotsketch
15:45 davidfetter joined #parrotsketch
15:48 davidfetter left #parrotsketch
16:33 bluescreen joined #parrotsketch
16:41 cotto_w0rk joined #parrotsketch
16:45 bluescreen joined #parrotsketch
16:50 cotto_working joined #parrotsketch
17:11 rdice joined #parrotsketch
17:41 rdice joined #parrotsketch
18:03 mikehh joined #parrotsketch
18:13 wagle joined #parrotsketch
18:26 cotto_working left #parrotsketch
18:26 cotto_working joined #parrotsketch
18:27 SamuraiJack joined #parrotsketch
18:30 darbelo joined #parrotsketch
18:34 SamuraiJack hello
18:34 SamuraiJack just curious - whether it is possible to rewrite Parrot in PASM/PIR?
18:34 SamuraiJack does it make any sense at all? )
18:35 darbelo SamuraiJack: Half-maybe. But you want to ask that in #parrot
18:35 SamuraiJack ok
18:38 allison joined #parrotsketch
18:39 whiteknight joined #parrotsketch
18:43 NotFound joined #parrotsketch
18:51 plobsing joined #parrotsketch
18:55 plobsing What I Did:
18:56 plobsing * rewrote nativecall.pl in PIR (wanted to refactor, might as well re-write)
18:56 plobsing * helped darbelo++ a little on pmc_freeze_with_pmcs
18:56 plobsing What I Plan:
18:56 plobsing * figure out how to work nativecall.pir into the build (probably need to check src/nci.c into svn, regenerate when necessary)
18:56 plobsing * refactor nativecall.pir further to generate 3rd party runtime-loadable NCI trampoline libraries
18:56 plobsing * deprecate config/gen/call_list/misc.in (3rd parties shouldn't have to register their NCI signatures in core to get support)
18:56 plobsing EOR
18:57 NotFound What I did:
18:57 NotFound - parrot
18:57 NotFound * Just testing
18:57 NotFound - Winxed
18:57 NotFound * Code cleanings, some more examples
18:57 NotFound * Some more predef functions and operators
18:57 NotFound * Backporting to stage 0 some stage 1 features
18:57 NotFound What I will do:
18:57 NotFound * No plan
18:57 NotFound EOR
19:06 japhb joined #parrotsketch
19:06 whiteknight WHAT I DID:
19:06 whiteknight (parrot) Worked on and merged kill_array_pmc branch. The Array PMC is gone now. Closed 4 related tickets.
19:06 whiteknight (parrot) Lots of testing for kill_array_pmc to make sure nobody was relying on it (almost nobody was)
19:06 whiteknight (parrot) Planning for either (a) optimizations on existing array types, or (b) creating a new project with optimized/specialized types. Jury still out on way forward
19:06 whiteknight (parrot) Testing and small codestd fixes for pmc_freeze_with_pmcs branch. All tests pass and branch appears good to merge.
19:06 whiteknight (parrot) Already helping to plan next steps in freeze/thaw cleanups and refactors
19:06 whiteknight (parrot) Testing and debugging on gc_encapsulate branch
19:06 whiteknight (parrot) Lots of blogging, especially about GSoC. Looking for good ideas to publicize
19:06 whiteknight (matrixy) Fixed some builtins, preparing for a big refactor of function dispatch code
19:06 whiteknight WHAT I WILL DO:
19:06 whiteknight (parrot) Support pmc_freeze_with_pmcs branch and merger
19:06 whiteknight (parrot) Continue debugging on gc_encapsulate branch
19:06 whiteknight (pla) Adding freeze/thaw to matrix PMCs, using new pmc_freeze_with_pmcs mechanics
19:06 whiteknight (matrixy) Starting on big function dispatch refactor
19:06 whiteknight WHAT I AM BLOCKING ON:
19:06 whiteknight Life, the universe, and everything.
19:18 mikehh What I did since my last report:
19:18 mikehh * building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
19:18 mikehh * a lot of branch testing
19:18 mikehh * some fixes
19:18 mikehh What I intend to do in the next week:
19:18 mikehh * testing and fixing
19:18 mikehh .eor
19:31 darbelo DONE:
19:31 darbelo * Got involved with PL/Parrot.
19:32 darbelo * Turned the visit_info structure used to drive the freeze/thaw process into a PMC.
19:32 darbelo This opens up several new cleanup opportunities.
19:32 darbelo * Merging branch into trunk right now.
19:32 darbelo PLANED:
19:32 darbelo * Help HLLs that are affected by the freeze/thaw change.
19:32 darbelo * Get started with the NEWS.
19:32 darbelo BLOCKERS: * Being a lazy bum.
19:32 darbelo EOR
19:32 cotto_working #did:
19:32 cotto_working * Tried to get pbc_merge working while trying to understand certian pbc oddities.  Got stuck.
19:32 cotto_working #will do:
19:32 cotto_working * Make pbc_merge work, accepting that the oddities of what imcc generates aren't worth figuring out atm.
19:32 cotto_working #blockers:
19:32 cotto_working * self
19:32 cotto_working #closed TTs:
19:32 cotto_working * none
19:32 cotto_working #eor
19:38 cotto_working q1q
19:38 darbelo q1q
19:42 Util # Done
19:42 Util * NULL
19:42 Util # Plan to:
19:42 Util * NULL
19:42 Util # Blockers:
19:42 Util * $WORK == MAX_INT
19:42 Util .end
19:45 mikehh joined #parrotsketch
19:48 tewk #WORKING ON I have a patch that removes ParrotRunningThread, I'll hit the list with it soon.
19:48 tewk #THINKING ABOUT trying to revive ncigen, especially the C99 parser
19:48 tewk #DONE
19:49 japhb Util.report.clone;
19:52 mikehh joined #parrotsketch
19:55 particle joined #parrotsketch
20:00 cotto_working q-1q (total 0)
20:05 whiteknight q1q
20:10 whiteknight actually, q2q
20:22 chromatic joined #parrotsketch
20:26 Coke joined #parrotsketch
20:27 allison Last week:
20:27 allison - Reworked the old calling conventions task list to clean out the completed tasks, and add the new ones for eligible deprecations after 2.0.
20:27 allison - The main focus there is the 'get_results' refactor, to move it *after* the call to 'set_returns'.
20:27 allison Next week:
20:27 allison - Will work on Debian/Ubuntu packaging for 2.0.
20:27 allison EOR
20:28 chromatic I'm still working on TT #389.  I think I have it cracked.
20:28 chromatic I have some GC tuning ideas to explore too.
20:30 Coke last two weeks:
20:30 Coke partcl: update to avoid issues with removal of Array
20:30 Coke parrot infrastructure: Tweety and Piper are gone.
20:30 Coke parrot tickets:
20:30 Coke TT #338 - remove dynpmc.pl
20:30 Coke TT #1145 - remove some deprecated functions.
20:30 Coke minor build updates, post one_make mergeback to trunk.
20:30 bacek joined #parrotsketch
20:30 chromatic Hello, everyone.
20:30 whiteknight hello
20:31 japhb o/
20:31 bacek aloha
20:31 japhb Thanks for the time change
20:31 Coke ~~
20:31 Tene Hi!
20:31 whiteknight +1 on time change
20:31 darbelo Hola
20:31 chromatic Let's review last week's priorities.
20:31 Util hrllo
20:31 NotFound hola
20:31 chromatic How are we doing on removing/demoting ops?
20:32 darbelo That didn't get done AFAIK.
20:32 chromatic I see a branch, but that's about it.
20:32 chromatic Okay.  Does anyone have time to work on that?
20:33 darbelo I might have time to do some op->dynop.
20:33 darbelo Not guaranteed. But likely
20:33 chromatic Fantastic.
20:33 chromatic Feel free to recruit anyone else with time.
20:33 chromatic How about VTABLE removals?
20:34 Coke (dynops need to have their build process changed, btw. I'll try not to step on toes)
20:34 bacek They are depend on op->dynops migration afaik.
20:34 darbelo Didin't the VTBALES block on the dynops?
20:34 chromatic That makes sense then.
20:35 cotto_working I took a shot at http://trac.parrot.org/parrot/ticket/866 and realized that it should be closed given allison's input.
20:35 cotto_working (vtable removal)
20:36 chromatic What should our current priority be for this week?
20:36 chromatic Are any branches close to merging?
20:36 bacek gc_enccapsulate almost done
20:37 whiteknight I'm looking forward to that one
20:37 chromatic Me too.
20:37 bacek I just need help with debugging.
20:37 bacek And little bit more spare time...
20:37 whiteknight I'll fire up the ol' debugger tonight
20:37 bacek whiteknight, excellent!
20:38 chromatic I'm trying to find a list of our 2.3 goals.
20:38 Coke i haz a q.
20:38 whiteknight 2q
20:39 chromatic Hm, the spreadsheet has 1) Improved GC 2) Subroutine leave/exit semantics 3) Core libraries/plumage
20:39 chromatic Can we make another weekly goal to work on #1?
20:39 whiteknight +1
20:39 bacek I will rewire Boehm again after gc_encapsulate finished
20:40 chromatic I can commit to writing notes on the size-based tuning idea I have as well as the sweepless GC.
20:40 chromatic Anyone else?
20:40 allison we need to go through the 2.6 road map items and spread them over 2.3
20:40 allison and also enter the 2.3 items from the google spreadsheet
20:41 chromatic Is there a Trac wizard?
20:41 whiteknight those three items that chromatic mentioned are pretty big. Can we add more to 2.3 without overbooking?
20:41 Coke chromatic: I can be the trac wizard.
20:41 whiteknight GC and another PCC refactor will eat up some major time
20:41 Coke and what whiteknight said.
20:42 allison whiteknight: currently the spreadsheet lists "subroutine leave semantics/exit handlers" also, and "Core Libraries/Plumage"
20:43 allison the latter seems like a different group of people than the GC/PCC refactors, so no trouble being parallel
20:43 allison I suspect the exit handlers is a feature needed for Perl 6, but again, that is listed as pmichaud/tene working on it, so wouldn't block
20:43 chromatic I'd rather focus on one or two things that we're confident we can do and have to take on additional work if we finish early than try to do many things at once.
20:43 Coke then we should ask those people when it will land, not assume it's going to be 2.3
20:44 allison I would question whether we can do the GC and PCC refactors for 2.3
20:44 allison since it's pretty much the same people
20:44 japhb re: Plumage, I am just beginning to get tuits back from being slammed the last couple months.  That puts me behind where I wanted to be; people who don't want to work on C code are welcome to spend tuits helping plumage
20:44 whiteknight GC is the bigger task of the two, methinks
20:44 allison whiteknight: agreed
20:45 allison PCC is in "final cleanup" mode, a few things we needed an extra deprecation cycle for
20:45 allison GC is really quite extensive, about where PCC was a year ago
20:45 allison (though, hopefully we can get through it faster than PCC did, using the dogpile method)
20:45 Tene PCC I'm confident I can help with.  GC and leave/exit handlers, much less confident.
20:46 allison how about, PCC for 2.3, GC we start now and deliver partial for 2.3, more complete for 2.6?
20:46 whiteknight I would be interested in more information about leave/exit handlers too, I might be able to help with that
20:46 chromatic We'll always be tweaking GC.
20:46 whiteknight allison: +1
20:47 allison chromatic: indeed, but there are a few substantial tasks we need to tackle this year
20:47 allison the first task is "make a list of tasks that we need to tackle this year"
20:47 Tene whiteknight: it mostly comes down to "Whenever we leave this block, in any way, run this code.
20:48 chromatic allison, I'll make a list of tasks for GC changes if you make a list of tasks for PCC refactoring.
20:48 whiteknight Tene: gotcha.
20:48 allison chromatic: already done on the PCC refactoring
20:49 allison (that was my focus on two 8 hour flights this week)
20:49 chromatic Excellent.
20:49 chromatic Other discussion about this?
20:49 Tene whiteknight: even "Most normal ways of leaving this block" would be helpful, for now.
20:49 bacek I can try to experiment with VTABLE swap idea for GC  from http://research.microsoft.com/en-us/um/p​eople/simonpj/papers/non-stop/index.htm
20:50 bacek We can have Generational GC almost for free.
20:50 whiteknight bacek: I saw that paper too, very interesting. I would help with that
20:51 chromatic Can you both write a task list for that?
20:51 bacek Yes.
20:51 chromatic Thank you.
20:52 allison there is a GCTasklist wiki page, we can revise/extend it
20:52 chromatic Let's move on to questions.
20:52 chromatic darbelo?
20:53 darbelo We nned a better name for the ImageIO PMC. Got any?
20:53 whiteknight PMCSerializer
20:54 darbelo Ok, I'll go with that.
20:54 chromatic whiteknight?
20:54 whiteknight Trancendental math ops are moving to dynlib. I would like to move them to a separate project entirely so we can provide a more complete set of trigonometric routines without letting feature creep happen in the parrot repo.
20:54 whiteknight is that cool, or do we keep them as-is in the repo?
20:55 darbelo Put in a deprecation notice and remove at the next deprecation cycle?
20:55 allison seems like a reasonable direction to head
20:55 whiteknight okay
20:55 whiteknight and question 2:
20:56 bacek +1
20:56 whiteknight Parrot array types have bad performance in certain operations. Would like to create specialized types that are optimized for particular purposes (PMCStack, PMCQueue, etc). Better performance at the expense of limited feature set. Do these kinds of things belong in the repo, or do I create a separate project?
20:57 allison I'd start separate, then move them into the core if they become widespread
20:57 allison (this is assuming that it's easy to install them)
20:57 whiteknight okay, that's what I was figuring.
20:57 whiteknight EOQ
20:57 japhb Whiteknight: Is the performance problem with current array types because A) There's no way you can optimize for each of these different purposes simultaneously, or B) because our array types haven't been all that optimized yet?  (Like how perl5's have a lot of heuristics to speed up common use cases)
20:57 japhb ?
20:58 Coke I think they were ``optimized'' many years ago.
20:58 whiteknight japhb: just a lot of operations to support, and memory is not as flexible
20:58 whiteknight push/pop/shift/unshift. It's hard to do those all well at the same time in the same object
20:58 whiteknight unshifting and pushing grows the array at both ends, which is hard to do without spamming memcpy
20:59 allison plus, they're general purpose, and so have to support more features than a restricted stack/queue
20:59 Coke I'm not sure that we have benchmarks of the behaviors we want to be fast/memory efficient
20:59 japhb Nod.  IIRC shift/unshift to implement a stack in perl5 (used to be?) much slower than push/pop to make a stack, so I see that point.
20:59 Coke Be nice to have requirements in place before we head off in (yet another) direction.
21:00 NotFound A deque can be good enough for stacks, queues, and such
21:00 allison Coke: it's true, but there are some classic aggregate datatypes that could be implemented pretty quickly
21:00 whiteknight I'll throw some prototypes together outside the repo, and anything we like we can move into core
21:00 whiteknight stacks and queues could be made very efficient. Sparse arrays would be nice too
21:00 japhb Can we namespace these beasties, please?  I'd like to have a decent library of efficient data structures, but not having them spam the top level PMC namespace.
21:00 Coke allison: sure, but writing code we don't need is a long standing problem we have that I'd like to avoid.
21:00 whiteknight japhb: done
21:00 * allison just implemented a general-purpose graph in C that might make a good PMC
21:01 allison Coke: agreed, especially on coding for YAGNI
21:01 chromatic Anything else on this?
21:01 allison Coke: call it a prototyping exercise, kept out of the core to reduce maintainence burden
21:01 whiteknight Coke: to ease your worries, I'm writing this code anyway. No loss. Just wondering where it should happen
21:02 bacek joined #parrotsketch
21:03 chromatic Coke, you had a question.
21:05 bacek joined #parrotsketch
21:05 Coke whiteknight: if there are no benchmarks or requirements, then outside core.
21:06 Coke chromatic: yes, can we get feedback on TT #679 (Rename Hash)
21:06 chromatic -1
21:06 Coke doesn't have to be here, but if anyone wants or doesn't want it, please comment on the ticket.
21:06 darbelo KeepTheNameItHasNowPlease
21:07 cotto_working -1
21:07 * allison looking
21:07 bacek -1
21:08 allison the alternate names are pretty clunky, I'm not really fond of any of them
21:08 allison but, I'm conscious of the fact that only Perl uses "Hash" like that
21:08 allison and, of the fact that our ordered arrays all go for descriptive names
21:08 Coke java has hashmap. there's ruby...
21:08 whiteknight python and .NET I think use Dictionary
21:08 allison also, that the single Hash name doesn't leave room for typed hashes
21:09 whiteknight PMCHashTable?
21:09 Coke we have no typed hashes and no plans to create one.
21:09 allison (StringHash, IntegerHash, whatever)
21:09 japhb Dictionary is officially A Sucky Name.
21:09 bacek allison, current Hash support native types
21:09 whiteknight An IntegerHash is really synonymous with a sparse array
21:09 whiteknight with maybe a few other methods
21:09 allison Coke: so, perhaps the question is "why do we have typed arrays"?
21:09 bacek we don't need typed Hashes
21:09 cotto_working We do kind of have typed hashes, but only from C.
21:09 Coke allison: an EXCELLENT question which I have been asking for some time. =-)
21:10 chromatic We're talking about renaming an intrinsic PMC used extensively everywhere.  That's a huge HLL tax for little benefit.
21:10 allison bacek: sort of
21:10 bacek chromatic, +1
21:10 allison Coke: I'm happy to close the "Hash rename" ticket and open a "unify arrays" ticket
21:10 darbelo +1
21:10 japhb +1
21:10 bacek cotto_working, nope. They are available from PIR
21:10 bacek allison, +1
21:10 allison (with the potential option to migrate the many types of arrays to an external repo)
21:11 Coke the question on the arrays should be, I think, the same one that should drive whiteknight's work: what are our requirements on containers, does what we have support that, and if not, how do we get there.
21:11 NotFound Just make sure that if we drop specialized arrays we don't have to recreate them immediately because of speed problems.
21:11 allison we've proved in CallContext that we can have typed storage in a single data structure, instead of forcing every element to be boxed/unboxed as a PMC
21:11 cotto_working +1 to array unification
21:11 whiteknight allison: we CAN do it, but lacks a certain efficiency
21:12 whiteknight -1 on unification, especially if we lose tons of performance
21:12 particle +1 on trying it out
21:12 Coke there is no proof we have performance now, is there?
21:12 Coke is there a benchmark we can look at?
21:12 allison whiteknight: it's certainly not as compact as a straight integer array that's one blob of memory,
21:12 whiteknight Coke: true, but we lose potential at least
21:12 bacek Coke, there is benchmark for arrays.
21:12 Coke let's /measure/ it before we worry aboutit.
21:12 allison and, we use those integer arrays heavily in the calling conventions at the moment
21:12 allison but, we can get around that
21:12 particle fixedintegerarray is the one important one
21:12 Coke bacek: excellent. then we can know if we lose anything.
21:13 NotFound Coke: I can wite one with winxed in a few minutes.
21:13 allison but, I'd really like to rip the fixedintegerarrays out of PCC anyway
21:13 particle convert that, benchmark with the unified array
21:13 whiteknight we WILL lose something, it's a measure of how much and how important that is
21:13 allison (cut down on the number of PMCs we create)
21:13 japhb Making a unified array implementation does not preclude having a special version that makes calling conventions faster.
21:13 allison japhb: or something within the CallContext PMC itself
21:14 japhb allison, right
21:14 allison yup
21:14 allison definitely worth exploring
21:14 Coke so, in any case, I'll close out the rename hash ticket.
21:14 * whiteknight has to leave now. Will backlog. Later
21:14 chromatic Other questions?
21:16 particle sorry i haven't been around much.  anything i need to know about, ping me in #parrot on privmsg me.
21:16 chromatic Last question: how does this time work for everyone?
21:16 bacek much better for me
21:16 Coke +0.5
21:17 cotto_working nicely
21:17 darbelo WFM
21:17 allison better for me too (I thought it was neutral, but it actually helps with the new class schedule this term)
21:17 chromatic Anyone it doesn't help?
21:17 allison did we get pmichaud?
21:17 japhb WFM
21:17 Util +0
21:18 * bacek have to go.
21:18 Tene works great for me
21:18 chromatic We didn't get pmichaud or dukeleto.
21:19 Tene pm was active in #perl6 during the meeting.
21:19 darbelo I think dukeleto was +1 for the new time.
21:19 allison then perhaps it's a matter of spreading the new time
21:20 allison (i.e. people getting used to the new time)
21:20 Coke chromatic sent out the email. need to do that a few more weeks in a row.)
21:20 Coke chromatic++
21:21 allison sounds like a "stick with the new time", I'll update my calendar
21:21 allison thanks chromatic!
21:21 Coke ... or you could just pull the event from the google calendar!
21:21 chromatic Thanks everyone; let's get back to work.
21:22 NotFound left #parrotsketch
21:24 rdice joined #parrotsketch
21:24 chromatic left #parrotsketch
21:37 bacek left #parrotsketch
21:48 plobsing left #parrotsketch
22:06 PacoLinux left #parrotsketch
22:11 allison joined #parrotsketch
23:08 cotto_w0rk joined #parrotsketch
23:09 cotto_work joined #parrotsketch
23:25 Whiteknight joined #parrotsketch

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