Vision for 2.0: Production Users | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 1 February 2010.
00:14 TimToady joined 01:31 cotto_work joined 02:56 PacoLinux_ joined 02:58 Tene_ joined 02:59 PerlPilot joined 03:00 japhb_ joined 03:01 ascent_ joined 03:03 wagle joined, TimToady joined 03:04 tewk_ joined, integral joined 03:12 cotto_w0rk joined 03:22 ilbot2 joined
moderator Vision for 2.0: Production Users | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead. | irclog: irc.pugscode.org/
03:30 cotto_working joined 03:35 wagle joined 03:40 Util joined 03:42 PacoLinux_ joined 03:44 integral joined, ascent joined 13:09 kid51 joined
kid51 kid51's report 13:10
* Created tt1393_retcon branch to explore a one-line fix in src/pmc/retcontinuation.pmc to address GC-related problem. 13:11
* Would appreciate smoke reports and review by GC experts, posted to trac.parrot.org/parrot/ticket/1393. 13:12
EOR
14:37 rdice joined 15:18 davidfetter joined 15:45 davidfetter joined 15:48 davidfetter left 16:33 bluescreen joined 16:41 cotto_w0rk joined 16:45 bluescreen joined 16:50 cotto_working joined 17:11 rdice joined 17:41 rdice joined 18:03 mikehh joined 18:13 wagle joined 18:26 cotto_working left, cotto_working joined 18:27 SamuraiJack joined 18:30 darbelo joined
SamuraiJack hello 18:34
just curious - whether it is possible to rewrite Parrot in PASM/PIR?
does it make any sense at all? )
darbelo SamuraiJack: Half-maybe. But you want to ask that in #parrot 18:35
SamuraiJack ok
18:38 allison joined 18:39 whiteknight joined 18:43 NotFound joined 18:51 plobsing joined
plobsing What I Did: 18:55
* rewrote nativecall.pl in PIR (wanted to refactor, might as well re-write) 18:56
* helped darbelo++ a little on pmc_freeze_with_pmcs
What I Plan:
* figure out how to work nativecall.pir into the build (probably need to check src/nci.c into svn, regenerate when necessary)
* refactor nativecall.pir further to generate 3rd party runtime-loadable NCI trampoline libraries
* deprecate config/gen/call_list/misc.in (3rd parties shouldn't have to register their NCI signatures in core to get support)
EOR
NotFound What I did: 18:57
- parrot
* Just testing
- Winxed
* Code cleanings, some more examples
* Some more predef functions and operators
* Backporting to stage 0 some stage 1 features
What I will do:
* No plan
EOR
19:06 japhb joined
whiteknight WHAT I DID: 19:06
(parrot) Worked on and merged kill_array_pmc branch. The Array PMC is gone now. Closed 4 related tickets.
(parrot) Lots of testing for kill_array_pmc to make sure nobody was relying on it (almost nobody was)
(parrot) Planning for either (a) optimizations on existing array types, or (b) creating a new project with optimized/specialized types. Jury still out on way forward
(parrot) Testing and small codestd fixes for pmc_freeze_with_pmcs branch. All tests pass and branch appears good to merge.
(parrot) Already helping to plan next steps in freeze/thaw cleanups and refactors
(parrot) Testing and debugging on gc_encapsulate branch
(parrot) Lots of blogging, especially about GSoC. Looking for good ideas to publicize
(matrixy) Fixed some builtins, preparing for a big refactor of function dispatch code
WHAT I WILL DO:
(parrot) Support pmc_freeze_with_pmcs branch and merger
(parrot) Continue debugging on gc_encapsulate branch
(pla) Adding freeze/thaw to matrix PMCs, using new pmc_freeze_with_pmcs mechanics
(matrixy) Starting on big function dispatch refactor
WHAT I AM BLOCKING ON:
Life, the universe, and everything.
mikehh What I did since my last report: 19:18
* building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
* a lot of branch testing
* some fixes
What I intend to do in the next week:
* testing and fixing
.eor
darbelo DONE: 19:31
* Got involved with PL/Parrot.
* Turned the visit_info structure used to drive the freeze/thaw process into a PMC. 19:32
This opens up several new cleanup opportunities.
* Merging branch into trunk right now.
PLANED:
* Help HLLs that are affected by the freeze/thaw change.
* Get started with the NEWS.
BLOCKERS: * Being a lazy bum.
EOR
cotto_working #did:
* Tried to get pbc_merge working while trying to understand certian pbc oddities. Got stuck.
#will do:
* Make pbc_merge work, accepting that the oddities of what imcc generates aren't worth figuring out atm.
#blockers:
* self
#closed TTs:
* none
#eor
q1q 19:38
darbelo q1q
Util # Done 19:42
* NULL
# Plan to:
* NULL
# Blockers:
* $WORK == MAX_INT
.end
19:45 mikehh joined
tewk #WORKING ON I have a patch that removes ParrotRunningThread, I'll hit the list with it soon. 19:48
#THINKING ABOUT trying to revive ncigen, especially the C99 parser
#DONE
japhb Util.report.clone; 19:49
19:52 mikehh joined 19:55 particle joined
cotto_working q-1q (total 0) 20:00
whiteknight q1q 20:05
actually, q2q 20:10
20:22 chromatic joined 20:26 Coke joined
allison Last week: 20:27
- Reworked the old calling conventions task list to clean out the completed tasks, and add the new ones for eligible deprecations after 2.0.
- The main focus there is the 'get_results' refactor, to move it *after* the call to 'set_returns'.
Next week:
- Will work on Debian/Ubuntu packaging for 2.0.
EOR
chromatic I'm still working on TT #389. I think I have it cracked. 20:28
I have some GC tuning ideas to explore too.
Coke last two weeks: 20:30
partcl: update to avoid issues with removal of Array
parrot infrastructure: Tweety and Piper are gone.
parrot tickets:
TT #338 - remove dynpmc.pl
TT #1145 - remove some deprecated functions.
minor build updates, post one_make mergeback to trunk.
20:30 bacek joined
chromatic Hello, everyone. 20:30
whiteknight hello
japhb o/ 20:31
bacek aloha
japhb Thanks for the time change
Coke ~~
Tene Hi!
whiteknight +1 on time change
darbelo Hola
chromatic Let's review last week's priorities.
Util hrllo
NotFound hola
chromatic How are we doing on removing/demoting ops?
darbelo That didn't get done AFAIK. 20:32
chromatic I see a branch, but that's about it.
Okay. Does anyone have time to work on that?
darbelo I might have time to do some op->dynop. 20:33
Not guaranteed. But likely
chromatic Fantastic.
Feel free to recruit anyone else with time.
How about VTABLE removals?
Coke (dynops need to have their build process changed, btw. I'll try not to step on toes) 20:34
bacek They are depend on op->dynops migration afaik.
darbelo Didin't the VTBALES block on the dynops?
chromatic That makes sense then.
cotto_working I took a shot at trac.parrot.org/parrot/ticket/866 and realized that it should be closed given allison's input. 20:35
(vtable removal)
chromatic What should our current priority be for this week? 20:36
Are any branches close to merging?
bacek gc_enccapsulate almost done
whiteknight I'm looking forward to that one 20:37
chromatic Me too.
bacek I just need help with debugging.
And little bit more spare time...
whiteknight I'll fire up the ol' debugger tonight
bacek whiteknight, excellent!
chromatic I'm trying to find a list of our 2.3 goals. 20:38
Coke i haz a q.
whiteknight 2q
chromatic Hm, the spreadsheet has 1) Improved GC 2) Subroutine leave/exit semantics 3) Core libraries/plumage 20:39
Can we make another weekly goal to work on #1?
whiteknight +1
bacek I will rewire Boehm again after gc_encapsulate finished
chromatic I can commit to writing notes on the size-based tuning idea I have as well as the sweepless GC. 20:40
Anyone else?
allison we need to go through the 2.6 road map items and spread them over 2.3
and also enter the 2.3 items from the google spreadsheet
chromatic Is there a Trac wizard? 20:41
whiteknight those three items that chromatic mentioned are pretty big. Can we add more to 2.3 without overbooking?
Coke chromatic: I can be the trac wizard.
whiteknight GC and another PCC refactor will eat up some major time
Coke and what whiteknight said.
allison whiteknight: currently the spreadsheet lists "subroutine leave semantics/exit handlers" also, and "Core Libraries/Plumage" 20:42
the latter seems like a different group of people than the GC/PCC refactors, so no trouble being parallel 20:43
I suspect the exit handlers is a feature needed for Perl 6, but again, that is listed as pmichaud/tene working on it, so wouldn't block
chromatic I'd rather focus on one or two things that we're confident we can do and have to take on additional work if we finish early than try to do many things at once.
Coke then we should ask those people when it will land, not assume it's going to be 2.3
allison I would question whether we can do the GC and PCC refactors for 2.3 20:44
since it's pretty much the same people
japhb re: Plumage, I am just beginning to get tuits back from being slammed the last couple months. That puts me behind where I wanted to be; people who don't want to work on C code are welcome to spend tuits helping plumage
whiteknight GC is the bigger task of the two, methinks
allison whiteknight: agreed
PCC is in "final cleanup" mode, a few things we needed an extra deprecation cycle for 20:45
GC is really quite extensive, about where PCC was a year ago
(though, hopefully we can get through it faster than PCC did, using the dogpile method)
Tene PCC I'm confident I can help with. GC and leave/exit handlers, much less confident.
allison how about, PCC for 2.3, GC we start now and deliver partial for 2.3, more complete for 2.6? 20:46
whiteknight I would be interested in more information about leave/exit handlers too, I might be able to help with that
chromatic We'll always be tweaking GC.
whiteknight allison: +1
allison chromatic: indeed, but there are a few substantial tasks we need to tackle this year 20:47
the first task is "make a list of tasks that we need to tackle this year"
Tene whiteknight: it mostly comes down to "Whenever we leave this block, in any way, run this code.
chromatic allison, I'll make a list of tasks for GC changes if you make a list of tasks for PCC refactoring. 20:48
whiteknight Tene: gotcha.
allison chromatic: already done on the PCC refactoring
(that was my focus on two 8 hour flights this week) 20:49
chromatic Excellent.
Other discussion about this?
Tene whiteknight: even "Most normal ways of leaving this block" would be helpful, for now.
bacek I can try to experiment with VTABLE swap idea for GC from research.microsoft.com/en-us/um/peo.../index.htm
We can have Generational GC almost for free. 20:50
whiteknight bacek: I saw that paper too, very interesting. I would help with that
chromatic Can you both write a task list for that? 20:51
bacek Yes.
chromatic Thank you.
allison there is a GCTasklist wiki page, we can revise/extend it 20:52
chromatic Let's move on to questions.
darbelo?
darbelo We nned a better name for the ImageIO PMC. Got any? 20:53
whiteknight PMCSerializer
darbelo Ok, I'll go with that. 20:54
chromatic whiteknight?
whiteknight Trancendental math ops are moving to dynlib. I would like to move them to a separate project entirely so we can provide a more complete set of trigonometric routines without letting feature creep happen in the parrot repo.
is that cool, or do we keep them as-is in the repo?
darbelo Put in a deprecation notice and remove at the next deprecation cycle? 20:55
allison seems like a reasonable direction to head
whiteknight okay
and question 2:
bacek +1 20:56
whiteknight Parrot array types have bad performance in certain operations. Would like to create specialized types that are optimized for particular purposes (PMCStack, PMCQueue, etc). Better performance at the expense of limited feature set. Do these kinds of things belong in the repo, or do I create a separate project?
allison I'd start separate, then move them into the core if they become widespread 20:57
(this is assuming that it's easy to install them)
whiteknight okay, that's what I was figuring.
EOQ
japhb Whiteknight: Is the performance problem with current array types because A) There's no way you can optimize for each of these different purposes simultaneously, or B) because our array types haven't been all that optimized yet? (Like how perl5's have a lot of heuristics to speed up common use cases)
?
Coke I think they were ``optimized'' many years ago. 20:58
whiteknight japhb: just a lot of operations to support, and memory is not as flexible
push/pop/shift/unshift. It's hard to do those all well at the same time in the same object
unshifting and pushing grows the array at both ends, which is hard to do without spamming memcpy
allison plus, they're general purpose, and so have to support more features than a restricted stack/queue 20:59
Coke I'm not sure that we have benchmarks of the behaviors we want to be fast/memory efficient
japhb Nod. IIRC shift/unshift to implement a stack in perl5 (used to be?) much slower than push/pop to make a stack, so I see that point.
Coke Be nice to have requirements in place before we head off in (yet another) direction.
NotFound A deque can be good enough for stacks, queues, and such 21:00
allison Coke: it's true, but there are some classic aggregate datatypes that could be implemented pretty quickly
whiteknight I'll throw some prototypes together outside the repo, and anything we like we can move into core
stacks and queues could be made very efficient. Sparse arrays would be nice too
japhb Can we namespace these beasties, please? I'd like to have a decent library of efficient data structures, but not having them spam the top level PMC namespace.
Coke allison: sure, but writing code we don't need is a long standing problem we have that I'd like to avoid.
whiteknight japhb: done
allison just implemented a general-purpose graph in C that might make a good PMC
Coke: agreed, especially on coding for YAGNI 21:01
chromatic Anything else on this?
allison Coke: call it a prototyping exercise, kept out of the core to reduce maintainence burden
whiteknight Coke: to ease your worries, I'm writing this code anyway. No loss. Just wondering where it should happen
21:02 bacek joined
chromatic Coke, you had a question. 21:03
21:05 bacek joined
Coke whiteknight: if there are no benchmarks or requirements, then outside core. 21:05
chromatic: yes, can we get feedback on TT #679 (Rename Hash) 21:06
chromatic -1
Coke doesn't have to be here, but if anyone wants or doesn't want it, please comment on the ticket.
darbelo KeepTheNameItHasNowPlease
cotto_working -1 21:07
allison looking
bacek -1
allison the alternate names are pretty clunky, I'm not really fond of any of them 21:08
but, I'm conscious of the fact that only Perl uses "Hash" like that
and, of the fact that our ordered arrays all go for descriptive names
Coke java has hashmap. there's ruby...
whiteknight python and .NET I think use Dictionary
allison also, that the single Hash name doesn't leave room for typed hashes
whiteknight PMCHashTable? 21:09
Coke we have no typed hashes and no plans to create one.
allison (StringHash, IntegerHash, whatever)
japhb Dictionary is officially A Sucky Name.
bacek allison, current Hash support native types
whiteknight An IntegerHash is really synonymous with a sparse array
with maybe a few other methods
allison Coke: so, perhaps the question is "why do we have typed arrays"?
bacek we don't need typed Hashes
cotto_working We do kind of have typed hashes, but only from C.
Coke allison: an EXCELLENT question which I have been asking for some time. =-)
chromatic We're talking about renaming an intrinsic PMC used extensively everywhere. That's a huge HLL tax for little benefit. 21:10
allison bacek: sort of
bacek chromatic, +1
allison Coke: I'm happy to close the "Hash rename" ticket and open a "unify arrays" ticket
darbelo +1
japhb +1
bacek cotto_working, nope. They are available from PIR
allison, +1
allison (with the potential option to migrate the many types of arrays to an external repo)
Coke the question on the arrays should be, I think, the same one that should drive whiteknight's work: what are our requirements on containers, does what we have support that, and if not, how do we get there. 21:11
NotFound Just make sure that if we drop specialized arrays we don't have to recreate them immediately because of speed problems.
allison we've proved in CallContext that we can have typed storage in a single data structure, instead of forcing every element to be boxed/unboxed as a PMC
cotto_working +1 to array unification
whiteknight allison: we CAN do it, but lacks a certain efficiency
-1 on unification, especially if we lose tons of performance 21:12
particle +1 on trying it out
Coke there is no proof we have performance now, is there?
is there a benchmark we can look at?
allison whiteknight: it's certainly not as compact as a straight integer array that's one blob of memory,
whiteknight Coke: true, but we lose potential at least
bacek Coke, there is benchmark for arrays.
Coke let's /measure/ it before we worry aboutit.
allison and, we use those integer arrays heavily in the calling conventions at the moment
but, we can get around that
particle fixedintegerarray is the one important one
Coke bacek: excellent. then we can know if we lose anything.
NotFound Coke: I can wite one with winxed in a few minutes. 21:13
allison but, I'd really like to rip the fixedintegerarrays out of PCC anyway
particle convert that, benchmark with the unified array
whiteknight we WILL lose something, it's a measure of how much and how important that is
allison (cut down on the number of PMCs we create)
japhb Making a unified array implementation does not preclude having a special version that makes calling conventions faster.
allison japhb: or something within the CallContext PMC itself
japhb allison, right 21:14
allison yup
definitely worth exploring
Coke so, in any case, I'll close out the rename hash ticket.
whiteknight has to leave now. Will backlog. Later
chromatic Other questions?
particle sorry i haven't been around much. anything i need to know about, ping me in #parrot on privmsg me. 21:16
chromatic Last question: how does this time work for everyone?
bacek much better for me
Coke +0.5
cotto_working nicely 21:17
darbelo WFM
allison better for me too (I thought it was neutral, but it actually helps with the new class schedule this term)
chromatic Anyone it doesn't help?
allison did we get pmichaud?
japhb WFM
Util +0
bacek have to go. 21:18
Tene works great for me
chromatic We didn't get pmichaud or dukeleto.
Tene pm was active in #perl6 during the meeting. 21:19
darbelo I think dukeleto was +1 for the new time.
allison then perhaps it's a matter of spreading the new time
(i.e. people getting used to the new time) 21:20
Coke chromatic sent out the email. need to do that a few more weeks in a row.)
chromatic++
allison sounds like a "stick with the new time", I'll update my calendar 21:21
thanks chromatic!
Coke ... or you could just pull the event from the google calendar!
chromatic Thanks everyone; let's get back to work.
21:22 NotFound left 21:24 rdice joined, chromatic left 21:37 bacek left 21:48 plobsing left 22:06 PacoLinux left 22:11 allison joined 23:08 cotto_w0rk joined 23:09 cotto_work joined 23:25 Whiteknight 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!