Camelia, the Perl 6 bug

IRC log for #parrot, 2013-02-10

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:19 Reini joined #parrot
00:50 PacoAir joined #parrot
01:24 PacoAir left #parrot
01:27 PacoAir joined #parrot
02:17 kid51 joined #parrot
03:12 kid51_ joined #parrot
04:43 Reini joined #parrot
06:08 Reini joined #parrot
06:28 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?
07:09 Mike-PerlRecruiter_ joined #parrot
08:28 bluescreen_ joined #parrot
09:43 Psyche^ joined #parrot
11:51 dalek nqp: 6b358a3 | jnthn++ | src/core/NQPRoutine.pm:
11:51 dalek nqp: Toss now-unrequired clone callback legacy code.
11:51 dalek nqp: review: https://github.com/perl6/nqp/commit/6b358a3dcc
11:51 dalek nqp: f92cd68 | jnthn++ | src/QAST/Operations.nqp:
11:51 dalek nqp: Add an nqp::escape that maps to pir::escape.
11:51 dalek nqp: review: https://github.com/perl6/nqp/commit/f92cd68130
11:51 dalek nqp: 3f27005 | jnthn++ | src/stage0/ (9 files):
11:51 dalek nqp: Update bootstrap.
11:51 dalek nqp: review: https://github.com/perl6/nqp/commit/3f27005e4c
11:51 dalek nqp: 26d0d0f | jnthn++ | src/QAST/ (2 files):
11:51 dalek nqp: Get QASTNodes free of pir::.
11:51 dalek nqp: review: https://github.com/perl6/nqp/commit/26d0d0f9b7
12:21 mj41 joined #parrot
12:40 xcombelle joined #parrot
13:09 kid51 joined #parrot
14:10 bouncy joined #parrot
14:11 PacoAir joined #parrot
14:14 PacoAir joined #parrot
14:23 Psyche^ joined #parrot
15:22 benabik joined #parrot
15:38 xcombelle joined #parrot
15:46 Reini joined #parrot
16:38 allison cotto: ititially, it was just a "bonus"
16:39 allison 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 allison cotto: but it grew over time, especially as Dan became disilusioned with Perl 6 design
16:40 allison cotto: the more Dan hated Perl 6, the more focus he put on supporting multiple languages
16:40 allison cotto: see, the whole tension between Perl 6 and Parrot didn't start with Rakudo
16:40 allison cotto: it went all the way back to the root
16:41 allison At the time, I thought Dan was a bit daft. (I was on the Perl 6 design team at the time.)
16:42 allison Sort of like "here, we've got this lovely design for you, don't you want to implement it?"
16:42 allison But, when I became architect, oddly, I found myself following in his footsteps.
16:43 allison 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 allison Truly weird things.
16:44 allison I see this as a fundamental flaw in Perl 6 as a whole.
16:44 allison Not the features, they're weird, but features are always changable.
16:45 allison The flaw is the separation between design and implementation.
16:45 allison Perl 1 was all Larry, design and implementation.
16:46 allison 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:47 allison 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 allison Perl 6 slipped the bonds of gravity. It was never required to be practical.
16:48 allison 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:53 allison Curiously, the whole "multi-language" thing is what scared Java and Microsoft the most.
16:54 allison That's what made them see Parrot as serious competition, because they couldn't support the lanaguages Parrot was targeting.
16:54 allison So, they threw money at the problem, hired a bunch of developers to work on it.
16:54 allison And both of them more-or-less solved the problem.
16:55 allison The JVM and DLR can support dynamic languages well enough now.
16:55 allison Not as well as Parrot might be able to provide someday, but better than anything Parrot has actually provided so far.
16:56 allison We were so convincing, that we changed the world. :)
17:01 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
17:01 allison and in the process, wiped out it's competitive advantage
17:02 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 :)
17:02 allison Tweaking Microsoft and Sun is something I'll remember fondly :)
17:03 davidfetter re: sun, /requiescat in pace/
17:04 allison at the rate they're going Microsoft won't be far behind
17:05 allison seems like Oracle has the greatest motivation to pick them up too :)
17:09 pmichaud good morning, #parrot
17:10 allison good morning, pmichaud
17:10 benabik o/ pmichaud
17:11 pmichaud very interesting discussion on parrot-dev.  :-)
17:12 allison indeed
17:13 dalek nqp/rx-portability: f5d0a8b | jnthn++ | / (5 files):
17:13 dalek nqp/rx-portability: Stub in an NFA representation.
17:13 dalek nqp/rx-portability:
17:13 dalek nqp/rx-portability: We'll keep it in the current form for construction; this is what we'll
17:13 dalek nqp/rx-portability: feed to the executor and also serialize them as.
17:13 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/f5d0a8bb2c
17:13 dalek nqp/rx-portability: ecc5234 | jnthn++ | src/QAST/Operations.nqp:
17:13 dalek nqp/rx-portability: Sketch in some nqp:: ops for NFA handling.
17:13 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/ecc523421f
17:13 dalek nqp/rx-portability: ce1308b | jnthn++ | src/stage0/ (9 files):
17:13 dalek nqp/rx-portability: Update bootstrap to get nqp::ops.
17:13 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/ce1308b279
17:13 dalek nqp/rx-portability: b027079 | jnthn++ | src/ (3 files):
17:14 dalek nqp/rx-portability: Implement various NFA ops.
17:14 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/b0270790c4
17:14 dalek nqp/rx-portability: 5980aa5 | jnthn++ | src/QRegex/NFA.nqp:
17:14 dalek nqp/rx-portability: Start using new NFA REPR and ops.
17:14 dalek nqp/rx-portability:
17:14 dalek nqp/rx-portability: Avoids doing a lot of v-table calls while evaluating the NFA (can do a
17:14 dalek nqp/rx-portability: bit more improvement yet also). This should also help ease NFA porting,
17:14 dalek nqp/rx-portability: plus it's good to get this cleared up before porting things.
17:14 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/5980aa50aa
17:14 pmichaud allison: I found your summary of the situation to be particularly helpful, thanks for writing it.
17:15 allison pmichaud: thanks, it's something I've thought a lot about over the years
17:22 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:26 pmichaud although reading yesterday's #parrot logs, it looks to me as though moritz++ has it about right :)
17:29 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 allison pmichaud: If so, we get into the finer details of "what form?"
17:30 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.
17:30 allison pmichaud: Well, even if the project stopped tomorrow, the Parrot codebase would still be out there under the same license as Rakudo.
17:30 pmichaud right.
17:30 allison pmichaud: So, it's not "going away" in that sense.
17:31 pmichaud and that's always been my fallback if Parrot took a direction that Rakudo couldn't easily follow.
17:31 allison yes
17:34 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:36 allison without profiling to find the performance bottlenecks, I can't say where they are for sure
17:36 allison but, I can say for sure that they exist
17:36 allison and, my experience suggests that they're probably about equally distributed over lines of code
17:36 allison i.e. in both the Parrot codebase and the Rakudo codebase
17:36 allison but, the only way to tackle it is head on
17:37 allison do the profiling
17:37 allison be heartless, cut the low performing code
17:37 allison rip, tear, drop, squash
17:37 allison it requires setting a goal for *what* should perform well
17:38 allison 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
17:39 * benabik would be willing if he had tuits.
17:40 allison pmichaud: it's back to the tragedy of the separation
17:40 allison 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 #parrot
17:41 pmichaud anyway, I think that gets around to answering your question then (more)
17:41 pmichaud or, at least answering the larger question
17:42 pmichaud 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 pmichaud and maybe longer
17:43 allison yes
17:43 allison (various historical reasons, but none really matter anymore)
17:46 allison pmichaud: on the Parrot side, I get the impression that there are people interested in Perl 6
17:46 allison that is, I've heard more people interested in refocusing on Rakudo than on any of the other alternate futures proposed
17:46 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"?
17:47 pmichaud 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"
17:48 pmichaud well, I know that many people got into Parrot because of language interop possibilities, more than Perl 6
17:49 uvtc joined #parrot
17:50 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"?
17:50 pmichaud s/Parrot's existence/Parrot's initial existence/
17:50 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.
17:50 uvtc Well, that complaint along with slow start-up time.
17:51 pmichaud uvtc: there's no harm, but I don't think there's much interest in doing that, as measured in committers
17:52 pmichaud 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:54 allison uvtc: and the risk is totally dedicating Parrot to Rakudo, only to find that Rakudo preferrs JVM anyway
17:54 allison uvtc: then Parrot would have run down a path to no purpose
17:55 allison uvtc: and killed itself
17:55 allison pmichud: yes, I think you're right, that Parrot has attracted many people with very different goals over the years
17:55 allison pmichaud: the mailing list posts of "possible futures" certainly convince me of that
17:56 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
17:57 allison uvtc: the clearest alternative with a chance of success is to ditch Perl 6 entirely, and focus on being a light, fast VM
17:58 allison uvtc: it likely means picking one language to focus on
17:58 Reini joined #parrot
17:58 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 allison uvtc: does that make sense?
17:59 allison 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.)
17:59 allison uvtc: yes, that's the alternate path
18:00 allison uvtc: probably a really popular language like Javascript
18:00 allison uvtc: I'm not saying I prefer that route :)
18:00 uvtc :)
18:00 allison uvtc: I'm just looking at it with a "businessman's eye"
18:01 allison uvtc: if this were a startup, what are it's chances for survival?
18:01 allison uvtc: the problem with the "multi-language" story, is it needs an interop lure
18:01 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.
18:02 allison The JVM interop story is Java.
18:02 allison the DLR interop story is .Net
18:02 allison Offering interop with... nothing, isn't compelling.
18:03 pmichaud In some sense, NQP's interop story is Perl 6, I think.
18:03 pmichaud if I'm understanding allison correctly.
18:03 allison pmichaud: yes
18:04 allison 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)
18:04 allison also true for ALGOL
18:05 allison success is possible, but no guarantees
18:05 allison the only interop I can think would be compelling at this point is interop with Perl 5
18:05 allison which has, of course, been tried
18:06 allison Perl 5 is what people are actually using
18:06 allison really, millions of people
18:06 allison billions of lines of code
18:06 allison it's a real, viable project
18:06 allison hugely successful
18:06 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
18:07 allison yes, I'd agree
18:07 allison Perl 6's only path to success is a smooth transition for all the Perl 5 users
18:08 allison 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
18:08 allison not just "inspired by" perl
18:08 * moritz believes that Perl 6 has lots of potential in its own right, not just for attracting Perl 5 developers
18:08 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
18:09 allison fair enough, though that's dangerously close to what Python 3 has done
18:09 allison and, it hasn't been successful
18:09 allison people are just refusing to take the porting steps necessary
18:09 allison and sticking with the old Python 2 code
18:09 pmichaud allison: well, we're not talking about porting as much as redesigning libraries altogether (more)
18:10 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
18:11 pmichaud in an economic world, we'd call it "creative destruction", as older libraries are being replaced by new designs
18:11 pmichaud 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
18:11 allison Yes
18:11 allison particularly, a real object model
18:12 allison (in Perl 5)
18:12 pmichaud right, which things like Moose and the p5mop projects have been investigating
18:12 allison and investigating quite well
18:13 allison 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.
18:13 allison Moose would hugely benefit from core support for it's class declaration syntax
18:14 allison 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.
18:14 pmichaud uvtc:  see also blizkost
18:15 uvtc allison: I don't mean a Perl 5 on Parrot. I mean a way to talk to /usr/bin/perl (Perl 5).
18:16 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
18:17 allison uvtc: like, if you think about it, tossing blobs of JSON around is pretty common practice
18:17 allison uvtc: but serialization and deserialization is pretty slow
18:17 allison uvtc: and there's no way to really speed it up
18:18 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"
18:19 pmichaud I think it should also be said that it's worth trying or prototyping even if slow
18:19 allison yup
18:19 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. :)
18:19 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
18:20 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"  :)
18:21 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 allison people hate writing linking boilerplate
18:22 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:23 allison uvtc: I will say, the JVM is unlikely to ever offer a really good story for interop with Perl 5
18:23 allison uvtc: so it'll either be in Rakudo/NQP, or in Parrot that it has to happen
18:23 pmichaud right
18:23 pmichaud 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
18:28 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?
18:29 pmichaud speed and interop with C libraries are the two that come to mind to me
18:29 pmichaud I don't know that speed will be achievable without some major internals rework
18:30 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.
18:31 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 allison pmichaud: doesn't that mean you're doing your own C interop now?
18:32 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.
18:32 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.
18:33 allison pmichaud: I'm not even clear what Rakudo is using Parrot for now.
18:33 allison pmichaud: sounds like not much, which could make for a very light and fast Parrot  :)
18:34 allison pmichaud: though, not exactly feature-rich
18:34 allison pmichaud: GC? does Rakudo still use Parrot's GC?
18:35 moritz yes, it does
18:35 allison i.e. basic memory allocation for objects
18:35 allison as well as cleanup
18:35 moritz it also uses parrot's exception handling
18:35 moritz IO
18:35 allison dispatch only in the most primitive of senses, and Rakudo wishes it could short-circuit more
18:36 allison does Rakudo manage its own call stack?
18:36 moritz I don't think so
18:36 pmichaud I think we still use Parrot contexts, yes
18:37 allison how about C-level PMCs?
18:37 pmichaud not so much anymore, except where they're needed for IO
18:37 allison I know Rakudo has it's own object hierarchy
18:37 allison basic strings, ints, and floats?
18:38 moritz yes, we use them
18:38 moritz we also use parrot's lexicals
18:38 pmichaud we use strings ints and floats in registers, but I don't think we make much use of String, Integer, and Float PMCs
18:38 allison basic code objects, then
18:39 allison 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
18:39 moritz but that's stuff that could easily be changed, given the right ops
18:39 allison ah, yes, how about Parrot's massive body of ops?
18:39 allison how much of that does Rakudo use?
18:39 pmichaud We don't use many parrot ops.  I can give you a basic count in a second... :-)
18:40 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.
18:40 moritz https://github.com/perl6/nqp/bl​ob/master/src/QAST/Compiler.nqp lists nearly all the parrot ops we use
18:40 pmichaud cotto: yes, but there's a big "but"
18:40 cotto pmichaud: I'm sure there's more than one.
18:41 pmichaud https://github.com/perl6/nqp/b​lob/master/docs/nqp-opcode.txt   # a more readable list
18:41 moritz no, wrong link, wait a sec
18:41 moritz pmichaud: I'm not sure how up-to-date that is
18:42 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.
18:42 cotto pmichaud: yes, to the extent that they're not necessary to build Parrot itself.
18:42 pmichaud I agree that it's unnecessary baggage to Rakudo, but the items mentioned also aren't impediments to Rakudo either
18:43 pmichaud i.e., they don't impact Rakudo's performance significantly
18:43 pmichaud 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
18:43 allison pmichaud: memory and execution speed aren't the only limited resources
18:44 allison pmichaud: maintenance and development focus is relevant too
18:44 pmichaud allison: yes, see what I just wrote :)
18:44 allison pmicaud: aye, thinking alike :)
18:44 pmichaud I think I'm reacting to something a bit specific here (more)
18:45 allison and, it's likely that cutting support for all those extras would also make it easier to trim the parrot core
18:45 allison as in, each of those bits depends on different Parrot features than Rakudo does
18:45 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)
18:46 pmichaud 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
18:46 allison yeah
18:46 pmichaud ...and we never get to the second part, which is "we'll be able to make improvements"
18:46 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.
18:47 cotto 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 cotto still hard work, but less constrained
18:48 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 pmichaud My perception has been that this isn't the bottleneck or limiting factor.
18:48 allison the biggest limiting factor is that it's a big scary codebase
18:49 allison which is related, but not exactly the same
18:49 cotto That's a relevant factor.
18:51 allison and also helped substantially by ripping out a bunch of stuff
18:55 allison I have to say, I'm tempted, I really am.
18:55 allison That's the only alternate I'm tempted by.
18:57 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 cotto allison: thanks for the historical background.
18:58 allison cotto: anytime :)
18:59 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.
19:00 uvtc 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.
19:01 allison pmicaud: AFAICT, commitbits aren't really a blocker, tuits are
19:01 cotto That's my view also.
19:02 pmichaud same here.
19:03 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 cotto again, big if
19:03 allison what are the requirements on the Rakudo side now?
19:03 allison does Rakudo still use Perl CLA?
19:04 allison (because if that's a blocker, it's easy enough to adopt something like the Linux Kernel certificate of origin)
19:04 allison (which requires no signing)
19:06 allison Legal infrastructure should always serve the project, not the project serve the legal infrastructure :)
19:07 allison 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
19:07 allison cotto: more about Parrot joining TPF, with the express purpose of collaborating with Rakudo
19:08 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
19:08 allison cotto: yeah
19:08 allison moritz: replace it with an NQP-based JSON parser?
19:09 allison moritz: bootstrapping required, but that doesn't seem to be scary to Rakudo folks
19:09 Mike-PerlRecruiter_ joined #parrot
19:10 moritz sure, doable, just not trivial
19:10 allison yup
19:11 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:12 allison arnsholt: at the moment I was largely looking for the broad brushstrokes of whether NQP needs Parrot for C interop anymore
19:13 allison 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 #parrot
19:15 not_gerd ~~
19:21 not_gerd 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 not_gerd 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)
19:22 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
19:23 moritz note that this requires all of 6model
19:23 allison moritz: replacing Parrot objects with 6model is a viable negotiation
19:23 moritz sure
19:23 allison moritz: though it may also be Parrot just provides no object model at all
19:24 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...)
19:24 allison moritz: it is, but how much of that tight coupling does Rakudo/NQP depend on?
19:25 allison moritz: like, for example, ops2c gets a lot simpler if the only ops needed are the few NQP uses
19:27 pmichaud note that one could check in the PIR code for ops2c and still eliminate nqp-rx, I think.
19:28 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.
19:29 not_gerd cotto: there might be bootstrapping issues
19:29 not_gerd not unsolvable, but someone needs to take a closer look
19:29 cotto not_gerd: yes.  That was the first issue I ran into when looking at it.
19:30 pmichaud I have to run for a while -- bbl
19:30 cotto doable, but not without thought
19:30 cotto I've had lunch sitting next to me for the last 10 minutes getting cold, so ditto.
19:47 Eddward joined #parrot
19:50 bouncy joined #parrot
20:18 brrt joined #parrot
20:23 brrt hi all
20:23 brrt whats the deal with closing off parrot?
20:27 brrt i'm unhappy about it\
20:28 not_gerd apparently, PaFo will close its doors
20:28 not_gerd the future of Parrot itself is yet to be decided
20:29 cotto brrt: not so much closing as refining its focus
20:29 cotto in my head, at least
20:32 brrt well, what focus are we talking about, then?
20:33 cotto changing focus from hosting all dynamic languages to supporting Rakudo exclusively
20:37 brrt hmmm
20:37 brrt but, radical suggestion, wouldn't supporting rakudo pretty much mean that you could support any other language as well?
20:37 cotto It needs a lot of hmmming.
20:37 brrt it does
20:37 brrt but perl6 is much of a superset of other languages
20:37 cotto yes, but incidentally
20:37 brrt other suggestion: why does rakudo need a vm at all
20:38 brrt why couldn't we / they just compile nqp to x86 / arm / whatever
20:38 brrt basically, if parrot becomes 'the thing to run rakudo on', well, the limits are off
20:39 cotto s/the/a/, given recent nqp/jvm work
20:39 brrt well, yes, sure\
20:40 brrt 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 contingencyplan joined #parrot
20:41 cotto nqp/jvm is showing initial promising signs, but that's not necessarily an indicator of how the end result will look.
20:42 brrt that is true
20:42 brrt is anything still happening on the m0 front?
20:42 brrt basically, why is the perl community disintegrating?
20:42 cotto wrt Parrot in an nqp/jvm world, I can't say for sure.
20:43 cotto I don't think that much will be happening with M0 in the immediate future.
20:44 cotto 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
20:45 allison brrt: but there's a big difference between "implicit support" and actual implementation work
20:45 cotto allison: exactly
20:45 allison brrt: and when the rubber hits the road, Parrot's lack of focus has contributed to implementation efforts flying all over the map
20:45 cotto The idea is to get one language into a production-ready state, then possibly look at branching out.
20:45 allison brrt: instead of delivering a usable product
20:46 brrt well, lack of focus is a general thing now, isn't it?
20:46 brrt but yeah
20:46 brrt actually, looking at the parrot source code it isn't at all the horror it is made out to be
20:47 allison brrt: the team has been pretty good at sticking to coding style guidelines and passing tests, which buys a lot
20:47 allison brrt: even when working on a very complex problem
20:48 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
20:49 allison (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
20:49 allison brrt: which lead to "okay then, what's happening in the Parrot project?"
20:49 allison not_gerd: close, I mean PaFo has been talking about closing for months now
20:50 allison 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
20:50 brrt fair enough
20:51 allison not_gerd: it was only Friday that I thought to ask "will Parrot development actually continue?"
20:51 allison brrt: and so far, no one has actually said "I'll do it"
20:51 brrt hmm
20:51 brrt who could do it?
20:51 brrt whiteknight++ gave it a long run
20:52 brrt 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"
20:52 allison er, 3?
20:52 allison I lost count
20:52 brrt it seems everybody who would've done it has done it alone
20:52 allison brrt: in recent years, yes
20:52 cotto I've been trying to figure out a plan that I can get one or two others to buy into.
20:52 moritz and one who wants cross-platform GUI stuff on parrot :-)
20:52 brrt moritz, that one was hilarious
20:52 cotto That one came out of left field.
20:53 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 allison moritz: I at least give him credit-due for thinking about practical use cases
20:53 allison moritz: instead of just compiler theory
20:54 brrt yes, well, vms are always somewhat removed from practical use cases, aren't they?
20:54 allison brrt: sort of, yes
20:54 allison brrt: at least it's very easy to fall into the trap of making the "framework" king
20:55 allison brrt: but, a VM isn't much use if it isn't actually used for something
20:55 allison brrt: it's just... hot air
20:56 allison 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.
20:56 allison cotto: me too :)
20:57 cotto I hoping for some time tonight.  I had a nice email all drafted, then 50 other replies happened.
20:57 allison heh :)
20:57 cotto *I'm
20:57 allison and another long IRC thread
20:57 brrt :-)
20:57 brrt well
20:57 brrt i'm following any and all discussions
20:58 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
20:59 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
20:59 cotto Just tell me that it wouldn't be taught by Neil deGrasse Tyson.
21:00 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 allison *than
21:00 allison nah, just ordinary profs
21:01 allison but, it is getting into general relativity, so beyond the basics of stars and planets
21:01 allison definitely interesting
21:01 uvtc Astrophysics is fun intellectual stimulation, but not very practical.
21:01 cotto uvtc: the tiny black hole sitting on my desk says otherwise.
21:01 cotto ;)
21:01 allison uvtc: depends on your goal
21:02 allison uvtc: in some ways it's *very* practical, it's totally focused on physical matter and the interactions between real world objects
21:02 allison uvtc: I find that grounding in reality refreshing
21:02 not_gerd one of my profs got a patent on energy generation via miniture black holes as a practical joke
21:02 allison uvtc: especially after years in CS where people will argue to their dying day that their theory is "right" with no proof
21:03 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
21:03 allison not_gerd: sounds like a fun professor :)
21:04 allison uvtc: I think CS folks could do with an upset as radical as realizing the earth isn't flat
21:04 allison uvtc: and the sun doesn't orbit the earth
21:05 allison 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.
21:06 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
21:06 allison *they
21:06 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
21:07 allison uvtc: sort of the other way around
21:07 allison uvtc: I got into Perl 6 quite early on
21:07 allison uvtc: mainly on the basis of my background in linguistics
21:08 allison uvtc: i.e. "how can we make a language that more closely maps to the human brain"
21:08 allison (a computer language, that is)
21:09 allison 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 bouncy joined #parrot
21:11 allison uvtc: and then was lured out of it by quantum computing
21:12 allison uvtc: and from there into quantum mechanics
21:12 allison uvtc: and from there into astrophysics
21:12 uvtc astrophysics is certainly very alluring.
21:13 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 allison uvtc: we'll see if I get to it
21:14 allison uvtc: on the whole, I think I find quantum mechanics more interesting than astrophysics
21:14 allison uvtc: but both are interesting
21:14 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...
21:15 allison uvtc: There's a bit of personal motivation in there.
21:15 allison uvtc: I'm still a Perl developer. I (partly) make money writing Perl code.
21:16 allison uvtc: I don't want to find myself working on the JVM in 3 years. Or even 10 years.
21:16 allison uvtc: That's not to say I'm against having a Perl 6 implementation on the JVM.
21:17 allison uvtc: That's totally cool, and if someone wants to write it, they have my hearty support. From a distance.
21:17 allison uvtc: I just don't want to use i.
21:17 allison *it
21:17 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. :)
21:18 allison uvtc: exactly. Astrophysics isn't going anywhere. It'll be pretty much the same next year as it is this year.
21:18 allison uvtc: Parrot might not be.
21:18 uvtc allison: was just about to type that. :)
21:19 uvtc " 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.
21:20 allison uvtc: It's a target audience thing.
21:20 brrt i have my doubts about jvm as well
21:21 brrt 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.
21:21 allison uvtc: But, the question is, who?
21:21 allison and how many of them?
21:21 allison I don't think Perl 5 developers are suddenly going to start looking for Java libraries they can use.
21:21 brrt do perl6 people know java languages
21:22 brrt s/languages/libraries/
21:22 brrt what does 'we can haz lotsa libraries' even mean
21:22 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.
21:22 allison So, it's a tiny cross-section of two very large communities.
21:22 allison Not compelling, business-wise.
21:23 allison (Back to "if this was a  startup...")
21:23 brrt java developers are jumping to scala, however
21:23 allison brrt: sure, but scala is totally focused on Java features
21:23 allison brrt: is Perl 6 going to take that step?
21:24 allison 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
21:24 brrt perl6 is pretty OO though, ahnd has functional stuff
21:24 allison brrt: without much certainty that Java users will like it
21:24 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?"
21:24 brrt why isn't there a 'simplest p6 that could possibly work'
21:25 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.
21:26 allison uvtc: Perlers won't be excited by looking for Java libraries instead of writing it themselves?
21:26 allison uvtc: It certainly does seem to be the Perl way to "write it myself".
21:26 uvtc allison: I think it's going to be percieved as a "rock and a hard place" situation.
21:27 allison uvtc: It's the essence of TMTOWTDI.
21:27 * brrt is off for sleeping
21:27 brrt good discussion, thanks people
21:27 brrt good to see people still /care/
21:28 allison thanks for the thoughts, brrt
21:28 cotto 'night brrt
21:28 brrt :-) 'night all
21:28 not_gerd anyone wants to make a pretty picture from that: https://gist.github.com/gerdr/4751112
21:29 cotto not_gerd: graphviz is surprisingly easy to use
21:31 cotto 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:32 allison not_gerd: that's a very long list :(
21:33 allison not_gerd: aiming to cut it in half could be a good first goal
21:37 Reini joined #parrot
21:45 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 uvtc d that this might not be a long-term recipe for success.
21:48 allison uvtc: yes, I lean in that direction too
21:51 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:52 Eddward 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:53 Eddward 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:54 Eddward I hope perl doesn't go that way.  perl6 still looks like the language I want to use.
21:55 allison Eddward: That's a good point, and does fit my experience working in Java.
21:55 allison Eddward: (Both "old" Java and "Android" Java.)
21:56 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 Eddward I spend too much time fighting with IDEs that are needed to make up for language-isms.
21:57 * not_gerd is tempted to rewrite ops2c in Perl6 and bootstrap by checking in generated files
21:57 allison not_gerd: Perl6 or NQP?
21:58 allison not_gerd: Neither is a problem in the "focus on Rakudo" scenario, just curious.
21:58 not_gerd allison: full-blown Perl6
21:58 allison not_gerd: and if there are only 20 ops in Parrot, do they even need to be generated?
21:59 not_gerd allison: that... might be worth considering
22:00 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.
22:00 allison cotto: probably a different 20 than m0
22:00 allison cotto: i.e. instead of redesigning the 20, just go with what NQP actually uses
22:00 allison cotto: and leave those in place, working as is
22:00 allison cotto: and ditch the rest
22:00 cotto allison: nqp uses way more than 20
22:01 cotto even if you're just counting the core parrot ops
22:01 allison cotto: it was a short list, fewer than 100 certainly
22:01 allison https://github.com/perl6/nqp/b​lob/master/docs/nqp-opcode.txt
22:01 allison was what someone gave me
22:02 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 cotto 20 is easy enough to maintain by hand.  100, maybe.
22:04 uvtc focus on Rakudo + slimming down + "good-enough" Perl 5 interop + interop with C libs = "the great molting of 2013" ? :)
22:06 cotto Both of those needs a whole lot of planning.
22:08 Reini joined #parrot
22:12 * not_gerd wishes everyone a good night and looks for a snack before heading off to bed
22:12 not_gerd left #parrot
22:16 allison cotto: and a whole lot of work
22:16 allison must run, my son is in a piano concert this afternoon
22:17 uvtc o/
22:17 cotto allison: yes
22:30 MikeFair joined #parrot
22:43 Reini joined #parrot
23:00 dalek nqp/rx-portability: 5ecc011 | jnthn++ | src/ (3 files):
23:00 dalek nqp/rx-portability: Add nqp::const mechanism.
23:00 dalek nqp/rx-portability:
23:00 dalek nqp/rx-portability: Allows mapping constants in a backend-independent way.
23:00 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/5ecc0110f6
23:00 dalek nqp/rx-portability: b7756b5 | jnthn++ | src/stage0/ (9 files):
23:00 dalek nqp/rx-portability: Update bootstrap.
23:00 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/b7756b57f2
23:00 dalek nqp/rx-portability: 081a30f | jnthn++ | src/QRegex/ (2 files):
23:00 dalek nqp/rx-portability: Lots of pir:: => nqp:: in NFA and Cursor.
23:00 dalek nqp/rx-portability: review: https://github.com/perl6/nqp/commit/081a30fde7
23:07 pjcj joined #parrot
23:11 alester joined #parrot
23:14 Reini joined #parrot
23:44 Reini joined #parrot

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

Parrot | source cross referenced