Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-12-06

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

All times shown according to UTC.

Time Nick Message
00:00 cotto one or two at a time we can handle
00:00 chromatic whiteknight's API work is a good time to update the API PDD.
00:00 whiteknight and a quarterly PDS meeting gives us plenty of time to prepare
00:00 chromatic It would be nice to have a single document which gives a good philosophical and design overview of a subsystem.
00:00 whiteknight chromatic: assuming there is community support to keep and merge my work, yes
00:00 whiteknight it is a pretty radical change with unilateral design vision
00:00 chromatic Assuming so.
00:01 nwellnhof do we need PDDs at all? shouldn't we simply have one single documentation?
00:01 whiteknight nwellnof: good question. The Perl6 people might suggest that design before implementation is a good thing
00:01 whiteknight assuming we implement for the design
00:01 chromatic Maybe we can retire the concept that the PDD is the design artifact created before any implementation.
00:01 cotto The design docs are helpful when they work.
00:01 cotto chromatic, +1
00:01 whiteknight having something written to inform the decisions of developers is always beneficial
00:02 particle specs are important.  see perl5 for the anti-pattern.
00:02 whiteknight whether it's worth the effort to prepare beforehand is the question
00:02 mikehh I think we still need design docs
00:02 particle hell, see imcc for an anti-pattern.
00:02 whiteknight but again, if we tackle one or two at a time when they are most relevant, we can really make use of them
00:02 chromatic Perl 5 and IMCC have the anti-pattern of "Whatever exists now you may use and we will support it."
00:02 mikehh like: this is what we want to do, then this is what we have done, etc
00:03 lucian what confused me at first was that PDDs aren't marked for up-to-date-ness or implementation
00:03 chromatic That's very different from "Thou shalt document what you will do and ratify the document before writing a line of code>"
00:03 kid51 lucian: I agree.
00:03 kid51 I started to re-read the PDDs in September after whiteknight started to rant about them.
00:04 kid51 but it was very difficult to determine which aspects of the design had been implemented, which abandoned, etc.
00:04 whiteknight exactly
00:04 atrodo i've wondered if the PDDs are too broad and all encompassing
00:04 whiteknight they have no real bearing on reality
00:04 plobsing they feel like armchair design to me
00:04 kid51 Are there parts of Parrot that are stable enough that we could write a "this is what we have designed" doc?
00:04 whiteknight if you have to flip a coin to determine whether each statement is true or false, the docs are worthless
00:04 * lucian likes python PEPs
00:04 mikehh we definately need to re-structure them so that they do reflect reality
00:05 whiteknight yes, the PEPs are nice
00:05 Util Plans are worthless, but planning is everything. -- D.D.Eisenhower
00:05 chromatic I want to read something that says "Here's what this subsystem tries to do.  Here are the assumptions we make.  Here are consistent design elements.  Here's how we structured the code."
00:05 whiteknight each is smaller, more focused, more up-to-date
00:05 particle plobsing: the io pdd was designed at the same time as the tests for the io subsystem
00:06 particle so there was a spec and tests, ready and waiting for the implementor.
00:07 mikehh I think that is the approach we need to work on
00:07 chromatic I have my doubts that that spec/tests first approach is viable.
00:08 mikehh that is if we are following a TDD approach
00:08 atrodo That approach is good if you want to rewrite a lot of docs and tests.  not saying it's a bad thing but
00:08 particle i don't think it's viable now, but hand-in-hand approach for docs/tests is valuable
00:08 whiteknight The problem with our tests as they are now, is that they were all designed with the assumption that PIR was the star of the show and would always be a central part of Parrot
00:09 whiteknight now we're looking for any opportunities to rip out PIR, but all the tests assume we have it and that it is lord
00:09 particle pir was the star of the show, and a big improvement over perl5
00:09 chromatic I suggest tabling *that* discussion while we talk about PDDs.
00:09 particle aye.
00:09 whiteknight particle: yes, no question that it was good for a while
00:09 whiteknight but now it's clearly not the direction we want to keep going in
00:09 cotto Is anyone willing to update PDD0, which describes the PDDs?
00:09 particle i have three words for that: GCI
00:10 particle (for whiteknight, not cotto)
00:10 chromatic How would we update PDD 0?
00:10 chromatic What do we want out of PDDs?
00:10 cotto yes
00:10 * kid51 is confused:  In what sense is PIR going away (before I've ever learned it)?
00:10 particle reference docs for our next book.
00:11 chromatic Reference docs for users, embedders, hackers, language developers, or ... ?
00:11 kid51 Well, maybe someone could blog about that.  BAck to discussion about PDDs.
00:13 nwellnhof if you have a look at http://docs.parrot.org/parrot/latest/html/
00:13 nwellnhof say, you want to find docs about strings or IO, for example...
00:14 nwellnhof you have to look at the PDDs, the PMC docs, the developer docs...
00:14 nwellnhof that should be more centralized IMO.
00:14 whiteknight kid51: I
00:14 whiteknight 'll blog about PIR
00:14 whiteknight and I'll try to avoid curse words
00:14 whiteknight ...actually, no. I make no promises about the verbiage
00:15 cotto +1
00:16 atrodo nwellnhof> I had exactly that problem when trying to decypher how to embed parrot.  And most of the time, reading the headers or code was a better, more centralized refrence
00:16 kid51 Given my hope that we become more focused on Parrot as usable product, the documentation I would most like to see is:  "This is our API; use it."
00:16 dukeleto kid51: PIR is not going away, but the implementation of PIR will change
00:17 dukeleto kid51: IMCC is on a death bed, PIRC is the new implementation
00:17 cotto *cough*PIRATE*cough*
00:17 kid51 PIRC?  Didn't we just expel it?  Is anyone working on its?
00:17 dukeleto kid51: expel? It got it's own repo
00:17 dukeleto PIRATE is what I meant. Sorry
00:17 * dukeleto gets PIRC and PIRATE confused
00:18 cotto with hilarious results
00:18 kid51 Do we have any document or blog post that gives an overview of PIRATE?
00:18 kid51 Who is working on PIRATE?
00:18 kid51 Which team?
00:18 cotto I have enough familiarity with it to blog about it.
00:18 dukeleto kid51: no team is devoted to it
00:18 particle what's pirate?
00:18 dukeleto kid51: bacek was caring for it, but he has been concentrating on the GC
00:18 Util The work to replace IMCC is being done from a separate repo to boost visibility.
00:19 chromatic This is what I'd like PDDs to become: <kid51> Do we have any document or blog post that gives an overview of PIRATE?
00:19 dukeleto particle: PIR compiler using nqp-rx
00:19 * kid51 learns something new every day ;-)
00:19 cotto I've had a hand in it too.
00:19 Util Soon we will need a diagram filled with boot straps.
00:19 particle right. i keep forgetting what it is, since pirate used to be a python impl on parrot 0.0*
00:19 cotto I think it's just us two.
00:20 cotto particle, yes.  I'm glad the name is getting a new life.
00:20 kid51 So, cotto, in terms of resource allocation:  What's your focus among Lorito, MOP, PDDs and Pirate?
00:20 * dukeleto has a commit bit to PIRATE, but hasn't done anything useful
00:20 atrodo \
00:20 kid51 or, what should be *our* focus?
00:20 atrodo (sorry)
00:21 dukeleto IMHO: MOP, Lorito, Pirate, PDDs is the order of importance
00:21 cotto dukeleto, yes ( though the mop only came to the forefront relatively recently)
00:21 dukeleto Our MOP changes will dictate Lorito changes, so we should work on MOP first to minimize changing a bunch of stuff unnecessarily
00:21 cotto and the PDDs can be interspersed
00:22 kid51 (and add Garbage Collection to that list)
00:22 dukeleto cotto: it has been a blocker for a long time, but we only recently have decided to do something about it
00:22 cotto dukeleto, I'll be digging into nom as much as I can and will have that in mind while working out Lorito's design.
00:22 dukeleto cotto: awesome. We can compare notes.
00:23 dukeleto Lorito and our new MOP will have interaction and they will not be worked on in insolate.
00:23 lucian i also think MOP is important. the main selling point of parrot is language interop
00:23 cotto it'll be fun
00:23 dukeleto isolation, rather.
00:23 diakopter cotto: at the top you mentioned you'd powpow with chromatic and allison to extract braindumps of lorito. do you have an idea of when that'll occur?
00:23 kid51 cotto: Can you describe what will be your main focus between now and, say, end of january?
00:24 dukeleto kid51: I think each parrot team needs it's own focus
00:24 kid51 Agreed. Wondering what the Architecture and Design Team's will be.
00:24 cotto 1) getting Lorito into an iterable state 2)understanding the MOP and how it'll work on Lorito 3)learning other parrot subsystems (and blogging)
00:25 cotto diakopter, we're meeting this week
00:26 cotto There may be other priorities.  there's a good reason I use the wiki for external memory.
00:26 * kid51 notes that we're about 90 minutes into the meeting -- and still have 2 pre-scheduled issues to discuss
00:27 dukeleto shall we move to the next issues?
00:27 cotto sure
00:28 kid51 The 2 pre-scheduled issues are API and 2011 summits.  Which first?
00:28 chromatic summits will likely be shorter and faster
00:29 kid51 So here's the gist of my proposal
00:29 kid51 Quarterly summits, held on the 2nd weekend after each supported release.
00:29 kid51 which works out to last weekends of January April July October
00:30 cotto We should check that those don't coincide with important conferences.
00:30 kid51 Exact time within a given weekend to be worked out in preceding month.
00:30 kid51 Rotate start time among quarterly summits so that people in time zone X aren't unnecessarily inconvenienced
00:31 kid51 Pre-schedule certain issues for discussion.  Example:  API for today.  GSOC 2011 plan for January.  MOP plan for January (?)
00:31 dukeleto +1 to rotating times. That is a *great* idea.
00:31 kid51 That's the gist
00:31 cotto I'd rather try to use doodle and find something minimally inconvenient.
00:31 kid51 cotto:  Do you agree about the quarterly scheduling?
00:32 dukeleto kid51: can we count on you to organize these PDS's? You seem to be the most organized.
00:32 cotto yes
00:32 kid51 yes
00:32 dukeleto Awesome.
00:32 kid51 Does anyone have an alternative vision of the "gist"?
00:33 particle please don't rely on one person for this.  use group calendaring, task lists, and wiki pages for organizing.
00:33 particle and mailing lists.
00:33 dukeleto Next topic?
00:33 kid51 particle:  I will use all those means.  I will recruit deputies.  Can I deputize you?
00:33 particle aye.
00:33 kid51 next topic:  Whiteknight on API
00:33 whiteknight perfect timing
00:34 dukeleto particle: we use doodle to figure out a time, and try to share the burden.
00:34 dukeleto whiteknight++ on his embed API write up.
00:34 whiteknight a few days ago I sent out an email about the current status of the API to the list. I hope most people read i
00:34 whiteknight it
00:34 cotto very helpful
00:34 kid51 I liked it, though understood only parts
00:34 whiteknight The new API represents a lot of work but as I mentioned before it was entirely designed by myself so I want a lot of feedback before we start talking about merge or whatever else
00:35 kid51 and we'll need a lot of testing on all major OSes
00:35 whiteknight the embed_api2 branch is seeing some failures on darwin especially, but otherwise all primary development is complete
00:35 Util I like everything I read in the document, but need to spend time with the code.
00:35 kid51 "We should really be thinking about Parrot as two parts: libparrot (a language-agnostic bytecode interpreter and runtime) and the Parrot executable (the IMCC PIR/PASM front-end for libparrot). The Parrot executable now embeds libparrot using the new embedding API. And if the Parrot executable can do it, anybody else can too."
00:35 * dukeleto queues up another topic: Parrot on Mobile platforms
00:35 kid51 good
00:36 Util +1 to the redesign of the embedded API, especially the libparrot/frontend separation.
00:36 Util Gentle reminder: Embed/Extend APIs are particularly needy of quality documentation, since their users will often have zero background in Parrot internals.
00:36 cotto dukeleto, queued
00:36 Util Q: Does the "die_from_exception" change mean that pbc_to_exe should start including code to dissect the Exception and dump its info to STDERR?
00:36 whiteknight Util: yes, spending time with the code is a very good idea. It is a very different API from what we used to expose
00:36 cotto i.e. useful
00:36 whiteknight Util: yes. I did add a basic implementatin to pbc_to_exe in the branch as an example
00:36 whiteknight but it probably needs to be improved. src/main.c is my flagship tester
00:37 Util thx, will check both
00:38 chromatic Does this allow us to use PARROT_API liberally?
00:38 chromatic Does this allow us to remove several uses of PARROT_EXPORT?
00:38 dukeleto whiteknight: perhaps i can create a branch of PL/Parrot to use the new embed api?
00:38 kid51 whiteknight:  Does your team have a timeframe for its development?
00:38 dukeleto whiteknight: so we can actually have rubber hitting the road?
00:39 dukeleto Util: i have a TPF grant to write embedding docs and increase test coverage to 95%. I am on it.
00:39 Util dukeleto++
00:39 whiteknight kid51: like I said, primary development of the first wave is complete.
00:39 whiteknight I would like to get it mergable by 3.0 if everybody likes it
00:39 whiteknight there shouldn't be any deprecation issues
00:41 whiteknight chromatic: I'm reserving PARROT_API for the API in src/embed/*
00:41 kid51 whiteknight Can you describe the extent to which this work has been a team effort?
00:41 whiteknight I can use a different designator if we need to reuse that one.
00:41 whiteknight PARROT_EXPORT is for all other symbol exports (like the extending API)
00:43 kid51 Anything else on API?
00:44 chromatic What changes do Rakudo need?
00:44 dukeleto kid51: it has mostly been whiteknight and bluescreen, from what I can see
00:45 dukeleto kid51: i have been looking on from the sidelines
00:45 kid51 dukeleto:  That's my impression.  Just trying to gauge whether concept of 'team' is working at all or not?
00:45 kid51 chromatic: Other than jnthn, I don't see any Rakudo folks here.
00:46 dukeleto kid51: a team of 2, it seems
00:46 kid51 which, to be frank, is better than we usually do
00:46 chromatic I meant Rakudo changes from the API changes.
00:46 dukeleto What rakudo seems to need more nowadays is consisten speed improvements.
00:47 kid51 chromatic:  Well, then, I guess the question becomes:  At what point does the new API have a form and docs we can present to Rakudo for feedback?
00:48 dukeleto We will keep Rakudo well informed of any API changes.
00:48 bluescreen_ kid51: From a newcomer standpoint teams was the perfect approach... as you have somebody mentoring you.. .otherwise the gap it too high
00:48 diakopter was the "random segfault when rakudo spectest" issue resolved?
00:48 kid51 bluescreen_:  Very good feedback!
00:48 cotto bluescreen_, yes.
00:50 whiteknight the teams approach is working well, but you don't have a team form out of thin air. People have to volunteer and have the time to work on things
00:50 whiteknight so several people were interested in the embedding work, but were busy or had other parrt things to work on
00:50 whiteknight and that's fine, but we had a team of 2 and got a lot of good work done
00:50 bluescreen_ specially and this is something i want to bring up.. is the fact that is hard to grab a ticket from Trac... since there are a bunch of invalid tickets out there
00:51 whiteknight A team may mean 1 or 2 people , so we need to allow for that
00:51 kid51 invalid? in what sense?
00:52 bluescreen_ meaning that the either were already fixed, deprecated or things we won't implement
00:52 mikehh I'll accept 2 for a team, 1 is a bit of a problem
00:52 dukeleto Many trac tickets are old and have not been updated in so long as to be useless.
00:52 whiteknight mikehh: 1 is a "potential team"
00:52 whiteknight the important part is that you plan to make it easy for more people to get involved
00:53 mikehh whiteknight: 'k, I'll go for that
00:53 whiteknight if the team leader creates some low-hanging fruit, people may come latch on to them
00:53 dukeleto I think we need to organize a culling of old Trac tickets, but that is a topic for another time.
00:53 * dukeleto will need to go AFK soon
00:53 kid51 bluescreen_ I'm not surprised, but perhaps after whiteknight is done with you I can guide you in the "art of cage cleaning" ;-)
00:53 whiteknight dukeleto: good idea. The trac ticket queue is unmanagably large
00:53 bluescreen_ kid51 ;)
00:54 whiteknight and it is filled with crufty tickets that don't lead to any work being done
00:54 mikehh The art of getting rid of invalid Trac tickets
00:55 chromatic Are we under 600 now?
00:55 kid51 Yes
00:55 cotto it's not low enough
00:56 cotto better but not good
00:56 chromatic That's good progress from earlier this year though.  We've improved our velocity as of late and reduced our ticket count.
00:56 tcurtis left #parrotsketch
00:56 kid51 Perhaps I could develop a proposal for a Cage Cleaning Week in which everyone suspends their "regular" Parrot work and focuses on tickets.
00:56 kid51 A once-a-year clearance sale!
00:57 cotto We should ticket validity criteria.  Otherwise it'll be too subjective and we'll all worry about stepping on other people's toes.
00:57 dukeleto My philosophy: if a ticket looks stale (hasn't been updated in more than a year), just reject it. If it is important, it will be re-created with recent, relevant info.
00:57 bluescreen_ +1
00:57 kid51 dukeleto: I tend to agree with that ... but I have had my knuckles rapped when I've done that in the past.
00:58 kid51 To the point where there are certain people whose tickets I simply will not touch
00:58 whiteknight kid51: a spring cleaning of sorts would be appreciated
00:58 cotto one more thing for the queue: roadmap management
00:59 mikehh there are some tickets that are still valid but need some ways of handling them, opengl for one,native_pbc and others
00:59 cotto kid51, that's one of the reasons I want a set of generally accepted criteria
00:59 dukeleto Are we ready for our next topic?
00:59 kid51 It looks as if our discussion on API has petered out.  whiteknight/bluescreen:  Can you prepare a summary report on where things stand as of mid-January (3.0)?
00:59 whiteknight yessir
00:59 cotto dukeleto, go for it.
01:00 whiteknight side note: we should hammer out a policy on closing tickets. Because we have several users with very different (strongly-held) strategies, which leads to erratic-looking behavior
01:00 cotto whiteknight, noted
01:01 whiteknight cotto++ # note taking
01:02 cotto dukeleto, you wanted to talk about Parrot on mobile platforms, didn't you?
01:03 cotto He must have gone afk.
01:03 kid51 cotto: If you're ready about roadmap, why not proceed
01:03 cotto sure
01:04 cotto I noticed that we have a lot of roadmap tickets in trac that don't seem to be doing much good.  Do we want to continue to track roadmap items via trac as we have been?
01:04 kid51 I confess I have not looked at roadmap in many months
01:04 * dukeleto will start with the next topic
01:04 cotto dukeleto, go ahead
01:05 cotto roadmaps&
01:05 dukeleto I am hacking on Parrot on Android
01:05 Util dukeleto: rooted?
01:05 dukeleto There is something called SL4A "Scripting Layer 4 Android"
01:06 dukeleto it allows dynamic languages to run on non-rooted android phones
01:06 dukeleto see http://trac.parrot.org/parrot/ticket/1881 for some details
01:06 dukeleto basically, it allows writing scripts on phones with dynamic languages, that normally can't be used.
01:07 dukeleto so it is a first step in porting Parrot.
01:07 dukeleto so in the case of SL4A, Parrot would be running on top of Dalvik, not replacing it.
01:07 dukeleto I think this is an important first step.
01:07 * dukeleto is experiencing huge IRC lag, sorry
01:08 lucian dukeleto: uh, i don't think that's ow SL4A works
01:08 Util Sounds good; much better than Parrot->JVM transputing
01:08 dukeleto I am looking for people who want to be on a "Mobile Parrot" team
01:09 lucian right now, CPython for example runs alongside dalvik
01:09 dukeleto lucian: have you read the source of SL4A ?
01:09 lucian with a proxy to dalvik APIs
01:09 lucian dukeleto: not recently
01:09 tcurtis joined #parrotsketch
01:09 dukeleto Currently SL4A has ruby, python, javascript, perl 5, lua and a few other languages
01:10 lucian yes. a few run on Dalvik, a few others run natively + dalvik proxy
01:10 dukeleto Util: SL4A would basically expose Parrot or Rakudo Perl 6 as a scripting language for the phone
01:10 atrodo i assume that since perl5 is in there, a C layer is inovled?
01:10 dukeleto I think getting Parrot in SL4A is a babystep for getting Parrot into the mobile niche.
01:10 lucian atrodo: it just runs perl5
01:11 whiteknight if parrot were more mature, I might suggest we talk to google and try to *become* the next SL4
01:11 cotto It does look like a good first step.
01:11 whiteknight SL4A
01:11 whiteknight but we're not ready for that yet
01:11 diakopter left #parrotsketch
01:11 kid51 whiteknight: I know others who would agree with you
01:11 lucian whiteknight: i also think you're overestimating SL4A
01:11 dukeleto whiteknight: SL4A has nothing to do with google
01:12 Util dukeleto: I agree; best first step for Mobile; Palm and iOS are harder roads.
01:13 dukeleto lucian: sounds like I need you on the mobile team
01:13 whiteknight we obviously need working compilers for all those languages before we can look to replace existing runtimes for them
01:13 dukeleto SL4A has a hacked up copy of Perl 5 in their source tree.
01:13 lucian dukeleto: yeah, they've had to patch bash and CPython too
01:13 dukeleto SL4A usually requires modifications to the source of interpreters to actually work.
01:14 lucian because Android is ... let's say peculiar
01:14 lucian java stuff is easier in SL4A though, JRuby and beanshell work almost unchanged, and with full access to the Android API (because it's all java)
01:15 Util hacked-up is not automatically a negative; most new ports of Perl5(etc...) start just that way, then the hacks get folded into the mother tree.
01:16 Util Perl5 on Win32 by ActiveState took that route.
01:16 kid51 dukeleto:  Can I suggest that you and lucian work up a document which would be a game plan for us?
01:16 lucian dukeleto: btw, I'm somewhat familiar with android, but i have no low-level knowledge
01:16 kid51 Something that, say, starts out as blog posts and evolves into something on parrot-dev?
01:17 kid51 Sounds like something that would make good GSOC projects?
01:17 dukeleto Android is very peculiar, but it has become an important mobile platform.
01:17 dukeleto I basically wanted to let everyone know that I am working on this stuff, and invite any and all to give feedback and help.
01:17 dukeleto lucian: I want to recruit you. We need to interview the people who got Perl 5 on Android to work, and understand exactly what was needed.
01:17 dukeleto kid51: sounds reasonable.
01:17 dukeleto lucian: you up to give me some help on that document?
01:17 dukeleto kid51: yes and yes and yes
01:17 kid51 And I'd like to have a document to show to other people (non-current-Parrot)
01:17 lucian dukeleto: sure, just be aware my free time is tight
01:17 Util dukeleto: will you work in a Parrot branch, or separate repo?
01:18 lucian however, don't be disillusioned that people will write Android apps on parrot any time soon
01:18 lucian unless you're Java, you're not invited to the party
01:19 dukeleto lucian: that is fine. I would greatly appreciate any help you could give.
01:19 dukeleto Util: not sure yet, does it matter?
01:19 dukeleto lucian: i am not worried about that. I am interested in test-driving and benchmarking Parrot on a mobile platform.
01:19 dukeleto lucian: i fully understand that. My end goal is to replace Dalvik. This is just the first step in that journey.
01:20 lucian dukeleto: that's also far off. although dalvik's GC sucks almost as much as parrot's :)
01:20 dukeleto lucian: Yes. I am thinking long term.
01:20 Util dukeleto: I just want to follow along. Got my first droid 2 weeks ago
01:21 * dukeleto needs to go AFK. I will write up more info about Parrot on Android in a blog post soonishly.
01:21 dukeleto Util: awesome! Will keep everyone in the loop.
01:21 lucian dukeleto: ping me if you need help
01:21 cotto any other thoughts on mobile parrot?
01:21 kid51 Thanks:  This will be very interesting to follow.
01:21 cotto yes it will
01:21 dukeleto lucian: thanks, i appreciate it.
01:22 * dukeleto will rejoin soon if PDS is still in progress. Excalibur!
01:22 kid51 Can we return to roadmap discussion?
01:22 Util mobile thought: Keep keeping kid51++'s "low memory platforms" ideas in mind.
01:22 cotto kid51, yes
01:22 kid51 my thoughts:
01:23 cotto The question pertained to whether we wanted to continue using the roadmaps as before.
01:23 kid51 There are only a few of us who really understand the project will enough to establish a vision, which a roadmap concretizes.
01:23 kid51 allison could do that.
01:23 kid51 whiteknight has some vision in his head
01:23 kid51 the rest of us mostly don't
01:24 whiteknight it really is a big project
01:24 kid51 cotto:  I think this comes down to:  What works for you as architect?
01:24 cotto I'll be thinking about that.
01:24 kid51 And whiteknight:  What works for you as Product Manager?
01:24 whiteknight kid51: I
01:25 whiteknight 'm on the architecture team too
01:25 whiteknight but yes, lots of things to keep in mind
01:25 kid51 We have a number of people who *could* be working on 6 major areas at once ... if they were paid to do it full-time.
01:25 cotto that'll be the day
01:26 mikehh roadmap items give a focus on what we would like to achieve by a given release
01:26 kid51 My concern is:  What can we persuade cotto, whiteknight, bacek, duke, etc to *focus* on in, say, a given quarter.
01:26 cotto or to better phrase it, what can we agree to focus on
01:26 kid51 mikehh  But I think that past roadmaps have amounted to little more than wishlists
01:27 mikehh good for guidance, not always achievable
01:27 cotto kid51, exactly.  That's one of the negative criteria.
01:29 cotto I've got that on my todo list.
01:29 cotto any other topics?
01:29 plobsing q1q
01:29 kid51 Concretely:  I think that if cotto and whiteknight discussed (off this channel) what you wanted over each of the next 8 quarters, that would be sufficient roadmap for the rest of us.
01:30 kid51 Anything more than that would be wishlist.
01:30 cotto 2 years is a long time, but we could figure something out for at least a subset of that
01:30 kid51 Actually, a realistic roadmap for 4 quarters is better than a wishlist for 8.
01:31 kid51 Thinking product-wise, what features do we want Parrot to have for each of the supported releases in 2011?
01:31 kid51 the answer to that question is our roadmp.
01:31 chromatic +1 to that
01:32 mikehh +1
01:32 kid51 So (to sound a familiar chord) can you and Andrew work that up in blog posts, then something on parrot-dev?
01:32 cotto sure
01:32 whiteknight I can work together with cotto on that
01:33 kid51 Excellent.
01:33 kid51 (I think plobsing's ? is next.)
01:33 cotto plobsing, go ahead
01:34 plobsing with more of parrot being implemented in parrot (very good thing IMHO), we expose more internals to the outside. Do we want to draw a line about stuff that cannot be touched and how do we want to do that?
01:34 plobsing cannot be touched by users
01:35 kid51 plobsing:  Does this mean "a more strictly defined API" -- or something beyond that?
01:35 plobsing a good example is bytecode structure (which has been "experimental" since forever). experimental isn't a good classification for such things.
01:35 chromatic How about "a supported API" and "supported semantics"?
01:35 kid51 chromatic:  Can you explain supported semantics?
01:36 plobsing kid51: a strictly defined API is sort of what I'm getting at. It's something along the lines of "yes, we know you can poke that, but don't whine at us when we change it". I just want to leave us wiggle room.
01:37 chromatic Sure.  Suppose we never document that if you pass a STRING to Parrot_pmc_register() the STRING gets registered as live with the GC.  Anyone who does that and expects that always to continue working is just out of luck.
01:37 whiteknight we have multiple levels of API, and first step is to define what those are
01:37 whiteknight we have embedding API, extending API, bytecode API, etc
01:37 lucian an 'internal' namespace or similar would be nice
01:37 cotto chromatic, lol
01:38 cotto something like PARROT_INTERNAL?
01:38 cotto as a macro
01:38 lucian cotto: i guess. i'm not familiar with parrot C code
01:39 plobsing cotto: C functions aren't the only things that are internal though
01:39 plobsing ImageIO pmcs, Packfile pmcs, bytecode in general, lorito bits, etc...
01:39 whiteknight we've explicitly defined that structure internals should be opaque outside of core parrot
01:40 chromatic Does our deprecation policy say "Everything not explicitly supported isn't"?
01:40 cotto we could create an extra pmclass modifier "internal", though I'm not sure how we'd use it apart from documentation.
01:41 whiteknight chromatic: no. Nothing is explicitly supported
01:41 whiteknight that's been my biggest beef with the deprecation policy
01:41 whiteknight it's extremely vague and broad about what we cover
01:42 plobsing I'm thinking about the ImageIO pmcs in particular, with which I'm fairly certain I've broken dep-policy several times (but nobody noticed, because they really are internal).
01:42 whiteknight plobsing: so that's a good point. Maybe all PMC types are not external
01:42 mikehh how about this is the api, that will be subject to deprecation notices etc
01:44 cotto whiteknight, do you think marking PMCs as explicitly internal is workable?
01:44 cotto For functions it's probably too much effort.
01:45 whiteknight cotto: we can't prevent people from using them, but we can declare that they don't have a stable API for users
01:45 whiteknight use at your own risk, etc
01:45 cotto of course
01:46 whiteknight a simple idea would be to prefix certain type names with an underscore
01:46 whiteknight _ImageIO, to let people know it's internal-only
01:46 cotto Simple yet ugly.
01:46 chromatic Ugly yet ugly.
01:46 whiteknight like in libc, things with _ are not intended for users
01:46 whiteknight or we could set a flag
01:47 whiteknight PObj_DONT_FREAKING_USE_THIS_FLAG
01:47 cotto POBJ_WE_WILL_SOMETIMES_SHUFFLE_INTERNALS_WITHOUT_REASON_OR_WARNING_FLAG
01:48 plobsing what would a runtime flag accomplish? I much prefer something static unless there's a benefit to the flag.
01:49 whiteknight plobsing: we can check the flag in the PIR op to prevent PIR code from instantiating that type
01:49 whiteknight that's if we really want to make certain PMC types internal-only
01:49 whiteknight if we don't want to go to lengths to prevent it, we need a cultural instead of a technical solution
01:49 tcurtis left #parrotsketch
01:50 mikehh warning - thisa is an internal function/PMC
01:50 kid51 bbial
01:50 chromatic I haven't seen any proposals I love yet.
01:50 plobsing We're all grown ups here. If a user really wants to use an internal functionality, and accepts the risks, they should be able to.
01:50 cotto They just shouldn't be able to do so without knowing what they're doing.
01:50 whiteknight right, the difference is whether we need to jump through hoops when we change the interface for it
01:51 whiteknight for ImageIO, we don't want to do that
01:51 whiteknight some things we support externally, some we don't
01:51 chromatic Let's document what we support and disclaim what we don't.
01:51 mikehh +1
01:51 whiteknight EXACTLY
01:51 * lucian almost likes _ImageIO
01:52 cotto chromatic, +1
01:52 plobsing +1 to document. where? DEPRECATED.pod? PMC source? other?
01:52 cotto support policy seems like the most natural place
01:52 whiteknight I've always wanted to have an explicit list of things we supported. A dedicated file for that would be fine
01:52 chromatic Yeah, the support policy document.
01:53 whiteknight some things are obvious: src/embed/*, src/embed.c, src/extend.c
01:53 whiteknight dynpmcs
01:53 whiteknight dynops
01:54 chromatic I volunteer to make a document listing what we need to consider when we merge a feature branch.
01:54 whiteknight chromatic++
01:54 cotto thanks
01:54 mikehh we should have a "supported" set of tests for that as well
01:54 whiteknight better yet, it isn't supported without a test
01:55 whiteknight so that we know exactly what behaviors we support
01:55 mikehh I was thinking along the lines of api tests to see if we break anything with merges/changes
01:55 plobsing whiteknight: I like that idea, but I don't want our testsuite to take as long as rakudo spectest
01:56 whiteknight plobsing: good point. Some kind of triage of existing tests may be nice
01:56 whiteknight some of ours, like the ops parsing ones, already take way too long
01:56 mikehh different aspects of the testsuite
01:57 whiteknight or different test targets
01:57 whiteknight coretest vs test, etc
01:58 mikehh in that regard the original concept of core has changed a bit
01:58 mikehh especially as we use nqp-rx more and more
01:59 whiteknight yes
02:00 * kid51 notes that we've reached the 3-hour point in this meeting
02:01 whiteknight it seems like we still have some steam. Do we want to continue the meeting? Move to #parrot? call it quits?
02:01 cotto keep on
02:01 Util Key question: are we on the last topic for this PDS?
02:01 whiteknight okay, good
02:02 cotto Util, I got that impression.
02:02 kid51 We have discussed all pre-scheduled topics.
02:02 Util keep on
02:03 kid51 We are in the "any other business/questions" phase (and have been so for > 1 hour
02:06 cotto Is the deprecation/support question sufficiently resolved?
02:06 chromatic For now I'm satisfied.
02:06 Util cotto: I think "enough to move forward"
02:07 cotto ok.  Any other questions?
02:09 Util I move to adjourn :)
02:09 whiteknight second
02:09 cotto It's over.
02:09 mikehh good session overall
02:10 Util Time well spent.
02:10 cotto agreed
02:11 kid51 I will post to parrot-dev a summary focusing on action items, ie.. what people promised they would do
02:11 Util kid51++
02:11 whiteknight kid51: great. All I need is a reminder of all the stuff I promise to do
02:12 lucian and then some beer to cope with it? :)
02:13 atrodo kid51++ # Very good job
02:22 lucian left #parrotsketch
02:32 nwellnhof left #parrotsketch
02:42 dukeleto still going?
02:42 plobsing nope. sorry.
02:43 dukeleto plobsing: ok, thanks for letting me know :)
02:43 dukeleto left #parrotsketch
03:22 bluescreen_ left #parrotsketch
03:44 kid51 left #parrotsketch
03:53 atrodo left #parrotsketch
04:03 whiteknight left #parrotsketch
04:04 plobsing left #parrotsketch
06:33 PerlJam left #parrotsketch
06:33 PerlJam joined #parrotsketch
06:45 cotto is now known as clock
06:46 clock is now known as cotto
07:54 bacek joined #parrotsketch
08:12 chromatic left #parrotsketch
09:28 lucian joined #parrotsketch
11:34 lucian left #parrotsketch
12:00 lucian joined #parrotsketch
12:12 lucian left #parrotsketch
12:18 lucian joined #parrotsketch
13:43 bluescreen joined #parrotsketch
15:53 bluescreen left #parrotsketch
16:01 PerlJam left #parrotsketch
16:02 PerlJam joined #parrotsketch
16:10 bluescreen joined #parrotsketch
18:26 bacek left #parrotsketch
21:55 bluescreen left #parrotsketch
22:30 lucian left #parrotsketch
22:31 lucian joined #parrotsketch
23:38 kid51 joined #parrotsketch
23:39 whiteknight joined #parrotsketch
23:47 bluescreen joined #parrotsketch

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