Parrot 5.0.0 "Johnny Five Alive" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 23 January 2013.
00:19 Reini joined 00:50 PacoAir joined 01:24 PacoAir left 01:27 PacoAir joined 02:17 kid51 joined 03:12 kid51_ joined 04:43 Reini joined 06:08 Reini joined
cotto allison: What happened that made Parrot's developers switch from building a vm just for Rakudo to providing one suitable for all dynamic languages? 06:28
07:09 Mike-PerlRecruiter_ joined 08:28 bluescreen_ joined 09:43 Psyche^ joined
dalek p: 6b358a3 | jnthn++ | src/core/NQPRoutine.pm:
Toss now-unrequired clone callback legacy code.
 11:51
p: f92cd68 | jnthn++ | src/QAST/Operations.nqp:
Add an nqp::escape that maps to pir::escape.
p: 3f27005 | jnthn++ | src/stage0/ (9 files):
Update bootstrap.
p: 26d0d0f | jnthn++ | src/QAST/ (2 files):
Get QASTNodes free of pir::.
12:21 mj41 joined 12:40 xcombelle joined 13:09 kid51 joined 14:10 bouncy joined 14:11 PacoAir joined 14:14 PacoAir joined 14:23 Psyche^ joined 15:22 benabik joined 15:38 xcombelle joined 15:46 Reini joined
allison cotto: ititially, it was just a "bonus" 16:38
cotto: the idea that if you design the architecture with good encapsulation between internals and parsing/compiling, then it would mean you could support multiple languages easily 16:39
cotto: but it grew over time, especially as Dan became disilusioned with Perl 6 design
cotto: the more Dan hated Perl 6, the more focus he put on supporting multiple languages 16:40
cotto: see, the whole tension between Perl 6 and Parrot didn't start with Rakudo
cotto: it went all the way back to the root
At the time, I thought Dan was a bit daft. (I was on the Perl 6 design team at the time.) 16:41
Sort of like "here, we've got this lovely design for you, don't you want to implement it?" 16:42
But, when I became architect, oddly, I found myself following in his footsteps.
I started with total focus on supporting Perl 6, and rapidly got more and more grumpy about the weird things Perl 6 wanted. 16:43
Truly weird things.
I see this as a fundamental flaw in Perl 6 as a whole. 16:44
Not the features, they're weird, but features are always changable.
The flaw is the separation between design and implementation. 16:45
Perl 1 was all Larry, design and implementation.
So, if he ran across a piece where he thought "this is a pretty neat idea", but found in practice that it didn't work, he'd just chuck it, or refine it so it worked. 16:46
Perl 4 and Perl 5 were grander, but still very practical, very focused on what's needed right now for a usable language. 16:47
Perl 6 slipped the bonds of gravity. It was never required to be practical.
And the most frustrating thing as an implementer is when you tell a designer "the laws of physics don't work that way", and the designer says "make them work that way". 16:48
Curiously, the whole "multi-language" thing is what scared Java and Microsoft the most. 16:53
That's what made them see Parrot as serious competition, because they couldn't support the lanaguages Parrot was targeting. 16:54
So, they threw money at the problem, hired a bunch of developers to work on it.
And both of them more-or-less solved the problem.
The JVM and DLR can support dynamic languages well enough now. 16:55
Not as well as Parrot might be able to provide someday, but better than anything Parrot has actually provided so far.
We were so convincing, that we changed the world. :) 16:56
davidfetter so you're saying parrot was like the al-qaeda of VMs in that it produced a massive overreaction to the perceived threat? 17:01
allison davidfetter: heh :) good analogy
and in the process, wiped out it's competitive advantage
davidfetter you never know *how* you're going to change the world. it's nice when you get to change it :) 17:02
allison I agree :)
Tweaking Microsoft and Sun is something I'll remember fondly :)
davidfetter re: sun, /requiescat in pace/ 17:03
allison at the rate they're going Microsoft won't be far behind 17:04
seems like Oracle has the greatest motivation to pick them up too :) 17:05
pmichaud good morning, #parrot 17:09
allison good morning, pmichaud 17:10
benabik o/ pmichaud
pmichaud very interesting discussion on parrot-dev. :-) 17:11
allison indeed 17:12
dalek p/rx-portability: f5d0a8b | jnthn++ | / (5 files):
Stub in an NFA representation.

We'll keep it in the current form for construction; this is what we'll feed to the executor and also serialize them as.		 17:13
p/rx-portability: ecc5234 | jnthn++ | src/QAST/Operations.nqp:
Sketch in some nqp:: ops for NFA handling.
p/rx-portability: ce1308b | jnthn++ | src/stage0/ (9 files):
Update bootstrap to get nqp::ops.
p/rx-portability: b027079 | jnthn++ | src/ (3 files):
Implement various NFA ops.
p/rx-portability: 5980aa5 | jnthn++ | src/QRegex/NFA.nqp:
Start using new NFA REPR and ops.

Avoids doing a lot of v-table calls while evaluating the NFA (can do a bit more improvement yet also). This should also help ease NFA porting, plus it's good to get this cleared up before porting things.
pmichaud allison: I found your summary of the situation to be particularly helpful, thanks for writing it.
allison pmichaud: thanks, it's something I've thought a lot about over the years 17:15
pmichaud I'm trying to figure out how I can be most helpful to the discussion, especially with respect to "what Rakudo would like from Parrot", but I haven't found the right "hooks" to be able to add my thoughts yet. 17:22
although reading yesterday's #parrot logs, it looks to me as though moritz++ has it about right :) 17:26
allison pmichaud: I think the biggest question so far with respect to Rakudo, is whether it has any interest at all in Parrot in any form. 17:29
pmichaud: If so, we get into the finer details of "what form?"
pmichaud Well, clearly we're not ready for Parrot to disappear entirely -- it's still the only platform on which we run. 17:30
allison pmichaud: But if not, it's quite simple, Parrot shouldn't target Rakudo if Rakudo isn't going to use it anyway.
pmichaud: Well, even if the project stopped tomorrow, the Parrot codebase would still be out there under the same license as Rakudo.
pmichaud right.
allison pmichaud: So, it's not "going away" in that sense.
pmichaud and that's always been my fallback if Parrot took a direction that Rakudo couldn't easily follow. 17:31
allison yes
pmichaud as far as whether we have any interest in Parrot in any form, there are forms in which we'd be interested, yes. Right now I think our main concern is the same one that has bugged us for a while -- namely, performance. 17:34
allison without profiling to find the performance bottlenecks, I can't say where they are for sure 17:36
but, I can say for sure that they exist
and, my experience suggests that they're probably about equally distributed over lines of code
i.e. in both the Parrot codebase and the Rakudo codebase
but, the only way to tackle it is head on
do the profiling 17:37
be heartless, cut the low performing code
rip, tear, drop, squash
it requires setting a goal for *what* should perform well
while Parrot has always stuck to a kind of least-common-denominator 17:38
pmichaud yeah, and profiling has been a big issue, because we don't have any Parrot devs that are willing to do look in depth at NQP or Rakudo code, and we don't have any Rakudo/NQP devs that want to dive deep enough into Parrot to instrument it
benabik would be willing if he had tuits. 17:39
allison pmichaud: it's back to the tragedy of the separation 17:40
pmichaud: it introduces a chasm between two parts of the Perl 6 implementation, and things that fall in the middle get lost
17:41 zby_home joined
pmichaud anyway, I think that gets around to answering your question then (more) 17:41
or, at least answering the larger question
if Parrot wants to remain relevant to Rakudo, or it wants to target Rakudo, there have to be some Parrot devs that are willing to dive into actually writing and running some Perl 6 code. Parrot hasn't had that for a couple of years. 17:42
and maybe longer
allison yes 17:43
(various historical reasons, but none really matter anymore)
pmichaud: on the Parrot side, I get the impression that there are people interested in Perl 6 17:46
that is, I've heard more people interested in refocusing on Rakudo than on any of the other alternate futures proposed
pmichaud allison: but is that interest "we want to write Perl 6 code" or "Rakudo's our primary customer and the only path for Parrot survival"?
wait, rephrasing 17:47
allison pmichaud: not quite either, but close, more "Perl 6 is the reason we got into Parrot in the first place"
pmichaud well, I know that many people got into Parrot because of language interop possibilities, more than Perl 6 17:48
17:49 uvtc joined
pmichaud I think many people acknowledge that Perl 6 is the reason for Parrot's existence, but I don't know how many current devs joined up primarily because of Perl 6 17:50
uvtc If Parrot is no longer really viable as a multi-language VM (due to lack of contributors/tuits/competition/whatever), and if Rakudo is still committed to running on multiple backends, and since Rakudo still relies on Parrot (since the JVM port is still a little ways away), what harm would there be in moving Parrot under Rakudo's aegis with an aim toward having it be "the Rakudo back-end that comes with Rakudo"?
pmichaud s/Parrot's existence/Parrot's initial existence/
uvtc As someone who's used Clojure a bit (another JVM lanugage), one common sentiment I see is folks who don't like Java and the JVM. Using a JVM language often means falling back on Java libs when your language doesn't have what you need.
Well, that complaint along with slow start-up time.
pmichaud uvtc: there's no harm, but I don't think there's much interest in doing that, as measured in committers 17:51
uvtc: it's not enough to say "Parrot moves under Rakudo" -- there have to be some people that are willing to make it happen as measured in code commits 17:52
allison uvtc: and the risk is totally dedicating Parrot to Rakudo, only to find that Rakudo preferrs JVM anyway 17:54
uvtc: then Parrot would have run down a path to no purpose
uvtc: and killed itself 17:55
pmichud: yes, I think you're right, that Parrot has attracted many people with very different goals over the years
pmichaud: the mailing list posts of "possible futures" certainly convince me of that
uvtc allison: right. I guess the question is, do the other alternatives run the same risk of killing the project. 17:56
allison pmichaud: each one is a completely different plan, motivated by a completely different set of goals
uvtc: the clearest alternative with a chance of success is to ditch Perl 6 entirely, and focus on being a light, fast VM 17:57
uvtc: it likely means picking one language to focus on 17:58
17:58 Reini joined
allison uvtc: there's every bit as much chance it won't succeed, but that chance doesn't depend on another project's future choices 17:58
uvtc: does that make sense?
uvtc: it's not a matter of guaranteed success anywhere 17:59
uvtc allison: you wrote "ditch Perl 6 entirely", then "picking one language to focus on". Do you mean that Parrot should pick one language to focus on that's not Perl 6? (Sorry if I'm misunderstanding you here.)
allison uvtc: yes, that's the alternate path
uvtc: probably a really popular language like Javascript 18:00
uvtc: I'm not saying I prefer that route :)
uvtc :)
allison uvtc: I'm just looking at it with a "businessman's eye"
uvtc: if this were a startup, what are it's chances for survival? 18:01
uvtc: the problem with the "multi-language" story, is it needs an interop lure
uvtc My understanding is that JS already has numerous and very fast VMs available. I'd say its chances for survival as a JS VM are very small.
allison The JVM interop story is Java. 18:02
the DLR interop story is .Net
Offering interop with... nothing, isn't compelling.
pmichaud In some sense, NQP's interop story is Perl 6, I think. 18:03
if I'm understanding allison correctly.
allison pmichaud: yes
though, commercially, interop with Perl 6 isn't highly sought after, yet 18:04
pmichaud correct, although that was true for Java too at one point (but in a different market)
allison also true for ALGOL
success is possible, but no guarantees 18:05
the only interop I can think would be compelling at this point is interop with Perl 5
which has, of course, been tried
Perl 5 is what people are actually using 18:06
really, millions of people
billions of lines of code
it's a real, viable project
hugely successful
pmichaud the vision that was articulated at the reunification summit was that Perl 5 and Perl 6 need to start evolving towards each other, especially in library design
allison yes, I'd agree 18:07
Perl 6's only path to success is a smooth transition for all the Perl 5 users
it has to actually be the next version of Perl 18:08
pmichaud and there was significant buy-in to that vision. Trying to get Perl 6 to run all existing Perl 5 code is the wrong vision, because there's a lot of Perl 5 code that Perl 5 doesn't even want to support
allison not just "inspired by" perl
moritz believes that Perl 6 has lots of potential in its own right, not just for attracting Perl 5 developers
pmichaud but if Perl 5 can migrate to something that Perl 6 can interop with more cleanly, then both languages have a good path forward with a long future
allison fair enough, though that's dangerously close to what Python 3 has done 18:09
and, it hasn't been successful
people are just refusing to take the porting steps necessary
and sticking with the old Python 2 code
pmichaud allison: well, we're not talking about porting as much as redesigning libraries altogether (more)
allison yes, people are refusing to write the libraries in Python 3 18:10
pmichaud we already see continued churn in CPAN and the Perl 5 world as new ideas (e.g., Moose) become a core part of the ecosystem
in an economic world, we'd call it "creative destruction", as older libraries are being replaced by new designs 18:11
so it's no so much that we need the new libraries written in Perl 6, but rather we need APIs and underlying models that are Perl 6-like in their conception
allison Yes
particularly, a real object model
(in Perl 5) 18:12
pmichaud right, which things like Moose and the p5mop projects have been investigating
allison and investigating quite well
but, they've kind of hit the limits of what they can do as mere "add ons" to Perl 5 18:13
uvtc Please excuse my ignorance here, but is there any reasonably possible path to follow where Parrot could provide an easy way for Perl 6 code to call Perl 5 libraries? B/c if there is, that would seem to be a pretty compelling direction for a slimmed-down Rakudo-dedicated Parrot.
allison Moose would hugely benefit from core support for it's class declaration syntax
uvtc: see Ponie, failure circa 2002ish 18:14
pmichaud moritz: I agree with you, Perl 6 has lots of potential in its own right, and someday it will hopefully be recognized as such. It needs a good real-world application.
uvtc: see also blizkost
uvtc allison: I don't mean a Perl 5 on Parrot. I mean a way to talk to /usr/bin/perl (Perl 5). 18:15
pmichaud uvtc: a way to talk to Perl 5 was also discussed at the reunification summit, based on some of the work mst has been doing with shipping objects over communication channels 18:16
allison uvtc: well, inter-process communication is easy enough, though not entirely satisfying
uvtc: like, if you think about it, tossing blobs of JSON around is pretty common practice 18:17
uvtc: but serialization and deserialization is pretty slow
uvtc: and there's no way to really speed it up
benabik You can do better than parsing/emitting JSON if you're doing everything locally, but there's still cost somewhere. 18:18
allison uvtc: which is a long-winded way of saying "yes, with challenges"
pmichaud I think it should also be said that it's worth trying or prototyping even if slow 18:19
allison yup
uvtc Well, makes it easy enough to talk to Perl 5 modules, while at the same time gently encouraging you to consider writing replacements in Perl 6. :)
pmichaud the fact that Perl 5 is shipping objects across the wire to Perl 5 on the other side means that there are applications for it
allison the devil is really in the API for communication, on both the Perl 5 side and the Perl 6 side 18:20
pmichaud right, and a good way to get to that API is to try a few things and see what works. see "evolution" and "creative destruction" :)
allison if they "feel like" you're just loading a Perl 5 object in Perl 6, it'll be more successful than if it requires a lot of ornate plumbing 18:21
people hate writing linking boilerplate
uvtc Anyhow, I suspect that the combination of "slimmed-down Rakudo-focused" *plus* "good-enough interop with Perl 5" might be Parrot's sweet spot for the future. But that's just how it looks from my armchair over here. :) 18:22
allison uvtc: I will say, the JVM is unlikely to ever offer a really good story for interop with Perl 5 18:23
uvtc: so it'll either be in Rakudo/NQP, or in Parrot that it has to happen
pmichaud right
and part of NQP's story is that we hope to be a path by which some form of Perl 5 can start to appear on the JVM
cotto time for some serious backscrolling 18:28
allison pmichaud: So, is there anything Parrot could provide to Rakudo that would give it an edge over JVM? From your perspective?
pmichaud speed and interop with C libraries are the two that come to mind to me 18:29
I don't know that speed will be achievable without some major internals rework
allison agreed 18:30
pmichaud Parrot's NCI isn't really the interface we want; indeed, it's a bit of a sore point since Parrot's self-started NCI changes in 2011 broke so many things we were depending on. NQP has built its own NCI interface instead.
allison I believe it's achievable with some major internals rework, especially since speed used to be one of Parrot's killer features. 18:31
pmichaud: doesn't that mean you're doing your own C interop now?
pmichaud allison: essentially, yes. I think we what we have is still a little primitive, though, although it's getting much less primitive rather quickly. 18:32
uvtc (interop with C libraries)++. When using JVM languages, there tends to be constant pressure to use Java-alternatives to your favorite C libs.
allison pmichaud: The reason I ask, is that what I'm hearing from Rakudo so far is "We've got that covered ourselves" on everything that Parrot might offer.
pmichaud: I'm not even clear what Rakudo is using Parrot for now. 18:33
pmichaud: sounds like not much, which could make for a very light and fast Parrot :)
pmichaud: though, not exactly feature-rich 18:34
pmichaud: GC? does Rakudo still use Parrot's GC?
moritz yes, it does 18:35
allison i.e. basic memory allocation for objects
as well as cleanup
moritz it also uses parrot's exception handling
IO
allison dispatch only in the most primitive of senses, and Rakudo wishes it could short-circuit more
does Rakudo manage its own call stack? 18:36
moritz I don't think so
pmichaud I think we still use Parrot contexts, yes
allison how about C-level PMCs? 18:37
pmichaud not so much anymore, except where they're needed for IO
allison I know Rakudo has it's own object hierarchy
basic strings, ints, and floats?
moritz yes, we use them 18:38
we also use parrot's lexicals
pmichaud we use strings ints and floats in registers, but I don't think we make much use of String, Integer, and Float PMCs
allison basic code objects, then
pmichaud: yeah, I would expect the registers to be more useful than the PMCs there 18:39
moritz pmichaud: I think there are a few sparse cases where we use (at least some of) those PMCs, because some functionality isn't available as ops
but that's stuff that could easily be changed, given the right ops
allison ah, yes, how about Parrot's massive body of ops?
how much of that does Rakudo use?
pmichaud We don't use many parrot ops. I can give you a basic count in a second... :-)
allison stripping away a pile of useless ops would be a quick optimization :) 18:40
cotto This sounds like a plan for things that could be removed from Parrot as step 1 of refocusing on Rakudo.
moritz github.com/perl6/nqp/blob/master/s...mpiler.nqp lists nearly all the parrot ops we use
pmichaud cotto: yes, but there's a big "but"
cotto pmichaud: I'm sure there's more than one.
pmichaud github.com/perl6/nqp/blob/master/d...opcode.txt # a more readable list 18:41
moritz no, wrong link, wait a sec
pmichaud: I'm not sure how up-to-date that is
pmichaud cotto: on parrot-dev, someone mentioned "pct, tge, pge, nqp-rx, winxed, libffi" as being Parrot baggage that is unnecessary to Rakudo 18:42
cotto Looking at coverage isn't a hard problem.
pmichaud: yes, to the extent that they're not necessary to build Parrot itself.
pmichaud I agree that it's unnecessary baggage to Rakudo, but the items mentioned also aren't impediments to Rakudo either
i.e., they don't impact Rakudo's performance significantly 18:43
so eliminating them doesn't really improve the situation for Rakudo, except to the extent that eliminating them frees Parrot to focus on things that would help Rakudo
allison pmichaud: memory and execution speed aren't the only limited resources
pmichaud: maintenance and development focus is relevant too 18:44
pmichaud allison: yes, see what I just wrote :)
allison pmicaud: aye, thinking alike :)
pmichaud I think I'm reacting to something a bit specific here (more)
allison and, it's likely that cutting support for all those extras would also make it easier to trim the parrot core 18:45
as in, each of those bits depends on different Parrot features than Rakudo does
pmichaud from a Rakudo perspective, over the past several years there's been a tendency to say "let's make Parrot better for Rakudo" which starts with "okay, we need to clean up XYZ and then we'll be able to make improvements" (more)
so then there's a lot of effort put into "clean up XYZ", which gets done, and everyone congratulates themselves on completing a very difficult task (more) 18:46
allison and then get bogged down in the implications of the cleanup for all the many other uses of Parrot
yeah
pmichaud ...and we never get to the second part, which is "we'll be able to make improvements"
cotto What I'm hoping for with a reduced focus is that when Parrot developers are looking at a profile and notice something slow, the only factors to consider are if it breaks Parrot and if it breaks Rakudo.
This gets rid of the idea that there might be some other language that'd want feature x, so we have to keep it. 18:47
still hard work, but less constrained
pmichaud If that's actually been a bottleneck for Parrot development in recent times, then yes, it'd be a help to move things forward. 18:48
My perception has been that this isn't the bottleneck or limiting factor.
allison the biggest limiting factor is that it's a big scary codebase
which is related, but not exactly the same 18:49
cotto That's a relevant factor.
allison and also helped substantially by ripping out a bunch of stuff 18:51
I have to say, I'm tempted, I really am. 18:55
That's the only alternate I'm tempted by.
cotto Even if it's only ripping out something relatively symbolic like tge at first, I still really like the idea. It's a strong signal that Parrot is heading in a different direction. 18:57
allison: thanks for the historical background.
allison cotto: anytime :) 18:58
uvtc Maybe this is a crazy question, but would it make sense to create a fork of parrot under the github.com/perl6 org? That way, whomever has a perl6 commit bit would also be able to commit changes to parrot as well. Also it would send a strong signal re. what the new goals are. 18:59
s/are/would be/ 19:00
pmichaud I think it might be easier and cleaner to simply open up commitbit policy on github.com/parrot/parrot, if that's a blocker.
allison pmicaud: AFAICT, commitbits aren't really a blocker, tuits are 19:01
cotto That's my view also.
pmichaud same here. 19:02
cotto Though I'm not sure what the implications for the CLA requirement would be should the projects eventually reach the point where both sides are comfortable merging. 19:03
again, big if
allison what are the requirements on the Rakudo side now?
does Rakudo still use Perl CLA?
(because if that's a blocker, it's easy enough to adopt something like the Linux Kernel certificate of origin) 19:04
(which requires no signing)
Legal infrastructure should always serve the project, not the project serve the legal infrastructure :) 19:06
cotto: and, my sense is that we're not talking about Rakudo and Parrot "merging" 19:07
moritz fwiw removing tge isn't trivial. nci_thung_gen.pir depends on data_json, which in turn depends on TGE
allison cotto: more about Parrot joining TPF, with the express purpose of collaborating with Rakudo
cotto I don't necessarily mean merge in the git sense, more what you just said. 19:08
allison cotto: at least, that's the sense I get from Rakudo folks
cotto: yeah
moritz: replace it with an NQP-based JSON parser?
moritz: bootstrapping required, but that doesn't seem to be scary to Rakudo folks 19:09
19:09 Mike-PerlRecruiter_ joined
moritz sure, doable, just not trivial 19:10
allison yup
arnsholt allison: (from scrollback) If you want more info on the NQP FFI subsystem, I can fill you in. The basic design is jnthn's, but I've been the one working on it for about a year now 19:11
allison arnsholt: at the moment I was largely looking for the broad brushstrokes of whether NQP needs Parrot for C interop anymore 19:12
arnsholt: though, that would be an interesting chat to have at some point :) 19:13
arnsholt Sounds like a plan. I'll be around =)
19:15 not_gerd joined
not_gerd ~~ 19:15
also keep in mind that it's possible to rip out subsystems and check in the generated files instead until replacements are ready 19:21
as far as I can tell, nqp-rx is mainly necessary because of ops2c and HLL.pbc (which gets generated from a stage0 PIR file anyway)
cotto For JSON, we can easily port JSON::PP. 19:22
not_gerd check in the NQP-generated PIR files for ops2c and nqp-rx can go the way of the dodo
moritz note that this requires all of 6model 19:23
allison moritz: replacing Parrot objects with 6model is a viable negotiation
moritz sure
allison moritz: though it may also be Parrot just provides no object model at all
moritz I just want to illustratet that stuff is more tightly coupled than it might seem at first glance 19:24
allison (not that the strategy has worked well for Perl 5...)
moritz: it is, but how much of that tight coupling does Rakudo/NQP depend on?
moritz: like, for example, ops2c gets a lot simpler if the only ops needed are the few NQP uses 19:25
pmichaud note that one could check in the PIR code for ops2c and still eliminate nqp-rx, I think. 19:27
not_gerd pmichaud: that's what I was getting at - NQP should have read NQP-rx 19:28
cotto I'd like to see Parrot's uses of nqp-rx migrated to nqp.
not_gerd cotto: there might be bootstrapping issues 19:29
not unsolvable, but someone needs to take a closer look
cotto not_gerd: yes. That was the first issue I ran into when looking at it.
pmichaud I have to run for a while -- bbl 19:30
cotto doable, but not without thought
I've had lunch sitting next to me for the last 10 minutes getting cold, so ditto.
19:47 Eddward joined 19:50 bouncy joined 20:18 brrt joined
brrt hi all 20:23
whats the deal with closing off parrot?
i'm unhappy about it\\ 20:27
not_gerd apparently, PaFo will close its doors 20:28
the future of Parrot itself is yet to be decided
cotto brrt: not so much closing as refining its focus 20:29
in my head, at least
brrt well, what focus are we talking about, then? 20:32
cotto changing focus from hosting all dynamic languages to supporting Rakudo exclusively 20:33
brrt hmmm 20:37
but, radical suggestion, wouldn't supporting rakudo pretty much mean that you could support any other language as well?
cotto It needs a lot of hmmming.
brrt it does
but perl6 is much of a superset of other languages
cotto yes, but incidentally
brrt other suggestion: why does rakudo need a vm at all
why couldn't we / they just compile nqp to x86 / arm / whatever 20:38
basically, if parrot becomes 'the thing to run rakudo on', well, the limits are off
cotto s/the/a/, given recent nqp/jvm work 20:39
brrt well, yes, sure\\
if nqp/jvm takes off (which i expect it will, it is a better fit than i had imagined) will parrot still make sense? 20:40
20:40 contingencyplan joined
cotto nqp/jvm is showing initial promising signs, but that's not necessarily an indicator of how the end result will look. 20:41
brrt that is true 20:42
is anything still happening on the m0 front?
basically, why is the perl community disintegrating?
cotto wrt Parrot in an nqp/jvm world, I can't say for sure.
I don't think that much will be happening with M0 in the immediate future. 20:43
My personal goal is to trim down Parrot to what's useful for Rakudo rather than rebuild. 20:44
allison brtt: the idea that supporting Perl 6 features "implicitly" supports all other languages is true in one sense
brrt: but there's a big difference between "implicit support" and actual implementation work 20:45
cotto allison: exactly
allison brrt: and when the rubber hits the road, Parrot's lack of focus has contributed to implementation efforts flying all over the map
cotto The idea is to get one language into a production-ready state, then possibly look at branching out.
allison brrt: instead of delivering a usable product
brrt well, lack of focus is a general thing now, isn't it? 20:46
but yeah
actually, looking at the parrot source code it isn't at all the horror it is made out to be
allison brrt: the team has been pretty good at sticking to coding style guidelines and passing tests, which buys a lot 20:47
brrt: even when working on a very complex problem
brrt yeah, so why the panic attack all of the sudden? 20:48
allison brrt: it was started by the discussions over closing the Parrot Foundation
(which will be happening, no matter what the Parrot project does) 20:49
not_gerd brrt: because whiteknight and rurban have moved on, PaFo is closing shop and Rakudo gets a JVM backend
allison brrt: which lead to "okay then, what's happening in the Parrot project?"
not_gerd: close, I mean PaFo has been talking about closing for months now
not_gerd: and we all just assumed "of course, Parrot development will continue, we just need to find it a new home" 20:50
brrt hmm
fair enough
allison not_gerd: it was only Friday that I thought to ask "will Parrot development actually continue?" 20:51
brrt: and so far, no one has actually said "I'll do it"
brrt hmm
who could do it?
whiteknight++ gave it a long run
but at the end 20:52
allison brrt: though there are currently 4 people on the mailing list who have said "it should be done this way"
er, 3?
I lost count
brrt it seems everybody who would've done it has done it alone
allison brrt: in recent years, yes
cotto I've been trying to figure out a plan that I can get one or two others to buy into.
moritz and one who wants cross-platform GUI stuff on parrot :-)
brrt moritz, that one was hilarious
cotto That one came out of left field.
allison moritz: he's not far off, it's just that HTML5 is a simple text output, and not part of the VM 20:53
moritz: I at least give him credit-due for thinking about practical use cases
moritz: instead of just compiler theory
brrt yes, well, vms are always somewhat removed from practical use cases, aren't they? 20:54
allison brrt: sort of, yes
brrt: at least it's very easy to fall into the trap of making the "framework" king
brrt: but, a VM isn't much use if it isn't actually used for something 20:55
brrt: it's just... hot air
cotto: and, yes, a plan that can rally the interest of multiple people is the key 20:56
cotto allison: yeah. I'd be doing that now if I didn't have some $dayjob hours to make up.
allison cotto: me too :)
cotto I hoping for some time tonight. I had a nice email all drafted, then 50 other replies happened. 20:57
allison heh :)
cotto *I'm
allison and another long IRC thread
brrt :-)
well
i'm following any and all discussions
allison cotto: I'm toying with the idea of dropping an astrophysics class this year to dive into "one more go" on Parrot for Rakudo/Perl 6 20:58
cotto allison: that sounds like a hard choice
allison cotto: I haven't *quite* convinced myself that we have enough of a plan to go on 20:59
cotto there's so much awesomeness in astrophysics
Just tell me that it wouldn't be taught by Neil deGrasse Tyson.
allison cotto: but the pieces I find most compelling are refocus on Rakudo performance, rip out everything else, and add Perl 5 compatibility (by a more reasonable path that was previously tried) 21:00
*than
nah, just ordinary profs
but, it is getting into general relativity, so beyond the basics of stars and planets 21:01
definitely interesting
uvtc Astrophysics is fun intellectual stimulation, but not very practical.
cotto uvtc: the tiny black hole sitting on my desk says otherwise.
;)
allison uvtc: depends on your goal
uvtc: in some ways it's *very* practical, it's totally focused on physical matter and the interactions between real world objects 21:02
uvtc: I find that grounding in reality refreshing
not_gerd one of my profs got a patent on energy generation via miniture black holes as a practical joke
allison uvtc: especially after years in CS where people will argue to their dying day that their theory is "right" with no proof
uvtc In the past I've spent lots of time solving physics problems. And it's certainly very personally rewarding, and refreshing. 21:03
allison uvtc: and no real world way to ever get proof
not_gerd: sounds like a fun professor :)
uvtc: I think CS folks could do with an upset as radical as realizing the earth isn't flat 21:04
uvtc: and the sun doesn't orbit the earth
uvtc: they're far too complacent 21:05
cotto And that coding standards and separation of concerns are too much of a "real-world" concern.
uvtc allison: Is that what drew you to Perl 6 in the first place? A language usable, yet modifiable enough to do radical apple-cart-toppling stuff with? :) 21:06
allison cotto: yeah, the dismiss the only possible chances of reality shaking up their constructed fiction
*they
not_gerd well, there's the video by the Forth guy (Moore?) that tells you you shouldn't use libraries and that a stack depth of 18 should be enough for everyone
allison uvtc: sort of the other way around 21:07
uvtc: I got into Perl 6 quite early on
uvtc: mainly on the basis of my background in linguistics
uvtc: i.e. "how can we make a language that more closely maps to the human brain" 21:08
(a computer language, that is)
uvtc: it was only as I got deeper and deeper into "and how do we make that language actually work?" that I hit the wall of prejudice and stupidity in CS :) 21:09
21:09 bouncy joined
allison uvtc: and then was lured out of it by quantum computing 21:11
uvtc: and from there into quantum mechanics 21:12
uvtc: and from there into astrophysics
uvtc astrophysics is certainly very alluring.
allison uvtc: I still have this idea of "tilting windmills" with CS by using quantum wave functions to write "proofs" for dynamic languages 21:13
uvtc: we'll see if I get to it
uvtc: on the whole, I think I find quantum mechanics more interesting than astrophysics 21:14
uvtc: but both are interesting
uvtc allison: It sounds like you're interested in playing the long game wrt Perl 6. And that you're not particularly crazy about the idea of the JVM becoming the dominant Perl 6 backend...
allison uvtc: There's a bit of personal motivation in there. 21:15
uvtc: I'm still a Perl developer. I (partly) make money writing Perl code.
uvtc: I don't want to find myself working on the JVM in 3 years. Or even 10 years. 21:16
uvtc: That's not to say I'm against having a Perl 6 implementation on the JVM.
uvtc: That's totally cool, and if someone wants to write it, they have my hearty support. From a distance. 21:17
uvtc: I just don't want to use i.
*it
uvtc Well, if there's a time to dive back into Parrot and give the JVM a run for its money, seems like now's probably the time. :)
allison uvtc: exactly. Astrophysics isn't going anywhere. It'll be pretty much the same next year as it is this year. 21:18
uvtc: Parrot might not be.
uvtc allison: was just about to type that. :)
" I don't want to find myself working on the JVM in 3 years. Or even 10 years." <--- I'd be willing to bet that a lot of Perlers share that sentiment. 21:19
allison uvtc: Yeah, I imagine so.
uvtc: It's a target audience thing. 21:20
brrt i have my doubts about jvm as well
allison, what do you mean by target audience? 21:21
allison uvtc: Someone (I don't recall who) made the point that there are a lot of Java libraries out there that people might use.
uvtc: But, the question is, who?
and how many of them?
I don't think Perl 5 developers are suddenly going to start looking for Java libraries they can use.
brrt do perl6 people know java languages
s/languages/libraries/ 21:22
what does 'we can haz lotsa libraries' even mean
allison And, I don't think even a tiny fraction of Java developers are going to start using Perl 6 to use their existing Java libraries.
So, it's a tiny cross-section of two very large communities.
Not compelling, business-wise.
(Back to "if this was a startup...") 21:23
brrt java developers are jumping to scala, however
allison brrt: sure, but scala is totally focused on Java features
brrt: is Perl 6 going to take that step?
brrt :if it does, I'd make a pretty safe bet that Perl 5 users won't like it 21:24
brrt blegh, i don't know
perl6 is pretty OO though, ahnd has functional stuff
allison brrt: without much certainty that Java users will like it
uvtc allison: I think that was me. The point is, if you're using a language impl on the jvm, and you need a lib that your language doesn't provide, you're faced with: "do I write it myself or go looking for a Java alternative?"
brrt why isn't there a 'simplest p6 that could possibly work'
uvtc I don't get the impression that Perlers are going to be terribly excited by that prospect. 21:25
allison brrt: I'd guess "just because it hasn't been done yet". Simplification is often more work than the original idea.
uvtc: Perlers won't be excited by looking for Java libraries instead of writing it themselves? 21:26
uvtc: It certainly does seem to be the Perl way to "write it myself".
uvtc allison: I think it's going to be percieved as a "rock and a hard place" situation.
allison uvtc: It's the essence of TMTOWTDI. 21:27
brrt is off for sleeping
good discussion, thanks people
good to see people still /care/
allison thanks for the thoughts, brrt 21:28
cotto 'night brrt
brrt :-) 'night all
not_gerd anyone wants to make a pretty picture from that: gist.github.com/gerdr/4751112
cotto not_gerd: graphviz is surprisingly easy to use 21:29
I don't mean that to blow you off, just that I'm trying to focus on other things now so I can focus on Parrot things later tonight. 21:31
allison not_gerd: that's a very long list :( 21:32
not_gerd: aiming to cut it in half could be a good first goal 21:33
21:37 Reini joined
uvtc allison: I agree that Perlers often do like to "write it myself", but my thought is that --- when your lang impl is on the JVM --- there's continuous gentle pressure to "just use the existing Java lib for that" (maybe self-imposed, maybe even by your employer). And then you find yourself in the javadocs and using interop all the time, and even maybe dropping down to Java for performance. Seems to me like Perl and Java are like oil and water, an 21:45
d that this might not be a long-term recipe for success.
allison uvtc: yes, I lean in that direction too 21:48
Eddward From the peanut gallery, I've like perl because you can learn it in bit-n-pieces. I think the term was you can learn it "incrementally." 21:51
My experience with java is that learning to use one library well requires to you to learn a few others or at least some new idioms too. 21:52
There mihgt be a cook book example, but then you don't know what you've done or how to fix it if the recipe wasn't exactly right for you. 21:53
I hope perl doesn't go that way. perl6 still looks like the language I want to use. 21:54
allison Eddward: That's a good point, and does fit my experience working in Java. 21:55
Eddward: (Both "old" Java and "Android" Java.)
Eddward allison: I haven't had any experience with andriod. I'm glad that people who like java have it, but I find I don't think that way. 21:56
I spend too much time fighting with IDEs that are needed to make up for language-isms.
not_gerd is tempted to rewrite ops2c in Perl6 and bootstrap by checking in generated files 21:57
allison not_gerd: Perl6 or NQP?
not_gerd: Neither is a problem in the "focus on Rakudo" scenario, just curious. 21:58
not_gerd allison: full-blown Perl6
allison not_gerd: and if there are only 20 ops in Parrot, do they even need to be generated?
not_gerd allison: that... might be worth considering 21:59
allison not_gerd: or would it be better to just fork off the *current* generated C files, and start maintaining them as straight C code 22:00
cotto 20? This is sounding like m0.
allison cotto: probably a different 20 than m0
cotto: i.e. instead of redesigning the 20, just go with what NQP actually uses
cotto: and leave those in place, working as is
cotto: and ditch the rest
cotto allison: nqp uses way more than 20
even if you're just counting the core parrot ops 22:01
allison cotto: it was a short list, fewer than 100 certainly
github.com/perl6/nqp/blob/master/d...opcode.txt
was what someone gave me
cotto allison: that sounds more plausible. Once some has taken the time to produce and validate a list, it makes sense to ask if opsc is still needed. 22:02
20 is easy enough to maintain by hand. 100, maybe.
uvtc focus on Rakudo + slimming down + "good-enough" Perl 5 interop + interop with C libs = "the great molting of 2013" ? :) 22:04
cotto Both of those needs a whole lot of planning. 22:06
22:08 Reini joined
not_gerd wishes everyone a good night and looks for a snack before heading off to bed 22:12
22:12 not_gerd left
allison cotto: and a whole lot of work 22:16
must run, my son is in a piano concert this afternoon
uvtc o/ 22:17
cotto allison: yes
22:30 MikeFair joined 22:43 Reini joined
dalek p/rx-portability: 5ecc011 | jnthn++ | src/ (3 files):
Add nqp::const mechanism.

Allows mapping constants in a backend-independent way.		 23:00
p/rx-portability: b7756b5 | jnthn++ | src/stage0/ (9 files):
Update bootstrap.
p/rx-portability: 081a30f | jnthn++ | src/QRegex/ (2 files):
Lots of pir:: => nqp:: in NFA and Cursor.
23:07 pjcj joined 23:11 alester joined 23:14 Reini joined 23:44 Reini joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!