Camelia, the Perl 6 bug

IRC log for #parrot, 2013-02-08

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:08 benabik joined #parrot
02:46 kid51 joined #parrot
03:09 sivoais joined #parrot
03:24 sivoais joined #parrot
03:29 kid51 joined #parrot
03:52 contingencyplan joined #parrot
04:00 Reini joined #parrot
04:35 Reini joined #parrot
06:12 MikeFair joined #parrot
07:09 Mike-PerlRecruiter_ joined #parrot
09:37 drift_ joined #parrot
09:39 cosimo joined #parrot
09:44 Psyche^ joined #parrot
09:58 bouncy joined #parrot
11:57 xcombelle joined #parrot
13:38 dalek nqp: 55ae367 | (Paweł Murias)++ | t/nqp/59-nqpop.t:
13:38 dalek nqp: Avoid testing for negative arguments to nqp::deletepos.
13:38 dalek nqp: review: https://github.com/perl6/nqp/commit/55ae3675b2
13:51 mtk joined #parrot
13:57 Coke dukeleto: still waiting for that board email.
13:57 Coke cotto: are you still the architect?
14:17 PacoAir joined #parrot
14:26 Reini joined #parrot
14:38 bluescreen joined #parrot
15:20 Reini joined #parrot
15:54 benabik joined #parrot
16:36 benabik joined #parrot
17:06 contingencyplan joined #parrot
17:09 dmalcolm joined #parrot
18:51 Reini joined #parrot
18:56 xcombelle joined #parrot
19:04 benabik joined #parrot
19:08 cotto Coke, yes.  Why do you ask?
19:09 Mike-PerlRecruiter_ joined #parrot
19:14 Coke Just wondering if there are plans.
19:18 Reini joined #parrot
19:45 cotto For the time being that's an open question.  I'm planning on meeting with dukeleto around the conference circuit to talk about that.
20:04 perlite_ joined #parrot
20:18 Coke If he hasn't yet, please ping him about getting some correspondence out from the board.
20:18 Coke Esp. in light of allison's last email.
20:18 Coke Did you read the twitfest between chromatic et al. yesterday?
20:19 cotto yes
20:21 Coke Hopefully it will inspire someone with tuits to make pretty things.
20:22 Coke (I'm trying not to be pissed about it and mostly succeeding.)
20:24 allison it might help to know chromatic's dog died last weekend :(
20:24 Coke Well, that sucks.
20:25 allison a substantial added measure of grumpiness
20:25 allison dukeleto has been following up with the board this week
20:26 allison mainly, we need to have elections
20:26 allison to move things from people who don't have time to people who do have time
20:27 Coke I think we're down to one developer who's on break. I'm not sure anyone has time at this point.
20:27 * benabik doesn't have much during the school year.
20:27 allison the only blocker there is someone who has time to run elections...
20:27 Coke But yah, if we can get some volunteers. My understanding was, though, that there was no point to having elections due to <reasons>
20:27 allison yeah, exactly
20:27 cotto My view is that a sufficient plan would motivate people to find time.
20:28 allison we do need some people with access to pay bills and such
20:28 allison and sign paperwork to move the legal operation over to a new hosting organization
20:28 cotto i.e. sfc or the Apache Foundation?
20:28 allison (none of this affects development, it's just administrative trivia)
20:28 allison cotto: aye
20:29 allison sfc has been very agreeable, we haven't really talked much with Apache yet
20:29 allison my only hesitation about Apache is that they've made an "issue" of git in the past
20:29 allison insisting on svn
20:29 allison but, that may have changed
20:29 allison it's in the "worth asking" department
20:31 moritz I know that several Apache projects have migrated to git
20:31 allison Apache has the advantage of a clearly defined incubation process
20:31 moritz for example lucy (a C/Perl based search engine)
20:32 allison which is actually quite a healthy "housekeeping" run for projects
20:32 atrodo Just my 2c, but from my perspective, it seems like projects  that go to Apache become irrelevant
20:32 allison sfc has the advantage of entirely not caring how the project is run, and just provides legal/financial infrastructure
20:33 allison atrodo: sounds like a vote for sfc
20:33 allison (Software Freedom Conservancy, that is)
20:34 Coke I think all we care about is the infrastructure. TPF might also be worth considering.
20:35 allison I have chatted with TPF (I'm still on the board) and the thinking was that it's already hard to allocate funding to Rakudo, and Parrot would be even harder
20:35 allison not a "no", but definitely a "look at other options first"
20:38 allison Coke: and it's a bit of a personality decision for the Parrot developers/members
20:39 Coke so, my take is, if the foundation is shuttering, there's no need for elections at this point, let's just get the thing moved.
20:39 allison if the group is comfortable declaring that Perl 6 is the primary purpose of Parrot, that would make TPF a better match
20:39 atrodo allison: Nothing against asf, but yes. Then again I worry about the relevance of parrot anyways.
20:39 Coke At this point, who is the group?
20:40 cotto How about whoever responds on parrot-dev.
20:40 Coke anyone with a commit int he past 2 years?
20:40 allison Coke: agreed, since we have limited time, better to focus it towards the first priority
20:40 Coke cotto: the org has some rules which might cover this.
20:40 allison (that was agreed on skipping elections)
20:40 cotto Coke, that's true
20:40 allison Coke: yes, legally it's the membership
20:41 allison which primarily consists of developers
20:41 allison (since the rules for a commit bit are the same as the rules for membership)
20:41 allison but, there may be some developers who haven't been granted membership yet
20:41 allison if they're new since the last election
20:42 allison Coke: I guess that raises the question, do you think it makes sense to officially shut the project down?
20:43 allison I see enough activity that I'm investing time in keeping the project going.
20:43 allison As in, providing the legal transition from the current foundation to another host.
20:44 allison so it can keep running
20:45 allison Coke: but, it'd be easy enough to say, assign the copyright to TPF, have them release it as public domain or BSD license, and shut the doors
20:46 allison Coke: say we had a good run, and anyone is welcome to take the code in any direction they want
20:47 allison Coke: or PSF, for that matter. They indicated a few years ago that they'd be willing.
20:47 allison (I'm not on the board there anymore)
20:49 atrodo allison: Python? Really? That's pretty cool actually
20:52 allison atrodo: :) I don't think they have the bandwidth to take on Parrot as an active project, but workable as simple code-holders
20:55 PerlJam Hmm.
20:56 * PerlJam reads scrollback a little bit.
20:56 Coke allison: you mean, don't even bother transfering the codebase to a new org?
20:57 Coke I have no opinion on that.
20:57 allison Coke: we have to transfer it somewhere, legally
20:57 Coke is it a matter of just assigning copyright at that point?
20:57 Coke brb.
20:58 allison yes, assigning the copyright, and a license to past contributor agreements
20:58 allison (because contributors continue to own their contributions)
20:58 allison Coke: it's really only a very slight difference, legally
20:59 allison Coke: but practically, it's the difference between asking for a new home for an entire project with active contributors, and asking for a new home for an inactive codebase
21:01 PerlJam you're just talking about the legal infrastructure, right?
21:09 allison PerlJam: I'm asking Coke what he thinks about the whole shebang.
21:09 allison And, by extension, anyone else who has thoughts on it.
21:10 allison PerlJam: My assumption has been that Parrot is active, and we need to find a new host for it to continue as an active project.
21:10 allison PerlJam: But, what Coke said made me question my assumption.
21:10 Coke you say host, I think code infrastructure - that's covered, isn't it?
21:11 allison I mean legal host, as in the owner of the intellectual property.
21:11 allison Not source control, which is covered by Github.
21:12 allison Coke: Really, I'm asking "do you all want to keep working on the Parrot project?"
21:12 allison By "you all" I mean "anyone".
21:12 allison Coke: And, I'm hoping the answer is "yes".
21:13 allison I'm hoping there are enough people still interested and motivated to keep working on it that it continues.
21:14 Coke we should at least wait for rurban to show up again.
21:14 rurban I'm here
21:14 rurban But I'm busy with p2 and perlcc
21:14 allison Coke: oh yeah, it's not a snap thing, it's something for deep thought
21:17 rurban I'll take parts of parrot for p2, but current parrot is not practical due to its function call overhead.
21:18 atrodo p2?
21:18 rurban http://perl11.org/p2/
21:18 cotto rurban, is p2 the perl 11 project you mentioned earlier?
21:18 rurban a potion (neko, lua) based compiler, vm and runtime
21:18 atrodo neat
21:20 rurban I'm designing the p5 parser now with macros in mind. I do not worry about parrot anymore. But we'll see how far I'll get with it.
21:20 cotto I admire your ambition.
21:20 rurban p6 should be pretty straightforward to target. Much better than the jvm port at least
21:21 rurban The parrot GC and threads are top notch.
21:21 rurban perl6 is bitching about it without any clues.
21:23 allison rurban: that has been a chronic problem with parrot/perl6 relations
21:24 rurban diakopter and kraih mostly, pmichaud at least is knowledgable
21:24 rurban chromatic was very good recently
21:25 rurban rakudo will NOT ditch parrot is the official statement. The need it, if not for bootstrapping
21:26 rurban And the jvm will not help a lot I guess.
21:27 rurban rakudo will then be as fast as niecza, so what
21:29 allison rurban: if parrot shut down as a project, do you predict Rakudo would pick up the codebase?
21:29 moritz maybe for ensuring buildability until it has bootstrapped on another VM
21:30 allison moritz: sounds like a "no"
21:30 rurban perl6 should look at all the options. jvm is not the last word would be my prediction. parrot has more to offer but needs work with the calling convention.
21:31 moritz and JIT
21:31 rurban yes
21:31 moritz which has been in the works since, when, 2008 or so?
21:31 arnsholt JVM is definitely not the last word, AFAICT
21:32 allison arnsholt: JVM is a bloated nightmare
21:32 allison arnsholt: but, it works
21:32 rurban parrot has a better GC and threads than JVM at least. It scales linear, without overhead.
21:32 allison at the end of the day, being "done" with something bad is better than "not done" with something awesome
21:32 allison (unfortunately)
21:33 arnsholt The eternal victory of Worse is Better, yeah
21:33 arnsholt (Unfortunately, yeah)
21:33 moritz well, parrot is still a far way off from being awesome
21:33 allison moritz: it's an awesome idea, that's not done
21:33 rurban what is missing? signals. async IO is easy to do now.
21:33 allison rurban: "easy to do" is not "done"
21:33 moritz rurban: JIT compiler, for one.
21:34 moritz I don't see that one being easy to do
21:34 allison I will freely say that Parrot is the best *idea* for a VM anywhere on the planet right now.
21:34 allison but, idea != implementation
21:34 rurban well, regarding jit I'm sceptical. A fast vm and compiler should outperform jitting overhead.
21:34 moritz allison: which part of the parrot idea do you find best?
21:35 moritz rurban: is that actually the case for any dynamic language out there in the wild?
21:35 allison moritz: idea-wise, it's truly and purely dynamic, in a way that no one else has ever been willing to embrace
21:35 moritz ISTR benchmarks that python, JS and LUA are all faster with JIT than without
21:36 allison moritz: again, idea != implementation
21:36 moritz allison: which part of the ideas are you referring to?
21:36 cotto The problem with a JIT is keeping the knowledge to maintain it as part of the community.  The old one was ripped out because lack of expertise meant that we couldn't make some of the changes we wanted to.
21:36 atrodo allison++ # I agree, parrot's idea is the best
21:36 moritz allison: there are many ideas that went into parrot, and I truly don't know which ones you are talking about, and which not
21:36 allison moritz: well, GC, Threading, and Unicode are important, but not exactly revolutionary
21:37 allison moritz: those were important ideas in Parrot, only because Perl 5 didn't have them (very well, at the time)
21:37 allison moritz: the far more interesting ideas developed later
21:38 allison moritz: around dynamic dispatch, and continuation passing style
21:38 allison moritz: (never fully implemented)
21:39 allison moritz: around concurrency in more of an Erlang style than the JVM monolith style
21:40 moritz allison: if those are the truely interesting ideas behind parrot, it has been marketed quite wrong all those years
21:40 donaldh joined #parrot
21:40 allison moritz: it hasn't really been marketed at all (which is another problem, though unrelated)
21:40 moritz I remeber hearing about "register baesd", "language interop", and integration with C as some of the major selling point
21:41 Coke I am waiting to see where jnthn et al. get with the JVM before saying it's not going to be a good target. initial timings vs. parrot are very good, given no optimization on nqp's part, and esp. noting that the jvm timings currently include cross compilation from parrot.
21:41 rurban p2 is 100x faster than parrot or 40x than perl5 even without jit
21:41 allison moritz: "register based" is part of the dynamic dispatch
21:41 allison moritz: i.e. break away from stacks
21:42 moritz allison: sorry, I don't see the connection
21:42 moritz dispatching and calling are (nearly) orthogonal
21:42 moritz so I see that register based is related to breaking away from stacks, but not to dynamic dispatch
21:43 allison moritz: continuation passing style eliminates stacks
21:43 allison moritz: you're talking about "dynamic dispatch" in the limited sense of how you look up code objects to invoke?
21:43 moritz yes
21:44 allison moritz: yes, I meant "a highly dynamic style of dispatch", encompassing a number of features
21:44 allison including CPS, but not limited to it
21:45 allison moritz: I'm not saying the other features weren't important, they are part of the whole package that makes up Parrot
21:45 allison moritz: but simply achiving feature parity with other existing VMs doesn't put a project on the map
21:46 allison moritz: and Parrot had some really exciting developments in the whole concept of dynamic VMs
21:47 allison moritz: but, as you say, they weren't broadcast
21:48 allison moritz: and, to be fair, they weren't part of the Perl 6 spec, so pretty much irrelevant as far as Rakudo was concerned
21:49 allison moritz: still, awesome
21:49 moritz allison: well, if they'd have let to faster execution of code, they'd be quite relevant to Rakudo
21:50 allison moritz: if speed was truly the priority for Rakudo, then cutting out about 80% of Parrots features would probably have been a closer fit
21:50 moritz for example properly done CPS could have let to a very fast way to implement Perl 6's return() through control exception
21:51 allison moritz: that was the theory, yes
21:51 moritz allison: to be fair, it wasn't at first
21:51 PerlJam rehashing the past won't change it :)
21:51 allison moritz: well, no CPS was introduced to support Ruby
21:52 moritz and now we do cut out quite some parrot features, and replace them with our own (like, the object model)
21:52 allison moritz: but, it was a nice side-effect
21:52 allison moritz: yes, but you still carry the burden of those Parrot features, in overall performance
21:53 allison moritz: which seems a bit silly, since many expensive features in Parrot were introduced for Perl 6
21:53 allison (like, Parrot's existing object system)
21:53 moritz allison: ... and then generalized to others, for which the Perl 6 support suffered
21:53 moritz or Perl 6 changed, and parrot refused to follow
21:54 allison I don't think it's "refused" so much as "just didn't have time"
21:54 rurban like dyncall instead of libffi?
21:54 moritz rurban: no
21:54 moritz rurban: I'm thinking of collisions of named arguments, for example
21:55 moritz parrot's and Perl 6's world view mismatched, so in the end Rakudo had to implement its own again
21:55 moritz because parrot wanted to support some hypothetical language or compiler to come
21:55 allison moritz: again, unfortunate
21:55 moritz yes.
21:56 allison moritz: is the impasse... unpassable?
21:57 allison mortiz: seriously, what if the Parrot codebase were chucked at the Rakudo project whole?
21:57 allison moritz: "here, it's under the same license, do whatever you want with it"
21:57 allison moritz: or, maybe "hypothetically" rather than "seriously"
21:57 cotto I can't entirely convince myself that re-merging Parrot and Rakudo would be a bad idea.  Much of the trouble came from splitting them too soon.
21:57 allison moritz: I think I'm largely playing devils advocate today
21:58 cotto of course there's the issue of convincing Rakudo...
21:58 rurban merging would be very good, yes
21:58 moritz allison: I can't speak for all the Rakudo developers, but I for one am not interested in developing or a maintaining a VM
21:58 PerlJam Assuming you can get people to hack on Parrot when  they're really interested in hacking on Rakudo
21:58 allison moritz: as I understand it, you pretty much already are
21:58 cotto moritz, it's not so much an issue of Rakudo maintaining Parrot, but being able to iterate more quickly.
21:58 allison moritz: just using another VM for a small subset of internal features
21:59 rurban rakudo should have a veto over parrot features.
21:59 allison moritz: or to think of it another way, what's the difference between a VM and an interpreter?
21:59 cotto If they're merged, the Parrot folks can absorb dyncall without Rakudo necessarily noticing.
21:59 allison moritz: Perl 5 is just one
21:59 cotto for exampke
21:59 cotto *example
22:00 cotto rurban, if Parrot decided that its purpose is to support Rakudo, that's sensible
22:00 rurban dyncall is technically inferior to libffi, and it runs on less platforms. It was just jonathan who was not able to compile libffi on windows. he should have asked instead of going away.
22:01 cotto ok.  6model
22:02 moritz I'll have to think about the parrot<->rakudo merge a bit more, but I remain skeptical
22:02 PerlJam moritz: me too.
22:02 allison moritz: even if the alternative was reimplementing the rakudo project on an entirely different VM?
22:03 moritz allison: looking at all the baggage that parrot brings with it, yes
22:03 PerlJam allison: I think even *with* Parrot, that's what would need to happen.  (Rakudo would need to reimplement lots of Parroty bits)
22:03 moritz allison: just list all the major parrot subsystems, and tell me which ones you think are well designed and well executed
22:04 allison PerlJam: yes, I expect they'd want to rework a lot
22:04 moritz allison: from my mostly outside view, only the GC is done well
22:04 cotto moritz, if Parrot's purpose is Rakudo, lots of baggage can go away.
22:04 moritz calling convention, subs, namespaces, bytecode, OO... *shudder*
22:04 PerlJam cotto: and who will do that cleaning work?
22:04 rurban moritz: good: gc, threads, io, pmc, ops. bad: call
22:05 moritz PerlJam: that would have been my next question too
22:05 allison rurban/moritz: how do you feel about Parrot's unicode? good/bad/indifferent?
22:05 moritz allison: I have failed to really understand parrot's Unicode model so far
22:05 atrodo Playing hypotheticals, what if parrot went a m0-style route and didn't focus at all on keep any existing bits?
22:06 rurban good enough I would say
22:06 moritz allison: what Perl 6 really needs is an NFG/Grapheme mode, and a clear distinction between buffers and strings
22:06 allison atrodo: at that point, you'd have to wonder if the name was worth keeping either. it's got a bit of bad history
22:06 moritz the existing pieces aren't bad, as long as you have ICU
22:07 rurban much better than perl5 for sure. we have buffers and strings with encoding vtables.
22:07 allison moritz: again, NFG/Grapheme was the Parrot idea, but not ever implemented
22:08 cotto PerlJam: people who are interested in supporting that kind of a future for Parrot would help.  A concrete purpose is better than a fuzzy one.
22:08 rurban parrots strings are much better than in any other language vm I can think of. most just do utf8 all, or ucs-4 all.
22:08 cotto It wouldn't generally make things worse for Rakudo if it took a while for developers to gain an interest.
22:08 atrodo I think there's people interested in parrot or a parrot-like vm, but don't want to work on the current parrot internals
22:08 atrodo it's scary code, which is really why I've never dived in to do anything
22:09 allison atrodo: yes, it is scary code
22:09 allison atrodo: partly, trying to be too many things for too many people
22:09 allison atrodo: partly history
22:09 allison atrodo: growth over time
22:10 allison atrodo: maybe some small part of the complexity is essential
22:10 atrodo allison: Absolutely
22:10 bluescreen joined #parrot
22:10 cotto atrodo: yes
22:10 allison atrodo: as in, solving a complex problem requires *some* level of code complexity
22:10 cotto er, allison
22:11 allison atrodo: but I'd estimate a lot of the complexity really is non-essential, i.e. could be stripped out while still accomplishing the same purpose
22:11 allison atrodo: (or a more tightly focused purpose)
22:11 cotto It'd be good for Parrot to decide that its primary goal is to support Rakudo at the expense of other use cases.  If it ends up being like PyPy and having other use cases, let that be a bonus.
22:11 atrodo allison: certainly, it's a complex problem. I've never felt like the code is proportionally complex.
22:11 atrodo allison: exactly
22:11 davidfetter joined #parrot
22:12 cotto or alternately to have some concrete vision
22:12 allison cotto: yes, I think serving one master well is far, far easier than serving many masters (poorly)
22:12 moritz great to see some new discussions going on here; sadly I have to leave
22:13 cotto moritz: thanks for dropping by
22:13 cotto It's been stimulating.
22:13 rurban I am in favor to give rakudo full power over parrot.
22:13 rurban veto or maint or feature sets
22:13 atrodo I would agree as well, unless we can quickly bring more than a couple languages up quickly, focusing on one is best
22:14 Coke An interesting project might be to see what can be culled from parrot and still have nqp run atop it.
22:14 Coke having struggled for years trying to bring up another language, I think we might be better off focusing on one.
22:15 cotto Coke: that's a very interesting idea.
22:15 Coke (there are still tickets open from years ago when something changed in parrot that broke partcl, and they have not be fixable.)
22:15 PerlJam especially if, by culling, you can get speed improvements :)
22:17 Coke cotto: and then see if that smaller parrot was something that could not only work for rakudo, but also other languages. Iunno.
22:17 Coke er, *not been fixed, I guess is better way to say it.
22:17 Coke Something to think about. That was kind of the spirit I was trying to rip out PASM in.
22:18 PerlJam Coke: there'd still be the impedence mismatch between parrot features and nqp features (object model for instance)
22:18 Coke PerlJam: not if parrot used 6model natively.
22:18 allison PerlJam: the current object model in Parrot is certainly sacrificable, it was only added because Rakudo requested it
22:18 allison PerlJam: so if they don't need it anymore, it can go
22:18 Coke but, if not, better to have NO object system than an unused one.
22:19 Coke (same reason we killed the jit)
22:19 PerlJam yes. quite true.
22:19 allison Coke: aye, strip down to basic ability to have pointers to objects
22:19 allison Coke: with no inherent behavior added
22:19 Coke So, anyway, that sounds like a nifty side project that I'd like to see where that goes.
22:20 Coke But right now, I have to drive througha  snowstorm. laters.
22:20 PerlJam Coke: be careful!
22:20 atrodo Coke> Good luck!
22:27 davidfetter joined #parrot
22:41 pmichaud joined #parrot
22:41 pmichaud good afternoon, #parrot
22:44 cotto hio pmichaud
22:47 pmichaud someone suggested I read the backscroll and possibly weigh in on the discussion :-)
22:49 cotto I was going to email you a bit later, but that works too.
22:50 pmichaud well, email might be easier for more reflective thought, yes.  I might not be able to answer until Sunday though.
22:51 cotto It's not a thought that needs a quick response.
22:57 Reini joined #parrot
22:59 diakopter joined #parrot
23:00 Reini1 joined #parrot
23:07 diakopter allison: rurban is completely wrong in accusing me of being "without any clues" and not "knowledgeable". My critique of the threads system on parrot-dev is sound.
23:08 rurban Based on what?
23:08 allison diakopter: since I haven't looked at the code at all, I can only say "clearly there is a difference of opinion here" and leave it at that
23:08 pmichaud fwiw, I suggested a way through that debate -- prototype some code in parrot threads that emulates what rakudo or Perl 6 would need
23:08 pmichaud so rather than arguing "who's correct" let's see some code that we can evaluate.
23:09 allison pmichaud: how about a wholehearted replacement with what rakudo needs?
23:09 rurban there's enough code in examples/threads
23:09 not_gerd joined #parrot
23:10 * Coke arrives alive, and cancels his other evening plans to sit at home.
23:10 pmichaud allison: replacement would be fine... but I suspect whoever does the replacement needs a good understanding of Perl 6 parallelism
23:10 cotto Coke: think of all the snowmen you could be making.
23:10 pmichaud rurban: is there an example of how one would use threads to do something like    @a >>+<< @b    in Perl 6?
23:11 not_gerd for what it's worth, these were my thoughts 5 months ago when I stopped working on my m0 prototype: https://gist.github.com/gerdr/48890726c026588535fa
23:11 Coke not_gerd: seems reasonable.
23:12 diakopter rurban: your question "Based on what?" is confusing. If you're asking on what my critique is based, read the email. If you're asking on what I based my claim that you are completely wrong, see nearly everything you've said to this channel today, which give the clear impression you are currently manic - your expansive mood and grandiose thoughts are .. extreme.
23:13 rurban pmichaud: You added a ticket for this simple example and I had no time yet to implement it
23:14 rurban diakopter: I don't see any recent parrot-dev email of yours, which bashes threads. Maybe you sent it to perl6?
23:14 diakopter um.
23:14 diakopter try again
23:15 Coke diakopter: perhaps provide a subject, a date, or a URL.
23:15 sorear http://lists.parrot.org/pipermail/p​arrot-dev/2013-February/thread.html
23:15 rurban diakopter: And you are alone with your extreme opinion, sorry. Just don't spread anti-parrot fud publicly
23:15 sorear I see nada
23:15 pmichaud rurban: I've heard from several people whose opinions I highly respect that the new parrot threads implementation has some significant fundamental issues. (more)
23:15 diakopter Dec 8.
23:15 Coke there's no need for anyone to get upset or snippet.
23:15 Coke *snippy
23:15 diakopter sorear: did I say it was in February?
23:15 cotto Coke: +1
23:16 rurban So parrot-dev would like to hear that the critic is. Is it too fast now?
23:16 diakopter rurban: did I even say it was "recent"?
23:16 sorear diakopter: I would assume that if people are going to get upset over something, they should get upset over something recent
23:16 rurban I looked a few pages back.
23:17 rurban Do you mean http://lists.parrot.org/pipermail/p​arrot-dev/2012-December/007296.html maybe?
23:17 Coke the subject is "Re: hybrid threads questions"
23:17 pmichaud rurban: rakudo's position on parrot threads is therefore "we'd like to see how the Parrot designers intend for this to work" rather than us trying to figure it out based on faulty assumpions about how it should work.
23:17 diakopter yes.
23:18 rurban complicated and real-life examples how threads should work are in examples/threads. even with semaphores, which are generally not needed.
23:18 diakopter so you're saying you can't understand my questions?
23:18 pmichaud rurban: if your answer is "rakudo needs to figure out parrot threads on their own", that's fine, just realize that it won't be a priority for us.
23:18 rurban easy examples how to iterate in parallel or how to update s single external variable need to be written.
23:20 rurban nine wrote a paper how threads work, I wrote a simplified blog post how threads work. there' are enough big examples and test cases.
23:21 rurban diakopter: your question were directed to niner. I don't see big problems that we have no fully concurrent GC yet. Still better than jvm threads.
23:21 Coke diakopter: Is your main concern "how can GC work when data is passed between threads"
23:21 Coke ?
23:22 rurban he wondered that proxies life longer than expected
23:22 Coke If so, it seems like this would be amenable to some demo code that demonstrated a memory leak.
23:22 rurban that they leak until process end
23:23 rurban however I found no leaks whatsoever in my tests
23:26 rurban Creating subtasks from tasks is a current limitation, nobody cares about. Why this should be the cause to cry foul on parrot on our gc/threads is BS
23:26 diakopter note that I didn't complain about that in that email
23:27 rurban no, you just complained via twitter that parrot threads and GC are broken, which is total BS
23:27 Coke diakopter: note that saying "did I say that" when other people didn't say that is really not playing fair. Perhaps we can all calm down and write some tests.
23:28 diakopter I'm not allowed to say "but you're putting words in my mouth"?
23:30 rurban https://twitter.com/diakopte​r/status/299614785861976064
23:30 rurban https://twitter.com/kraih/​status/299588826924470272
23:31 rurban "Parrot threads are basically iThreads again, the JVM is lightyears ahead" pardon, that was years ago.
23:31 diakopter uhm..
23:31 pmichaud okay, this discussion has zero value to me, so I'll come back again sometime.  Take care, all!
23:31 diakopter now you're just embarrassing yourself
23:31 pmichaud (less than zero value, actually)
23:31 Coke right, same here. you two have fun bitching at each other.
23:32 rurban fact is: parrot threads scale linear, and do not block the GC
23:32 sorear *sigh*
23:32 rurban I know no other language which can do that.
23:32 rurban left #parrot
23:32 Coke it would be helpful if examples/threads/alloc_test.pir had notes about what it was testing.
23:38 Coke I tried running alloc_test.pir - seems to hang and do nothing. the matrix_part.winxed chews up a lot of cpu, but I can't see that it's doing anything. if it's an example, we problably want somethign that finishes sooner.
23:39 allison that digression didn't really answer my question
23:40 allison which was "what if Rakudo was given total authority to decide what Parrot did?"
23:40 allison I understand there are differences of opinion on what it currently does.
23:40 Coke without tuits, the hypothetical doesn't really matter.
23:40 Coke I doubt rakudo is going to spend cycles hacking on VMs when they coudl be hacking on rakudo.
23:41 Coke and parrot currently just pissed off it's one developer.
23:41 Coke gah. *its
23:41 allison true, parrot features are largely determined by who volunteers to do something
23:41 allison Coke: "parrot" did? "rakudo" did? or something?
23:41 Coke #parrot did.
23:42 allison ah, yeah
23:42 diakopter just me, not the channel
23:44 allison Coke: but then, that one developer already said he was working on his own VM now and didn't have time for parrot
23:44 allison Coke: though he might pick up some code from it (probably that same threads and GC, I'd guess)
23:45 allison Coke: and if no one is working on it, really and truly no one, then it's time to hang up the hats and go home
23:45 allison Coke: not a bad thing, really
23:45 allison Coke: it's a good project, we did good work
23:46 allison Coke: very ambitious
23:46 pmichaud allison: to answer your question more directly... I think I agree with moritz and PerlJam from earlier that most Rakudo devs aren't interested in trying to take over Parrot
23:46 allison pmichaud: I agree the codebase without developers isn't very useful
23:47 allison pmichaud: there's a chance that working for Rakudo might inspire some past, present, or future VM devs to get cracking on the codebase
23:47 cotto What I was talking about wasn't as much taking Parrot over as merging them and giving Rakudo the primary voice in Parrot's direction.
23:47 Coke (too busy) ah, excellent point.
23:48 pmichaud well, "merging them" in this manner pretty much seems equivalent to "Rakudo taking over Parrot"
23:49 pmichaud or I'm not seeing an important distinction
23:49 sorear I wonder how much of the current meltdown I may have accidentally inspired with my exchange with dwo*
23:49 allison sorear: from my perspective, not much, it has more to do with closing down the Parrot Foundation
23:49 sorear wat
23:49 cotto pmichaud: that could well be the case.
23:49 allison sorear: which is the ideal time to ask "what's next?"
23:50 diakopter allison: does the PaFo have any grant development funds remaining?
23:50 Coke no.
23:50 allison diakopter: no
23:51 Coke well, only the treasurer knows for sure, but SFAIK, we owe a lawyer a few bucks we don't have.]
23:51 sorear cursory attempt to find documents concerning pafo shutdown: failed
23:51 allison Coke: we have a bit of funding, plenty to pay down the last debts
23:51 allison Coke: but not grant-worthy
23:51 allison diakopter: PaFo hasn't received any donations in years
23:52 cotto apart from gsoc
23:52 Coke and those have been keeping the lights on, yes?
23:52 allison yup
23:52 Coke examples/threads/moretasks.pir also doesn't seem to end.
23:53 allison aye, you need production users to get donations
23:55 benabik joined #parrot
23:56 allison While I'm playing the devils advocate...
23:56 allison If Rakudo doesn't want Parrot, is there interest in converting Parrot into a production-ready Perl 6 interpreter?
23:56 allison no bootstrapping
23:57 allison strip it down to be light and fast
23:58 allison i.e. serve TimToady, rather than Rakudo
23:58 cotto You mean turn Parrot into a Perl6 implementation rather than a VM for one?
23:58 allison yup
23:58 cotto My head hurts.
23:58 allison :)
23:58 allison that's how it started
23:58 allison it kind of diverged
23:58 Coke I suspect that would be more work than being a good target for nqp, but Iunno.
23:59 cotto Parsing STD.pm shouldn't be too hard.
23:59 pmichaud Parsing STD.pm implies you have a Perl 6 parser already, though.

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

Parrot | source cross referenced