Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3126985 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/parrotsketch/today
Set by moderator on 16 January 2011.
kid51 chromatic: *your* vision 00:00
pmichaud Lorito was first identified in Summer of 2009. It's now 2011. :-)
kid51 pmichaud. Yes, and that means ...
cotto pmichaud, that's why I'm considering a spec and implementation as a hard goal for 3.3 00:01
pmichaud rakudo didn't feel it could wait around for Lorito.
kid51 3. cotto: We really need your outline of Lorito development ASAP
cotto clearly
00:02 bacek_ joined
kid51 pmichaud: Can you post to parrot-dev as I've suggested? 00:02
pmichaud kid51: absolutely
cotto kid51, please do
kid51 Thanks. I really look forward to that.
pmichaud and I'd like to be clear -- I'm impressed with much of the work that Parrot has done over the past year
kid51 Parrot needs to plan its destiny ...
pmichaud it's just that some things are taking a long time, and we (Rakudo / NQP devs) felt we could help faster outside of the Parrot repo than within it. 00:03
kid51 ... but it also needs to listen to its major customers ...
... and it needs >1 major customer.
chromatic It's like Parrot is damned if it does, damned if it doesn't with regard to Rakudo though.
particle is lua a failure? 00:04
chromatic Is Lua used?
particle not as far as i know.
cotto It's eerily stable as far as I've heard.
particle we have a fully-functional, popular hll running on parrot, that's been passing an official test suite for a year or more. 00:05
nobody uses it
why?
because it's slow, and parrot runtime is huge compared to lua runtime
cotto speed, most likely
bacek_ because Parrot is slow
mikehh the same reason pmichaud broght up, speed
sorear perhaps Parrot should think about how it competes with other language development toolkits; iirc the main complaint against the MS DLR was startup time, and we have powerful tools for that
allison size of runtime is key too
chromatic I think the speed issue is partially a red herring.
particle and the parrot dream of hll interoperability has not been realized
and it's not marketed as working. 00:06
chromatic See also damned if you do/don't.
particle chromatic: exactly, i'm illustrating your point.
allison it turns out interoperability isn't a very exciting selling point
chromatic 1. Rakudo/NQP needs somethinig.
2. Rakudo/NQP implements a wad of code.
2a. Rakudo/NQP triggers the deprecation policy somehow.
2b. Rakudo/NQP doesn't run fast.
3. Rakudo/NQP blames Parrot.
3a. Someone (and it's been me a fair few times) optimizes Parrot. 00:07
Now repeat a few times.
Tene particle: I *had* it working over a year ago, and nobody in Parrot cared, and it got trashed and dropped every time I got it working again.
kid51 chromatic: So where do we go from here?
chromatic I would like to see one of those steps be "Try to improve Parrot" to get rid of a big wad of code in NQP/Rakudo.
particle parrot has huge technical debt.
Tene particle: blogs.gurulabs.com/stephen/2009/05/...ading.html 00:08
pmichaud chromatic: isn't that what nqp is recommending?
isn't that _exactly_ what I said above?
particle we are in desperate need of a continuous integration environment to test hll's vs parrot
chromatic Along with "Write another big wad of code that's portable to other VMs."
dukeleto particle: yes, case in point, our huge list of deprecate stuff that has been eligible way too long
particle: i can and have been working towards that
pmichaud I don't follow the "big wad of code portable to other VMs" part. 00:09
dukeleto particle: i talked to OSL and they didn't get our Supercell submission, so I submitted it again
chromatic NQP expects a certain API from any of its backends, right?
pmichaud no.
allison particle: what I found discouraging is that the technical debt is increasing, rather than decreasing. I.e. I vastly improve a system, look back 3 months later and it's worse than when I started.
Tene particle: and, even then, it was a fight and I always felt like nobody else involved in parrot actually cared about hll interop.
dukeleto and for everyone else, Supercell is an initiative where OSL will be running a huge farm of VMs where open source projects can use as build/test/whatever machines 00:10
allison: can you give an example?
particle should i be encouraged or disheartened in that i'm not alone in these feelings?
allison concurrency, multiple-dispatch, etc, etc
(I can dig up specific patch sets, but would take me a while and I'm not sure the effort is really useful.) 00:11
dukeleto allison: no, just a high-level description is fine
allison particle: probably encouraged
kid51 It seems like there are an awful lot of veteran Parrot people here who are very down on Parrot
allison particle: that is, the first step to addressing a problem is acknowledging it :)
pmichaud nqp (the new one) now expects to have to implement compatibility-layer code for whatever backend(s) it targets. 00:12
kid51 ... which doesn't give those of use who are currently active much hope
allison kid51: no, no, don't take it that way at all
kid51 Should we all just walk away?
particle many parrot subsystems have been rewritten and improved over the years. our code coverage is higher than ever. the cycle of broken hll's continues, driving most hll authors away. what problems are we concentrating on fixing, and why? what problems are we blind to?
allison kid51: take it as "learn from our mistakes, instead of repeating them"
sorear particle: your second sentence doesn't sound very much like a problem 00:13
allison particle: that's kind of the whole point of Lorito
particle lorito won't fix the cycle of broken hll's
cotto Tene, my long-term goal is a PHP implementation that can interoperate with other HLLs.
particle it's not a parrot problem, it's a process&infrastructure problem
hell, it's a cultural problem. 00:14
allison particle: well, fixing broken HLLs was the point of the deprecation cycle, but HLLs don't seem to be taking advantage of that
mikehh needs some coffee
allison particle: most of them still follow trunk
pmichaud and at least one HLL has consistently said that the deprecation cycle was a negative, not a benefit :)
dukeleto kid51: parrot veterans have hard-earned negative comments, but they are valuable to new parrot developers, to learn how to not repeat previous mistakes.
cotto Once performance looks like it'll be solved and we have a standard-ish workflow for implementing an HLL (if such a thing exists), that'll be my focus.
Tene cotto: phplens.com/phpeverywhere/?q=node/view/84 is very interesting
back in 2004, rasmus lerdorf wanted to migrate PHP to use parrot.
dukeleto Deprecations as Data will allow us to prove HLL authors with the proper tools to keep their HLLs up to speed. That is my hope, and I plan on making sure that happens. 00:15
cotto I *really* wish we'd been ready.
pmichaud (in counterpoint, the deprecation cycle is now working to rakudo's advantage, now that parrot has stabilized enough that we aren't having to patch it often)
dukeleto s/prove/provide/
allison pmichaud: fair enough. As an example of deprecation cycles that work, see Ubuntu. The guarantee of making things work is met every 6 months. Between those 6 months is the chaos of getting everything to work.
pmichaud allison: I think deprecation cycles work for mature systems. I don't think Parrot qualified at the time. 00:16
allison pmichaud: it's fine to have things break in the chaos, as long as they're fixed
pmichaud: Linux didn't really qualify when Ubuntu started, but they pushed it and now it does
pmichaud still, bridge, water, I'm sorry for bringing it up again.
particle i applaud all parrot contributors for their dedication and enthusiasm. i encourage others to join us in improving parrot. i challenge us to stop repeating yesterday's problems and find new ones.
allison pmichaud: yah, it's okay, it's a place where we're not meeting needs and need to do better 00:17
dukeleto particle: yes, i like that attitude
particle i spoke to rasmus last year. he told me where to shove parrot.
dukeleto particle: lulz
particle we may get buy-in from someone inside php, but it won't be him 00:18
cotto particle, we'll fix that if it's fixable. It's understandable given what we haven't been doing in the meantime.
kid51 particle: Fine as far as it goes ... but we really need the views of veteran developers articulated in blog posts or parrot-dev posts ... not just in online meetings.
allison particle: trust is something you build up over time
kid51 That's what we need for guidance
allison particle: what we've given PHP is a lot of promises, and no follow-through
particle: we're like a bad boyfriend
cotto allison, exactly
particle i know i am....
dukeleto I think Parrot needs to see how Rubinius is a direct competitor to us, and what we can learn from what they do. Hopefully there can be some good cross-polination of ideas. 00:19
chromatic You want to let HLL developers off the hook that easily?
kid51 Right now, most of our activity is internally generated, other than the impetus we get from rakudo.
dukeleto Let's not make promises any more.
Let's write code and add features and tell people when they are done and tested properly.
Is that so hard?
chromatic Yes, it is.
pmichaud chromatic: +1
cotto dukeleto, except ones (roadmap goals) we will keep.
pmichaud look how long it took to replace the gc
long how long it has taken to replace imcc (not done yet)
chromatic We're not going to be able to add the right features in the right way without direct feedback from users as to what they need. 00:20
kid51 .. which is our next topic
chromatic Which we are not getting.
allison to put things in perspective, the android/dalvik code is absolutely horrible
pmichaud we still don't have a good serialization mechanism, 14 months after it was identified
00:20 bacek_ left
particle even phoenix (of rubinius) was parrot-friendly, last i checked 00:20
allison we get too wrapped up in how we're "not good enough yet", but the competition really isn't any better
lucian allison: and to finish that point, targeting android/dalvik is very nice
dukeleto allison: yes, there is always that :)
Tene Almost every time I've seen someone aspire to fix and clean up a broken subsystem, the effort fizzles out and dies after a few months, leaving one or more abandoned branches behind. 00:21
dukeleto Dalvik is chewing gum and duct tape with no security model.
pmichaud Tene: in defense, that has become much less true of late
dukeleto Parrot can soar past it, if we have a few more things figured out.
cotto see also: whiteknight
pmichaud gc has been cleaned up and replaced (October 2010)
Tene Yes, it seems to be going a bit better these days.
dukeleto Tene: that has been much less likely in the age of Git
pmichaud there have some very significant subsystem revamps over the last 6 months
kid51 Friends, we're now 2:21 into this meeting 00:22
dukeleto For better or worse, Git is the wind in our sails, as is GSoC and GCI.
kid51 Time to move it along.
cotto kid51, indeed
dukeleto wrap-up? shall we migrate to #parrot ?
kid51 pmichaud, chromatic, particle, etc.: Can we expect write-ups from you?
pmichaud I'm on the hook for two writeups. 00:23
kid51 We need these on parrot-dev
chromatic I don't know what to write.
pmichaud nqp plans, and what rakudo needs from parrot over the next 3/6/9/12 months
kid51 chromatic: Then respond to pmichaud once he posts.
particle i'm not sure what to write either, but i'll review this log later and see what springs to mind.
kid51 particle: Yes, at the very least, respond to what pmichaud will post
particle i have (as usual) more questions than answers.
pmichaud I should note that in many ways "what rakudo needs" will be repeats of previous posts. 00:24
kid51 Fine, those of us who are more active right now get very immersed in the day-to-day
so we need to hear from those who have the longer perspective.
dukeleto cotto: have we accomplished everything we need in this PDS?
pmichaud I should try to find a way to call out the things of the previous posts that have been achieved, however. That might be harder.
kid51 dukeleto: No we have other agenda items 00:25
particle signs off, exhausted but hopeful
dukeleto kid51: let's move on then
particle parrot++ everyone++
kid51 dukeleto: Thanks
chromatic May I say one last thing?
kid51 Yes, briefly, s.v.p.
Tene Sure.
chromatic Ultimately, I think we're better off migrating things that have made their way into NQP/Rakudo down the stack into Parrot. I wish we'd done more of that before now. 00:26
That's all.
dukeleto chromatic: a list of those things that need migrating would be great for parrot-dev
dukeleto shuts up
kid51 chromatic: I would love to read more about that on parrot-dev
00:26 bacek joined
chromatic You know as much as I do about that now. 00:27
kid51 Now let's move on
As cotto, whiteknight and I have been posting about, we want to discuss Roadmap Items ...
... i.e., those which the project as a whole promises to deliver in a supported release ... 00:28
... and which has a team of developers behind it.
cotto Yes. We have a few of those on the schedule.
kid51 whiteknight posted about his plans for IMCC on parrot-dev
That was the only post that really attempted to be a roadmap item ...
cotto I sent mine to parrot-dev shortly after the start of the meeting.
kid51 ... though a couple from dukeleto I think fall into "Other Goals" 00:29
dukeleto Deprecations as Data. I promise to work on it (already have done a bunch of work) and i think tadzik++ will help as well
kid51 I don't see whiteknight here, but I would like to get feedback on the IMCC proposal now.
dukeleto whiteknight is not present
kid51 dukeleto: Okay, If we can get a team, then it qualifies as roadmap-eligible.
tadzik dukeleto: as soon as my exam session ends, well or not, I'm all Parrots
kid51 dukeleto: true, I don't know where he is.
dukeleto kid51: there is a branch sitting there, with a parrot-dev email describing it 00:30
cotto tadzik, I'm looking forward to your work there.
kid51 But he did the writeup, so I would like to hear about IMCC.
dukeleto kid51: it improves the way we handle experimental and deprecated features drastically
it will allow us to provide tools, which will make it as simple as possible to learn about deprecations 00:31
cotto and deal with the more programatically
dukeleto one issue that i have is we *delete* stuff from a file, instead of moving it into another file, such as old_api 00:32
we need to keep all deprecations/experimental stuff that has ever existed in a file, not in our git history
because if we get rid of a deprecated feature and delete it from the YAML file, it doesn't help Bob HLL author the next month to figure out why his HLL doesn't compile
cotto We can keep the most current data at the beginning of the file. 00:33
dukeleto does anybody have feedback about the IMCC branches that we need to talk about?
cotto: so much easier to have 2 files, one for previous, one for current 00:34
00:34 bacek left
dukeleto cotto: but the implementation details don't matter so muc 00:34
much, as long as Alice can figure out why her HLL doesn't compile on the latest parrot
cotto one we have something in place to play with, we can use it and see how it works in practive 00:35
dukeleto that is all, any other discussion can be added to the DaD thread on parrot-dev
cotto: we have something
cotto: it is called leto/deprecations_as_data :) 00:36
cotto: when i merge to master, i have to deal with various stuff being deleted from DEPRECATED.yaml
kid51 dukeleto: In terms of making this a roadmap goal ...
dukeleto cotto: and i want to add those to a seperate file, like docs/changes/old_api.yaml
kid51 ... what is the objective for 3.3? ... and who are the team members?
dukeleto kid51: roadmap goal : Review leto/deprecations_as_data and merge it if it is wanted 00:37
kid51: i would prefer that to happen before 3.1
kid51: i.e. ASAP
i see getting a prototype of Lorito that does 1 thing well as a good goal for 3.3
cotto I hope to have it sooner, but you know how that goes. 00:38
kid51 Well, if it's something we're going to do within a couple of weeks, I don't think we need to list it as a roadmap goal. We should JFDI
Roadmap goals should be those that require more effort from more developers, IMO 00:39
dukeleto kid51: no, i disagree 00:40
kid51: we need at least 2 serious reviews of my branch to make sure it is a good way forward
cotto We can make it a goal to get some infrastructure around it too.
dukeleto kid51: my branch is the tip of the iceberg, it just provides enough data to make other things possible 00:41
nothing wrong with small roadmap items
it will boost our esteem to actually complete a few on time...
kid51 Alright, I'll let cotto make the call on that. (I don't disagree with the content, I should emphasize.) 00:42
cotto I'm fine with them.
dukeleto more roadmap items?
kid51 IMCC
dukeleto death to IMCC
cotto as long as we're not primarily promising small things.
kid51 Even in Andrew's absence, I want to hear some feedback on his post.
dukeleto kid51: he is doing awesome stuff and we should all stand back and push him forward 00:43
kid51 tinyurl.com/4lz25ge
dukeleto: I agree that it's awesome, but the idea of a *roadmap* goal is that it's not a one-person effort
dukeleto Fixing IMCC does not provide Parrot users with anything shiny to hold in their hands.
kid51 If it's on the roadmap, the Parrot project is publicly pledging to get it done 00:44
dukeleto I want to remove IMCC, but that needs to be taken into account.
kid51: yes, i understand that.
kid51: which is why i am not pledging anything regarding it
kid51: because i know nothing about it and prefer to keep it that way
cotto dukeleto, I don't entirely agree. It means that our core compiler is using the same interface that any other one will be using.
dukeleto cotto: don't agree with what? 00:45
who else wants to promise to work on IMCC with whiteknight?
cotto that it's not something that we can point out to users as a benefit
I'll work with him on that.
dukeleto cotto: i hear what you are saying, but it is a hard sell, believe me. 00:46
cotto dukeleto, yeah
dukeleto "fixing our internals" isn't the same as "we have this cool new application/language/spacerocket"
00:46 bacek joined
dukeleto of course it is necessary, but it doesn't excite our users 00:46
we need to understand that
kid51 I believe that whiteknight has spoken with plobsing about working on the IMCC project ... but I can't presume to speak for plobsing 00:47
The one piece missing from Andrew's post was ... team members ...
mikehh fixing our internals is what will help improve and speed up parrot
kid51 ... which is essential because it's too big for one person and we can't have a bus factor of 1 on this.
mikehh which will ultimately help our users 00:48
chromatic I have an interest in helping with IMCC.
kid51 Also, it's not clear what's deliverable by 3.3 (April) and what comes later.
dukeleto mikehh: you are preaching to the choir :)
kid51 chromatic: Do you have any thoughts about andrew;'s post?
chromatic I haven't read it in sufficient detail.
dukeleto we have at least 3 IMCC warriors, make it a roadmap item, next?
dukeleto needs to leave soon
kid51 I will follow up with whiteknight. 00:49
Tene fwiw, I'm much more hopeful about parrot after this meeting.
pmichaud my concern is that since imcc is _the_ only mechanism presently available for writing Parrot code, it needs kid gloves in its replacement. But I trust the current team enough to see that this happens properly.
kid51 chromatic: Can you post any response to Andrew's, particularly to indicate any part you'd like to work on?
pmichaud There have been notable successes from the team on such issues in the recent past.
chromatic I'll coordinate with him on that.
kid51 cotto: Same thing: Can you respond to whiteknight to claim a piece of the action? 00:50
cotto yes
kid51 Good, then we can move on
Were there any other items that merited consideration as Roadmap Items?
(I don't think there were, but just askikng. 00:51
asking)
cotto the Lorito planning
kid51 Speak to it.
00:51 bacek left
kid51 lists.parrot.org/pipermail/parrot-d...05400.html 00:51
cotto The goal is to turn all the discussion of Lorito into something that's runnable by the 3.3 release. 00:52
atrodo, dukeleto and I are on board, though others are welcome
kid51 runnable in what sense?
dukeleto cotto++
cotto kid51, you can pass a script or bytecode to an interp and it'll run fib or a similar demo
kid51 Ah! A concrete goal at last! 00:53
dukeleto are we done?
cotto the goal is demos for hashes, arrays, functions and structs
pmichaud I would love to see NQP be able to target a Lorito :-)
cotto pmichaud, me too
dukeleto pmichaud: that is the plan, but i am not sure we can do that by 3.3, but it sure would be nice 00:54
kid51 Okay: We have a concrete goal, a team, a team leader. It qualifies.
pmichaud nqp on lorito by 3.3 isn't likely. by 3.6 might be possible.
kid51 pmichaud: Add to cotto's post what you would particularly like by 3.3/3.6.
cotto The roadmap goal is to have M0 by 3.3. Something that nqp can run on will happen after that.
kid51 Any other goals which ought to merit Roadmap status? 00:55
pmichaud what I would particularly like is "running code" :-)
00:55 bacek_ joined
dukeleto +1 to that, cotto++ 00:55
pmichaud doesn't have to be correct or final... just anything that shows the direction things are headed :)
cotto jfdi++
dukeleto kid51: i don't think we should promise anything else for 3.3
pmichaud (so cotto++'s goal is exactly on target)
dukeleto jfdi++
kid51 If not, then does anyone wish to present goals that they themselves as individuals are working on?
Things that we can wish for and look forward to, but don't have to publicly pledge to deliver. Any thing? 00:56
dukeleto is futzing with Javascript on Parrot called Jaspers github.com/leto/jaspers and will be making PL/Perl6 run on a modern Rakudo
kid51 dukeleto: Yes that's exactly the sort of thing I was looking for 00:57
dukeleto and trying to get IPv6 people interested in Parrot
bacek_ cotto, do we have "M0 ops" defined somewhere?
dukeleto has submitted some PL/Perl6 talks and will submit a few more Parrot-related talks to various confs
bacek_: yes, in atrodo's repo
kid51 dukeleto++
chromatic How about removing deprecations, as always?
dukeleto bacek_: he has really good docs
chromatic: i want that to be our next weekly dev focus 00:58
chromatic: get rid of old deprecated junk
chromatic: there is a lot of LHF
chromatic Huge amounts.
kid51 has Individual/Non-roadmap goals:
dukeleto bacek_: the docs in atrodo's repo are 95% exactly the same as what M0 ops are planned
bacek_ dukeleto, looking. 00:59
mikehh if you are going to do anything for 3.1 it need to be done within 1 week
kid51 1. Convene Python developers to work on Parrot implementation (looks like it started today)
00:59 allison left
kid51 2. Work with other devs to develop a "canned slide show" that anyone could run to get a 10-minute exposure to current state of Parrot VM. 00:59
dukeleto kid51: also, i am finishing my TPF grant to properly document and test our current embed API. 01:00
kid51 3. Similar: 10-minute video about Parrot for You Tube, updatable quarterly. (but I know nothing about videos or You Tube)
01:01 nwellnhof left
pmichaud (I have to run off to dinner -- thanks all for coming and listening!) 01:01
kid51 bacek, mikehh, others: Are there things you expect to work on in next 3 months?
dukeleto I hope bacek will continue hacking on PAST/POST/PIRATE stuff, which is very important. Also, whatever else he wants to hack on :) 01:02
bacek_ kid51, I don't know exactly how much time I can spend in next 6-12 month... 01:03
dukeleto, PIRATE is _less_ important now with new nqp coming.
kid51 bacek_: Where do you expect to concentrate? Where can you use help?
dukeleto bacek_: whatever you say, boss
bacek_ kid51, PBC emitting from "newPOST"; Lorito; May be GenGC 01:04
kid51 bacek_: Would there be things in your domain that could be formulated as GSOC projects?
bacek_ kid51, not really. May be GenGC?
dukeleto bacek_: i implore you, please try to delegate low-hanging fruit :)
bacek_: what is the most important thing you will concentrate on between now and 3.3 ? 01:05
bacek_ dukeleto, "Implement Lorito as totally separate project"
dukeleto, partially joking.
dukeleto bacek_: lulz
mikehh If I get time I want to review aspects of the test suite, like skips that can become todos etc
kid51 mikehh: Yes, that would be very valuable. 01:06
dukeleto mikehh: also, writing docs for how you do smoke testing would be useful
kid51 mikehh: You can probably carve off a piece of that for me.
mikehh dukeleto: that's also on my TODO list :-}
dukeleto mikehh: and we don't really have an updated "how to write parrot tests" guide, either. Making sure your knowledge is written down somewhere is very important 01:07
mikehh: awesome!
dukeleto will be ejecting very soon to eat dinner with a loved one
but I am very excited about all the things that were talked about at PDS today.
mikehh I also thionk we need updated docs on what is needed to run parrot 01:08
dukeleto bacek_: you just keep being the magic Loki coding robot :)
kid51 So, let me summarize: We have 3 roadmap-level action items: deprecations-as-data, IMCC removal, lorito development
Is that correct?
dukeleto mikehh: yeps. if you send an email to parrot-dev about that, i will add my opinions
mikehh i.e. perl and library dependencies
dukeleto kid51: i think "IMCC removal" needs to be "IMCC isolation" 01:09
kid51: it will become optional instead of mandatory
kid51 One other action item, GSOC planning, has already been initiated by mikehh
dukeleto: noted
cotto kid51, sounds good with that modification
dukeleto I expect DaD to be done by 3.1 or not done at all.
kid51 the other non-roadmap action item is to get whiteknight to write summary post about embedding
cotto I'd call it "M0 spec and prototype" though
sorear Will we have a "parrot-pir" executable in the near future? 01:10
kid51 dukeleto: If it's on the roadmap, it will be done!
dukeleto sorear: we can if that is wanted. Should be pretty trivial
01:10 whiteknight joined
cotto whiteknight, welcome 01:10
kid51 Well, look who's here!
mikehh yey whiteknight
dukeleto oh my. A second wave.
kid51 whiteknight: You got a lot of backscrolling to do ;-)
cotto we were just saying how much we all loved imcc 01:11
dukeleto whiteknight: everyone would like to hear about IMCC, and I will read the logs :)
whiteknight sorry I'm late
dukeleto whiteknight: you have any timelines for how long it will take to isolate IMCC?
whiteknight: i.e. to make it non-mandatory ? 01:12
kid51 whiteknight: See backscroll for those who have volunteered to be part of IMCC-isolation team.
cotto for one
dukeleto whiteknight: you have at least 3 IMCC warriors
whiteknight bleeding-edge work is being done in the imcc_compreg_pmc branch. When that branch is ready, IMCC will be 95% isolated and removed
dukeleto whiteknight: but we don't know enough info to make timeline decisions about it
kid51 We will need to know: Who else is working on this? What's deliverable by 3.3 and what by 3.6?
whiteknight at that point, we need some makefile changes to compile it into a separate library
kid51 whiteknight: We have asked pmichaud et al to share their thoughts on the IMCC work (via parrot-dev) 01:13
bacek_ dukeleto, small whinge about deprecation_as_data - why yaml? It's awful format. JSON is much better from my point of view
kid51 whiteknight: And we could use a summary post on parrot-dev about the embedding API work.
whiteknight embedding API is in and done prior to 3.0, there's nothing else really to say about it 01:14
dukeleto bacek_: YAML is more easy to edit as a human
bacek_: you are not human
bacek_: >:)
bacek_ dukeleto, it's much harder to parse it.
dukeleto bacek_: we can provide a copy in json if you really want
kid51 whiteknight: I think a post that points people to the particular files/docs in the distro which embody the embedding work would be helpful
bacek_ And main audience for "deprecated.yaml" is some other tools 01:15
dukeleto bacek_: we use YAML.pm right now, end of problem. If we want to dogfood, we write a good YAML parser.
bacek_: yes, i wrote the first tools for it, and they were very simple to write :)
bacek_ dukeleto, it's almost impossible to write 100% correct YAML parser.
sorear dukeleto: please do not write another YAML parser. All the existing parsers are incompatible
dukeleto cotto++ wanted YAML, so I changed it from JSON to YAML. I don't really care. 01:16
cotto I don't either, as long as the format is amenable to writing documentation.
dukeleto YAML is easier to edit as a human. We don't care about incompatible YAML parsers
we are parsing brain-dead simple YAML
cotto YAML seemed nicer, but I don't appear to know what bacek_ and sorear do.
dukeleto we aren't doing anything fancy or using extended features of some particular YAML parser
mikehh at the moment our make html is based on JSON 01:17
bacek_ cotto, I did read "yaml spec". It's about order of magnitude more complex than XML + XMLNamespace
cotto mikehh, it's not a bad format for that.
sorear as long as our YAML is all hand-written it's possible to ensure that it works the same on all parsers
cotto mikehh, it has relatively simple needs.
sorear, we can even have a test 01:18
sorear but in general, machine-generated YAML from library A is not readable with library B
dukeleto sorear: yes, but that is not our problem
cotto but that's a concern
sorear there are subtle differences with quoting, etc
dukeleto sorear: we have human-written YAML in the subset of YAML that all parsers like the taste of
sorear: these issues are interesting, but don't concern us. We can change the format if we want. But we need the data in a usuable format, now. 01:19
whiteknight kid51: Sure thing. I'll post a recap about it somewhere
cotto If we can make something that widely-used parsers can deal with without bending over backwards, I'm happy.
bacek_ cotto, any json parser will parse any json file :)
sorear also, this isn't like a programming language decision
if we change our data format, we can recode the file with almost 0 effort 01:20
bacek_ cotto, just because json is small
dukeleto i think IMCC is more important to talk about
bacek_ and we already have json parser in parrot (speaking of dog food)
sorear listens at dukeleto
cotto bacek_, json isn't great for writing documentation though. I'm picturing writing the stuff in trac.parrot.org/parrot/wiki/ParrotD...ionsFor3.0 in a json file and not liking the idea. 01:21
dukeleto bacek_: please send your concerns as a reply to my thread on parrot-dev
dukeleto ejects
sorear dukeleto: not wanting to talk about IMCC?
cotto sorear, he has to leave 01:22
bacek_ sigh... I don't like atrodo's lorito. 01:25
Basically it's JVM
cotto bacek_, it's an exploratory prototype.
whiteknight okay, looks like we're all over the place right now. What are we talking about?
01:25 kid51 is now known as kid51_at_dinner
bacek_ stack based, single byte opcode, etc. 01:25
cotto We're not constrained to use it as long as we learn from it. 01:26
bacek_ whiteknight, world domination
whiteknight, and pony
cotto, we can just implement "PIR" on top of LuaVM 01:27
not jocking at all
cotto That's worth exploring.
bacek_ luaforge.net/docman/index.php?group...guage_id=1 01:28
A No-Frills Introduction to Lua 5.0.2 VM Instructions (latest; 20060221)
01:28 chromatic left
bacek_ Replace "table" with "PMC" in this PDF and it's what Lorito about. 01:29
cotto This is more #parrot discussion though. It seems the meeting's about over.
bacek_ ok 01:30
cotto Any other PDS topics?
mikehh how far did we get with roadmap items for later 01:31
just for 3.3
cotto We're just doing 3.3 for now according to my understanding. 01:32
mikehh 'k
looking at earlier discussions here and on parrot wrt rakudo, I think we really need to develop better liason there 01:34
obviously we need to consider other HLL's but in essence rakudo is still our main customer 01:35
or should I say nqp and rakudo 01:36
01:36 plobsing joined
sorear I would say nqp/pct 01:38
mikehh I think chromatic's proposals on parrot should seriously be taken into account 01:39
02:11 bacek_ left 02:34 lucian left 02:37 bacek joined 02:49 kid51_at_dinner is now known as kid51 03:38 dukeleto left 03:40 whiteknight left 04:02 kid51 left 04:14 cxreg joined 04:18 plobsing left 06:50 allison joined 07:05 allison left 07:07 allison joined 09:04 allison_ joined, allison left 09:48 contingencyplan left 10:45 sheant joined 11:47 whiteknight joined 12:43 sheant left 13:35 kid51 joined 13:52 sheant joined 13:56 whiteknight left 14:01 kid51 left 17:25 kid51 joined 17:42 tadzik left 17:44 tadzik joined 18:45 contingencyplan joined 19:20 kid51 left 20:51 tadzik left 22:46 whiteknight joined 23:08 sheant left

Powered by Cro and the Raku® Programming Language.

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

Thank you!