Camelia, the Perl 6 bug

IRC log for #parrotsketch, 2010-07-13

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

All times shown according to UTC.

Time Nick Message
00:18 dduncan joined #parrotsketch
02:35 eternaleye joined #parrotsketch
05:44 mikehh joined #parrotsketch
07:50 rv2733 joined #parrotsketch
12:56 particle joined #parrotsketch
14:08 whiteknight joined #parrotsketch
14:21 tcurtis joined #parrotsketch
15:30 whiteknight joined #parrotsketch
15:38 NotFound joined #parrotsketch
16:13 eternaleye joined #parrotsketch
16:15 whiteknight joined #parrotsketch
18:39 mikehh joined #parrotsketch
19:06 Coke Did: mostly hacked on partcl-nqp, slowly getting things back to even.
19:07 Coke Did not: send out those emails about the experimental items. Prepare to discuss at #ps today.
19:07 Coke EOR
19:12 mikehh What I did since my last report:
19:12 mikehh * building and testing parrot on amd64/i386, with gcc/g++
19:12 mikehh * various fixes
19:12 mikehh * branch testing and some fixes
19:12 mikehh * testing rakudo, partcl-nqp, partcl, pir/PIRATE, winxed and some plumage
19:12 mikehh What I intend to do in the next week:
19:12 mikehh * testing and fixing
19:12 mikehh * make sure I understand all the requirements for release manager for 2.7.0
19:12 mikehh .eor
19:46 chromatic joined #parrotsketch
19:54 tcurtis Did:
19:54 tcurtis * Implemented traversal of all PAST::Node attributes that I am aware of that can hold another PAST in PAST::Walker.
19:54 tcurtis * Implemented traversal of PAST::Var attributes that can hold another PAST in PAST::Transformer.
19:54 tcurtis * Switched PAST::Pattern to use PAST::Pattern::Transformer instead of Tree::Pattern::Transformer.
19:54 tcurtis * Moved my GSoC project to a github repository
19:54 tcurtis - http://github.com/ekiru/tree-optimization
19:54 tcurtis - It's now available via plumage as "tree-optimization"
19:54 tcurtis * Implemented a working tail-call elimination optimization for NQP-rx
19:54 tcurtis - Caveat: only works for explicit returns.
19:54 tcurtis - http://github.com/ekiru/nqp-rx/blob/o​ptimizations/src/NQP/Optimizer.pm#L23
19:55 tcurtis * Blog post
19:55 tcurtis - http://parrot.org/content/tail-ca​ll-elimination-and-moving-github
19:55 tcurtis * Discovered a segfault that might be GC related. Will create a TT later tonight if I can't find any that seem to be the same thing.
19:55 tcurtis * Submitted a first draft of my GSoC midterm evaluation.
19:55 tcurtis - May revise before Friday.
19:55 tcurtis * Started rewriting the Squaak tutorial for modern NQP-rx.
19:55 tcurtis - partially updated version is currently at http://github.com/ekiru/squaak-tutorial
19:55 tcurtis Will do:
19:55 tcurtis * Research the possibility of converting PAST or POST into some sort of SSA or CPS form to simplify optimization.
19:55 tcurtis * Research LLVM's FunctionPass, LoopPass, and such, to see how best to adapt such things to PAST.
19:55 tcurtis * Work on more optimizations for NQP-rx and PIRATE.
19:55 tcurtis * Add new functionality and improve existing functionality of Tree/PAST/etc.::Walker/Transformer/Pattern
19:55 tcurtis * Finish updating Squaak tutorial
19:55 tcurtis EOR
19:55 tcurtis q1q
19:56 chromatic I moved my office.  I'll have more time in the coming week.
19:59 cotto_work joined #parrotsketch
20:08 Chandon joined #parrotsketch
20:09 khairul joined #parrotsketch
20:11 khairul Did:
20:11 khairul -blog post @ http://parrot.mangkok.com/?p=129
20:11 khairul -mostly refactoring
20:11 khairul Will Do:
20:11 khairul -Complete GSoC midterm evaluation
20:11 khairul -Catch up on last week's goals.
20:11 khairul EOR
20:12 bacek joined #parrotsketch
20:13 Chandon Done:
20:13 Chandon * GSOC Mid-term evaluation
20:13 Chandon * Basic Green Threads functionality
20:13 Chandon Will do:
20:13 Chandon * Blog post
20:14 bacek Little bit of pirate hacking. Nothing particular. Heavily affected by #rl...
20:15 cotto_work #did: met with khairul, reviewed code, finished gsoc midterm eval
20:16 cotto_work #will do: not sure (tuits in short supply this week)
20:16 cotto_work #eor
20:21 NotFound What I did:
20:21 NotFound -parrot
20:21 NotFound * Miscellaneous testing, nothing worth mentioning.
20:21 NotFound -winxed
20:21 NotFound * Several minor fixes and refactors
20:21 NotFound * More predef runtime evaluation
20:21 NotFound * Added a better example of opengl usage
20:21 NotFound * Added a minimal support for float in stage 0, allowing its usage in
20:21 NotFound places of stage 1 compiler where will be conditionally ignored,
20:21 NotFound allowing const float expression optimizations in stage 2
20:21 NotFound * More const expression optimizations in stages 1 and 2
20:21 NotFound What I will do:
20:21 NotFound No plan
20:21 NotFound EOR
20:28 Util # Done:
20:28 Util * Improved Perl6book build
20:28 Util * Worked on Win32 Rakudo coretest problem
20:28 Util # Plan to do:
20:28 Util * Perl6book examples
20:28 Util * Finish Win32 Rakudo coretest problem
20:28 Util # Blockers:
20:28 Util * $WORK
20:28 Util .end
20:30 moritz joined #parrotsketch
20:31 chromatic Hello.
20:31 cotto_work hi
20:31 mikehh hi there
20:31 tcurtis Hello.
20:32 Util Hello
20:32 bacek aloha
20:32 NotFound hola
20:32 chromatic Let's review the past week.  Looked slow to me; what's notable?
20:33 Coke release in one week. Nobody broke anything.
20:34 chromatic Is a code slush keeping people out of corer?
20:34 chromatic *core
20:34 cotto_work either that or a coincidental lack of tuits
20:34 Coke might be. haven't seen any branches other than gsoc.
20:34 eternaleye joined #parrotsketch
20:34 bacek I think both.
20:34 wendar joined #parrotsketch
20:34 Coke 'sfine. haven't heard any complaints from rakudo, either.
20:35 chromatic Any bugs anyone particularly wants fixed for next week?
20:35 Coke I'd like 'make html' to be finished by then. hope to have some tuits this week. (my parrot time this week was spent hacking on partcl-nqp)
20:35 chromatic Are you leading the charge on that?
20:36 Coke Any segfaults that are still open would be nice to have a whack at.
20:36 cotto_work There are a few small things (minor bugfix and some PARROT_EXPORT annotations) from khairul's branch.
20:36 Coke chromatic: yah.
20:36 chromatic Are there bite-sized tasks you can delegate on that one, Coke?
20:36 Coke we need to decide this week if any of the stuff marked experimental is mature enough to get unmarked.
20:37 Coke chromatic: Yes, been doing that with mikehh who spoke up last week when this conversation happened.
20:37 Coke if more people are interested, come see me.
20:37 chromatic Any other volunteers to fix make-html?
20:38 mikehh waiting on Coke, but working on it
20:38 Coke right. if so, ping me on irc or email.
20:38 Coke ah, mikehh, if you want more tasks, I'll break a few off. =-)
20:38 chromatic We also need experimental review.  Is there a canonical list?
20:39 Coke DEPRECATED.pod
20:39 chromatic Any other suggestions for focus?
20:39 Coke improve documentation.
20:39 Coke especially for users.
20:39 chromatic Any particular part?  The book?  Something else?
20:40 Coke tcurtis++ for working on updating the squawk tutorial.
20:40 Coke chromatic: I think the tutorial is the most commonly mentioned bit of broken docs.
20:40 chromatic Squaak?
20:40 Coke likely. =-)
20:41 chromatic That needs NQP knowledge and review.  Is tcurtis in charge there?
20:41 Coke he stepped up, so sure. =-)
20:42 chromatic Okay, same goal then.
20:42 chromatic Anything else we should review for the release?
20:44 Coke platforms, TODO those failures on the smolder server...
20:44 particle make sure any web pages related to downloading parrot and asking for help are up to date
20:44 Coke (since the smoke obscures real failures)
20:44 chromatic Do we have a volunteer to review the download pages?
20:47 chromatic Sounds like a "Not yet"
20:47 Util Will review DL pages
20:48 chromatic Thank you.
20:48 Coke here: http://trac.parrot.org/parro​t/wiki/ResolveExperimentals
20:48 chromatic allison, should we discuss the 2.3 - 2.6 series now or next week?
20:49 Coke I'll send a message out to list, we can use that to track/vote on anything that we think needs to be supported.
20:50 allison chromatic: some discussion is worthwhile in case of deprecations
20:50 chromatic As in "What did we discover we needed to deprecate?"
20:50 allison aye
20:51 allison but we can hold off on the overall planning until next week
20:51 bacek "everything" looks like a good answer :)
20:51 chromatic The big shocker for me was how pervasive TT #389 (don't store methods in namespaces) was.
20:52 moritz that's because we've been building too long on top of the wrong behaviour
20:53 chromatic Yeah, Class and Object and NameSpace are too intertwined.
20:53 Coke chromatic: note that there are still outstanding bugs related to that fix.
20:53 allison bacek: that's for 3.0 :)
20:53 bacek allison, ok :)
20:54 Coke chromatic: did you mean 2.7-3.0 ?
20:54 bacek I want to deprecated current :main sub selection.
20:54 Coke since we're about to release 2.6
20:54 Coke bacek: and replace it with what?
20:54 bacek E.g. have only explicit :main sub.
20:54 chromatic I meant "Should we review how well our process worked for the past three months."
20:54 bacek Not "maybe first sub in PIR file if there is no :main"
20:54 Coke and what do you run if you have no explicit main?
20:55 bacek Coke, exception.
20:55 Coke do you throw an error? do nothign?
20:55 Coke what problem is this solving?
20:56 bacek Coke, https://trac.parrot.org/pa​rrot/ticket/1033#comment:7
20:58 bacek Coke, we can't check 0-args subs. Because it can be :main. And :main has some kind of magical invocation with :slurpy args.
20:58 Coke bacek: EWRONGCOMMENT?
20:58 bacek Instead, I would like to have explicit :main sub with explicit .param pmc slurpy
20:59 allison it seems like fixing it so we check 0-arg subs would be a better solution
20:59 chromatic Removing magic always seems good to me.
20:59 bacek Coke, yeah. Read all of them :)
21:00 bacek allison, it still deprecation.
21:00 particle chromatic: that's why you love C so much.
21:00 cotto_work now's the time to add it
21:00 bacek currently ":main" sub can be declared without params.
21:00 bacek It works because we don't check 0-arity subs.
21:01 bacek So, deprecation should be like ":main Sub must be declared with .param pmc args :slurpy"
21:02 chromatic and no magical "You didn't declare a :main, so we'll pick one"?
21:02 bacek it would be nice too.
21:02 Coke whatever we do, we need to make sure both ways are supported in a single release. (probably with a new :tag)
21:02 cotto_work Should multiple :main subs be explicitly disallowed too?
21:02 allison as long as it's always the first one, there's no real need to require :main
21:02 bacek cotto_work, no.
21:03 allison these are really two separate issues
21:03 bacek allison, yes.
21:03 chromatic Yes, let's keep them as separate issues.
21:03 allison if a sub is being used a the main, it has certain arguements and the sub needs to handle them
21:03 Coke I would not mind a :run that was like main except required a single of .param pmc foo slur:slurpy.
21:04 allison the arguments are orthogonal
21:04 allison (to whether it's being used as :main)
21:05 allison the second problem seems to be that people are getting confused by an implicit :main sub
21:05 chromatic Issue 1: disallow implicit :main
21:05 chromatic Issue 2: enable arity checking on 0-ary subs
21:05 allison thumbs up
21:06 bacek +100500 :)
21:06 chromatic +1 to both for me too
21:06 chromatic any other comments?
21:07 bacek I'll put it into DEPRECATED.pod and on wiki (later today)
21:07 tcurtis On that? Or on deprecations in general?
21:07 Coke I think we can get away with adding a warning in this release regarding the deprecated :main tag. (enabled only with -w), and not it  the pod. then we can remove it post release.
21:07 mikehh how many instances of the inplicit :main / o-ary subs are there?
21:07 Coke chromatic: should 2 be "that aren't :main" ?
21:08 bacek Coke, no-no-no. :mail should have :slurpy args.
21:08 bacek params
21:09 bacek :main
21:09 * bacek need coffee...
21:09 chromatic We don't do arity-checking on 0-ary subs to enable :main's magical behavior, as I understand it.
21:09 allison bacek: it doesn't matter if :main has :slurpy args
21:09 allison bacek: people can choose
21:10 bacek allison, :main _should_ have :slurpy. As chromatic said
21:10 particle chromatic: correct, that's my understanding too
21:10 allison backe: :main should handle some args, but it doesn't have to handle them as slurpy
21:10 chromatic We don't have to enforce :main with :slurpy.
21:10 whiteknight joined #parrotsketch
21:10 bacek allison, ah, yes.
21:11 chromatic If a programmer chooses to handle arguments explicitly, the program can fail with an arity check and that could be intended behavior.
21:11 particle especially with :main :multi
21:11 bacek We just need note in docs.
21:12 chromatic Shall we move on to questions?
21:12 NotFound left #parrotsketch
21:12 tcurtis I think pmichaud and jnthn want a notice that NQP's object model(and possibly P6object?)'s implementation and maybe API might change in as-yet-unknown ways before 2.9 related to the new implementation thereof jnthn's planning. Not absolutely certain it's a deprecation notice in Parrot or what that they want, though.
21:12 NotFound joined #parrotsketch
21:13 chromatic Good point. Can you or someone check on any deprecations there?
21:14 allison P6Object should probably move out of Parrot and into NQP
21:14 chromatic That's probably a deprecation too.
21:14 tcurtis I don't think they wanted to deprecate anything specific, iiuc; just a warning that there might be some changes, so that if any changes need to be made to the API, they can still switch NQP over to jnthn's new implementation.
21:14 particle then only nqp-based languages can use it
21:15 allison it's pretty much only useful to nqp-based languages anyway
21:16 tcurtis allison: PCT uses it.
21:16 particle as do some non-nqp languages iirc
21:17 allison then make it part of PCT (and change the name)
21:18 allison not urgent or anything, just sensible cleanup
21:18 Coke the right way to say "something is going to change and we don't know what" is to make it experimental.
21:18 bacek We still need some foundation of objects system in parrot. Otherwise HLL interoperability will be much more painful.
21:18 chromatic +1 for experimental
21:18 allison it sounds like these are additions, rather than removals
21:18 allison so, the additions can be experimental
21:19 allison and we won't remove the existing features until after 2.9
21:19 allison bacek: uh, there is an object system
21:19 chromatic Do we have good documentation of what "experimental" means?
21:20 allison bacek: P6object certainly isn't it
21:21 bacek ok.
21:21 whiteknight chromatic: if we do, it's in the support policy
21:22 Coke or in Deprecated.pod
21:22 chromatic I'll check.
21:22 Coke but basically, it means "deprecation doesn't apply, sorry, not baked yet.
21:22 chromatic Any other questions?  tcurtis had one.
21:22 tcurtis allison: jnthn is going to be re-implementing P6object with new features(e.g., index attribute lookup, custom dispatchers, faster type-checking, natively typed attributes(though I'm not certain what this means))They don't yet know what changes to the API might be necessary. None might; or some might.
21:23 tcurtis chromatic: mine was about the Squaak tutorial. No need to ask it anymore since Coke brought it up.
21:23 chromatic Other questions?
21:24 cotto_work one
21:24 particle chromatic: docs/project/stability.pod iirc
21:24 allison tcurtis: right, but if they miss the deprecation notice in 2.6, that just means we leave the existing P6object in place, and they develop the new one with a different name
21:25 allison tcurtis: (which is a good idea anyway, since the old name is confusing)
21:25 tcurtis allison: but would they be able to swap it out in NQP-rx before 2.9?
21:25 Coke NQP-rx is an external app.
21:26 Coke we bundle it, but I'm not sure it's covered under our policy.
21:26 Coke (we should probably be explicit about stuff in ext/ in that regard.)
21:26 allison tcurtis: they can certainly change it in NQP-rx externally, and then we'll have to make the call on whether to update the Parrot bundled copy
21:27 allison tcurtis: but, again, if they change the name of the module, there's no problem
21:27 allison tcurtis: NQP-rx can use the new PCT::Object (or whatever), and leave the old P6object in Parrot unchanged
21:28 Coke gotta run. #offline
21:28 chromatic cotto_work, question?
21:29 cotto_work wrt Lorito design, it seems like the discussion would be better-formed if we made an attempt to nail down the design aspects in the approximate order they're listed on LoritoRoadmap.
21:29 cotto_work Deciding on a set of ops is important, but other issues like register size, types and ffi are already being raised.  I'd like to see us address those issues in turn (as much as possible) and deliberately rather than discussing them ad hoc.
21:29 cotto_work Hmm.  I guess that wasn't really a question.
21:30 cotto_work call it a suggestion, then
21:30 chromatic In my discussion with allison, she suggested that some sort of spike solution on which we could iterate would help answer these questions.
21:30 allison +1
21:32 allison yes, there's a risk on both sides of spending too much time designing in a theoretical context, and of "just throwing something in to work now" and not thinking the issues through
21:32 allison I would like to see a working minimal set of opcodes quickly
21:33 tcurtis atrodo++ seems to have been working on some sort of prototype vm for the opcode set you mentioned in your mail to parrot-dev, allison
21:33 tcurtis http://github.com/atrodo/lorito
21:33 allison and if we can pair it so we have the advanced discussion on each subsystem as we write them, we'll be doing well
21:33 allison tcurtis: I saw that, looked like a good start
21:34 cotto_work I see the value in that
21:34 chromatic Any other questions?
21:35 mikehh I also thought the whiteknight++ blog post important
21:36 cotto_work allison, would you say that the next step would be to get something that can run the P&W object model and see which design issues need to be solved to get that code usable?
21:36 cotto_work s/run/implement/
21:37 allison I'm not sure I'm entirely sold on the P&W object model, but is has some good features
21:37 cotto_work Call it a first approximation.  If we can implement that, we'll be closer to implementing whatever we end up wanting to use.
21:38 allison how about "we'll talk through the object model when we get to that part of the interpreter"?
21:38 allison we have a whole pile of problems in the existing implementation that we want to solve
21:39 allison the current object model is definitely one of them
21:39 cotto_work I'm thinking "What's the first thing we want our spike solution to be able to do?".
21:39 allison and its interaction with namespaces, etc
21:39 chromatic I have some thoughts on that.
21:39 allison we want a tiny interpreter capable of hosting a full parrot solution
21:40 allison i.e. our first set of opcodes needs to be enough to a) define the other opcodes we want and b) define our PMCs
21:40 bacek cotto_work, "20 dynops + implementation of RPA in it" as prototype
21:40 allison bacek: basically, yeah
21:41 cotto_work wfm.  Hash might be more interesting, but anything like that would be fine.
21:41 allison say, Integer, Number, String, and Array
21:41 allison Hash next
21:41 allison (Hash is a good stress test)
21:42 cotto_work ok.  So our current goal is a Lorito that can implement something like our current RPA.
21:42 cotto_work +1
21:44 chromatic Anything else?
21:44 bacek nope
21:44 chromatic Let's wrap it up.
21:44 tcurtis One thing?
21:45 tcurtis I asked jnthn what he thought about the suggestion to rename his new P6object re-implementation and do it separately. Here's his response:
21:45 tcurtis "The issue would more be that PCT currently uses P6object to provide its underlying object model, and would switch to using The New Thing."
21:45 tcurtis "I will do what is reasonable to make that painless. At present, I expect the impact to be relatively low to most users, especially since most people write stuff in nqp-rx."
21:45 tcurtis "It'll mostly hit people who use p6object explicitly in conjunction with their use of PCT."
21:45 tcurtis "So the deprecatin notice I was thinking of was more along those lines - that PCT could be sat atop a new meta-model implementation with a slightly different API (but not entirely different)."
21:45 tcurtis "I'll do my best to judge the balance between progress and not causing pain, anyways. :-)"
21:47 allison so, it's a deprecation cycle on the interface of PCT, that's important here
21:47 allison it needs a deprecation notice
21:47 allison or, we may not be able to launch some change until after 2.9
21:48 jnthn joined #parrotsketch
21:48 allison (which is only 3 months away, after all)
21:48 allison hi jnthn
21:49 jnthn hi!
21:49 jnthn I hope not to actually affect the interface of PCT
21:49 cotto_work quick question: Is it certain that we'll fold strings and PMCs into the same type in Lorito?
21:49 chromatic No.
21:49 cotto_work ok
21:49 jnthn There shouldn't be a need to.
21:49 allison cotto: no, just an idea
21:49 cotto_work eoq
21:49 sorear Is it certain that we'll fold PMCs and Objects into the same type?
21:50 allison sorear: yes
21:50 jnthn It's more that it'd have something other than p6object as its underlying meta-model implementation.
21:50 allison jnthn: it's perfectly possible to write a deprecation notice around that
21:50 jnthn So anyone who relies on peculiarities of P6object WRT to PCT objects would probably get hit.
21:50 jnthn allison: Yes, I think so.
21:51 allison can you describe the parts of PCT where the old interface peeked through?
21:51 allison e.g. "If you were calling this set of methods on X object..."
21:51 chromatic That might be better back in #parrot
21:52 jnthn allison: Generally, "if I do .HOW on an object that's part of the PCT eco-system, the object I get back from that might have a different interface"
21:52 jnthn allison: That is, it's only if going digging into the meta level.
21:52 jnthn allison: For the typical person writing grammars and actions in NQP and building PAST nodes, I'd expect close to zero impact.
21:52 allison jnthn: yeah, that's not a big deal, and easy to define in a deprecation notice
21:53 whiteknight if we fold PMCs and Objects together, will we still have a pluggable object model?
21:53 jnthn allison: I'll try and write on that gives specifics, but also gives enough wiggle room.
21:53 jnthn *one
21:53 chromatic whiteknight, with a good metaobject protocol we can.
21:53 allison whiteknight: yes, it means PMC get promoted to pluggable, rather than Objects being demoted to cement
21:53 cotto_work whiteknight, that's part of what p&w allows
21:53 whiteknight okay, just making sure we don't burn any bridges
21:54 allison the "PMC" is just one very primitive object model
21:54 jnthn General notice: while what I'm going to design wil obviously have various p6-isms, in a sense if I don't churn out a meta-model design that's pluggable enough for other languages to do their stuff, I'll probably have failed.
21:55 allison jnthn: sure, but not all languages will use it. Python won't, for example
21:55 jnthn allison: :-)
21:56 jnthn allison: The thing is, at some level we'll need some fundemtnals.
21:57 jnthn allison: That is, some small amount of protocol between which all of these different language implementations can talk.
21:58 jnthn Just something to keep in mind.
21:58 jnthn (And something I'll have in mind as I work on this.)
21:59 allison jnthn: agreed
21:59 allison jnthn: it should be a pretty simple level though
21:59 chromatic Can I help somehow?
22:00 allison jnthn: as in, we shouldn't require every language to implement the complexity of P6 objects, but p6 objects should be able to talk to the simpler object models
22:00 jnthn allison: Oh, completely.
22:01 jnthn allison: That kind of thing immediately faces me - for example, the meta-class NQP classes use doesn't want to have all the stuff in it to support full blown Perl 6 either.
22:01 jnthn allison: But I suspect there may be an even simpler pre-NQP layer too.
22:02 allison jnthn: makes sense
22:04 jnthn I'd like to try and not to go off and design something in complete isolation from what Parrot is doing though. I know there's interest in similar things on the Parrot side.
22:04 jnthn (e.g. meta-model improvements)
22:05 chromatic That's why I ask.
22:05 allison jnthn: the basic interface is likely to stay the same (i.e. you can call 'add_method' to add a method), though the internals are likely to change substantially in the near future
22:07 jnthn chromatic: I'm sure you can help. :-) The point I'm at now is more looking at what I need for Perl 6 and NQP, and what the smallest sane protocol I can build that on is.
22:07 jnthn chromatic: I kinda need a bit more time/space on that side of things at the moment, tbh.
22:07 chromatic I have a sketch that defines role, class, and object and models behavior based on that.
22:08 chromatic It doesn't bootstrap though.
22:08 jnthn chromatic: I plan to write up quite a lot of stuff that I'm thinking about.
22:08 jnthn chromatic: Maybe at that point we (and others who are interested) can compare notes.
22:08 jnthn (e.g. when I've got something more concrete to offer than "I'd like to do this awesome stuff")
22:08 chromatic I'll write some notes too.
22:08 jnthn chromatic: I'd be interested to see your sketches too.
22:08 jnthn OK, great.
22:10 jnthn There's a lot of things to weigh up on the Perl 6 side. One of my biggest realisations so far has been that Perl 6 really needs a meta-model designed for a gradually typed language, not a dynamically typed one.
22:11 jnthn We'd need to work out if, for example, Parrot would also want its its protocol to handle that or just stick with the dynamic parts.
22:12 chromatic Or at least how Parrot can make that possible.
22:12 jnthn (Other fun includes dealing with representations and natively typed attributes into the design...)
22:12 jnthn chromatic: *nod*
22:13 jnthn Anyway, I'll get some deprecation note - hopefully a sane one - in.
22:13 jnthn Squawk if it's not sane enough. :-)
22:14 jnthn And I'll blog some meta-model-y bits as I get things together.
23:07 Chandon left #parrotsketch
23:24 cotto_work joined #parrotsketch
23:26 jnthn left #parrotsketch

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