Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2011-01-29

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

All times shown according to UTC.

Time Nick Message
00:52 whiteknight joined #parrotsketch
02:18 whiteknight left #parrotsketch
03:05 contingencyplan left #parrotsketch
10:17 contingencyplan joined #parrotsketch
12:12 whiteknight joined #parrotsketch
13:19 mikehh joined #parrotsketch
15:12 whiteknight left #parrotsketch
17:06 cotto left #parrotsketch
17:59 mikehh left #parrotsketch
18:10 mikehh joined #parrotsketch
18:41 sorear PDS in 3:19 ?
18:44 mikehh sorear: I think so
19:47 mikehh left #parrotsketch
19:49 lucian joined #parrotsketch
19:52 gerd joined #parrotsketch
20:02 mikehh joined #parrotsketch
20:38 cotto joined #parrotsketch
20:38 gerd left #parrotsketch
20:58 chromatic joined #parrotsketch
21:37 allison joined #parrotsketch
21:51 * Util will be late for the PDS.
21:53 dukeleto joined #parrotsketch
21:55 kid51 joined #parrotsketch
21:59 nwellnhof joined #parrotsketch
22:00 kid51 Welcome to the first Parrot Developers Summit for 2011
22:00 bacek aloha
22:00 mikehh hi there
22:00 chromatic afternoon
22:01 nwellnhof good evening
22:01 cotto hi
22:01 kid51 At our Dec 05 2010 summit meeting, we decided to hold these meetings quarterly, on the second weekend after each supported release
22:01 kid51 Since we had a supported release on Jan 18 2011, this is the weekend, and this is the time
22:02 kid51 Can everyone who is present right now, and who hasn't said hello, sound off now?
22:02 allison hi
22:02 kid51 (don't all shout at once!)
22:03 sorear hi
22:04 lucian hello
22:04 pmichaud_ joined #parrotsketch
22:05 dukeleto hola
22:05 particle hola
22:05 pmichaud_ good 2200utc, whatever that ends up being in your locale
22:05 pmichaud_ is now known as pmichaud
22:06 mikehh methinks we have a quorum
22:07 kid51 cotto has asked me to chair for a while at the start of the meeting
22:07 kid51 We're proposing this structure:
22:07 kid51 1. Follow-up on action items from Dec 05 2010 PDS.
22:07 kid51 2. Roadmap goals
22:07 kid51 3. Other goals and topics.
22:07 kid51 Does that overall structure look satisfactory?
22:08 dukeleto +1
22:08 mikehh +1
22:08 pmichaud I'd like to have a few minutes before 2. Roadmap goals to discuss the changes we're planning for nqp
22:08 pmichaud otherwise it looks fine to me
22:08 kid51 ok
22:08 pmichaud (the nqp changes may impact the roadmap goals)
22:08 pmichaud I apologize in advance that I was not able to write up the nqp description in advance of this meeting
22:09 kid51 So, at the Dec 05 PDS, we ended the meeting with several action items ...
22:09 kid51 ... about which I posted on parrot-dev shortly thereafter
22:09 kid51 ... and did a summary of results a few days ago.
22:09 kid51 Take a minute to look at the summary:  http://tinyurl.com/4cd34gs
22:10 kid51 (subsequent to that post, dukeleto posted about one of the items)
22:11 kid51 So, I suggest we briefly go through each of these 6 items to see (a) is my summary of the status of the action item correct; (b) next step, if any.
22:12 kid51 Does that sound like an acceptable approach?
22:12 bubaflub joined #parrotsketch
22:12 mikehh +1
22:13 dukeleto +1
22:13 kid51 action item #1 concerned 2011 google summer of code;
22:13 kid51 dukeleto Anything to report yet?
22:13 dukeleto i have done nothing in regard to it
22:13 dukeleto EOR
22:13 cotto What's needed and what needs parallelizing?
22:13 cotto (if anything)
22:14 mikehh we need to set up a wiki page for it
22:14 kid51 we could use wiki to discuss topics we'd like to see worked on
22:15 dukeleto i will have very little time to do anything related to GSoC2011 in this quarter. If some people can start a wiki and organize some ideas for projects, that would be awesome
22:15 dukeleto volunteers?
22:15 mikehh I can start something
22:15 cotto dukeleto, ok.  Do you have any preference as to how ideas are organized?
22:15 kid51 okay, then I propose we go on to the next action item and come back to GSOC in the "other goals" part of meeting
22:16 kid51 Let's do the review first
22:16 dukeleto cotto: a single wiki page that lists all GSoC2011 ideas is fine for now
22:16 kid51 action item #2: architecture and design: cotto: status of this item?
22:19 particle mikehh: see http://trac.parrot.org/parrot/wiki/GSOC2010 for a reference point
22:19 cotto got some blog posts on Lorito, will be sending a roadmap goal to parrot-dev in a few minutes
22:19 kid51 k
22:19 kid51 action item #3: embedding API
22:20 kid51 I don't see whiteknight or bluescreen here yet, but whiteknight blogged extensively on this
22:20 nwellnhof i think we made some good progress on the embedding API but there's still work to be done. see tt #1990 for example.
22:21 kid51 nwellnhof: It would be great if someone (you!) could post a brief summary of progress to date on parrot-dev, as that list is a more permanent part of our record
22:21 kid51 2-3 paragraphs would suffice
22:23 nwellnhof i think whiteknight should do that. i've only been watching the progress on his and bluescreen's work.
22:23 kid51 Any other comment right now on item 3?
22:23 kid51 k
22:23 * kid51 will bother whiteknight about that ;-)
22:24 kid51 action item #4:  Parrot on Android:  Lucian has emailed me indicating that time/work pressures prevented him from making progress on this item.
22:24 kid51 dukeleto:  Anything to add about Android?
22:24 dukeleto kid51: no
22:25 lucian kid51: last idea was to add it as an interpreter for SL4A
22:25 dukeleto kid51: i am still interested in it, but have other things with higher precedence, such as Lorito hacking
22:25 dukeleto lucian: do you know any SL4A people that we can recruit?
22:25 lucian dukeleto: just the author, really
22:25 lucian if he's interested
22:26 dukeleto lucian: doesn't hurt to ask
22:26 lucian yep. my opinion is that parrot on android is pointless while it's still so fragile (and without decent implementations)
22:26 kid51 Parrot fragile or Android fragile?
22:27 lucian so yeah, Lorito and language implementations are a priority. I'd rather rewrite pynie
22:27 lucian kid51: parrot
22:27 lucian android's fine
22:27 kid51 lucian: I've been working on one guy in NYC about python on parrot
22:28 lucian otoh, parrot SL4A shouldn't be much effort
22:28 lucian kid51: i'd like to try for GSoC with a pynie rewrite
22:28 kid51 once I make some progress with him, I hope to pull all the python people around parrot into a team
22:28 cotto I love the idea of a Python on Parrot written by Python people.
22:28 kid51 okay, when we come to the Individual Goals section, we can come back to Android
22:29 lucian cotto: and in python :)
22:29 cotto even better
22:29 kid51 action item #5: parrot roadmap
22:29 * kid51 blogged ad nauseum about that
22:29 cotto kid51++ for that
22:30 kid51 ... and since it looks like we are focusing on roadmap goals at this meeting, it looks like this item was Achieved ;-)
22:30 kid51 action item #6:  how to merge a feature branch; chromatic++ got right on this!
22:31 chromatic It's all done.
22:31 kid51 Any other comment on action items coming out of Dec 05 meeting?
22:32 kid51 cotto: Shall we have pmichaud go now?  And then you can take over for Roadmap Items?
22:32 cotto sounds good
22:32 kid51 patrick ... you have the floor
22:33 dukeleto pmichaud: is all you
22:33 pmichaud what I have is a bit long (33 lines) -- I can either paste it into the channel or nopaste it
22:33 dukeleto paste it, because nopastes expire
22:33 kid51 please put it in channel so that it's logged (even though that takes mroe time)
22:33 dukeleto nice to have a log
22:33 pmichaud okay, here it comes
22:34 cotto watch out for throtting
22:34 * dukeleto puts on helmet
22:34 pmichaud irssi usually handles that okay
22:34 pmichaud Over the past few months, jnthn and others have been working on some significant enhancements to nqp-rx.
22:34 pmichaud The new version has enough significant differences from the existing nqp-rx (I'll outline them in a bit)
22:34 pmichaud that it's practically a new implementation of nqp.
22:34 pmichaud As a result, we're planning to fork this new version into its own "nqp" repository (no "-rx").  The
22:34 pmichaud existing implementation will continue to be known as "nqp-rx", to distinguish it in the future.
22:34 pmichaud The main philosophical change in the new nqp implementation is that it now expects to always
22:34 pmichaud have its own minimal "runtime API" available for the programs it compiles.  This is somewhat
22:34 pmichaud different from past versions of nqp that simply provided an interface to whatever Parrot provides.
22:34 pmichaud In particular, the new implementation of nqp no longer makes use of Parrot's builtin Class and Object
22:34 pmichaud PMCs -- nqp provides its own implementation for these (currently known as "6model").  The new
22:34 pmichaud implementation adheres much more closely to Perl 6's design for an object system, and allows
22:34 pmichaud capabilities Parrot's current implementation doesn't provide (such as native int/num/string types
22:34 pmichaud for object attributes, and attribute fetch via integer index instead of hash lookup).
22:35 pmichaud Similarly, nqp will have its own implementations of MultiSub PMCs and multidispatch, and a
22:35 pmichaud custom set of dynops.
22:35 pmichaud Our hope is that someday Parrot/Lorito will be able to adopt the new object and multidispatch
22:35 pmichaud system as core components of Parrot.  Our intent and belief is that the new systems are general
22:35 pmichaud and efficient enough to implementat all dynamic languages, not just Perl 6.
22:35 pmichaud For people that have been using NQP to develop compilers and write programs in NQP, we expect
22:35 pmichaud there to be little overall hassle in migrating to the new system at an NQP "source code" level.
22:35 pmichaud The syntax and semantics are largely unchanged from previous versions.
22:35 pmichaud However, for people that have been using NQP as a way to access Parrot core PMC and class/object PMCs,
22:35 pmichaud this will be a significant change.
22:35 pmichaud (end of paste, discussion can begin here)
22:35 bacek pmichaud, what will happen to nqp-setting?
22:36 pmichaud I'm expecting there may be two "NQP"s for a while -- the existing nqp-rx that gets ported into Parrot, and a standalone nqp
22:36 pmichaud the existing nqp-rx would be able to retain its setting
22:36 pmichaud the new nqp will have a setting built-in
22:36 kid51 what means 'setting'?
22:36 pmichaud (which will likely subsume much  of what is in the existing setting)
22:36 bacek pmichaud, in same way as Rakudo?
22:37 cotto kid51, set of runtime functions
22:37 pmichaud "setting" is the core classes and runtime functions provided by the language itself
22:37 pmichaud bacek: we're still working that out, but yes, likely similar to Rakudo
22:37 dukeleto kid51: basic stuff that nqp-rx needs to bootstrap
22:37 pmichaud dukeleto: that's incorrect, fwiw
22:37 pmichaud the setting isn't part of bootstrap at all
22:38 dukeleto pmichaud: mea culpa, i was using "bootstrap" in a very general sense
22:38 dukeleto pmichaud: as in "stuff needing before other stuff"
22:38 dukeleto needed, even
22:38 pmichaud even in its most general sense.  nqp-rx expects to run without any setting
22:38 pmichaud it's never needed (indeed, none of nqp/rakudo use it)
22:39 bacek opsc and "new PCT" use it :)
22:39 pmichaud well, that's the other thing
22:39 pmichaud we expect to re-implement PCT in NQP, which means that the new PCT will be based on NQP's new object system
22:40 bacek pmichaud, should PCT leave the nest?
22:41 pmichaud essentially NQP is going to provide a re-implementation of PCT, likely.
22:41 pmichaud it needs to do so in order to take advantage of the optimization possibilities available through the new object system
22:41 pmichaud (as well as having a PCT written in NQP should be easier to maintain and port to other backends)
22:42 bacek pmichaud, can we factor out 6model as standalone library? Similar to P6object.
22:42 dukeleto pmichaud: i intend to port 6model stuff to Lorito when enough of Lorito exists. I am sure I will need some help :)
22:42 dukeleto 6model seems more like a spec with multiple implementations
22:43 cotto dukeleto, "April"
22:43 pmichaud I'm sure there will be plenty of support for porting 6model to Lorito
22:43 cotto (or sooner)
22:43 pmichaud from an nqp perspective, we're operationally planning that we have to provide our own 6model for a while
22:43 pmichaud but as soon as it's available in Parrot, we'll gladly switch to what parrot provides
22:43 dukeleto pmichaud: yes, that is correct. But hopefully we can converge soon
22:44 cotto pmichaud, great.
22:44 pmichaud from a rakudo perspective, this also likely means that we will be phasing out "PARROT_REVISION" to instead have "NQP_REVISION"
22:44 dukeleto pmichaud: why not both?
22:44 pmichaud in other words, currently Rakudo depends on a given version of Parrot, which then incorporates some copy of nqp-rx
22:45 pmichaud in the new setup, Rakudo will depend on a given version of nqp, which will then build/require the version of Parrot that it wants
22:45 pmichaud there's still a PARROT_REVISION, but it's only in nqp, not Rakudo
22:45 particle nqp-parrot?
22:45 pmichaud likely.
22:45 particle i wonder how this will work with multiple backends, but that seems outside the scope here
22:45 pmichaud in parallel we expect others may want to work on nqp-jvm and nqp-clr
22:46 dukeleto pmichaud: we could make nqp-rx a git submodule, which means parrot.git can choose a sha1 of nqp-rx to use
22:46 pmichaud dukeleto: nqp-rx always refers to the old one -- is that intentional in your statement?
22:46 dukeleto pmichaud: not sure if that actually solves the problem though
22:46 dukeleto pmichaud: yes
22:46 dukeleto pmichaud: parrot will depend on nqp-rx for a while
22:46 pmichaud however parrot would like to handle nqp-rx is fine with me
22:47 dukeleto pmichaud: at least one more dep cycle, i guess
22:47 particle deprecation and all.
22:47 dukeleto pmichaud: ok, sounds good
22:47 pmichaud I would suggest to continue with the current model, though.
22:47 pmichaud that's partially why we're creating a new repo for nqp, and not just a branch in the existing nqp-rx repo
22:47 dukeleto pmichaud: it works, so yeah, i agree.
22:47 particle i agree, until 6model is baked into parrot
22:47 dukeleto mmmm, baked 6cookies
22:47 kid51 May I make a number of observations?
22:48 cotto please do
22:48 pmichaud certainly
22:48 kid51 From my naive perspective, this sounds like it has profound implications for Parrot
22:48 kid51 So I think we need:
22:48 kid51 (a) pmichaud to do a write-up on parrot dev;
22:49 kid51 (b) it will need to become a roadmap goal at, say, the late April PDS (it's not ready for today)
22:49 kid51 So far so good?
22:49 cotto Lorito has always meant some pretty deep changes from Parrot.  It's just that they're coming closer now.
22:49 pmichaud for (a), I was planning to do a write-up last weekend, but $life intervened.  I again apologize for my not being up-to-speed on this
22:49 kid51 okay, now here's some more subtle points:
22:49 pmichaud but yes, an nqp roadmap is on my tasklist
22:50 kid51 It has been argued that Parrot has spent 10 years rewriting itself and has never become a product.
22:50 kid51 How does this affect our viability in that regard?
22:50 kid51 for example
22:50 kid51 If I'm meeting with a group of people who do Python for a living ...
22:50 kid51 ... and trying to convince them to develop an implementation on parrot vm ...
22:50 kid51 ... where do I tell them to start?
22:51 pmichaud I have two answers
22:51 particle cardinal has stalled due to parrot's incomplete object model. perl6 has worked around it, and parrot plans to adopt it.
22:51 particle that should unblock cardinal and other hll's
22:51 pmichaud first, speaking somewhat selfishly, I'd recommend hll authors to target the new nqp
22:51 particle i believe this rewrite is necessary.
22:51 dukeleto pmichaud: python people don't want to write stuff in NQP
22:52 dukeleto pmichaud: sad but true
22:52 dukeleto kid51: i would recommend telling them to embed PyPy in Parrot, which may excite them a bit more
22:52 pmichaud dukeleto: python programmers, or people writing pythong compilers?
22:52 particle would they prefer a nqpy syntax layer ?
22:52 kid51 dukeleto: Yes, that is the psychological point I was getting at
22:52 pmichaud *python
22:52 dukeleto pmichaud: both
22:52 mikehh my understanding is that P6model is the most comprehensive object model available and the new nqp implements this
22:52 cotto Part of selling Parrot as a universal VM is saying that people can use whatever language they want to target it.
22:52 pmichaud dukeleto: I think it's almost axiomatic that any compiler writer starts out by writing in some other language first
22:53 pmichaud so while it's a fair concept to say "they don't like NQP", they'll still have to fall back to C or PIR or bison or something else like that
22:53 dukeleto pmichaud: of course. I am just remarking about what I hear Python people say. Perhaps I haven't talked to the right Python coders yet
22:53 allison making Parrot one optional back end to PyPy makes sense
22:53 dukeleto pmichaud: there are a lot of options, such as using PyPy to parse Python and not have to re-invent that wheel
22:54 dukeleto allison++
22:54 allison dukeleto: what do you mean by "embed"
22:54 pmichaud dukeleto: I agree, but there there still has to be some non-Python programming involved
22:54 allison basically, PyPy is an alternate to NQP
22:54 Tene Large parts of Rakudo are written in Perl 6.  I rather expect that python on parrot would end up largely written in python, but there's always going to be some bootstrapping stage and some layer that uses native parrot stuff for the backend.
22:54 dukeleto allison: use C and duct tape to make PyPy and Parrot talk to each other
22:54 allison (a much more python-friendly alternate)
22:54 pmichaud I'm saying use NQP for the duct tape
22:54 pmichaud I'm not necessarily saying use NQP for the entire compiler implementation
22:54 allison pmichaud: it's overkill, PyPy already has everything NQP provides
22:54 pmichaud fair enough
22:55 dukeleto pmichaud: i agree with you, and I enjoy NQP. But I think we need a few flavors of duct tape to attract people outside of the Perl-sphere
22:55 pmichaud dukeleto: I was simply providing my answers to kid51's question (more)
22:55 pmichaud I certainly am not trying to claim that NQP is the only answer.  It's just the one I would go with and recommend to others that want to implement $HLL_compiler on Parrot in the next year.
22:56 allison pmichaud: NQP is exactly where your focus should be
22:56 dukeleto pmichaud: i totally agree
22:56 chromatic Instead of bending over backwards to add maximum flexibility for every possible use we can imagine someone somewhere might want to use something different, how about we focus on making one thing that works really well first?  That goes for NQP as well.
22:56 dukeleto pmichaud: the "flavors of duct tape" is a parrot issue, not a nqp/rakudo issue
22:56 chromatic ... given that we seem to be lacking people who say "I'd use it if it had more flexibility in that one spot right there."
22:56 kid51 chromatic:  What would that "one thing" be?
22:57 bacek kid51, "M0"
22:57 pmichaud nqp's focus is on overcoming the speed/impedance issues between Perl 6 and Parrot (and other vm)
22:57 chromatic I don't particularly care what that one thing is, as long as it's not "providign the universal plug and play compiler/vm/toolkit/runtime where you can swap out anything and everything."
22:57 pmichaud nqp-rx served its purpose of getting us to a working Perl 6.  The new nqp is focused on making rakudo more usable.
22:58 pmichaud in the process we believe it can be used for other compiler authors that wish to develop tools for Parrot and other vms
22:58 dukeleto chromatic: i think PL/Perl6 is a project that can deliver a product to many people outside the normal Perl/Parrot sphere
22:58 pmichaud but we're not really pushing that
22:59 allison chromatic: yes, that way lies chaos
22:59 allison chromatic: one of the hardest things about Parrot has been trying to be everything for everybody, so we end up being nothing for nobody
22:59 allison I like the way NQP is heading toward providing its own object model
23:00 allison that makes core parrot much lighter
23:00 chromatic I don't. I think that way lies madness for NQP as well.
23:00 dukeleto chromatic: i think our new embed api is very important, and we should make it very shiny and give it good documentation, and we will see parrot embedding in interesting places
23:00 cotto allison, they'll be converging once it's possible though
23:00 lucian sorry i missed the python discussion :)
23:01 allison cotto: sure, but "converging" doesn't mean all languages will use the full complexity of Perl6's object model
23:01 allison cotto: as far as I can tell, no other language will
23:01 dukeleto chromatic: also, once a few more zits have been popped in parrot internals, making parrot mobile-friendly will open up many possible use-cases
23:01 lucian PyPy isn't really similar to NQP at all
23:01 chromatic Parrot's portability and embedding is only useful if Parrot gets used.
23:01 allison lucian: at an implementation level, they're not similar
23:02 chromatic Portability and embedding are good, but they're ancillary.
23:02 allison lucian: but they both provide a parser and a language runtime, on top of a core VM
23:02 lucian and writing a python compiler targeting parrot in python isn't complicated at all, since we have CPython
23:02 particle i agree with chromatic's suggestion that it's not yet time to take parrot mobile
23:02 lucian allison: to some degree, i guess. more like PyPY is similar to parrot, not nqp
23:02 allison (PyPy's core VM is currently CPython, NQP's core VM is currently Parrot)
23:02 dukeleto particle: yes, which is why i have held off
23:02 lucian no, PyPy's core VM is the PyPy vm
23:03 lucian the PyPy python interpreter can run on either CPython on compiled PyPY
23:03 dukeleto particle: but we are definitely coming close to a critical value in parrot's history
23:03 pmichaud (just a note that I still have a 2nd answer to kid51's question when this thread slows down)
23:03 particle that value is not yet 42 ;)
23:03 dukeleto pmichaud: go for it
23:04 allison lucian: yah, NQP has multiple backends too
23:04 lucian allison: perhaps you're comparing NQP with RPython, but even that isn't very accurate
23:04 pmichaud I just wanted to note that although the new nqp has its own object model, it is still able to communicate with existing Parrot objects.  It just can't create any on its own (except through whatever methods those objects provide).  So HLL interop remains a possibility with languages and systems that don't use 6model objects.
23:04 allison lucian: move to #parrot, to allow pmichaud to continue
23:05 lucian allison: sorry
23:05 bacek pmichaud, what about Q:PIR in new nqp?
23:05 pmichaud but unlike the current nqp-rx that is able to build Parrot classes and objects (through p6object), the new one will not likely have that capability for a while
23:05 pmichaud Q:PIR will continue to exist
23:05 pmichaud in general we prefer pir::   (more)
23:05 * kid51 will convene a separate discussion, like this one, about Python and Parrot in a few weeks when he talks to some python folks more
23:06 sorear bacek: does Q:PIR make any sense with direct-to-pbc-POST?
23:06 bacek sorear, none at all.
23:06 pmichaud most pir:: will be going away in favor of a nqp:: namespace, where nqp itself can map the abstract operation to the underlying vm
23:06 bacek sorear, and POST::Op(:inline(...)) too
23:06 pmichaud Q:PIR and :inline() have always been intended as bailing wire and string, not as permanent answers to the puzzle
23:07 cotto pmichaud, I'll be glad to see them go away as long as we get equivalent functionality.
23:07 pmichaud they're conveniences to "get something working", not "recommended API"
23:08 lucian left #parrotsketch
23:08 pmichaud depends on the level of "equivalent functionality" involved.  A lot of the functionality that Q:PIR and :inline provide really need to go away for Lorito's sake, I think.
23:09 pmichaud as sorear and bacek note, they don't play well with direct-to-pbc
23:09 pmichaud they're really from a time when imcc was the only tool Parrot offered
23:09 dukeleto pmichaud: that time is coming to a close
23:09 cotto and good riddance
23:10 lucian joined #parrotsketch
23:10 kid51 Can I ask that we move this discussion toward a focus on:  What do both Rakudo and Parrot developers need to focus on in next 3 and 6 month periods?
23:10 pmichaud as an aside, based on past experience in both Rakudo and Parrot, I'm hesitant to make any claims about things being "real soon now" (or to accept them at face value)
23:10 dukeleto whiteknight++ is isolating IMCC in preperation for ejection
23:11 pmichaud dukeleto: Yes, I've been reading his blogs closely.
23:11 pmichaud Still, our collective track record is not always that good.
23:11 dukeleto pmichaud: yes, but we code and learn
23:11 pmichaud I can answer for Rakudo when you're ready.
23:11 kid51 pmichaud: proceed
23:12 pmichaud Jonathan wants Rakudo to switch over to the new nqp in the next 3 months.  He feels we can do it in 2 months; I'm less willing to commit to that timeframe.  We expect it to be less overall pain and effort than it was to convert from "Rakudo alpha" to "Rakudo ng" around this time last year.
23:13 kid51 What will Parrot have to do *in preparation* for that?  And what *should* Parrot do *after* that?
23:13 pmichaud so, we expect to have the new nqp running within the next week, and start the Rakudo conversion process in the next two weeks.  We don't know how long it will take, but estimate ~2 - 3 months, such that the April Rakudo release is based on the new nqp.
23:13 pmichaud We don't have any specific needs from Parrot to support that, as far as I know.
23:13 kid51 okay.
23:14 kid51 the "should-after" question is as much for cotto as for pmichaud
23:14 chromatic Also "should Parrot even support this"?
23:14 pmichaud (other than the standard "don't change anything too radically underneath us that hasn't been deprecated" :-)
23:15 sorear Does new-NQP still use IMCC?
23:15 cotto It sounds like "follow our deprecation policy" is all that's needed.
23:15 pmichaud as this is taking place, I hope that parrot core devs will have a chance to look at 6model and see how it plays with planning for lorito
23:15 sorear or I should say, "PIR as an intermediate step"
23:15 pmichaud sorear: yes, if only because it has to at this point.
23:16 cotto pmichaud, I've been doing just that.
23:16 bacek pmichaud, I probably will stop any work on migrating current PCT to NQP. It doesn't make sense at all now. I think it's better to focus on "newPCT" to PBC emitting as soon it will be in reasonably good shape.
23:16 pmichaud cotto: yes, and chromatic++ as well.  I'm just recording it for the log :)
23:16 pmichaud bacek: I plan to steal liberally your pct work.  :)
23:16 bacek pmichaud, it's in kind of "draft mode" :)
23:17 chromatic I've started to question the value of borrowing from 6model in core Parrot.
23:17 pmichaud it's not at all wasted -- I see it as being key to where we're going (and incredibly well-timed)
23:17 bacek pmichaud, ok. I can probably help with newPCT then
23:17 pmichaud bacek: I would like that very much
23:17 bacek pmichaud, deal :)
23:17 cotto chromatic, can you expand on that?
23:18 chromatic If NQP has backend portability as a goal, it needs a compatibility layer.
23:18 chromatic It already has one, in its object model.
23:18 chromatic Why should Parrot do more work for something NQP isn't going to use?
23:18 chromatic (Besides the fact that if NQP has backend portability as a goal, what's the point of Parrot?)
23:19 bacek M0->6model->NQP->Rakudo?
23:19 bacek works for me
23:19 chromatic Why not M0-6model->Rakudo?
23:19 chromatic I mean,
23:19 chromatic M0->NQP->Rakudo?
23:19 bacek chromatic, we need some object model for Parrot runtime.
23:19 bacek It can be "current PMCs"
23:19 bacek Or new 6model
23:20 chromatic To support what?
23:20 bacek PCC? NCI? GC?
23:20 pmichaud I think that nqp considers 6model to largely be its compatibility layer
23:20 mikehh btw, I put up a page on the wiki as a start point -> Ideas for GSoc 2011
23:21 chromatic I have no desire in core Parrot to support NQP's backend portability.
23:21 mikehh which will later become GSoC 2011
23:21 pmichaud I mean the 6model api, then, not the model itself.
23:21 dukeleto mikehh++
23:21 pmichaud I don't think we're asking (or expecting) Parrot to provide backend compatibility
23:21 particle chromatic++
23:22 bacek chromatic, ooookey. How various HLLs can interop than?
23:22 chromatic Ask Rakudo, I guess.
23:23 chromatic Maybe something like "Every HLL should somehow adopt an object model portable across multiple backend VMs."
23:23 pmichaud without completely following the details,  M0->NQP->Rakudo sounds about right to me
23:23 pmichaud but I keep thinking that object handling needs to be more core than Parrot has traditionally thought of it
23:24 pmichaud and I don't think M0 does that (I have trouble keeping it straight)
23:24 * jnthn tries to catch up with what's being discussed
23:25 chromatic If NQP/Rakudo wants a really simple, really dumb VM that provides minimal features in common with other VMs, then Parrot can do a lot less work, if it's even valuable at all for Parrot to try to meet that goal.
23:25 pmichaud chromatic: I don't think that's what we want at all
23:25 pmichaud (more)
23:25 Tene I've always expected parrot to eventually have a sufficiently-flexible MOP such that HLLs can replace behaviour in metaclass subclasses or whatever, such that HLLs don't have to do anything special to use objects from other languages.
23:26 pmichaud Our experience somewhat says that there's always some level of mismatch between the underlying VM and what NQP/Rakudo need
23:26 pmichaud what we'd like to see is a VM that minimizes that mismatch so that we get the biggest speed/performance
23:27 pmichaud not necessarily a lowest-common-denominator
23:27 chromatic I'm not sure adding more compatibility layers meets that goal.
23:27 pmichaud right
23:27 dukeleto Tene: yes, that is my vision as well
23:27 pmichaud if Parrot can become the VM that doesn't require a compatibility layer, then it's ahead of the others.
23:27 particle are we still in the realm of strategic discussion or off in the weeds, and better suited for #parrot?
23:27 dukeleto particle: somewhere in between :)
23:28 pmichaud I doubt that clr or jvm or any other the other vms will ever be able to avoid the compatibility layer
23:28 chromatic But backend portability is still a goal?
23:28 pmichaud it's a goal, yes, but one where (I think) Parrot can have an advantage
23:28 pmichaud perhaps I'm naive
23:29 kid51 particle:  This is more strategic discussion than we've had in > 1 year ;-)
23:29 dukeleto pmichaud: i think having other backends will make Parrot more honest, because we can be compared to them
23:29 chromatic I'm not telling you how to spend your time, but I personally see no value in pursuing hypothetical portability.
23:29 kid51 particle:  And the purpose of PDS is strategic, not tactical.
23:29 jnthn *sigh*
23:29 dukeleto chromatic: that is a choice left to Rakudo developers
23:29 jnthn chromatic: Rakudo/NQP is persuing a multi-backend approach. I've heard your opinions.
23:29 dukeleto chromatic: we need you to worry about Parrot :)
23:30 chromatic I worry that baking these assumptions into Parrot is a mistake.
23:30 jnthn What assumptions?
23:30 mikehh chromatic: in what way?
23:30 pmichaud Yes, I'm not sure what assumptions are being baked in.
23:30 * Util arrives, is reading backlog
23:30 mikehh Util: good luck :-}
23:30 chromatic Supporting NQP, for one.
23:30 dukeleto chromatic: you are concerned that 6model will taint the way Parrot does a meta object protocol (MOP) ?
23:31 Tene Instead of a compatibility layer, I'd like to see a parrot such that you can implement your metaclass behaviour on the same level as whatever is core.  Instead of saying "write a glue layer", say "replace the parts that don't work for you".
23:31 dukeleto chromatic: i think your concern is valid, but i plan on learning from 6model and implementing what parrot needs, not copying it wholesale
23:31 mikehh we need to make NQP pluggable
23:31 dukeleto Tene++
23:32 pmichaud Tene: IIUC, 6model somewhat wants to provide that
23:32 jnthn I dunno where anyone particularly got the idea that 6model is primarily a compatibility layer.
23:32 dukeleto does making NQP pluggable make us go down the road of "pluggable for pluggability's sake" ?
23:32 cotto Tene, that's what I'm planning too.
23:32 dukeleto jnthn: i don't see it as such
23:32 Tene pmichaud: My understanding has been the same.
23:32 chromatic NQP is the compatibility layer.
23:33 * jnthn is very confused.
23:33 dukeleto chromatic: please expand your statement, because as it stands, many of us do not agree.
23:33 pmichaud I agree, NQP is the compatibility layer for making Rakudo portable to various vm backends.
23:33 pmichaud (jnthn, please speak up if you disagree with what I just wrote)
23:33 chromatic Then I see no value in supporting NQP above and beyond we'd support any other project not in Parrot's core.
23:34 pmichaud I see it as "NQP offers a viable alternative underlying object model, when we know that Parrot's current oo implementation has issues."
23:34 pmichaud it's more that 6model may be a reasonable "next oo implementation" for Parrot.
23:35 pmichaud because the current one doesn't work out well, at least not for Rakudo or NQP
23:35 Tene My understanding has always been that 6model was a prototype or experiment in implementing such a pluggable or flexible metamodel, with the goal that the parrot implementation of it would eventually guide a rewrite of parrot's metamodel support.
23:35 pmichaud it's an oo implementation that we think .... does what Tene++ just wrote
23:35 chromatic I have no problem with 6model.
23:35 mikehh I see 6model as the most comprehensive object model at the moment
23:35 pmichaud it's not so much that it supports NQP, as that we think it's a better alternative for Parrot to adopt than what Parrot has now.
23:35 chromatic I have a big problem with focusing Parrot's support on NQP.
23:36 pmichaud I don't think jnthn or I are necessarily asking for that.
23:36 jnthn I'm certainly not asking for that.
23:36 chromatic I want it out of the repo, out of the tarballs, and I want our tools in the core to stop using it.
23:37 pmichaud kid51's question was "What should Parrot do after Rakudo/NQP switch."  My answer was that Parrot should look at NQP's object model and see about adopting it for Lorito.
23:37 mikehh chromatic: what do you see as the alternative
23:37 chromatic I don't have an alternative.
23:37 jnthn chromatic: That's all well and good, but what do you want people developing core Parrot tools to write in?
23:37 chromatic How about a language/toolkit that doesn't suggest they should migrate away from Parrot?
23:37 jnthn WTF?
23:38 dukeleto chromatic: i am not quite understanding that
23:38 pmichaud I think chromatic is looking for a language/toolkit that remains eternally Parrot-focused.
23:38 jnthn chromatic: How is giving people a way to write compilers that target, amongst other VMs, Parrot, suggesting they migrate away from Parrot?
23:38 pmichaud I don't think that's entirely unreasonable, fwiw.
23:38 chromatic I see no reason why Parrot should support VM backend portability.
23:39 jnthn Oh forget it, I'm not wasting my time on this argument.
23:39 jnthn left #parrotsketch
23:39 dukeleto hmmmm
23:39 chromatic If we push all of the smarts of Parrot into a VM compatibility layer, what's the goal of Parrot?
23:39 dukeleto chromatic: i agree with you that we should not, but I don't think we are. The Rakudo devs are doing that.
23:40 chromatic I'm not going to tell Rakudo/NQP developers how to spend their time.
23:40 particle dukeleto: the nqp devs are doing that
23:40 pmichaud chromatic: would it be fair to recast your statement as "I don't think Parrot should support tools that provide VM backend portability"?
23:40 particle can parrot get an nqp that's parrot-only?
23:40 chromatic I don't want to adopt those goals uncritically in Parrot.
23:40 particle does that make anyone happy?
23:40 chromatic If some/all of those goals make sense in Parrot, that's fine.
23:40 pmichaud chromatic: I think I'm entirely in agreement.
23:41 dukeleto chromatic: what is your motivation for excising nqp from parrot core? What does it solve?
23:41 chromatic If NQP isn't a Parrot-focused tool, what value is it to Parrot?
23:41 particle agreed.
23:41 pmichaud it's a tool that lets people write software for Parrot.
23:41 chromatic I'm not suggesting that it has no value, but I think we need to discuss its value to Parrot.
23:41 Coke for one, it's still easier to write code in NQP than in anything else.
23:41 cotto +1
23:41 pmichaud that's always been its claim to fame
23:41 dukeleto i agree with pmichaud. NQP is basically "something that sits on parrot", and end-user of parrot
23:42 bubaflub left #parrotsketch
23:42 particle dukeleto: not when core parrot tools become users of nqp
23:42 dukeleto particle: yes, i agree with that
23:42 pmichaud I should also note in passing that if Parrot decides to completely expunge nqp from its archives and sources, I have no problem with that.
23:43 cotto I like nqp in core because it makes some tests and libraries less painful.  If we switched to winxed or something else and got the same benefit, that'd be fine (module the cost of switching).
23:43 mikehh I don't see a viable alternative at the moment
23:43 chromatic That's not the worst problem though.
23:43 dukeleto there is not viable alternative at the moment
23:44 particle kid51: how long is this meeting scheduled to continue, and what remains to discuss?
23:44 bacek left #parrotsketch
23:44 mikehh roadmap?
23:44 dukeleto chromatic: does this play into the "let's rewrite our internals every few years" rigamarole? Does this help us get a product out the door in the next year?
23:44 chromatic I see it more as a question of "Why are we doing this?"
23:44 dukeleto chromatic: i share your concerns, but i am not sure if they are our biggest problem currently
23:45 dukeleto chromatic: i agree, it needs some analysis and discussion
23:45 kid51 particle: We don't have a fixed meeting length.
23:45 chromatic What is the only real project using Parrot right now?
23:45 kid51 The next item to be discussed is the IMCC roadmap item.
23:45 dukeleto chromatic: define "real project"
23:45 particle nqp.
23:46 Tene and why isn't parrot sufficiently attractive to other projects yet?
23:46 dukeleto chromatic: i submit PL/Parrot as a real project, and I am willing to defend that :)
23:46 Tene And how can we get there?
23:46 chromatic Let's say "Project with more than two developers" or "Project with a roadmap" or "Project that probably would not survive Parrot shutting down right now."
23:46 mikehh winxed is a good example
23:46 chromatic But I'm comfortable saying "Most important" or "Most widely used" project too.
23:46 dukeleto chromatic: what is your answer to that question?
23:46 chromatic NQP/Rakudo
23:47 particle nqp/rakudo is the reason parrot is still around
23:47 dukeleto chromatic: which was really the same project, 11 years ago, if what I read is true
23:48 particle there is no other hll foundation or group supporting parrot materially
23:48 mikehh so your contention is that if NQP can target other VM's parrot will fade away?
23:48 chromatic Is there a good reason to work on Parrot then?
23:48 dukeleto chromatic: Parrot has never had a real external user, i.e. a project by someone that was not a Parrot core dev already
23:49 dukeleto chromatic: i am interested in hacking Javascript on Parrot, and I won't be using anything related to NQP.
23:49 dukeleto chromatic: would you like javascript as the internal parrot language of choice, instead?
23:50 allison chromatic: Shipping a viable Perl 6, running on Parrot, used in production, by real companies, is the single biggest step we can take toward Parrot's "success". A significant portion of the community is and should be focused on that.
23:50 Tene chromatic: My reasons for wanting to work on Parrot remain unchanged.  I believe that a good dynamic VM with good support for language interop would be very valuable.  I'd love to see it.
23:50 allison chromatic: But, that doesn't mean we drop everything and work only on Perl 6.
23:50 dukeleto allison: i totally agree
23:50 mikehh +1
23:51 dukeleto chromatic: can you send an email to parrot-dev with your concerns about NQP?
23:51 chromatic I'm not sure what else to say.
23:51 Tene fwiw, nqp's support of other VMs certainly could go the other way as well.  A project on another VM adopting NQP could make it easier for them to move to Parrot.
23:51 kid51 Can we move toward translating this discussion into action items?
23:51 chromatic NQP's goals aren't necessarily Parrot's goals.
23:51 dukeleto chromatic: well, a summary of what would said for those that are not here would be extremely useful
23:52 chromatic Rakudo's goals aren't necessarily Parrot's goals.
23:52 dukeleto kid51++ # let's bake some action items
23:52 kid51 chromatic: I agree with dukeleto.  I would like to see a post on parrot-dev
23:52 chromatic If Rakudo doesn't really want Parrot anymore, what should Parrot do?
23:52 mikehh yes but Rakudo IS a parrot goal
23:52 pmichaud Let me speak to what Rakudo wants.
23:52 pmichaud Rakudo wants a fast implementation of Perl 6.
23:52 particle we can fork nqp-rx, or take it over as a parrot core tool
23:53 pmichaud That's our current #1 problem at the moment.
23:53 dukeleto pmichaud: yes, i agree
23:53 Tene chromatic: As far as I can tell, Rakudo *does* want parrot, but parrot hasn't been living up to Rakudo's desires yet.  I see that meaning that we should try to meet those goals, not drop rakudo.
23:53 dukeleto pmichaud: i meant to reply to particle, oops
23:53 pmichaud Our ability to improve Rakudo's speed has been limited by our toolset.
23:53 pmichaud Not just Parrot, but PCT and NQP as well.
23:54 pmichaud notably, afaict none of the roadmap items from December addressed Parrot speed
23:54 Tene If rakudo says "Parrot isn't meeting our needs, so we're dating other VMs", we don't take our ball and go home, we try to address the issues instead.
23:54 pmichaud perhaps I'm incorrect about that
23:54 dukeleto Tene: i like that sentiment
23:55 nwellnhof we shouldn't forget that the JVM and CLR are closed source. there will always be people who want to use parrot simply because it's open.
23:55 dukeleto I see many people flocking to Parrot soon, because of worries about corporate overlords of all other popular VMs.
23:55 pmichaud so, we have two choices:  we can either bet the farm on improving parrot's speed, or we can say "well, what options are available for other vms"?
23:55 kid51 pmichaud:  The list of action items was based on those raised by participants in that summit.
23:56 dukeleto pmichaud: i think rakudo is doing it's due diligence, and totally understand
23:56 particle so i should stop thinking about selling parrot to oracle?
23:56 pmichaud kid51: fair enough.  The participants there didn't have speed as a high priority, even though that's been rakudo's #1 request for well over a year.
23:56 sorear nwellnhof: the CLR has several implementations; I use an open-source one daily
23:56 chromatic I haven't seen Rakudo benchmarks in months.
23:57 kid51 pmichaud:  Well, I know I would not have been able to articulate what Rakudo needed from Parrot
23:57 nwellnhof sorear: well, not open enough for some people.
23:57 cotto Let's summarize this and move on.
23:58 dukeleto cotto++
23:58 Tene Summary: Rakudo and Parrot should start going to couples therapy.
23:58 kid51 I think we need posts on parrot-dev that address the following:
23:58 kid51 1. What does Rakudo -- our principal customer -- need from us over the next 3/6/9/12 month periods.
23:58 mikehh I thought that the function of Lorito etc was to simplify AND improve the speed of parrot significanyly
23:58 cotto mikehh, it is.
23:59 Tene mikehh: Yes, but it still hasn't happened yet.
23:59 pmichaud mikehh: I agree... I  haven't seen much progress (as measured in code) on Lorito.  Our NQP effort is very much intended to help jumpstart that process.
23:59 kid51 2. chromatic:  I get the sense that your vision of Parrot is somewhat different from others; I would like you to articulate that, if that is the case.  On parrot-dev that is.
23:59 chromatic I'm not sure we have a vision.
23:59 mikehh that is what I saw it to be as well, especially 6model

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