Camelia, the Perl 6 bug

IRC log for #parrot, 2010-04-30

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 Coke mmm.
00:23 snarkyboojum joined #parrot
00:27 Mokurai1 joined #parrot
00:28 Coke cotto_work: pmc-> results in an invalid variable name.
00:29 * Coke tries SELF
00:36 bacek_at_work Coke, stop touching you SELF
00:38 Coke :P
00:38 Coke ugh. gdb and pmc .c files is a terrible combination.
00:45 kid51 I see from the YAPC Calendar that there is a Parrot/Perl 6 workshop scheduled for all day on the 3rd day:  http://yapc2010.com/yn2010/event/674
00:45 kid51 I thought Allison had nixed the idea of a Parrot workshop at YAPC.
00:49 Coke I thought that was just a BOF room.
00:49 Coke is RSA the one that's been failing recently?
00:50 Coke ah, yup, there it is.
00:50 kid51 True, it's listed in a BOF room -- but BOFs typically take place at lunchtime or late afternoon/early evening
00:50 Coke they have a lot more rooms to fill this time.
00:50 Coke i heard in #yapc that pmichaud had req'd the bof room.
00:51 Coke woot. coretest passes with my codestring mods...
00:51 kid51 Actually, it's listed in that room for all 3 days of the conference!
00:51 kid51 pmichaud has two talks scheduled in the main rooms.  This workshop is distinct from those.
00:52 kid51 And there's no detail as to what the workshop will consist of on any given day.
00:54 snarkyboojum joined #parrot
00:55 dalek rakudo: f31d524 | jonathan++ | src/Perl6/Module/Loader.pm:
00:55 dalek rakudo: Apply patch from sorear++ to further fix up loading modules from other languages.
00:55 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​31d524037b6c298002e96323504b573ae6590c4
00:57 Coke I think it's just an ongoing hackathon. =-)
00:57 Coke but I don't know. I'd ping the list and ping #yapcs.
00:58 dalek parrot: r46161 | darbelo++ | trunk/src/dynpmc/Rules.in:
00:58 dalek parrot: [dynpmc] Move the .h along with the .c file to the dynpmc/ dir.
00:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46161/
00:59 kid51 I just think that if we want to occupy a given space for all 3 days, we should have a more focused agenda at particular times.
01:05 Coke that's what the talks are for.
01:08 ash_ joined #parrot
01:08 snarkyboojum joined #parrot
01:14 dalek parrot: r46162 | coke++ | branches/codestring/src/pmc/string.pmc:
01:14 dalek parrot: Make String more forgiving about child PMCs that don't use the String ATTR.
01:14 Coke I'd probably just start by figuring out who drove getting us the room.
01:14 dalek parrot: This seems too verbose, and perhaps is a good candidate for PMC2C to do for us.
01:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46162/
01:14 dalek parrot: r46163 | coke++ | branches/codestring/src/pmc/codestring.pmc:
01:14 dalek parrot: Whoops, checked wrong variable.
01:14 dalek parrot: Don't create a new RSA when caching, just reusing the existing one.
01:14 dalek parrot: 'make test' now at 100%
01:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46163/
01:16 TiMBuS joined #parrot
01:36 kid51 Hmm, build failure
01:36 kid51 error:imcc:syntax error, unexpected $end
01:36 kid51 in file 'runtime/parrot/library/ProfTest/PIRProfile.pir' line 1
01:37 nopaste "kid51" at 192.168.1.3 pasted "'make' failure in trunk at r46163" (839 lines) at http://nopaste.snit.ch/20409
01:39 kid51 This is where things start looking amiss:
01:39 kid51 src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
01:39 kid51 Backtrace - Obtained 31 stack frames (max trace depth is 32).
01:40 kid51 ... which was immediately preceded by:
01:40 kid51 ./parrot-nqp --target=pir runtime/parrot/library/ProfTest/PIRProfile.nqp > runtime/parrot/library/ProfTest/PIRProfile.pir
01:45 Coke kid51: that's been failing sporadically in taptinder for 2 days.
01:48 kid51 I had successful builds on this box at r 46126 last night.
01:49 Coke yup. it's sporadic.
01:49 Coke taptinder?
01:49 purl it has been said that taptinder is continues integration tool - http://taptinder.org . For Parrot project running on http://tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot.
01:55 mikehh joined #parrot
01:58 Psyche^ joined #parrot
01:59 JimmyZ joined #parrot
01:59 kid51 This is indeed strange.  I'm getting a build failure on a checkout of r46126 -- the same rev at which I got PASS in make test (and relevant parts of make fulltest) last night
02:04 ttbot Parrot trunk/ r46161 i386-freebsd-64int make error http://tt.taptinder.org/file/cmdout/288509.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
02:05 kid51 I take back what I said about 46126.  I misspecified the test.
02:15 kid51 Hmm.  Successful builds and make test at 46153 and 46154.
02:16 Coke can someone time a rakudo build for me? (with trunk and with branchs/codestring)
02:16 sorear rakudo build with trunk is 12m real 10m user
02:16 sorear with codestring is "how do I switch branches?
02:17 Coke svn switch <path to branch>
02:20 Coke not sure if that'll work with the --gen-parrot stuff.
02:22 kid51 Damn:  an intermittent build failure:  the worst kind.
02:22 kid51 I've gotten both successful and failed builds at r46163.
02:25 sorear ok, started rakudobuild on the branch
02:26 Coke hokay. lemme konw.
02:26 kid51 The first taptinder report at which this particular build failure was reported was this one by Allison at r46092:  http://tt.taptinder.org/file/cmdout/285080.txt
02:27 Coke it's sporadic, though; could be any number of commits before that.
02:27 Coke that's an excellent starting point, htough.
02:28 theory_ joined #parrot
02:36 kid51 Well, one clear possibility is r46054, where a change was made to the NQP file associated with the failing PIR:  runtime/parrot/library/ProfTest/PIRProfile.nqp
02:38 bacek_mobile joined #parrot
02:38 bacek_mobile hi
02:39 bacek_mobile problem with segfaults is in compact-pool-revamp merge
02:39 kid51 bacek_mobile:  Which commit was that merge?
02:41 theory joined #parrot
02:41 kid51 r46077
02:42 kid51 okay, if that commit was problematic, that would be chronologically consistent with failures observed; none were before that
02:45 sorear what is the logic behind responding to out of memory by abort() ?
02:45 sorear dropping a 1.5 GB core file is very disruptive to system operation
02:45 Mokurai joined #parrot
02:48 Coke debug purposes?
02:49 Coke Iunno.
02:51 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33563), fulltest) at r46163 - Ubuntu 10.04 i386 (g++)
02:51 mikehh t/pmc/packfile.t - TODO passed:   34 - in coretest, smoke and all cores in fulltest
02:51 mikehh in testf - t/op/exit.t - TODO passed:   6
02:52 dalek parrot: r46164 | jimmy++ | trunk/src/oo.c:
02:52 dalek parrot: random consting
02:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46164/
02:54 theory joined #parrot
02:55 sorear Did something change in parrot_config recently?  I'm getting cg_flag not found errors with blizkost
02:56 ttbot Parrot trunk/ r46164 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/288556.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
02:59 Mokurai joined #parrot
03:00 janus joined #parrot
03:02 * mikehh ha - it's after 4am for me - needs sleep - bbl
03:06 JimmyZ sleeping well
03:13 Coke sorear: you mean "cc_flag" ?
03:14 Coke its "ccflags"
03:16 snarkyboojum joined #parrot
03:20 sorear Coke: no, @cg_flag@
03:20 sorear it worked fine until I updated parrot from 2.3.0 to trunk
03:20 sorear unfortunately there are no comments to explain what it /does/
03:20 purl Hmm.  No matches for that, sorear.
03:20 Coke ah, yes. probably removed with the runcore.
03:20 sorear "the runcore"?
03:21 Coke the computed goto runcore.
03:21 sorear ohhh
03:21 sorear I was trying to expand it as cc -g flag
03:21 Coke why are you looking for it?
03:21 Coke ... no.
03:21 Coke that might be @optimize@
03:21 sorear because blizkost FTBFS with a missing config entry error
03:22 Coke it shouldn't need it unless it was generating dynamic opcodes.
03:22 sorear blizkost uses a cargo cult build system
03:22 sorear there are no comments and lots of platform ifs
03:22 sorear I have no idea what half of it is for
03:24 Coke blizkost?
03:24 purl i think blizkost is http://github.com/jnthn/blizkost/tree/master or the last Jonathan's project, an embedding of Perl 5 in Perl 6
03:24 Coke is that the main url?
03:28 Andy joined #parrot
03:28 sorear Coke: yes
03:28 Coke k. checking.
03:29 Coke looks like you can just remove it.
03:30 Coke s/@cg_flag@ //
03:30 Coke I do that, I get a warning about my Perl not allowing interpreters, and then build fails on exactly that.
03:30 Coke rip it out, give it a shot. =-)
03:34 dalek blizkost: 02c45ba | sorear++ | build/Makefile.in:
03:34 dalek blizkost: Remove obsolete references to the cgoto core
03:34 dalek blizkost: Coke++ for decyphering the error.
03:34 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​02c45baa0c68e374d462190bdde3ff25f11d1606
03:42 dalek parrot: r46165 | jimmy++ | trunk/src/pmc/class.pmc:
03:42 dalek parrot: changed interp to INTERP for unification
03:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46165/
03:45 Coke Jimmy++
03:46 Coke sorear: hey, would you be willing to try that build again with a slightly different patch?
03:46 Coke (which I have not yet committed)
03:46 sorear Coke: yes
03:50 ttbot Parrot trunk/ r46168 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/288647.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
03:51 Coke tewk: to save me the trouble, can you add experimental notes for your new pmcs?
03:52 Coke (also, why is one named parrot* and one not? (I always thought naming anything parrot* was redundant. =-)))
03:52 Coke (also (lisping))
03:54 ttbot Parrot trunk/ r46169 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/288684.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
03:54 kurahaupo joined #parrot
03:57 dalek TT #1395 closed by jimmy++: [patch]various minor change to parrot
03:57 dalek TT #1395: http://trac.parrot.org/parrot/ticket/1395
03:57 dalek TT #92 closed by jimmy++: Should all header files under src/ be moved to include/ dir?
03:57 dalek TT #92: http://trac.parrot.org/parrot/ticket/92
03:58 Coke sorear: ok. branch updated with a WAG.
03:58 dalek parrot: r46166 | tewk++ | trunk (4 files):
03:58 dalek parrot: Remove old thread pmcs
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46166/
03:58 dalek parrot: r46167 | tewk++ | trunk (5 files):
03:58 dalek parrot: Remove thread types PARROT_THR_TYPE_1 ...
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46167/
03:58 dalek parrot: r46168 | tewk++ | trunk (2 files):
03:58 dalek parrot: Remove pt_thread_run
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46168/
03:58 sorear WAG?
03:58 purl WAG is Wild Ass Guess
03:58 dalek parrot: r46169 | tewk++ | trunk (2 files):
03:58 dalek parrot: new thread creation functions
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46169/
03:58 dalek parrot: r46170 | tewk++ | trunk (7 files):
03:58 dalek parrot: Added new parrotthread pmcs
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46170/
03:58 dalek parrot: r46171 | coke++ | branches/codestring/src/pmc (2 files):
03:58 dalek parrot: passing codetest
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46171/
03:58 dalek parrot: r46172 | coke++ | branches/codestring/src/pmc/codestring.pmc:
03:58 dalek parrot: Instead of re-using the existing FSA, see if making a new one is more
03:58 dalek parrot: friendly to memory usage.
03:58 dalek parrot: (Was the old one hanging onto the old elements?)
03:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46172/
03:59 sorear Coke: fwiw I'm *not* doing distcleans between branch switches
03:59 sorear tewk is the gsok thread guy?
04:01 Coke msg tewk: regarding removal of the old PMCs in trunk - was ther ea ticket for that? (I don't see it in deprecated.pod)
04:01 purl Message for tewk stored.
04:03 sorear Coke: within 3 seconds, 800MB and climbing fast
04:04 sorear this could just be a transient though - hold on
04:05 tewk Coke: threads are just plain broken, this is an attempt to slowly fix them.
04:06 tewk sorear: I'm not the gsok guy.
04:07 sorear huh
04:07 sorear top says 12% SY
04:07 sorear I didn't know swapping was that CPU intensive
04:09 tewk I have a very preliminary draft pdds that gives some ideas on how to implement parallelism on a language virtual machine.
04:09 Coke tewk: by completely changing the interface?
04:09 Coke I'm not complaining about fixes, just wish we had a ticket before 2.3.0 went out the door.
04:09 Coke c'est le vie.
04:10 JimmyZ tewk++ for parallelism
04:11 sorear Coke: with your fix, rakudo build ran out of memory 25% faster.
04:11 sorear only took 9 minutes this time.
04:12 JimmyZ sorear: how about trunk?
04:12 tewk http://tewk.com/pdd32_parallelism
04:12 sorear JimmyZ: Finishes without error in 12 minutes.
04:13 JimmyZ how about memory?
04:13 purl DOCTOR MEMORY!!!
04:13 sorear I don't know
04:13 tewk What I just checked in is broken too, (no GC support),  but succesfully I've implemented futures on top of what I just checked in.
04:13 sorear I dozed off when I was supposed to be staring at top and all I have is the time output :(
04:13 tewk Coke: where do you want experimental notes.
04:13 dalek TT #896 closed by jimmy++: [patch]consting socket_win32.c
04:13 dalek TT #896: http://trac.parrot.org/parrot/ticket/896
04:14 dalek parrot: r46173 | jimmy++ | trunk/src/io/socket_win32.c:
04:14 dalek parrot: random consting
04:14 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46173/
04:15 ttbot Parrot trunk/ r46173 i386-freebsd-64int make error http://tt.taptinder.org/file/cmdout/288788.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
04:19 kurahaupo joined #parrot
04:19 sorear tewk!  you broke my build
04:19 sorear make: *** No rule to make target `src/pmc/parrotrunningthread.pmc', needed by `src/pmc/parrotrunningthread.dump'.  Stop.
04:19 sorear svn status shows no '!'
04:20 tewk sorear: make realclean
04:22 Coke sorear: jezu. Ok, I'll leave it for chromatic to figure out. =-)
04:23 Coke tewk: open a ticket, add a ref to it in the DEP.pod (mark the ticket as an 'experimental' - feel free to use one ticket to cover everything.)
04:39 wagle joined #parrot
04:41 kurahaupo joined #parrot
04:46 dalek TT #1601 created by tewk++: Parallelism aka ParrotThreads
04:46 dalek TT #1601: http://trac.parrot.org/parrot/ticket/1601
04:47 dalek parrot: r46174 | tewk++ | trunk/DEPRECATED.pod:
04:47 dalek parrot: Add thread and parallelism to experimental
04:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46174/
04:49 Coke tewk: if you're reusing an existing name, that's fine. the commit said "added".
04:49 Coke so I assumed it was new.
04:50 tewk Well I removed it then added it again, so I think you may have a good point.
04:53 Andy joined #parrot
05:03 rurban_ joined #parrot
05:12 Andy joined #parrot
05:13 ttbot Parrot trunk/ r46174 cygwin-thread-multi-64int make error http://tt.taptinder.org/file/cmdout/288907.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
05:21 Coke if anyone can track down the memory usage issues with building rakudo master with the parrot branch "codestring", I'd appreciate it.
05:21 Coke I pinged chromatic, but he is not swooping in to save the day.
05:21 Coke (I assume Real Life is involved.)
05:22 Coke ah. it wasn't pmichaud that requested the parrot room, it was particle.
05:22 Coke (per pmichaud++)
05:23 Coke only changes in the branch are to codestring (make it has-a-RSA and use that for all 'emit'() usage), and String (make it be nicer to new codestring subclass)
05:23 sorear IIRC subclassing PMCs is extremely expensive
05:23 JimmyZ Yeah
05:24 sorear I've looked at the implementation
05:24 sorear it's... like watching a trainwreck
05:25 JimmyZ I'd very appreciate if you can fix it.
05:25 sorear I can't move.
05:25 sorear Too... enthralling...
05:28 Coke expensive how?
05:28 Coke a lot of that complexity is at build time, not run time.
05:32 Coke if I'm just using ATTRs, does the default destroy cleaning that up from a GC perspective?
05:32 szabgab joined #parrot
05:34 tewk With a gc the problem is usually premature collection due to failing to mark correctly
05:36 Coke tewk: branches/codestring is consuming a ton of memory; I'm assuming I'm not freeing something.
05:37 Coke or perhaps I'm overmarking.
05:38 Coke if I allocate 1000 codestring pmcs, I end up with 2000 more ACTIVE_PMCS.
05:38 Coke (that's if I allocate them in a tight loop and throw them out, and do a collect before I check again.
05:39 Coke ugh, and it get worse and worse if I /use/ the codestrings.
05:39 tewk well a codestring has a linepos and a strings pmc thus 2x
05:40 sorear If your goal here is performance why not start in C
05:40 sorear ?
05:41 Coke ... PMCs are in c.
05:45 tewk Coke: set string native creates a new RSA, just set its size to 0 and then push the string.
05:47 Coke tewk: that was a test - current version just resets it instead. that saves me 2 pmcs that weren't getting freed.
05:47 Coke still leaking 7 PMCs when doing a new Codestring, .emit('foo') $S0 = $P0.
05:48 Coke think I need a custom destroy.
05:48 Coke and I think codestring might have been leaking linepos all this time.
05:48 tewk no, I think you need to define concatenate, I think you are getting the impl from scalar.
05:49 sorear Coke: I was under the impression CodeString was in PIR.
05:50 Coke sorear: no.
05:50 Coke not for some ... what, 2 years now?
05:50 Coke hurm. destroy looks like it's only needed if you're managing your own memory, which I'm not. what the hell is holding onto these PMCS?
05:51 ttbot Parrot trunk/ r46175 i386-freebsd-64int make error http://tt.taptinder.org/file/cmdout/288976.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
05:51 Coke I wish there was a way to say "dump all the PMCs you know about" so I could see what was keeping the reference.
05:52 sorear walking the heap in gdb isn't too hard
05:52 Coke blarghle. my demo wasn't running a gc.
05:52 dalek parrot: r46175 | jimmy++ | trunk/src/pmc/callcontext.pmc:
05:52 dalek parrot: removed outdated comment
05:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46175/
05:52 dalek parrot: r46176 | coke++ | branches/codestring/src/pmc/codestring.pmc:
05:52 dalek parrot: Avoid creating a new pmc that we were just leaking anyway.
05:52 dalek parrot: Reduce, reuse, recycle. (revert)
05:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46176/
05:52 Coke collect != sweep.
05:52 dalek parrot: r46177 | coke++ | branches/codestring/src/pmc/codestring.pmc:
05:52 dalek parrot: don't call SUPER in init/mark - we're not built that way anymore.
05:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46177/
05:53 Coke ok. pmc usage isn't increasing now. buffer usage is, though.
05:56 Coke sorear: src/pmc/codestring.pmc
05:57 alexn_org joined #parrot
06:01 sorear Coke: mm?
06:01 Coke is the pmc definition for CodeString.
06:02 Coke which is transformed to C and then compiled.
06:08 cotto Coke, how does it work that you use STRING *strings; in CodeString's set_string_native without initializing it?
06:09 dalek parrot: r46178 | coke++ | branches/codestring/src/pmc/codestring.pmc:
06:09 dalek parrot: remove unused variable.
06:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46178/
06:09 Coke cotto: there's a GET_ATTR there.
06:09 Coke ah, think I found my leak.
06:10 cotto the leak appears to be in my brain
06:10 cotto too much garbage, not enough collection
06:12 nopaste "coke" at 192.168.1.3 pasted "this look right? Doesn't seem to help, sadly." (23 lines) at http://nopaste.snit.ch/20412
06:25 dalek parrot: r46179 | coke++ | branches/codestring/src/pmc​/resizablestringarray.pmc:
06:25 dalek parrot: When trying to shrink an array, forget about our previous contents.
06:25 dalek parrot: (This doesn't seem to help with the # of ACTIVE_BUFFERS issue, but
06:25 dalek parrot: it does seem correct.)
06:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46179/
06:28 tewk Coke:  I don't think you need to null things out, mark only marks the size slots, it doesn't mark all allocated slots.
06:29 Coke tewk: crud.  you're right.
06:32 Coke reverted.
06:32 Coke tewk++
06:32 tewk wait, I'm not so sure.
06:33 tewk no I'm right, the NULL loop that was already there is needed, your new one isn't
06:34 tewk Time to go to bed.
06:34 Coke amen.
06:40 tewk I think emit should use a local temporary RSA to do the % formating, and them join to a string and push that string on the codestring RSA.
06:40 nopaste "coke" at 192.168.1.3 pasted "this is causing the leak" (4 lines) at http://nopaste.snit.ch/20414
06:41 dalek parrot: r46180 | coke++ | branches/codestring/src/pmc​/resizablestringarray.pmc:
06:41 dalek parrot: fix typo. (no, still doesn't help with burning ACTIVE_BUFFERS when using
06:41 dalek parrot: codestring.emit)
06:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46180/
06:41 dalek parrot: r46181 | coke++ | branches/codestring/src/pmc​/resizablestringarray.pmc:
06:41 dalek parrot: Revert changes to this file;
06:41 dalek parrot: tewk++ points out that FSA's mark() doesn't mark items outside the size of
06:41 dalek parrot: the array anyway, so these should be GC'd.
06:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46181/
06:43 Coke tewk: Why have N RSAs?
06:43 sorear Parrot has an extremely wrong notion of what "Unicode" means.
06:43 Coke tewk: instead of a single oen?
06:43 Coke sorear: you're not helping.
06:44 Coke If you have specific complaints, those are nice to hear and we can fix them.
06:44 Coke If you have rants with no details, those are just frustrating.
06:44 tewk Coke:  if (pos == 0 && percentPos < 0) just push the string, don't do substr.
06:44 tewk thats effectively just a concat, no special formating
06:44 Coke tewk: isn't that just going to end up with /more/ temporary RSAs?
06:45 Coke tewk: how dumb is substr?
06:45 Coke that is a simple enough check, though, sure.
06:46 theory joined #parrot
06:46 sorear They're just confusing terminology.  All of our charsets are Unicode; why is one of them called Unicode?
06:46 Coke tewk: sunova. that also fixes the leak in my simple program.
06:47 Coke sorear: no, all of our charsets are not unicode.
06:47 moritz sorear: the latin1 charset is not Unicode
06:47 moritz sorear: it is *in* Unicode, but it is not the same
06:48 Coke (they is us, btw. =-)
06:49 Coke tewk: looks like anything that's doing a substr is leaking BUFFERs.
06:49 Coke (at least in emit())
06:50 sorear What's the difference between an encoding and a charset?
06:50 moritz charset = character set = character repertoir
06:50 moritz encoding = mapping from bytes into a character repertoir
06:51 sorear Why have charsets that are supersets of each other?
06:51 tewk Coke: your right my tempoarary RSA is a bad idea for our current collector, but with a generation collector it might be better
06:51 moritz sorear: because some applications what small charsets for faster operations
06:51 Coke tewk: why?
06:52 Coke oh. YOUR RSA, not mine. =-)
06:52 sorear Coke: you know about the substr optimization, right?  could be relevant here
06:52 Coke I still think a single join at the end is more efficient.
06:52 Coke I was just about to ping bacek, since he mucked with strings.
06:52 tewk Coke: your probably right.
06:52 sorear moritz: Hah.  I'm amazed you gain more than you lose with the extra layer of indirection and word of data on strings, but I'm not the one with the data
06:53 sorear Coke: Parrot_str_substr doesn't necessarily copy any data; it shares a reference to the old buffer
06:54 sorear if you have a big string and substr out a few small pieces, you'll leak
06:54 sorear is this what you're seeing?
06:55 Coke I thought chromatic & bacek fixed that issue.
06:55 bacek_at_work It will not leak.
06:55 bacek_at_work (And single join is much more efficient)
06:55 sorear (for very conservative definitions of leak)
06:56 sorear the big string will last as long as the pieces
06:56 bacek_at_work yes
06:56 sorear chromatic & bacek created this "issue"
06:56 sorear it's a win in a lot of cases
06:56 bacek_at_work no
06:56 bacek_at_work it's about same as old COW strings
06:56 sorear oh right, COW
06:57 sorear I blissfully forgot about that
06:57 bacek_at_work actually, it's _exactly_ same as COWed strings
06:57 Coke bacek_at_work: if you have any ideas why branches/codestring/src/pmc/codestring.pmc:emit( seems to be leaking BUFFERS, I'd be glad to hear it. =)
06:57 bacek_at_work Coke, any "symptoms"?
06:58 dalek parrot: r46182 | mikehh++ | trunk/MANIFEST:
06:58 dalek parrot: re-generate MANIFEST
06:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46182/
06:58 dalek parrot: r46183 | mikehh++ | trunk/src/pmc (2 files):
06:58 dalek parrot: add svn properties
06:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46183/
06:58 dalek parrot: r46184 | coke++ | branches/codestring/src/pmc/codestring.pmc:
06:58 dalek parrot: Small optimization - if the whole string is %-free, avoid a substr call.
06:58 dalek parrot: tewk++ for pointing this out.
06:58 dalek parrot: tewk++ as this seems to fix the buffer leak in the simple case.
06:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46184/
06:58 dalek parrot: r46185 | mikehh++ | trunk/src/pmc/parrotthread.pmc:
06:58 dalek parrot: fix codetest failure - line length and trailing spaces
06:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46185/
06:58 dalek parrot: r46186 | coke++ | branches/codestring/src/pmc/codestring.pmc:
06:58 dalek parrot: fix comment oddity and bizarre in-situ assignment that must have been a cNpasto
06:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46186/
06:58 dalek parrot: r46187 | mikehh++ | trunk/src/thread.c:
06:58 Coke memory usage compared to trunk is big, per sorear. if I run code to check # of active buffers before and after a few thousand emits, it grows, even though I destroy all the evidence in PIR.
06:58 dalek parrot: fix codetest failure - line length
06:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46187/
06:58 tewk bacek_at_work: does Parrot_str_substr do the right optimization if you ask for a substr that is the whole string?
06:59 bacek_at_work tewk, str_substr just create new string header and reuse old buffer.
06:59 bacek_at_work So, it doesn't really matter how big substring is
07:00 tewk right, but it doesn't need to create a new string header if the substr is the entire string right?
07:00 bacek_at_work no. We always create new string header.
07:00 nopaste "coke" at 192.168.1.3 pasted "sample script" (98 lines) at http://nopaste.snit.ch/20415
07:01 bacek_at_work Coke, try put VTABLE_set_integer_native(INTERP, strings, 0) on line 120
07:01 Coke bacek_at_work: that's wrong.
07:01 purl Coke is channeling thoth!
07:01 Coke (the value of strings needs to persist over multiple calls to emit()"
07:02 Coke if you call .emit("a"), .emit("b"), the output will be "a\nb\n" when you later do a get_string.
07:02 bacek_at_work ah...
07:02 tewk "We always create new string header." is why coke had to do "Small optimization - if the whole string is %-free, avoid a substr call."
07:03 tewk if you detected a substr that was the same as the original string you could save a string header allocation.
07:05 Coke bacek_at_work: so, anyway; remaining cases all suspiciously use Parrot_str_substr, and buffer use grows.
07:06 nopaste "coke" at 192.168.1.3 pasted "output of that script." (20 lines) at http://nopaste.snit.ch/20416
07:06 tewk Coke does rakudo do codstring += string
07:07 Coke i've created 1K codestrings, only gained 4 active PMCs. active buffers goes from 203 to 3151.
07:07 moritz the POST compiler does codestring.emit excessively
07:07 sorear excessivelt?
07:07 Coke you can do emit a lot. it's ok. =-)
07:07 tewk if so you should implement concate in codestring, the one in scalar isn't
07:07 Coke tewk: possibly.
07:08 Coke ... though I doubt it, since the build completed for me.
07:08 Coke (of rakudo using this branch.)
07:08 tewk the one in scalar is inefficient.
07:08 tewk They probably generally use emit for concat.
07:09 Coke concat is just the simple emit() path with this new setup.
07:10 tewk right, but if someone does += instead of .emit they won't get the benefit of codstrings internal RSA
07:10 bacek_at_work Coke, you can use temporal RSA and push single joined string into C<strings>
07:10 Coke bacek_at_work: why does every suggest that? =-)
07:10 tewk temporal RSA doesn't exist.
07:11 Coke then you end up calling join() and creating a lot of temp RSAs.
07:11 tewk Every RSA becomes junk the GC has to collect.
07:11 Coke (which is a more PMCs.)
07:11 Coke and more strings, too.
07:14 tewk Coke: with a very long lived codestring and genrational GC, there might be a small pay off, because in the long run you reduce the total number of objects. and young garbage for a generational collector doesn't have a collection cost.
07:14 Coke part of the goal of this was to call _concat as infrequently as possible. (like, never.)
07:14 tewk but that is really stretching it, and we don't have a generational GC.
07:14 Coke tewk: the objects go away as soon as some calls get_string()
07:14 Coke s/go away/are collectable/
07:15 dalek parrot: r46188 | coke++ | branches/codestring/src/pmc/codestring.pmc:
07:15 dalek parrot: fix the comment
07:15 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46188/
07:15 dalek parrot: r46189 | mikehh++ | trunk/src/thread.c:
07:15 dalek parrot: fix codetest failure - add c function docs
07:15 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46189/
07:15 Coke ok. I'm supposed to be asleep 4 hours ago.
07:15 tewk So your comment " why does every suggest that? =-)" is justified,
07:16 moritz btw it seems that there is a Codestring .= String operation in POST
07:16 mikehh tewk: you might want to check the documentation in r46189 or add to it
07:16 moritz compilers/pct/src/POST/Compiler.pir +289
07:16 tewk I was just suggesting that you implement concat in codestring so that it appends to the RSA instead of using scalars concat which is a real string concat
07:17 sorear rakudo just uses PCTR
07:17 sorear PCT
07:17 sorear it doesn't do += or anything
07:17 tewk <@moritz> btw it seems that there is a Codestring .= String operation in POST
07:18 moritz I have no idea how often it is called, though
07:18 tewk moritz justifies my suggestion.
07:18 tewk good point.
07:18 Coke ok. if someone adds a (failing) test to t/pmc/codestring.t in the branch, that would be awesome.
07:19 Coke (that does a .= String)
07:19 Coke (no need to todo it even.)
07:19 Coke ok. sleep now.
07:19 tewk Coke it wont fail, it will just be less efficient.
07:20 tewk it will force a premature join
07:20 tewk I'm realy going to bed now, nite.
07:21 dalek plparrot: 1ae4402 | dukeleto++ |  (4 files):
07:21 dalek plparrot: Attemp to use Parrot_load_bytecode to load P6object.pbc
07:21 dalek plparrot: Loading PIR which does load_bytecode did not seem to work, so we attempt to
07:21 dalek plparrot: call Parrot_load_bytecode(interp, "P6object.pbc") before we load our PIR
07:21 dalek plparrot: that intercepts file I/O.
07:21 dalek plparrot: This currently coredumps in parrot_split_path_ext, which is called by Parrot_load_bytecode.
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/1​ae4402fbad6a724b3db31fac0287b1e1f76de43
07:21 dalek plparrot: e39408d | dukeleto++ | plparrot.c:
07:21 dalek plparrot: The docs for Parrot_load_bytecode were wrong (the horror!), it takes a Parrot_String
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/e​39408d6cc85179b2ba47884a2826c9710b91a47
07:21 dalek plparrot: 26766ad | dukeleto++ | plparrot.c:
07:21 dalek plparrot: Create a dummy packfile
07:21 dalek plparrot: This brings us back to:
07:21 dalek plparrot: "load_bytecode" couldn't find file 'P6object.pbc'
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/2​6766ad6a1a680b9e841cf8a9eb682939f318f95
07:21 dalek plparrot: 2a0d28c | dukeleto++ | plparrot (3 files):
07:21 dalek plparrot: Go back to load_bytecode in PIR and add an :immediate flag
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/2​a0d28cdbcd1c203dfb9c2324106e2f618a72746
07:21 dalek plparrot: fc4809c | dukeleto++ |  (5 files):
07:21 dalek plparrot: First prototype of a working security system
07:21 dalek plparrot: Finally, a working security subsystem! A few bugs in Parrot had to be worked
07:21 dalek plparrot: around, such as not being able to load_bytecode in PIR which is called from
07:21 dalek plparrot: the embedding interface, so P6object.pbc is loaded from C.
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/f​c4809c79fb2adb3a6ebcaca2114b4fa5271930b
07:21 dalek plparrot: 17e2a82 | dukeleto++ | Makefile:
07:21 dalek plparrot: Remove some junk from Makefile
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/1​7e2a82dca9018297ad3aaf2c84397b3eeffcf43
07:21 dalek plparrot: 54339f4 | dukeleto++ | HISTORY:
07:21 dalek plparrot: Add a trifle to HISTORY
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/5​4339f474d99d8964eae6d4a8548367f5ec332ee
07:21 dalek plparrot: 8b0266b | dukeleto++ | TODO:
07:21 dalek plparrot: Update TODO
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/8​b0266bbfe8ba29ec88aec441a18a5ac1ee5b7a1
07:21 dalek plparrot: 63472ee | dukeleto++ |  (6 files):
07:21 dalek plparrot: Merge branch 'security'
07:21 dalek plparrot: Conflicts:
07:21 dalek plparrot: HISTORY
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/6​3472eef98ab10ba0ee98d7a76ae016518760f5a
07:28 fperrad joined #parrot
07:31 dalek parrot: r46190 | fperrad++ | trunk (2 files):
07:31 dalek parrot: [TAR] add full_path() & rename()
07:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46190/
07:44 * cotto tosses dalek some ketchup
07:47 dalek blizkost: 64df29f | sorear++ | src/pmc/ (8 files):
07:47 dalek blizkost: Reify nexuses as objects outside P5Interpreter
07:47 dalek blizkost: This makes the code a bit more symmetric, makes the signatures a bit neater,
07:47 dalek blizkost: provides a platform to avoid destruction order dependencies, and gives me an
07:47 dalek blizkost: excuse to use the word nexus more.
07:47 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​64df29fdc1c57a6f47e548bfc3e04ca6cd305090
07:47 ttbot Parrot trunk/ r46190 cygwin-thread-multi-64int make error http://tt.taptinder.org/file/cmdout/289272.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
07:48 dalek parrot: r46191 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
07:48 dalek parrot: [distutils] make tarball without copy in filesystem
07:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46191/
07:52 aukjan joined #parrot
07:55 cotto mai plan.  let me show you it
07:55 dalek tracwiki: v1 | cotto++ | UsingGitAndSvnInTrac
07:55 dalek tracwiki: http://trac.parrot.org/parrot/wiki/UsingG​itAndSvnInTrac?version=1&amp;action=diff
07:55 dalek tracwiki: v2 | cotto++ | UsingGitAndSvnInTrac
07:55 dalek tracwiki: fix wiki formattening
07:55 dalek tracwiki: http://trac.parrot.org/parrot/wiki/UsingG​itAndSvnInTrac?version=2&amp;action=diff
07:55 dalek tracwiki: v3 | cotto++ | UsingGitAndSvnInTrac
07:55 dalek tracwiki: http://trac.parrot.org/parrot/wiki/UsingG​itAndSvnInTrac?version=3&amp;action=diff
07:55 cotto . o O (Couldn't have timed that better.)
07:58 dalek blizkost: cca07ac | sorear++ | src/pmc/ (4 files):
07:58 dalek blizkost: Sever nexuses at the start of global destruction
07:58 dalek blizkost: The testsuite no longer segfaults, although it does leak memory (4 words per
07:58 dalek blizkost: interpreter created).
07:58 dalek blizkost: review: http://github.com/jnthn/blizkost/commit/​cca07ac031eb84be549209970e80c98103846050
07:59 cotto definitely time for sleep
07:59 cotto night, humans
08:36 aukjan joined #parrot
08:38 dalek parrot: r46192 | jimmy++ | trunk/src (72 files):
08:38 dalek parrot: manual optimization for old compiler
08:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46192/
08:53 allison joined #parrot
08:54 dalek parrot: r46193 | jimmy++ | trunk/src (19 files):
08:54 dalek parrot: manual optimization for old compilers
08:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46193/
08:57 ttbot Parrot trunk/ r46193 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/289409.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
09:13 Infinoid wow, dalek is getting a workout these days
09:43 dalek parrot: r46194 | jimmy++ | trunk/src/sub.c:
09:43 dalek parrot: localize vars
09:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46194/
09:51 iblechbot joined #parrot
10:07 aukjan joined #parrot
10:22 riffraff joined #parrot
10:43 aukjan joined #parrot
10:46 Andy joined #parrot
10:48 dalek parrot: r46195 | NotFound++ | trunk/src/pmc/parrotthread.pmc:
10:48 dalek parrot: set_integer_native is void
10:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46195/
11:09 NotFound The Parrot_pmc_free_temporary in hashiterator.pmc shift_string looks suspicious.
11:10 NotFound Is a good candidate for the random segfaults.
11:49 JimmyZ joined #parrot
12:26 ruoso joined #parrot
12:29 whiteknight joined #parrot
12:31 dalek nqp-rx: 8712c4a | moritz++ | src/Regex/Cursor.pir:
12:31 dalek nqp-rx: create new match objects and arrays in separate methods that can easily be overridden from HLLs
12:31 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/8​712c4a0f706b3eaf031467e94e1b9e0fe997b1c
12:31 dalek nqp-rx: 5c23708 | moritz++ | src/Regex/Cursor.pir:
12:31 dalek nqp-rx: Merge remote branch 'origin/mob2'
12:31 dalek nqp-rx: This adds overridable new_match and new_array methods to Regex::Cursor, which
12:31 dalek nqp-rx: simplify generation of HLL-specific match objects. There's a proof-of concept
12:31 dalek nqp-rx: Rakudo branch 'mob3' which uses this new facility.
12:31 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/5​c2370818c100bf49a5ba05e5b3590bcf0e30d68
12:37 dalek nqp-rx: 3f00ce8 | moritz++ |  (5 files):
12:37 dalek nqp-rx: update stage0 files
12:37 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/3​f00ce88490997dfacdd6a5d1a92305fcc33fe57
12:38 bluescreen joined #parrot
12:45 khairul joined #parrot
12:48 khairul left #parrot
12:48 khairul joined #parrot
12:59 dalek parrot: r46196 | moritz++ | trunk/ext/nqp-rx/src/stage0 (4 files):
12:59 dalek parrot: [nqp] update to get latest match object creation hooks
12:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46196/
12:59 dalek parrot: r46197 | NotFound++ | trunk/src/pmc/fixedintegerarray.pmc:
12:59 dalek parrot: avoid a temporary PMC in FPA set_string_keyed_int
12:59 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46197/
13:03 mikehh joined #parrot
13:03 rurban_ joined #parrot
13:08 JimmyZ joined #parrot
13:13 Coke mentor jimmy?
13:14 Coke rurban: hey, reini.
13:25 particle coke: what's this business with "the parrot room"?
13:27 mikehh tewk: ping
13:30 bkuhn joined #parrot
13:31 JimmyZ Coke: what?
13:33 mikehh getting a bunch of packfile test failures
13:34 atrodo joined #parrot
13:39 Coke JimmyZ: did you see chromatic's question about your --i vs. i-- patch?
13:39 Coke you may be optimizing for compilers that we're not supporting.
13:41 Coke particle: http://yapc2010.com/yn2010/event/674, http://yapc2010.com/yn2010/event/673, and http://yapc2010.com/yn2010/event/671
13:41 Coke I understand that's your doing.
13:42 Coke er, and http://yapc2010.com/yn2010/event/675 and http://yapc2010.com/yn2010/event/676
13:42 particle aye, i suppose it is
13:43 Coke SO, that's, what, 40 HOURS of ``content'' ?
13:43 Coke I look forward to your gymnastic routine. =-)
13:43 particle i never got confirmation from patrick that it was workable, so my tentative 'yes' became definite without further input
13:43 Coke I think if it's just "a room for us to hack in and answer questions", that's fine; having it on the schedule with the talks is probably wrong.
13:44 particle it will be a room to hack in and answer questions, most of the time, i imagine
13:45 particle either during BoF hours, tutorial days, or some conference sessions, there may be tutorial-style content.
13:45 particle it'd be nice to have a little something each day
13:46 particle msg pmichaud ping me when available for yapc-perl6workshop discussion
13:46 purl Message for pmichaud stored.
13:46 Coke if you're imagining something that needs manpower, we need to make sure there's staffing, etc.
13:46 particle i guess i'd better book flight/hotel... i'm in denver now, nyc later, urbana/champaign end of may
13:47 Coke I imagine there are going to be times when no one is in the room because, e.g., chromatic is giving a talk and we're all fanboys.
13:47 particle coke: aye, there are many details to work out, booking the room was most important
13:47 Coke wish I could take the train. *sigh*
13:47 particle why not?
13:48 dalek parrot: r46198 | NotFound++ | trunk/src/pmc/codestring.pmc:
13:48 dalek parrot: avoid pmc_new_temporary in codestring emit method, maybe slower but less crashy. Also use fixed instead of resizable string array
13:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46198/
13:48 Coke particle: might want to throw out a little note on the -dev list; swill help stop people saying "HUUUUUWAH?" and get them thinking of what can or should be done. (I for one am just looking forward to having a few days to hack.)
13:48 Coke (hell, none of us may be there thur or fri.)
13:49 particle right... damian teaching perl 6 is compelling, but i expect the workshop room to be pretty empty then :)
13:50 JimmyZ Coke: Does that patch was wrong?
13:50 Coke JimmyZ: I don't see that it does anything.
13:51 JimmyZ Coke: Do we support VC 6 ++ ?
13:51 Coke which was chromatic's question too, I think - specifically, what are you optimizing there, and who is benefitting?
13:51 Coke particle, answer the man's question.
13:51 Coke =-)
13:51 NotFound If is just the changes from postifx to infix increment, I don't think is bad. It doesn't hurt anyone and can be faster in some compilers.
13:52 NotFound s/infix/prefix
13:53 Coke NotFound: maintenance cost to eke out a fractional speedup on 10 year old compilers is probably not a win.
13:53 particle msvc 6 is still widely used for folks cross-compiling on windows
13:53 NotFound Coke: What's the maintenance cost of having ++i instead of i++?
13:53 Coke purl, 2010 - 1998?
13:53 particle we're just on the cusp of cross-compiling parrot
13:53 purl coke: no idea
13:53 Coke 2010 - 1998
13:53 purl 12
13:53 JimmyZ msvc 6  doesn't suprrot postfix optimization
13:54 Coke NotFound: because every time I look at that, I have to say "why is that prefix?"; I am extrapolating that it will have the same effect on others. =-)
13:54 JimmyZ Coke: since parrot was targeting C89
13:55 Coke I'm /win 2
13:55 JimmyZ Coke: I think it is necessary for old compilers, and I don't think it hurt any morden compilers
13:55 Coke hey, win 2, there you are. =-)
13:56 Coke /necessary/ ?
13:56 Coke i++ doesn't work in msvc 6?
13:56 NotFound Coke: well, people used to c++ like me usually think "why is that postfix"? ;)
13:56 darbelo 'cause ++c sucks as a name?
13:56 Coke NotFound: fair enough.
13:57 Coke darbelo: [incr tcl] disagrees with you
13:57 NotFound Overloaded postfix can't be optimized to the prefix variant unless your compiler is very very smart.
13:58 NotFound So yoy use the prefix by default and tends to do right thing.
13:58 Coke even if your c++ compiler is compiling C? =-)
13:59 NotFound Coke: when is compiling C, can't be overlodaded ;)
13:59 dukeleto 'ello
14:00 Coke eh. ok. I rank this about with some of the overzealous testing we're doing. I won't commit cycles, but knock yourself out. =-)
14:00 particle wait... overloaded postfix... in C?
14:00 particle C89 is not C99
14:01 particle postfix optimization is for OBJECTS in C++, because postfix ++ needs to copy the object
14:01 particle prefix ++ doesn't
14:01 NotFound particle: no, in C++, but is the reason to get used to use prefix by default.
14:02 particle but parrot is written in C, not C++
14:02 Coke particle: yes, but we have C++ people who work on prrot.
14:03 JimmyZ I can revert it if someone doesn't like it. but I  think it's an optimization for some compilers and for Embedding
14:03 Coke JimmyZ: I imagine chromatic would actually like some documentation that it's an optimization.
14:03 NotFound particle: yes, but if we talk about what looks strange, the strangeness is in the eye of the beholder.
14:03 Coke parrot has a long history of prematurely optimizing things that turned out not to help so much.
14:04 particle benchmarking on a specific compiler, with results in the commit message or a related ticket, is the proper way to put that patch in
14:05 particle saying "this big ugly patch is possibly faster on a compiler somewhere" is too vague for a syntax like that to take root
14:05 JimmyZ So do I revert it or keep it?
14:06 particle benchmark it before and after patch, post results to parrot-dev, and let the hoardes decide
14:06 zostay joined #parrot
14:06 particle i don't mind changing the mindset of developers to prefer prefix increment over postfix, if it makes sense
14:07 Coke or we could just let it go, as it can't hurt. =-)
14:07 NotFound Talking about premature optimization, someone took a look at r46198
14:07 particle but it will get reverted over time
14:07 NotFound ?
14:07 Coke NotFound: check out branches/codestring
14:07 Coke which does that slightly differently.
14:08 NotFound Coke: but we have random crasehs in trunk right now.
14:08 Coke those random crashes predate codestring.
14:08 Coke er, chromatic's codestring.
14:09 NotFound Coke: some of them might have been fixed by r46197
14:10 Coke in any case, more eyes on codestring branch appreciated. =-)
14:12 NotFound I think pmc_new_temporary need lots of test... or alternatively, kill it.
14:16 NotFound Anyway, after those last fixes I'm no longer having crasehs on x86-64
14:18 NotFound Checking out branch
14:23 lucian joined #parrot
14:25 hercynium joined #parrot
14:27 NotFound Coke: no random crashes for a now with the codestring branch, amd64 both with and without --optimize
14:28 Coke danke.
14:28 Coke any idea why it seems to be using more memory? =-)
14:29 bubaflub joined #parrot
14:30 particle JimmyZ: can you do the benchmarking?
14:31 JimmyZ particle: I don't have old compilers
14:34 JimmyZ particle: but from me, it's 0.01% faster, though it's not exact
14:34 JimmyZ particle: I guess I got wrong benchmarking
14:34 jan joined #parrot
14:37 * JimmyZ is confused, why it get controversy
14:38 Coke I think if you sold it as a "code cleanup" instead of an "optimization", you'd have gotten little (or less) feedback.
14:38 darbelo Big patches with 'optimization' on the commit message get a lot of attention.
14:38 JimmyZ then sorry for the wrong message ;)
14:39 darbelo Big patches with 'code cleanup' on the commit message get very little attention.
14:40 darbelo You're also a new committer, so people pay more attention to your contributions.
14:40 NotFound JimmyZ: chromatic is highly sensitive to the word 'optimization' ;)
14:41 Coke see my previous send about historical ``optimizations''
14:41 * JimmyZ is feeling he was doing the wrong things.
14:42 NotFound JimmyZ: don't worry too much about that.
14:42 darbelo Not really, it's just a matter of timing. My first patch removing a few hundred lines of code got a lot of attention, now I can rip out whole subsystems without people thinking twice about it.
14:43 darbelo They've gotten used to me.
14:44 particle actually, the patch isn't that big, now that i look at it again
14:44 particle it's a micro-optimization, and perhaps premature, but it's harmless.
14:45 NotFound Coke: no idea about the memory usage. I suppose that codestring keeps refered somewhere long after used.
14:45 NotFound Looks big, but the changes are pretty little.
14:45 Coke NotFound: yup, see nothing obvious that would get kept.
14:46 particle is there some way for me to see a diff of trunk and branches/codestring online?
14:46 particle i have a little time to look for scoping problems or other memory-related changes
14:47 particle perhaps i should update my local svn repo for the first time in months
14:47 darbelo particle: remember to realclean before updating. There's been a lot of Makfile hackery going on.
14:48 particle thanks
14:49 Coke particle: http://trac.parrot.org/parr​ot/log/branches/codestring - click on "view changes"
14:49 Coke it's not vs. trunk, but vs. the branch point. close enough.
14:49 Coke (but branch point was just after chromatic's change to CS)
14:49 particle ah, yes, trac.parrot, not svn.parrot... thanks
14:49 particle and that's where you see the memory changes, vs the branch point?
14:52 JimmyZ joined #parrot
14:54 ash_ joined #parrot
14:55 JimmyZ good night,all
14:55 Coke night
14:55 Coke particle: sorear reports that it tear through memory much faster building rakudo.
14:56 Coke I can verify that Codestring's '
14:56 particle hrmm, well, i can try that and see
14:56 Coke emit seems to be generating BUFFERS that are not let go.
14:57 Coke see my nopastes from about 8 hours ago for sample code.
14:59 particle ok, bbi5m after i dial into a concall
15:45 NotFound Coke: I've found where the CodeString gets marked: in the context
15:45 NotFound Just insert a call to any function before sweep, and buufers gets cleaned.
15:46 NotFound In the CallContext PMC
15:48 theory joined #parrot
15:50 NotFound So looks like the poblem in other cases must also be that the CodeString keeps refered long before after his usage.
15:50 NotFound s/before/after
15:57 Coke NotFound: good find. can we fix this from inside codestring?
15:58 Coke `/win 2
15:58 NotFound Coke: I don't think so, looks like a hole in PCC
15:58 moritz please remember to ticket it
15:58 NotFound A workaround for codestring can be to provide a method to release his content.
15:59 Coke NotFound:  but then someone outside of CS would have to invoke it, yes?
15:59 NotFound Coke: yeah
15:59 Coke so, meh.
16:00 Coke NotFound++ for finding the leak
16:00 NotFound You can test it just by adding other call to sweep and parrot_debug at the end of your example.
16:01 Coke ... that is f'd up.
16:01 Coke (verified, all the buffers go away then.)
16:02 NotFound I think the current object is set for the method call and doesn't get cleaned until other method or sub call is done.
16:03 Coke seems like we could clear it as soon as we checked the results.
16:03 Coke (near get_results)
16:04 NotFound Mm... but get_results is omitted if no return is expected, isn't it?
16:05 NotFound BTW I found it just by inserting abort(); in CodeString mark
16:06 Coke ... which shows you when it got freed?
16:06 Coke ``freed''
16:06 NotFound The backtrace shows the call chain.
16:06 Coke neat trick.
16:06 * purl pulls a rabbi out of her ass.
16:06 Coke shalom, purl.
16:06 purl shalom is probably at http://www.neurotrash.com/original/​filmplay.asp?MediaFile=shalom2.rm&a​mp;Channel=Original&amp;Item_ID=101
16:06 NotFound Shows where a poiter to is retained.
16:07 Coke I imagine this will be a huge fix. you should totally beat chromatic to it. =-)
16:09 cotto forget shalom
16:09 purl cotto: I forgot shalom
16:12 brrant joined #parrot
16:13 cotto Coke, is parrot.org running apache?
16:15 Coke cotto: I believe so, eys.
16:24 Coke seen chromatic?
16:24 purl chromatic was last seen on #parrot 2 days, 12 hours, 54 minutes and 40 seconds ago, saying: I fixed that in Rakudo's immutable_strings branch.  [Apr 28 03:29:31 2010]
16:38 NotFound Uh... I was wrong, in the example parrot_debug isn't a sub, is a macro.
16:40 Coke still, if you do sweep 1 (.parrot_debug) sweep 1 (.parrot_debug), the last debug shows the BUFFERS were collected
16:42 Coke NotFound: hey, you wanna see segfault? =-)
16:45 NotFound I already see a lot X-)
16:46 Coke http://trac.parrot.org/parrot/ticket/1602
16:49 Coke so I can't check to see if the CURRENT_OBJECT is the issue or not. =-)
16:51 Coke the same problem is occuring in trunk, btw.
16:52 dalek TT #1602 created by coke++: .INTERPINFO_CURRENT_OBJECT causes segfault:
16:52 dalek TT #1602: http://trac.parrot.org/parrot/ticket/1602
16:55 NotFound Coke: nice catch
17:00 ruoso joined #parrot
17:01 Coke NotFound: opened 1603 to track the ACTIVE_BUFFERS issue; feel free to add your notes.
17:04 ash_ joined #parrot
17:09 ruoso joined #parrot
17:13 davidfetter joined #parrot
17:14 NotFound Setting object and signature to null in current context during get_results seems to avoid the CodeString get marked, but the buffers keep active.
17:15 NotFound Ah, no, I was misreading.
17:17 NotFound Looks like the context signature is the problem. Somewhere the current_object is copied to it.
17:18 NotFound I mean, the context.... the callee context, maybe.
17:24 confound_ joined #parrot
17:24 particle joined #parrot
17:25 NotFound can't find HEADERIZER HFILE directive in "src/pmc/threadinterpreter.pmc"
17:38 dalek parrot: r46199 | NotFound++ | trunk (2 files):
17:38 dalek parrot: Don't return NULL in interpinfo_p, TT #1602, Coke++
17:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46199/
17:41 cotto_work good morning
17:41 purl For you maybe.
17:41 dalek TT #1602 closed by NotFound++: .INTERPINFO_CURRENT_OBJECT causes segfault:
17:41 dalek TT #1602: http://trac.parrot.org/parrot/ticket/1602
17:43 NotFound I see now. The context signature is used to pass the results. But I don't know why the current object is stored in it.
17:44 * NotFound looking pdd03
17:45 joeri joined #parrot
17:47 Coke NotFound: I don't think it's the current object - the PMCs are around, the strings area.
17:47 Coke er, BUFFERs.
17:47 Coke could it be that the containers are getting recycled, but it's child strings are not, until the second sweep?
17:47 NotFound Coke: it was the current object during the method call.
17:48 Coke NotFound: I'm just looking at my interpinfo output - the PMC's aren't stacking up.
17:49 NotFound Coke: is hidden in the signature object of the current context, until some call overwrites it.
17:49 Coke freaky.
17:50 NotFound Now looking if the fix breaks some unrelated part.
18:09 dukeleto 'ello
18:13 Coke NotFound: you got it?
18:14 bubaflub afternoon dukeleto
18:15 Coke cotto: enjoy the present in your email.
18:15 NotFound Coke: I think I have a fix right now for the problem a hand, but persists the problem of leaving arguments of last call in the context, and some tests seem to depend on that feature. That may need further discussion.
18:16 nopaste "NotFound" at 192.168.1.3 pasted "Fix for TT #1603" (14 lines) at http://nopaste.snit.ch/20417
18:17 NotFound Coke: here is.
18:20 cotto_work woohoo
18:20 NotFound I still don't understand well enough PCC details, allison must take some look.
18:20 Coke NotFound: no effect on the sample code.
18:21 NotFound Coke: Uh? For me ACTIVE_BUFFERS: 218
18:21 Coke hurm. did my rebuild not take?
18:21 Coke double checking.
18:22 Coke ACTIVE_BUFFERS.............: 4151
18:22 Coke (it's the second print of ACTIVE_BUFFERS that's the bad one.)
18:22 kjeldahl joined #parrot
18:22 NotFound Let me rebuild, maybe there is some remaining of the previous attempts.
18:29 NotFound Stupid of me... was using a modified version of the example with two sweeps.
18:30 NotFound Let me found again what was the appropiate change.
18:38 Coke going to yapc?
18:38 purl See : going to yapc::na or yapc::whatever or cwest, uri, DrForr, dha, ology
18:38 Coke going to yapc::na?
18:38 purl See "going to YAPC::NA $year"
18:38 Coke going to yapc::na 12010?
18:38 Coke going to yapc::na 2010?
18:38 purl going to yapc::na 2010 is jhannah, rbuels, cfedde or apeiron or dha or nacmac or dhoss or mst or chargrill or me or kyriel or a. or triddle or DrForr
18:38 Coke going to yapc::na 2010 is also coke or packy
18:38 purl okay, Coke.
18:38 rbuels purl: going to yapc::na 2010 is also dukeleto
18:38 purl okay, rbuels.
19:00 Coke going to yapc::na 2010 is also kolibrie
19:00 purl okay, Coke.
19:07 NotFound Even if I manage to avoid the codestring being marked, the buffers are not freed until the second sweep.
19:08 Coke I wonder if the container is getting zorched, but its elements are not.
19:08 NotFound And part of the problem is the emit method returning SELF, so it goes into the positional returns.
19:08 Coke is our gc too lazy?
19:08 Coke NotFound: I'm not sure that behavior is actually required anywhere.
19:09 Coke going to yapc::na 2010 is also colomon
19:09 purl okay, Coke.
19:09 NotFound I think this problem wants an architect's eye.
19:10 NotFound The args and the return must be freed at some point, but I don't know what point.
19:12 NotFound And the second sweep frees them even without any fix, so they get freed at some other point %-)
19:13 Coke msg allison & chromatic - if you could check out TT #1603, that'd be spiffy.
19:13 purl Message for allison stored.
19:13 Coke msg chromatic & allison - if you could check out TT #1603, that'd be spiffy.
19:13 purl Message for chromatic stored.
19:18 allison Coke: ok
19:18 Coke allison: sneaky!
19:19 Coke trying to speed up codestring in a branch, but even in trunk, it seems to be hanging on to things longer than needed.
19:21 NotFound I've added some comments right now.
19:21 allison my first guess is that it's not sweeping because it doesn't need to reclaim that memory yet for something else, but it could be more wrong than that
19:22 NotFound The interesting part is that the codestring is marked in the first sweep, but not in the second.
19:24 Coke er, 2nd and 3rd?
19:24 Coke (the first one was a baseline.)
19:24 NotFound Ah, yes.
19:28 Coke allison: (not sweeping) - but we're forcing the sweep in the example.
19:35 allison Coke: aye, I'm not sure which gc core it's using, but one optimization technique for gc is to skip even "requested" sweeps
19:35 allison Coke: seems unlikely here, since the 3rd is catching i
19:36 Coke allison: that doesn't seem very optimal. =-)
19:37 allison Coke: it is if sweeping is expensive :)
19:40 NotFound Looks to me that on the contrary, usually parrot is doing too much sweeps.
19:41 allison NotFound: aye, highly likely
19:42 allison NotFound: I wish we had a better way of tracing exactly what's happening here
19:42 cotto_work Tell khairul to get to work. ;)
19:43 cotto_work It might be helpful to put up a wishlist on the wiki.
19:44 NotFound allison: in my test I found that a pointer or several to the codestring are kept in the context, inside the signatures. There is also a positional return, becaause the 'emit' method return self.
19:44 NotFound And I fail to locate a point where safely clear the positional returns.
19:46 allison NotFound: returns only exist during the life of the call
19:47 allison NotFound: that is, they live in the call context, so as soon as that's gone, they disappear
19:47 allison NotFound: but they won't be swept while the call context is still active
19:48 NotFound allison: not if a pointer to the callee context is retained somewhere on the caller.
19:48 allison NotFound: aye
19:48 allison NotFound: so, try this...
19:49 allison NotFound: put a call to some other subroutine before that 2nd sweep
19:49 NotFound allison: that was the first thing I do.
19:49 allison NotFound: the call context is stored in the caller
19:49 allison NotFound: and?
19:50 NotFound The buffers were disposed. But let me try again, I've do a lot of experiments and maybe I'm confusing myself.
19:50 hicx174 joined #parrot
19:54 NotFound No, the buffers aren't disposed, but the codestring mark vtable is not hit.
20:07 NotFound Without that call, the vtable mark is hit on mark_positionals(INTERP, SELF); at CallContext mark.
20:08 NotFound Which itself gets called as current_sig on the interpreter current context.
20:14 jsut_ joined #parrot
20:16 dalek rakudo: d12eed6 | moritz++ | t/spectest.data:
20:16 dalek rakudo: run S06-operator-overloading/sub.t
20:16 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​12eed658115b0f2c289b5f0ce8844ef9e7eaefd
20:22 dalek parrot: r46200 | fperrad++ | trunk (4 files):
20:22 dalek parrot: [osutils] add catfile() & splitpath()
20:22 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46200/
20:33 eternaleye joined #parrot
20:38 Coke allison: when you do a sweep, is there a guarantee that all the memory that can be freed will be, or is the promise merely "ok, I'll see what I can do."
20:38 Coke s/freed/put in the free pool/
20:54 eternaleye joined #parrot
20:55 dalek parrot: r46201 | fperrad++ | trunk (5 files):
20:55 dalek parrot: rename Archive/TAR to Archive/Tar
20:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46201/
21:01 eternaleye_ joined #parrot
21:03 rurban_ joined #parrot
21:15 sorear Coke: Where is this "feedback"?  Is there a secret parrot-commits-replies@ list that's not mentioned on mailman?
21:16 moritz huh? people usually reply to commit messages on parrot-dev
21:21 sorear huh.  I missed it.
21:22 moritz because it's secret :-)
21:25 fperrad joined #parrot
21:43 dalek tracwiki: v4 | cotto++ | UsingGitAndSvnInTrac
21:43 dalek tracwiki: expand and organize
21:43 dalek tracwiki: http://trac.parrot.org/parrot/wiki/UsingG​itAndSvnInTrac?version=4&amp;action=diff
21:44 cotto_work I'd appreciate feedback on that plan (as much as is planned, at least).
21:48 bacek ~~
21:48 bacek cotto, good plan
21:51 sorear as an outsider, nothing leaps out at me as revoltig
21:53 cotto_work high praise
22:04 cotto_work allison: ping
22:04 donaldh joined #parrot
22:04 allison Coke: no guarantees in a sweep, the only guarantee is to make memory available when it's needed. The GC can play fast and loose otherwise.
22:05 allison Coke: that is, garbage will be cleaned up eventually, but if the space isn't needed, it might not be cleaned up until program termination
22:05 allison cotto: pong
22:07 cotto_work allison: if I can make Trac work with git while still preserving svn access, what are your thoughts on moving forward with the transition to git?
22:07 allison I question it!
22:07 donaldh irc://irc.freenode.net/#perl6
22:07 allison I still hate it, and every time someone tries to demo how great git is, it breaks.
22:08 donaldh sorry
22:08 allison It ain't robust, stable, reliable, easy for newbies...
22:09 allison I'm really, really, trying to be open minded about it, and give the devs who like git space to work in their own flow.
22:09 sorear allison: btw I managed to fix the destruction segfaults in blizkost
22:09 allison But, moving the whole project to it is... big
22:09 cotto_work I feel the same way about svn right now.
22:10 allison and, as far as I can tell, the move is entirely unnecessary
22:10 allison so, work in git
22:10 allison just use svn as the store
22:10 cotto_work you mean git-svn?
22:11 allison git-svn gives you a connection point, but from there you can just use the standard git workflow
22:11 allison I'm totally fine with people using git branches instead of svn branches
22:12 allison (instead of trying to manage svn branches through git, which is nutty)
22:12 cotto_work and applying them as a single big diff?
22:13 sorear every branch merge in svn is a single big diff
22:13 allison sure, why not
22:13 sorear svn merge is just a thin layer over "svn diff" and "patch"
22:13 sorear with a smidge of logic to stop you from applying the same rev's diff twice
22:13 allison if we ever rolled it back, we'd want to roll it back as a unit
22:13 allison sorear: yup, that's one of the things I like about svn
22:14 allison it's clean
22:15 * allison hears minds reeling in the background
22:15 cotto_work yes, you do
22:15 Coke ... clean is not a word I would use to describe svn's branching and merging. =-)
22:16 Coke allison: have you seen github's "use this git repo via svn" interface?
22:16 Coke it's like svn-git.
22:17 Coke (as opposed to git-svn)
22:20 bacek (merging with git) You can rollout git merge as single unit. Just always merge with --no-ff.
22:20 chromatic joined #parrot
22:21 cotto_work just in time
22:21 chromatic -1 to svn, solely for its difficulty of branching and merging
22:21 allison cotto: I'm not quite clear on why the devs who like git are still bothering with svn branches
22:21 allison cotto: can you explain?
22:22 allison or chromatic or Coke
22:22 bacek because it's only one official way to share work
22:22 cotto_work yeah
22:22 allison no, we changed that
22:22 allison we officially blessed git branches
22:22 cotto_work de jure, yes.  De facto, meh
22:23 allison cotto: explain?
22:23 allison as in, why isn't it being used?
22:23 allison (this is important, as git branches were the "toe in the water" for testing git)
22:23 Coke allison - I'm using svn branches because I wish to share my work with others.
22:24 Coke allison: ... what?
22:24 purl Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
22:24 chromatic Out of repository is out of mind.
22:24 cotto_work It might just be a bootstrapping issue (nobody's using them because nobody's using them), but ... what he said.
22:24 allison but, that's how git branches work
22:24 chromatic No it isn't.
22:24 purl oh yes it is!
22:24 allison everybody has their own, and share patches back and forth
22:24 Coke I love you, purl.
22:24 purl Coke: what?
22:24 allison that's what it was designed for
22:24 bacek no
22:24 bacek it is not
22:25 chromatic A profile of building Rakudo's core.pm with trunk http://wgz.org/chromatic/t​mp/rakudo_gen_core.cg.bz2
22:25 allison "Distributed Version Control"
22:25 allison distributed
22:25 purl distributed is definitely the way to go, it's what sets IRC apart from other chat things
22:25 Coke so, chromatic, you clobbered my working changes with your codestring updates. I like mine better. Any feedback?
22:25 bacek not "Local Patches Sharing Thingy"
22:25 Coke no, purl, distributed is <reply>
22:25 purl okay, Coke.
22:26 chromatic Coke, you're trading long-lived GCables for avoiding short-lived string header and buffer allocations.
22:26 sorear chromatic: 403
22:27 bacek Coke, I told ya! Use RSA local to CodeString.emit!
22:27 chromatic All of our processes and procedures and habits (smolder, sharing code, collaborating) rely on a centralized repository.
22:27 chromatic Take away the centralized repository without changing all of those dependents and they break.
22:27 chromatic perms fixed on the file, by the way
22:29 allison chromatic: I agree on smolder
22:29 allison chromatic: sharing code and collaborating can go either way
22:29 chromatic Certainly they can change, but I'm only describing how things work now.
22:29 allison at the moment, I certainly find it easier to pull a clean diff of a branch in svn than git
22:29 allison for code review
22:30 chromatic That's because you don't know how to use git.
22:30 bacek git checkout <branch>; git diff master
22:30 allison no, I got a git expert to pull it for me, remember?
22:30 allison and got some 12k lines of diff
22:30 chromatic I'm not a git expert by any means.  I learned how to use it is all.
22:30 davidfetter joined #parrot
22:31 allison if I saw a compelling advantage to git, I'd be there in a heartbeat
22:31 chromatic Branches and merges work.
22:31 allison but at the moment, it looks to me like some strange cult drinking the same cool aid and not making any sense to the rest of the world
22:32 allison (sorry, just trying to find an apt metaphor)
22:32 chromatic Is there anyone in this channel who's done both successfully in both SVN and Git who thinks that SVN is anything other than painful?
22:32 allison I get that a handful of people love git
22:32 allison I understand, I accept
22:32 allison well
22:32 allison I don't understand *why*
22:33 allison but I understand that it is important to them
22:33 allison you
22:33 sorear probably these people don't have commit bits
22:33 allison whatever
22:33 purl whatever is easiest to type
22:33 bacek Because git is fast. And it just work
22:33 allison git is slow
22:33 allison I mean, it's doing a lot more work with a git pull than an svn update is doing
22:34 allison so, it's not a fair comparison
22:34 chromatic I don't even know how to respond to that.
22:35 allison I'm just saying that it's fair that it's slower
22:35 allison not a dis
22:35 chromatic Not true, either.
22:36 chromatic But even if it were true, it's irrelevant to my point, and likely irrelevent to bacek's point.
22:36 chromatic Right now, if you want to merge SVN branches in Parrot with SVN, you have to resolve merge conflicts of SVN metadata in unrelated files for reasons no one has been able to discern.
22:36 allison well, he offered speed as an advantage
22:36 chromatic Speed *is* an advantage.
22:37 allison not really
22:37 chromatic You don't know how to use Git.  How can you say this?
22:37 allison I don't understand why people are having so much trouble with svn branches
22:37 allison mine always merge cleanly
22:37 chromatic None of the rest of us can get them to merge cleanly.
22:37 allison maybe I have some deep mystical svn foo, but somehow I doubt it
22:38 allison it's just too dead simple
22:38 bacek Just because sometime you have to recreate new branch.
22:38 chromatic Maybe because none of the rest of us squash our branches into patches, create empty new branches from trunk, then apply and massage the patches manually.
22:38 cotto_work I'm happy that they work for you, but I've been doing absolutely nothing special and had no end of trouble witht them.
22:39 allison chromatic: the only time I've had to do that was recovering someone else's mangled branch
22:39 chromatic I thought you recommended that approach in general.
22:39 allison will you at least look at Mercurial or Bazaar?
22:39 allison they're so much nicer than git
22:39 chromatic I've used hg.
22:40 chromatic Meh.
22:40 allison elaborate?
22:40 chromatic It's slower than git, and it didn't do anything substantially better than git for me to want to switch to it.
22:40 allison what I'd really like, is to move to bazaar running on parrot
22:41 allison really, really
22:41 bacek what for???
22:41 purl for fun.
22:42 allison eat our own dogfood
22:42 allison have a real practical project on parrot, that we're motivated to support
22:42 bacek It's not _our_ dogfood.
22:42 allison it would be if it was running on parrot
22:42 bacek Oookey.
22:43 bacek Let's port Ruby and migrate to redmine.
22:43 chromatic If we ported Bourne shell, we could migrate to tla.
22:43 bacek Then we will have " real practical project on parrot, that we're motivated to support"
22:43 cotto_work I see charm in dogfooding but that sounds a lot like making a technical decision for a non-technical reason.
22:43 chromatic Does Trac have bzr plugins, out of curiosity?
22:44 cotto_work I think I saw some.
22:44 allison that's not the reason for the decision, it just a by-the-way
22:44 bacek it should have
22:44 cotto_work I didn't bother testing them.
22:44 chromatic Any chance the bzr plugins have the support or maturity of the git plugins?
22:44 cotto_work possibly.  The git plugin is labeled as alpha.
22:46 chromatic If migrating to a different repo means migrating Trac to something else, I'd vote for sticking with SVN and telling anyone interested in working on a branch to use git-svn instead.
22:46 allison the main reason for the decision is it's just too early
22:46 allison git may be great in a year or two
22:46 allison (it has potential)
22:46 bacek Look at those numbers closely: Bazaar is taking around a second to make a commit on a tree with 38k files and just over 3 seconds to log a branch with 20k revisions! Git is faster but Bazaar is clearly fast enough for 99.9% of users. If Bazaar 2.x is genuinely too slow for you on your project, please tell us where and we’ll do what we can to fix the problem for you.
22:46 bacek Ultimately, raw speed matters but the real challenge is overall user productivity. As more and more users begin using GUI applications instead of the command line tools, the time required to achieve tasks will be more dependent on how well the UI is designed, an area where Bazaar arguably excels.
22:46 cotto_work It's not a huge change for Trac afaict.
22:46 Coke allison: and svn  might be usable in another decade.
22:47 bacek Mua-ha-ha *cough*, GUI, *cough*
22:47 sorear I wonder if allison used github
22:47 bacek Linux, Perl5, Rakudo, 90% of languages on parrot uses Git.
22:47 allison sorear: yes
22:48 bacek Git is definitively *immature* for all this projects.
22:48 Whiteknight joined #parrot
22:48 allison what I would like to see is more developer workflow in git
22:48 cotto_work hio Whiteknight.
22:48 Whiteknight hello cotto_work
22:48 chromatic What do you mean by "developer workflow"?
22:48 cotto_work like the ones on the wiki?
22:48 allison chromatic: basically, git branches rather than svn branches
22:49 chromatic Goodbye testers!
22:49 allison aside from the final commit back to the shared repository, work as if this were a git-based project
22:49 allison chromatic: I don't understand that
22:49 allison chromatic: if testers aren't willing to use git now, why would they be any more willing if we switched?
22:50 chromatic It's not a matter of willingness.  It's discoverability.
22:50 allison we have to send around the name of the branch
22:50 chromatic and the location
22:50 purl You are in a maze of twisty passages, all alike.
22:50 allison a link isn't really more trouble
22:50 chromatic and its existence
22:50 chromatic And I know how this song ends.
22:51 plobsing joined #parrot
22:51 allison I'm dubious that we get people randomly trolling the branches/ directory to test things
22:51 chromatic "Gee, it looks like you git-cultists are spending a lot of time on infrastructure.  That can't be as convenient as bzr!  Let's switch to bzr!"
22:51 sorear github is constantly overloaded and has miserable uptime.  don't use it in VCS speed comparisons (ideally, a git-daemon would be set up on the same server as the svn-daemon for the duration of the test)
22:51 allison I'm a skeptic, what can I say
22:51 allison I like cold, hard proof
22:52 cotto_work I'd argue that testing branches will be more common if we swithc to git.
22:52 allison and so far, I don't see proof of git's superiority
22:52 bacek http://www.parrot.org/content/straw-poll-whic​h-version-control-system-would-you-parrot-use
22:52 allison a little better in some things, a little worse in others
22:52 chromatic I can imagine, if you still think that SVN is faster than Git.
22:52 allison it just doesn't seem worth the pain of a transition
22:52 bacek Erm... What other reasons do we need?
22:52 cotto_work it's a longer process to check out a svn branch thana git branch
22:52 allison cotto: that I believe
22:53 cotto_work svn is causing enough pain right now that it's worth the transition
22:53 allison (copying individual file)
22:53 allison what pain?
22:53 purl hmmm... pain is spelt "pain"
22:53 allison I feel no pain
22:53 * bacek usually works on 3-4 branches
22:53 allison and maybe that's the problem
22:53 chromatic I usually work on a handful of branches.
22:53 bacek And switch between them in seconds.
22:53 allison (I mean, maybe that's the reason for my skepticism)
22:53 chromatic Less than seconds.
22:54 allison bacek: I do too, and do a build on one while I'm working on the other
22:54 bacek In same checkout???
22:54 allison bacek: I don't *want* them in the same directory
22:54 bacek heh...
22:54 bacek nice...
22:54 bacek No more questions.
22:54 bacek One size fit all solution ftw.
22:55 allison that'd be nice
22:55 chromatic He's being sarcastic.
22:55 allison maybe our next project will be a revision control system
22:55 * allison groans at the thought
22:57 chromatic I'll say this.  I'm never going to merge another branch with SVN again.
22:57 allison so, do it with git
22:57 chromatic I'm going to warn other committers against merging branches with SVN.
22:58 allison I'd warn them against using whatever merging strategy it is that's causing the problem
22:58 chromatic svn merge
22:58 purl svn merge is probably really losing  :/
22:58 allison svn merge just makes a diff
22:59 chromatic ... and conflicts on metadata in the book directories, for example.
22:59 allison I've seen those commits running by and wondered about it
22:59 allison it makes no sense
22:59 chromatic That's what I'm saying.
22:59 cotto_work and fails to account for files added to the parent since the last merge
22:59 chromatic Oh yeah, I forgot about that.
23:00 allison but presumably, people review their merges before they commit?
23:00 allison and can revert unintended changes?
23:00 allison I would expect them to do that with git too
23:01 chromatic Don't forget renamed files, those are awful!
23:01 allison those I agree on
23:01 allison I didn't ever see the demo I asked for on git with that feature
23:02 sorear yeah and git has no rename handling at all
23:02 chromatic Because git doesn't need rename handling.
23:02 cotto_work I don't think to try to filter through the huge log of changes for something that svn should be expected to do.
23:02 sorear git is about points, it doesn't handle edges at all
23:02 allison cotto: branch review isn't just about that, it's about code quality
23:03 allison someone should be reading through a diff of every branch before it goes into trunk
23:03 allison someone other than the main developer of the branch
23:04 chromatic That's what commit mail is for.
23:04 chromatic ... except that's another piece of infrastructure we lose with git-only branches.
23:04 sorear Is chromatic arguing for or against git?
23:04 allison except for the merge back into trunk
23:05 allison sorear: he's arguing against a partial move
23:05 allison sorear: against git process on top of svn
23:05 allison I suspect git has some way of doing commit mail
23:05 chromatic against "You guys should try doing git-only branches, and we'll see how that process works, and then we'll stick with SVN or move to bzr."
23:06 cotto_work Getting the message only after the branch is merged negates some of the benefits of working in a branch.
23:07 allison git branches can be set up to email the parrot-commits list
23:07 allison (if they can't, then we have a deeper problem)
23:09 cotto_work ok, but that's more impedance matching between git and our existing svn infrastructure
23:09 chromatic Git branches look like more work in that scenario.
23:10 allison looks to me like Github provides default post-commit hooks including email
23:12 chromatic Okay.  So for a committer to demonstrate that working with Git is easier, faster, simpler, more correct than working with SVN, you must check out Parrot with git-svn, sign up on Github, fork an existing GH repo of Parrot, create your own branch, edit that branch to provide commit messages to parrot-commits, then link the two upstreams in your checkout.
23:13 chromatic I notice two things.
23:13 chromatic First, that's a bit of ceremony.
23:13 allison that's pretty much git in a nutshell, as far as I can tell
23:13 chromatic Second, Git makes all of that possible -- reasonably easy, actually.
23:14 jan joined #parrot
23:14 allison I'm with sorear on this one, I can't tell what position you're arguing for anymore
23:15 chromatic You can't do anything like that with SVN.
23:15 allison why would you want to?
23:15 Coke ... allison, I call bullshit on "not worth the pain of transition". if we cared about that, we'd still be back at perl.org.
23:15 sorear there are really two questions here
23:16 sorear 1. is git a better tool for us than svn?
23:16 allison Coke: that pain is exactly why we said there would be no infrastructure changes for at least two years
23:16 chromatic Why would I want to go through that ceremony?  Because you're arguing that it's the only way to demonstrate that git is worthwhile.  So let's play that game.
23:16 sorear 2. is decentral web a better workflow for us than single hub?
23:16 atrodo joined #parrot
23:16 allison sorear: that's a good clear way of putting it
23:17 allison I hear a lot of debate on 1, but so far no one seems to be pitching in for 2
23:17 Coke s/we/you/ =-)
23:17 allison Coke: there was general agreement at the time, probably because the memory was still fresh
23:18 allison (sometimes being the only one with a photograpic memory is frustrating)
23:18 sorear allison: I suspect that's because nobody supports 2.  I've never seen a svn->git transition result in a web process
23:19 chromatic Hey, that sounds like something I wrote quite a while earlier this afternoon.
23:19 allison sorear: it seems strange to me, since that's the one thing about git that I really consider to be an advantage
23:20 allison sorear: (an advantage shared by other DVCS)
23:20 cotto_work The it doesn't need to be argued.
23:20 cotto_work *then
23:20 Coke let me rephrase this debate: is there anyone other than allison who doesn't want to move to git?
23:20 sorear the web processes I see in the wild are on tiny projects with three contributors, where the logistics aren't an issue, and on huge critical projects (Linux itself) where you need five signoffs on everything and a web is a good way to arrange that
23:20 chromatic Why does that surprise you?  That's not a painful thing for committers, and this is a discussion for committers.
23:20 allison Coke: there's a lot of people who are concerned about the change
23:20 Coke allison: All I hear is you.
23:20 chromatic Coke, kid51 doesn't want to move to Git either.
23:21 allison but, as far as I can tell they're willing to put up with whatever the "higher ups" put on them
23:21 Coke ok. Thank you. I feel better about having the discussion knowing that it is not just a single developer who is concerned.
23:21 allison I'm just vocal
23:22 allison I'm generally inclined toward defending those who don't defend themselves
23:22 chromatic I don't want to speak for Jim, but I get the sense it's not a philosophical disagreement with Git or a distrust of the tool more than it is discomfort and unfamiliarity with it.
23:22 allison yes, I think you're right
23:22 Coke allison: you could be projecting.
23:22 Coke certainly there's a lot of developers who don't want to argue with you about this because you're the architect.
23:23 allison chromatic: probably even true for most people who are averse to the idea
23:23 allison but remember that we're dealing with volunteers here, and discomfort drives people away
23:23 Coke allison: Yes. That's a good thing for all of us to remember.
23:23 chromatic So does a repository which says "Your patches aren't first-class citizens."
23:24 allison I will say this, I may be the only person who has really used git, really understands it, and still hates it
23:24 chromatic Do you really understand it?
23:24 bacek 2/3 of our developers _want_ to switch to git.
23:24 allison Coke: I haven't seen much hesitation in arguing ;)
23:25 Coke speaking of discomfort - see you guys later.
23:25 Coke left #parrot
23:25 bacek I use git at $work for last two years.
23:25 allison you notice I haven't put my foot down and said never?
23:25 allison I'm still open to the idea
23:25 bacek Our front-end devs use Git without any problems.
23:26 chromatic We're talking about replacing a system which many developers acknowledge have problems which have bitten them and which many developers actively work around.
23:26 chromatic s/have/has/
23:26 allison yes, but replacing it with a system that's still biting people
23:26 allison and has the potential to do more damage
23:27 allison I wish I could see it
23:27 chromatic Are you volunteering to merge svn branches now?
23:27 bacek Can you prove that "git  has the potential to do more damage"???
23:27 allison bacek: it allows you to edit prior commits
23:27 bacek yes, so what?
23:27 chromatic I use that all the time.  It's a useful feature.
23:28 allison which means a mistake can trash the entire repository
23:28 bacek Until it's pushed you can do whatever you want.
23:28 allison all the way back in time
23:28 bacek no
23:28 bacek it can trash _your_ copy of repo
23:28 chromatic and only if you let it
23:28 allison and push it up
23:28 chromatic no
23:28 bacek and git-deamon will reject it
23:29 sorear every copy of the repo contains the entire history, and a cryptographic hash of the entire history
23:29 sorear not only will other contributors have a backup, but they will know *immediately* that something is wrong
23:29 sorear because the non- --force'd push will fail
23:30 allison so, as long as you don't run the *really* bad version of the command, you're safe?
23:30 * sorear plays with svnadmin
23:31 allison yah, I can do it, and so can 3 other admins on the svn server
23:31 chromatic svn rm *; svn ci -m 'HAHAHAHA'
23:32 allison are there different permission levels for git
23:32 sorear that doesn't affect history
23:32 bacek are there different permission levels for svn?
23:33 bacek sorear, ssh sv.parrot.org; rm -rf /var/lib/svn;
23:33 chromatic Sure, but you can disable forced fastforwards too.
23:33 sorear I think allison is talking about git reset --hard e927c24 # that's r1 in our git-svn ; git push --force --mirror
23:33 allison I'll tell you one thing that I *do* like about moving to git
23:34 allison hosting at github instead of Coke and I adminning the svn box
23:34 chromatic You can use a server-side receive hook to enable/disable features for certain users.
23:34 allison (there are others with access, but we do the admin work)
23:35 cotto_work that's a legitimate option.  We can also keep a clone on parrot.org for trac integration.
23:35 * bacek wander why my work git central repo doesn't require any administration in last 2 years. With about 20 different projects in it.
23:35 allison (of course, that'd be the same on hg too)
23:35 sorear I'd like to argue against github
23:35 sorear It has an abysmal uptime record
23:36 allison bacek: you don't do any admin on that server?
23:36 cotto_work That's not as important for a dvcs
23:36 bacek no one do.
23:36 allison bacek: never think about updime, upgrades, etc
23:36 allison uptime
23:36 cotto_work It'll be a minor annoyance.  that's all.
23:36 bacek Apart from adding more repos.
23:36 allison installing the latest version of git?
23:36 cotto_work (not saying anything for/against github)
23:36 allison making sure all the repos are compatible with the latest version?
23:36 bacek allison, it's still running 1.5.something.
23:37 bacek And I'm running 1.6.something
23:37 bacek And they all compatible.
23:37 bacek Welcome to modern world of non-braking changes.
23:37 allison bacek: probably time for an upgrade
23:37 bacek It's not bloody svn when update on central server require syncronous update of clients.
23:37 bacek allison, no. We don't need it.
23:38 chromatic sidebar!
23:38 purl i heard sidebar was too big.
23:38 bacek It's just central storage.
23:38 chromatic allison, if we disabled the possibility of rewriting history on the central Git server, would you feel more comfortable?
23:38 bacek Clients can be updated. "Server" can stay
23:38 allison chromatic: yes
23:38 chromatic I believe that's a trivial configuration option.
23:39 allison (which is not to say "entirely comfortable", but a significant improvement)
23:39 chromatic I also believe it even disables the --force behavior.
23:40 allison what would make me a whole lot more comfortable is if you could get ordinary testers/etc using git, and showing no signs of distress
23:40 allison I can learn anything, I've got an Einstein-level IQ
23:40 allison but, I'm very conscious of the fact that I'm strange
23:41 cotto_work That's a relatively simple issue of giving testers a couple of commands to run.
23:41 allison there's a difference between being told the commands and using the system on a regular basis
23:41 allison a *huge* difference
23:42 allison this is why I keep pushing for the trial run
23:42 chromatic The appreciable difference between working with branches in SVN versus working with branches in Git is... well, basically the presence of the Git index.
23:42 allison I want to know our devs can make the transition painlessly
23:42 allison and I don't mean the early adopter types
23:43 allison (I understand you all eat, drink, and breathe bleeding edge)
23:43 Whiteknight many of the new contributors we get, in my experience, are newbies to SVN as well
23:43 chromatic Hardly!  I didn't want Rakudo to move to Git.
23:44 allison Whiteknight: aye, but svn seems easier to pick up than git
23:44 sorear My biggest suspicion is that the biggest advantage of Git (eliminating the barrier to entry of new contributors) is rendered moot by the PCA
23:44 allison git has so many exceptions to the rule
23:44 Whiteknight and svn has so many known problems that need to be avoided
23:44 allison Whiteknight: but it's usually only advanced developers that run into them
23:45 allison Whiteknight: by which point, they can handle a little variation
23:45 cotto_work doing advanced things like merging branches?
23:45 chromatic renaming files
23:45 chromatic checking out branches
23:45 Whiteknight I've been bitten by file-renaming commits without branches before
23:45 allison sorear: the idea of DVCS is that everyone works on their own local repo, so it's no disadvantage not to have commit access to the central repo
23:46 Whiteknight I will no longer make a commit where I rename files and do anything else
23:46 chromatic Plain vanilla merges while renaming files!
23:46 allison sorear: our disadvantage there is not using distributed techniques
23:46 allison branch merging on git is *not* for the newbie
23:46 bacek allison, it is.
23:46 cotto_work Will a newbie be doing something that necessitates a branch then?
23:47 allison there are far more things that can go wrong, and in far worse ways
23:47 bacek When you do "git pull" you merge branches.
23:47 allison a recursive revert is sufficient to handle any mis-merge in svn
23:47 chromatic Ha.
23:47 allison with git, I've had to blow away my entire local copy
23:48 * bacek never blowed away local git repo.
23:48 chromatic Ditto.
23:48 allison it can't even handle an update if I have local changes
23:48 allison just barfs
23:48 chromatic Shenanigans.
23:48 purl Come on in to Shenanigans, Indiana's Premier "Couples Only" Club!
23:48 bacek git stash; git pull; git stash apply;
23:49 bacek _done_
23:49 allison and that's more friendly to newbies than 'svn update'?
23:49 chromatic Though why you'd update with local uncommitted changes is odd.
23:49 allison so I can test them on the latest version before committing
23:50 chromatic That's what local branches are for.
23:50 allison (really, the thought of committing something before testing it hurts my stomachh)
23:50 bacek That's why you don't use git.
23:50 bacek In git you always commit changes.
23:50 allison so you can commit a pile of stuff that might not actually work?
23:50 sorear the git-standard way to test is between 'commit' and 'push'
23:51 Whiteknight you're only "committing" it to where it is already on your machine
23:51 bacek You have power to review/revert this commit before push.
23:51 sorear if the tests fail, commit --amend
23:51 * allison hears fingernails on a chalkboard
23:51 chromatic Hang on, you're all confusing the issue.
23:51 chromatic Git doesn't force you to do that, allison.
23:51 allison I welcome all beliefs
23:51 sorear (this bugs me too)
23:51 allison it's fine
23:51 chromatic You can still use your own workflow.
23:51 chromatic I don't commit before testing, myself.
23:52 chromatic But what everyone is (implicitly) saying is that you don't *push* to a remote repo before testing.
23:52 allison before pulling and testing, hopefully
23:52 chromatic Sure.
23:53 chromatic If you hack, hack, hack then test and commit (or commit and test), you end up with some local commits you want to push.
23:53 chromatic Then you pull.
23:53 chromatic That implicitly rebases your changes to the remote HEAD.
23:53 chromatic Then you can test.
23:53 chromatic If you're happy, you can push.
23:53 bacek (rebase) it will not do it implicitely.
23:54 chromatic I know, I'm sort of lying to explain things.
23:55 bacek :)
23:55 chromatic If you're in the SVN worldview, there's little effective difference.  If you know how Git stores commits and files, you know why I'm lying.
23:55 allison see, it's when really smart people like you all get into debates about things like how to do a simple commit that I get worried
23:55 chromatic No one is saying "Push your commits before testing."
23:56 allison I have a chess-player brain, and I'm always thinking 7 steps ahead
23:56 allison one possibility is that we make the transition, it all goes smoothly, no trouble
23:56 allison everyone keeps on developing without a hitch
23:58 allison another possibility is that we lose 6 months to a year trying to work out the kinks in the infrastructure (like we did last time), development comes to a standstill, and the wonderful influx of new developers we're getting now drops off to a trickle, then a drip
23:58 allison another possibility is just low-grade annoyance
23:58 chromatic We already have the latter.
23:59 allison no outright revolt, but sullen disgust, motivating early departures from the project
23:59 allison chromatic: I don't see it, commits are high, branches are progressing and being merged

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

Parrot | source cross referenced