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.
13:03 bluescreen joined 13:26 bluescreen joined 14:38 whiteknight joined 15:14 whiteknight joined 17:20 NotFound joined 18:11 mikehh joined 18:33 chromatic joined 18:40 plobsing joined
whiteknight WHAT I DID: 19:28
* 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
* 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".
* Created tt_1449 branch and committed potential fix for the problem. Looking for input and test cases. Hoping to merge today after the release.
* 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.
* 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
* Deleted some older branches, pinged some responsible people to make decisions on others that are particularly old or unused
WHAT I WILL DO:
* Hoping to merge op_pmcs, tt_1449, and pmc_func_cleanup soon.
* Need to update Parrot-Linear-Algebra and Parrot-Data-Structures projects with new Parrot_pmc_* function names.
WHAT I AM BLOCKING ON:
* Nothing
19:31 bubaflub joined, darbelo joined 19:32 bacek joined
mikehh What I did since my last report: 19:44
* building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
* a lot of branch testing
* testing and fixing for 2.1 release
* quite a few fixes - adding ASSERT_ARGS etc.
What I intend to do in the next week:
* testing and fixing
* looking at cleaning up some tests
* documentation
.eor
NotFound What I did 19:45
- parrot
* Built and tested on Maemo - Nokia N900
- Winxed
* Tested bootstrapping without C++ in Maemo.
* More examples: http server, opengl, Xlib.
* Minor improvements.
What I will do:
* No plan
EOR
plobsing What I Did: 19:49
* created opengl_dynamic_nci branch
* lays groundwork for a better (yet still fairly simple) frame builder system
* ready for testing
* test protocol: make -j3, run examples/opengl/* (should panic on fail)
* created tt362 branch
* addresses TT362, todo in src/packfile.c
* proves value of work in pmc_freeze_cleanup & pmc_freeze_with_pmcs branches 19:50
* ready for testing (standard method)
What I Plan:
* merge opengl_dynamic_nci and tt362 branches
* remove nativecall.pl (replaced by nativecall.pir)
* make nativecall.pir installable (for use by extenders/embedders)
EOR
bacek What I did: 19:53
- GC cleanup/encapsulate work.
- Boehm GC in Parrot
- PIRC headerizing
Plan:
Yay! My first #ps report :)
darbelo PAST 19:55
* Participated in the VTABLE massacre.
* Updated decnum-dynpmcs to the new world order.
* 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!
* Released Parrot 2.1.0 "As scheduled." * Forgot to rename the ImageIO PMC.
FUTURE 19:56
* Write a pbc_dump replacement that exercises the PackFile PMCs.
* Maybe, do more cleanups on the ImageIO PMC.
BLOCKERS
* Life
* Universe
* Everything
END
chromatic What I Did: 19:58
* Fixed a few bugs
* Implemented the size threshold for the GC (to good effect)
* Checked in a few other optimizations
What I Will Do:
* TT #389 is tough, very tough
20:11 whiteknight joined
Util # Done: 20:18
* Set up an Amazon EC2 account.
= It allows me to test many platforms ( (32|64)-bit (Linux|Win200[38]|OpenSolaris) ) very cheaply
^ (but not cheap enough to run 24/7 as a build farm).
* Tested upcoming Parrot release.
* Updated PLATFORMS with 64-bit Linux entry from EC2 experiment.
= Cost: $0.19 USD
* Slowed down on TT #919 over the many meanings of "readline".
# Plan to do:
* Resume work on TT #919 and TT #1217.
# Blockers:
* $WORK.
.end
cotto_work #did: 20:19
* vtable_massacre help
* added some function docs, removed TODOs from approrpriate codingstd tests
* made examples/c/nanoparrot.c compileable
#will do:
* pmichaud having time to look at ops_pct
* brains
#closed TTs:
* #1423 (pirc breaks headerizer, bacek++ for the actual fixes)
* #1383 (add --hash-seed to specify hash seed)
#eor
20:20 bacek_ joined
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
Will do: Commit the patch after the release, and then work on adding class-based filters to ExceptionHandler.
KTHXBAI
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:28
So, consider that my question. 20:29
20:29 Coke joined
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:30
whiteknight hello 20:31
NotFound hola
darbelo Hi.
cotto_work hi
bacek o hai
Coke ~~ 20:32
whiteknight tildetilde
darbelo q2q
whiteknight q1q
cotto_work q0q
bacek q-1q
Util Hello
mikehh Hello 20:33
chromatic Hello everyone. Let's begin.
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
darbelo rm_cflags remains unmerged.
bacek gc_encapsulate branches merged 20:36
(or it was last week?...)
cotto_work it was this week
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.
darbelo He used Sun cc, right?
Coke yes. all the warnings hoops never worked for non-gcc anyway.
20:37 allison joined
chromatic Other successes from last week? 20:38
One of the GC tuning goals made it in; so far so good there.
darbelo pmichaud did some nqp updates as well. 20:39
chromatic Let's talk about goals for this week then. 20:40
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
so fixing that mess could be a big help
chromatic It's definitely hurting HLLs. 20:42
whiteknight #784, I mean 20:43
chromatic allison, what's the status of the task list for get/set params/results ops changes?
allison tasklist is finished 20:44
ready to start work
starting on that could be a task for this week
whiteknight I've got 3 branches of my own to merge, then I would love to work on that
allison is the GC tasklist ready to work on?
chromatic One of the GC tasks is done.
whiteknight I think bacek is still working on another branch 20:45
allison it's a bit of a toss-up between those two
but, I think the PCC deprecation item will be pretty quick
chromatic Let's do the quick one first then.
particle gc has momentum, too
bacek There is last thing left for GC: sys_mem_reduce branch.
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
whiteknight allison++ 20:47
chromatic I'll start a branch for the subclass MMD bugs.
20:47 dukeleto joined
dukeleto is here, but late 20:48
chromatic Any blockers we need to address?
20:49 mib_nunkyu joined
chromatic Let's go to questions then. 20:49
Tene?
Tene I see there's some sort of 'does' support in Parrot. hash.pmc "provides hash", etc. 20:50
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
Or should I check explicitly for subclasses of parrot;Exception?
VTABLE_isa?
chromatic It should work. If it doesn't, it's a bug we need to fix.
Coke does doesn't really guarantee anything.
Tene Or is there a better way to check for implementing the desired interface?
whiteknight ancillary question: can "does" be made to guarantee something?
Coke and what it does, it does so very vaguely. (e.g. does "array")
Tene Also, does my desired change need a deprecation cycle? 20:52
bacek +1 for checking does (even if doesn't guarantee anything)
allison provides is very low-level, 'does' is higher-level, i.e. roles
Coke no, does is just provides.
at least the last time I ranted about its lack of utility.
chromatic does and provides are synonyms in pmc2c
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
Coke: but, it may still be in partial transition
Coke yes, but it doesn't work that way and never has and there is, SFAIK, no ticket to make it so.
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?"
whiteknight maybe that's the way forward: start on a proper implementation of roles
chromatic That's a different question than what Tene asked though.
allison it seems sensible for 'does' to check provides
Tene I didn't see much coverage of roles in t/
allison he asked if 'provides' is exposed
and it is, through does
(or, if it isn't, should be) 20:55
Tene I meant to be asking "Is this what I should be using for exceptions"
Coke for now, sure, you can use does. I think "does" is probably better than "isa"
allison yes, inheritance isn't enough
Coke since isa assumes that every exception type inherits from Exception.
allison if you check does, that gives you "provides exception" for now, and any kind of exception composition later
Tene Okay, great. I'll move forward on that. One more question... 20:56
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:57
"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
take it to the list is fine
dukeleto What I did: * Getting Parrot working on RTEMS and BUG (ARM) * worked on PL/Parrot * Gave a talk called "An Introduction to Parrot"
allison the quick answer is "keep it as lightweight as possible"
dukeleto What I will do: * Continue working on PL/Parrot * Setup my cross-compile environment so I can write a BitBake recipe for Parrot
Blocking on: * Time to do stuff.
chromatic Workable for now, Tene? 20:59
allison Tene: right now those classes of exceptions are marked as attributes on the exception object
Tene I'm really looking forward to getting a better system than integer exception types in place.
Yes, workable for now. I'm done with my question.
chromatic darbelo, first question?
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?
whiteknight +1
allison Tene: aye, I meant that as "this is one lightweight solution that seems to work pretty well, but not necessarily the only one"
Tene nods. 21:01
chromatic How big are these changes, darbelo?
Coke I for one am not using gdbm in core, so I don't mind.
plobsing q2q
darbelo Almost a rewrite. I wanto to extend it to wrap all of the *dbm s. 21:02
And doing *that* in core would bloat the configure stage for little benefit. 21:03
chromatic Fair enough.
Any other comments on this? 21:05
cotto_work +1
NotFound 1
mikehh +1
chromatic Next question, darbelo?
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:06
whiteknight +1 21:07
darbelo I'm thinking for example of the various digest pmcs. Nobody uses or loves them.
I doubt most people even build them...
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
(with a decent Plumage install strategy)
darbelo I can adopt those as well if we kick them out of the core.
mikehh if we can grab them from plumage, fine 21:09
whiteknight dukeleto: PDS is probably not suitable for those types
but new repos are cheap
Util +0.1, if the Plumage versions become immediatly available.
darbelo Util: It should be trivial to acomplish that. 21:10
chromatic We need to check if any languages use those digest PMCs. 21:11
fperrad might know.
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
mikehh +1
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
darbelo Works for me.
But my point was slightly larger than that.
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 :)
darbelo Do we want to move all non-essential modules out of core, like it was done for languages? 21:13
whiteknight +1
plobsing +1
cotto_work +1
allison +1 21:14
mikehh +1
chromatic +1 only if we get them installable and tested regularly.
darbelo A 'delete after adoption' policy would be the best, IMO.
bacek +1 if it's git submodule
Util +0. Why now?
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
NotFound Or even without C parts, fakecutable bulding needs a compiler. 21:16
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 ;)
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)
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.
allison we've already trimmed pretty extensively, but there are a few more that could go
Util +1 21:20
allison Util: I would like to see an extensive test suite for externals too
Util: perhaps we could make it part of Plumage?
darbelo allison: plumage is growing support for that, yes. 21:21
allison excellent, that seems like the right place for it
Util allison: that would be great.
darbelo I think one of japhb's goals was to have 'plumage test all' command.
But we've wandered pretty far from the quistion.
bacek Can we have "make plumage" target in core?
darbelo +Inf 21:22
allison bacek: the intention last I heard was to do Plumage like we're doing nqp-rx
bacek allison, wfm
allison so, it's maintained externally, but a version is shipped in parrot core releases
darbelo has no more questions. 21:23
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
mark *some* PMCs in core as DEPRECATED
Coke wfm.
Tene I dunno, I bet we can get resizablepmcarray.pmc into plumage. 21:25
Coke Tene: *thwap*
chromatic plobsing, please ask one of your questions to end this mess.
allison it'd be nice to get down to one core array-ish type at some point
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
plobsing: +1
NotFound +1
Coke plobsing: just get japh's buyin. everyone else will fall in.
plobsing Coke: haven't seen japhb in a while
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.
plobsing whiteknight: that had crossed my mind
Coke ... or what whiteknight said.
whiteknight (so long as we are exorcising things en masse)
plobsing follow up question: do the signatures in config/gen/call_list/misc.in require a deprecation notice? 21:28
whiteknight i hope not
plobsing they only really worked by registration, so if your project isn't in there, you don't really have support right now
chromatic Are you thinking of removing some?
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
Coke if there's a replacement, sure. in the meantime, yes, I'd call that part of the API.
whiteknight is very agreeable today
NotFound What library builders?
plobsing anyone mentioned in config/gen/call_list/misc.in 21:30
examples: mod_parrot, python, etc
chromatic As long as we can bind to the same shared library APIs, no deprecation necessary.
NotFound If I need a library to use NCI, NCI is not such thing.
chromatic If you remove the ability to bind to a specific function, that's a deprecation.
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
chromatic Long answer: yes, if you remove something that people can do right now. 21:32
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.
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.
darbelo Coke: git-svn users for sure don't.
Coke e.g.: ports/debian/parrot.install.in 21:35
just added :
/branches/op_pmcs/ports/debian/parrot.install.in:43820-44044
... but that branch didn't touch that file, did it?
chromatic This isn't #parrot.
bacek Coke, wrong window?
Coke whoops. yes.
I was going to blame darbelo, but I started it. =-)
chromatic plobsing, we might need more discussion on this. Can you mail the list?
plobsing chromatic: sure 21:36
chromatic Any other questions?
No? Let's call this a week then. Developers wanted on the two focus branches. 21:38
21:38 Coke left 21:39 NotFound left 21:42 bluescreen joined
allison (Looks like chromatic didn't copy in my report when I thought I couldn't make it, so...) 22:01
Last week:
- Worked on Pynie, build cleanups to make sure it works with current parrot.
- Preparing Pynie talk for PyCon.
- Further work on mini-language, talked with Patrick about possible nqp-rx bug.
Next week:
- Speaking at PyCon and participating in VM and Python implementations summits.
- Start on PCC deprecations to reverse order of 'set_returns' and 'get_results' (to the "natural" order.)
EOR
22:16 darbelo left 22:18 chromatic left 22:22 Whiteknight joined 22:35 PacoLinux left 23:48 dukeleto left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!