Camelia, the Perl 6 bug

IRC log for #parrot, 2010-04-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:02 dalek parrot: r45545 | bacek++ | branches/immutable_strings_part1/​src/string/charset/iso-8859-1.c:
00:03 dalek parrot: Update iso charset's case-changing functions.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45545/
00:03 dalek parrot: r45546 | bacek++ | branches/immutable_strings_part​1/src/string/charset/unicode.c:
00:03 dalek parrot: Update unicode charset's case changing functions.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45546/
00:03 dalek parrot: r45547 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
00:03 dalek parrot: Remove useless string clone - charset will allocate new string automatically.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45547/
00:03 dalek parrot: r45548 | bacek++ | branches/immutable_strings_pa​rt1/include/parrot/charset.h:
00:03 dalek parrot: Consting case-changing functions
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45548/
00:03 dalek parrot: r45549 | bacek++ | branches/immutable_strings_part​1/src/string/charset/unicode.c:
00:03 dalek parrot: Consting unicode charset.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45549/
00:03 dalek parrot: r45550 | bacek++ | branches/immutable_strings​_part1/src/string/charset (3 files):
00:03 dalek parrot: Consting charsets.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45550/
00:03 dalek parrot: r45551 | bacek++ | branches/immutable_strings_part​1/src/string/charset/unicode.c:
00:03 dalek parrot: Fix fallback to ascii charset.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45551/
00:03 dalek parrot: r45552 | bacek++ | branches/immutable_strings_part​1/src/string/charset/unicode.c:
00:03 dalek parrot: More fixes to unicode upcase/downcase.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45552/
00:03 dalek parrot: r45553 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
00:03 dalek parrot: Properly adjust bufsize in str_replace.
00:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45553/
00:16 dalek rakudo: c99eeb3 | (Solomon Foster)++ | src/core/ (2 files):
00:16 dalek rakudo: Tweak the Any versions of unpolar and cis, define Real versions of the same.
00:16 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​99eeb31d6bdb1f3f4032d66ddc273d4973ce357
00:19 dalek parrot: r45554 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
00:19 dalek parrot: Set proper charset/encoding str_append.
00:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45554/
00:20 Whiteknight bacek++
00:20 Whiteknight (as if he needs it)
00:20 bacek Whiteknight, no I don't :)
00:21 Whiteknight karma bacek
00:21 purl bacek has karma of 2208
00:22 Whiteknight dayum
00:24 snarkyboojum left #parrot
00:26 bacek Whiteknight, "dayum"?
00:28 chromatic joined #parrot
00:30 tetragon joined #parrot
00:30 nopaste "bacek" at 58.107.108.21 pasted "chromatic, there is another epic fail with 2-args string ops." (9 lines) at http://nopaste.snit.ch/20237
00:33 chromatic More semantics which need to change.
00:33 bacek .oO ( Can we convince Gosling to work on Parrot? )
00:33 bacek chromatic, yes. Easiest way - remove 2-args ops.
00:34 chromatic How do we look on benchmarks?
00:34 chromatic oofib should be interesting
00:35 bacek I didn't test it yet.
00:36 bacek Heh. About 2x faster on branch :)
00:37 chromatic Let me get a visualization on trunk.
00:38 bacek hmm...
00:38 bacek May be not.
00:41 chromatic 15% I can believe.
00:43 chromatic No, not a good benchmark for strings.
00:44 chromatic examples/benchmarks/hamming.pir
00:44 Whiteknight joined #parrot
00:49 chromatic Rakudo doesn't run.
00:49 chromatic No benchmark there.
00:50 bacek I expected it. What about hamming?
00:50 chromatic Not enough code running to make a difference.
00:57 chromatic We need something performing a lot of reflection, checking isa a lot, or passing lots of constant strings.
01:17 bacek chromatic, agreed... Do we have such test?
01:20 chromatic I usually use building Rakudo.  I don't know of anything else, but maybe one of the gc_wave* benchmarks.
01:21 tcurtis joined #parrot
01:23 bacek yeah... It will require some more effort to resurrect PCT...
01:24 dalek parrot: r45555 | bacek++ | branches/immutable_strings_par​t1/src/string/charset/ascii.c:
01:25 dalek parrot: Set new charset after converting.
01:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45555/
01:25 dalek parrot: r45556 | bacek++ | branches/immutable_strings_part​1/src/string/charset/unicode.c:
01:25 dalek parrot: Fix unicode.titlecase
01:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45556/
01:25 dalek parrot: r45557 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
01:25 dalek parrot: Set result hashval to 0 in case-changing functions.
01:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45557/
01:37 bacek chromatic, compact_pool killing constant strings...
01:50 chromatic That's strange.
01:55 nopaste "bacek" at 58.107.108.21 pasted "coretest summary with blocked compact_pool." (16 lines) at http://nopaste.snit.ch/20238
01:55 bacek chromatic, see nopaste. Many bugs just disappeared...
01:56 bacek PGE builds
01:56 bacek pbc_to_exe consumes too much memory for my box...
02:06 snarkyboojum joined #parrot
02:13 dalek parrot: r45558 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
02:13 dalek parrot: Clear more flags in Parrot_str_clone
02:13 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45558/
02:18 bacek chromatic, hooray. I've got same results on r45559 without disabling compact_pool.
02:18 bacek Well... Almost. PGE segfaults...
02:29 dalek parrot: r45559 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
02:30 dalek parrot: Set flags explicitely in Parrot_str_clone instead of cleaning some of them.
02:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45559/
02:41 janus joined #parrot
02:46 dalek parrot: r45560 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
02:46 dalek parrot: Clear string flags in Parrot_str_append
02:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45560/
03:18 dalek parrot: r45561 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
03:18 dalek parrot: Made str_concat synonim for str_append
03:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45561/
03:19 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 #parrot
03:46 chromatic Wow, pbc_to_exe is fairly awful now.
03:52 dalek parrot: r45562 | bacek++ | branches/immutable_strings_pa​rt1/tools/dev/pbc_to_exe.pir:
03:52 dalek parrot: Quick hack pbc_to_exe to RSA for gathering string chunks instead of concatenating them all the time
03:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45562/
03:52 dalek parrot: r45563 | plobsing++ | branches/stringnull/src/string/api.c:
03:52 dalek parrot: more stringnullish goodness
03:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45563/
04:04 bacek chromatic, r45564
04:04 bacek chromatic, guess what? We invoke compact_pool on every single allocation of string...
04:06 chromatic Really?
04:07 bacek YA RLY
04:07 chromatic That shouldn't be.  That's definitely a time sink.
04:07 bacek check mem_allocate
04:08 bacek after compact_pool we will have very small amount of free memory
04:08 chromatic 22,877 mem_allocate, 40 compact pool.
04:08 bacek is it on trunk?
04:09 chromatic r45562
04:09 dalek parrot: r45564 | bacek++ | branches/immutable_strings_part1/src/string/api.c:
04:09 dalek parrot: Improve Parrot_str_join slightly. Still LTA but works much faster then original.
04:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45564/
04:09 bacek anyway, on branch only 2-args string ops test failing.
04:09 bacek we are ready to try rakudo
04:10 bacek chromatic, interesting. During making "old" pbc_to_exe I found that we spent 99.9999% in compact_pool...
04:11 chromatic 66.91% for me on r45564.
04:13 bacek way too many
04:13 chromatic I agree.
04:14 bacek .oO( CodeString.emit need some love. E.g. using RSA for chunks and then join them in one pass )
04:19 Andy joined #parrot
04:23 chromatic I wish we could fix compact_pool in a couple of ways.
04:24 chromatic 1) Don't make only one big pool.
04:24 chromatic 2) Don't copy pools that are almost entirely full.
04:24 chromatic 3) Don't loop more than once over the pools.
04:25 bacek "2" and "3" are conflicting
04:25 bacek we have to pass over pool to check liveness flag
04:25 chromatic #3 is much less important than #2.
04:26 chromatic In theory, pool->guaranteed_reclaimable should be accurate though.
04:27 bacek In practice...
04:27 purl rumour has it in practice is valid
04:27 chromatic Segfault city.
04:31 nopaste "bacek" at 58.107.108.21 pasted "make _test_ summary on branch" (19 lines) at http://nopaste.snit.ch/20241
04:31 bacek chromatic, for now I do want to remove 2-args ops...
04:32 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 http://nopaste.snit.ch/20242
04:33 bacek chromatic, it almost fixed after reimplementing str_join
04:33 bacek not perfect though
04:38 chromatic More than half the time compact_string doesn't free anything.
04:41 bacek and in second half it frees 5% of memory.
04:43 chromatic Much less fragmentation this way, I suppose.
04:44 bacek Price for this is too high
04:44 chromatic We compact way too much, but I cut out part of it.
04:46 bacek we can easily implement #2
04:46 bacek about dozen lines of code
04:46 bacek (and it will imply #1)
04:46 chromatic I tried once and failed, but that was before allison cleaned it up.
04:54 bacek chromatic, inline op substr(out STR, inout STR, in INT, in INT, in STR) :base_core
04:54 bacek I do want to kill it...
04:54 bacek It's awful...
04:55 bacek it returns substr in $1 and cut it from $2
04:55 bacek (at least on trunk...)
04:56 bacek way too much semantics for single function...
05:03 chromatic +    j = Parrot_utf8_encoding_ptr->to_encoding(interp, j);
05:03 chromatic What's that do, bacek?
05:03 bacek just to make all strings in same encoding
05:04 bacek to avoid hassles with charset/encoding to calculate buflen and copy memeory
05:06 chromatic 16.96% of pbc_to_exe execution time there.
05:07 bacek hmm...
05:07 bacek it's... weird
05:07 bacek I convert joiner once
05:07 bacek And pbc_to_exe should invoke str_join once
05:08 chromatic +        next = Parrot_utf8_encoding_ptr->to_encoding(interp, next);
05:08 chromatic That's probably it.
05:08 chromatic I'm working on that function now.
05:09 bacek yeah.
05:09 bacek It can be improved.
05:14 dalek parrot: r45565 | petdance++ | trunk (2 files):
05:14 dalek parrot: consting and shimming
05:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45565/
05:15 chromatic This isn't quite right, but it's close and faster.
05:16 nopaste "chromatic" at 67.168.199.244 pasted "bacek: no PMC in Parrot_str_join()" (62 lines) at http://nopaste.snit.ch/20243
05:17 bacek chromatic, looks about all right
05:18 chromatic PGE doesn't build, so there's an off-by-one somehow.
05:20 chromatic Avoiding the PMC and the repeated encoding check helps a lot.
05:25 bacek chromatic, you can blindly memcopy strings with different encodings...
05:26 Andy joined #parrot
05:26 janus joined #parrot
05:26 tcurtis joined #parrot
05:26 TonyC joined #parrot
05:26 yjh joined #parrot
05:26 theory joined #parrot
05:26 sorear joined #parrot
05:26 moritz joined #parrot
05:26 zibri joined #parrot
05:26 ttbot joined #parrot
05:26 jhelwig joined #parrot
05:26 sjn joined #parrot
05:26 slavorg joined #parrot
05:26 Essobi joined #parrot
05:26 Util joined #parrot
05:26 pmichaud joined #parrot
05:26 jjore joined #parrot
05:26 pjcj joined #parrot
05:26 integral joined #parrot
05:26 Khisanth joined #parrot
05:26 ruoso joined #parrot
05:26 mj41_ joined #parrot
05:26 PerlJam joined #parrot
05:26 magnachef joined #parrot
05:26 s1n joined #parrot
05:26 NotFound joined #parrot
05:26 knewt joined #parrot
05:26 eiro_ joined #parrot
05:26 athomason joined #parrot
05:26 slavorgn joined #parrot
05:26 dukeleto joined #parrot
05:26 he joined #parrot
05:26 Hunger joined #parrot
05:26 sri joined #parrot
05:26 baest joined #parrot
05:26 bacek_at_work joined #parrot
05:26 Tene joined #parrot
05:26 Infinoid joined #parrot
05:26 treed joined #parrot
05:26 estrabd joined #parrot
05:26 GeJ joined #parrot
05:26 PacoLinux joined #parrot
05:26 wagle joined #parrot
05:26 cosimo joined #parrot
05:26 bacek joined #parrot
05:26 dngor joined #parrot
05:26 cotto_work joined #parrot
05:26 Austin joined #parrot
05:26 rbuels joined #parrot
05:26 silug joined #parrot
05:26 eternaleye joined #parrot
05:26 Coke joined #parrot
05:26 confound joined #parrot
05:26 solarion_ joined #parrot
05:26 purl joined #parrot
05:26 chromatic Yes, that doesn't help.
05:29 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.
05:30 bacek it will work.
05:30 chromatic That way we avoid any unnecessary work.
05:31 bacek hmm
05:31 bacek Nope.
05:31 bacek What about ascii?
05:32 chromatic The converting is expensive, not the comparison.
05:32 bacek can we single encoding/charset for strings?
05:32 bacek sigh...
05:33 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.
05:34 chromatic Definitely.
05:35 chromatic We can reuse a lot of string_rep_compatible() in the loop.
05:35 bacek in which loop?
05:36 chromatic The second loop, the one which does the memcpy.
05:37 bacek in join??? I don't see any string_rep_compatible
05:37 chromatic Right, but we should check that.
05:38 chromatic If the strings have the same representations, we can do the memcpy directly.
05:38 chromatic If not, we need to transcode them.
05:38 bacek We have to do it in first loop
05:38 bacek Otherwise we have to reallocate memory
05:38 chromatic Ah, I see.
05:39 chromatic That's true.
05:46 chromatic ... and it has to walk back through the loop.
05:46 bacek yes.
05:46 bacek way too much work
05:47 chromatic We only have to write that algorithm once.
05:47 chromatic If we always transcode to UTF-8, every join suffers.
05:48 bacek agreed.
05:48 bacek But we can do it later.
05:49 bacek e.g. after fixing all test failures :)
05:50 bacek afk # shopping
06:28 chromatic Ah, we can still do it in two passes.
06:31 chromatic Whoops, no.  Grr.
06:38 nopaste "chromatic" at 67.168.199.244 pasted "bacek: this is closer" (108 lines) at http://nopaste.snit.ch/20244
06:40 bacek chromatic, why don't calculate total_length in second loop?
06:40 bacek it will be simpler
06:41 bacek ah, sorry
06:41 bacek I see
06:42 bacek Looks like you missed joiner (in third loop)
06:43 bacek and we have to transcode it under "if(transcoded)"
06:46 bacek Even better: if remove NULLOK from C<j> we can use it for initial c/e pair
07:07 fperrad joined #parrot
07:11 fperrad_ joined #parrot
07:36 eternaleye_ joined #parrot
07:50 payload joined #parrot
07:54 fperrad_ joined #parrot
07:54 dalek plparrot: 4a007ea | dukeleto++ | plparrot.c:
07:54 dalek plparrot: This makes bad things happen
07:54 dalek plparrot: review: http://github.com/leto/plparrot/commit/4​a007ea9548f9744cf34244fa07e3d783e17dbca
07:54 dalek plparrot: 6cbdf6b | dukeleto++ | plparrot.c:
07:54 dalek plparrot: Attempt to correctly handle creating PG Strings from String PMCs
07:54 dalek plparrot: review: http://github.com/leto/plparrot/commit/6​cbdf6b9e53b3d903ab0a68a257aedeceb86d642
07:54 dalek plparrot: 3d523d8 | dukeleto++ | plparrot.c:
07:54 dalek plparrot: Make converting PG strings -> Parrot String PMCs work
07:54 dalek plparrot: review: http://github.com/leto/plparrot/commit/3​d523d81a7471e0ee8f3408c615effba7f183ac8
07:56 payload1 joined #parrot
07:56 dukeleto PL/Parrot is now passing all tests. w00t!
07:57 bacek dukeleto, you need more tests!
07:57 dukeleto bacek: yes, i do :)
07:57 dukeleto 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 #parrot
08:00 dalek plparrot: dbe8b5e | dukeleto++ | plparrot.c:
08:00 dalek plparrot: Correct conversion from Parrot Float PMCs -> PG floats. All tests pass!
08:00 dalek plparrot: review: http://github.com/leto/plparrot/commit/d​be8b5e57dc1a846fda9a8f39c1633b7b6713950
08:18 szabgabx joined #parrot
08:30 chromatic Oh, that's what j is.  That's the source of my problems.
08:31 chromatic ... but I must sleep now.
09:01 cognominal joined #parrot
09:05 dalek joined #parrot
09:23 ruoso joined #parrot
09:24 dalek plparrot: 1a02f12 | dukeleto++ | t/sql/test.sql:
09:24 dalek plparrot: Add a test for float return values and change test subs to be :anon
09:24 dalek plparrot: review: http://github.com/leto/plparrot/commit/1​a02f1218b52ebdb378f5f401800427eb07cf096
09:24 dalek plparrot: 988f885 | dukeleto++ | plparrot.c:
09:24 dalek plparrot: Parrot_new_string -> Parrot_str_new
09:24 dalek plparrot: review: http://github.com/leto/plparrot/commit/9​88f885f87241994a27672bfb655c17d27d5c491
09:24 dalek plparrot: 74d4089 | dukeleto++ | plparrot.c:
09:24 dalek plparrot: Plug a memory leak in plparrot_make_sausage
09:24 dalek plparrot: review: http://github.com/leto/plparrot/commit/7​4d40899763bb39e86d9fa301b2f2321c843d931
09:30 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:32 snarkyboojum joined #parrot
09:45 fperrad_ joined #parrot
09:59 AndyA joined #parrot
10:03 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 mikehh rakudo - t/spec/S06-multi/syntax.rakudo - Failed tests:  21-22
10:03 mikehh rakudo - t/spec/S05-mass/properties-general.rakudo - TODO passed:   4-6, 11-13, 544-546, 550
10:03 mikehh rakudo - t/spec/S32-str/uc.rakudo - TODO passed:   17-20
10:08 moritz all of these are expected, except uc.rakudo, which is... worrying
10:09 moritz sometimes it fails, sometimes it passes, soemtimes it passes TODO tests
10:12 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:53 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 #parrot
11:09 Whiteknight Good morning, #parrot
11:09 Whiteknight LTA?
11:09 purl LTA is less than adequate, see also http://acronyms.thefreedictionary.com/LTA
11:09 bacek "Less Than Awesome" in Rakudo world :)
11:10 bacek purl LTA is also "Less Than Awesome" in Rakudo world :)
11:10 purl okay, bacek.
11:10 bacek LTA?
11:10 purl LTA is less than adequate, see also http://acronyms.thefreedictionary.com/LTA or "Less Than Awesome" in Rakudo world :)
11:26 Whiteknight allison: ping
11:37 khairul joined #parrot
11:39 jan joined #parrot
11:40 payload joined #parrot
11:44 dalek rakudo: 9406f55 | (Solomon Foster)++ | src/core/ (3 files):
11:44 dalek rakudo: Define Real versions of ceiling, floor, truncate, and round.  Plus infix:<+>, infix:</>, and infix:<==>.  Tweak Any versions, Real versions.
11:44 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​406f55c8e28b9528a82668d540100b9ed3d2aba
11:45 payload1 joined #parrot
11:50 dalek rakudo: ae2e81b | (Solomon Foster)++ | src/core/Bool.pm:
11:50 dalek rakudo: Add Bool.Bridge, because Bool somehow manages to be an Int (and do Real) without having Int's methods.
11:50 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​e2e81b286a025472f557c80a6dc9db2bfb2d025
12:17 Whiteknight tcurtis: ping
12:20 Whiteknight 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 #parrot
13:17 Mokurai1 joined #parrot
13:25 moritz somebody needs to volunteer for mentoring tcurtis' gsoc proposal
13:26 moritz 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
13:26 Whiteknight but I will volunteer for it now, to move the process along
13:26 Whiteknight done
13:27 Whiteknight any word yet on how many slots we will get?
13:27 moritz no idea
13:28 moritz will be determined around Tuesday, I think
13:28 moritz 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)
13:29 Whiteknight I can volunteer for all the parrot-related ones, for now
13:29 Whiteknight I would really like dukeleto to volunteer for the RTEMS ones
13:30 bacek aloha
13:31 bacek what about tcurtis proposal?
13:31 Whiteknight good morning, bacek
13:31 bacek fsvo morning :)
13:32 Whiteknight it's always morning somewhere :)
13:32 Whiteknight and at the moment, I live in that somewhere
13:34 bacek my somewhere is far ahead of yours somewhere :)
13:36 bacek Is parrot's GSoC projects under perl foundation umbrella?
13:37 Whiteknight yes
13:37 bacek Who can approve my mentor request?
13:37 bacek chromatic? coke?
13:38 moritz bacek: dukeleto and particle1
13:38 bacek moritz, thanks
13:38 bacek dukeleto, ping?
13:41 patspam joined #parrot
13:43 bacek ok, if no one else volunteer for tcurtis' project I will
13:43 bacek (modulo my mentor request approval)
13:44 kid51 joined #parrot
13:48 Whiteknight bacek: I already did
13:48 bacek Whiteknight, ok then.
13:48 Whiteknight we only need volunteers now to assign slots
13:48 Whiteknight after the slots are assigned we can rearrange
13:49 bacek ok. Now I can sleep peacefully :)
13:49 bacek night
13:50 bacek good night
13:51 Whiteknight goodnight
14:17 dalek parrot: r45566 | whiteknight++ | branches/block_exit_handlers:
14:17 dalek parrot: Creating new branch to experiment with exit handlers for rakudo
14:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45566/
14:17 dalek parrot: r45567 | whiteknight++ | branches/block_exit_handlers/src (5 files):
14:17 dalek parrot: initial test work
14:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45567/
14:36 Whiteknight where should we put tests for PIR semantics?
14:37 Whiteknight t/pmc/sub.t seem lousy
14:39 Whiteknight t/pir seems decent, but that folder is mostly empty
14:39 ruoso joined #parrot
14:40 moritz time to change that :-)
14:43 sorear joined #parrot
14:50 dalek parrot: r45568 | whiteknight++ | branches/block_exit_handlers (6 files):
14:50 dalek parrot: fix build. all tests pass
14:50 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45568/
15:08 particle bacek: done
15:08 * particle wanders off for some breakfast &
15:13 tetragon joined #parrot
15:17 iblechbot joined #parrot
15:27 fperrad joined #parrot
15:38 theory joined #parrot
15:38 fperrad_ joined #parrot
15:45 jan joined #parrot
16:09 TiMBuS joined #parrot
16:40 PacoLinux joined #parrot
16:43 dalek parrot: r45569 | plobsing++ | branches/stringnull/src/pmc/string.pmc:
16:43 dalek parrot: fix problems with string tests
16:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45569/
16:46 tcurtis joined #parrot
17:15 Whiteknight the meeting today, is it in here or in #parrotsketch?
17:16 dalek parrot: r45570 | plobsing++ | branches/stringnull (2 files):
17:16 dalek parrot: fix replace on stringnull bug
17:16 dalek parrot: STRINGNULL *cannot* be set to arbitrary strings
17:16 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45570/
17:16 dalek parrot: r45571 | plobsing++ | branches/stringnull (2 files):
17:16 dalek parrot: don't copy stringnull from string pmcs
17:16 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45571/
17:21 ruoso joined #parrot
17:22 payload joined #parrot
17:24 Coke how can we tell if a proposal has a real mentor instead of just a proposed one. click on it?
17:24 Coke (is that it?)
17:25 Coke dukeleto: ping
17:27 Whiteknight Coke: on the list it says "1 proposed", I suspect it would not say "proposed" onced a mentor has been affixed
17:28 Coke poked into a few of the parrot proposals, doesn't look like we have any assigned mentors.
17:28 Coke (which, based on GSOC list traffic, is bad.)
17:31 Whiteknight Coke: what we need now is just proposed mentors
17:31 Whiteknight that's what the list traffic is talking about
17:31 brooksbp joined #parrot
17:31 Whiteknight we get slots assigned based on the number of proposals with proposed mentors
17:31 Whiteknight then when we have the slots, we can make assignments to them
17:32 brooksbp could someone with an ACM subscription please help me getting this paper? http://portal.acm.org/citation.cfm?id=1780.1803
17:32 dalek parrot: r45572 | plobsing++ | branches/stringnull (2 files):
17:32 dalek parrot: stringnull preserved accross freeze/thaw
17:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45572/
17:42 dukeleto Coke: pong
17:52 Tene joined #parrot
18:11 cotto dukeleto, who's Chris wrt RTEMS?
18:22 Whiteknight brooksbp: what do you need the paper for?
18:22 Whiteknight (I don't have an ACM subscription, just curious)
18:25 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:26 Whiteknight allison: I may be misreading, but I don't see there being any way to make an assignment right now
18:26 Whiteknight unless particle1 and dukeleto have magic controls that I cannot see
18:27 Whiteknight 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:29 allison Whiteknight: assignment has to be done by an admin
18:30 allison brooksbp: ACM has very sane rules on article sharing. Here you go: http://pub.lohutok.net/parrot/p603-georgeff.pdf
18:30 Whiteknight April 21 looks like the deadline when mentors need to be assigned
18:30 Whiteknight http://socghop.appspot.com/document/sho​w/gsoc_program/google/gsoc2010/timeline
18:31 allison Whiteknight: yes, the deadline this week is just about allocating how many students each organization will get
18:31 allison Whiteknight: which they determine automatically on the basis of an algorithm they haven't entirely explained
18:32 allison 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
18:32 Whiteknight everything I've read has been very very vague on that point
18:32 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
18:33 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 Whiteknight how many slots has TPF requested?
18:34 Whiteknight best documentation I've seen for how slots are allocated is here: http://socghop.appspot.com/document/show/p​rogram/google/gsoc2009/studentallocations
18:48 davidfetter joined #parrot
18:54 allison Whiteknight: I don't know if they've requested any yet
19:00 Chandon joined #parrot
19:04 dukeleto i requested 15 slots this year
19:05 allison dukeleto: excellent!
19:05 purl Smithers, release the hounds!
19:05 allison dukeleto: do you know if it's proposed or assigned mentors they care about?
19:05 moritz allison: assigned
19:06 allison moritz: that's what I thought, but we don't have any assigned
19:06 moritz well, we should have :-)
19:06 moritz the mentors can be swapped later on
19:06 moritz but only proposals with assigned mentors will be considered
19:07 moritz (has been discussed on that noisy google-summer-of-code-mentors-list@googlegroups.com list)
19:07 * dukeleto looks at melange-pain now
19:09 dukeleto is the summit starting in about 20 minutes?
19:10 allison dukeleto: yes, 20 minutes
19:10 purl 20 minutes is too fuckin long
19:10 dukeleto i shall notify the interwebs
19:11 sorear hello
19:11 purl privet, sorear.
19:12 Whiteknight are we going to talk about the proposals today at the summit?
19:13 Whiteknight if not, I think dukeleto can go through and just assign mentors to the various projects
19:13 Whiteknight dukeleto: is it 15 slots for all TPF?
19:14 dukeleto Whiteknight: yes
19:14 Whiteknight I guess parrot only needs 5 of those.
19:14 dukeleto Whiteknight: that is what I requested originally, before any proposals were in
19:14 Whiteknight ...and we damn well better get all 5 :)
19:15 Whiteknight both bubaflub and darbelo submitted two each, so we need to decide as a group which of them we prefer for each
19:15 Whiteknight and both of them applied to port to RTEMS, so obviously only one person can get that
19:15 mikehh joined #parrot
19:15 moritz Whiteknight: the votes on darbelo's proposals speak pretty clearly for NFG and against RTEMS :-)
19:16 Whiteknight moritz: the votes so far
19:16 Whiteknight but yes, it does look like people want darbelo's considerable talents devoted to NFG
19:18 dukeleto i haven't had time to look at any comments on the proposals. I have been enjoying my vacation too much :)
19:18 dukeleto that, and making PL/Parrot work. All tests pass!
19:18 moritz \o/
19:18 Whiteknight dukeleto++
19:18 Whiteknight vacation++
19:22 Whiteknight 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:24 dukeleto i just added a few comments to his RTEMS proposal
19:24 dukeleto i have been talking with the rtems guys
19:24 dukeleto 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
19:24 purl okay, dukeleto.
19:24 dukeleto i am listed as a proposed mentor for rtems
19:25 Whiteknight darbelo did propose to both orgs. He says so in his application
19:25 dukeleto so i think that is the case
19:25 dukeleto ah. it might have been darbelo that proposed to both. not sure about bubaflub
19:25 Whiteknight oh, okay
19:27 dukeleto we have until the 21st to sort all of this out
19:27 Whiteknight yes
19:27 Whiteknight summit in 3, correct?
19:27 moritz really? all the people on the mailing list said Monday (tomorrow)
19:28 Whiteknight moritz: tomorrow are preliminary slot estimates
19:28 Whiteknight the 21st is the hard deadlne for it
19:28 moritz ah, ok
19:28 allison Whiteknight: yes, 2 minutes
19:28 Util Whiteknight: summit time = correct
19:28 dukeleto i may just apply some mentors to various proposals and it can always be changed later
19:28 allison dukeleto: that seems to be the consensus on the gsoc list
19:29 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
19:30 allison I'm happy with either threading or strings
19:30 allison I suspect I may need to be more involved in the strings one
19:30 Tene Is the meeting taking place in #parrotsketch?
19:30 kid51 dukeleto:  Are you going to be in Portland during the week in May when pdx.pm meets?
19:30 Tene or here?
19:30 purl it has been said that here is better than there
19:30 kid51 purl is correct
19:30 Whiteknight allison: I get that impression too, the strings one is a little more obscure and will need more design help
19:30 allison Tene: we advertised it as here
19:31 allison 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 #parrot
19:31 Whiteknight wherever it happens, /me declares this summit started
19:31 dukeleto kid51: yes
19:31 sorear if it moves to #parrotsketch, does that connote being closed to the public?
19:31 allison sorear: nope, still open
19:31 Whiteknight I say we do it here
19:32 dukeleto +1 to here
19:32 Whiteknight these discussions can either hold or be continued in the meeting
19:32 allison good for me, let's go
19:32 allison Welcome everyone!
19:32 japhb OK, here
19:32 * kid51 is present
19:32 Whiteknight welcome!
19:32 purl Welcome to #perl.  You will never find a more wretched hive of scum and pedantry.
19:32 allison The second quarterly virtual parrot developer summit
19:32 allison who's here?
19:32 purl i think here is better than there
19:32 * moritz
19:32 was kicked by moritz: purl
19:32 purl joined #parrot
19:32 * Util feels welcome
19:32 Whiteknight (+1 on making these meetings quarterly, by the way)
19:33 was kicked by moritz: purl
19:33 chromatic joined #parrot
19:33 moritz feel free to lift the ban once the meeting is over :-)
19:33 * Tene present
19:33 Whiteknight moritz: probably better left the way it is :)
19:33 * sorear also feels welcome
19:33 cotto hi
19:33 mikehh I am here
19:33 sorear Whiteknight: no purl = no karma from dalek
19:34 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.
19:34 allison Would everyone please briefly look over the roadmap items for 2.6 and 3.0:
19:34 allison http://trac.parrot.org/parrot/roadmap
19:34 allison Plus the spreadsheet items for 2.6, 2.9, and 3.0.
19:34 allison http://spreadsheets.google.com/ccc?key=0Ah​m1zTZwW0VHdFVPSW1BemVEZU82RkFrZDZ5cTdtYXc
19:34 allison 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?
19:35 allison While you're doing that, I'll summarize what people unable to attend pre-contributed.
19:35 allison Jonathan reports that memory usage is much improved. Great work everyone!
19:35 allison There will be ongoing tasks there.
19:35 Whiteknight chromatic++ and bacek++ on the memory improvements
19:36 * 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
19:36 sorear down from 12 hours to 12 minutes
19:36 chromatic Some changes on the Rakudo side: I fixed a few leaks there.
19:36 allison Other priorities for Rakudo *: error reporting (line numbers), block exit handlers, lexical implementation, performance in general.
19:36 allison Priorities after Rakudo *: NFG strings, concurrency, prototype-based OO, HLL interop.
19:37 allison 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.
19:37 Whiteknight do we have tickets for all these things?
19:37 * japhb very disappointed about that.  :-(
19:37 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.
19:38 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
19:38 chromatic Are you suggesting we discuss that now, or are you discussing an agenda?
19:38 dukeleto allison: i think the "security subsystem" needs to be on the roadmap somewhere
19:39 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?
19:39 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
19:40 dukeleto allison: sounds great
19:40 sorear #1524 in particular has caused me quite a bit of headaches
19:41 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.
19:41 Whiteknight okay, I think we're jumping in too quickly. What is the agenda today?
19:42 japhb Whiteknight, I thought we were posting suggestions for that.
19:42 bubaflub joined #parrot
19:42 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
19:42 japhb :-)
19:42 bubaflub sorry i'm late ya'll, deacon's meeting at church ran late.  i'm reading the back log now
19:43 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
19:43 dukeleto NOTE: I am assigning some temporary mentors to GSoC proposals now, so we make tomorrows ill-communicated deadline
19:43 sorear I don't think we can really do much about HLL interop without an implementation to experiment on
19:44 bubaflub allison: awesome.
19:44 cotto dukeleto, thanks.
19:44 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"
19:47 allison Okay, here's the current agenda, anything you'd like to add or remove from it?
19:47 allison - error reporting (line numbers)
19:47 allison - block exit handlers
19:47 allison - lexical implementation
19:47 allison - performance/memory usage in general
19:47 allison - plumage (project priority, how to boost resources, how far along is it? what does it need?)
19:47 allison - NFG strings
19:47 allison - concurrency (wait for GSoC?)
19:47 allison - prototype-based OO
19:47 allison - HLL interop
19:47 allison - moving the build system off Perl5
19:47 allison - chmod files
19:47 allison - tar library
19:47 allison - zlib library
19:47 allison - security subsystem
19:47 allison - next big task: GC/Concurrency/Lorito/?
19:47 allison - #566, #567, #568, and #1524
19:47 allison How about process discussions?
19:48 Whiteknight process discussions are always good
19:48 allison any pros or cons of the current process, or suggested changes?
19:48 chromatic Suggestion: review of the 2.3 release, process questions, roadmap review.
19:48 Tene re error reporting, I have some fixes for that in my exceptions_refactor branch.  I can elaborate.
19:48 sorear what's the significance of 3.6, why do we have tickets assigned to it?
19:48 sorear parrot version
19:48 mikehh how essential is it that we maintain all the different runcores?
19:48 allison sorear: it's one of the "supported" releases
19:49 allison sorear: the last one in the current roadmap
19:49 allison mikehh: good question, will add to agenda
19:49 Whiteknight after that, parrot is "finished", and all commit bits are revoked
19:49 Whiteknight ...or we just extend the roadmap
19:50 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
19:50 dukeleto bubaflub++
19:51 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
19:51 cotto do we want dalek active during the meeting?
19:51 allison cotto: the archive would be useful
19:51 sorear (I'm also interested in (rudimentary) ordered sweeping from the roadmap, but I don't think it needs to be on the agenda)
19:51 dukeleto what is realistic to accomplish for 2.3 ? when does the 2.3 new-feature-commit-freeze start ?
19:51 Whiteknight gerd is release manager for 2.3, he would know
19:52 allison chromatic: (that is, we're doing a roadmap review now, but may want more detail later)
19:52 chromatic Okay.
19:52 allison Okay, agenda set, let's begin.
19:52 allison - review of the 2.3 release
19:52 allison - process questions
19:52 allison - error reporting (line numbers)
19:52 allison - block exit handlers
19:52 allison - lexical implementation
19:52 allison - performance/memory usage in general
19:52 allison - plumage (project priority, how to boost resources, how far along is it? what does it need?)
19:52 allison - NFG strings
19:52 allison - concurrency (wait for GSoC?)
19:52 allison - prototype-based OO
19:52 allison - HLL interop
19:52 allison - moving the build system off Perl5
19:52 allison - chmod files
19:52 allison - tar library
19:53 allison - zlib library
19:53 allison - security subsystem
19:53 allison - next big task: GC/Concurrency/Lorito/?
19:53 allison - runcore support, can we trim the list?
19:53 allison - #566, #567, #568, and #1524
19:53 allison - roadmap review
19:53 allison 2.3 release, what went well, what went badly?
19:53 allison any lessons to learn from it?
19:53 dukeleto allison: do you mean 2.2 ?
19:53 Whiteknight is 2.3 out? isn't it 2.2?
19:53 chromatic The deprecation policy change seems to have worked better.
19:53 * dukeleto looks back from the future
19:54 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
19:54 allison yes, 2.2
19:55 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
19:55 allison Whiteknight: can you elaborate on the remaining pain points?
19:55 dukeleto allison: sorry, it slipped my mind, but conversion to git should be on the roadmap as well
19:55 bubaflub dukeleto++
19:55 cotto +1
19:55 allison Whiteknight: (with respect to deprecation policy)
19:56 allison 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
19:56 Whiteknight it's not so bad that it's worth arguing about now
19:56 allison Whiteknight: okay, good to keep it in mind though, thank you
19:57 allison any concerns or questions about the upcoming 2.3 release?
19:57 allison this is a supported release
19:57 mikehh possibly need to add updating parrot web sites to the notes
19:57 allison one thing I'd like to see is package testing for various distributions before the release
19:58 Whiteknight +1 on package testing
19:58 allison I had some painful points in Debian packaging for 2.0 that were entirely avoidable
19:58 cotto Where's that testing process documented?
19:58 Whiteknight I'm happy to help with debian packaging this goround
19:58 allison (things that  would have been trivial to fix in advance like new executables without manpages)
19:59 allison cotto: the testing process is essentially "build a package from the current trunk, try it in the target distro"
20:00 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
20:00 allison that would make a *huge* difference to package testing
20:00 dukeleto allison: i would like to work on that
20:00 allison dukeleto: okay, taking a note of that as a possible roadmap task
20:01 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)
20:01 mikehh I can certainly help with the testing
20:01 allison Tene: it's not currently in the priority queue, but it's on the list
20:01 allison Tene: it dropped in priority when Patrick said he didn't need it anymore
20:02 Tene 'k
20:02 allison mikehh: thanks, I'll note you as interested
20:02 allison sounds like we're wrapping up on 2.2 and 2.3
20:03 allison chromatic, would you like to run process questions?
20:03 chromatic Any discussion of what we implemented in 2.1 - 2.3?
20:03 japhb (afk for a couple)
20:04 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.
20:04 dukeleto a big +1 to the 3 month dep cycle
20:04 mikehh +1
20:05 chromatic Anything else on implementation?
20:05 Whiteknight nope
20:06 chromatic Okay.  Process questions.
20:06 chromatic What's working in our process?
20:06 chromatic I've heard only praise for shorter deprecation cycles.
20:06 chromatic Any other changes we've made that work out well?
20:06 Whiteknight yes, shorter cycles are better
20:07 Whiteknight 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.
20:07 sorear PSA?
20:07 chromatic Any thoughts on moving #ps?
20:07 japhb (bak)
20:07 allison chromatic: we discussed it and decided to stay on #parrot
20:07 Whiteknight the move plus daylight savings has given me some troubles, but nothing major
20:08 mikehh works fine as it is for me
20:08 Whiteknight allison: he's talking about moving meeting time of weekly #ps
20:08 allison chromatic: restarting the roadmap review each week has been helpful
20:08 Whiteknight +1 to weekly roadmap review
20:08 allison Whiteknight: (ah, thanks for the translation)
20:08 chromatic Talking more regularly to #perl6 seems to have helped set priorities too.
20:09 dukeleto sorear: PSA = Public Service Announcement
20:10 chromatic Any other positives in the process?
20:11 dukeleto i think parrot is doing well welcoming new devs via GSoC
20:11 sorear dukeleto: ah
20:11 AndyA joined #parrot
20:11 chromatic GSoC appears to be going very well.
20:11 * allison just added JIT to the agenda
20:11 Whiteknight yes, lots of quality submissions
20:11 Whiteknight very very high quality submissions
20:12 chromatic We seem to be attracting more contributors.
20:12 sorear Is that good?
20:12 allison sorear: contributors are always good
20:12 Whiteknight sorear: we burn them for warmth
20:13 chromatic Let's move on.
20:13 chromatic What could we improve?
20:14 chromatic We still seem to drop about half of our weekly priorities.
20:14 Whiteknight we may have too many of them
20:14 mikehh rakudo has a policy of NOT closing a ticket until an appropriate test is added to the test suite
20:15 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
20:15 chromatic Let's take these in order.
20:15 chromatic Do we set too many weekly priorities?
20:15 allison yes
20:15 allison (IMO)
20:16 cotto yes
20:16 japhb But the reason for that seems to be "dear god, let one of these please stick"
20:16 Whiteknight priorities are like herding cats. We can never get more than a handful of people working on any priority
20:16 kid51 queue 1 not-doing-so-well issue
20:16 allison they seem to change too often
20:16 Whiteknight allison: too often? so is the alternative to set monthly priorities?
20:16 allison or, perhaps they're just not fine-grained enough to be 1-week tasks?
20:16 chromatic Or are they too specific to attract people?
20:17 allison a weekly priority should be specific
20:17 cotto not everyone will be able to do every task, even if willing
20:17 allison well, okay, the alternative is to say the weekly priority isn't a task to complete
20:17 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
20:17 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
20:17 allison like "this weeks priority is testing"
20:17 allison or "documentation"
20:18 dalek parrot: r45573 | chromatic++ | branches/immutable_strings_part1/src/string/api.c:
20:18 dalek parrot: [str] Revised Parrot_str_join() to avoid creating a new PMC and to transcode
20:18 dalek parrot: strings unnecessarily.  This is much faster than before, but it could use
20:18 dalek parrot: prettifying.
20:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45573/
20:18 allison they should either be general with no "completion" goal, or small and specific and easy to complete within a week
20:18 Whiteknight allison: like a central thrust, instead of a finite task?
20:18 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.
20:18 allison Whiteknight: yes, we seem to mix up the two
20:19 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
20:19 bubaflub agreed.  that way two people of varying skill can work on something together.
20:19 chromatic That sounds reasonable.
20:19 Whiteknight saying we want something as a group, but nobody volunteers up front to do it, means it won't get done
20:19 allison +1
20:20 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
20:21 * dukeleto goes afk. will respond on parrot-dev if i miss my questions
20:21 chromatic Are they useful?
20:21 kid51 task lists are good if you know they're there.
20:21 kid51 I was not aware of those lists.
20:21 Whiteknight chromatic: link to your tasklist?
20:22 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.
20:22 Whiteknight +1
20:22 chromatic See http://trac.parrot.org/parrot/​wiki/FixingPIRVtableOverrides for example.
20:22 Whiteknight oh, you've been making specific tasklists, not a large general one
20:22 chromatic Right.
20:22 Whiteknight okay, I misunderstood
20:23 chromatic Any other discussion of weekly priorities?
20:23 allison Sounds like no
20:23 allison On to the remainder of the agenda...
20:23 chromatic Next discussion point: are some of our long term priorities stale?
20:24 allison yes
20:24 kid51 By 'long-term' you mean ...?
20:24 chromatic Milestone priorities.
20:25 chromatic 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
20:25 allison that doesn't delete the ticket
20:26 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
20:26 Whiteknight as milestones get closer, we start replacing general ideas with specific tasks
20:26 mikehh the problem being that removing from the roadmap put it to sllep often
20:27 chromatic Do we need a wishlist?
20:27 mikehh it gets forgotten
20:27 allison yes, 3.6 has a ticket "pluggable everything" which is good and general for a release that far away
20:27 chromatic Maybe we only schedule for the next milestone release, and leave everything else as wishlist.
20:27 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
20:28 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"
20:28 chromatic I get the impression that we're not very good at predicting priorities more than a few months in advance.
20:29 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
20:29 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".
20:29 sorear 3.6 also has a ticket for ordered GC
20:29 allison chromatic: well, no one is really able to predict work 2 years in advance, that's not really the purpose of a roadmap
20:29 chromatic Right, but bumping things from milestone to milestone is busy work.
20:30 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?
20:30 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.
20:30 allison for some things, yes
20:30 chromatic That's a good point, japhb.
20:31 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?
20:31 allison they're not tied to a particular release, they're just a general priority
20:31 sorear +1
20:31 Whiteknight so instead of a roadmap, would it be good to just have a prioritized wishlist?
20:32 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
20:32 chromatic The nice thing about the roadmap is that it helps us decide what we're *likely* to do for the next milestone.
20:32 japhb Which leads to sorting that is the difference of two fuzzy numbers, and essentially random.  :-(
20:32 chromatic If we know we can do three big things per milestone, we pick our top three.
20:32 chromatic ... but we're not good at knowing what we can do per milestone.
20:33 japhb chromatic, very true.
20:33 allison though, honestly, I'd reserve the roadmap items for "big plans" rather than "small tasks"
20:33 tcurtis japhb: why not list both the importance and the feasibility separately and allow sorting by each?
20:33 Whiteknight tcurtis: that's not a bad idea. No idea how easy it is to do in trac
20:33 allison and really, I'd be fine with only having roadmap items for supported releases, and not for development releases
20:34 japhb tcurtis, a decent idea, though as chromatic stated we're rather poor at the second number.
20:34 Whiteknight allison: +1
20:34 chromatic Let's take proposals then.
20:34 chromatic What changes should we make?
20:35 japhb So: weekly: inch-pebbles, monthly: branches, quarterly: milestones?
20:35 allison japhb: I like that
20:35 chromatic Makes sense to me.
20:35 mikehh and also to maintain a prioritized TODO list
20:36 allison So, every week we review our weekly, monthly, and quarterly priorities
20:36 Whiteknight yes
20:36 chromatic and we need to schedule warm bodies on weekly priorities, otherwise they fall off our list
20:36 Whiteknight where hopefully we have fewer tasks in longer-term queues
20:36 allison mikehh: sounds like a wiki page
20:37 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 japhb chromatic, quite.
20:37 chromatic How will we know if this experiment works?
20:37 japhb I think mixing the sizes of priorities has led to trouble.
20:38 allison if we complete more weekly priorities
20:38 japhb Or at least, higher percentage of the ones we set for ourselves.
20:38 allison and spend less time reviewing pushing around roadmap items
20:38 allison and if we deliver on all the roadmap items for 2.6
20:39 chromatic Other comments?
20:39 allison (which would mean we both selected the right items and focused developer effort on them)
20:40 chromatic Can we all commit to trying this for 2.6?
20:40 * allison does
20:40 japhb In so far as I have any time to give ...
20:41 chromatic I'm all in.
20:41 chromatic Whiteknight?  cotto?  dukeleto?
20:41 cotto yes
20:41 Whiteknight I'm in
20:42 allison dukeleto is afk
20:42 chromatic Okay, let's move on.
20:42 chromatic Stale tickets in Trac.
20:43 allison we're at 661 active tickets
20:43 cotto Coke's been good about trolling old tickets regularly.
20:43 allison not bad, really
20:43 kid51 That's about 40 more than has been our traditional average.
20:43 chromatic I'd rather be under 500.
20:44 allison yes, agreed
20:44 japhb chromatic, what's magical about that number, aside from being round?
20:44 allison it's just at the level of "let's to a ticket-a-thon next weekend"
20:44 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
20:44 allison not at the level of "emergency!"
20:44 smash joined #parrot
20:44 smash hello everyone
20:44 allison hi smash
20:44 sorear hello
20:44 chromatic 500 is nice because we can close 50 more tickets than we open per release.
20:45 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?
20:46 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
20:46 Whiteknight cotto: +1
20:46 Whiteknight vague tickets don't help. There must be a clear standard for how we know when it's done
20:46 chromatic Do we need ticket closing guidelines?
20:47 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
20:47 Whiteknight allison: what are the benefits to that?
20:47 japhb Might need to ask people in the project to help those outside who don't know how to make tests for their problem.
20:47 allison it forces someone to clearly define the task of creating the test
20:48 allison 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?
20:48 japhb allison, Rakudo partially gets away with that because masak is really good about the precision of his initial reports.
20:48 japhb Trac does not seem to have good uptake.  People don't just wander over and start browsing it for work.
20:48 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
20:48 brooksbp Whiteknight: it's to understand how to implement closures on the stack
20:49 chromatic Maybe we're using Trac for the wrong things.
20:49 allison it is intended for bug reports
20:49 japhb Or we're using Trac wrong.  (giving it the benefit of the doubt)
20:49 allison we're using it for project planning
20:49 chromatic Right.
20:50 allison that was actually my complaint about RT too (using it for project planning)
20:50 allison do we have ideas for a better way to do project planning?
20:50 sorear quarterly meetings?
20:50 allison yes :)
20:51 allison 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.
20:51 bubaflub i'm a big fan of the task list / priority list
20:51 allison how to keep track of what needs to be done
20:51 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."
20:51 allison the spreadsheet is terrible for tracking milestones
20:51 kid51 That person doesn't have to promise any effort to achieving X.
20:51 allison (I say that with authority, because I've been maintaining the spreadsheet)
20:52 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?
20:52 japhb kid51, that implies trying to be aggressive about converting wishlist tickets to task list items, and closing the 'bug'
20:52 Whiteknight yes, definitely need somethign better than the spreadsheet
20:52 allison tickets are better than the spreadsheet, but I suspect there's something better than tickets
20:52 kid51 japhb:  Then perhaps I should go thru RT and reclassify many tickets as wishlist.
20:52 chromatic How about a wiki page?
20:52 kid51 s/RT/TT/
20:53 allison I'm not sure about a wiki page
20:53 allison it works well for branch tasklists
20:53 chromatic List our milestone priorities at the top, link them to tasks, then make everything else below that line an obvious wishlist item.
20:53 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.
20:53 allison but, I suspect a wiki may not scale well to 661 tasks
20:53 allison willing to give it a try, though
20:54 allison 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.
20:54 japhb I certainly think it's a good idea to make a pass on the TT's to separate bugs from feature requests.
20:54 allison aye, but scrolling still means you can't really focus on all of them at the same time
20:54 allison you have to page through in one way or another
20:54 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?
20:54 cotto is there a tool to embed reports in a wiki page?
20:54 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.
20:54 allison and, a wiki doesn't do well at sorting, selecting, etc
20:55 kid51 ... and frequently these are people who formerly were very active in Parrot.
20:55 Whiteknight a combination like bugzilla + testopia might be nice
20:55 allison kid51: would it help if we had a process to review those tickets in parrotsketch?
20:56 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..."
20:56 Util Reminder: any Trac ticket list can be downloaded in csv or tsv format.
20:56 japhb kid51: +`
20:56 japhb er
20:56 japhb +1
20:56 chromatic Let me ask the question a different way.  What *value* is there in keeping wishlist items in Trac?
20:56 allison kid51: at least they'd know they got our attention
20:56 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
20:57 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*?
20:57 allison chromatic: that's pretty much our entire data management problem
20:57 chromatic That's what I'm saying.
20:57 allison ah, Trac, well that's about selecting and sorting
20:57 allison the ability to manipulate the data
20:58 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
20:58 chromatic How is it better than a wiki page?
20:58 allison selecting, sorting, tagging
20:58 kid51 allison:  agreed
20:58 chromatic How is sorting and selecting useful?
20:58 chromatic Look at some of the wishlist items in Trac and tell me that they have sufficient detail to review?
20:58 allison because you can focus on a particular group of tasks/ideas
20:59 allison and, regroup them depending on what your interest is at a particular time
20:59 allison without having to manually move data around
20:59 chromatic Most of the wishlist items are useless.  They're inspecific.  They're vague.  They're stale.
20:59 allison remember, we started the roadmap in the wiki
20:59 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.
20:59 allison it was a terrible pain
20:59 Util In trac, varying amounts of detail and history do not lend weight to the more-documented items.
20:59 chromatic Wishlist items are documents.  Trac tickets are linear conversations.
20:59 allison we spent an enormous amount of time manually munging data around
21:00 allison agreed on wishlist as a document
21:00 chromatic Then why are we cramming documents that need to evolve with collaboration into bug reports?
21:00 allison by linear conversations you mean comments??
21:01 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?
21:01 chromatic That's my suggestion.
21:01 Whiteknight we do have a large assortment of tasklists
21:01 Whiteknight maybe those already are what we need
21:01 allison I'm good with wishlists as wiki pages
21:02 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
21:02 chromatic Sure, that would help.
21:02 cotto Ticket numbers are automatically crossed off when the relevant ticket is closed.  That'll help some.
21:02 allison and specific pages for specific larger items
21:02 chromatic kid51, migrate the request to the wiki and close the ticket.
21:03 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.
21:03 allison and also, include discussion of how we use wiki pages for wishlists in the "report a bug, make a request" documentation
21:03 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.
21:03 kid51 Is there one, definitive Wishlist page in the wiki?
21:04 allison kid51: not yet, that's one of the things I suggested adding
21:04 kid51 k
21:04 Whiteknight kid51: we have several. We could have one unsorted grabbag
21:04 chromatic We're moving into suggestions.  Shall we make these concrete?
21:04 kid51 yes
21:04 allison I'm not ready to give up tickets for roadmap items
21:04 allison unless we have a better solution
21:04 chromatic What do you see as the value of tickets for roadmap items?
21:04 allison selecting, sorting, etc
21:05 allison 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".
21:05 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
21:06 allison too many items that aren't really priorities
21:06 allison too much thrash
21:06 allison bumping tasks from one release to the next
21:06 chromatic Trying to schedule too many milestones in advance.
21:06 allison so, if we follow our new strategy for the roadmap, that may make a wiki page perfectly feasible for the roadmap
21:07 chromatic Is it worth experimenting with?
21:07 allison yes
21:07 chromatic Okay, let's get to specifics then.
21:07 allison I'm willing to do the legwork of transforming our roadmap tickets to a roadmap wiki page
21:07 chromatic Which concrete changes should we make?
21:07 chromatic Migrate wishlist tickets to a wishlist page?
21:08 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.
21:08 allison It's radical, but seems cleaner, easier to maintain.
21:08 chromatic Other suggestions?
21:09 japhb No good ones.  :-)
21:09 chromatic Okay.  Can we commit to changing our philosophy of Trac?
21:09 chromatic +1 from me
21:09 cotto yes
21:09 chromatic kid51?
21:09 japhb +1
21:09 chromatic Coke?
21:09 allison yes
21:10 allison should we discuss this on the mailing list before making a final call?
21:10 allison giving people who aren't here a chance to think it over?
21:10 japhb +0
21:10 chromatic It'll be part of the notes for this meeting.  Do we need something more?
21:10 kid51 yes, but mailing list post would be helpful;
21:11 allison we'll definitely do a post-meeting summary
21:11 chromatic I can write highlights of our changes.
21:11 allison I'll wait until after this week's parrotsketch to do roadmap conversion
21:11 allison (there's some chance someone may have a better idea)
21:11 chromatic Anything else on stale tickets?
21:11 cotto A message to the list would help reinforce the commitment to this change if nothing else.
21:12 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.
21:12 Whiteknight a definition like that would be easy to automate in trac with good SQL
21:13 chromatic How do we measure success for this experiment?
21:13 cotto Yes.  A "stale tickets" report would simplify life a little.
21:14 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.
21:14 japhb I blocked three hours, just in case.
21:14 chromatic Success condition: Trac is more useful?
21:15 kid51 yes
21:15 allison Trac becomes more managable, containing only actual bug reports
21:15 chromatic We close more Trac tickets per release?
21:15 allison we manage to keep the number of Trac tickets below 100 through 3.0
21:15 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 ....
21:15 chromatic All of these work for me.  Any more discussion here?
21:16 Whiteknight no
21:16 sorear we still have the entire agenda left
21:16 sorear oh, here
21:16 allison so, next question, extend the meeting, or reconvene at a later date/time
21:16 chromatic +1 to extend here
21:16 japhb +1 to extend
21:16 allison I'm inclined to extend
21:16 cotto +1
21:16 kid51 +1 to extend one hour max
21:17 Util +1
21:17 allison current hour +1 at half-past the hour
21:17 Whiteknight okay, lets rocket through the rest of the agenda
21:17 allison the rest is more design related
21:18 allison ready?
21:18 allison and...
21:18 allison go
21:18 Whiteknight ready!
21:18 allison - error reporting (line numbers)
21:18 chromatic I'm blocked on a testing framework for that.
21:18 allison this is a substantial priority for Rakudo
21:18 allison it is a task being actively worked on now
21:18 japhb You might be able to leverage the code in the weaving tool I wrote way back when
21:19 japhb (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.
21:19 allison do we have a good handle on what needs to be done? (sounds like yes)
21:19 allison do we need to get more resources on it?
21:19 chromatic Given that test, I can start to fix things (and explain how to fix them).
21:20 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.
21:20 japhb Ah, here it is: .../parrot/tools/util/dump_pbc.pl
21:20 allison Jonathan mentioned error reporting as a more general category, are there specific tasks we need to be thinking about there?
21:20 japhb The code in there might be useful to whoever is working on this (cotto, I guess)
21:21 cotto japhb, quite
21:21 Tene (I'd like to report both the original and rethrown location, maybe.)
21:21 Tene I expect to be able to get that branch merged into trunk in the near future.
21:21 allison Tene: reporting both seems sensible
21:22 allison Tene: especially if we can track it as "rethrown at..."
21:23 allison sounds like no one is aware of other error reporting issues, so that's one to take back to Jonathan
21:23 allison anything else on error reporting and line numbers?
21:24 cotto not from me
21:24 Whiteknight NEXT
21:24 allison a more general question on these items, do they become high-priorities in the new wiki pages?
21:24 allison think about it while we're running through
21:25 allison - block exit handlers, TT #1523
21:25 allison this is a priority for Rakudo
21:25 Whiteknight I started a branch to play with that
21:25 Whiteknight I think I need more info from the rakudo people first
21:25 allison how big does the task look?
21:25 Whiteknight depends on what they need
21:25 Whiteknight could be small, could be impossibly large
21:25 Whiteknight there are lots of ways to exit blocks
21:26 allison okay, this sounds like one that needs spec work
21:26 Whiteknight exactly.
21:26 allison possibly a PDD
21:26 allison basically, handler semantics
21:27 allison we'll spend time with Jonathan, etc to figure out what they need
21:27 Whiteknight yes, that would be perfect
21:27 allison - lexical implementation
21:27 allison another one for Rakudo
21:27 bacek ~~
21:27 chromatic Is that primitives stored as lexicals?
21:27 allison I don't have a good sense yet of what changes they need
21:28 Whiteknight yes, jonathan's email was not very detailed
21:28 allison he spoke of "proto-lexpad"
21:28 chromatic Not enough detail to schedule.
21:28 allison Patrick and I have talked about lexicals before, but not about that
21:29 allison so, another one to talk about with the rakudo team
21:29 allison PDD changes may be involved
21:29 allison - performance/memory usage in general
21:29 allison we've done well there this quarter
21:30 chromatic We should be able to improve further.
21:30 allison is there further low-hanging fruit people would like to attack this quarter?
21:30 chromatic I made a list of 16 performance improvements on the wiki.
21:30 allison you read my mind
21:30 Whiteknight steps for this one: 1) tell chromatic he can do whatever he wants. 2) ??? 3) Profit!
21:30 japhb chromatic, url?
21:30 chromatic http://trac.parrot.org/parrot​/wiki/PerformanceImprovements
21:30 japhb thx
21:30 chromatic Fixing Vtable Overrides is a big one.
21:31 chromatic We should be able to get constant string caching working after 2.3.
21:31 japhb Oh excellent, I like how you did this.
21:31 chromatic Sweep-free GC should be a big 2.6 priority.
21:31 chromatic Immutable strings may be mergeable (if desired) soon after 2.3.
21:31 allison I'm not sure Lorito belongs on the performance improvements page
21:32 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)
21:32 allison is there some way we can mark those off?
21:32 chromatic When completed, when scheduled, or something else?
21:32 allison do you mean "monthly branch sized"?
21:33 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?
21:33 allison I mean mark them as "big tasks"
21:33 chromatic allison, add another column, the first one, then put an X or a * in it.
21:33 allison something like that
21:33 chromatic japhb, reducing the number of constant strings thawed from PBC by 90%.
21:34 allison the exact details not important
21:34 japhb wah.
21:34 kurahaupo joined #parrot
21:34 chromatic It also lets us make runtime constant strings cheaper.
21:34 allison chromatic's list looks good
21:34 japhb agreed.
21:34 allison anything to add on performance improvements?
21:35 chromatic My recommendation is to make those two I suggested monthly branches.
21:35 allison sounds good
21:35 allison (on different months)
21:35 chromatic Yes.
21:36 allison we can discuss which months in parrotsketch
21:36 allison but, I'm guessing in the 2.4-2.5 area?
21:36 allison I'm also guessing the primaries will be chromatic and bacek
21:37 allison onward?
21:37 chromatic and upward
21:37 allison - plumage
21:37 allison this is a substantial project priority
21:37 japhb I am really low on free cycles, and I could really use help.
21:37 allison and we know that japhb isn't going to have much time to work on it
21:37 japhb I can guide, mentor, explain, and so on, but I don't seem to have cycles to code.
21:37 allison so, some discussion on how to boost work on it is useful
21:38 allison japhb: do you have a sense of how far along it is?
21:38 allison how much is left to be done?
21:38 japhb The basic structure is good.  Basic operation is as well.  Making it installable as part of Parrot is actually quite close.
21:39 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.
21:39 allison (the answer was no 4 months ago, and may still be no, but it's worth checking)
21:39 japhb Possible to pull into parrot core -- now, I'd say yes, with a relatively small amount of work.
21:40 allison as in, keeping multiple versions of the same modules installed at the same time?
21:40 allison 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)
21:41 japhb allison, multiple modules versions installed, and handling different modules requiring different versions of modules.
21:41 chromatic +0 to incore for me
21:41 allison chromatic: elaborate?
21:41 chromatic I'm no more or less likely to work on it.
21:42 japhb I'm somewhat concerned that I'm the only one interested in working on it, even though it is a project priority.
21:43 allison japhb: me too
21:43 japhb I'll take suggestions from the peanut gallery on changing that ...
21:44 allison curiously, I think it's a bootstrapping problem
21:44 sorear is plumage intended to supplant languag-specific systems like CPAN6 and Proto?
21:44 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".
21:44 allison CPAN has a body of energy behind it separate from Perl core, and we need the same
21:44 allison but, need Plumage before that can get started
21:44 japhb sorear: work with.  Proto could be replaced, or simply sit on top of the modules Plumage provides.
21:44 darbelo joined #parrot
21:45 allison japhb: yes, funding is a substantial possibility
21:45 japhb (to make a perl6-specific interface to general cross-Hll functionality)
21:45 * darbelo backlogs
21:45 japhb allison: then we should talk separately.
21:45 allison japhb: if we put together a funding proposal, I can shop it around to our sponsors
21:45 allison japhb: yes, let's do that
21:45 japhb THANK YOU.
21:46 allison further discussion on plumage?
21:46 allison - NFG strings
21:46 allison we have a summer of code proposal for this
21:46 Whiteknight darbelo proposed that for gsoc
21:46 allison that may give us the rough initial implementation
21:47 allison my concern about the proposal is that it suggests replacing *all* strings with NFG strings
21:47 allison which is contrary to the fundamental design of parrot, and likely to be dog slow
21:47 japhb -1 to "all" strings
21:48 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.
21:48 allison darbelo: that was my impression while reading the proposal
21:48 Whiteknight once we have the encoder and deocder for NFG, however we choose to insert it into the system is a relatively small decision
21:48 bacek replace "fundamental design of strings" looks good for me
21:49 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?
21:49 chromatic Let's not get into design discussions during scheduling.
21:49 allison sorear: we can talk later
21:50 allison sorear: also, take a look at the strings PDD
21:50 * dukeleto is back
21:50 sorear ok
21:51 allison so, we'll hope NFG strings is one of the funded GSoC proposals
21:51 allison (and talk further later if not)
21:51 allison - concurrency
21:52 allison several people brought this up as a priority
21:52 allison and there's one GSoC proposal
21:52 japhb And I've heard outside requests for it as well (when chatting with people outside #parrot)
21:52 smash (concurrency) i love that topic
21:52 allison threads currently work, but they're limited
21:52 chromatic Concurrency is a post-Star priority for Rakudo.
21:53 allison (the GSoC proposal focused heavily on one failing test)
21:53 sorear threads in parrot today are basically just p5 fork emulation?
21:53 allison sorear: no, they're full POSIX threads on *nix, and windows threads on windows
21:53 japhb I would really like to see some of the classic pre-threads unix-style stuff working well -- fork, pipe, etc.
21:54 allison japhb: that's a good point, not to lose sight of the simple things in the more complex things
21:54 japhb nodnod
21:54 plobsing can we really say that threads work if they dissable GC?
21:54 allison that's a problem with GC
21:54 allison not with threads
21:55 allison (slight semantic difference, but important)
21:55 plobsing but the problem with GC makes threads nearly unusable
21:55 japhb Though our users simple see "it doesn't WFM"
21:55 japhb er simply
21:55 dukeleto chromatic: i am +1 to the new roadmap experiment for 2.6
21:56 * dukeleto is backlogging
21:56 allison I guess the main question here, in planning, is which should be first?
21:56 allison should we focus on concurrency first or GC?
21:56 japhb GC
21:56 chromatic GC
21:56 bacek I vote for GC
21:56 smash i would say GC, it makes mre sense
21:57 allison okay, that was my sense as well
21:57 allison concurrency would be our priority for around summer-time
21:57 Util GC first
21:57 Chandon joined #parrot
21:57 sorear hello
21:57 Chandon Hullo. Meeting still going?
21:57 mikehh bearing in mind that work on GC needs to consider possible concurrency issues
21:57 sorear yes
21:58 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
21:58 allison mikehh: definitely
21:58 dukeleto +1 to GC
21:58 japhb mikehh, as long as "keep it in mind" does not prevent actual immediate work from getting done, I agree.
21:58 allison okay, will come back to GC later in the agenda
21:59 allison (we're about half done and about half-way through our extended hour, so doing well)
21:59 allison - prototype-based OO
21:59 japhb What was that about?
21:59 allison this is for Rakudo
21:59 japhb Oh, sorry, misread
22:00 allison Jonathan expressed some concerns about Class and Object not being a good base for Rakudo OO
22:00 allison really, we expected that
22:01 allison 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.
22:02 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
22:02 sorear can we derive Rakudo classes from P5 classes?
22:02 allison japhb: he was reading more into the unification of PMCs with HLL classes than we actually plan
22:02 sorear but this is post-Star
22:02 japhb ah
22:02 sorear 95% of CPAN doesn't need to be subclassed to be useful
22:02 allison that is, we do plan to merge them closer together, but we don't plan to exclude other class models
22:03 allison it's just that the current PMC+PMCProxy cludge doesn't really work
22:03 allison a "temporary" fix that has lived out its useful existance
22:04 allison so, are there any objections to adding a Prototype PMC to the core?
22:04 Whiteknight +1
22:04 japhb no objection
22:04 sorear no objection
22:04 dukeleto no objection. PMCProxy gives me the creeps
22:04 mikehh none from me
22:05 snarkyboojum joined #parrot
22:05 allison okay, good
22:06 allison will let jonathan know
22:06 allison (and will respond to that message in more detail)
22:06 allison next
22:06 allison - HLL interop TT #556, #557, #558
22:06 allison someone mentioned they were working on this now?
22:06 dukeleto allison: i am -1 to plumage being in core and +1 on working on it with direction from japhb
22:06 japhb dukeleto, yay!
22:07 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
22:07 japhb We can talk more about what time you have and when.
22:07 sorear i.e. I'm treating the PDDs as guidelines, not rules, and will update them once blizkost is working
22:07 allison sorear: that's reasonable
22:07 * Whiteknight goes to dinner, will backlog, assume I agree with everything chromatic says :)
22:08 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
22:08 japhb For me HLL interop is in general fairly high priority, but HLL -> Parrot module loading is very high.
22:08 lue joined #parrot
22:08 allison sorear: don't want you to get to the end and then get an overwhelming slurry of comments
22:08 allison sorear: that should keep everyone involved in your thinking
22:09 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)
22:10 japhb Does anyone know if pmichaud is able to schedule an hour yet?
22:10 chromatic +1 to that
22:10 allison japhb: good idea
22:10 allison pmichaud's availability varies still
22:11 allison but, he's good at passing along his general ideas to a delegate
22:11 japhb OK
22:11 allison next:
22:11 allison - moving the build system off Perl5
22:11 allison this is a general project goal
22:11 japhb Not for me a priority, but I know it's important to some.
22:11 allison not an urgent priority
22:11 allison just a direction we're moving along
22:12 allison (as in, it guides other decisions)
22:12 darbelo It's a lot of small-ish tasks, not a big monolith.
22:12 chromatic We need to make that into smaller tasks.
22:12 allison sounds like a new wiki page
22:12 sorear what we need to agree on is a language to use
22:12 bacek e.g. "finish opsc"
22:12 allison sorear: as much as possible, nothing external to parrot
22:13 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?
22:13 sorear what I'm toying with is an NQP-autoconf that generates (shell scripts, C, perl5, etc)
22:13 sorear but there's probably a simpler way
22:14 japhb +1 to aiming for simple
22:14 sorear +1 to a wiki page to review possibilities
22:15 allison okay, we'll mention it in the summary as a possible task
22:15 allison next
22:15 Tene japhb: That's a great idea, I'd love to do that.
22:15 allison - chmod files
22:15 allison I'd say this is simply "yes, that's a good feature, add to the wishlist"
22:16 kid51 Agreed; same for next two agenda items
22:16 allison same for tar library and zlib library
22:16 sorear OSInterfaceAdditionsTasklist
22:16 allison sorear: excellent, thanks!
22:16 allison next
22:16 allison - git
22:17 dukeleto do people still want to convert to git?
22:17 sorear I thought git was outright rejected?
22:17 japhb I do.  But I don't feel it's worth another big battle.
22:17 allison we said during the last conversation it that we'd postpone any tool changes til after 3.0
22:17 chromatic I thought it was until after Rakudo Star.
22:17 dukeleto ok, i was not sure if it was 2.3 or 3.0
22:17 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.
22:18 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.
22:18 cotto I'm for it whenever it's possible.
22:18 bubaflub didn't someone talk about getting a duplicate trac with git integration up and running for us to see?
22:18 allison this is is a planning session, so the question is "is this something we want to discuss during this quarter?"
22:18 kid51 Not during this quarter.
22:18 sorear no
22:19 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
22:19 bacek +1 for git
22:19 dukeleto and to have an "official" parrot git mirror
22:19 allison dukeleto: no decisions here
22:20 allison 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.
22:20 allison personally, I'm more inclined to go to mercurial
22:20 allison so, even that may be presuming too much
22:20 kid51 Then let's have a mercurial proposal as well
22:20 allison though, it would at least give us an idea of feasibility
22:20 mikehh bzr
22:20 allison I like bzr too
22:21 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.
22:21 sorear hmm, tracwiki isn't letting me log in, so I can't create OSInterfaceAdditionsTasklist right now
22:21 allison and really, it's probably worth talking with the developers of some of these projects
22:21 mikehh Ubuntu does very well on bzr
22:21 dukeleto kid51: i understand that. I was involved in a large svn->git transition recently. It is worth it on the other side
22:21 allison (I know several of them)
22:21 sorear kid51: the git advocates don't have much power because git primarily benefits non-commit-bits
22:21 allison okay, 10 minutes levt
22:22 allison left
22:22 allison let's set git aside
22:22 allison talk again at the next quarterly meeting? or between now and then?
22:22 chromatic -1 to hg
22:22 sorear next quarterly sounds good
22:22 kid51 next q; next agenda item
22:22 dukeleto allison: i can send something to parrot-dev
22:22 allison dukeleto: ok
22:22 allison - security subsystem
22:23 allison this is a priority
22:23 dukeleto The security subsystem is the largest blocker for PL/Parrot
22:23 allison as in a quarterly roadmap level priority
22:23 chromatic Which quarter?
22:23 allison we have a PDD, I'd say the next step is converting that into a tasklist
22:24 allison chromatic: doesn't matter yet, we need to work out more details first
22:24 allison not before 2.9
22:24 allison perhaps 3.0
22:24 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
22:24 allison that's a specific task
22:25 allison and can actually be worked on right away
22:25 dukeleto allison: that sounds great. I can help
22:25 allison excellent, we can talk about details
22:25 allison next
22:25 allison - runcore support, can we trim the list?
22:25 allison yes
22:26 allison and I'm open to proposals on the list about which ones to trim
22:26 chromatic That should be easy.
22:26 bacek keep slow/fast cores only
22:26 chromatic Can we discuss that in the upcoming #ps, to deprecate them at 2.3?
22:26 allison chromatic: good idea
22:26 japhb +1
22:26 mikehh +1
22:26 cotto +1
22:26 bacek +1
22:27 darbelo +
22:27 darbelo 1
22:27 sorear -1 to dropping cgp without a *very* good rationale
22:27 allison there are a few tickets mentioned here, which I'll look over and discuss after the meeting
22:27 allison so, last item
22:27 allison what's our next big task?
22:28 allison I suggested GC/Concurrency/Lorito
22:28 allison and it sounds like GC is the winner
22:28 japhb +1 to GC
22:28 chromatic GC
22:28 mikehh +1
22:28 bacek I can work on GC after finishing immutable strings.
22:28 allison in a rough approximation of order, I'd say we're looking at GC, then Concurrency, then Lorito, then JIT
22:29 allison bacek: good, thanks
22:29 chromatic Do we need "Make sure that GSoC projects succeed" as a milestone?
22:29 allison the first order on GC is to review and extend the tasklist
22:29 bubaflub that'd be nice
22:29 allison it's a project priority, but not really a development milestone
22:30 allison 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.
22:30 allison so there's not much anyone can do except the mentor
22:30 allison that's a good goal
22:30 allison so, something to review every week?
22:31 allison and see if their blockers can make weekly priorities?
22:31 mikehh sounds good
22:31 darbelo Weekly GSoC reports helped me keep an eye on the schedule last year.
22:31 allison those are quite helpful
22:32 japhb Yes, keeping GSoC unblocked via weekly tasks seems very worthy.
22:32 dukeleto weekly gsoc reports will be done this year
22:32 allison any final topics to discuss?
22:32 dukeleto i will tell all parrot students to submit either an email and/or blog post to parrot-dev each week
22:33 cotto dukeleto, great
22:33 allison alright, thanks everyone for participating!
22:34 allison (back to your regular unscheduled #parrot)
22:36 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
22:36 allison dukeleto: excellent, thanks
22:37 chromatic bacek, my Rakudo-building benchmark is 4.584% faster with immutable strings than without.
22:38 mikehh chromatic++, bacek++
22:38 mikehh hey do we need to re-activate purl?
22:38 chromatic We need to find a few more optimizations.
22:38 sorear allison: ok, fperrad's OS tasklist is on the wiki now
22:39 allison sorear: great!
22:39 dukeleto +1 to letting purl back in. it looks cold and rainy outside
22:39 Whiteknight I think GSoC'ers should probably be at weekly #ps too
22:40 darbelo Whiteknight: +1
22:40 dukeleto Whiteknight: that sounds like a good idea
22:41 sorear purl doesn't respond to INVITE, any purl admins handy?
22:41 allison purl is sulking
22:41 Whiteknight we need to craft an apology that she can parse
22:42 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
22:43 Whiteknight tcurtis: #ps is a meeting like this one that happens every tuesday in the #parrotsketch chatroom
22:43 Whiteknight it's 4:30 my time, so 3:30 for you?
22:43 darbelo Ask purl when she comes back :)
22:43 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
22:44 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
22:45 dalek parrot: r45574 | chromatic++ | branches/immutable_strings_part1/src/string/api.c:
22:45 dalek parrot: [str] Removed unnecessary string copying from Parrot_str_append().
22:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45574/
22:45 dalek parrot: r45575 | chromatic++ | branches/immutable_strings_part1/src/ops (2 files):
22:45 dalek parrot: [ops] Removed an unnecessary Parrot_str_clone() from the clone STR, STR op.
22:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45575/
22:45 darbelo dynloadable runcores?
22:45 plobsing darbelo: how does that play with dynloadable oplibs?
22:46 darbelo In NxM ways, I'd guess.
22:48 dukeleto dynloadable runcores would make the gsoc instrumentation proposal nicer
22:48 dukeleto but he could just create a new instrumentation runcore, i guess
22:48 dalek tracwiki: v1 | sorear++ | OSInterfaceAdditions
22:48 dalek tracwiki: from #parrot
22:48 dalek tracwiki: http://trac.parrot.org/parrot/wiki/OSInte​rfaceAdditions?version=1&amp;action=diff
22:48 dalek tracwiki: v2 | sorear++ | OSInterfaceAdditions
22:48 dalek tracwiki: fix list formatting
22:48 dalek tracwiki: http://trac.parrot.org/parrot/wiki/OSInte​rfaceAdditions?version=2&amp;action=diff
22:48 dalek tracwiki: v163 | sorear++ | WikiStart
22:48 dalek tracwiki: link OSInterfaceAdditions
22:48 darbelo dukeleto: They are already pluggable.
22:48 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=163&amp;action=diff
22:48 chromatic Making runcores dynloadable is a SMOP.  Adding a runcore is a sMOP.
22:49 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 allison Whiteknight/chromatic/sorear: I'd say yes to the first and no to the second
22:49 darbelo The upside is that, if they are dynloadable, exotic runcores are someone else's problem.
22:49 Util chromatic: doesn't CGP work on Win32 when compiled with MinGW (which is really GCC)?
22:49 allison (which tends toward ripping out the current one to make way for a better one)
22:51 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.
22:51 sorear Forth people call it "direct threaded code"
22:52 Util VS is not the only supported compiler on Win32
22:52 allison Util: yes, but it's one we have to support
22:53 darbelo Util: CGP is gcc-only, afaict.
22:53 allison so, anything that doesn't run on VS must be "optional" to the core
22:53 sorear computed goto is gcc-originated, but icc and clang emulate it
22:54 allison I like dynaloadable runcores
22:54 allison libparrot is monstrously huge
22:54 sorear dynloadable runcores don't have to N*M with dynloadable oplibs because dynops are not like coreops
22:55 sorear dynops look something like _dynopdispatch "find_lex_skip_current", "$_", $P0
22:55 sorear dynops are only compiled for the fast core; _dynopdispatch emulates the fast core no matter the current runloop
22:55 chromatic Cutting runcores, or at least making them optional, helps make Lorito more tractable.
22:57 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.
22:57 allison chromatic: doesn't lorito pretty much replace the current runcores?
22:57 chromatic Yes.
22:57 allison then, they're all deprecated :)
22:57 darbelo Less runcores == less to replace.
22:58 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 wknight8111 joined #parrot
22:59 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 allison and, should plan to start with a single runcore for Lorito
22:59 allison with the idea of making it pluggable to add more later
23:00 allison with the further restriction that adding a runcore shouldn't involve bulking out parrot's footprint
23:00 allison restriction/suggestion?
23:00 wknight8111 I like the plan
23:01 mikehh +1
23:01 dukeleto sounds good to me
23:01 chromatic 398596 src/ops/core_ops_cg.o
23:01 chromatic 459648 src/ops/core_ops_cgp.o
23:01 chromatic 1136124 src/ops/core_ops.o
23:01 chromatic 1972148 src/ops/core_ops_switch.o
23:01 wknight8111 runcores we dont use are worthless, practcally speaking
23:01 mikehh although we need to retain testr or something similar
23:01 wknight8111 yes, testr is good
23:02 chromatic I suggest a branch which disables building/linking of specific cores, so we can check footprint and benchmarking.
23:02 chromatic ... but I must leave now.
23:02 allison good idea
23:02 chromatic I looked at it once, but it required more Makefile hackery than I wanted.
23:05 dalek tracwiki: v164 | dukeleto++ | WikiStart
23:05 dalek tracwiki: http://trac.parrot.org/parrot/wiki/W​ikiStart?version=164&amp;action=diff
23:05 mikehh did anyone figgure out how to stop purl sulking
23:05 sorear erm, does lorito mean we're dropping C89?
23:05 allison so, our runcores alone account for 2.5M of libparrot's current 9M hulk
23:05 whiteknight sorear: how does on relate to the other?
23:05 bacek chromatic, (performance) excellent.
23:06 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
23:06 whiteknight so...why drop C89?
23:07 allison sorear: not dropping it
23:07 allison sorear: since Lorito itself will be written in C
23:07 whiteknight killing some useless opcodes would bring down bulk too
23:07 allison sorear: but severely reducing the scope of it's presence
23:08 allison 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?
23:08 sorear ah, so there would be a Lorito interpreter?
23:08 allison mikehh: it is the most portable subset
23:09 allison sorear: Lorito is really just a codename for the next Parrot core
23:09 mikehh yeah I know - but still 20th Centuary
23:10 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
23:10 whiteknight mikehh: and microsoft C is C89
23:10 allison mikehh: the dates are misleading
23:10 whiteknight to support that really dictates our standard
23:10 mikehh :-}
23:10 allison mikehh: it's more like "core C" and "extended C"
23:11 allison 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
23:11 allison whiteknight: good point
23:12 allison mikehh: yeah, we're also supporting that end of the spectrum
23:13 allison sorear: which is to say "yes, it's the equivalent of IMCC and PIR"
23:15 Util re: CGP core - Abe Pralle got a CGP-equivalent core working in MSVS, by using just a dollop of inline assembly
23:15 Util http://abepralle.wordpress.com/2009/01/25/how-not​-to-make-a-virtual-machine-label-based-threading/
23:19 dukeleto Util: that is quite interesting
23:21 dalek tracwiki: v1 | dukeleto++ | SecurityTasklist
23:21 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Secu​rityTasklist?version=1&amp;action=diff
23:42 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.
23:42 whiteknight allison has dibs on darbelo's
23:43 cotto fine by me.  It just shouldn't be me.
23:43 whiteknight I want Nat's
23:43 cotto That strikes me as one you'd want.
23:44 cotto I know the assignments are temporary but I also don't want them to inadvertently become permanent.
23:53 sorear allison: report sent

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

Parrot | source cross referenced