Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-08-04

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

All times shown according to UTC.

Time Nick Message
00:07 davidfetter joined #parrotsketch
14:35 whiteknight joined #parrotsketch
14:43 jimka joined #parrotsketch
16:13 nillo joined #parrotsketch
16:17 moritz joined #parrotsketch
16:21 mikehh joined #parrotsketch
16:22 satrac joined #parrotsketch
16:22 kj joined #parrotsketch
16:23 satrac left #parrotsketch
16:26 kj First report since February 2009 (or so).
16:26 kj * Not much to report, more saying "Hi, I'm still here"
16:26 kj * made a few commits to prepare the conversion from C strings (char *) to STRINGs
16:26 kj * Will not have much time due to $work (which is research related to OSS) but plan to spend bits here and there if I have tuits.
16:26 kj EOR
16:26 kj * FYI, the mentioned work is for compilers/PIRC.
16:27 kj EOR
16:27 dukeleto joined #parrotsketch
16:28 NotFound joined #parrotsketch
16:56 whiteknight What I did:
16:56 whiteknight * Added a new fixed-size object allocator to the GC, especially to help decrease costs of PMC attribute structure allocation
16:56 whiteknight * Following along enthusiastically with TT #895 (NotFound++)
16:56 whiteknight * Prototyped a lazy pool allocator on suggestion from chromatic++
16:56 whiteknight * Bought a copy of the book, read it cover-to-cover, already brainstorming ideas to make it bigger/better/gold-plated
16:56 whiteknight What I will do:
16:56 whiteknight * Help with TT #895
16:56 whiteknight * Attempt to add the lazy allocator to the PObj pools and do some benchmarks to see if it improves startup time
16:56 whiteknight * Still hoping to work on io_cleanups
16:56 whiteknight What I am blocking on:
16:56 whiteknight * Not enough time
17:10 moritz I'll not be online during #ps meeting; don't have anything interesting to report either
17:14 Topic for #parrotsketchis now Vision for 2.0: Production Users | https://trac.parrot.org/parrot/w​iki/ProposedParrotsketchProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
17:14 Coke joined #parrotsketch
17:14 Coke left #parrotsketch
17:14 Coke joined #parrotsketch
17:15 treed joined #parrotsketch
17:31 Tene Last week:
17:31 Tene * Helped treed with Cardinal
17:31 Tene * Looked for some way to poll() or select() FDs in Parrot, found the apparently-unused Parrot_io_poll, added it as a method to the Socket PMC.
17:31 Tene * Not sure if that's where it belong, or if that's even correct.  Still no way to select() from a list a FDs.
17:31 Tene Coming week:
17:31 Tene * No plans yet, and I'm starting to have more tuits available.  I'm considering working on IO stuff.l
17:34 davidfetter joined #parrotsketch
17:36 NotFound What I did:
17:36 NotFound * Implemented and tested an idea for automatic attribute allocation, TT #895
17:36 NotFound * Some tests with this and the fixed-size allocator (whitenight++)
17:36 NotFound * Several cleanups that will help the transition and testing of the former.
17:36 NotFound * Implemented a last resort attempt to show exception messages in corner cases.
17:36 NotFound * Some minor fixes and cleanups.
17:36 NotFound What I will do:
17:36 NotFound * More work in TT #895 and related issues.
17:37 PacoLinux joined #parrotsketch
17:50 treed Posting at Tene's suggestion (Cardinal dev here; hiya!)
17:50 treed What I've Done:
17:50 treed * Not much in the past week, mostly messed around with the test suite.
17:50 treed * I did enable precompilation as part of that, which can save a great deal of time spent parsing. (25 seconds for test:all rather than 6+ minutes; still well above the 2-3 seconds it takes for cruby, but it does help a lot when running the test suite often.)
17:51 treed * Keeping up with the fork queue and occasionally helping joeri/danius. (They don't need much help, though.)
17:51 treed What I Expect To Do:
17:51 treed * I've been cooking up a fix for assignment (http://github.com/cardinal​/cardinal/issues#issue/23) in my head. I took a whack at it a few weeks ago, but failed to take some things into account. I expect to at least make another attempt in the next week.
17:51 treed * I may start working on revising the object model and renaming CardinalClasses to just Classes.
17:51 treed What I'm Blocking On:
17:51 treed * Kinda still in the process of moving/looking for a job, which is taking some of my time.
17:51 treed * Not much in Parrot, AFAICT. Mostly my own ignorance.
17:51 treed * Could maybe use some help figuring out if http://github.com/cardinal​/cardinal/issues#issue/31 is related to the Parrot side or my own ignorance. Sent a purl-gram to pmichaud, at Tene's suggestion, about it, haven't heard back yet.
18:11 allison joined #parrotsketch
18:14 Util joined #parrotsketch
18:16 chromatic joined #parrotsketch
18:16 Util # Done:
18:16 Util * Researched Coverity RETURN_LOCAL defects in NCI functions of PMCs. No conclusions yet.
18:16 Util # Plan for next week:
18:16 Util * NULL
18:16 Util # Blockers:
18:16 Util * 0 tuits until next Monday.
18:16 Util .end
18:16 chromatic Reviewing and fixing and closing some Coverity defects.
18:16 chromatic Still working on pluggable runcores; blocking on time and energy.
18:16 chromatic Will continue.
18:17 allison - My week was mostly absorbed by visa application. Nothing left to do there but wait.
18:17 allison - For the next two weeks I'll be working only on Parrot, will see how far I can push the pcc_rewiring branch.
18:17 allison EOR
18:33 cotto # What I did:
18:33 cotto * made SUPER dtrt for dynpmcs (darbelo needed this)
18:33 cotto - also ripped out DYNSUPER, since we no longer have the compiletime/runtime distinction
18:33 cotto - created a nice memory leak in the process
18:33 cotto * wrote a simple proof-of-concept profiling runcore (not committed)
18:33 cotto - am hacking the slow runcore so I'm not blocking on chromatic's pluggable_runcore work
18:33 cotto - started (and killed and restarted) a script to postprocess profiling output for kcachegrind
18:33 cotto - can profile simple PIR programs but Rakudo hello world segfaults
18:33 cotto - imcc's poor line numbering is going to get more painful once we have a profiler
18:33 cotto # What I hope to do and how many tuits I expect to have:
18:33 cotto * get the runcore working with HLLs
18:33 cotto - add support for HLL annotations
18:33 cotto - confirm (and fix) profiling fancy control structures (exceptions, coroutines, etc)
18:33 cotto * integration with pluggable_runcore whenever it's ready
18:33 cotto # What could block my progress:
18:33 cotto * no apparent blockers on the horizon
18:33 cotto .eor
18:34 whiteknight Hello
18:34 NotFound hola
18:34 allison hi
18:34 Util hi
18:34 kj hi
18:34 chromatic hello
18:35 Tene Hi!
18:35 cotto hi
18:37 chromatic I suppose we should do roadmap review.
18:37 chromatic Runloops: in progress, blocking some on me.
18:37 allison https://trac.parrot.org/parrot/report/14
18:38 chromatic Profiling tools: blocking on runloops.  I will fix that.
18:38 chromatic Vtable swap: bacek and I discussed some different ideas; he put his on the wiki.  Needs review from allison.
18:38 chromatic (probably needs review from me)
18:38 chromatic Packfile PMCs; do we have an Infinoid?
18:39 chromatic sounds like a no
18:39 chromatic kj, what's the status of pirc?
18:39 Tene has kj even been around lately?
18:40 chromatic He just said hi.
18:40 kj not much changed since i left it for what it is in February. major problem is some bugs of storing NUMs and STRINGs in the constant table
18:40 Tene ... right, reading...
18:40 allison kj: what's your estimate of what's left?
18:40 kj i just don't understand what's going on. i've started to think about converting char * (c strings) into parrot STRINGs
18:41 allison we were talking about where to schedule it last week
18:41 kj quite some work if done by myself. Reasons are: no gdb skills... (more)
18:41 kj need to look into bytecode generator, which is mostly code copied from IMCC (and hence not very trustworthy)...
18:42 kj and STRING conversion will take quite a bit of work throughout PIRC
18:42 kj .
18:42 chromatic Do you have a list of tasks and places other people can help?
18:42 NotFound I'm thinking about doing some reworking of the unescape functions, that may help?
18:42 kj there's some TTs for the bugs/problems with NUM and STRING constants
18:43 kj NotFound: PIRC stores all strings as char *. That should change to use STRINGs only
18:43 chromatic How about further development tasks?
18:43 kj since C strings are evil, so I have been told (and I'm convinced)
18:43 allison As a rough estimate, how does 2.6 (next July) sound?
18:44 kj it's really hard to say :-(
18:44 kj STRING conversion is straightforward (but not trivial)
18:44 allison kj: It's just an estimate, and we can always reschedule.
18:44 chromatic Let's get a couple of people to help with the constants issue.
18:45 kj bytecode bugs are no fun, and I'm not looking fwd to debug those
18:45 allison kj: Mainly, I want the schedule to reflect our priorities.
18:45 * davidfetter doesn't see sandbox anywhere on that roadmap :(
18:45 kj once that's done, there's probably some small tasks, but those shouldn't be too hard.
18:46 chromatic Let's try to get Infinoid's attention there in the short term.  He did a lot of the Packfile PMCs.
18:46 * whiteknight needs Infinoid to finish his pipes implementation first
18:47 chromatic Can someone create a PIRC page on the Wiki with links to the appropriate tickets?
18:47 kj I guess I could do that
18:47 chromatic Thanks!
18:47 whiteknight kj++
18:47 chromatic Seed libraries?
18:48 chromatic Anyone?
18:49 Tene Parrot's mysql is bitrotted
18:49 allison we kept that to break out into one per month
18:49 allison so, pick one seed library to fix up for 1.5
18:49 NotFound Tene: you mean the one in examples?
18:49 Tene Is there a list anywhere of desired seed libraries, or a proposition on where we're going to store the libraries?  In Parrot svn?  Somewhere else?  Wasn't there an argument about this on the ml?
18:50 Tene NotFound: yes.
18:50 NotFound Tene: I lacked the time to fix it after some nci changes.
18:50 chromatic japhb's post was a summary, I think.
18:51 allison Tene: the ticket has a generic list, but needs to be broken down into more detailed smaller items
18:51 allison perhaps a "what libraries should Parrot provide?" thread on the mailing list?
18:51 * japhb rezzes in
18:51 NotFound I think that we must not do configure checks for libraries, except in corner cases like opengl. Do all at runtime.
18:52 chromatic We'll have to improve our library searching then.  It gets tricky across platforms.
18:52 japhb allison: My last ML post had the basic heirarchy structure.  I do think it is time to decide what goes into layer 1 and possibly 2.
18:52 NotFound I added some comments in a postgresql ticket,
18:52 allison japhb: okay, I'll look for and respond to that message this week
18:53 Tene Should japhb's last post go into the ticket?
18:53 allison Tene: probably, yes
18:53 * allison hasn't seen it yet
18:54 japhb allison: thread 'Re: Parrot "standard libraries"', last post was me summarizing the ideas that pmichaud and I discussed last Friday.
18:55 Tene http://lists.parrot.org/pipermail​/parrot-dev/2009-July/002666.html
18:55 japhb Thanks, Tene
18:55 allison thanks japhb/Tene
18:55 allison back to vtable swap, if we're still in design phase, that's not a 1.5 deliverable
18:56 allison is that a 1.7 deliverable?
18:56 chromatic 1.7 is very likely.
18:56 allison okay, changed
18:56 einstein joined #parrotsketch
18:57 allison do we want to do questions before the 2.0 roadmap review?
18:57 chromatic Yes.
18:57 chromatic I'd like to get mikehh a commit bit; he's very good about coding standards and catching failing tests.
18:57 chromatic His patches are fine and he's had the lecture.  His CLA is on the way.
18:57 chromatic Comments?
18:57 NotFound +1
18:57 allison +1 from me
18:58 Tene +1
18:58 Util +1
18:58 Tene q1q
18:58 moritz +1
18:58 chromatic Alright, I'll keep an eye out.
18:58 NotFound q2q
18:59 chromatic Tene?
18:59 Tene I noticed recently that there's apparently no way in Parrot to select() on a list of FDs.  Is that a scheduled capability, and if so, when?  I don't think I see anything in the roadmap that looks like it would include it, but I'm full of reading fail today.
19:00 allison there's no select in the I/O pdd
19:00 whiteknight I'm planning to add it in AIO, but it could be added before that if necessary
19:00 chromatic Seems like a standard feature.
19:00 whiteknight A Select PMC would be a nice addition
19:01 Tene I don't see AIO on the roadmap.  Should it be there?
19:01 whiteknight there's a ticket, I don't know how things get into the roadmap
19:01 allison whiteknight: we talk about it here and decide if it should go in the roadmap
19:01 allison (and when)
19:02 allison yes, async I/O should be added
19:02 Tene Okay, I'm done.
19:02 allison not a 2.0 priority
19:02 allison 2.6 or 3.0?
19:02 whiteknight I plan to start on it as soon as the pipes implementation is finished, so I suspect it will be in long before 2.6
19:02 allison whiteknight: what's the ticket #?
19:02 whiteknight let me look
19:03 whiteknight TT #31
19:03 allison whiteknight: roadmap items are scheduled by "reasonable expectation of a stable and complete implementation", rather than "the soonest we could have it completed"
19:04 allison (so, more on the conservative estimate side)
19:04 Tene threads doesn't seem to be on the roadmap anywhere either.
19:04 whiteknight that's fair. I say 2.6
19:04 allison Tene: 3.0
19:04 Tene allison: thanks
19:04 chromatic NotFound?
19:05 NotFound TT   #872, kill PASM1 pseudo-compiller
19:06 chromatic Hearty thumbs up here.
19:06 whiteknight what does that compiler even do (or, what was it intended to do)?
19:07 allison +1
19:07 NotFound whiteknight: it was supposed to make work the eval instruction of the debugger, but it doesn't work since long time ago.
19:07 whiteknight ok
19:07 allison it was used in early testing of compreg
19:08 allison get in a deprecation notice for 2.1
19:08 NotFound allison: the question was kill it, not deprecate it.
19:09 chromatic First the one, then the other.
19:09 allison we have a deprecation policy for a reason, we stick to it
19:09 chromatic Unless it never worked.
19:09 allison it was never fully functional, but id does work in a limited way
19:10 NotFound allison: I'd verified that it not worked at all in 1.0
19:11 NotFound Or a least, I'm unable to find any way to use it that works,
19:11 allison NotFound: fair enough, we can change it to throw a clean exception stating that it's been deprecated
19:11 allison (that's better than a segfault)
19:11 NotFound (sigh) ok.
19:12 chromatic Next question?
19:13 NotFound Next question: TT  #895 requires a change in the vtable layout. Cant that be commited or need a deprecation cycle?
19:13 allison NotFound: depends on if it's adding or removing features (checking)
19:14 NotFound Just adding a member to the vtable structure
19:14 allison it's purely internal, doesn't remove any existing functinality, and not visible to the user, so not subject to deprecation policy
19:15 NotFound Ok :)
19:15 chromatic ... but it has binary compatibility implications.
19:15 allison done on a branch, we can test if it helps or hurts speed
19:16 allison chromatic: if we don't freeze the struct size, then it's not a change to the bytecode
19:16 whiteknight with recent changes to the GC, it should be a good net win
19:16 chromatic If you add a member to a struct, any compiled code which uses that struct will act differently.
19:16 chromatic ... depending on where you add it.
19:16 NotFound I was trying to avoid the need to learn how to branch, but ok ;)
19:17 NotFound We can put it at the end of the structure, to minimize the changes.
19:17 chromatic I'm not sure the vtable processor works that way.
19:17 chromatic If we don't guarantee binary compatibility for extensions, that's not a problem.
19:17 chromatic I just raise it in case we do.
19:17 allison chromatic: binary compatibility isn't on our current list of guarantees
19:17 allison chromatic: maybe by 3.0
19:18 chromatic Thought so.  Thanks.
19:18 NotFound EOQ
19:19 chromatic Other questions?
19:20 davidfetter am i the only one who thinks parrot needs a restricted execution environment?
19:20 chromatic No.
19:20 Tene No.
19:21 allison quick triage on the 2.0 roadmap items?
19:21 chromatic +1
19:21 allison okay
19:21 allison garbage collectable contexts
19:22 allison for 2.0 or not?
19:22 allison if so, by when?
19:22 chromatic If we can get PCC rewiring, yes.
19:22 allison okay, so keep, but later in 6 months
19:22 allison will say.... 1.9
19:22 allison pdd15-objects is a design review
19:23 allison should happen earlier, say... 1.6
19:23 allison bytecode migration, generation, and testing
19:23 allison for 2.0 or not?
19:23 chromatic Seems like the point it's necessary.
19:23 allison if so, by when? and who is working on them?
19:24 NotFound Fixing the packfile pmcs is not a prerequisite for that?
19:24 chromatic <crickets />
19:25 whiteknight I thought the packfile PMCs were fixed?
19:25 allison chromatic: necessary for 2.0? or just generally desirable in the not-too-distant future?
19:26 chromatic I think it's well within the vision of 2.0.
19:26 NotFound whiteknight: his tests they keep failing sometimes at least in amd64 for no apparent reason.
19:26 chromatic But if we retain bytecode compatibility until 2.6, 2.6 is the latest point at which it makes sense.
19:26 Tene for migration, 2.0 is the first release that we start caring, so we won't *need* a migration tool until the first release *after* 2.0 where bytecode is changed.
19:27 allison bytecode generation from post is part of pirc, so probably makes sense to bump that to 2.6
19:27 allison bytecode testing should be the first priority
19:27 chromatic Should we break it into separate items then?
19:28 allison bytecode migration tool is nice to have soon, but not an ultra high priority (i.e. not next month)
19:28 allison it's three tickets, I was just mentally lumping them together
19:28 allison bytecode testing for 1.7?
19:29 chromatic We have to figure out what that means.
19:29 allison bytecode migration tool for 1.8, but an understanding that it's okay if it's post 2.0?
19:29 allison chromatic: yes, that's the first step in working on the task
19:29 NotFound We have still pending the problem of encoding no stored in PBCs...
19:29 chromatic Lots of things aren't stored in PBCs.
19:30 allison chromatic: right now want to stick to quick triage
19:30 Tene if we don't have any volunteers to work on these, should we put out a call for volunteers?
19:30 NotFound TT #468
19:30 allison testing and documentation sprint for 1.8?
19:30 Tene that's where I'd put it.
19:31 particle if we don't have bytecode compat by 2.0, we should at least be able to include hll source in the pbc files for (re)compilation
19:31 Tene maybe documentation for 1.9
19:31 allison okay, testing for 1.8, documentation for 1.9
19:31 NotFound The encoding is an important one. For example, utf16 strings doesn't work,
19:33 allison particle: we'll still follow bytecode deprecation cycles, but I don't know that we'll offer bytecode backward compatibility until 3.0
19:34 allison particle: including source in the bytecode files wouldn't be my ideal solution
19:34 allison particle: if they want to include source files, ship the source files
19:35 allison pge, debug and visibility, tools
19:35 particle if the source files are lost, there is no hope of running on future parrot
19:35 particle oh well.
19:35 allison patrick's not here, so will review that one next week
19:35 NotFound particle: you can use the pbc disassembler from that version
19:36 allison particle: I'm not following your logic, but we can talk about it more on #parrot or mailing list
19:36 allison prune c data structures
19:36 particle agreed, this meeting is *long* already
19:36 allison for 2.0 or not?
19:37 chromatic Yes please.
19:37 allison it's fundamental change, so should be early
19:37 allison (leaving plenty of time for testing)
19:37 allison 1.6?
19:37 chromatic It's not that big, but we shouldn't do it in the final month.
19:37 allison right, it's small but significant
19:38 chromatic Let's tackle one or two significant structs every month.
19:38 allison chromatic: sounds good
19:38 allison chromatic: I'll put it at 1.5 so we remember to break it down into 1 per month
19:38 chromatic I'll work on that tomorrow.
19:39 allison the last is user mailing list, which I'll put at 1.8
19:39 allison (enough time so it's in place for 2.0)
19:39 allison that's it for roadmap review
19:40 Tene Do we want to have a development priority for this week?
19:41 Tene I remember some kind of mention of tha tin the past?
19:41 chromatic Removing deprecated features?
19:42 allison aye, that's a good priority for the month
19:42 japhb Vision for 2.0: Production Users | Priority for 1.5: Remove Deprecated Features | https://trac.parrot.org/parrot/w​iki/ProposedParrotsketchProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
19:43 japhb gah
19:43 Tene maybe that should go in #parrot too?
19:43 Topic for #parrotsketchis now Vision for 2.0: Production Users | Priority for 1.5: Remove Deprecated Features | https://trac.parrot.org/parrot/w​iki/ProposedParrotsketchProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
19:44 japhb Tene: done
19:46 japhb meeting over?
19:47 chromatic yes; adjourn
19:47 Util left #parrotsketch
19:47 allison thanks all!
19:47 chromatic left #parrotsketch
19:48 moritz left #parrotsketch
19:49 NotFound left #parrotsketch
19:51 allison left #parrotsketch
19:57 treed left #parrotsketch
19:59 nillo left #parrotsketch
20:48 PacoLinux left #parrotsketch
21:05 Whiteknight joined #parrotsketch
21:27 Coke left #parrotsketch
22:00 cotto joined #parrotsketch
22:38 particle joined #parrotsketch

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