»ö« | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, alpha:, pugs:, std:, or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by moritz_ on 25 June 2010.
20:50 ilogger2 joined 20:53 Cyrus joined
sorear rakudo: my @x; say @x[*-1] 21:01
p6eval rakudo 037f68: ( no output )
sorear rakudo: my @x; sub foo($k) { say $k }; foo @x[*-1]
p6eval rakudo 037f68: ( no output )
sorear in Perl 5, the latter version dies, while the former DTRTs 21:02
:/
21:15 whiteknight joined
mj41 Parrot vs. JVM by allison video.google.de/videoplay?docid=290...749292774# 21:15
21:17 fod joined
sorear whiteknight: I see I wasn't *entirely* crazy when I went all Chicken Little on continuation/inferior runloop interactions those months ago... 21:18
21:19 tylercurtis joined
whiteknight sorear: it's always been a problem, and likely will be for a long time coming 21:20
this certainly isn't my first run-in with it
tadzik mj41: are the slides somewhere around? 21:23
mj41 tadzik: wiki.jvmlangsummit.com/pdf/38_Randal_parrot.pdf 21:24
tadzik: also try to search perl6.cz/wiki/Perl_6_and_Parrot_lin...ot.2C_Pugs 21:25
tadzik mj41: thanks 21:26
21:29 drbean joined
pmichaud good afternoon, #perl6 21:30
diakopter wth is his obsession with [multiple] trampolines?
I know that mono uses at least two 21:31
pmichaud sorry I missed #phasers -- was busy with $otherstuff
sorear Hello pmichaud
diakopter: who? 21:32
diakopter "chromatic's comments on PerlMonks" you asked for
sorear ah 21:33
diakopter "Any runtime for Perl 6 is going to end up looking a lot like Parrot." -- his entire posting reads a lot better if this statement is amended to "Any runtime for Perl 6 is going to end up looking a lot like an attempt at a Perl 6 implementation."
jnthn pmichaud: No worries. :-)
pmichaud I guess I should comment on the perlmonks thread. 21:36
diakopter by "support Perl 6" it sounds like he means "support all of Perl 6's control flow and memory management structures natively", which shows merely that he wants certain parts of the implementation at the same level as the GC/JIT. 21:37
21:39 chromatic joined, masak joined
masak ahoy! 21:39
phenny masak: 19:32Z <sorear> tell masak yes, protopad = static lexpad. static lexpad is probably more correct now since I've eliminated all prototype aspects of the static pad.
jnthn yayitsmasak! 21:40
masak I missed tonight's #phasers. ごめん。
chromatic Okay, anyone who wants to psychoanalyze me can do it while I'm here.
pmichaud masak: I missed it also. :-)
masak I will make up for it in a completely non-satisfactory way by reading its logs.
jnthn masak: Not loads happened. You did miss your chance to say "omg finished my gsoc proj!" :-)
masak pmichaud: yes, but your missing it was probably honourable, whereas mine was not.
jnthn: perhaps I get to say that in all other possible circumstances instead. :P 21:41
21:41 PZt joined
jnthn masak: Do we want to know what dishonorable thing you were up to? :-) 21:41
masak jnthn: I was indulging in an impromptu dinner. 21:42
I... got a bit carried away...
jnthn Inpromptu dinner causes inpromptness.
;-)
diakopter chromatic: it seems I could do it while you weren't here, too 21:44
chromatic My preference is while I'm here. 21:45
masak chromatic: you should be here more often.
[particle] how does that make you feel? 21:46
masak [particle]++ # the only one who gets it 21:47
TimToady I prefer to psychoanalyze parrots. 21:49
[particle] tell me more about parrots.
chromatic As long as those psychoanalyzed parrots get bugs filed on them, great!
masak chromatic: according to @chromatic_x on Twitter, you're a grump today. 21:50
chromatic Well sure, but I'm happy to explain what I mean by "writing trampolines for the rest of your life". 21:51
sorear What definition of trampoline are you using? 21:54
chromatic The rough "My platform's native calling conventions don't support all of the operations I need to do, so I need to do something clever in them so I don't recurse forever and still support the non-linear control flow I need." 21:55
diakopter chromatic: I agree with your point (that a Perl 6 runtime will look a lot like Parrot). But I claim it will be built on [not part of] something that has a very robust (thousands of productive hours put into it) GC and a very robust JIT. I believe that solely because of the resources [un]available to parrot. 21:56
but of course I'm not *complaining* about that lack of resources. ;) 21:57
chromatic You pick your poison though.
Build on an existing platform which provides a GC and a JIT, and you have to build the rest of your Parrot workalike.
You may or may not be able to tell that GC and that JIT how Perl 6 works. 21:58
You may or may not be able to ask for platform changes to smooth out any impedence mismatches between it and Parrot.
diakopter yeah. that's the poison.
pmichaud rakudo and nqp's perspective is that we're hedging our bets on both solutions, fwiw. 21:59
s/solutions/paths/
sorear I fail to see the distinction here
PaFo has ... exactly how much ... chance of getting a change approved to ISO C or the Pentium ISA?
chromatic As much as anyone. 22:00
masak sorear: why would it need that?
chromatic PaFo also has the same chance of getting a change approved to the Mars mission.
TimToady you're planning to host parrot using the Mars mission? Cool!!! 22:01
pmichaud lol 22:02
sorear masak: chromatic appears to be arguing against rakudo -> (parrotoid) -> CLR on the basis having less control than rakudo -> (parrotoid) -> C89
masak sorear: ah.
chromatic I'm not arguing *against* anything.
diakopter chromatic: I'm quite certain that a parrotoid -> CLR will be able "... tell that GC and that JIT how Perl 6 works." CLR has WeakReferences and quite a lot of control over the GC, actually, and JIT control is "solved" in my C# sprixel runtime, from which niecza spawned, sort of. 22:05
and that's ignoring the strong possibility of distributing a custom mono 22:06
chromatic Are you able to have precise GC?
sorear (I should point out that I'm only avoidng Parrot for short-term performance reasons, since niecza is really just intended as a better viv. Once lorito lands there will almost certianly be a port to Parrot) 22:07
pmichaud fwiw, I'm not sure what this discussion is about.
(not that I need to, but I have trouble seeing a coherent thread)
masak chromatic: while on the topic of GC, I've never heard anyone explain how the DESTROY submethod would work in Perl 6 on top of Parrot. maybe you know?
diakopter pmichaud: I think it was about www.perlmonks.org/?node_id=855567
pmichaud diakopter: sure, I saw that thread.
diakopter that's what I think it was about 22:08
chromatic masak, are you asking about timely destruction?
pmichaud diakopter: but perlmonks seems to be more along the lines of "Rakudo should focus on finishing what it has instead of looking at other backends."
and I disagree.
sorear People have an expectation that { my $x = open "foo" } should close foo immediately
I think this is a P5ism and should die
diakopter pmichaud: I meant that url exactly.
that post.
pmichaud sorear: it's already been declared dead, at least on #perl6 22:09
masak chromatic: no, I'm asking if there's some decision, anywhere, about how the plumbing between the GC and the DESTROY submethod will actually work.
chromatic I still don't understand that question then, masak.
sorear closing files should be done with an explicit framing construct, like C# and Java have now and Scheme has had since forever
jnthn chromatic: I guess it partly boils down to, "is the destroy v-table method in object overridable"?
Or more ot the point
What would be the consequences of doing so? 22:10
masak chromatic: maybe I'm phrasing it badly. all I'm seeing in the spec is a hand-wavey "DESTROY will get called on destruction". that's not enough for an implementation.
jnthn I don't think it's an especially big deal though.
chromatic I've overridden it before. As far as I know, it's still overridable.
jnthn OK
We may be able to hang it off that then.
masak actually, it's probably DESTROYALL that would be called by the GC.
s/probably // 22:11
tylercurtis jnthn: trac.parrot.org/parrot/browser/trun...t.pmc#L289
chromatic Given automatic allocation and deallocation of PMC attributes, you're not leaking anything then either.
22:11 pmichaud_ joined
diakopter chromatic: mono's is not precise, and neither is .Net's 22:11
pmichaud_ *sigh* feather connection fail
jnthn tylercurtis: hmm
pmichaud_ diakopter: I agree with chromatic's bottom point on that post (more)
"I suppose the question is whether another runtime can create enough trampolines to prop up the as-yet-unported pudding layer sooner than we can fix those bugs in Parrot." 22:12
Rakudo and NQP are taking the approach that we're willing to explore both paths.
chromatic I suppose my point on the PerlMonks thread, phrased badly and nearly implicit, is that "Supporting additional backends from PCT doesn't necessarily take away from the goal of a performant, spec-compliant implementation of Perl 6 with Rakudo but it's definitely not a quick way to get a performant, spec-compliant Rakudo."
I think the desire to support multiple backends was one of the two things that killed Pugs.
pmichaud_ chromatic: I agree, but I think Pugs had different motivations for multiple backends 22:13
chromatic Yes and no.
22:13 hugme left
diakopter heh 22:13
chromatic One of those desires was -Ofun for sure, but Pugs had unusable performance.
TimToady I don't think multiple backends killed pugs *at all*
masak oh noes, hugme quit?! :(
pmichaud_ I don't think unusable performance was what killed bugs
*pugs
I think it was an unmaintainable core codebase
chromatic I stopped using Pugs when the spec tests took 8 hours to run.
22:14 PerlJam left
chromatic I don't mind cleaning up unmaintainable code. 22:14
See also IMCC.
TimToady patches welcome
sorear I started using Rakudo when 'make' took 12 hours.
masak the decrease in bus number killed Pugs.
chromatic I seem to recall fixing that, too.
pmichaud_ chromatic: the point is, that nobody has stepped up to maintain pugs
sorear yes. chromatic++
pmichaud_ 'make' has never taken 12 hours on my system, fwiw. it's never taken more than 1.
chromatic It's too simplistic to say "No one could maintain Pugs." 22:15
diakopter chromatic: oops, I'm wrong; the just-released major release of Mono (2.8) does have a precise one.
chromatic No one could maintain Pugs for at least one reason.
pmichaud_ I didn't say "no one could maintain pugs". I'm saying "no one has"
masak chromatic: "No-one has wanted to maintain Pugs."
pmichaud_ and the reason it's not maintained has little to do with multiple-backend-ness
chromatic Fair point, but I'm not sure it changes my argument.
masak or what pmichaud_ said.
chromatic diakopter, are you able to give the GC hints about object layouts for precision?
No one has maintained Pugs for at least one reason.
diakopter chromatic: sigh; another correction; 2.8 isn't released yet 22:16
pmichaud_ one thing we do know that is different between pugs and rakudo is that rakudo's parser is accessible to more people
chromatic That's a huge advantage for Rakudo, yes.
pmichaud_ and I've maintained that parsing is at the core of making a successful perl 6 implementation.
chromatic Being able to write in NQP and Perl 6 is another advantage.
sorear chromatic: the CLR knows object layouts (it's a lot like the JVM in how it handles this)
pmichaud_ that's where pugs ran into difficulty -- it was hard to grok the parser and translation unless you were a strong lambdacamel 22:17
TimToady the chief problem with pugs is that the code got too smart for anyone who isn't brilliant to understand
much of the time in #perl6 back then was explaining what snippets of Haskell are really doing
masak or it was too smart from the beginning.
chromatic I recall that, as you recall.
Pugs never had a strong priority of improving its bus number. 22:18
TimToady it did, but Haskell didn't. :)
pmichaud_ returning to my earlier comment -- rakudo and nqp are basically entering a phase where we're going to see if parrot improves faster than our ability to target another vm 22:19
sorear (am I the only one who thinks Juerd ought not to IRC from feather?)
masak jnthn++ # "The hottest footwear!"
jnthn: that's your best pun in a long time!
chromatic Maybe I'm wrong, but I've always thought that the effort spent on supporting multiple backends for Pugs took away from making Pugs more maintainable.
pmichaud_ and it's not mutually exclusive -- we fully expect that what jnthn learns from implementing a new object metamodel in nqp will get ported back into Parrot 22:20
jnthn masak: Wow, one you like. :-)
masak jnthn: yeah, almost all the other ones were awful :P
jnthn chromatic: The way this is looking at the moment is that we'll end up with _more_ written in NQP.
chromatic: Which means more hackable.
(And more portable.)
chromatic Unless it's a pudding layer.
jnthn And also fewer primitives that need to be made fast. 22:21
TimToady Perl 6 is pudding. Yum!
diakopter mmm butterfly pudding
pmichaud_ chromatic: (I'm speaking for jnthn here a bit) I think that neither jnthn nor I have a lot of confidence in our ability to effect changes in Parrot except by first prototyping them outside of Parrot.
(jnthn please clarify if I'm mis-stating your feelings on this) 22:22
jnthn It's not a mis-statement, just not a full one. I also believe it's _easier_ to prototype at least the current set of stuff I'm doing outside of Parrot. 22:23
chromatic Use cases and design constraints definitely help me make and suggest changes to Parrot.
pmichaud_ chromatic: agreed, and so we're looking to provide them.
jnthn But yes, it's true. In the prototype I'm working on, I could just throw in a "static lexpad" concept and hack up an auto-close that uses it and move on. It took me 10 minutes. Now I get to see how it works and how useful it is. 22:24
chromatic I support that fully, but in my mind that's orthogonal to supporting multiple backends.
TimToady one way to view these parrot attempts at high-level features such as multimethods is that they are useful prototypes that should expect to be thrown away
chromatic That's how I view them.
jnthn TimToady: Right. They have been _enormously_ useful in getting us started. 22:25
pmichaud_ ...except that Parrot has had trouble with the "expect to be thrown away" part (e.g., deprecation policy)
TimToady that's getting better, I think
pmichaud_ sure, I agree
chromatic I like to think our current deprecation policy has improved a lot.
22:25 fod left 22:26 fod joined
pmichaud_ but we still have plenty of cases where core issues in Parrot haven't been addressed. NQP can (1) block, (2) try to improve parrot, and (3) explore other ways of solving the problem. 22:26
multiple backends falls into 3
chromatic My preference is 2, 1, 3. 22:27
pmichaud_ well, that makes sense. I've had little success with 2.
TimToady 3 also feeds back into knowing how better to express what we want from 2
chromatic We'll see.
TimToady We've already seen. :) 22:28
sorear Do you have a stand on non-Rakudo implementations not using Parrot? 22:29
chromatic Does it matter? I'm not in charge of how other people spend their time. 22:30
pmichaud_ beyond the points illustrated above, the other reason for targeting other backends is that, as was pointed out to me last year, there's one major scripting language that doesn't run on .Net
chromatic Ruby?
pmichaud_ ;-)
okay, maybe two. but the point is, I'd like for Rakudo to mean more than "Perl 6 on Parrot" 22:31
I'd like it to be robust enough to be shared on multiple platforms.
sorear FWIW Niecza is stealing bits and pieces of Rakudo all over the place
both design and actual code
diakopter Microsoft contracted ActiveState to build ActivePerl.Net, and they did for a while in 1999-2000, but it was abandoned.
pmichaud_ Allison also made a similar comment at yapc::eu -- that she felt that it was important that we target multiple backends so that we can show other languages a path by which they can ultimately target Parrot. 22:32
perigrin ActivePerl.NET wasn't Perl on the CLR
diakopter sorry, there was one that was Perl on the CLR
perigrin but perl embedded into the CLR with a bridge
TimToady yes, just a bridge
diakopter I found the one that was a Perl implementation, not the bridge
sorear Is "Perl on the CLR" allowed to use unsafe blocks 22:33
diakopter I say yes.
TimToady as long as they're declared unsafe :)
sorear rewriting the p5vm without pointer arithmetic sounds like "fun"
chromatic I suppose it's two things. 22:34
sorear and by fun I mean 20+ man-years
TimToady oh wait, you weren't asking my permission...
chromatic 1) I have a concern that supporting multiple backends will provide some distraction from making a spec-complete Rakudo on any backend. I know developers aren't completely fungible, but there is a pudding layer.
2) I want that pudding layer for Rakudo on Parrot to move as much into Parrot as possible.
masak Yapsi is also heavily inspired by Rakudo.
pmichaud_ We want #2 also. 22:35
TimToady I want the pudding layer for Rakudo to move as much as possible into Perl 6. The only way we can agree is to reimplement large chunks of Parrot in Perl 6.
which is a disavowed goal of Parrot. :) 22:36
jnthn The pudding layer should be lagom. :-)
masak :)
pmichaud_ and yes... Rakudo has experienced the pushback that TimToady++ mentions quite heavily.
It's much less so in recent months... but that may also be because we've stopped pushin. 22:37
*pushing.
chromatic I don't understand any of that. 22:38
TimToady you really shouldn't give us straight lines like that...
diakopter as in... so obtuse... 22:39
diakopter just startled all my cow-orkers with a guffaw 22:40
chromatic Look, I'm trying to communicate something here I find important.
pmichaud_ I recognize that. 22:41
I'm not sure what part isn't understood.
chromatic What is that pushback and what does it mean?
I think also "Why is there pushback?" but that question may depend on my previous one.
masak wants to go to bed but finds the discussion fascinating 22:42
pmichaud_ when we identify things that Perl 6 needs from Parrot, we have historically gotten "Perl shouldn't be dictating what Parrot provides"
or, even if we identify something really important, it takes months or years for progress to be made on it
chromatic I can think of several examples.
pmichaud_ I think you mentioned PCC earlier -- that's probably a very good example, and spot-on for this discussion. 22:43
chromatic I have spent a lot of effort to improve that in 2010.
pmichaud_ the PCC that parrot put together wasn't sufficient for Rakudo's needs, and that was explicitly identified at the time it was being done 22:44
chromatic If I have to spend more effort to do so, I will.
pmichaud_ i.e., it was recognized at the time it was being done that we'd ultimately end up writing our own dispatcher
jnthn (binder in this case, I think) 22:45
pmichaud_ right, binder
thanks.
jnthn (though we've needed our own dispatcher too)
22:46 awwaiid joined
pmichaud_ By no means do I wish to discount or downplay the improvements that Parrot has made over the past year. They've been terrific. 22:46
jnthn I agree. Parrot _has_ improved and it has helped.
chromatic That's deliberate. 22:47
22:47 masak left
pmichaud_ and we recognize that also. If we're not saying it enough, I'll say it more frequently and publicly. :) 22:47
but there are also some areas where the pace of change feels.... glacial.
chromatic Then we will prioritize them. 22:48
pmichaud_ we've prioritized them a bit also
thus, the #1 item I identified at yapc::na we're already working on -- object metamodel improvements
it is fully expected that we'll do a new metamodel in Parrot. 22:49
chromatic Sure, and I understand that sometimes Rakudo needs things before Parrot can provide them appropriately.
It has to go both ways, though.
pmichaud_ and we fully expect that someday Parrot will completely switch over to our new model.
jnthn Do we? :-)
pmichaud_ jnthn: I do.
chromatic I do.
jnthn I don't quite have that much hubris. ;-)
Oh, OK
:-)
\o/ 22:50
jnthn polishes it extra shinily
pmichaud_ but at the same time we may be able to make some progress on a multiple-backend strategy, so we're doing that too.
chromatic I expect to have my own input into it with regard to what else Parrot needs, but yes.
pmichaud_ the other items identified at yapc::na.... I'm not so certain how they'll get handled. 22:52
jnthn chromatic: That's fine, so long as we end up with a superset rather than disjoint sets. :-) Given I'm aiming very a very small "core" and then NQP gets everything built atop of that, a superset could still be pretty small, though.
s:1st/very/for/
pmichaud_ where did the yapc::na list end up, anyway? I thought it was on the parrot wiki but I don't see it now. 22:53
chromatic Someone took a picture of it.
pmichaud_ I thought it was also transcribed somewhere.
pmichaud_ looks.
chromatic I think that small core, fat NQP works against Parrot's interests in some ways. 22:54
pmichaud_ in some sense "small core" is really "Lorito"
chromatic If we implement most of the rest of Parrot in terms of NQP perhaps. 22:55
TimToady or QP
pmichaud_ assuming one of parrot's goals continues to be multiple languages running on top of it, what do we expect those languages to be written in? 22:57
(honest question, not rhetorical)
TimToady whatever the implementors choose to use 22:58
chromatic NQP seems the most likely candidate.
TimToady in the short term
chromatic Right, in the short term.
pmichaud_ I agree that may be only a short-term answer.... but I'm fairly sure they won't be doing it in PIR or the standard opcode set.
so Parrot has to provide something a bit higher-level than what it has now, if NQP is excluded. 22:59
either way, I think we end up with small core, fatness in an intermediate layer
chromatic I see no technical reason to exclude NQP.
pmichaud_ right. I'm just saying that "fat NQP works against Parrot's interests" would seem to apply to almost any other pudding layer 23:00
so then it's a question of "what are Parrot's interests...?"
chromatic I interpreted it as "Pudding written in NQP" not as "Pudding available as part of NQP".
tylercurtis Why not both?
chromatic The former doesn't necessarily imply the latter, but the latter could imply the former. 23:01
pmichaud_ even as "Pudding written in NQP", that sounds a bit like Lorito. Small core, higher-level stuff written in a higher-level abstraction.
perhaps the wrong abstraction, but...
chromatic And I'm fine with that.
I believe it's in Parrot's interests to take many of the Rakudo workarounds, polish them, generalize them, perhaps make them extensible for some Rakudo-specific customizations, but ultimately adopt and absorb them. 23:02
pmichaud_ I agree. 23:03
chromatic Parrot can provide most of the pudding. You can put chocolate chips and marshmallows in it.
TimToady that strikes me as premature optimization, usually
chromatic What does, TimToady?
pmichaud_ I'd really like for Parrot to provide more of the pudding. But so far things haven't moved in that direction very quickly. 23:04
TimToady you want most of what you do to be in high level language, and then take bits into core
not assume it's almost all going into core
fsdo core
tylercurtis TimToady: I think a large part of the purpose of Lorito is so that much of Parrot's "core" can be written in high level languages.
chromatic I'm talking of things like dispatch and binding, not necessarily the setting. 23:05
TimToady sure
pmichaud_ we're talking of dispatch and binding in NQP also
iiuc what jnthn++ is working on
23:05 awwaiid left
chromatic My *preference* for supporting multiple backends is to port Lorito's M0, not NQP. 23:06
pmichaud_ I don't see a problem with that (more)
TimToady my preference is that they be the same :)
pmichaud_ NQP would have no issue with targeting a Lorito M0 that can then go to multiple backends
chromatic Which would you like to be the same, TimToady? 23:07
pmichaud_ but I think that we'd need some exploration about how to get our higher-level concepts onto those other backends, so that we know what M0 would need to look like
TimToady Lorito's and NQP's MO
jnthn chromatic: Thus why NQP's class meta-object will be written in NQP.
pmichaud_ ...and that's exactly the avenue that jnthn++ is exploring.
jnthn chromatic: And thus I won't have to port it. :-)
Sounds like if we can agree on what comes beneath that, we have a chance of converging. :-) 23:08
pmichaud_ the url I have for the lorito bof notes is thenceforward.net/parrot/yapc_bof_20100621.txt but it seems to be gone/missing now.
tylercurtis webcache.googleusercontent.com/sear...&gl=us 23:10
chromatic Instead of emitting NQP code for another backend, you're okay with emitting Lorito-compatible code?
pmichaud_ i'm not sure about "emitting NQP code" -- we don't do that now. afaik.
right now we have an emitter for PIR
jnthn is working on a .net emitter
23:11 lestrrat is now known as lest_away
pmichaud_ I don't see any reason why we'd have difficulty with a Lorito emitter 23:11
jnthn chromatic: Oh, I was talking about the object-y stuff, not the code generation.
But the approach is the take PAST and then emit different things from that.
pmichaud_ ....and write the emitters in NQP, ultimately.
in that sense, it's similar to what PIRATE is doing.
23:12 drbean left
jnthn pmichaud_: Already am. 23:12
pmichaud_ (iiuc what PIRATE is doing)
chromatic Yes, that's the intent of PIRATE
jnthn pmichaud_: github.com/jnthn/6model/blob/master...ompiler.pm
pmichaud_ if Lorito's M0 ends up handling the multiple backend aspects for us, we'd happily target it. 23:13
23:13 jhuni joined
pmichaud_ but something is going to need to describe the metamodel, and it makes sense for us to write that description in p6 or nqp 23:13
chromatic Right.
pmichaud_ that's what we're doing.
well, jnthn++ thus far.
chromatic Yes, portability to other backends is a possibility of Lorito. I'd like to see it run on Dalvik, for example. 23:14
pmichaud_ I would view NQP and Rakudo's work on multiple backends as being the path by which Lorito learns what is needed for it to target other backends, then.
chromatic I don't see that as helpful to Lorito.
It's not harmful, but I don't think it's necessary. 23:15
pmichaud_ I do. I don't think the people involved in creating Lorito have enough understanding of Perl 6's needs.
chromatic In what sense?
pmichaud_ I mean as a team dynamic; certainly individuals (yourself) are there. 23:16
but when we say we need serialization, the discussion tends towards proving that parrot already has what we need instead of seeing that the current model is tragically flawed.
or when we need better exception handling and subroutine leave semantics... there's just not an understanding of the issues that we're trying to express. (more) 23:17
or, when I give Perl 6 code to try to illustrate it, the answer often comes back with "that's something Perl 6 will have to layer on top of parrot, not something parrot should natively provide"
sorear there is also an attitude that providing for Perl 6 is politically untenable because it undermines the notion of Parrot as a cross-language VM 23:18
chromatic Then stop perpetuating that myth, sorear. 23:19
sorear It perpetuates fine in #parrot without me
I only ever talk about it here
chromatic I disagree, and filing Parrot bugs in here is not effective. 23:20
pmichaud_ but more to my original point -- how often do discussions of Lorito also include "and we need it to go to other vm backends?"
chromatic Not often, mostly because that's not the primary goal of Lorito. It's a benefit and it's something I want to make possible, but it's not the primary goal. 23:21
pmichaud_ I don't recall seeing anything in the lorito discussion documents that mention .net or jvm or the like. Maybe I'm just missing them.
if that's a goal, then we'll need some experience to feed into the design.
chromatic Maybe I'm horribly naive, but I believe that most of porting Lorito to another backend is mapping the handful of M0 ops to another VM. 23:22
pmichaud_ Do we know what M0 ops are needed to efficiently implement a p6-like object metamodel?
chromatic I believe the same M0 ops needed to implement just about anything else we support right now. 23:23
pmichaud_ that's the disconnect (more) 23:24
what "parrot supports right now" is not really what Rakudo needs.
or, it's a good first approximation, but we need to refine it a lot more
in some sense that statement feels like it might repeat the error that Parrot originally made, when it sought to reimplement the Perl 5 vm 23:25
because that vm wasn't really what is needed for Perl 6
chromatic Let me rephrase then.
pmichaud_ okay, please do.
I know my statements probably read much harsher than I intend. 23:26
chromatic If we can port Parrot as it exists now to M0, M0 is sufficient to implement an efficient metamodel in NQP.
pmichaud_ I'm not so sure about that.
diakopter (what's M0)
chromatic M0 is a series of very low level ops, as if you were writing a virtual machine for a language like C without hewing to its memory model or calling conventions. 23:27
s/series/set/
pmichaud_ I still remain concerned that Parrot focuses far too much on opcodes when what we really need is methods
chromatic Me too. 23:28
pmichaud_ and since the discussions I've seen of Lorito are focused on making opcodes more efficient, I worry that it's gotten things backwards.
chromatic I want to make vtables go away in favor of multimethods in Lorito.
Better?
pmichaud_ Definitely. 23:29
TimToady is not so sure...
chromatic Why is that?
pmichaud_ TimToady: I still think we'll have the notion of vtable-like things that are hidden from the normal method call interface, but they still end up acting very method-like. 23:30
TimToady it just feels like interpreter-on-top-of-interpreter to me 23:31
23:31 Italian_Plumber joined
TimToady and FP is fundamentally built on lambdas, not multimethods 23:31
pmichaud_ that's a good notion/point to remember.
chromatic Some FP has to perform pattern matching for dispatch though. 23:32
pmichaud_ anyway, I'll be called to dinner soon (more)
TimToady Yes, "some", not "all"
pmichaud_ I'll note that while others have focused on the fact that NQP is looking at other backends, it is not at all the core team's primary focus at the moment, except maybe for jnthn++ 23:33
i.e., what gets the most publicity is not necessarily where the effort actually ends up
chromatic Like I said, it's none of my business how other people spend their time.
I just want to make sure that Parrot supports Rakudo as best it can.
pmichaud_ +1 to that :)
chromatic If that means pleading and cajoling to pull parts of proofs of concept and workarounds into Parrot, so be it. 23:34
pmichaud_ Perhaps kid51 can re-produce the notes he had posted from the yapc::na meeting
[particle] i think they're on the parrot wiki, but i can't recall
pmichaud_ [particle]: I couldn't find them there. 23:35
tylercurtis chromatic: Is the Parrot object model intended to be implemented on top of M0 in some manner? If so, I suppose that that means it will probably allow pointer arithmetic? In which case, how do we translate pointer arithmetic to JVM ops?
[particle] harumph
tylercurtis webcache.googleusercontent.com/sear...&gl=us google cache of broken link pmichaud_ mentioned earlier to those notes, I think.
chromatic I don't think we have to support pointer arithmetic; we just have to support numbered slots.
pmichaud_ tylercurtis++ # yes, that looks like it 23:36
my comments from lists.parrot.org/pipermail/parrot-d...03223.html also still apply
#4 has been addressed.
chromatic #1 is in progress, as always. 23:37
pmichaud_ #1a has been worked on
I haven't seen much new from #1b lately
#2 is still a bit of an issue
chromatic I can work on #6 if you want it now. It's fairly easy.
pmichaud_ jnthn++ is working on it 23:38
chromatic Lexicals?
pmichaud_ yes
as well as attributes
and we still have some p6 spec work to be done there
TimToady hides
chromatic Primitive lexicals seems like an easy fix in Parrot. 23:39
jnthn I'm only digging into attributes for the moment.
pmichaud_ sure, but we still need tools to be able to support them
jnthn It's too early for me to say whether Parrot doing #6 will for certain help but I suspect yes.
pmichaud_ and even if you gave us primitive lexicals tomorrow, I doubt we'd do much with them until after jnthn's work lands
chromatic NQP support you mean?
pmichaud_ NQP and PCT, yes.
jnthn (In the long run, not "tomorrow", as Pm said)
Well, medium run
:-) 23:40
chromatic Let me know. I know how to make them work in Parrot.
pmichaud_ right
that's one of the reasons that item was #6 on my list -- it's worth considering but not a huge impact
#2 from the yapc::na list is more important (the general handling of lexpads and contexts in parrot)
chromatic Sure, but a week of work for lexicals is going to land sooner than a month work of lexpand handling. 23:41
jnthn chromatic: What I will say is don't spend time on native type support in the Object PMC. 23:42
chromatic: Well, re-phrased.
Don't spend time on it in the epxectation it'll help Rakudo.
pmichaud_ my feeling is that this is an area where lexpad handling will ultimately be the arbiter of how it needs to work
chromatic Right, that's part of metamodel changes.
jnthn (Think you know that, but don't want to send you down a blind alley.)
pmichaud_ i.e., the week of work for core types in lexicals would ultimately be lost because lexpad handling implies a more radical change anyway 23:43
23:43 mjk joined
pmichaud_ not sure that's the case, but that's my feeling. 23:43
chromatic They have to be able to store and retrieve things that aren't PMCs anyway.
pmichaud_ it feels like one of those fundamental things like list/arrays/iterators in p6, where the smallest change in the fundamentals ends up having radical changes on the entire system
chromatic Adding typed storage is fairly easy.
jnthn I think we may need a model change though. 23:44
pmichaud_ anyway, typed storage might be of some use to NQP at some point, it's very unlikely to help Rakudo anytime soon.
i.e., Rakudo's typed storage is likely to be based on the object metamodel.
and not on Parrot register types.
jnthn For example, the static lexpad and dynamic lexpad probably want to look a lot more alike.
chromatic Including lexicals?
trac.parrot.org/parrot/wiki/PCCPerf...provements 23:45
I want to address how we handle contexts and signatures anyway.
That could include more specific types of Subs, like Closure.
pmichaud_ ...Closure?
chromatic Or at least a specific Sub subclass which knows it has an outer scope. 23:46
outer static scope
jnthn argh, didn't we kill that?
pmichaud_ ah.
well, that's a piece we're definitely missing.
23:46 mjk left
chromatic static scopes? 23:46
pmichaud_ afaik, we don't have a way in Parrot to say "create a Sub of type OtherPMC"
TimToady seems more like you'd want a specific class that *doesn't* know about that, since the default is to have an outer
pmichaud_ and yes, what TimToady said
we have far more subs with outer scopes than subs without. 23:47
subs without outer scopes are quite rare in Perl 6, or NQP.
chromatic I have no preference which is the default, merely that we can distinguish them.
pmichaud_ right now we can distinguish by the existence of an :outer flag :-)
jnthn Isn't that just a pointer-is-not-PMCNULL check today?
TimToady it should be orthogonal to type
jnthn (e.g. the otuer thingy)
pmichaud_ and yes, the inability to have good sub types is a blocker for many parts of NQP and Rakudo. 23:48
chromatic I don't want to perform runtime checks for things we know at compile time.
pmichaud_ we don't always know the outer at compile time.
TimToady huh?
jnthn pmichaud_: We _can_ conceptually though.
pmichaud_ TimToady: artifact of Parrot's compilation model.
yes, conceptually we can.
jnthn pmichaud_: Other things keep us from doing so.
Right. :-) 23:49
pmichaud_ but imcc's linkage is a problem.
jnthn That's the disconnect there.
[particle] shoots imcc 23:50
pmichaud_ anyway, NQP suffers from the Sub PMC type problem today -- it doesn't have a way to compile-time create a Sub of type RegexPMC
(or any subclass of Sub)
[particle] if only bullets stopped zombie compilers
pmichaud_ I'm being called to dinner
chromatic I think that's fixable.
TimToady
.oO("put a bullet through csh's head")
 23:51
pmichaud_ chromatic: I think it needs to be fixed as part of a larger serialization fix
although perhaps there's an intermediate step
chromatic :subtype( 'MyCoolSub' )
pmichaud_ chromatic: would that work even if MyCoolSub is a type created during :load :init ? 23:52
i.e., not a core PMC or dynpmc?
chromatic Not sure, but it could be fixed.
pmichaud_ okay. That gets into some nasty parts of imcc, I fear.
and definitely affects freeze/thaw sorts of things, I suspect. 23:53
anyway
chromatic: your concern about multiple-backends diluting effort is noted; let us know if it looks like progress in other areas is stalling.
chromatic Will do. 23:54
pmichaud_ I don't agree that multi-backends was a primary cause for lack of effort on pugs
but I agree it is a danger
chromatic It wasn't the primary cause no.
pmichaud_ personally, I still measure success in terms of how usable rakudo is for the typical programmer
and for me, that's features and speed at this point 23:55
(and correctness)
okay, gone to dinner.
TimToady chow 23:56
sjohnson ciao 23:57
（　｀ー´）

Powered by Cro and the Raku® Programming Language.

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

Thank you!