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:08 benabik joined 02:46 kid51 joined 03:09 sivoais joined 03:24 sivoais joined 03:29 kid51 joined 03:52 contingencyplan joined 04:00 Reini joined 04:35 Reini joined 06:12 MikeFair joined 07:09 Mike-PerlRecruiter_ joined 09:37 drift_ joined 09:39 cosimo joined 09:44 Psyche^ joined 09:58 bouncy joined 11:57 xcombelle joined
dalek p: 55ae367 | (Paweł Murias)++ | t/nqp/59-nqpop.t:
Avoid testing for negative arguments to nqp::deletepos.
 13:38
13:51 mtk joined
Coke dukeleto: still waiting for that board email. 13:57
cotto: are you still the architect?
14:17 PacoAir joined 14:26 Reini joined 14:38 bluescreen joined 15:20 Reini joined 15:54 benabik joined 16:36 benabik joined 17:06 contingencyplan joined 17:09 dmalcolm joined 18:51 Reini joined 18:56 xcombelle joined 19:04 benabik joined
cotto Coke, yes. Why do you ask? 19:08
19:09 Mike-PerlRecruiter_ joined
Coke Just wondering if there are plans. 19:14
19:18 Reini joined
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. 19:45
20:04 perlite_ joined
Coke If he hasn't yet, please ping him about getting some correspondence out from the board. 20:18
Esp. in light of allison's last email.
Did you read the twitfest between chromatic et al. yesterday?
cotto yes 20:19
Coke Hopefully it will inspire someone with tuits to make pretty things. 20:21
(I'm trying not to be pissed about it and mostly succeeding.) 20:22
allison it might help to know chromatic's dog died last weekend :( 20:24
Coke Well, that sucks.
allison a substantial added measure of grumpiness 20:25
dukeleto has been following up with the board this week
mainly, we need to have elections 20:26
to move things from people who don't have time to people who do have time
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.
allison the only blocker there is someone who has time to run elections...
Coke But yah, if we can get some volunteers. My understanding was, though, that there was no point to having elections due to <reasons>
allison yeah, exactly
cotto My view is that a sufficient plan would motivate people to find time.
allison we do need some people with access to pay bills and such 20:28
and sign paperwork to move the legal operation over to a new hosting organization
cotto i.e. sfc or the Apache Foundation?
allison (none of this affects development, it's just administrative trivia)
cotto: aye
sfc has been very agreeable, we haven't really talked much with Apache yet 20:29
my only hesitation about Apache is that they've made an "issue" of git in the past
insisting on svn
but, that may have changed
it's in the "worth asking" department
moritz I know that several Apache projects have migrated to git 20:31
allison Apache has the advantage of a clearly defined incubation process
moritz for example lucy (a C/Perl based search engine)
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
allison sfc has the advantage of entirely not caring how the project is run, and just provides legal/financial infrastructure
atrodo: sounds like a vote for sfc 20:33
(Software Freedom Conservancy, that is)
Coke I think all we care about is the infrastructure. TPF might also be worth considering. 20:34
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
not a "no", but definitely a "look at other options first"
Coke: and it's a bit of a personality decision for the Parrot developers/members 20:38
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
atrodo allison: Nothing against asf, but yes. Then again I worry about the relevance of parrot anyways.
Coke At this point, who is the group?
cotto How about whoever responds on parrot-dev. 20:40
Coke anyone with a commit int he past 2 years?
allison Coke: agreed, since we have limited time, better to focus it towards the first priority
Coke cotto: the org has some rules which might cover this.
allison (that was agreed on skipping elections)
cotto Coke, that's true
allison Coke: yes, legally it's the membership
which primarily consists of developers 20:41
(since the rules for a commit bit are the same as the rules for membership)
but, there may be some developers who haven't been granted membership yet
if they're new since the last election
Coke: I guess that raises the question, do you think it makes sense to officially shut the project down? 20:42
I see enough activity that I'm investing time in keeping the project going. 20:43
As in, providing the legal transition from the current foundation to another host.
so it can keep running 20:44
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:45
Coke: say we had a good run, and anyone is welcome to take the code in any direction they want 20:46
Coke: or PSF, for that matter. They indicated a few years ago that they'd be willing. 20:47
(I'm not on the board there anymore)
atrodo allison: Python? Really? That's pretty cool actually 20:49
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:52
PerlJam Hmm. 20:55
PerlJam reads scrollback a little bit. 20:56
Coke allison: you mean, don't even bother transfering the codebase to a new org?
I have no opinion on that. 20:57
allison Coke: we have to transfer it somewhere, legally
Coke is it a matter of just assigning copyright at that point?
brb.
allison yes, assigning the copyright, and a license to past contributor agreements 20:58
(because contributors continue to own their contributions)
Coke: it's really only a very slight difference, legally
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 20:59
PerlJam you're just talking about the legal infrastructure, right? 21:01
allison PerlJam: I'm asking Coke what he thinks about the whole shebang. 21:09
And, by extension, anyone else who has thoughts on it.
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
PerlJam: But, what Coke said made me question my assumption.
Coke you say host, I think code infrastructure - that's covered, isn't it?
allison I mean legal host, as in the owner of the intellectual property. 21:11
Not source control, which is covered by Github.
Coke: Really, I'm asking "do you all want to keep working on the Parrot project?" 21:12
By "you all" I mean "anyone".
Coke: And, I'm hoping the answer is "yes".
I'm hoping there are enough people still interested and motivated to keep working on it that it continues. 21:13
Coke we should at least wait for rurban to show up again. 21:14
rurban I'm here
But I'm busy with p2 and perlcc
allison Coke: oh yeah, it's not a snap thing, it's something for deep thought
rurban I'll take parts of parrot for p2, but current parrot is not practical due to its function call overhead. 21:17
atrodo p2? 21:18
rurban perl11.org/p2/
cotto rurban, is p2 the perl 11 project you mentioned earlier?
rurban a potion (neko, lua) based compiler, vm and runtime
atrodo neat
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.
rurban p6 should be pretty straightforward to target. Much better than the jvm port at least
The parrot GC and threads are top notch. 21:21
perl6 is bitching about it without any clues.
allison rurban: that has been a chronic problem with parrot/perl6 relations 21:23
rurban diakopter and kraih mostly, pmichaud at least is knowledgable 21:24
chromatic was very good recently
rakudo will NOT ditch parrot is the official statement. The need it, if not for bootstrapping 21:25
And the jvm will not help a lot I guess. 21:26
rakudo will then be as fast as niecza, so what 21:27
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
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.
moritz and JIT 21:31
rurban yes
moritz which has been in the works since, when, 2008 or so?
arnsholt JVM is definitely not the last word, AFAICT
allison arnsholt: JVM is a bloated nightmare 21:32
arnsholt: but, it works
rurban parrot has a better GC and threads than JVM at least. It scales linear, without overhead.
allison at the end of the day, being "done" with something bad is better than "not done" with something awesome
(unfortunately)
arnsholt The eternal victory of Worse is Better, yeah 21:33
(Unfortunately, yeah)
moritz well, parrot is still a far way off from being awesome
allison moritz: it's an awesome idea, that's not done
rurban what is missing? signals. async IO is easy to do now.
allison rurban: "easy to do" is not "done"
moritz rurban: JIT compiler, for one.
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.
but, idea != implementation
rurban well, regarding jit I'm sceptical. A fast vm and compiler should outperform jitting overhead.
moritz allison: which part of the parrot idea do you find best?
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
moritz ISTR benchmarks that python, JS and LUA are all faster with JIT than without
allison moritz: again, idea != implementation 21:36
moritz allison: which part of the ideas are you referring to?
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.
atrodo allison++ # I agree, parrot's idea is the best
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
allison moritz: well, GC, Threading, and Unicode are important, but not exactly revolutionary
moritz: those were important ideas in Parrot, only because Perl 5 didn't have them (very well, at the time) 21:37
moritz: the far more interesting ideas developed later
moritz: around dynamic dispatch, and continuation passing style 21:38
moritz: (never fully implemented)
moritz: around concurrency in more of an Erlang style than the JVM monolith style 21:39
moritz allison: if those are the truely interesting ideas behind parrot, it has been marketed quite wrong all those years 21:40
21:40 donaldh joined
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
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
allison moritz: "register based" is part of the dynamic dispatch
moritz: i.e. break away from stacks
moritz allison: sorry, I don't see the connection 21:42
dispatching and calling are (nearly) orthogonal
so I see that register based is related to breaking away from stacks, but not to dynamic dispatch
allison moritz: continuation passing style eliminates stacks 21:43
moritz: you're talking about "dynamic dispatch" in the limited sense of how you look up code objects to invoke?
moritz yes
allison moritz: yes, I meant "a highly dynamic style of dispatch", encompassing a number of features 21:44
including CPS, but not limited to it
moritz: I'm not saying the other features weren't important, they are part of the whole package that makes up Parrot 21:45
moritz: but simply achiving feature parity with other existing VMs doesn't put a project on the map
moritz: and Parrot had some really exciting developments in the whole concept of dynamic VMs 21:46
moritz: but, as you say, they weren't broadcast 21:47
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:48
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
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
allison moritz: that was the theory, yes 21:51
moritz allison: to be fair, it wasn't at first
PerlJam rehashing the past won't change it :)
allison moritz: well, no CPS was introduced to support Ruby
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
moritz: yes, but you still carry the burden of those Parrot features, in overall performance
moritz: which seems a bit silly, since many expensive features in Parrot were introduced for Perl 6 21:53
(like, Parrot's existing object system)
moritz allison: ... and then generalized to others, for which the Perl 6 support suffered
or Perl 6 changed, and parrot refused to follow
allison I don't think it's "refused" so much as "just didn't have time" 21:54
rurban like dyncall instead of libffi?
moritz rurban: no
rurban: I'm thinking of collisions of named arguments, for example
parrot's and Perl 6's world view mismatched, so in the end Rakudo had to implement its own again 21:55
because parrot wanted to support some hypothetical language or compiler to come
allison moritz: again, unfortunate
moritz yes.
allison moritz: is the impasse... unpassable? 21:56
mortiz: seriously, what if the Parrot codebase were chucked at the Rakudo project whole? 21:57
moritz: "here, it's under the same license, do whatever you want with it"
moritz: or, maybe "hypothetically" rather than "seriously"
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.
allison moritz: I think I'm largely playing devils advocate today
cotto of course there's the issue of convincing Rakudo... 21:58
rurban merging would be very good, yes
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
PerlJam Assuming you can get people to hack on Parrot when they're really interested in hacking on Rakudo
allison moritz: as I understand it, you pretty much already are
cotto moritz, it's not so much an issue of Rakudo maintaining Parrot, but being able to iterate more quickly.
allison moritz: just using another VM for a small subset of internal features
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?
cotto If they're merged, the Parrot folks can absorb dyncall without Rakudo necessarily noticing.
allison moritz: Perl 5 is just one
cotto for exampke
*example
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.
cotto ok. 6model 22:01
moritz I'll have to think about the parrot<->rakudo merge a bit more, but I remain skeptical 22:02
PerlJam moritz: me too.
allison moritz: even if the alternative was reimplementing the rakudo project on an entirely different VM?
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)
moritz allison: just list all the major parrot subsystems, and tell me which ones you think are well designed and well executed
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
cotto moritz, if Parrot's purpose is Rakudo, lots of baggage can go away.
moritz calling convention, subs, namespaces, bytecode, OO... *shudder*
PerlJam cotto: and who will do that cleaning work?
rurban moritz: good: gc, threads, io, pmc, ops. bad: call
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?
moritz allison: I have failed to really understand parrot's Unicode model so far
atrodo Playing hypotheticals, what if parrot went a m0-style route and didn't focus at all on keep any existing bits?
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
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
moritz the existing pieces aren't bad, as long as you have ICU
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
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.
cotto It wouldn't generally make things worse for Rakudo if it took a while for developers to gain an interest.
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
it's scary code, which is really why I've never dived in to do anything
allison atrodo: yes, it is scary code 22:09
atrodo: partly, trying to be too many things for too many people
atrodo: partly history
atrodo: growth over time
atrodo: maybe some small part of the complexity is essential 22:10
atrodo allison: Absolutely
22:10 bluescreen joined
cotto atrodo: yes 22:10
allison atrodo: as in, solving a complex problem requires *some* level of code complexity
cotto er, allison
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
atrodo: (or a more tightly focused purpose)
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.
atrodo allison: certainly, it's a complex problem. I've never felt like the code is proportionally complex.
allison: exactly
22:11 davidfetter joined
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)
moritz great to see some new discussions going on here; sadly I have to leave
cotto moritz: thanks for dropping by 22:13
It's been stimulating.
rurban I am in favor to give rakudo full power over parrot.
veto or maint or feature sets
atrodo I would agree as well, unless we can quickly bring more than a couple languages up quickly, focusing on one is best
Coke An interesting project might be to see what can be culled from parrot and still have nqp run atop it. 22:14
having struggled for years trying to bring up another language, I think we might be better off focusing on one.
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.)
PerlJam especially if, by culling, you can get speed improvements :)
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
er, *not been fixed, I guess is better way to say it.
Something to think about. That was kind of the spirit I was trying to rip out PASM in.
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.
allison PerlJam: the current object model in Parrot is certainly sacrificable, it was only added because Rakudo requested it
PerlJam: so if they don't need it anymore, it can go
Coke but, if not, better to have NO object system than an unused one.
(same reason we killed the jit) 22:19
PerlJam yes. quite true.
allison Coke: aye, strip down to basic ability to have pointers to objects
Coke: with no inherent behavior added
Coke So, anyway, that sounds like a nifty side project that I'd like to see where that goes.
But right now, I have to drive througha snowstorm. laters. 22:20
PerlJam Coke: be careful!
atrodo Coke> Good luck!
22:27 davidfetter joined 22:41 pmichaud joined
pmichaud good afternoon, #parrot 22:41
cotto hio pmichaud 22:44
pmichaud someone suggested I read the backscroll and possibly weigh in on the discussion :-) 22:47
cotto I was going to email you a bit later, but that works too. 22:49
pmichaud well, email might be easier for more reflective thought, yes. I might not be able to answer until Sunday though. 22:50
cotto It's not a thought that needs a quick response. 22:51
22:57 Reini joined 22:59 diakopter joined 23:00 Reini1 joined
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:07
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
pmichaud fwiw, I suggested a way through that debate -- prototype some code in parrot threads that emulates what rakudo or Perl 6 would need
so rather than arguing "who's correct" let's see some code that we can evaluate.
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
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
cotto Coke: think of all the snowmen you could be making.
pmichaud rurban: is there an example of how one would use threads to do something like @a >>+<< @b in Perl 6?
not_gerd for what it's worth, these were my thoughts 5 months ago when I stopped working on my m0 prototype: gist.github.com/gerdr/48890726c026588535fa 23:11
Coke not_gerd: seems reasonable.
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:12
rurban pmichaud: You added a ticket for this simple example and I had no time yet to implement it 23:13
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.
try again
Coke diakopter: perhaps provide a subject, a date, or a URL. 23:15
sorear lists.parrot.org/pipermail/parrot-d...hread.html
rurban diakopter: And you are alone with your extreme opinion, sorry. Just don't spread anti-parrot fud publicly
sorear I see nada
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)
diakopter Dec 8.
Coke there's no need for anyone to get upset or snippet.
*snippy
diakopter sorear: did I say it was in February?
cotto Coke: +1
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"?
sorear diakopter: I would assume that if people are going to get upset over something, they should get upset over something recent
rurban I looked a few pages back.
Do you mean lists.parrot.org/pipermail/parrot-d...07296.html maybe? 23:17
Coke the subject is "Re: hybrid threads questions"
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.
diakopter yes.
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?
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.
rurban easy examples how to iterate in parallel or how to update s single external variable need to be written.
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:20
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"
?
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.
rurban that they leak until process end
however I found no leaks whatsoever in my tests 23:23
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
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.
diakopter I'm not allowed to say "but you're putting words in my mouth"? 23:28
rurban twitter.com/diakopter/status/299614785861976064 23:30
twitter.com/kraih/status/299588826924470272
"Parrot threads are basically iThreads again, the JVM is lightyears ahead" pardon, that was years ago. 23:31
diakopter uhm..
pmichaud okay, this discussion has zero value to me, so I'll come back again sometime. Take care, all!
diakopter now you're just embarrassing yourself
pmichaud (less than zero value, actually)
Coke right, same here. you two have fun bitching at each other.
rurban fact is: parrot threads scale linear, and do not block the GC 23:32
sorear *sigh*
rurban I know no other language which can do that.
23:32 rurban left
Coke it would be helpful if examples/threads/alloc_test.pir had notes about what it was testing. 23:32
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:38
allison that digression didn't really answer my question 23:39
which was "what if Rakudo was given total authority to decide what Parrot did?" 23:40
I understand there are differences of opinion on what it currently does.
Coke without tuits, the hypothetical doesn't really matter.
I doubt rakudo is going to spend cycles hacking on VMs when they coudl be hacking on rakudo.
and parrot currently just pissed off it's one developer. 23:41
gah. *its
allison true, parrot features are largely determined by who volunteers to do something
Coke: "parrot" did? "rakudo" did? or something?
Coke #parrot did.
allison ah, yeah 23:42
diakopter just me, not the channel
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
Coke: though he might pick up some code from it (probably that same threads and GC, I'd guess)
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
Coke: not a bad thing, really
Coke: it's a good project, we did good work
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
allison pmichaud: I agree the codebase without developers isn't very useful
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.
Coke (too busy) ah, excellent point.
pmichaud well, "merging them" in this manner pretty much seems equivalent to "Rakudo taking over Parrot" 23:48
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*
allison sorear: from my perspective, not much, it has more to do with closing down the Parrot Foundation
sorear wat
cotto pmichaud: that could well be the case.
allison sorear: which is the ideal time to ask "what's next?"
diakopter allison: does the PaFo have any grant development funds remaining? 23:50
Coke no.
allison diakopter: no
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
allison Coke: we have a bit of funding, plenty to pay down the last debts
Coke: but not grant-worthy
diakopter: PaFo hasn't received any donations in years
cotto apart from gsoc 23:52
Coke and those have been keeping the lights on, yes?
allison yup
Coke examples/threads/moretasks.pir also doesn't seem to end.
allison aye, you need production users to get donations 23:53
23:55 benabik joined
allison While I'm playing the devils advocate... 23:56
If Rakudo doesn't want Parrot, is there interest in converting Parrot into a production-ready Perl 6 interpreter?
no bootstrapping
strip it down to be light and fast 23:57
i.e. serve TimToady, rather than Rakudo 23:58
cotto You mean turn Parrot into a Perl6 implementation rather than a VM for one?
allison yup
cotto My head hurts.
allison :)
that's how it started
it kind of diverged
Coke I suspect that would be more work than being a good target for nqp, but Iunno.
cotto Parsing STD.pm shouldn't be too hard. 23:59
pmichaud Parsing STD.pm implies you have a Perl 6 parser already, though.

Powered by Cro and the Raku® Programming Language.

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

Thank you!