Vision for 2.0: Production Users | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 2 August 2009.
00:07 davidfetter joined 14:35 whiteknight joined 14:43 jimka joined 16:13 nillo joined 16:17 moritz joined 16:21 mikehh joined 16:22 satrac joined, kj joined 16:23 satrac left
kj First report since February 2009 (or so). 16:26
* Not much to report, more saying "Hi, I'm still here"
* made a few commits to prepare the conversion from C strings (char *) to STRINGs
* Will not have much time due to $work (which is research related to OSS) but plan to spend bits here and there if I have tuits.
EOR
* FYI, the mentioned work is for compilers/PIRC.
EOR 16:27
16:27 dukeleto joined 16:28 NotFound joined
whiteknight What I did: 16:56
* Added a new fixed-size object allocator to the GC, especially to help decrease costs of PMC attribute structure allocation
* Following along enthusiastically with TT #895 (NotFound++)
* Prototyped a lazy pool allocator on suggestion from chromatic++
* Bought a copy of the book, read it cover-to-cover, already brainstorming ideas to make it bigger/better/gold-plated
What I will do:
* Help with TT #895
* Attempt to add the lazy allocator to the PObj pools and do some benchmarks to see if it improves startup time
* Still hoping to work on io_cleanups
What I am blocking on:
* Not enough time
moritz I'll not be online during #ps meeting; don't have anything interesting to report either 17:10
moderator Vision for 2.0: Production Users | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 17:14
Coke joined, Coke left, Coke joined 17:15 treed joined
Tene Last week: 17:31
* Helped treed with Cardinal
* Looked for some way to poll() or select() FDs in Parrot, found the apparently-unused Parrot_io_poll, added it as a method to the Socket PMC.
* Not sure if that's where it belong, or if that's even correct. Still no way to select() from a list a FDs.
Coming week:
* No plans yet, and I'm starting to have more tuits available. I'm considering working on IO stuff.l
17:34 davidfetter joined
NotFound What I did: 17:36
* Implemented and tested an idea for automatic attribute allocation, TT #895
* Some tests with this and the fixed-size allocator (whitenight++)
* Several cleanups that will help the transition and testing of the former.
* Implemented a last resort attempt to show exception messages in corner cases.
* Some minor fixes and cleanups.
What I will do:
* More work in TT #895 and related issues.
17:37 PacoLinux joined
treed Posting at Tene's suggestion (Cardinal dev here; hiya!) 17:50
What I've Done:
* Not much in the past week, mostly messed around with the test suite.
* I did enable precompilation as part of that, which can save a great deal of time spent parsing. (25 seconds for test:all rather than 6+ minutes; still well above the 2-3 seconds it takes for cruby, but it does help a lot when running the test suite often.)
* Keeping up with the fork queue and occasionally helping joeri/danius. (They don't need much help, though.) 17:51
What I Expect To Do:
* I've been cooking up a fix for assignment (github.com/cardinal/cardinal/issues#issue/23) in my head. I took a whack at it a few weeks ago, but failed to take some things into account. I expect to at least make another attempt in the next week.
* I may start working on revising the object model and renaming CardinalClasses to just Classes.
What I'm Blocking On:
* Kinda still in the process of moving/looking for a job, which is taking some of my time.
* Not much in Parrot, AFAICT. Mostly my own ignorance.
* Could maybe use some help figuring out if github.com/cardinal/cardinal/issues#issue/31 is related to the Parrot side or my own ignorance. Sent a purl-gram to pmichaud, at Tene's suggestion, about it, haven't heard back yet.
18:11 allison joined 18:14 Util joined 18:16 chromatic joined
Util # Done: 18:16
* Researched Coverity RETURN_LOCAL defects in NCI functions of PMCs. No conclusions yet.
# Plan for next week:
* NULL
# Blockers:
* 0 tuits until next Monday.
.end
chromatic Reviewing and fixing and closing some Coverity defects.
Still working on pluggable runcores; blocking on time and energy.
Will continue.
allison - My week was mostly absorbed by visa application. Nothing left to do there but wait. 18:17
- For the next two weeks I'll be working only on Parrot, will see how far I can push the pcc_rewiring branch.
EOR
cotto # What I did: 18:33
* made SUPER dtrt for dynpmcs (darbelo needed this)
- also ripped out DYNSUPER, since we no longer have the compiletime/runtime distinction
- created a nice memory leak in the process
* wrote a simple proof-of-concept profiling runcore (not committed)
- am hacking the slow runcore so I'm not blocking on chromatic's pluggable_runcore work
- started (and killed and restarted) a script to postprocess profiling output for kcachegrind
- can profile simple PIR programs but Rakudo hello world segfaults
- imcc's poor line numbering is going to get more painful once we have a profiler
# What I hope to do and how many tuits I expect to have:
* get the runcore working with HLLs
- add support for HLL annotations
- confirm (and fix) profiling fancy control structures (exceptions, coroutines, etc)
* integration with pluggable_runcore whenever it's ready
# What could block my progress:
* no apparent blockers on the horizon
.eor
whiteknight Hello 18:34
NotFound hola
allison hi
Util hi
kj hi
chromatic hello
Tene Hi! 18:35
cotto hi
chromatic I suppose we should do roadmap review. 18:37
Runloops: in progress, blocking some on me.
allison trac.parrot.org/parrot/report/14
chromatic Profiling tools: blocking on runloops. I will fix that. 18:38
Vtable swap: bacek and I discussed some different ideas; he put his on the wiki. Needs review from allison.
(probably needs review from me)
Packfile PMCs; do we have an Infinoid?
sounds like a no 18:39
kj, what's the status of pirc?
Tene has kj even been around lately?
chromatic He just said hi. 18:40
kj not much changed since i left it for what it is in February. major problem is some bugs of storing NUMs and STRINGs in the constant table
Tene ... right, reading...
allison kj: what's your estimate of what's left?
kj i just don't understand what's going on. i've started to think about converting char * (c strings) into parrot STRINGs
allison we were talking about where to schedule it last week 18:41
kj quite some work if done by myself. Reasons are: no gdb skills... (more)
need to look into bytecode generator, which is mostly code copied from IMCC (and hence not very trustworthy)...
and STRING conversion will take quite a bit of work throughout PIRC 18:42
.
chromatic Do you have a list of tasks and places other people can help?
NotFound I'm thinking about doing some reworking of the unescape functions, that may help?
kj there's some TTs for the bugs/problems with NUM and STRING constants
NotFound: PIRC stores all strings as char *. That should change to use STRINGs only 18:43
chromatic How about further development tasks?
kj since C strings are evil, so I have been told (and I'm convinced)
allison As a rough estimate, how does 2.6 (next July) sound?
kj it's really hard to say :-( 18:44
STRING conversion is straightforward (but not trivial)
allison kj: It's just an estimate, and we can always reschedule.
chromatic Let's get a couple of people to help with the constants issue.
kj bytecode bugs are no fun, and I'm not looking fwd to debug those 18:45
allison kj: Mainly, I want the schedule to reflect our priorities.
davidfetter doesn't see sandbox anywhere on that roadmap :(
kj once that's done, there's probably some small tasks, but those shouldn't be too hard.
chromatic Let's try to get Infinoid's attention there in the short term. He did a lot of the Packfile PMCs. 18:46
whiteknight needs Infinoid to finish his pipes implementation first
chromatic Can someone create a PIRC page on the Wiki with links to the appropriate tickets? 18:47
kj I guess I could do that
chromatic Thanks!
whiteknight kj++
chromatic Seed libraries?
Anyone? 18:48
Tene Parrot's mysql is bitrotted 18:49
allison we kept that to break out into one per month
so, pick one seed library to fix up for 1.5
NotFound Tene: you mean the one in examples?
Tene Is there a list anywhere of desired seed libraries, or a proposition on where we're going to store the libraries? In Parrot svn? Somewhere else? Wasn't there an argument about this on the ml?
NotFound: yes. 18:50
NotFound Tene: I lacked the time to fix it after some nci changes.
chromatic japhb's post was a summary, I think.
allison Tene: the ticket has a generic list, but needs to be broken down into more detailed smaller items 18:51
perhaps a "what libraries should Parrot provide?" thread on the mailing list?
japhb rezzes in
NotFound I think that we must not do configure checks for libraries, except in corner cases like opengl. Do all at runtime.
chromatic We'll have to improve our library searching then. It gets tricky across platforms. 18:52
japhb allison: My last ML post had the basic heirarchy structure. I do think it is time to decide what goes into layer 1 and possibly 2.
NotFound I added some comments in a postgresql ticket,
allison japhb: okay, I'll look for and respond to that message this week
Tene Should japhb's last post go into the ticket? 18:53
allison Tene: probably, yes
allison hasn't seen it yet
japhb allison: thread 'Re: Parrot "standard libraries"', last post was me summarizing the ideas that pmichaud and I discussed last Friday. 18:54
Tene lists.parrot.org/pipermail/parrot-d...02666.html 18:55
japhb Thanks, Tene
allison thanks japhb/Tene
back to vtable swap, if we're still in design phase, that's not a 1.5 deliverable
is that a 1.7 deliverable? 18:56
chromatic 1.7 is very likely.
allison okay, changed
18:56 einstein joined
allison do we want to do questions before the 2.0 roadmap review? 18:57
chromatic Yes.
I'd like to get mikehh a commit bit; he's very good about coding standards and catching failing tests.
His patches are fine and he's had the lecture. His CLA is on the way.
Comments?
NotFound +1
allison +1 from me
Tene +1 18:58
Util +1
Tene q1q
moritz +1
chromatic Alright, I'll keep an eye out.
NotFound q2q
chromatic Tene? 18:59
Tene I noticed recently that there's apparently no way in Parrot to select() on a list of FDs. Is that a scheduled capability, and if so, when? I don't think I see anything in the roadmap that looks like it would include it, but I'm full of reading fail today.
allison there's no select in the I/O pdd 19:00
whiteknight I'm planning to add it in AIO, but it could be added before that if necessary
chromatic Seems like a standard feature.
whiteknight A Select PMC would be a nice addition
Tene I don't see AIO on the roadmap. Should it be there? 19:01
whiteknight there's a ticket, I don't know how things get into the roadmap
allison whiteknight: we talk about it here and decide if it should go in the roadmap
(and when)
yes, async I/O should be added 19:02
Tene Okay, I'm done.
allison not a 2.0 priority
2.6 or 3.0?
whiteknight I plan to start on it as soon as the pipes implementation is finished, so I suspect it will be in long before 2.6
allison whiteknight: what's the ticket #?
whiteknight let me look
TT #31 19:03
allison whiteknight: roadmap items are scheduled by "reasonable expectation of a stable and complete implementation", rather than "the soonest we could have it completed"
(so, more on the conservative estimate side) 19:04
Tene threads doesn't seem to be on the roadmap anywhere either.
whiteknight that's fair. I say 2.6
allison Tene: 3.0
Tene allison: thanks
chromatic NotFound?
NotFound TT #872, kill PASM1 pseudo-compiller 19:05
chromatic Hearty thumbs up here. 19:06
whiteknight what does that compiler even do (or, what was it intended to do)?
allison +1 19:07
NotFound whiteknight: it was supposed to make work the eval instruction of the debugger, but it doesn't work since long time ago.
whiteknight ok
allison it was used in early testing of compreg
get in a deprecation notice for 2.1 19:08
NotFound allison: the question was kill it, not deprecate it.
chromatic First the one, then the other. 19:09
allison we have a deprecation policy for a reason, we stick to it
chromatic Unless it never worked.
allison it was never fully functional, but id does work in a limited way
NotFound allison: I'd verified that it not worked at all in 1.0 19:10
Or a least, I'm unable to find any way to use it that works, 19:11
allison NotFound: fair enough, we can change it to throw a clean exception stating that it's been deprecated
(that's better than a segfault)
NotFound (sigh) ok.
chromatic Next question? 19:12
NotFound Next question: TT #895 requires a change in the vtable layout. Cant that be commited or need a deprecation cycle? 19:13
allison NotFound: depends on if it's adding or removing features (checking)
NotFound Just adding a member to the vtable structure 19:14
allison it's purely internal, doesn't remove any existing functinality, and not visible to the user, so not subject to deprecation policy
NotFound Ok :) 19:15
chromatic ... but it has binary compatibility implications.
allison done on a branch, we can test if it helps or hurts speed
chromatic: if we don't freeze the struct size, then it's not a change to the bytecode 19:16
whiteknight with recent changes to the GC, it should be a good net win
chromatic If you add a member to a struct, any compiled code which uses that struct will act differently.
... depending on where you add it.
NotFound I was trying to avoid the need to learn how to branch, but ok ;)
We can put it at the end of the structure, to minimize the changes. 19:17
chromatic I'm not sure the vtable processor works that way.
If we don't guarantee binary compatibility for extensions, that's not a problem.
I just raise it in case we do.
allison chromatic: binary compatibility isn't on our current list of guarantees
chromatic: maybe by 3.0
chromatic Thought so. Thanks. 19:18
NotFound EOQ
chromatic Other questions? 19:19
davidfetter am i the only one who thinks parrot needs a restricted execution environment? 19:20
chromatic No.
Tene No.
allison quick triage on the 2.0 roadmap items? 19:21
chromatic +1
allison okay
garbage collectable contexts
for 2.0 or not? 19:22
if so, by when?
chromatic If we can get PCC rewiring, yes.
allison okay, so keep, but later in 6 months
will say.... 1.9
pdd15-objects is a design review
should happen earlier, say... 1.6 19:23
bytecode migration, generation, and testing
for 2.0 or not?
chromatic Seems like the point it's necessary.
allison if so, by when? and who is working on them?
NotFound Fixing the packfile pmcs is not a prerequisite for that? 19:24
chromatic <crickets />
whiteknight I thought the packfile PMCs were fixed? 19:25
allison chromatic: necessary for 2.0? or just generally desirable in the not-too-distant future?
chromatic I think it's well within the vision of 2.0. 19:26
NotFound whiteknight: his tests they keep failing sometimes at least in amd64 for no apparent reason.
chromatic But if we retain bytecode compatibility until 2.6, 2.6 is the latest point at which it makes sense.
Tene for migration, 2.0 is the first release that we start caring, so we won't *need* a migration tool until the first release *after* 2.0 where bytecode is changed.
allison bytecode generation from post is part of pirc, so probably makes sense to bump that to 2.6 19:27
bytecode testing should be the first priority
chromatic Should we break it into separate items then?
allison bytecode migration tool is nice to have soon, but not an ultra high priority (i.e. not next month) 19:28
it's three tickets, I was just mentally lumping them together
bytecode testing for 1.7?
chromatic We have to figure out what that means. 19:29
allison bytecode migration tool for 1.8, but an understanding that it's okay if it's post 2.0?
chromatic: yes, that's the first step in working on the task
NotFound We have still pending the problem of encoding no stored in PBCs...
chromatic Lots of things aren't stored in PBCs.
allison chromatic: right now want to stick to quick triage 19:30
Tene if we don't have any volunteers to work on these, should we put out a call for volunteers?
NotFound TT #468
allison testing and documentation sprint for 1.8?
Tene that's where I'd put it.
particle if we don't have bytecode compat by 2.0, we should at least be able to include hll source in the pbc files for (re)compilation 19:31
Tene maybe documentation for 1.9
allison okay, testing for 1.8, documentation for 1.9
NotFound The encoding is an important one. For example, utf16 strings doesn't work,
allison particle: we'll still follow bytecode deprecation cycles, but I don't know that we'll offer bytecode backward compatibility until 3.0 19:33
particle: including source in the bytecode files wouldn't be my ideal solution 19:34
particle: if they want to include source files, ship the source files
pge, debug and visibility, tools 19:35
particle if the source files are lost, there is no hope of running on future parrot
oh well.
allison patrick's not here, so will review that one next week
NotFound particle: you can use the pbc disassembler from that version
allison particle: I'm not following your logic, but we can talk about it more on #parrot or mailing list 19:36
prune c data structures
particle agreed, this meeting is *long* already
allison for 2.0 or not?
chromatic Yes please. 19:37
allison it's fundamental change, so should be early
(leaving plenty of time for testing)
1.6?
chromatic It's not that big, but we shouldn't do it in the final month.
allison right, it's small but significant
chromatic Let's tackle one or two significant structs every month. 19:38
allison chromatic: sounds good
chromatic: I'll put it at 1.5 so we remember to break it down into 1 per month
chromatic I'll work on that tomorrow.
allison the last is user mailing list, which I'll put at 1.8 19:39
(enough time so it's in place for 2.0)
that's it for roadmap review
Tene Do we want to have a development priority for this week? 19:40
I remember some kind of mention of tha tin the past? 19:41
chromatic Removing deprecated features?
allison aye, that's a good priority for the month 19:42
japhb Vision for 2.0: Production Users | Priority for 1.5: Remove Deprecated Features | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
gah 19:43
Tene maybe that should go in #parrot too?
moderator Vision for 2.0: Production Users | Priority for 1.5: Remove Deprecated Features | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. 19:43
japhb Tene: done 19:44
meeting over? 19:46
chromatic yes; adjourn 19:47
19:47 Util left
allison thanks all! 19:47
19:47 chromatic left 19:48 moritz left 19:49 NotFound left 19:51 allison left 19:57 treed left 19:59 nillo left 20:48 PacoLinux left 21:05 Whiteknight joined 21:27 Coke left 22:00 cotto joined 22:38 particle joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!