Vision for 2.0: Production Users | Priority for 1.9: Performance and Testing | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 13 December 2009.
allison set 3.3, we can change later (moving forward or back) 00:00
portable runtime?
I don't see a specific need for this
japhb What does that mean?
particle1 like apache portable runtime, or jre
pmichaud goes to read the ticket.
allison suggest dropping from roadmap
pmichaud drop
particle1 only runs, does not compile
drop it.
allison yes, apache portable runtime
00:00 bacek joined
allison should we close the ticket too? 00:01
pmichaud close ticket +1
allison will note
refactor config?
chromatic In the interest of expedience, should we leave everything scheduled for 3.0 and later there until our 2.3 review and review now what's left?
We're 30 minutes over time.
Coke +1 00:02
kid51 I doubt we need to face up to refactor config until we're ready to jettison Perl 5
Coke we're more trying to map out until 2.3; not "until the end of time."
allison drop task?
particle1 we'll need a refactored config for lorito/3.0 i think
but that's not roadmap-worthy
allison yes, but that's part of the general task of lorito
particle1 aye
pmichaud many things on the roadmap now are things that we thought (at PDS 2008) that people would ask about, and we wanted to point to a plan to provide them.
allison we can hold the remaining 3.0 tasks for the 2.3 meeting, but I can say most of them aren't going to stay as 3.0 00:03
particle1 agreed.
pmichaud but a year on, I suspect they aren't being asked about as much, or we'd have to shrug and say "whenever someone has the tuits for them"
allison ah, we can do this quickly
kid51 agreed; we've labelled too many as 2.6
particle1 experience++
allison nanoparrot moves to 4.0?
drop the "perl 5 dependency" roadmap item 00:04
chromatic Post-lorito.
pmichaud a different approach: are there any tasks remaining that we think are pre-3.0 ?
if not, let's not roadmap them now.
chromatic Bytecode migration, perhaps.
Build/install directory cleanup.
japhb There are several 1.9 and 2.0 items, some of which are suspicious
particle1 lorito.
chromatic PARROT_API/deprecation policy change.
HLL interop.
allison we already did deprecation policy change
pmichaud HLL interop has a new spec, and an implementation in the NQP HLL compiler object. in some sense it's "landed" I think (to talk about more at next #ps) 00:05
(new draft spec, needs allison review/commentary)
allison okay, will leave that one
I'm moving the "pie in the sky" 3.0 tasks to 4.0
japhb +1 00:06
pmichaud I would say "3.9 or later"
allison but at the 2.3 review we should consider dropping some of them
Tene pmichaud: where in the nqp tree can I see this? This is the first I've heard about this, and I'd like to look at it.
allison bytecode testing framework?
keep or ditch?
or move ahead?
Coke I don't even know what that is.
pmichaud is it a pain point? If not, ditch it.
allison well, we can't currently test bytecode
mikehh we already do some testing with testr 00:07
kid51 wishlist
allison because it's platform-specific
chromatic Why not?
allison okay, drop from roadmap
chromatic: we can't store pre-generated bytecode and test it
it's infrastructure
chromatic Cross platform?
allison but, we should consider removing those bytecode tests that don't work 00:08
pmichaud (Tene: answered on #parrot)
chromatic We should change that to cross-platform bytecode format.
allison bytecode migration tool isn't 1.9
when?
chromatic I don't know when to schedule that.
I can write tasks for a naive bytecode migration tool. It's not awful, mostly SMOP. 00:09
allison is it important for Rakudo *?
pmichaud no
allison then let's push it out
pmichaud Rakudo tends to think in terms of source.
allison seems like most HLLs do 00:10
the bytecode is more like Python .pyc
pmichaud maybe it'll be important if we start to distribute .pbcs, but it's certainly not a Rakudo* goal
allison 2.9?
3.0?
chromatic 3.0
pmichaud I'd wait until people request it :) 00:11
japhb pmichaud, +1
allison prune C data structures?
pmichaud but 2.9, 3.0, or even later are fine with me :)
chromatic Ongoing.
allison do we need that on the roadmap anymore?
seems more general than roadmap
chromatic No.
kid51 No, but we need TTs that can point the way.
allison ok, will keep the ticket, but drop from roadmap) 00:12
kid51 e.g., prune structures in this particular file
allison though, specific tickets would be better than general one)
kid51 ... as a way to possibly integrate new C programmers into project
allison what is "pge, debug and visibility, tools"?
pmichaud adding debugging and tracing tools to pge 00:13
nqp-rx has this already
so, "done."
particle1 ayep
allison and is it relevant any more now that pge is deprecated
pmichaud (can use improvements, but it exists now)
allison ok
will mark to close
kid51 close: +1
pmichaud I'll take the TT
allison change build directory to match install directories
pmichaud (and close and explain)
chromatic Does that help Rakudo?
allison this is a simple task, but a messy one 00:14
pmichaud Rakudo works exclusively from a parrot install now
kid51 isn't it already a TT?
japhb not critical in short term, but does need to be done eventually
kid51 2.9
japhb s/need/should/
allison kid51: yes, IIRC, but someone suggested it as a roadmap item
pmichaud Rakudo doesn't need it any longer, but we do have an ongoing issue that what we install is not tested
i.e., the parrot binary that is tested is not the parrot binary that is installed 00:15
allison mirroring the directory structure might take care of that
particle1 this can't get lost. it's important to HLLs.
allison since it would mean the only difference would be the prefix
pmichaud 2.9 +1
allison will mark for 2.9
particle1 i think it's roadmap-worthy.
NotFound going to sleep
particle1 2.9: +1
allison last one
mark API functions with PARROT_API 00:16
particle1 oh please yes
pmichaud 2.6
japhb particle1: so, no opinion then? ;-)
pmichaud (it doesn't seem like a huge task to me)
allison this is mainly just a matter of going through the list of API functions and adding a tag
(manual editing, but not tricky at all)
particle1 are all api items subject to deprecation?
kid51 where is that list of API functions found?
allison particle: yes
pmichaud I'd say list it as 2.6, and let's find someone to take ownership of the task.
kid51 would be excellent for this, imo 00:17
particle1 i suggest that api items can be unstable/experimental
allison docs/embed.pod
particle1 depending on the subsystem
allison then they should have a separate tag
or an additional tak
tag
chromatic I understood that PARROT_API would be "Feel free to use; we're careful not to break them" and PARROT_EXPORT is "Use at your own risk."
pmichaud chromatic +1
allison PARROT_EXPORT is "Windows requires us to mark this" 00:18
japhb chromatic, +1
pmichaud I already put together a list of the Parrot functions that Rakudo wants to have as PARROT_API
particle1 PARROT_API_EXPERIMENTAL
allison there will be things marked as both PARROT_EXPORT and PARROT_API
particle1 let's be clear
pmichaud (sent it to jhorwitz earlier in the year)
I think that PARROT_API means "stable until deprecated", while everything else is "use at your own risk" 00:19
not sure we need an "experimental". Maybe "PARROT_API_PROPOSED"
allison pmichaud: yes
(on stable until deprecated)
chromatic PARROT_API can do the same thing as PARROT_EXPORT, with the additional feature that it does something more. 00:20
allison which doesn't mean "set in stone" just "we guarantee to support the interface until we explicitly deprecate it"
chromatic I don't want to multiply entities here, when we need to do only two things.
allison PARROT_API doesn't do anything
and lots of things that are marked PARROT_EXPORT aren't PARROT_API
chromatic It currently doesn't, but it means "You can call this function in libparrot and it'll keep working."
japhb allison: yes, but is there a PARROT_API that is not PARROT_EXPORT? 00:21
(That is not a bug)?
allison at some point, we might use PARROT_API as a way of warning extenders and embedders
(or, the lack of it)
chromatic We're bikeshedding.
allison yes
japhb yes
pmichaud I propose 2.6
allison when do we need it?
2.6 is good
marked
and, that's the end of the list 00:22
particle1 PARROT_API implies PARROT_EXPORT.
pmichaud it's more of a "let's get it started" task than anything that is a huge time sink
allison particle: not necessarily
particle1 congrats, everyone!
japhb Yay!
allison thanks all!
this has been hugely helpful
kid51 I recommend: (1) pmichaud to review 2.0 and 2.3 milestones to make sure we've got rakudo * covered
japhb Yes, definitely went well
pmichaud kid51: +1, I shall do that before #ps 00:23
kid51 then everyone else take another look at spreadsheet by Tuesday
to see if it still looks plausible when we sober up
pmichaud you all may assume that if you don't hear anything from me, then I didn't see anything left uncovered
(at this point I don't see anything uncovered :-)
allison let's wrap for the day 00:25
particle1 mailing list writup of session, anyone?
or save that for after parrotsketch?
mikehh yes 00:26
allison also some followup work in updating the roadmap tickets
pmichaud I'll do a bit on ticket updating also 00:29
chromatic Thanks, everyone. 00:30
pmichaud anyway, time to feed family here
thanks to everyone for very useful session!
mikehh sleep
japhb ditto that
(the thank you)
00:35 Coke left 01:00 Whiteknight joined 01:40 JimmyZ joined
dukeleto looks like i missed the meeting 01:56
Whiteknight yeah, you have to check scrollback 02:08
it was a very good meeting though 02:09
02:46 kid51 joined 03:15 kid51 left 03:49 JimmyZ left 04:01 GeJ left 04:13 bacek joined 05:36 mikehh joined 05:39 chromatic left 06:36 NotFound left 06:56 davidfetter left 07:48 cotto joined 09:20 bacek joined
bacek o hai 09:43
10:24 bacek joined 10:44 Infinoid left 12:12 bacek joined 12:40 bacek left 13:33 plobsing joined 14:57 bluescreen joined 15:04 PacoLinux joined 15:08 davidfetter joined, davidfetter left 15:31 bluescreen joined 15:37 mikehh joined 16:49 PerlJam joined 17:56 PacoLinux joined 18:25 cotto_work joined 22:10 Whiteknight joined 22:29 bacek_at_work left 22:46 davidfetter joined 22:48 davidfetter 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!