I'm going to be late for the meeting if I'm able to make it at all, so here's my report: * #40978: [PATCH] Clean up parts of the MMD system - Okay to apply? * Discussed :anon + namespaces on the list * More proposals in the works: - Transparent References - New !:anon !:attach flag I mentioned last week * Beginning [file] command in Tcl, which will lead to work on the OS and File PMCs * Tcl is passing nearly 15% of the official test suite now (Coke++) % chip has left chip!chip@feather.perl6.nl % leo_ has left leo_!lt@feather.perl6.nl % PerlJam has left PerlJam!duff@feather.perl6.nl % chip has joined #parrotsketch % leo_ has joined #parrotsketch % PerlJam has joined #parrotsketch % pmichaud has joined #parrotsketch It looks like a customer call will stop me from being around. particle_ are you here? are we still aiming for 18:30, as last week? yes, see topic i'm here, obra * pmichaud doesn't see the topic in his irc client particle_: can you ringlead for me? sure, the show must go on! thanks! % particle_ is now known as particle % Coke has joined #parrotsketch % mdiep has left mdiep!~matt@bursley-219-72.reshall.umich.edu % mdiep has joined #parrotsketch % particle has left particle!~particle@144.81.84.133 % particle has joined #parrotsketch % smash has left smash!~smash@gil.di.uminho.pt (allison reports taht she'll be late) -> vanish % bernhard has joined #parrotsketch % avar has joined #parrotsketch % chromatic has joined #parrotsketch Allison will be late. I'm okay with waiting for allison <-- unboxing and inventorying gifts thanks, chromatic. i'll be running the show today. any idea how late? No, she didn't say in her message. ok, let's see who else is here, then I'm only partly here (busy-ish) hi all ~~ let's get things moving, allison can catch the log, since tweety's here today chromatic, pmichaud, chip, leo_, coke, then me and mdiep's pasted report Not much here to report. i'm reading the traits and metaclasses paper. There are some great ideas there. I fixed a Parrot::Test bug for the Perl 6 compiler, but I haven't yet discussed it with Andy Lester. It was a Test::Harness change. I've done some work to help Allison analyze HLLCompiler, and it looks good. That's all. % jonathan has joined #parrotsketch having fun? I really wish I had more time. I have two books in process at the moment. December will be hectic too. % allison has joined #parrotsketch . o O ( ENOPARTICLE? ) Coke: what is this channel for? particle lost his irc client, and is having irc problems (he just called voice) so, since I'm next on list, I'll go from here, if that's okay with all (channel for) in #parrot, please. Go ahead, pmichaud. okay avar: this channel is for a moderated parrot status meeting. you're welcome to lurk, but please don't speak unless spoken to, thanks :) * particle is back report coming (long) Miscellaneous: * Helped Coke find a TclFloat bug in tcl. * frequently encountering "roaming segfaults" in Parrot * adding new features to perl6 causes the segfaults to move * running parrot with -G or --gc-debug avoids the segfaults * specific instances are reported in RT PGE: * added more tests from smash++ PAST-pm: * added ability for PAST/POST nodes to contain source in different HLLs (e.g., P6Regex source in Perl6 ASTs) HLLCompiler: * refactored API according to many excellent suggestions from allison++ * updated languages/abc, languages/perl6, past-pm to use new API * some features are now deprecated languages/perl6: * worked with chromatic++ to nail the bizarre Test::Harness bugs * added subroutine calls (both with and without parameters) * regexes and smart matches work again * cleaned up built-in lexicals * chained comparisons work again * I have an implementation for INIT/END closure traits, but it's not very clean so I'm rethinking the overall approach a bit * countdown to pugs test suite: binding, for, range, arity-based multisubs, try, use * I think the compiler infrastructure is in place to quickly implement all of these (except maybe 'try', but that's do-able) * some tests in 01-sanity/ appear to be outside the current p6 spec, so I'm working with pugs folks to resolve those * cleaned up files items in queue: * still need to review pheme for chromatic (pmichaud--) * implement scalar variable type in perl6 * develop a hll type <-> parrot type mapping strategy for perl6, past-pm * more refactors of HLLCompiler --end-- next report was chip, I believe Past/Present: * The perl;Integer problem is fixed; the fix breaks thread cloning, but once I've got that worked out, I'll commit it. Issue for Allison (I'll follow up on p2 with this): * Unresolved design issue: How at PIR/pasm source level to specifically request finding or creating a type in another HLL's class space. Note that this is not a namespace issue, though the problems are analogous in some ways. Future (unchanged): * First-tier projects, modulo who-gets-there-first: * Object model (for Patrick and pretty much everyone else) * Interpreter.open3 (for Jerry and all of us who have to wait for 'make test') /* next report is leo * nothing really reportable, except 2 smaller patches ^D next report is coke * tcl ** Improve handling of tcl's test suite: (14.65%) *** skip more tests to avoid exploding tests *** jiggle test_more.tcl so we can try to run tests that have constraints (think SKIP). While we fail a thousand or so of the new tests, we pass some. ** Report a bug in tclsh8.5a5: already fixed in tcl-cvs. ** Add some misc. functionality *** implement [string wordstart] *** implement [string reverse] ** Minor fixes (arg checking, better stubs, better error messages.) ** Solicit smash++ for [file extension] (woot) [exit] next is particle ok, i've got matt's and mine, then well do jonathan and allison great mdiep: * #40978: [PATCH] Clean up parts of the MMD system mdiep: - Okay to apply? mdiep: * Discussed :anon + namespaces on the list mdiep: * More proposals in the works: mdiep: - Transparent References mdiep: - New !:anon !:attach flag I mentioned last week mdiep: * Beginning [file] command in Tcl, which will lead to work on the OS and File PMCs mdiep: * Tcl is passing nearly 15% of the official test suite now (Coke++) some work with allison on punie this weekend, but haven't had time to commit anything not much else to report, ENOTIME, and that won't change much soon. won't be here next week .end particle: No laptop on the beach? :) jonathan: you're up * Done with travelling around giving talks for now and getting back into Parrot-y things * Sneaked some time at FPW to do a little more on the PDD13 branch * It's hard work and currently in an awkward very-hard-to-parallelize stage * With hindsight I may have gone about this differently, but I'll get there * Trying to catch up with the list * Read the traits paper EOR (getting back into Parrot-y things)++ allison: you're next - It's been an enormously productive week for the compiler tools. Patrick's work on the compiler tool chain is fantastic, and has made it possible for us to spin through the design at a rapid pace. (I suspect that our discussion on the mailing list could be easily condensed into a solid draft compiler tools PDD.) - Thanks to particle for getting me kicked off on the Punie port, made great progress on it this week. - I've also been working on the I/O PDD. I ended up doing more than just adding the two sections, but I'll check it in tomorrow if I don't get lured away by the Punie port. EOR any other reports? lacking any other reports, who has questions? * particle has a questtion particle: go has a time been scheduled for the object discussion? * mdiep arrives, belatedly particle: last I heard was "after today's meeting" Yup, that's as far as I know. I'm available for it. allison: I'm anxious to see the I/O PDD so I hope you do check it in tomorrow that's last I heard also. chromatic? Agreed. fab. okay, so after this meeting. Any other questions? (I have one) Have we finished all reports? i believe so, yes. I think we've finished all reports yes Alright, ignore me then. /ignore chromatic patrick's question next? I find it's never worthwhile to ignore chromatic. my question: how hard would it be to get exceptions implemented? my work this week shows that I'm really going to need exceptions much sooner than I thought I'd even bump it above some of the other requests I've made Implemented to what degree? I don't expect it to be extremely difficult well, I can start building a lot of stuff around the current implementation, but it'd be much nicer if we were closer to what is speced in pdd23 but it probly needs the attention of one of our C programmers unless we decide to prototype it in PIR if there were tickets for the changes that need to be made, I'd take a stab at them (which has a certain degree of appeal) we need an exception hierarchy, and a massive conversion effort i expect in particular, the current implementation seems to be built around trapping things with labels, while pdd23 seems to specify subs as exception handlers (sorting through the PDD takes more effort) well, we can leave the existing code in place, and just get new code on the new system pmichaud: you can always call the sub from the label IMHO that is, the conversion effort can come much later Patrick, are you at the point where you can write test cases for the parts you need? Or at least example code? chromatic: hmm, I suppose I could. * leo_ thinks that the generalization (branch to label) ought to be kept * particle agrees with leo_ not really feasible, except perhaps for the finality probably not even then leo: reasoning? it's the more general concept to the contrary. if the existing code is going to hang around a while, then I have much less concern about it leo: or, more specifically what features of that do you like? if you want a permanent non-local trasnfer you can take a continuation inside the handler sub labels, however, do not allow the "never mind" and "pick up where you left off" I can always call a sub in the handler at the label - the opposite isn't true chip: yup Deprecated.pod has been unchanged for a while. can we actually rip any of that out? (speaking of changing syntax...) Yes please. I think chromatic answered my question best -- I'll work within the existing implementation, and file RT tickets/test cases for any specific features I find I need coke: start a mailing list thread with the features highest on your list to rip out, we'll approve them one-by-one allison: roger. It wouldn't bother me if you used the new features, as long as they don't block you for too long. patrick: okay, that's a good way to move forward well, pdd23 speaks of doing things such as $P0 = new [ 'parrot'; 'exception'], $P1 but I don't know if that works yet Hm, that *could* be PIR for now, as Allison said. I figure the current exceptions implementation ain't unusable, since I implemented much of the .Net exception model on top of it ;-) exactly That might be a quicker way to work. we can implement the entire exceptions object model in PIR I'll investigate it further and report back, then * pmichaud notices that he ends up implementing almost everything he needs in PIR Whatever you think is best, Patrick. As long as you can keep making progress, good stuff. and tcl is using it to handle anything other than normal control flow. (use it for break, return, error, etc.) * allison has also noticed this, and thinks it's good Is there a RT# specifying work needed to be done for Interpreter.open3 (for Jerry and all of us who have to wait for 'make test')" Sound like something I might be able to tackle. * pmichaud searches rt.perl.org tewk: I seem to recall that there is one, but can't locate it at the moment. (ETOOMANYTCLTICKETS :-) particle: I know you're time-starved, but could you locate or create such a ticket for tewk, if that's appropriate? since there seems to be a lull, am I clear to apply my MMD patch? chip? I haven't actually seen it yet what's the quick run down of feature changes? check the ticket description: https://rt.perl.org/rt3/Ticket/Display.html?id=40978 I'm happy with it. It doesn't solve my Pheme problem, but it doesn't make it worse (and might make it easier to trace). chromatic: what is the Pheme problem? you mentioned something last week about your test harness, but I thought you were mentioning a feature and not a bug When you remove the long names for MMD variants, Pheme can't find some of its multimethods. I did some tracing and, while Parrot did identify the right variants, their Manhattan distance values were way too high and it discarded them as options. ah, yes. that's why I added the long names back in. it's on my list of things to tackle Anything that makes that code easier to trace or read is good by me. on a related note, I'd be interested in having a parrot designer weigh in on rt #40968 (underscore as :multi arg) would it be appropriate to just assign such things to allison in RT? (allison? can we use that a way to ping you?) (do chip and allison read the items assigned to them in RT?) the list of things assigned to me is long enough that I don't necessarily see new things assigned mdiep: Parrot_MMD_search_default_func() was needed somehow, but I can't remember the specific issue. Do all/same tests pass after the change? all tests pass, yes there was MultiSub specific code where there didn't need to be allison: k. we may still do it anyway, but ping you out of band. fine to assign them to me, but best to start a mailing list thread at the same time coke: ok okie - that part was very likely used by Python's bound methods, i.e. by currying it's likely that we will need that in future allison: by "mailing list thread" do you simply mean posting another message pointing to the rt ticket, or...? (since rt tickets already start threads) patrick: yeah, but we end up with long design discussions in rt tickets, which makes it difficult to review them later hmmm, I often think of long design discussions in rt tickets as being useful, so that someone working on the ticket can see the state of the current discussion as opposed to having to search in the archives patrick: more useful to have the summary of the discussion in the ticket useful: agreed. (coke: which "useful" are you agreeing with? ;-) both. thread is nice, summary is best. One other question: who else has filled out Jesse's matrix of features? not I not I I have not. adding it back to my todo list. I confess to not knowing exactly what I'm to be looking for with each mdiep: the mmd patch seems like an improvement. At some point in the near future we need to throughly review the design of MMD, but this is at least a step in the right direction. It seems to me mostly to be a list of impressions of our current status. allison: great. I'm going to continue cleaning things up (the namespace pollution in particular) Jesse Matrix latest URL? mdiep: great, many thanks In the repo: docs/dev/status_matrix.txt actually, that one is out-of-date, and the idea of using the .txt was nixed someone please svn del that, then done. Oops. I updated that one. the url I have for the matrix (from halloween) is http://fsck.com/~jesse/parrot.xls patrick: on bug # 40968, it seems there is no design for MMD mmd.pod refers to the calling conventions PDD, which says nothing about MMD :) leo: is there any up-to-date documentation on MMD? allison: that's correct, there's not a design spec (as leo mentions) I modeled MMD it after Perl6 docs _at that time_ (and simplified it) s/it // ok, it's probably going to end up being the same as events, exeptions, and threads, where I poke into the code, see how it works now, and use that as the starting point for the spec (branching out as needed) in that case, would it be too much to ask that '_' mean "any type" (including int/num/str) until there's a spec ? t/pmc/mmd.t is a good resource too ;) it seems like '_' just needs to catch up to autoboxing mdiep: yes okay, let's start there pmichaud: I'll try to take a look at that this week yep - this was also at times, when we didnÄt autobox, so native type was reay different mdiep: I'd really appreciate it. As it is now past-pm is having to box up all arguments to functions because mmd can't handle int/num/str (though cryptic identifiers like '_' are likely to be first against the wall when the refolution comes ;) revolution I'm at least a little familiar with the MMD system now, so it's a good place for me to hack renomination * particle thinks the docs should be changed to reflect the lack of MMD spec * pmichaud votes for perl6's "whatever *" well, as said several times, there isn't even a scalar spec ;) which will influence mmd ... we should really have the basics sorted out first yes, if we had a t/unspecced/ dir, it would be very large well, the basics will be shaped by what we need from more advanced features it's an iterative approach building the house upside down? particle, what's a good place to store todos like this? since there's no mmd pdd, perhaps pdd03? I'm thinking of some form of global list of design requests oh, we used to have ROADMAP for that then we moved to an RT-based system pdd99_unspecced either that or add an "unspecced" section to existing pdds The peanut gallery likes pdd99_unspecced aye, scattered sections across pdds will tend to get lost. I'll do pddXX_unspecced, just in case we end up with 98 other PDDs for some insane reason okay, pddXX_unspecced works for me another possibility would be to put all unspecced requests into their own pddXX_ document well, some of them will be full pdds, but others will only be additions to existing pdds we'll call pddXX_unspecced as the first stage, an independent pddXX second stage, a numbered pdd in clip third stage, etc sure, anything pddXX_* could just be an excerpt that may be merged/refactored into another pdd but I think any of these are good % particle has left particle!~particle@144.81.84.133 we should probably close the meeting soon -- any other items or questions that need addressing? aye, any process will work object discussion should we move to #parrot for that? % particle has joined #parrotsketch No preference here. #parrot is fine. or stay here for logging? * particle comes back to suggest tbd00_requirements.pod ;) I leave that up to others; so, parrotsketch reports end here, object discussion is next OK I think logging would be good for this discussion. Agree (logging++) sounds good am I ringleading this meeting? Alright. What's the main question we have to resolve? * pmichaud will lurk but has to leave soon for errands object creation (new/init) is a never ending story and came up again roles I think initially it may have been "should we make traits (aka roles) our primitive for everything" (object creation: I really like the model of passing a capture object to :vtable('init') ) new is object creation, init is a helper method for new I have collected a short list of thoughts after doing various bits of reading and thinking that I can paste in at some point, maybe to help seed discussion from a Perl6 standpoint, I think roles are implementable in the current system. Roles have implications for MMD, too. mdiep: aye, but we need composition at the parrot level pmichaud: see also my mail n p2p re that chromatic: how so? mdiep, if you treat roles as primitives to identify semantic groups of operations, and then you compose them into a class, all of a sudden Manhattan distance seems less applicable. chromatic: composition eliminates all inheritance distances Precisely. but, you can still have multiple methods within a composed class that have varying levels of appropriateness You just need a different metric for measuring appropriateness of variants. yes It's not really any different than having multiple variants within an ordinary class, though. Okay anyway, that seems like a sidenote. I'm curious to see Jonathan's thoughts. * mdiep has to move meatspace locations. be back in 10m OK, I'm more certain about some of these than others, and likely to be wrong on some stuff, but here goes... What if you want to compose varients from different roles, we might need syntax for that. * Mix-ins can be formulated in terms of inheritance, or vice versa * Single inheritance is just a special case of multiple inheritance * Patterns and subpatterns can be implemented in terms of mix-ins * That means we can have inheritance as a primitive to give us those things tewk: yes * Multiple inheritance is a pain to implement, but we need it... * Interfaces and abstract classes are somewhat similar, we can use the inheritance primitive (but for a fleeting moment I thought of using the composition one...it may make sense but I forget why) and the concept of an "unimplemented method"; there should be a way to block instantiating a class based upon the existence of these for languages that want this (by subclassing ParrotClass, perhaps). * I now understand why trait != mix-in * Traits likely want to be a separate primitive - composition with the flattening property is very different to inheritance * Traits can't have any non-private attributes, as the traits paper suggests (that's fine for Perl 6 roles, since all attributes are private, unless I don't understand something, which is very possible ;-)) * Conclusion: maybe we can just have two entities - classes and traits - and two primitives for relating them - inheritance and flattening compositon. Is that enough? .end jonathan: what did you think of metaclasses composed of traits? allison: I've not made it through that paper yet. :( It seems like the way to go to me. Can someone summarize the main points? I think you can almost do away with metaclasses altogether with that. that's my read, too The salient point was that it's possible. They identified a couple of potential drawbacks with regard to upwards and downwards compatibility based on inheriting from metaclasses. "Numerous approaches have tried to solve metaclass composition problems, but they always resort to an ad-hoc manner of handling conflicting properties, alienating the meta-programmer. We propose a uniform approach that represents class properties as traits, groups of methods that act as a unit of reuse from which classes are composed. Like all the other classes in the system, metaclasses are composed out of traits." Their approach is more formalized to ad-hoc metaclass composition found in Metatalk and CLOS (and Perl 5). a piece of the abstract is the best summary One difficulty they raise is composition collisions at compile time. They also dodge the idea of state, citing potential collisions. OK, interesting. So we keep metaclasses but build them with traits, which stops the class->metaclass cycle Sure, and the only thing that makes it a metaclass is that it implements the necessary metaclass methods somehow. Probably a bit of a rabbit trail for now, but I do want to keep in mind the idea that classes and metaclasses can be composed of traits. That lets us have our two primitives: roles and classes. Okay, let's go through Jonathan's seeds. Yeah composition has to be explicit. So does state handling, but I don't have any bright ideas around those too. mixins as inheritance or inheritance as mixins? I've seen it looked at both ways. Mixins are just inheritance with anonymous parent classes right ie Mixin is/as inheritance. Yes. That's the way of seeing it as just inheritance However, another paper argues that mixins generalize inheritance too That way leads to composition problems and inheritance conflicts in some cases. chromatic: Isn't that a general problem with mix-ins, and what traits were created to solve? I don't know of an imple that isn't inheritance under the covers, doesn't Mixin imply linearization. Traits are the solution YES My understanding was traits avoid the problem by not using the inheritance operator. Right Thus why I suggested inheritance handles mixins for us, and we have something separate for traits. why not have traits handle mixins? Because traits use flattening compositon, not inheritance. % mdiep_ has joined #parrotsketch Do we need mixins too? Mixins using the linearization definition anyway. Not for Perl 6 I guess. * mdiep_ is back But @other languages have mixins. I mean as a Parrot primitive. ok, defining our terms, are we saying that we'll probably need to support two forms of runtime creation of modified classes: one that preserves the inheritance hierarchy and one that composes flatly? It may be that we can not implement mix-ins in the VM itself, but as some sugar for something involving inheritance and anonymous classes. the Parrot roles 'hash' and 'array' both 'can' get_pmc_keyed - what does an OrderedHash PMC need to resolve that conflict? leo_: to implement its own get_pmc_keyed is the simple solution jonathan: but not the best one yep, and delegate according to the key MMD vtables! With traits, OrderedHash would have to explicitly say which one or alias both of them to new names and declare its' own implmentation. the best is to allow explicit selection of one variant at the time of composition but there's no automatic thingy possible for that chromatic: indeed leo: no, it's not possible to select automatically