Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-02-16

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

All times shown according to UTC.

Time Nick Message
13:03 bluescreen joined #parrotsketch
13:26 bluescreen joined #parrotsketch
14:38 whiteknight joined #parrotsketch
15:14 whiteknight joined #parrotsketch
17:20 NotFound joined #parrotsketch
18:11 mikehh joined #parrotsketch
18:33 chromatic joined #parrotsketch
18:40 plobsing joined #parrotsketch
19:28 whiteknight WHAT I DID:
19:28 whiteknight * Created vtable_massacre branch. Deleted all deprecated VTABLE entries and merged back into trunk. Fixed a few resultant problems, but most things are looking mostly clean
19:28 whiteknight * Created op_pmcs branch to add Opcode and OpLib PMC types. These are basic types to allow reading of info from interp->op_lib. Ultimate goal is improved PIR->PBC compilation from PIR. Branch is ready for merge immediately after release, new PMCs are listed as "experimental".
19:28 whiteknight * Created tt_1449 branch and committed potential fix for the problem. Looking for input and test cases. Hoping to merge today after the release.
19:28 whiteknight * Created pmc_func_cleanup branch, aiming to fix function naming in src/pmc.c to be named Parrot_pmc_*. Work 90% complete. Will alert the mailing list with a table of all function names changed when the time comes.
19:28 whiteknight * Added a mechanism to retrieve the name of the current GC system from the interpinfo opcode, so tests can TODO or SKIP intelligently depending on the behavior of the GC
19:28 whiteknight * Deleted some older branches, pinged some responsible people to make decisions on others that are particularly old or unused
19:28 whiteknight WHAT I WILL DO:
19:28 whiteknight * Hoping to merge op_pmcs, tt_1449, and pmc_func_cleanup soon.
19:28 whiteknight * Need to update Parrot-Linear-Algebra and Parrot-Data-Structures projects with new Parrot_pmc_* function names.
19:28 whiteknight WHAT I AM BLOCKING ON:
19:28 whiteknight * Nothing
19:31 bubaflub joined #parrotsketch
19:31 darbelo joined #parrotsketch
19:32 bacek joined #parrotsketch
19:44 mikehh What I did since my last report:
19:44 mikehh * building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
19:44 mikehh * a lot of branch testing
19:44 mikehh * testing and fixing for 2.1 release
19:44 mikehh * quite a few fixes - adding ASSERT_ARGS etc.
19:44 mikehh What I intend to do in the next week:
19:44 mikehh * testing and fixing
19:44 mikehh * looking at cleaning up some tests
19:44 mikehh * documentation
19:44 mikehh .eor
19:45 NotFound What I did
19:45 NotFound - parrot
19:45 NotFound * Built and tested on Maemo - Nokia N900
19:45 NotFound - Winxed
19:45 NotFound * Tested bootstrapping without C++ in Maemo.
19:45 NotFound * More examples: http server, opengl, Xlib.
19:45 NotFound * Minor improvements.
19:45 NotFound What I will do:
19:45 NotFound * No plan
19:45 NotFound EOR
19:49 plobsing What I Did:
19:49 plobsing * created opengl_dynamic_nci branch
19:49 plobsing * lays groundwork for a better (yet still fairly simple) frame builder system
19:49 plobsing * ready for testing
19:49 plobsing * test protocol: make -j3, run examples/opengl/* (should panic on fail)
19:49 plobsing * created tt362 branch
19:49 plobsing * addresses TT362, todo in src/packfile.c
19:50 plobsing * proves value of work in pmc_freeze_cleanup & pmc_freeze_with_pmcs branches
19:50 plobsing * ready for testing (standard method)
19:50 plobsing What I Plan:
19:50 plobsing * merge opengl_dynamic_nci and tt362 branches
19:50 plobsing * remove nativecall.pl (replaced by nativecall.pir)
19:50 plobsing * make nativecall.pir installable (for use by extenders/embedders)
19:50 plobsing EOR
19:53 bacek What I did:
19:53 bacek - GC cleanup/encapsulate work.
19:53 bacek - Boehm GC in Parrot
19:53 bacek - PIRC headerizing
19:53 bacek Plan:
19:53 bacek Yay! My first #ps report :)
19:55 darbelo PAST
19:55 darbelo * Participated in the VTABLE massacre.
19:55 darbelo * Updated decnum-dynpmcs to the new world order.
19:55 darbelo * Thought a lot about cross-compilation and out build process. * Made the hints file overridable  on the Configure command line. * Looking at porting to RTEMS.  BIRDS IN SPACE!
19:55 darbelo * Released Parrot 2.1.0 "As scheduled." * Forgot to rename the ImageIO PMC.
19:56 darbelo FUTURE
19:56 darbelo * Write a pbc_dump replacement that exercises the PackFile PMCs.
19:56 darbelo * Maybe, do more cleanups on the ImageIO PMC.
19:56 darbelo BLOCKERS
19:56 darbelo * Life
19:56 darbelo * Universe
19:56 darbelo * Everything
19:56 darbelo END
19:58 chromatic What I Did:
19:58 chromatic * Fixed a few bugs
19:58 chromatic * Implemented the size threshold for the GC (to good effect)
19:58 chromatic * Checked in a few other optimizations
19:58 chromatic What I Will Do:
19:58 chromatic * TT #389 is tough, very tough
20:11 whiteknight joined #parrotsketch
20:18 Util # Done:
20:18 Util * Set up an Amazon EC2 account.
20:18 Util = It allows me to test many platforms ( (32|64)-bit (Linux|Win200[38]|OpenSolaris) ) very cheaply
20:18 Util ^ (but not cheap enough to run 24/7 as a build farm).
20:18 Util * Tested upcoming Parrot release.
20:18 Util * Updated PLATFORMS with 64-bit Linux entry from EC2 experiment.
20:18 Util = Cost: $0.19 USD
20:18 Util * Slowed down on TT #919 over the many meanings of "readline".
20:18 Util # Plan to do:
20:18 Util * Resume work on TT #919 and TT #1217.
20:18 Util # Blockers:
20:18 Util * $WORK.
20:18 Util .end
20:19 cotto_work #did:
20:19 cotto_work * vtable_massacre help
20:19 cotto_work * added some function docs, removed TODOs from approrpriate codingstd tests
20:19 cotto_work * made examples/c/nanoparrot.c compileable
20:19 cotto_work #will do:
20:19 cotto_work * pmichaud having time to look at ops_pct
20:19 cotto_work * brains
20:19 cotto_work #closed TTs:
20:19 cotto_work * #1423 (pirc breaks headerizer, bacek++ for the actual fixes)
20:19 cotto_work * #1383 (add --hash-seed to specify hash seed)
20:19 cotto_work #eor
20:20 bacek_ joined #parrotsketch
20:21 Tene Done: I have a patch that allows subclasses of Exception to be thrown.  I don't know whether it needs a deprecation cycle or not, as it's allowing new functionality, not breaking anything.
20:21 Tene Will do: Commit the patch after the release, and then work on adding class-based filters to ExceptionHandler.
20:21 Tene KTHXBAI
20:28 Tene Also: it would be great if someone could convince me that Parrot's roles support was good enough that I could allow anything that supports the Exception API to be thrown. (does 'exception').
20:29 Tene So, consider that my question.
20:29 Coke joined #parrotsketch
20:30 Coke some minor work in the rm_cflags branch this week. Try to kill CFLAGS, but replacing it with something that isn't broken is slightly more involved than just ripping it out.
20:31 whiteknight hello
20:31 NotFound hola
20:31 darbelo Hi.
20:31 cotto_work hi
20:31 bacek o hai
20:32 Coke ~~
20:32 whiteknight tildetilde
20:32 darbelo q2q
20:32 whiteknight q1q
20:32 cotto_work q0q
20:32 bacek q-1q
20:32 Util Hello
20:33 mikehh Hello
20:33 chromatic Hello everyone.  Let's begin.
20:35 chromatic How did we do on last week's goals?  What did we merge and what's yet to merge?
20:35 whiteknight vtable_massacre merged, to much fanfare
20:35 darbelo rm_cflags remains unmerged.
20:36 bacek gc_encapsulate branches merged
20:36 bacek (or it was last week?...)
20:36 cotto_work it was this week
20:37 Coke rm_cflags is proving slightly more complicated as it turns into "get a warnings free build for andy"
20:37 chromatic Keeping Andy happy is very good.
20:37 darbelo He used Sun cc, right?
20:37 Coke yes. all the warnings hoops never worked for non-gcc anyway.
20:37 allison joined #parrotsketch
20:38 chromatic Other successes from last week?
20:38 chromatic One of the GC tuning goals made it in; so far so good there.
20:39 darbelo pmichaud did some nqp updates as well.
20:40 chromatic Let's talk about goals for this week then.
20:41 chromatic Suggestions?  We need to fix TT #389 eventually and should fix TT #562 soon.
20:41 whiteknight #562 is the same as #768 and #1040, I think
20:41 whiteknight so fixing that mess could be a big help
20:42 chromatic It's definitely hurting HLLs.
20:43 whiteknight #784, I mean
20:43 chromatic allison, what's the status of the task list for get/set params/results ops changes?
20:44 allison tasklist is finished
20:44 allison ready to start work
20:44 allison starting on that could be a task for this week
20:44 whiteknight I've got 3 branches of my own to merge, then I would love to work on that
20:44 allison is the GC tasklist ready to work on?
20:44 chromatic One of the GC tasks is done.
20:45 whiteknight I think bacek is still working on another branch
20:45 allison it's a bit of a toss-up between those two
20:45 allison but, I think the PCC deprecation item will be pretty quick
20:45 chromatic Let's do the quick one first then.
20:45 particle gc has momentum, too
20:45 bacek There is last thing left for GC: sys_mem_reduce branch.
20:46 chromatic If we reduce the number of GCables creates for PCC, we win no matter what kind of GC we have.
20:46 allison ok, I'll start a branch for the PCC deprecations now
20:47 whiteknight allison++
20:47 chromatic I'll start a branch for the subclass MMD bugs.
20:47 dukeleto joined #parrotsketch
20:48 * dukeleto is here, but late
20:48 chromatic Any blockers we need to address?
20:49 mib_nunkyu joined #parrotsketch
20:49 chromatic Let's go to questions then.
20:49 chromatic Tene?
20:50 Tene I see there's some sort of 'does' support in Parrot.  hash.pmc "provides hash", etc.
20:51 Tene Is that exposed sufficiently that I could add "does exception" to exception.pmc, and check VTABLE_does in 'op throw', and it could nicely be used from HLLs?
20:51 Tene Or should I check explicitly for subclasses of parrot;Exception?
20:51 Tene VTABLE_isa?
20:51 chromatic It should work.  If it doesn't, it's a bug we need to fix.
20:51 Coke does doesn't really guarantee anything.
20:51 Tene Or is there a better way to check for implementing the desired interface?
20:51 whiteknight ancillary question: can "does" be made to guarantee something?
20:51 Coke and what it does, it does so very vaguely. (e.g. does "array")
20:52 Tene Also, does my desired change need a deprecation cycle?
20:52 bacek +1 for checking does (even if doesn't guarantee anything)
20:52 allison provides is very low-level, 'does' is higher-level, i.e. roles
20:52 Coke no, does is just provides.
20:52 Coke at least the last time I ranted about its lack of utility.
20:52 chromatic does and provides are synonyms in pmc2c
20:53 allison Coke: that wasn't the intention, we changed the name of the 'array', 'hash' etc from 'does' to 'provides' so we could use does for true role composition
20:53 allison Coke: but, it may still be in partial transition
20:53 Coke yes, but it doesn't work that way and never has and there is, SFAIK, no ticket to make it so.
20:54 Coke This may dovetail with wk's work on separating out the pmc array types. =-)
20:54 allison well, roles seem to have fallen by the wayside, so a better question is "how should it work?"
20:54 whiteknight maybe that's the way forward: start on a proper implementation of roles
20:54 chromatic That's a different question than what Tene asked though.
20:54 allison it seems sensible for 'does' to check provides
20:54 Tene I didn't see much coverage of roles in t/
20:54 allison he asked if 'provides' is exposed
20:54 allison and it is, through does
20:55 allison (or, if it isn't, should be)
20:55 Tene I meant to be asking "Is this what I should be using for exceptions"
20:55 Coke for now, sure, you can use does. I think "does" is probably better than "isa"
20:55 allison yes, inheritance isn't enough
20:55 Coke since isa assumes that every exception type inherits from Exception.
20:55 allison if you check does, that gives you "provides exception" for now, and any kind of exception composition later
20:56 Tene Okay, great.  I'll move forward on that.  One more question...
20:57 Tene pdd23 describes "exception;death" and other such exception classes.  Should those then be roles?  Can we do namespaced roles in pmcs?  can we do namespaced classes in pmcs?  if not, where should I define those classes or roles?
20:58 Tene "take it to the list" is a perfectly acceptable answer
20:58 allison there doesn't seem to be much value in having individual pmcs for each of those exception varieties
20:58 allison take it to the list is fine
20:58 dukeleto What I did: * Getting Parrot working on RTEMS and BUG (ARM) * worked on PL/Parrot * Gave a talk called "An Introduction to Parrot"
20:58 allison the quick answer is "keep it as lightweight as possible"
20:58 dukeleto What I will do: * Continue working on PL/Parrot * Setup my cross-compile environment so I can write a BitBake recipe for Parrot
20:58 dukeleto Blocking on: * Time to do stuff.
20:59 chromatic Workable for now, Tene?
20:59 allison Tene: right now those classes of exceptions are marked as attributes on the exception object
20:59 Tene I'm really looking forward to getting a better system than integer exception types in place.
20:59 Tene Yes, workable for now.  I'm done with my question.
20:59 chromatic darbelo, first question?
21:00 Tene allison: I'm very familiar with the current implementation. :)
21:00 darbelo I have some ideas for the gdbm dynpmc. But I think they might be better realized outside of the parrot core. Is there any objection to marking them DEPRECATED and continuing development elsewhere?
21:00 whiteknight +1
21:00 allison Tene: aye, I meant that as "this is one lightweight solution that seems to work pretty well, but not necessarily the only one"
21:01 * Tene nods.
21:01 chromatic How big are these changes, darbelo?
21:01 Coke I for one am not using gdbm in core, so I don't mind.
21:01 plobsing q2q
21:02 darbelo Almost a rewrite. I wanto to extend it to wrap all of the *dbm s.
21:03 darbelo And doing *that* in core would bloat the configure stage for little benefit.
21:03 chromatic Fair enough.
21:05 chromatic Any other comments on this?
21:05 cotto_work +1
21:05 NotFound 1
21:05 mikehh +1
21:05 chromatic Next question, darbelo?
21:06 darbelo We have several other under-used dynpmcs in the repo, that we don't really maintain. Should we push to move those out of the core?
21:07 whiteknight +1
21:07 darbelo I'm thinking for example of the various digest pmcs. Nobody uses or loves them.
21:07 darbelo I doubt most people even build them...
21:08 dukeleto darbelo: maybe they can move into parrot-data-structures ?
21:08 allison I'd be in favor of moving the digest dynpmcs out of the repo
21:08 allison (with a decent Plumage install strategy)
21:08 darbelo I can adopt those as well if we kick them out of the core.
21:09 mikehh if we can grab them from plumage, fine
21:09 whiteknight dukeleto: PDS is probably not suitable for those types
21:09 whiteknight but new repos are cheap
21:09 Util +0.1, if the Plumage versions become immediatly available.
21:10 darbelo Util: It should be trivial to acomplish that.
21:11 chromatic We need to check if any languages use those digest PMCs.
21:11 chromatic fperrad might know.
21:11 allison they'll be subject to the usual deprecation cycle, so can't be removed from Parrot until after 2.3, but could be added to external repo for development right away
21:11 mikehh +1
21:12 chromatic darbelo, how's that work for you?
21:12 dukeleto +1 to moving them out of core and into somewhere that is easily installable via Plumage
21:12 darbelo Works for me.
21:12 darbelo But my point was slightly larger than that.
21:12 Util darbelo: Fine, then. I agree that they don't belong as part of Parrot's core. I just got them building today, which is why I favor them :)
21:13 darbelo Do we want to move all non-essential modules out of core, like it was done for languages?
21:13 whiteknight +1
21:13 plobsing +1
21:13 cotto_work +1
21:14 allison +1
21:14 mikehh +1
21:14 chromatic +1 only if we get them installable and tested regularly.
21:14 darbelo A 'delete after adoption' policy would be the best, IMO.
21:14 bacek +1 if it's git submodule
21:14 Util +0. Why now?
21:15 NotFound Note that modules with C parts need a C compiler. Maybe we need a way to provide links to binaries for such things.
21:15 allison Util: it's not a new idea, it's one we've been working on gradually for over a year, and will continue working on for a year or so into the future
21:16 NotFound Or even without C parts, fakecutable bulding needs a compiler.
21:17 darbelo NotFound: decnum-dynpmcs is pretty much all C and it's lived fine out of core for ayear now.
21:17 NotFound darbelo: but now I have parrot on my phone, then I'm more worried about that things ;)
21:18 darbelo NotFound: I'm also working slowly on enabling parrot cross-compilation.
21:18 allison NotFound: the benefit is keeping the core small (i.e. so it can fit on more phones)
21:19 allison darbelo: the  on going question is which modules are needed in core, which is more of a mailing list question
21:19 Util allison: I will be happier when all such former-internal-now-externals can be downloaded and tested via some `make test_kitchen_sink` target. Then again, that was my objection when languages left the nest, too.
21:19 allison we've already trimmed pretty extensively, but there are a few more that could go
21:20 Util +1
21:20 allison Util: I would like to see an extensive test suite for externals too
21:20 allison Util: perhaps we could make it part of Plumage?
21:21 darbelo allison: plumage is growing support for that, yes.
21:21 allison excellent, that seems like the right place for it
21:21 Util allison: that would be great.
21:21 darbelo I think one of japhb's goals was to have 'plumage test all' command.
21:21 darbelo But we've wandered pretty far from the quistion.
21:21 bacek Can we have "make plumage" target in core?
21:22 darbelo +Inf
21:22 allison bacek: the intention last I heard was to do Plumage like we're doing nqp-rx
21:22 bacek allison, wfm
21:22 allison so, it's maintained externally, but a version is shipped in parrot core releases
21:23 * darbelo has no more questions.
21:24 chromatic Concrete conclusions: mark the PMCs in core as DEPRECATED, shim them into Plumage, and get Plumage in shape.  Does that sound right?
21:24 allison chromatic: affirmative
21:24 allison mark *some* PMCs in core as DEPRECATED
21:24 Coke wfm.
21:25 Tene I dunno, I bet we can get resizablepmcarray.pmc into plumage.
21:25 Coke Tene: *thwap*
21:25 chromatic plobsing, please ask one of your questions to end this mess.
21:25 allison it'd be nice to get down to one core array-ish type at some point
21:26 plobsing I pinged the list about opengl_dynamic_nci but noone complained, so I assume I can go forward with this?
21:26 whiteknight allison: the parrot-data-structures project is ready and able to accept displaced types
21:26 whiteknight plobsing: +1
21:26 NotFound +1
21:26 Coke plobsing: just get japh's buyin. everyone else will fall in.
21:26 plobsing Coke: haven't seen japhb in a while
21:27 whiteknight ...the OpenGL bindings could be moved to a separate project...
21:27 Coke plobsing: do your best (email?) and then don't worry about it.
21:27 plobsing whiteknight: that had crossed my mind
21:27 Coke ... or what whiteknight said.
21:27 whiteknight (so long as we are exorcising things en masse)
21:28 plobsing follow up question: do the signatures in config/gen/call_list/misc.in require a deprecation notice?
21:28 whiteknight i hope not
21:28 plobsing they only really worked by registration, so if your project isn't in there, you don't really have support right now
21:28 chromatic Are you thinking of removing some?
21:29 plobsing chromatic: as soon as we're able to ship a tool to generate sigs for library builders, I want to remove them all
21:29 whiteknight +1
21:29 Coke if there's a replacement, sure. in the meantime, yes, I'd call that part of the API.
21:29 * whiteknight is very agreeable today
21:29 NotFound What library builders?
21:30 plobsing anyone mentioned in config/gen/call_list/misc.in
21:30 plobsing examples: mod_parrot, python, etc
21:30 chromatic As long as we can bind to the same shared library APIs, no deprecation necessary.
21:30 NotFound If I need a library to use NCI, NCI is not such thing.
21:30 chromatic If you remove the ability to bind to a specific function, that's a deprecation.
21:31 * whiteknight has to sign off. Will direct all my questions to the list. Later
21:31 plobsing so short answer is yes, they need deprecation
21:32 chromatic Long answer: yes, if you remove something that people can do right now.
21:33 chromatic Other questions?
21:33 NotFound I don't think is a good idea to remove anything until we have a way to generate calls at runtime.
21:34 plobsing NotFound: that approach probably won't work everywhere
21:34 Coke chromatic: I bet my problem is that some people aren't using the "new" svn merge.
21:34 darbelo Coke: git-svn users for sure don't.
21:35 Coke e.g.:  ports/debian/parrot.install.in
21:35 Coke just added :
21:35 Coke /branches/op_pmcs/ports/debian​/parrot.install.in:43820-44044
21:35 Coke ... but that branch didn't touch that file, did it?
21:35 chromatic This isn't #parrot.
21:35 bacek Coke, wrong window?
21:35 Coke whoops. yes.
21:35 Coke I was going to blame darbelo, but I started it. =-)
21:35 chromatic plobsing, we might need more discussion on this.  Can you mail the list?
21:36 plobsing chromatic: sure
21:36 chromatic Any other questions?
21:38 chromatic No?  Let's call this a week then.  Developers wanted on the two focus branches.
21:38 Coke left #parrotsketch
21:39 NotFound left #parrotsketch
21:42 bluescreen joined #parrotsketch
22:01 allison (Looks like chromatic didn't copy in my report when I thought I couldn't make it, so...)
22:01 allison Last week:
22:01 allison - Worked on Pynie, build cleanups to make sure it works with current parrot.
22:01 allison - Preparing Pynie talk for PyCon.
22:01 allison - Further work on mini-language, talked with Patrick about possible nqp-rx bug.
22:01 allison Next week:
22:01 allison - Speaking at PyCon and participating in VM and Python implementations summits.
22:01 allison - Start on PCC deprecations to reverse order of 'set_returns' and 'get_results' (to the "natural" order.)
22:01 allison EOR
22:16 darbelo left #parrotsketch
22:18 chromatic left #parrotsketch
22:22 Whiteknight joined #parrotsketch
22:35 PacoLinux left #parrotsketch
23:48 dukeleto left #parrotsketch

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