Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3126985 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/parrotsketch/today
Set by moderator on 16 January 2011.
00:52 whiteknight joined 02:18 whiteknight left 03:05 contingencyplan left 10:17 contingencyplan joined 12:12 whiteknight joined 13:19 mikehh joined 15:12 whiteknight left 17:06 cotto left 17:59 mikehh left 18:10 mikehh joined
sorear PDS in 3:19 ? 18:41
mikehh sorear: I think so 18:44
19:47 mikehh left 19:49 lucian joined 19:52 gerd joined 20:02 mikehh joined 20:38 cotto joined, gerd left 20:58 chromatic joined 21:37 allison joined
Util will be late for the PDS. 21:51
21:53 dukeleto joined 21:55 kid51 joined 21:59 nwellnhof joined
kid51 Welcome to the first Parrot Developers Summit for 2011 22:00
bacek aloha
mikehh hi there
chromatic afternoon
nwellnhof good evening 22:01
cotto hi
kid51 At our Dec 05 2010 summit meeting, we decided to hold these meetings quarterly, on the second weekend after each supported release
Since we had a supported release on Jan 18 2011, this is the weekend, and this is the time
Can everyone who is present right now, and who hasn't said hello, sound off now? 22:02
allison hi
kid51 (don't all shout at once!)
sorear hi 22:03
lucian hello 22:04
22:04 pmichaud_ joined
dukeleto hola 22:05
particle hola
pmichaud_ good 2200utc, whatever that ends up being in your locale
22:05 pmichaud_ is now known as pmichaud
mikehh methinks we have a quorum 22:06
kid51 cotto has asked me to chair for a while at the start of the meeting 22:07
We're proposing this structure:
1. Follow-up on action items from Dec 05 2010 PDS.
2. Roadmap goals
3. Other goals and topics.
Does that overall structure look satisfactory?
dukeleto +1 22:08
mikehh +1
pmichaud I'd like to have a few minutes before 2. Roadmap goals to discuss the changes we're planning for nqp
otherwise it looks fine to me
kid51 ok
pmichaud (the nqp changes may impact the roadmap goals)
I apologize in advance that I was not able to write up the nqp description in advance of this meeting
kid51 So, at the Dec 05 PDS, we ended the meeting with several action items ... 22:09
... about which I posted on parrot-dev shortly thereafter
... and did a summary of results a few days ago.
Take a minute to look at the summary: tinyurl.com/4cd34gs
(subsequent to that post, dukeleto posted about one of the items) 22:10
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:11
Does that sound like an acceptable approach? 22:12
22:12 bubaflub joined
mikehh +1 22:12
dukeleto +1 22:13
kid51 action item #1 concerned 2011 google summer of code;
dukeleto Anything to report yet?
dukeleto i have done nothing in regard to it
EOR
cotto What's needed and what needs parallelizing?
(if anything)
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
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
volunteers?
mikehh I can start something
cotto dukeleto, ok. Do you have any preference as to how ideas are organized?
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
Let's do the review first 22:16
dukeleto cotto: a single wiki page that lists all GSoC2011 ideas is fine for now
kid51 action item #2: architecture and design: cotto: status of this item?
particle mikehh: see 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
kid51 k
action item #3: embedding API
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.
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
2-3 paragraphs would suffice
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?
k
kid51 will bother whiteknight about that ;-)
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
dukeleto: Anything to add about Android?
dukeleto kid51: no
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
lucian: do you know any SL4A people that we can recruit?
lucian dukeleto: just the author, really
if he's interested
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)
kid51 Parrot fragile or Android fragile?
lucian so yeah, Lorito and language implementations are a priority. I'd rather rewrite pynie 22:27
kid51: parrot
android's fine
kid51 lucian: I've been working on one guy in NYC about python on parrot
lucian otoh, parrot SL4A shouldn't be much effort 22:28
kid51: i'd like to try for GSoC with a pynie rewrite
kid51 once I make some progress with him, I hope to pull all the python people around parrot into a team
cotto I love the idea of a Python on Parrot written by Python people.
kid51 okay, when we come to the Individual Goals section, we can come back to Android
lucian cotto: and in python :) 22:29
cotto even better
kid51 action item #5: parrot roadmap
kid51 blogged ad nauseum about that
cotto kid51++ for that
kid51 ... and since it looks like we are focusing on roadmap goals at this meeting, it looks like this item was Achieved ;-) 22:30
action item #6: how to merge a feature branch; chromatic++ got right on this!
chromatic It's all done. 22:31
kid51 Any other comment on action items coming out of Dec 05 meeting?
cotto: Shall we have pmichaud go now? And then you can take over for Roadmap Items? 22:32
cotto sounds good
kid51 patrick ... you have the floor
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
dukeleto paste it, because nopastes expire
kid51 please put it in channel so that it's logged (even though that takes mroe time)
dukeleto nice to have a log
pmichaud okay, here it comes
cotto watch out for throtting 22:34
dukeleto puts on helmet
pmichaud irssi usually handles that okay
Over the past few months, jnthn and others have been working on some significant enhancements to nqp-rx.
The new version has enough significant differences from the existing nqp-rx (I'll outline them in a bit)
that it's practically a new implementation of nqp.
As a result, we're planning to fork this new version into its own "nqp" repository (no "-rx"). The
existing implementation will continue to be known as "nqp-rx", to distinguish it in the future.
The main philosophical change in the new nqp implementation is that it now expects to always
have its own minimal "runtime API" available for the programs it compiles. This is somewhat
different from past versions of nqp that simply provided an interface to whatever Parrot provides.
In particular, the new implementation of nqp no longer makes use of Parrot's builtin Class and Object
PMCs -- nqp provides its own implementation for these (currently known as "6model"). The new
implementation adheres much more closely to Perl 6's design for an object system, and allows
capabilities Parrot's current implementation doesn't provide (such as native int/num/string types
for object attributes, and attribute fetch via integer index instead of hash lookup).
Similarly, nqp will have its own implementations of MultiSub PMCs and multidispatch, and a 22:35
custom set of dynops.
Our hope is that someday Parrot/Lorito will be able to adopt the new object and multidispatch
system as core components of Parrot. Our intent and belief is that the new systems are general
and efficient enough to implementat all dynamic languages, not just Perl 6.
For people that have been using NQP to develop compilers and write programs in NQP, we expect
there to be little overall hassle in migrating to the new system at an NQP "source code" level.
The syntax and semantics are largely unchanged from previous versions.
However, for people that have been using NQP as a way to access Parrot core PMC and class/object PMCs,
this will be a significant change.
(end of paste, discussion can begin here)
bacek pmichaud, what will happen to nqp-setting?
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
the existing nqp-rx would be able to retain its setting
the new nqp will have a setting built-in
kid51 what means 'setting'?
pmichaud (which will likely subsume much of what is in the existing setting)
bacek pmichaud, in same way as Rakudo?
cotto kid51, set of runtime functions 22:37
pmichaud "setting" is the core classes and runtime functions provided by the language itself
bacek: we're still working that out, but yes, likely similar to Rakudo
dukeleto kid51: basic stuff that nqp-rx needs to bootstrap
pmichaud dukeleto: that's incorrect, fwiw
the setting isn't part of bootstrap at all
dukeleto pmichaud: mea culpa, i was using "bootstrap" in a very general sense 22:38
pmichaud: as in "stuff needing before other stuff"
needed, even
pmichaud even in its most general sense. nqp-rx expects to run without any setting
it's never needed (indeed, none of nqp/rakudo use it)
bacek opsc and "new PCT" use it :) 22:39
pmichaud well, that's the other thing
we expect to re-implement PCT in NQP, which means that the new PCT will be based on NQP's new object system
bacek pmichaud, should PCT leave the nest? 22:40
pmichaud essentially NQP is going to provide a re-implementation of PCT, likely. 22:41
it needs to do so in order to take advantage of the optimization possibilities available through the new object system
(as well as having a PCT written in NQP should be easier to maintain and port to other backends)
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 :)
6model seems more like a spec with multiple implementations
cotto dukeleto, "April" 22:43
pmichaud I'm sure there will be plenty of support for porting 6model to Lorito
cotto (or sooner)
pmichaud from an nqp perspective, we're operationally planning that we have to provide our own 6model for a while
but as soon as it's available in Parrot, we'll gladly switch to what parrot provides
dukeleto pmichaud: yes, that is correct. But hopefully we can converge soon
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"
dukeleto pmichaud: why not both?
pmichaud in other words, currently Rakudo depends on a given version of Parrot, which then incorporates some copy of nqp-rx
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
there's still a PARROT_REVISION, but it's only in nqp, not Rakudo
particle nqp-parrot?
pmichaud likely.
particle i wonder how this will work with multiple backends, but that seems outside the scope here
pmichaud in parallel we expect others may want to work on nqp-jvm and nqp-clr
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?
dukeleto pmichaud: not sure if that actually solves the problem though
pmichaud: yes
pmichaud: parrot will depend on nqp-rx for a while
pmichaud however parrot would like to handle nqp-rx is fine with me
dukeleto pmichaud: at least one more dep cycle, i guess 22:47
particle deprecation and all.
dukeleto pmichaud: ok, sounds good
pmichaud I would suggest to continue with the current model, though.
that's partially why we're creating a new repo for nqp, and not just a branch in the existing nqp-rx repo
dukeleto pmichaud: it works, so yeah, i agree.
particle i agree, until 6model is baked into parrot
dukeleto mmmm, baked 6cookies
kid51 May I make a number of observations?
cotto please do 22:48
pmichaud certainly
kid51 From my naive perspective, this sounds like it has profound implications for Parrot
So I think we need:
(a) pmichaud to do a write-up on parrot dev;
(b) it will need to become a roadmap goal at, say, the late April PDS (it's not ready for today) 22:49
So far so good?
cotto Lorito has always meant some pretty deep changes from Parrot. It's just that they're coming closer now.
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
kid51 okay, now here's some more subtle points:
pmichaud but yes, an nqp roadmap is on my tasklist
kid51 It has been argued that Parrot has spent 10 years rewriting itself and has never become a product. 22:50
How does this affect our viability in that regard?
for example
If I'm meeting with a group of people who do Python for a living ...
... and trying to convince them to develop an implementation on parrot vm ...
... where do I tell them to start?
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.
that should unblock cardinal and other hll's
pmichaud first, speaking somewhat selfishly, I'd recommend hll authors to target the new nqp
particle i believe this rewrite is necessary.
dukeleto pmichaud: python people don't want to write stuff in NQP
pmichaud: sad but true 22:52
kid51: i would recommend telling them to embed PyPy in Parrot, which may excite them a bit more
pmichaud dukeleto: python programmers, or people writing pythong compilers?
particle would they prefer a nqpy syntax layer ?
kid51 dukeleto: Yes, that is the psychological point I was getting at
pmichaud *python
dukeleto pmichaud: both
mikehh my understanding is that P6model is the most comprehensive object model available and the new nqp implements this
cotto Part of selling Parrot as a universal VM is saying that people can use whatever language they want to target it.
pmichaud dukeleto: I think it's almost axiomatic that any compiler writer starts out by writing in some other language first
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
allison making Parrot one optional back end to PyPy makes sense
dukeleto pmichaud: there are a lot of options, such as using PyPy to parse Python and not have to re-invent that wheel
allison++ 22:54
allison dukeleto: what do you mean by "embed"
pmichaud dukeleto: I agree, but there there still has to be some non-Python programming involved
allison basically, PyPy is an alternate to NQP
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.
dukeleto allison: use C and duct tape to make PyPy and Parrot talk to each other
allison (a much more python-friendly alternate)
pmichaud I'm saying use NQP for the duct tape
I'm not necessarily saying use NQP for the entire compiler implementation
allison pmichaud: it's overkill, PyPy already has everything NQP provides
pmichaud fair enough
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)
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.
allison pmichaud: NQP is exactly where your focus should be 22:56
dukeleto pmichaud: i totally agree
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.
dukeleto pmichaud: the "flavors of duct tape" is a parrot issue, not a nqp/rakudo issue
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."
kid51 chromatic: What would that "one thing" be?
bacek kid51, "M0" 22:57
pmichaud nqp's focus is on overcoming the speed/impedance issues between Perl 6 and Parrot (and other vm)
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."
pmichaud nqp-rx served its purpose of getting us to a working Perl 6. The new nqp is focused on making rakudo more usable.
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
pmichaud but we're not really pushing that
allison chromatic: yes, that way lies chaos 22:59
chromatic: one of the hardest things about Parrot has been trying to be everything for everybody, so we end up being nothing for nobody
I like the way NQP is heading toward providing its own object model
that makes core parrot much lighter 23:00
chromatic I don't. I think that way lies madness for NQP as well.
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
cotto allison, they'll be converging once it's possible though
lucian sorry i missed the python discussion :)
allison cotto: sure, but "converging" doesn't mean all languages will use the full complexity of Perl6's object model 23:01
cotto: as far as I can tell, no other language will
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
lucian PyPy isn't really similar to NQP at all
chromatic Parrot's portability and embedding is only useful if Parrot gets used.
allison lucian: at an implementation level, they're not similar
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
lucian and writing a python compiler targeting parrot in python isn't complicated at all, since we have CPython
particle i agree with chromatic's suggestion that it's not yet time to take parrot mobile
lucian allison: to some degree, i guess. more like PyPY is similar to parrot, not nqp
allison (PyPy's core VM is currently CPython, NQP's core VM is currently Parrot)
dukeleto particle: yes, which is why i have held off
lucian no, PyPy's core VM is the PyPy vm
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
pmichaud (just a note that I still have a 2nd answer to kid51's question when this thread slows down)
particle that value is not yet 42 ;)
dukeleto pmichaud: go for it
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
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.
allison lucian: move to #parrot, to allow pmichaud to continue
lucian allison: sorry 23:05
bacek pmichaud, what about Q:PIR in new nqp?
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
Q:PIR will continue to exist
in general we prefer pir:: (more)
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
sorear bacek: does Q:PIR make any sense with direct-to-pbc-POST? 23:06
bacek sorear, none at all.
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
bacek sorear, and POST::Op(:inline(...)) too
pmichaud Q:PIR and :inline() have always been intended as bailing wire and string, not as permanent answers to the puzzle
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
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:08
as sorear and bacek note, they don't play well with direct-to-pbc 23:09
they're really from a time when imcc was the only tool Parrot offered
dukeleto pmichaud: that time is coming to a close
cotto and good riddance
23:10 lucian joined
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)
dukeleto whiteknight++ is isolating IMCC in preperation for ejection
pmichaud dukeleto: Yes, I've been reading his blogs closely. 23:11
Still, our collective track record is not always that good.
dukeleto pmichaud: yes, but we code and learn
pmichaud I can answer for Rakudo when you're ready.
kid51 pmichaud: proceed
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:12
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.
We don't have any specific needs from Parrot to support that, as far as I know.
kid51 okay.
the "should-after" question is as much for cotto as for pmichaud 23:14
chromatic Also "should Parrot even support this"?
pmichaud (other than the standard "don't change anything too radically underneath us that hasn't been deprecated" :-)
sorear Does new-NQP still use IMCC? 23:15
cotto It sounds like "follow our deprecation policy" is all that's needed.
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
sorear or I should say, "PIR as an intermediate step"
pmichaud sorear: yes, if only because it has to at this point.
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.
pmichaud cotto: yes, and chromatic++ as well. I'm just recording it for the log :)
bacek: I plan to steal liberally your pct work. :)
bacek pmichaud, it's in kind of "draft mode" :)
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)
bacek pmichaud, ok. I can probably help with newPCT then
pmichaud bacek: I would like that very much
bacek pmichaud, deal :)
cotto chromatic, can you expand on that?
chromatic If NQP has backend portability as a goal, it needs a compatibility layer. 23:18
It already has one, in its object model.
Why should Parrot do more work for something NQP isn't going to use?
(Besides the fact that if NQP has backend portability as a goal, what's the point of Parrot?)
bacek M0->6model->NQP->Rakudo? 23:19
works for me
chromatic Why not M0-6model->Rakudo?
I mean,
M0->NQP->Rakudo?
bacek chromatic, we need some object model for Parrot runtime.
It can be "current PMCs"
Or new 6model
chromatic To support what? 23:20
bacek PCC? NCI? GC?
pmichaud I think that nqp considers 6model to largely be its compatibility layer
mikehh btw, I put up a page on the wiki as a start point -> Ideas for GSoc 2011
chromatic I have no desire in core Parrot to support NQP's backend portability. 23:21
mikehh which will later become GSoC 2011
pmichaud I mean the 6model api, then, not the model itself.
dukeleto mikehh++
pmichaud I don't think we're asking (or expecting) Parrot to provide backend compatibility
particle chromatic++
bacek chromatic, ooookey. How various HLLs can interop than? 23:22
chromatic Ask Rakudo, I guess.
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
but I keep thinking that object handling needs to be more core than Parrot has traditionally thought of it
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
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
(more)
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.
pmichaud Our experience somewhat says that there's always some level of mismatch between the underlying VM and what NQP/Rakudo need 23:26
what we'd like to see is a VM that minimizes that mismatch so that we get the biggest speed/performance
not necessarily a lowest-common-denominator 23:27
chromatic I'm not sure adding more compatibility layers meets that goal.
pmichaud right
dukeleto Tene: yes, that is my vision as well
pmichaud if Parrot can become the VM that doesn't require a compatibility layer, then it's ahead of the others.
particle are we still in the realm of strategic discussion or off in the weeds, and better suited for #parrot?
dukeleto particle: somewhere in between :)
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?
pmichaud it's a goal, yes, but one where (I think) Parrot can have an advantage
perhaps I'm naive
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
chromatic I'm not telling you how to spend your time, but I personally see no value in pursuing hypothetical portability.
kid51 particle: And the purpose of PDS is strategic, not tactical.
jnthn *sigh*
dukeleto chromatic: that is a choice left to Rakudo developers
jnthn chromatic: Rakudo/NQP is persuing a multi-backend approach. I've heard your opinions.
dukeleto chromatic: we need you to worry about Parrot :)
chromatic I worry that baking these assumptions into Parrot is a mistake. 23:30
jnthn What assumptions?
mikehh chromatic: in what way?
pmichaud Yes, I'm not sure what assumptions are being baked in.
Util arrives, is reading backlog
mikehh Util: good luck :-}
chromatic Supporting NQP, for one.
dukeleto chromatic: you are concerned that 6model will taint the way Parrot does a meta object protocol (MOP) ?
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
mikehh we need to make NQP pluggable
dukeleto Tene++
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.
dukeleto does making NQP pluggable make us go down the road of "pluggable for pluggability's sake" ?
cotto Tene, that's what I'm planning too.
dukeleto jnthn: i don't see it as such
Tene pmichaud: My understanding has been the same.
chromatic NQP is the compatibility layer.
jnthn is very confused. 23:33
dukeleto chromatic: please expand your statement, because as it stands, many of us do not agree.
pmichaud I agree, NQP is the compatibility layer for making Rakudo portable to various vm backends.
(jnthn, please speak up if you disagree with what I just wrote)
chromatic Then I see no value in supporting NQP above and beyond we'd support any other project not in Parrot's core.
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
it's more that 6model may be a reasonable "next oo implementation" for Parrot.
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.
pmichaud it's an oo implementation that we think .... does what Tene++ just wrote
chromatic I have no problem with 6model.
mikehh I see 6model as the most comprehensive object model at the moment
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.
chromatic I have a big problem with focusing Parrot's support on NQP.
pmichaud I don't think jnthn or I are necessarily asking for that. 23:36
jnthn I'm certainly not asking for that.
chromatic I want it out of the repo, out of the tarballs, and I want our tools in the core to stop using it.
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
chromatic I don't have an alternative.
jnthn chromatic: That's all well and good, but what do you want people developing core Parrot tools to write in?
chromatic How about a language/toolkit that doesn't suggest they should migrate away from Parrot?
jnthn WTF?
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.
jnthn chromatic: How is giving people a way to write compilers that target, amongst other VMs, Parrot, suggesting they migrate away from Parrot?
pmichaud I don't think that's entirely unreasonable, fwiw.
chromatic I see no reason why Parrot should support VM backend portability.
jnthn Oh forget it, I'm not wasting my time on this argument. 23:39
23:39 jnthn left
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?
dukeleto chromatic: i agree with you that we should not, but I don't think we are. The Rakudo devs are doing that.
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
pmichaud chromatic: would it be fair to recast your statement as "I don't think Parrot should support tools that provide VM backend portability"?
particle can parrot get an nqp that's parrot-only?
chromatic I don't want to adopt those goals uncritically in Parrot.
particle does that make anyone happy?
chromatic If some/all of those goals make sense in Parrot, that's fine.
pmichaud chromatic: I think I'm entirely in agreement.
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?
particle agreed.
pmichaud it's a tool that lets people write software for Parrot.
chromatic I'm not suggesting that it has no value, but I think we need to discuss its value to Parrot.
Coke for one, it's still easier to write code in NQP than in anything else.
cotto +1
pmichaud that's always been its claim to fame
dukeleto i agree with pmichaud. NQP is basically "something that sits on parrot", and end-user of parrot
23:42 bubaflub left
particle dukeleto: not when core parrot tools become users of nqp 23:42
dukeleto particle: yes, i agree with that
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.
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
chromatic That's not the worst problem though.
dukeleto there is not viable alternative at the moment
particle kid51: how long is this meeting scheduled to continue, and what remains to discuss? 23:44
23:44 bacek left
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?
chromatic I see it more as a question of "Why are we doing this?"
dukeleto chromatic: i share your concerns, but i am not sure if they are our biggest problem currently
chromatic: i agree, it needs some analysis and discussion 23:45
kid51 particle: We don't have a fixed meeting length.
chromatic What is the only real project using Parrot right now?
kid51 The next item to be discussed is the IMCC roadmap item.
dukeleto chromatic: define "real project"
particle nqp.
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 :)
Tene And how can we get there?
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."
mikehh winxed is a good example
chromatic But I'm comfortable saying "Most important" or "Most widely used" project too.
dukeleto chromatic: what is your answer to that question?
chromatic NQP/Rakudo
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
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?
chromatic Is there a good reason to work on Parrot then?
dukeleto chromatic: Parrot has never had a real external user, i.e. a project by someone that was not a Parrot core dev already
chromatic: i am interested in hacking Javascript on Parrot, and I won't be using anything related to NQP. 23:49
chromatic: would you like javascript as the internal parrot language of choice, instead?
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.
allison chromatic: But, that doesn't mean we drop everything and work only on Perl 6.
dukeleto allison: i totally agree
mikehh +1
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.
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.
kid51 Can we move toward translating this discussion into action items?
chromatic NQP's goals aren't necessarily Parrot's goals.
dukeleto chromatic: well, a summary of what would said for those that are not here would be extremely useful
chromatic Rakudo's goals aren't necessarily Parrot's goals. 23:52
dukeleto kid51++ # let's bake some action items
kid51 chromatic: I agree with dukeleto. I would like to see a post on parrot-dev
chromatic If Rakudo doesn't really want Parrot anymore, what should Parrot do?
mikehh yes but Rakudo IS a parrot goal
pmichaud Let me speak to what Rakudo wants.
Rakudo wants a fast implementation of Perl 6.
particle we can fork nqp-rx, or take it over as a parrot core tool
pmichaud That's our current #1 problem at the moment. 23:53
dukeleto pmichaud: yes, i agree
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.
dukeleto pmichaud: i meant to reply to particle, oops
pmichaud Our ability to improve Rakudo's speed has been limited by our toolset.
Not just Parrot, but PCT and NQP as well.
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.
pmichaud perhaps I'm incorrect about that
dukeleto Tene: i like that sentiment
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.
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"?
kid51 pmichaud: The list of action items was based on those raised by participants in that summit.
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?
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.
sorear nwellnhof: the CLR has several implementations; I use an open-source one daily
chromatic I haven't seen Rakudo benchmarks in months.
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.
cotto Let's summarize this and move on.
dukeleto cotto++ 23:58
Tene Summary: Rakudo and Parrot should start going to couples therapy.
kid51 I think we need posts on parrot-dev that address the following:
1. What does Rakudo -- our principal customer -- need from us over the next 3/6/9/12 month periods.
mikehh I thought that the function of Lorito etc was to simplify AND improve the speed of parrot significanyly
cotto mikehh, it is.
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.
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.
chromatic I'm not sure we have a vision.
mikehh that is what I saw it to be as well, especially 6model

Powered by Cro and the Raku® Programming Language.

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

Thank you!