#parrot Parrot 2.2.0 "Like Clockwork" Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: fix line number annotations | Finish GSoC applications
Set by moderator on 6 April 2010.
dalek rrot: r45545 | bacek++ | branches/immutable_strings_part1/src/string/charset/iso-8859-1.c:
Update iso charset's case-changing functions.
 00:02
rrot: r45546 | bacek++ | branches/immutable_strings_part1/src/string/charset/unicode.c:
Update unicode charset's case changing functions.
rrot: r45547 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Remove useless string clone - charset will allocate new string automatically.
rrot: r45548 | bacek++ | branches/immutable_strings_part1/include/parrot/charset.h:
Consting case-changing functions
rrot: r45549 | bacek++ | branches/immutable_strings_part1/src/string/charset/unicode.c:
Consting unicode charset.
rrot: r45550 | bacek++ | branches/immutable_strings_part1/src/string/charset (3 files):
Consting charsets.
rrot: r45551 | bacek++ | branches/immutable_strings_part1/src/string/charset/unicode.c:
Fix fallback to ascii charset.
rrot: r45552 | bacek++ | branches/immutable_strings_part1/src/string/charset/unicode.c:
More fixes to unicode upcase/downcase.
rrot: r45553 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Properly adjust bufsize in str_replace.
kudo: c99eeb3 | (Solomon Foster)++ | src/core/ (2 files):
Tweak the Any versions of unpolar and cis, define Real versions of the same.
 00:16
rrot: r45554 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Set proper charset/encoding str_append.
 00:19
Whiteknight bacek++ 00:20
(as if he needs it)
bacek Whiteknight, no I don't :)
Whiteknight karma bacek 00:21
purl bacek has karma of 2208
Whiteknight dayum 00:22
00:24 snarkyboojum left
bacek Whiteknight, "dayum"? 00:26
00:28 chromatic joined 00:30 tetragon joined
nopaste "bacek" at 58.107.108.21 pasted "chromatic, there is another epic fail with 2-args string ops." (9 lines) at nopaste.snit.ch/20237 00:30
chromatic More semantics which need to change. 00:33
bacek .oO ( Can we convince Gosling to work on Parrot? )
chromatic, yes. Easiest way - remove 2-args ops.
chromatic How do we look on benchmarks? 00:34
oofib should be interesting
bacek I didn't test it yet. 00:35
Heh. About 2x faster on branch :) 00:36
chromatic Let me get a visualization on trunk. 00:37
bacek hmm... 00:38
May be not.
chromatic 15% I can believe. 00:41
No, not a good benchmark for strings. 00:43
examples/benchmarks/hamming.pir 00:44
00:44 Whiteknight joined
chromatic Rakudo doesn't run. 00:49
No benchmark there.
bacek I expected it. What about hamming? 00:50
chromatic Not enough code running to make a difference.
We need something performing a lot of reflection, checking isa a lot, or passing lots of constant strings. 00:57
bacek chromatic, agreed... Do we have such test? 01:17
chromatic I usually use building Rakudo. I don't know of anything else, but maybe one of the gc_wave* benchmarks. 01:20
01:21 tcurtis joined
bacek yeah... It will require some more effort to resurrect PCT... 01:23
dalek rrot: r45555 | bacek++ | branches/immutable_strings_part1/src/string/charset/ascii.c:
Set new charset after converting.
 01:24
rrot: r45556 | bacek++ | branches/immutable_strings_part1/src/string/charset/unicode.c:
Fix unicode.titlecase
rrot: r45557 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Set result hashval to 0 in case-changing functions.
bacek chromatic, compact_pool killing constant strings... 01:37
chromatic That's strange. 01:50
nopaste "bacek" at 58.107.108.21 pasted "coretest summary with blocked compact_pool." (16 lines) at nopaste.snit.ch/20238 01:55
bacek chromatic, see nopaste. Many bugs just disappeared...
PGE builds 01:56
pbc_to_exe consumes too much memory for my box...
02:06 snarkyboojum joined
dalek rrot: r45558 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Clear more flags in Parrot_str_clone
 02:13
bacek chromatic, hooray. I've got same results on r45559 without disabling compact_pool. 02:18
Well... Almost. PGE segfaults...
dalek rrot: r45559 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Set flags explicitely in Parrot_str_clone instead of cleaning some of them.
 02:29
02:41 janus joined
dalek rrot: r45560 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Clear string flags in Parrot_str_append
 02:46
rrot: r45561 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Made str_concat synonim for str_append
 03:18
bacek msg chromatic pbc_to_exe epically failing on parrot-nqp. We do need StringBuilder... 03:19
purl Message for chromatic stored.
03:39 plobsing joined
chromatic Wow, pbc_to_exe is fairly awful now. 03:46
dalek rrot: r45562 | bacek++ | branches/immutable_strings_part1/tools/dev/pbc_to_exe.pir:
Quick hack pbc_to_exe to RSA for gathering string chunks instead of concatenating them all the time
 03:52
rrot: r45563 | plobsing++ | branches/stringnull/src/string/api.c:
more stringnullish goodness
bacek chromatic, r45564 04:04
chromatic, guess what? We invoke compact_pool on every single allocation of string...
chromatic Really? 04:06
bacek YA RLY 04:07
chromatic That shouldn't be. That's definitely a time sink.
bacek check mem_allocate
after compact_pool we will have very small amount of free memory 04:08
chromatic 22,877 mem_allocate, 40 compact pool.
bacek is it on trunk?
chromatic r45562 04:09
dalek rrot: r45564 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
Improve Parrot_str_join slightly. Still LTA but works much faster then original.
bacek anyway, on branch only 2-args string ops test failing.
we are ready to try rakudo
chromatic, interesting. During making "old" pbc_to_exe I found that we spent 99.9999% in compact_pool... 04:10
chromatic 66.91% for me on r45564. 04:11
bacek way too many 04:13
chromatic I agree.
bacek
.oO( CodeString.emit need some love. E.g. using RSA for chunks and then join them in one pass )
 04:14
04:19 Andy joined
chromatic I wish we could fix compact_pool in a couple of ways. 04:23
1) Don't make only one big pool. 04:24
2) Don't copy pools that are almost entirely full.
3) Don't loop more than once over the pools.
bacek "2" and "3" are conflicting 04:25
we have to pass over pool to check liveness flag
chromatic #3 is much less important than #2.
In theory, pool->guaranteed_reclaimable should be accurate though. 04:26
bacek In practice... 04:27
purl rumour has it in practice is valid
chromatic Segfault city.
nopaste "bacek" at 58.107.108.21 pasted "make _test_ summary on branch" (19 lines) at nopaste.snit.ch/20241 04:31
bacek chromatic, for now I do want to remove 2-args ops...
chromatic Let's get the memory use fixed first. 04:32
nopaste "bacek" at 58.107.108.21 pasted "patch for rakudo" (38 lines) at nopaste.snit.ch/20242
bacek chromatic, it almost fixed after reimplementing str_join 04:33
not perfect though
chromatic More than half the time compact_string doesn't free anything. 04:38
bacek and in second half it frees 5% of memory. 04:41
chromatic Much less fragmentation this way, I suppose. 04:43
bacek Price for this is too high 04:44
chromatic We compact way too much, but I cut out part of it.
bacek we can easily implement #2 04:46
about dozen lines of code
(and it will imply #1)
chromatic I tried once and failed, but that was before allison cleaned it up.
bacek chromatic, inline op substr(out STR, inout STR, in INT, in INT, in STR) :base_core 04:54
I do want to kill it...
It's awful...
it returns substr in $1 and cut it from $2 04:55
(at least on trunk...)
way too much semantics for single function... 04:56
chromatic + j = Parrot_utf8_encoding_ptr->to_encoding(interp, j); 05:03
What's that do, bacek?
bacek just to make all strings in same encoding
to avoid hassles with charset/encoding to calculate buflen and copy memeory 05:04
chromatic 16.96% of pbc_to_exe execution time there. 05:06
bacek hmm... 05:07
it's... weird
I convert joiner once
And pbc_to_exe should invoke str_join once
chromatic + next = Parrot_utf8_encoding_ptr->to_encoding(interp, next); 05:08
That's probably it.
I'm working on that function now.
bacek yeah. 05:09
It can be improved.
dalek rrot: r45565 | petdance++ | trunk (2 files):
consting and shimming
 05:14
chromatic This isn't quite right, but it's close and faster. 05:15
nopaste "chromatic" at 67.168.199.244 pasted "bacek: no PMC in Parrot_str_join()" (62 lines) at nopaste.snit.ch/20243 05:16
bacek chromatic, looks about all right 05:17
chromatic PGE doesn't build, so there's an off-by-one somehow. 05:18
Avoiding the PMC and the repeated encoding check helps a lot. 05:20
bacek chromatic, you can blindly memcopy strings with different encodings... 05:25
05:26 Andy joined, janus joined, tcurtis joined, TonyC joined, yjh joined, theory joined, sorear joined, moritz joined, zibri joined, ttbot joined, jhelwig joined, sjn joined, slavorg joined, Essobi joined, Util joined, pmichaud joined, jjore joined, pjcj joined, integral joined, Khisanth joined, ruoso joined, mj41_ joined, PerlJam joined, magnachef joined, s1n joined, NotFound joined, knewt joined, eiro_ joined, athomason joined, slavorgn joined, dukeleto joined, he joined, Hunger joined, sri joined, baest joined, bacek_at_work joined, Tene joined, Infinoid joined, treed joined, estrabd joined, GeJ joined, PacoLinux joined, wagle joined, cosimo joined, bacek joined, dngor joined, cotto_work joined, Austin joined, rbuels joined, silug joined, eternaleye joined, Coke joined, confound joined, solarion_ joined, purl joined
chromatic Yes, that doesn't help. 05:26
bacek That's why I converted all of them to single one. 05:29
chromatic bacek, we should store the encoding of the first string, compare the encoding of subsequent strings, and only convert if they're different.
bacek it will work. 05:30
chromatic That way we avoid any unnecessary work.
bacek hmm 05:31
Nope.
What about ascii?
chromatic The converting is expensive, not the comparison. 05:32
bacek can we single encoding/charset for strings?
sigh...
chromatic Not easily in this patch. 05:33
bacek Yes, but we should consider splitting String with one canonical encoding/charset and Buffer with "binary" encoding.
chromatic Definitely. 05:34
We can reuse a lot of string_rep_compatible() in the loop. 05:35
bacek in which loop?
chromatic The second loop, the one which does the memcpy. 05:36
bacek in join??? I don't see any string_rep_compatible 05:37
chromatic Right, but we should check that.
If the strings have the same representations, we can do the memcpy directly. 05:38
If not, we need to transcode them.
bacek We have to do it in first loop
Otherwise we have to reallocate memory
chromatic Ah, I see.
That's true. 05:39
... and it has to walk back through the loop. 05:46
bacek yes.
way too much work
chromatic We only have to write that algorithm once. 05:47
If we always transcode to UTF-8, every join suffers.
bacek agreed. 05:48
But we can do it later.
e.g. after fixing all test failures :) 05:49
afk # shopping 05:50
chromatic Ah, we can still do it in two passes. 06:28
Whoops, no. Grr. 06:31
nopaste "chromatic" at 67.168.199.244 pasted "bacek: this is closer" (108 lines) at nopaste.snit.ch/20244 06:38
bacek chromatic, why don't calculate total_length in second loop? 06:40
it will be simpler
ah, sorry 06:41
I see
Looks like you missed joiner (in third loop) 06:42
and we have to transcode it under "if(transcoded)" 06:43
Even better: if remove NULLOK from C<j> we can use it for initial c/e pair 06:46
07:07 fperrad joined 07:11 fperrad_ joined 07:36 eternaleye_ joined 07:50 payload joined 07:54 fperrad_ joined
dalek parrot: 4a007ea | dukeleto++ | plparrot.c:
This makes bad things happen
 07:54
parrot: 6cbdf6b | dukeleto++ | plparrot.c:
Attempt to correctly handle creating PG Strings from String PMCs
parrot: 3d523d8 | dukeleto++ | plparrot.c:
Make converting PG strings -> Parrot String PMCs work
07:56 payload1 joined
dukeleto PL/Parrot is now passing all tests. w00t! 07:56
bacek dukeleto, you need more tests! 07:57
dukeleto bacek: yes, i do :)
but it took about 3 months to get those tests to pass, so I will revel in it for a few more minutes :)
07:59 iblechbot joined
dalek parrot: dbe8b5e | dukeleto++ | plparrot.c:
Correct conversion from Parrot Float PMCs -> PG floats. All tests pass!
 08:00
08:18 szabgabx joined
chromatic Oh, that's what j is. That's the source of my problems. 08:30
... but I must sleep now. 08:31
09:01 cognominal joined 09:05 dalek joined 09:23 ruoso joined
dalek parrot: 1a02f12 | dukeleto++ | t/sql/test.sql:
Add a test for float return values and change test subs to be :anon
 09:24
parrot: 988f885 | dukeleto++ | plparrot.c:
Parrot_new_string -> Parrot_str_new
parrot: 74d4089 | dukeleto++ | plparrot.c:
Plug a memory leak in plparrot_make_sausage
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33115), fulltest) at r45565 - Ubuntu 10.04 beta i386 (gcc with --optimize) 09:30
09:32 snarkyboojum joined 09:45 fperrad_ joined 09:59 AndyA joined
mikehh rakudo (c99eeb3) builds on parrot r45565 - make test PASS, spectest_smolder (pugs r30362 -> #33116) FAIL - Ubuntu 10.04 beta i386 (gcc with --optimize) 10:03
rakudo - t/spec/S06-multi/syntax.rakudo - Failed tests: 21-22
rakudo - t/spec/S05-mass/properties-general.rakudo - TODO passed: 4-6, 11-13, 544-546, 550
rakudo - t/spec/S32-str/uc.rakudo - TODO passed: 17-20
moritz all of these are expected, except uc.rakudo, which is... worrying 10:08
sometimes it fails, sometimes it passes, soemtimes it passes TODO tests 10:09
mikehh moritz: my last run on amd64 it did not pass the TODO's but the one before that it did (PASS the TODO'd that is) 10:12
bacek msg chromatic I'm going to remove almost all "inout STR" ops. Strings are immutable anyway 10:53
purl Message for chromatic stored.
11:06 Whiteknight joined
Whiteknight Good morning, #parrot 11:09
LTA?
purl LTA is less than adequate, see also acronyms.thefreedictionary.com/LTA
bacek "Less Than Awesome" in Rakudo world :)
purl LTA is also "Less Than Awesome" in Rakudo world :) 11:10
purl okay, bacek.
bacek LTA?
purl LTA is less than adequate, see also acronyms.thefreedictionary.com/LTA or "Less Than Awesome" in Rakudo world :)
Whiteknight allison: ping 11:26
11:37 khairul joined 11:39 jan joined 11:40 payload joined
dalek kudo: 9406f55 | (Solomon Foster)++ | src/core/ (3 files):
Define Real versions of ceiling, floor, truncate, and round. Plus infix:<+>, infix:</>, and infix:<==>. Tweak Any versions, Real versions.
 11:44
11:45 payload1 joined
dalek kudo: ae2e81b | (Solomon Foster)++ | src/core/Bool.pm:
Add Bool.Bridge, because Bool somehow manages to be an Int (and do Real) without having Int's methods.
 11:50
Whiteknight tcurtis: ping 12:17
purl msg tcurtis: one feature that I think might be nice is the ability to tag a PAST node with a debug flag, and then have an optimization step that removes all such nodes from the AST. 12:20
purl Message for tcurtis stored.
12:32 joeri joined 13:17 Mokurai1 joined
moritz somebody needs to volunteer for mentoring tcurtis' gsoc proposal 13:25
it's the only one of the top 15 proposals that hasn't got a potential mentor yet 13:26
Whiteknight chromatic had been keen about it earlier. I was hoping he would
but I will volunteer for it now, to move the process along
done
any word yet on how many slots we will get? 13:27
moritz no idea
will be determined around Tuesday, I think 13:28
dukeleto, particle1: I hope you are aware that by tomorrow (don't know which time) all interesting proposals have to have a mentor assigned (not just possible mentors)
Whiteknight I can volunteer for all the parrot-related ones, for now 13:29
I would really like dukeleto to volunteer for the RTEMS ones
bacek aloha 13:30
what about tcurtis proposal? 13:31
Whiteknight good morning, bacek
bacek fsvo morning :)
Whiteknight it's always morning somewhere :) 13:32
and at the moment, I live in that somewhere
bacek my somewhere is far ahead of yours somewhere :) 13:34
Is parrot's GSoC projects under perl foundation umbrella? 13:36
Whiteknight yes 13:37
bacek Who can approve my mentor request?
chromatic? coke?
moritz bacek: dukeleto and particle1 13:38
bacek moritz, thanks
dukeleto, ping?
13:41 patspam joined
bacek ok, if no one else volunteer for tcurtis' project I will 13:43
(modulo my mentor request approval)
13:44 kid51 joined
Whiteknight bacek: I already did 13:48
bacek Whiteknight, ok then.
Whiteknight we only need volunteers now to assign slots
after the slots are assigned we can rearrange
bacek ok. Now I can sleep peacefully :) 13:49
night
good night 13:50
Whiteknight goodnight 13:51
dalek rrot: r45566 | whiteknight++ | branches/block_exit_handlers:
Creating new branch to experiment with exit handlers for rakudo
 14:17
rrot: r45567 | whiteknight++ | branches/block_exit_handlers/src (5 files):
initial test work
Whiteknight where should we put tests for PIR semantics? 14:36
t/pmc/sub.t seem lousy 14:37
t/pir seems decent, but that folder is mostly empty 14:39
14:39 ruoso joined
moritz time to change that :-) 14:40
14:43 sorear joined
dalek rrot: r45568 | whiteknight++ | branches/block_exit_handlers (6 files):
fix build. all tests pass
 14:50
particle bacek: done 15:08
particle wanders off for some breakfast &
15:13 tetragon joined 15:17 iblechbot joined 15:27 fperrad joined 15:38 theory joined, fperrad_ joined 15:45 jan joined 16:09 TiMBuS joined 16:40 PacoLinux joined
dalek rrot: r45569 | plobsing++ | branches/stringnull/src/pmc/string.pmc:
fix problems with string tests
 16:43
16:46 tcurtis joined
Whiteknight the meeting today, is it in here or in #parrotsketch? 17:15
dalek rrot: r45570 | plobsing++ | branches/stringnull (2 files):
fix replace on stringnull bug
 17:16
rrot: r45571 | plobsing++ | branches/stringnull (2 files):
don't copy stringnull from string pmcs
17:21 ruoso joined 17:22 payload joined
Coke how can we tell if a proposal has a real mentor instead of just a proposed one. click on it? 17:24
(is that it?)
dukeleto: ping 17:25
Whiteknight Coke: on the list it says "1 proposed", I suspect it would not say "proposed" onced a mentor has been affixed 17:27
Coke poked into a few of the parrot proposals, doesn't look like we have any assigned mentors. 17:28
(which, based on GSOC list traffic, is bad.)
Whiteknight Coke: what we need now is just proposed mentors 17:31
that's what the list traffic is talking about
17:31 brooksbp joined
Whiteknight we get slots assigned based on the number of proposals with proposed mentors 17:31
then when we have the slots, we can make assignments to them
brooksbp could someone with an ACM subscription please help me getting this paper? portal.acm.org/citation.cfm?id=1780.1803 17:32
dalek rrot: r45572 | plobsing++ | branches/stringnull (2 files):
stringnull preserved accross freeze/thaw
dukeleto Coke: pong 17:42
17:52 Tene joined
cotto dukeleto, who's Chris wrt RTEMS? 18:11
Whiteknight brooksbp: what do you need the paper for? 18:22
(I don't have an ACM subscription, just curious)
allison Whiteknight: I thought based on the list traffic that we need at least one mentor *assigned* to any proposals we hope to get funding 18:25
Whiteknight allison: I may be misreading, but I don't see there being any way to make an assignment right now 18:26
unless particle1 and dukeleto have magic controls that I cannot see
none of the proposals have an "assigned" mentor, not even the perl ones. Would have to suspect at least one would have gotten assigned by now if it was possible 18:27
allison Whiteknight: assignment has to be done by an admin 18:29
brooksbp: ACM has very sane rules on article sharing. Here you go: pub.lohutok.net/parrot/p603-georgeff.pdf 18:30
Whiteknight April 21 looks like the deadline when mentors need to be assigned
socghop.appspot.com/document/show/g...0/timeline
allison Whiteknight: yes, the deadline this week is just about allocating how many students each organization will get 18:31
Whiteknight: which they determine automatically on the basis of an algorithm they haven't entirely explained
Whiteknight: but supposedly the number of proposals with assigned mentors is a factor 18:32
Whiteknight yes. I think the confusion here is whether they're talking about "assigned" mentors at this point, or just proposed mentors
everything I've read has been very very vague on that point
allison Whiteknight: and they weren't very clear exactly how it's a factor, so I'm wondering if they're afraid of people gaming the system
Whiteknight right. If there's a question, I have no problem with being more conservative and assigning mentors. we need to kick particle1 and dukeleto into action 18:33
how many slots has TPF requested?
best documentation I've seen for how slots are allocated is here: socghop.appspot.com/document/show/p...llocations 18:34
18:48 davidfetter joined
allison Whiteknight: I don't know if they've requested any yet 18:54
19:00 Chandon joined
dukeleto i requested 15 slots this year 19:04
allison dukeleto: excellent! 19:05
purl Smithers, release the hounds!
allison dukeleto: do you know if it's proposed or assigned mentors they care about?
moritz allison: assigned
allison moritz: that's what I thought, but we don't have any assigned 19:06
moritz well, we should have :-)
the mentors can be swapped later on
but only proposals with assigned mentors will be considered
(has been discussed on that noisy google-summer-of-code-mentors-list@googlegroups.com list) 19:07
dukeleto looks at melange-pain now
is the summit starting in about 20 minutes? 19:09
allison dukeleto: yes, 20 minutes 19:10
purl 20 minutes is too fuckin long
dukeleto i shall notify the interwebs
sorear hello 19:11
purl privet, sorear.
Whiteknight are we going to talk about the proposals today at the summit? 19:12
if not, I think dukeleto can go through and just assign mentors to the various projects 19:13
dukeleto: is it 15 slots for all TPF?
dukeleto Whiteknight: yes 19:14
Whiteknight I guess parrot only needs 5 of those.
dukeleto Whiteknight: that is what I requested originally, before any proposals were in
Whiteknight ...and we damn well better get all 5 :)
both bubaflub and darbelo submitted two each, so we need to decide as a group which of them we prefer for each 19:15
and both of them applied to port to RTEMS, so obviously only one person can get that
19:15 mikehh joined
moritz Whiteknight: the votes on darbelo's proposals speak pretty clearly for NFG and against RTEMS :-) 19:15
Whiteknight moritz: the votes so far 19:16
but yes, it does look like people want darbelo's considerable talents devoted to NFG
dukeleto i haven't had time to look at any comments on the proposals. I have been enjoying my vacation too much :) 19:18
that, and making PL/Parrot work. All tests pass!
moritz \\o/
Whiteknight dukeleto++
vacation++
bubaflub's two proposals need more comments and input, we really don't have enough right now to draw conclusions about which of his proposals is preferred 19:22
dukeleto i just added a few comments to his RTEMS proposal 19:24
i have been talking with the rtems guys
it is also possible that parrot+rtems goes under RTEMS, i think. i think bubaflub applied to both orgs, but i would have to verify
purl okay, dukeleto.
dukeleto i am listed as a proposed mentor for rtems
Whiteknight darbelo did propose to both orgs. He says so in his application 19:25
dukeleto so i think that is the case
ah. it might have been darbelo that proposed to both. not sure about bubaflub
Whiteknight oh, okay
dukeleto we have until the 21st to sort all of this out 19:27
Whiteknight yes
summit in 3, correct?
moritz really? all the people on the mailing list said Monday (tomorrow)
Whiteknight moritz: tomorrow are preliminary slot estimates 19:28
the 21st is the hard deadlne for it
moritz ah, ok
allison Whiteknight: yes, 2 minutes
Util Whiteknight: summit time = correct
dukeleto i may just apply some mentors to various proposals and it can always be changed later
allison dukeleto: that seems to be the consensus on the gsoc list
dukeleto i see that now. it sucks that that is not on the timeline. They need to make better timelines 19:29
Whiteknight chromatic was interested in the PAST optimization one. I would be very happy with the threading one if nobody else wants it
allison I'm happy with either threading or strings 19:30
I suspect I may need to be more involved in the strings one
Tene Is the meeting taking place in #parrotsketch?
kid51 dukeleto: Are you going to be in Portland during the week in May when pdx.pm meets?
Tene or here?
purl it has been said that here is better than there
kid51 purl is correct
Whiteknight allison: I get that impression too, the strings one is a little more obscure and will need more design help
allison Tene: we advertised it as here
Tene: but, as there's a discussion going on here, should we move to #parrotsketch? 19:31
Tene I had to mumble mumble my neighbor's wireless, as I don't have internet in the new apt yet, but I'm here.
19:31 yobert joined
Whiteknight wherever it happens, /me declares this summit started 19:31
dukeleto kid51: yes
sorear if it moves to #parrotsketch, does that connote being closed to the public?
allison sorear: nope, still open
Whiteknight I say we do it here
dukeleto +1 to here 19:32
Whiteknight these discussions can either hold or be continued in the meeting
allison good for me, let's go
Welcome everyone!
japhb OK, here
kid51 is present
Whiteknight welcome!
purl Welcome to #perl. You will never find a more wretched hive of scum and pedantry.
allison The second quarterly virtual parrot developer summit
who's here?
purl i think here is better than there
moritz
19:32 purl joined
Util feels welcome 19:32
Whiteknight (+1 on making these meetings quarterly, by the way)
19:33 chromatic joined
moritz feel free to lift the ban once the meeting is over :-) 19:33
Tene present
Whiteknight moritz: probably better left the way it is :)
sorear also feels welcome
cotto hi
mikehh I am here
sorear Whiteknight: no purl = no karma from dalek
allison First, get our bearings and decide what we need to cover today. 19:34
kid51 sorear: We can live without that for a couple hours.
allison Would everyone please briefly look over the roadmap items for 2.6 and 3.0:
trac.parrot.org/parrot/roadmap
Plus the spreadsheet items for 2.6, 2.9, and 3.0.
spreadsheets.google.com/ccc?key=0Ah...DZ5cTdtYXc
We won't go over each one in detail here, but call out any you would like to discuss and we'll talk about them today. Also, what's missing from this list?
While you're doing that, I'll summarize what people unable to attend pre-contributed. 19:35
Jonathan reports that memory usage is much improved. Great work everyone!
There will be ongoing tasks there.
Whiteknight chromatic++ and bacek++ on the memory improvements
moritz can confirm that 19:36
sorear absolutely huge improvements, in the month I've been involved compiling rakudo has become 60 times faster with no change on the rakudo side
down from 12 hours to 12 minutes
chromatic Some changes on the Rakudo side: I fixed a few leaks there.
allison Other priorities for Rakudo *: error reporting (line numbers), block exit handlers, lexical implementation, performance in general.
Priorities after Rakudo *: NFG strings, concurrency, prototype-based OO, HLL interop.
François contributes: moving the build system off Perl5, chmod files, tar library, zlib library, and concurrency. 19:37
japhb calls out plumage quickly: I'm effectively unavailable, because of change of job status. Without helpers, I won't be able to do much for some time, sadly.
Whiteknight do we have tickets for all these things?
japhb very disappointed about that. :-(
allison I would like to talk about what our next big task should be. The most likely candidates seem to be GC, Concurrency, or Lorito, but the floor is open for other suggestions.
Whiteknight how late can concurrency be pushed back? We have potential for serious work to get done this summer 19:38
allison japhb: okay, that's a good thing to talk about today, see how to keep that rolling
chromatic Are you suggesting we discuss that now, or are you discussing an agenda?
dukeleto allison: i think the "security subsystem" needs to be on the roadmap somewhere
allison dukeleto: yes, that's on my todo list, but not on the current roadmap. will add it to the list for discussion today 19:39
Tene How do those three proposed tasks relate to each other?
sorear on the ticketed side, #566, #567, #568, and #1524 are the interesting ones to me, where interesting = perl 5 interop either helps these or is blocked by them
dukeleto allison: sounds great 19:40
sorear #1524 in particular has caused me quite a bit of headaches
allison sorear: thanks, note taken for discussion today 19:41
japhb BTW, Rakudo being able to do 'use Foo:from<parrot>;' would be really nice for Rakudo* ... I get specific requests for OpenGL working in Rakudo 1-2 times per week, so there's clearly interest.
Whiteknight okay, I think we're jumping in too quickly. What is the agenda today?
japhb Whiteknight, I thought we were posting suggestions for that. 19:42
19:42 bubaflub joined
allison Whiteknight: the agenda is exactly what we're putting together now 19:42
Whiteknight japhb: ah, okay. didn't realize there was method to this madness
japhb :-)
bubaflub sorry i'm late ya'll, deacon's meeting at church ran late. i'm reading the back log now
Tene As soon as I get things settled here with new apt and new job, HLL interop is high on my priority list. 19:43
allison bubaflub: we're doing a quick run through the roadmap for 2.6, 2.9, and 3.0 to decide what topics we need to discuss today
dukeleto NOTE: I am assigning some temporary mentors to GSoC proposals now, so we make tomorrows ill-communicated deadline
sorear I don't think we can really do much about HLL interop without an implementation to experiment on
bubaflub allison: awesome. 19:44
cotto dukeleto, thanks.
sorear my plans for HLL interop are basically "implement :from<perl5> by irreverent hacking on Rakudo and Blizkost, and when it works, rewrite PDD-31 to match the working code"
allison Okay, here's the current agenda, anything you'd like to add or remove from it? 19:47
- error reporting (line numbers)
- block exit handlers
- lexical implementation
- performance/memory usage in general
- plumage (project priority, how to boost resources, how far along is it? what does it need?)
- NFG strings
- concurrency (wait for GSoC?)
- prototype-based OO
- HLL interop
- moving the build system off Perl5
- chmod files
- tar library
- zlib library
- security subsystem
- next big task: GC/Concurrency/Lorito/?
- #566, #567, #568, and #1524
How about process discussions?
Whiteknight process discussions are always good 19:48
allison any pros or cons of the current process, or suggested changes?
chromatic Suggestion: review of the 2.3 release, process questions, roadmap review.
Tene re error reporting, I have some fixes for that in my exceptions_refactor branch. I can elaborate.
sorear what's the significance of 3.6, why do we have tickets assigned to it?
parrot version
mikehh how essential is it that we maintain all the different runcores?
allison sorear: it's one of the "supported" releases
sorear: the last one in the current roadmap 19:49
mikehh: good question, will add to agenda
Whiteknight after that, parrot is "finished", and all commit bits are revoked
...or we just extend the roadmap
bubaflub dukeleto: to answer your previous question, i also applied to both TPF and RTEMS (but failed to mention it) 19:50
allison and the flying spaghetti monster comes to take us all to the big saucepot in the sky
dukeleto bubaflub++
Whiteknight allison: agenda looks good to me 19:51
allison chromatic: added 2.3 review and process questions to the start of the agenda, roadmap review to the end
cotto do we want dalek active during the meeting?
allison cotto: the archive would be useful
sorear (I'm also interested in (rudimentary) ordered sweeping from the roadmap, but I don't think it needs to be on the agenda)
dukeleto what is realistic to accomplish for 2.3 ? when does the 2.3 new-feature-commit-freeze start ?
Whiteknight gerd is release manager for 2.3, he would know
allison chromatic: (that is, we're doing a roadmap review now, but may want more detail later) 19:52
chromatic Okay.
allison Okay, agenda set, let's begin.
- review of the 2.3 release
- process questions
- error reporting (line numbers)
- block exit handlers
- lexical implementation
- performance/memory usage in general
- plumage (project priority, how to boost resources, how far along is it? what does it need?)
- NFG strings
- concurrency (wait for GSoC?)
- prototype-based OO
- HLL interop
- moving the build system off Perl5
- chmod files
- tar library
- zlib library 19:53
- security subsystem
- next big task: GC/Concurrency/Lorito/?
- runcore support, can we trim the list?
- #566, #567, #568, and #1524
- roadmap review
2.3 release, what went well, what went badly?
any lessons to learn from it?
dukeleto allison: do you mean 2.2 ?
Whiteknight is 2.3 out? isn't it 2.2?
chromatic The deprecation policy change seems to have worked better.
dukeleto looks back from the future
allison chromatic and I seem to have a telepathic link and both knew what we meant 19:54
Whiteknight agreed on the deprecation policy. I'm not 100% happy with it, but less restrictive than it ws
allison yes, 2.2
cotto double-checking the release announcement subject is highly recommended for future release managers 19:55
Whiteknight wasn't much notable about 2.2, to my recollection. Smooth, normal release it looks like
allison Whiteknight: can you elaborate on the remaining pain points?
dukeleto allison: sorry, it slipped my mind, but conversion to git should be on the roadmap as well
bubaflub dukeleto++
cotto +1
allison Whiteknight: (with respect to deprecation policy)
dukeleto: okay, added to agenda 19:56
Whiteknight allison: oh, nothing new since the last summit. would still prefer an opt-in system than an opt-out one, but I won't harp on it here
it's not so bad that it's worth arguing about now
allison Whiteknight: okay, good to keep it in mind though, thank you
any concerns or questions about the upcoming 2.3 release? 19:57
this is a supported release
mikehh possibly need to add updating parrot web sites to the notes
allison one thing I'd like to see is package testing for various distributions before the release
Whiteknight +1 on package testing 19:58
allison I had some painful points in Debian packaging for 2.0 that were entirely avoidable
cotto Where's that testing process documented?
Whiteknight I'm happy to help with debian packaging this goround
allison (things that would have been trivial to fix in advance like new executables without manpages)
cotto: the testing process is essentially "build a package from the current trunk, try it in the target distro" 19:59
dukeleto is it documented anywhere which 3rd-party packaging parrot is a part of ? such as: rpm's, deb's, freebsd port, etc... 20:00
allison what we don't have, and need, is a test suite that runs on an installed parrot
that would make a *huge* difference to package testing
dukeleto allison: i would like to work on that
allison dukeleto: okay, taking a note of that as a possible roadmap task
Tene where in the priority queue is reworking the build system to look like an installed parrot? I've seen that mentioned several times in the past. 20:01
allison dukeleto: (it's certainly a good task, even if it's not on the roadmap)
mikehh I can certainly help with the testing
allison Tene: it's not currently in the priority queue, but it's on the list
Tene: it dropped in priority when Patrick said he didn't need it anymore
Tene 'k 20:02
allison mikehh: thanks, I'll note you as interested
sounds like we're wrapping up on 2.2 and 2.3
chromatic, would you like to run process questions? 20:03
chromatic Any discussion of what we implemented in 2.1 - 2.3?
japhb (afk for a couple)
allison as mentioned earlier, the 3 month deprecation cycle seems to be working well 20:04
chromatic We clawed back some performance related to PCC.
dukeleto a big +1 to the 3 month dep cycle
mikehh +1
chromatic Anything else on implementation? 20:05
Whiteknight nope
chromatic Okay. Process questions. 20:06
What's working in our process?
I've heard only praise for shorter deprecation cycles.
Any other changes we've made that work out well?
Whiteknight yes, shorter cycles are better
moving the #ps meeting later seems to have not caused a negative effect 20:07
dukeleto PSA: All 24 valid GSoC proposals now have temporary mentors assigned.
sorear PSA?
chromatic Any thoughts on moving #ps?
japhb (bak)
allison chromatic: we discussed it and decided to stay on #parrot
Whiteknight the move plus daylight savings has given me some troubles, but nothing major
mikehh works fine as it is for me 20:08
Whiteknight allison: he's talking about moving meeting time of weekly #ps
allison chromatic: restarting the roadmap review each week has been helpful
Whiteknight +1 to weekly roadmap review
allison Whiteknight: (ah, thanks for the translation)
chromatic Talking more regularly to #perl6 seems to have helped set priorities too.
dukeleto sorear: PSA = Public Service Announcement 20:09
chromatic Any other positives in the process? 20:10
dukeleto i think parrot is doing well welcoming new devs via GSoC 20:11
sorear dukeleto: ah
20:11 AndyA joined
chromatic GSoC appears to be going very well. 20:11
allison just added JIT to the agenda
Whiteknight yes, lots of quality submissions
very very high quality submissions
chromatic We seem to be attracting more contributors. 20:12
sorear Is that good?
allison sorear: contributors are always good
Whiteknight sorear: we burn them for warmth
chromatic Let's move on. 20:13
What could we improve?
We still seem to drop about half of our weekly priorities. 20:14
Whiteknight we may have too many of them
mikehh rakudo has a policy of NOT closing a ticket until an appropriate test is added to the test suite
allison I'm concerned that our roadmap is cluttered with "priorities" that don't really matter anymore 20:15
bubaflub i browsed the ticketing system recently; there is a lot that is stale in there
chromatic Let's take these in order.
Do we set too many weekly priorities?
allison yes
(IMO)
cotto yes 20:16
japhb But the reason for that seems to be "dear god, let one of these please stick"
Whiteknight priorities are like herding cats. We can never get more than a handful of people working on any priority
kid51 queue 1 not-doing-so-well issue
allison they seem to change too often
Whiteknight allison: too often? so is the alternative to set monthly priorities?
allison or, perhaps they're just not fine-grained enough to be 1-week tasks?
chromatic Or are they too specific to attract people?
allison a weekly priority should be specific 20:17
cotto not everyone will be able to do every task, even if willing
allison well, okay, the alternative is to say the weekly priority isn't a task to complete
Whiteknight a weekly priority should be small enough for one or two people to complete. We're not going to get more than that on a regular basis
bubaflub for me, i'm not knowledgeable enough the areas to contribute significantly. i'd love to have someone assigning me stuff directly and pointing me in the right direction
allison like "this weeks priority is testing"
or "documentation"
dalek rrot: r45573 | chromatic++ | branches/immutable_strings_part1/src/string/api.c:
[str] Revised Parrot_str_join() to avoid creating a new PMC and to transcode

prettifying.		 20:18
allison they should either be general with no "completion" goal, or small and specific and easy to complete within a week
Whiteknight allison: like a central thrust, instead of a finite task?
chromatic Given our experience landing branches when we hack on them, we can get a lot done if two or more people collaborate on something.
allison Whiteknight: yes, we seem to mix up the two
Whiteknight maybe policy that we don't assign a weekly priority unless we have at least two people who can work on it reasonably 20:19
allison chromatic: that's definitely true, but branches often can't be completed in a week
bubaflub agreed. that way two people of varying skill can work on something together.
chromatic That sounds reasonable.
Whiteknight saying we want something as a group, but nobody volunteers up front to do it, means it won't get done
allison +1
chromatic I've been trying to create task lists on the wiki, in the hope that that will help attract people who want something to do. 20:20
dukeleto chromatic++ # task lists are very good
dukeleto goes afk. will respond on parrot-dev if i miss my questions 20:21
chromatic Are they useful?
kid51 task lists are good if you know they're there.
I was not aware of those lists.
Whiteknight chromatic: link to your tasklist?
kid51 I tend to follow the "last modified tickets" approach, myself. 20:22
allison Alright, we'll try that for the next cycle: weekly priorities are specific tasks, completable by 1-2 people in a week, and won't be set unless we have people volunteering for them.
Whiteknight +1
chromatic See trac.parrot.org/parrot/wiki/FixingP...eOverrides for example.
Whiteknight oh, you've been making specific tasklists, not a large general one
chromatic Right.
Whiteknight okay, I misunderstood
chromatic Any other discussion of weekly priorities? 20:23
allison Sounds like no
On to the remainder of the agenda...
chromatic Next discussion point: are some of our long term priorities stale?
allison yes 20:24
kid51 By 'long-term' you mean ...?
chromatic Milestone priorities.
How far in advance can we predict what we'll need? 20:25
allison the solution there may simply be a more aggressive approach to dropping things off the roadmap at the weekly meetings
that doesn't delete the ticket
Whiteknight the further away the milestone is, the larger and more general tickets should be 20:26
allison it just removes the clutter so we can use the roadmap to focus on the things that are really important for a particular release
Whiteknight as milestones get closer, we start replacing general ideas with specific tasks
mikehh the problem being that removing from the roadmap put it to sllep often
chromatic Do we need a wishlist? 20:27
mikehh it gets forgotten
allison yes, 3.6 has a ticket "pluggable everything" which is good and general for a release that far away
chromatic Maybe we only schedule for the next milestone release, and leave everything else as wishlist.
allison mikehh: yes, I think that's where most of the clutter is from, so perhaps we need another way to mark tickets as priorities
Whiteknight I like that idea, not schedulign too far in advance 20:28
allison there's a difference between "this is important" and "this needs to happen at release X.X"
chromatic I get the impression that we're not very good at predicting priorities more than a few months in advance.
allison we do have a priority tag on tickets, should we take that more seriously? 20:29
mikehh the problem being that important things keep getting moved further down the line
japhb The advantage of having gone through the scheduling process was *not* getting a decent roadmap, but rather discovering our real priority order, instead of "everything's important".
sorear 3.6 also has a ticket for ordered GC
allison chromatic: well, no one is really able to predict work 2 years in advance, that's not really the purpose of a roadmap
chromatic Right, but bumping things from milestone to milestone is busy work.
allison yes, exactly, that's what we need to stop 20:30
chromatic If we're not going to work on it in the next three months, does it matter when we have it scheduled?
japhb chromatic, I don't disagree. My point was that perhaps we need to focus on the sorting aspect, and less on the scheduling aspect.
allison for some things, yes
chromatic That's a good point, japhb.
allison as a practical example, the import HLL tickets shouldn't be on the roadmap 20:31
Whiteknight is the roadmap a listing of things that we would like, pie-in-the-sky, or a listing of things we actually think we can accomplish?
allison they're not tied to a particular release, they're just a general priority
sorear +1
Whiteknight so instead of a roadmap, would it be good to just have a prioritized wishlist?
japhb Whiteknight, my feeling is a listing of things we want to achieve, roughly ordered by how important it is to us and how likely we can get it done. Unfortunately, the last two are often at odds. 20:32
allison other things are important to keep in mind as tied to a particular release
chromatic The nice thing about the roadmap is that it helps us decide what we're *likely* to do for the next milestone.
japhb Which leads to sorting that is the difference of two fuzzy numbers, and essentially random. :-(
chromatic If we know we can do three big things per milestone, we pick our top three.
... but we're not good at knowing what we can do per milestone.
japhb chromatic, very true. 20:33
allison though, honestly, I'd reserve the roadmap items for "big plans" rather than "small tasks"
tcurtis japhb: why not list both the importance and the feasibility separately and allow sorting by each?
Whiteknight tcurtis: that's not a bad idea. No idea how easy it is to do in trac
allison and really, I'd be fine with only having roadmap items for supported releases, and not for development releases
japhb tcurtis, a decent idea, though as chromatic stated we're rather poor at the second number. 20:34
Whiteknight allison: +1
chromatic Let's take proposals then.
What changes should we make?
japhb So: weekly: inch-pebbles, monthly: branches, quarterly: milestones? 20:35
allison japhb: I like that
chromatic Makes sense to me.
mikehh and also to maintain a prioritized TODO list
allison So, every week we review our weekly, monthly, and quarterly priorities 20:36
Whiteknight yes
chromatic and we need to schedule warm bodies on weekly priorities, otherwise they fall off our list
Whiteknight where hopefully we have fewer tasks in longer-term queues
allison mikehh: sounds like a wiki page
japhb mikehh, I'd actually like (at least) two at the different granularities I listed. Keep big things only in our milestone priorities, keep small things only in our inch-pebble priorities. 20:37
chromatic, quite.
chromatic How will we know if this experiment works?
japhb I think mixing the sizes of priorities has led to trouble.
allison if we complete more weekly priorities 20:38
japhb Or at least, higher percentage of the ones we set for ourselves.
allison and spend less time reviewing pushing around roadmap items
and if we deliver on all the roadmap items for 2.6
chromatic Other comments? 20:39
allison (which would mean we both selected the right items and focused developer effort on them)
chromatic Can we all commit to trying this for 2.6? 20:40
allison does
japhb In so far as I have any time to give ...
chromatic I'm all in. 20:41
Whiteknight? cotto? dukeleto?
cotto yes
Whiteknight I'm in
allison dukeleto is afk 20:42
chromatic Okay, let's move on.
Stale tickets in Trac.
allison we're at 661 active tickets 20:43
cotto Coke's been good about trolling old tickets regularly.
allison not bad, really
kid51 That's about 40 more than has been our traditional average.
chromatic I'd rather be under 500.
allison yes, agreed 20:44
japhb chromatic, what's magical about that number, aside from being round?
allison it's just at the level of "let's to a ticket-a-thon next weekend"
bubaflub my problem was that it makes it hard to just jump in and take a ticket that's in there; the priorities list and task list mitigate that immensely
allison not at the level of "emergency!"
20:44 smash joined
smash hello everyone 20:44
allison hi smash
sorear hello
chromatic 500 is nice because we can close 50 more tickets than we open per release.
allison are there any suggestions for improving our ticket handling process? 20:45
chromatic Ideas for reducing the number of stale tickets or preventing tickets for going stale?
japhb chromatic, meaning you're aiming for ~0 in ~1 year, or meaning, you're aiming for ~500 in ~2.6 timeframe? 20:46
cotto clear closing conditions are important
Whiteknight cotto: +1
vague tickets don't help. There must be a clear standard for how we know when it's done
chromatic Do we need ticket closing guidelines?
japhb It would be nice if tickets could get tests in such a way that we can see when they turn green and close the ticket. 20:47
allison I would like to suggest that we don't follow Rakudo's policy of keeping tickets open until they're tested, but instead open a separate ticket for the tests
Whiteknight allison: what are the benefits to that?
japhb Might need to ask people in the project to help those outside who don't know how to make tests for their problem.
allison it forces someone to clearly define the task of creating the test
instead of lingering discussion of old issues after they've been resolved and implemented 20:48
chromatic Do we use Trac as a dumping ground for low-hanging fruit, hoping that someone will pick up almost-done small tasks?
japhb allison, Rakudo partially gets away with that because masak is really good about the precision of his initial reports.
Trac does not seem to have good uptake. People don't just wander over and start browsing it for work.
allison old tickets can be daunting to tackle when you have to spend far-too-long reading before you realize all that's let to be done is a simple task
brooksbp Whiteknight: it's to understand how to implement closures on the stack
chromatic Maybe we're using Trac for the wrong things. 20:49
allison it is intended for bug reports
japhb Or we're using Trac wrong. (giving it the benefit of the doubt)
allison we're using it for project planning
chromatic Right.
allison that was actually my complaint about RT too (using it for project planning) 20:50
do we have ideas for a better way to do project planning?
sorear quarterly meetings?
allison yes :)
but then, how to remember the details of the plan between quarterly meetings 20:51
chromatic Separate our two artifact repositories: the wiki/spreadsheet for milestones, Trac for bugs.
bubaflub i'm a big fan of the task list / priority list
allison how to keep track of what needs to be done
kid51 Since the barrier to filing a ticket is low, almost anyone can do it. That means someone who is peripheral to the project can file a ticket saying, "Parrot should implement X."
allison the spreadsheet is terrible for tracking milestones
kid51 That person doesn't have to promise any effort to achieving X.
allison (I say that with authority, because I've been maintaining the spreadsheet)
kid51 So the ticket remains open until one of the core committers takes a stand and says No, we're not going to do X. 20:52
chromatic Do we need to find something better than the spreadsheet?
japhb kid51, that implies trying to be aggressive about converting wishlist tickets to task list items, and closing the 'bug'
Whiteknight yes, definitely need somethign better than the spreadsheet
allison tickets are better than the spreadsheet, but I suspect there's something better than tickets
kid51 japhb: Then perhaps I should go thru RT and reclassify many tickets as wishlist.
chromatic How about a wiki page?
kid51 s/RT/TT/
allison I'm not sure about a wiki page 20:53
it works well for branch tasklists
chromatic List our milestone priorities at the top, link them to tasks, then make everything else below that line an obvious wishlist item.
japhb kid51, you know, even if we don't close the TT's that are wishlist, just *classifying* them as such allows us to separate them in reports.
allison but, I suspect a wiki may not scale well to 661 tasks
willing to give it a try, though
are there other suggestions for tools? 20:54
chromatic A wiki page can display 661 tasks without having to page through at 20 a time.
japhb I certainly think it's a good idea to make a pass on the TT's to separate bugs from feature requests.
allison aye, but scrolling still means you can't really focus on all of them at the same time
you have to page through in one way or another
chromatic We have two real needs though: what should we be working on this quarter and what do we want to remember the next time we schedule priorities?
cotto is there a tool to embed reports in a wiki page?
kid51 japhb: Yes. There are times I've been reluctant to close a ticket because I don't want to discourage the ticket creator from being interested in Parrot.
allison and, a wiki doesn't do well at sorting, selecting, etc
kid51 ... and frequently these are people who formerly were very active in Parrot. 20:55
Whiteknight a combination like bugzilla + testopia might be nice
allison kid51: would it help if we had a process to review those tickets in parrotsketch?
kid51 If TTs (particularly their initial descriptions) contained links to wiki pages, I'd be more inclined to go peruse the wiki. YMMV 20:56
allison kid51: so we could say "thanks for your suggestion, the development team has reviewed your suggestion and decided this feature isn't a priority at this time..."
Util Reminder: any Trac ticket list can be downloaded in csv or tsv format.
japhb kid51: +`
er
+1
chromatic Let me ask the question a different way. What *value* is there in keeping wishlist items in Trac?
allison kid51: at least they'd know they got our attention
kid51 allison: Well, I could go thru the list, make a list of TTs to reclassify as wishlist, and post that before #ps some week
allison chromatic: it all boils down to not wanting to lose good ideas 20:57
chromatic What value is there to keeping them *in Trac*?
allison chromatic: that's pretty much our entire data management problem
chromatic That's what I'm saying.
allison ah, Trac, well that's about selecting and sorting
the ability to manipulate the data
chromatic Trac is a big black hole of suck where wishlist items enter and may never leave. 20:58
allison it's not great, but it's better than a spreadsheet or a wiki page
chromatic How is it better than a wiki page?
allison selecting, sorting, tagging
kid51 allison: agreed
chromatic How is sorting and selecting useful?
Look at some of the wishlist items in Trac and tell me that they have sufficient detail to review?
allison because you can focus on a particular group of tasks/ideas
and, regroup them depending on what your interest is at a particular time 20:59
without having to manually move data around
chromatic Most of the wishlist items are useless. They're inspecific. They're vague. They're stale.
allison remember, we started the roadmap in the wiki
japhb If I'm understanding chromatic correctly, he's saying that the theory of Trac usefulness does not match the reality of our actual Trac entries.
allison it was a terrible pain
Util In trac, varying amounts of detail and history do not lend weight to the more-documented items.
chromatic Wishlist items are documents. Trac tickets are linear conversations.
allison we spent an enormous amount of time manually munging data around
agreed on wishlist as a document 21:00
chromatic Then why are we cramming documents that need to evolve with collaboration into bug reports?
allison by linear conversations you mean comments??
chromatic Reporter: this doesn't work. Developer: please try this patch. Reporter: yay! Developer: ticket closed. 21:01
Whiteknight so move wishlist back to the wiki?
chromatic That's my suggestion.
Whiteknight we do have a large assortment of tasklists
maybe those already are what we need
allison I'm good with wishlists as wiki pages
kid51 If we were to track wishlist items *only* on the wiki, then we would have to decide how to react when someone (newbie, oldbie) files a TT which is essentially a wish or new feature request. 21:02
allison perhaps one grab-bag wishlist page for people to add random feature requests to
chromatic Sure, that would help.
cotto Ticket numbers are automatically crossed off when the relevant ticket is closed. That'll help some.
allison and specific pages for specific larger items
chromatic kid51, migrate the request to the wiki and close the ticket.
allison kid51: I'd say politely move it over to the appropriate wiki page, and close the ticket 21:03
chromatic That way, tickets represent only the need for concrete work: fix a bug, update the documentation, schedule the artifact.
allison and also, include discussion of how we use wiki pages for wishlists in the "report a bug, make a request" documentation
Util kid51: Update ticket with "after this conversation [url] on the topic in #parrot, this item is being moved to the wishlist: [url]", then close ticket.
kid51 Is there one, definitive Wishlist page in the wiki?
allison kid51: not yet, that's one of the things I suggested adding 21:04
kid51 k
Whiteknight kid51: we have several. We could have one unsorted grabbag
chromatic We're moving into suggestions. Shall we make these concrete?
kid51 yes
allison I'm not ready to give up tickets for roadmap items
unless we have a better solution
chromatic What do you see as the value of tickets for roadmap items?
allison selecting, sorting, etc
basically, avoiding the pain that was the old wiki 21:05
chromatic That's inspecific; I don't know what you're trying to do with "sorting, searching, etc".
allison though, really, a lot o the pain of the old wiki roadmap page was exactly the same pain we just discussed removing for the ticket-based roadmap
too many items that aren't really priorities 21:06
too much thrash
bumping tasks from one release to the next
chromatic Trying to schedule too many milestones in advance.
allison so, if we follow our new strategy for the roadmap, that may make a wiki page perfectly feasible for the roadmap
chromatic Is it worth experimenting with? 21:07
allison yes
chromatic Okay, let's get to specifics then.
allison I'm willing to do the legwork of transforming our roadmap tickets to a roadmap wiki page
chromatic Which concrete changes should we make?
Migrate wishlist tickets to a wishlist page?
allison It sounds like the proposal is: only use tickets for bug reports. 21:08
chromatic Someone needs to write Trac guidelines then; I can do that.
allison It's radical, but seems cleaner, easier to maintain.
chromatic Other suggestions?
japhb No good ones. :-) 21:09
chromatic Okay. Can we commit to changing our philosophy of Trac?
+1 from me
cotto yes
chromatic kid51?
japhb +1
chromatic Coke?
allison yes
should we discuss this on the mailing list before making a final call? 21:10
giving people who aren't here a chance to think it over?
japhb +0
chromatic It'll be part of the notes for this meeting. Do we need something more?
kid51 yes, but mailing list post would be helpful;
allison we'll definitely do a post-meeting summary 21:11
chromatic I can write highlights of our changes.
allison I'll wait until after this week's parrotsketch to do roadmap conversion
(there's some chance someone may have a better idea)
chromatic Anything else on stale tickets?
cotto A message to the list would help reinforce the commitment to this change if nothing else.
bubaflub do we have a definition for "stale"? i like to think of a ticket that hasn't had any comments in 6 months 21:12
chromatic Sounds reasonable to me.
Whiteknight a definition like that would be easy to automate in trac with good SQL
chromatic How do we measure success for this experiment? 21:13
cotto Yes. A "stale tickets" report would simplify life a little.
allison we're 15 minutes from the proposed end of the meeting 21:14
japhb I'm not sure how to measure this in a way that doesn't say more about something else.
I blocked three hours, just in case.
chromatic Success condition: Trac is more useful?
kid51 yes 21:15
allison Trac becomes more managable, containing only actual bug reports
chromatic We close more Trac tickets per release?
allison we manage to keep the number of Trac tickets below 100 through 3.0
japhb chromatic, yes, certainly -- just I have no way to measure it, other than people's satisfaction. Which I guess we could just ask about in #ps ....
chromatic All of these work for me. Any more discussion here?
Whiteknight no 21:16
sorear we still have the entire agenda left
oh, here
allison so, next question, extend the meeting, or reconvene at a later date/time
chromatic +1 to extend here
japhb +1 to extend
allison I'm inclined to extend
cotto +1
kid51 +1 to extend one hour max
Util +1 21:17
allison current hour +1 at half-past the hour
Whiteknight okay, lets rocket through the rest of the agenda
allison the rest is more design related
ready? 21:18
and...
go
Whiteknight ready!
allison - error reporting (line numbers)
chromatic I'm blocked on a testing framework for that.
allison this is a substantial priority for Rakudo
it is a task being actively worked on now
japhb You might be able to leverage the code in the weaving tool I wrote way back when
(I'm NOT volunteering, I'll just be a block) 21:19
cotto It's messy but I think I'll have a test to check line numbers of pir files somewhat working by #ps.
allison do we have a good handle on what needs to be done? (sounds like yes)
do we need to get more resources on it?
chromatic Given that test, I can start to fix things (and explain how to fix them).
cotto It's a smop and I have enough tuits in the immediate future. 21:20
Tene I've already got a fix for line reporting confusion under rethrow in my exceptions_refactor branch.
japhb Ah, here it is: .../parrot/tools/util/dump_pbc.pl
allison Jonathan mentioned error reporting as a more general category, are there specific tasks we need to be thinking about there?
japhb The code in there might be useful to whoever is working on this (cotto, I guess)
cotto japhb, quite 21:21
Tene (I'd like to report both the original and rethrown location, maybe.)
I expect to be able to get that branch merged into trunk in the near future.
allison Tene: reporting both seems sensible
Tene: especially if we can track it as "rethrown at..." 21:22
sounds like no one is aware of other error reporting issues, so that's one to take back to Jonathan 21:23
anything else on error reporting and line numbers?
cotto not from me 21:24
Whiteknight NEXT
allison a more general question on these items, do they become high-priorities in the new wiki pages?
think about it while we're running through
- block exit handlers, TT #1523 21:25
this is a priority for Rakudo
Whiteknight I started a branch to play with that
I think I need more info from the rakudo people first
allison how big does the task look?
Whiteknight depends on what they need
could be small, could be impossibly large
there are lots of ways to exit blocks
allison okay, this sounds like one that needs spec work 21:26
Whiteknight exactly.
allison possibly a PDD
basically, handler semantics
we'll spend time with Jonathan, etc to figure out what they need 21:27
Whiteknight yes, that would be perfect
allison - lexical implementation
another one for Rakudo
bacek ~~
chromatic Is that primitives stored as lexicals?
allison I don't have a good sense yet of what changes they need
Whiteknight yes, jonathan's email was not very detailed 21:28
allison he spoke of "proto-lexpad"
chromatic Not enough detail to schedule.
allison Patrick and I have talked about lexicals before, but not about that
so, another one to talk about with the rakudo team 21:29
PDD changes may be involved
- performance/memory usage in general
we've done well there this quarter
chromatic We should be able to improve further. 21:30
allison is there further low-hanging fruit people would like to attack this quarter?
chromatic I made a list of 16 performance improvements on the wiki.
allison you read my mind
Whiteknight steps for this one: 1) tell chromatic he can do whatever he wants. 2) ??? 3) Profit!
japhb chromatic, url?
chromatic trac.parrot.org/parrot/wiki/Perform...provements
japhb thx
chromatic Fixing Vtable Overrides is a big one.
We should be able to get constant string caching working after 2.3. 21:31
japhb Oh excellent, I like how you did this.
chromatic Sweep-free GC should be a big 2.6 priority.
Immutable strings may be mergeable (if desired) soon after 2.3.
allison I'm not sure Lorito belongs on the performance improvements page
chromatic Of those, Fixing VTABLE Overrides and Sweep-free GC are milestone-sized tasks. 21:32
allison (I mean it will be, hopefully, but it's a much bigger task than that, with many more motivations)
is there some way we can mark those off?
chromatic When completed, when scheduled, or something else?
allison do you mean "monthly branch sized"?
chromatic yes 21:33
japhb chromatic, when you say "big memory savings" for FixingConstantSTRINGCaching, are we talking more or less than half as much memory used for, say, Rakudo?
allison I mean mark them as "big tasks"
chromatic allison, add another column, the first one, then put an X or a * in it.
allison something like that
chromatic japhb, reducing the number of constant strings thawed from PBC by 90%.
allison the exact details not important 21:34
japhb wah.
21:34 kurahaupo joined
chromatic It also lets us make runtime constant strings cheaper. 21:34
allison chromatic's list looks good
japhb agreed.
allison anything to add on performance improvements?
chromatic My recommendation is to make those two I suggested monthly branches. 21:35
allison sounds good
(on different months)
chromatic Yes.
allison we can discuss which months in parrotsketch 21:36
but, I'm guessing in the 2.4-2.5 area?
I'm also guessing the primaries will be chromatic and bacek
onward? 21:37
chromatic and upward
allison - plumage
this is a substantial project priority
japhb I am really low on free cycles, and I could really use help.
allison and we know that japhb isn't going to have much time to work on it
japhb I can guide, mentor, explain, and so on, but I don't seem to have cycles to code.
allison so, some discussion on how to boost work on it is useful
japhb: do you have a sense of how far along it is? 21:38
how much is left to be done?
japhb The basic structure is good. Basic operation is as well. Making it installable as part of Parrot is actually quite close.
allison would pulling it into the parrot core help at all? would it be possible? 21:39
japhb However: handling of versions and versioned prerequisites is planned but not implemented. That's the biggie. The rest is details.
allison (the answer was no 4 months ago, and may still be no, but it's worth checking)
japhb Possible to pull into parrot core -- now, I'd say yes, with a relatively small amount of work.
allison as in, keeping multiple versions of the same modules installed at the same time? 21:40
would having it in the parrot core help get more eyes on the code? (this is a question for the general pool of developers here)
japhb allison, multiple modules versions installed, and handling different modules requiring different versions of modules. 21:41
chromatic +0 to incore for me
allison chromatic: elaborate?
chromatic I'm no more or less likely to work on it.
japhb I'm somewhat concerned that I'm the only one interested in working on it, even though it is a project priority. 21:42
allison japhb: me too 21:43
japhb I'll take suggestions from the peanut gallery on changing that ...
allison curiously, I think it's a bootstrapping problem 21:44
sorear is plumage intended to supplant languag-specific systems like CPAN6 and Proto?
japhb question, which may need to be in another forum: can I get a grant to work on it? I'm doing contract work now, since full-time job went away ... problem is I can't spare hours for "free".
allison CPAN has a body of energy behind it separate from Perl core, and we need the same
but, need Plumage before that can get started
japhb sorear: work with. Proto could be replaced, or simply sit on top of the modules Plumage provides.
21:44 darbelo joined
allison japhb: yes, funding is a substantial possibility 21:45
japhb (to make a perl6-specific interface to general cross-Hll functionality)
darbelo backlogs
japhb allison: then we should talk separately.
allison japhb: if we put together a funding proposal, I can shop it around to our sponsors
japhb: yes, let's do that
japhb THANK YOU.
allison further discussion on plumage? 21:46
- NFG strings
we have a summer of code proposal for this
Whiteknight darbelo proposed that for gsoc
allison that may give us the rough initial implementation
my concern about the proposal is that it suggests replacing *all* strings with NFG strings 21:47
which is contrary to the fundamental design of parrot, and likely to be dog slow
japhb -1 to "all" strings
allison but, I don't have any trouble with waiting for the GSoC implementation to complete, and then working out the details of how to integrate it back in 21:48
darbelo allison: The 'all strings' part is mostly decoupled from the rest, and can be dropped.
allison darbelo: that was my impression while reading the proposal
Whiteknight once we have the encoder and deocder for NFG, however we choose to insert it into the system is a relatively small decision
bacek replace "fundamental design of strings" looks good for me
allison darbelo: and if you implement it as "another alternate string format" from the start, we can likely merge it into trunk as soon as your done 21:49
sorear allison: how does it oppose the fundamental design of Parrot?
chromatic Let's not get into design discussions during scheduling.
allison sorear: we can talk later
sorear: also, take a look at the strings PDD 21:50
dukeleto is back
sorear ok
allison so, we'll hope NFG strings is one of the funded GSoC proposals 21:51
(and talk further later if not)
- concurrency
several people brought this up as a priority 21:52
and there's one GSoC proposal
japhb And I've heard outside requests for it as well (when chatting with people outside #parrot)
smash (concurrency) i love that topic
allison threads currently work, but they're limited
chromatic Concurrency is a post-Star priority for Rakudo.
allison (the GSoC proposal focused heavily on one failing test) 21:53
sorear threads in parrot today are basically just p5 fork emulation?
allison sorear: no, they're full POSIX threads on *nix, and windows threads on windows
japhb I would really like to see some of the classic pre-threads unix-style stuff working well -- fork, pipe, etc.
allison japhb: that's a good point, not to lose sight of the simple things in the more complex things 21:54
japhb nodnod
plobsing can we really say that threads work if they dissable GC?
allison that's a problem with GC
not with threads
(slight semantic difference, but important) 21:55
plobsing but the problem with GC makes threads nearly unusable
japhb Though our users simple see "it doesn't WFM"
er simply
dukeleto chromatic: i am +1 to the new roadmap experiment for 2.6
dukeleto is backlogging 21:56
allison I guess the main question here, in planning, is which should be first?
should we focus on concurrency first or GC?
japhb GC
chromatic GC
bacek I vote for GC
smash i would say GC, it makes mre sense
allison okay, that was my sense as well 21:57
concurrency would be our priority for around summer-time
Util GC first
21:57 Chandon joined
sorear hello 21:57
Chandon Hullo. Meeting still going?
mikehh bearing in mind that work on GC needs to consider possible concurrency issues
sorear yes
japhb Chandon, yes 21:58
allison and that gives us time to see what the GSoC student runs into in their experimental alternate threading strategy too
mikehh: definitely
dukeleto +1 to GC
japhb mikehh, as long as "keep it in mind" does not prevent actual immediate work from getting done, I agree.
allison okay, will come back to GC later in the agenda
(we're about half done and about half-way through our extended hour, so doing well) 21:59
- prototype-based OO
japhb What was that about?
allison this is for Rakudo
japhb Oh, sorry, misread
allison Jonathan expressed some concerns about Class and Object not being a good base for Rakudo OO 22:00
really, we expected that
intentionally designing it so anything that implements the required interface is workable in the system as a class/object 22:01
japhb It *sounded* like he had some concerns about mixing OO and PMCs, instead of implementing OO on top of PMCs. Though I'm unclear.
allison (he mentioned that he wasn't sure if the interface model was still the case, but it is) 22:02
sorear my main concern with OO is nailing down the interface sufficiently to allow metamodel mixing
can we derive Rakudo classes from P5 classes?
allison japhb: he was reading more into the unification of PMCs with HLL classes than we actually plan
sorear but this is post-Star
japhb ah
sorear 95% of CPAN doesn't need to be subclassed to be useful
allison that is, we do plan to merge them closer together, but we don't plan to exclude other class models
it's just that the current PMC+PMCProxy cludge doesn't really work 22:03
a "temporary" fix that has lived out its useful existance
so, are there any objections to adding a Prototype PMC to the core? 22:04
Whiteknight +1
japhb no objection
sorear no objection
dukeleto no objection. PMCProxy gives me the creeps
mikehh none from me
22:05 snarkyboojum joined
allison okay, good 22:05
will let jonathan know 22:06
(and will respond to that message in more detail)
next
- HLL interop TT #556, #557, #558
someone mentioned they were working on this now?
dukeleto allison: i am -1 to plumage being in core and +1 on working on it with direction from japhb
japhb dukeleto, yay!
allison dukeleto: that seems to be the general consensus 22:07
sorear with regards to most HLL interop issues, I think that the spec needs to be delayed until we have a more complete implementation
japhb We can talk more about what time you have and when.
sorear i.e. I'm treating the PDDs as guidelines, not rules, and will update them once blizkost is working
allison sorear: that's reasonable
Whiteknight goes to dinner, will backlog, assume I agree with everything chromatic says :)
allison sorear: as you diverge from the current spec, could you raise the changes for discussion on parrot-dev? 22:08
dukeleto PL/Parrot will need a well-defined HLL interop layer for datatypes
japhb For me HLL interop is in general fairly high priority, but HLL -> Parrot module loading is very high.
22:08 lue joined
allison sorear: don't want you to get to the end and then get an overwhelming slurry of comments 22:08
sorear: that should keep everyone involved in your thinking
sorear allison: ok 22:09
japhb It would be really nice if we could get at least a little time with sorear, Tene, pmichaud, and me together (though I'm the least important)
Does anyone know if pmichaud is able to schedule an hour yet? 22:10
chromatic +1 to that
allison japhb: good idea
pmichaud's availability varies still
but, he's good at passing along his general ideas to a delegate 22:11
japhb OK
allison next:
- moving the build system off Perl5
this is a general project goal
japhb Not for me a priority, but I know it's important to some.
allison not an urgent priority
just a direction we're moving along
(as in, it guides other decisions) 22:12
darbelo It's a lot of small-ish tasks, not a big monolith.
chromatic We need to make that into smaller tasks.
allison sounds like a new wiki page
sorear what we need to agree on is a language to use
bacek e.g. "finish opsc"
allison sorear: as much as possible, nothing external to parrot
sorear which has to be available at Parrot configure time 22:13
allison do we have a volunteer to start a wiki page for it?
sorear what I'm toying with is an NQP-autoconf that generates (shell scripts, C, perl5, etc)
but there's probably a simpler way
japhb +1 to aiming for simple 22:14
sorear +1 to a wiki page to review possibilities
allison okay, we'll mention it in the summary as a possible task 22:15
next
Tene japhb: That's a great idea, I'd love to do that.
allison - chmod files
I'd say this is simply "yes, that's a good feature, add to the wishlist"
kid51 Agreed; same for next two agenda items 22:16
allison same for tar library and zlib library
sorear OSInterfaceAdditionsTasklist
allison sorear: excellent, thanks!
next
- git
dukeleto do people still want to convert to git? 22:17
sorear I thought git was outright rejected?
japhb I do. But I don't feel it's worth another big battle.
allison we said during the last conversation it that we'd postpone any tool changes til after 3.0
chromatic I thought it was until after Rakudo Star.
dukeleto ok, i was not sure if it was 2.3 or 3.0
japhb Lack of git has in the past gotten in the way of "being in the mood for Parrot hacking" when I had my choice of activities -- and git-svn proved to be insufficient for me.
dukeleto last i heard, it was 2.3, but i very well may be wrong 22:18
japhb But as I said, for now, not worth a fight.
cotto I'm for it whenever it's possible.
bubaflub didn't someone talk about getting a duplicate trac with git integration up and running for us to see?
allison this is is a planning session, so the question is "is this something we want to discuss during this quarter?"
kid51 Not during this quarter.
sorear no
allison (it's not something that could be done immediately after 2.3 anyway) 22:19
dukeleto i think we should decide if it is worth it to setup a dev trac with git integration
bacek +1 for git
dukeleto and to have an "official" parrot git mirror
allison dukeleto: no decisions here
dukeleto: just planning when to talk about it :) 22:20
kid51 Perhaps the git advocates could create a wiki page that would map out a transition plan.
allison personally, I'm more inclined to go to mercurial
so, even that may be presuming too much
kid51 Then let's have a mercurial proposal as well
allison though, it would at least give us an idea of feasibility
mikehh bzr
allison I like bzr too
kid51 At $job, making SVN->git transition. Requires a lot of planning. 22:21
japhb I'm fine with mercurial as well, I know Windows folks tend to favor it.
sorear hmm, tracwiki isn't letting me log in, so I can't create OSInterfaceAdditionsTasklist right now
allison and really, it's probably worth talking with the developers of some of these projects
mikehh Ubuntu does very well on bzr
dukeleto kid51: i understand that. I was involved in a large svn->git transition recently. It is worth it on the other side
allison (I know several of them)
sorear kid51: the git advocates don't have much power because git primarily benefits non-commit-bits
allison okay, 10 minutes levt
left 22:22
let's set git aside
talk again at the next quarterly meeting? or between now and then?
chromatic -1 to hg
sorear next quarterly sounds good
kid51 next q; next agenda item
dukeleto allison: i can send something to parrot-dev
allison dukeleto: ok
- security subsystem
this is a priority 22:23
dukeleto The security subsystem is the largest blocker for PL/Parrot
allison as in a quarterly roadmap level priority
chromatic Which quarter?
allison we have a PDD, I'd say the next step is converting that into a tasklist
chromatic: doesn't matter yet, we need to work out more details first 22:24
not before 2.9
perhaps 3.0
dukeleto I just got PL/Parrot converting the three basic datatypes back and forth between Parrot and Postgres. The simplest feature that PL/Parrot needs is to disable ops relating to filesystem access
allison that's a specific task
and can actually be worked on right away 22:25
dukeleto allison: that sounds great. I can help
allison excellent, we can talk about details
next
- runcore support, can we trim the list?
yes
and I'm open to proposals on the list about which ones to trim 22:26
chromatic That should be easy.
bacek keep slow/fast cores only
chromatic Can we discuss that in the upcoming #ps, to deprecate them at 2.3?
allison chromatic: good idea
japhb +1
mikehh +1
cotto +1
bacek +1
darbelo + 22:27
1
sorear -1 to dropping cgp without a *very* good rationale
allison there are a few tickets mentioned here, which I'll look over and discuss after the meeting
so, last item
what's our next big task?
I suggested GC/Concurrency/Lorito 22:28
and it sounds like GC is the winner
japhb +1 to GC
chromatic GC
mikehh +1
bacek I can work on GC after finishing immutable strings.
allison in a rough approximation of order, I'd say we're looking at GC, then Concurrency, then Lorito, then JIT
bacek: good, thanks 22:29
chromatic Do we need "Make sure that GSoC projects succeed" as a milestone?
allison the first order on GC is to review and extend the tasklist
bubaflub that'd be nice
allison it's a project priority, but not really a development milestone
the tricky part is, the student really has to work alone 22:30
chromatic Okay. I want to keep it in mind to help prevent the students from blocking.
allison so there's not much anyone can do except the mentor
that's a good goal
so, something to review every week?
and see if their blockers can make weekly priorities? 22:31
mikehh sounds good
darbelo Weekly GSoC reports helped me keep an eye on the schedule last year.
allison those are quite helpful
japhb Yes, keeping GSoC unblocked via weekly tasks seems very worthy. 22:32
dukeleto weekly gsoc reports will be done this year
allison any final topics to discuss?
dukeleto i will tell all parrot students to submit either an email and/or blog post to parrot-dev each week
cotto dukeleto, great 22:33
allison alright, thanks everyone for participating!
(back to your regular unscheduled #parrot) 22:34
mikehh sorear: just curious - where do you use the cgp core, or other cores for that matter? 22:36
dukeleto allison: i just sent an email to parrot-dev about the security subsystem
allison dukeleto: excellent, thanks
chromatic bacek, my Rakudo-building benchmark is 4.584% faster with immutable strings than without. 22:37
mikehh chromatic++, bacek++ 22:38
hey do we need to re-activate purl?
chromatic We need to find a few more optimizations.
sorear allison: ok, fperrad's OS tasklist is on the wiki now
allison sorear: great! 22:39
dukeleto +1 to letting purl back in. it looks cold and rainy outside
Whiteknight I think GSoC'ers should probably be at weekly #ps too
darbelo Whiteknight: +1 22:40
dukeleto Whiteknight: that sounds like a good idea
sorear purl doesn't respond to INVITE, any purl admins handy? 22:41
allison purl is sulking
Whiteknight we need to craft an apology that she can parse
tcurtis Whiteknight: when and where? I'll be there if I can, and if not, I'll read the logs as soon as I can. 22:42
chromatic purl, come play in traffic
Whiteknight tcurtis: #ps is a meeting like this one that happens every tuesday in the #parrotsketch chatroom 22:43
it's 4:30 my time, so 3:30 for you?
darbelo Ask purl when she comes back :)
sorear mikehh: I only use the default core; however, the last 20+ years of threaded code research tell us that cgp will work better than function pointer array threading, and so I'm going to need convincing that cgp is worthless for us
chromatic Do you want a core that works on Windows? 'cuz CGP isn't it. 22:44
Whiteknight CGP isn't used, isn't tested often, isn't maintained, etc
dalek rrot: r45574 | chromatic++ | branches/immutable_strings_part1/src/string/api.c:
[str] Removed unnecessary string copying from Parrot_str_append().
 22:45
rrot: r45575 | chromatic++ | branches/immutable_strings_part1/src/ops (2 files):
[ops] Removed an unnecessary Parrot_str_clone() from the clone STR, STR op.
darbelo dynloadable runcores?
plobsing darbelo: how does that play with dynloadable oplibs?
darbelo In NxM ways, I'd guess. 22:46
dukeleto dynloadable runcores would make the gsoc instrumentation proposal nicer 22:48
but he could just create a new instrumentation runcore, i guess
dalek tracwiki: v1 | sorear++ | OSInterfaceAdditions
tracwiki: from #parrot
tracwiki: trac.parrot.org/parrot/wiki/OSInter...ction=diff
tracwiki: v2 | sorear++ | OSInterfaceAdditions
tracwiki: fix list formatting
tracwiki: trac.parrot.org/parrot/wiki/OSInter...ction=diff
tracwiki: v163 | sorear++ | WikiStart
tracwiki: link OSInterfaceAdditions
darbelo dukeleto: They are already pluggable.
dalek tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
chromatic Making runcores dynloadable is a SMOP. Adding a runcore is a sMOP.
allison Whiteknight/chromatic/sorear: there's really two different questions here, one is whether CGP in general is good for us, and the other is whether our current implementation of CGP is good for us 22:49
Whiteknight/chromatic/sorear: I'd say yes to the first and no to the second
darbelo The upside is that, if they are dynloadable, exotic runcores are someone else's problem.
Util chromatic: doesn't CGP work on Win32 when compiled with MinGW (which is really GCC)?
allison (which tends toward ripping out the current one to make way for a better one)
sorear darbelo: my point is that CGP isn't "exotic", it's been used for (actually 20 was wrong, it's more like 50) years and is very well studied 22:51
chromatic VS doesn't support computed gotos.
sorear Forth people call it "direct threaded code"
Util VS is not the only supported compiler on Win32 22:52
allison Util: yes, but it's one we have to support
darbelo Util: CGP is gcc-only, afaict. 22:53
allison so, anything that doesn't run on VS must be "optional" to the core
sorear computed goto is gcc-originated, but icc and clang emulate it
allison I like dynaloadable runcores 22:54
libparrot is monstrously huge
sorear dynloadable runcores don't have to N*M with dynloadable oplibs because dynops are not like coreops
dynops look something like _dynopdispatch "find_lex_skip_current", "$_", $P0 22:55
dynops are only compiled for the fast core; _dynopdispatch emulates the fast core no matter the current runloop
chromatic Cutting runcores, or at least making them optional, helps make Lorito more tractable.
allison sorear: that's not currently true, we compile a separate dynop lib for multiple runcores 22:57
chromatic Note that certain features, such as timely event handling, haven't worked in the exotic runcores for more than a year.
allison chromatic: doesn't lorito pretty much replace the current runcores?
chromatic Yes.
allison then, they're all deprecated :)
darbelo Less runcores == less to replace.
chromatic The question is whether we have to support the switches or semantics of existing runcores with Lorito, or whether we deprecate them for that anyway. 22:58
22:58 wknight8111 joined
allison we'll discuss the details later, but in principle, we shouldn't tie ourselves to exactly duplicating the semantics of any of our current runcores 22:59
and, should plan to start with a single runcore for Lorito
with the idea of making it pluggable to add more later
with the further restriction that adding a runcore shouldn't involve bulking out parrot's footprint 23:00
restriction/suggestion?
wknight8111 I like the plan
mikehh +1 23:01
dukeleto sounds good to me
chromatic 398596 src/ops/core_ops_cg.o
459648 src/ops/core_ops_cgp.o
1136124 src/ops/core_ops.o
1972148 src/ops/core_ops_switch.o
wknight8111 runcores we dont use are worthless, practcally speaking
mikehh although we need to retain testr or something similar
wknight8111 yes, testr is good
chromatic I suggest a branch which disables building/linking of specific cores, so we can check footprint and benchmarking. 23:02
... but I must leave now.
allison good idea
chromatic I looked at it once, but it required more Makefile hackery than I wanted.
dalek tracwiki: v164 | dukeleto++ | WikiStart 23:05
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
mikehh did anyone figgure out how to stop purl sulking
sorear erm, does lorito mean we're dropping C89?
allison so, our runcores alone account for 2.5M of libparrot's current 9M hulk
whiteknight sorear: how does on relate to the other?
bacek chromatic, (performance) excellent.
sorear whiteknight: it's not possible to write a portable jit 23:06
allison for perspective, Perl 5.10 is 1.2M and Python 2.6 is 2M
whiteknight so...why drop C89?
allison sorear: not dropping it 23:07
sorear: since Lorito itself will be written in C
whiteknight killing some useless opcodes would bring down bulk too
allison sorear: but severely reducing the scope of it's presence
sorear: that is, have a very small fast core in C, the implement the rest on top of it 23:08
mikehh yeah but c89?
sorear ah, so there would be a Lorito interpreter?
allison mikehh: it is the most portable subset
sorear: Lorito is really just a codename for the next Parrot core 23:09
mikehh yeah I know - but still 20th Centuary
allison mikehh: most of the annoying restrictions we have are because of the various compilers we support, not because of C89 instead of C99 23:10
mikehh we are 20+ years later
whiteknight mikehh: and microsoft C is C89
allison mikehh: the dates are misleading
whiteknight to support that really dictates our standard
mikehh :-}
allison mikehh: it's more like "core C" and "extended C"
mikehh: the implementations are certainly substantially different now than 20 years ago 23:11
mikehh one of the reasons I test more with g++ than gcc
allison whiteknight: good point
mikehh: yeah, we're also supporting that end of the spectrum 23:12
sorear: which is to say "yes, it's the equivalent of IMCC and PIR" 23:13
Util re: CGP core - Abe Pralle got a CGP-equivalent core working in MSVS, by using just a dollop of inline assembly 23:15
abepralle.wordpress.com/2009/01/25/...threading/
dukeleto Util: that is quite interesting 23:19
dalek tracwiki: v1 | dukeleto++ | SecurityTasklist 23:21
tracwiki: trac.parrot.org/parrot/wiki/Securit...ction=diff
whiteknight dukeleto: HLL map FileHandle 23:42
cotto dukeleto, it'd make more sense to have me be the mentor for khairul's proposal and whiteknight for darbelo's.
whiteknight allison has dibs on darbelo's
cotto fine by me. It just shouldn't be me. 23:43
whiteknight I want Nat's
cotto That strikes me as one you'd want.
I know the assignments are temporary but I also don't want them to inadvertently become permanent. 23:44
sorear allison: report sent 23:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!