Parrot 2.3.0 Released | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches, test exceptions_refactor branch | welcome our GSoC students
Set by moderator on 27 April 2010.
Coke mmm. 00:02
00:23 snarkyboojum joined 00:27 Mokurai1 joined
Coke cotto_work: pmc-> results in an invalid variable name. 00:28
Coke tries SELF 00:29
bacek_at_work Coke, stop touching you SELF 00:36
Coke :P 00:38
ugh. gdb and pmc .c files is a terrible combination.
kid51 I see from the YAPC Calendar that there is a Parrot/Perl 6 workshop scheduled for all day on the 3rd day: yapc2010.com/yn2010/event/674 00:45
I thought Allison had nixed the idea of a Parrot workshop at YAPC.
Coke I thought that was just a BOF room. 00:49
is RSA the one that's been failing recently?
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
Coke they have a lot more rooms to fill this time.
i heard in #yapc that pmichaud had req'd the bof room.
woot. coretest passes with my codestring mods... 00:51
kid51 Actually, it's listed in that room for all 3 days of the conference!
pmichaud has two talks scheduled in the main rooms. This workshop is distinct from those.
And there's no detail as to what the workshop will consist of on any given day. 00:52
00:54 snarkyboojum joined
dalek kudo: f31d524 | jonathan++ | src/Perl6/Module/Loader.pm:
Apply patch from sorear++ to further fix up loading modules from other languages.
 00:55
Coke I think it's just an ongoing hackathon. =-) 00:57
but I don't know. I'd ping the list and ping #yapcs.
dalek rrot: r46161 | darbelo++ | trunk/src/dynpmc/Rules.in:
[dynpmc] Move the .h along with the .c file to the dynpmc/ dir.
 00:58
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. 00:59
Coke that's what the talks are for. 01:05
01:08 ash_ joined, snarkyboojum joined
dalek rrot: r46162 | coke++ | branches/codestring/src/pmc/string.pmc:
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.
rrot: r46163 | coke++ | branches/codestring/src/pmc/codestring.pmc:
Whoops, checked wrong variable.

  'make test' now at 100%
01:16 TiMBuS joined
kid51 Hmm, build failure 01:36
error:imcc:syntax error, unexpected $end
in file 'runtime/parrot/library/ProfTest/PIRProfile.pir' line 1
nopaste "kid51" at 192.168.1.3 pasted "'make' failure in trunk at r46163" (839 lines) at nopaste.snit.ch/20409 01:37
kid51 This is where things start looking amiss: 01:39
src/gc/api.c:169: failed assertion 'PObj_is_PMC_TEST(obj)'
Backtrace - Obtained 31 stack frames (max trace depth is 32).
... which was immediately preceded by: 01:40
./parrot-nqp --target=pir runtime/parrot/library/ProfTest/PIRProfile.nqp > runtime/parrot/library/ProfTest/PIRProfile.pir
Coke kid51: that's been failing sporadically in taptinder for 2 days. 01:45
kid51 I had successful builds on this box at r 46126 last night. 01:48
Coke yup. it's sporadic. 01:49
taptinder?
purl it has been said that taptinder is continues integration tool - taptinder.org . For Parrot project running on tt.taptinder.org/ and reporting build failures to #parrot channel as ttbot.
01:55 mikehh joined 01:58 Psyche^ joined 01:59 JimmyZ joined
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 01:59
ttbot Parrot trunk/ r46161 i386-freebsd-64int make error tt.taptinder.org/file/cmdout/288509.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 02:04
kid51 I take back what I said about 46126. I misspecified the test. 02:05
Hmm. Successful builds and make test at 46153 and 46154. 02:15
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
with codestring is "how do I switch branches?
Coke svn switch <path to branch> 02:17
not sure if that'll work with the --gen-parrot stuff. 02:20
kid51 Damn: an intermittent build failure: the worst kind. 02:22
I've gotten both successful and failed builds at r46163.
sorear ok, started rakudobuild on the branch 02:25
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: tt.taptinder.org/file/cmdout/285080.txt
Coke it's sporadic, though; could be any number of commits before that. 02:27
that's an excellent starting point, htough.
02:28 theory_ joined
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:36
02:38 bacek_mobile joined
bacek_mobile hi 02:38
problem with segfaults is in compact-pool-revamp merge 02:39
kid51 bacek_mobile: Which commit was that merge?
02:41 theory joined
kid51 r46077 02:41
okay, if that commit was problematic, that would be chronologically consistent with failures observed; none were before that 02:42
sorear what is the logic behind responding to out of memory by abort() ? 02:45
dropping a 1.5 GB core file is very disruptive to system operation
02:45 Mokurai joined
Coke debug purposes? 02:48
Iunno. 02:49
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33563), fulltest) at r46163 - Ubuntu 10.04 i386 (g++) 02:51
t/pmc/packfile.t - TODO passed: 34 - in coretest, smoke and all cores in fulltest
in testf - t/op/exit.t - TODO passed: 6
dalek rrot: r46164 | jimmy++ | trunk/src/oo.c:
random consting
 02:52
02:54 theory joined
sorear Did something change in parrot_config recently? I'm getting cg_flag not found errors with blizkost 02:55
ttbot Parrot trunk/ r46164 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/288556.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 02:56
02:59 Mokurai joined 03:00 janus joined
mikehh ha - it's after 4am for me - needs sleep - bbl 03:02
JimmyZ sleeping well 03:06
Coke sorear: you mean "cc_flag" ? 03:13
its "ccflags" 03:14
03:16 snarkyboojum joined
sorear Coke: no, @cg_flag@ 03:20
it worked fine until I updated parrot from 2.3.0 to trunk
unfortunately there are no comments to explain what it /does/
purl Hmm. No matches for that, sorear.
Coke ah, yes. probably removed with the runcore.
sorear "the runcore"?
Coke the computed goto runcore. 03:21
sorear ohhh
I was trying to expand it as cc -g flag
Coke why are you looking for it?
... no.
that might be @optimize@
sorear because blizkost FTBFS with a missing config entry error
Coke it shouldn't need it unless it was generating dynamic opcodes. 03:22
sorear blizkost uses a cargo cult build system
there are no comments and lots of platform ifs
I have no idea what half of it is for
Coke blizkost? 03:24
purl i think blizkost is github.com/jnthn/blizkost/tree/master or the last Jonathan's project, an embedding of Perl 5 in Perl 6
Coke is that the main url?
03:28 Andy joined
sorear Coke: yes 03:28
Coke k. checking.
looks like you can just remove it. 03:29
s/@cg_flag@ // 03:30
I do that, I get a warning about my Perl not allowing interpreters, and then build fails on exactly that.
rip it out, give it a shot. =-)
dalek izkost: 02c45ba | sorear++ | build/Makefile.in:
Remove obsolete references to the cgoto core
 03:34
rrot: r46165 | jimmy++ | trunk/src/pmc/class.pmc:
changed interp to INTERP for unification
 03:42
Coke Jimmy++ 03:45
sorear: hey, would you be willing to try that build again with a slightly different patch? 03:46
(which I have not yet committed)
sorear Coke: yes
ttbot Parrot trunk/ r46168 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/288647.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 03:50
Coke tewk: to save me the trouble, can you add experimental notes for your new pmcs? 03:51
(also, why is one named parrot* and one not? (I always thought naming anything parrot* was redundant. =-))) 03:52
(also (lisping))
ttbot Parrot trunk/ r46169 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/288684.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 03:54
03:54 kurahaupo joined
dalek TT #1395 closed by jimmy++: [patch]various minor change to parrot 03:57
TT #1395: trac.parrot.org/parrot/ticket/1395
TT #92 closed by jimmy++: Should all header files under src/ be moved to include/ dir?
TT #92: trac.parrot.org/parrot/ticket/92
Coke sorear: ok. branch updated with a WAG. 03:58
dalek rrot: r46166 | tewk++ | trunk (4 files):
Remove old thread pmcs
rrot: r46167 | tewk++ | trunk (5 files):
Remove thread types PARROT_THR_TYPE_1 ...
rrot: r46168 | tewk++ | trunk (2 files):
Remove pt_thread_run
sorear WAG?
purl WAG is Wild Ass Guess
dalek rrot: r46169 | tewk++ | trunk (2 files):
new thread creation functions
rrot: r46170 | tewk++ | trunk (7 files):
Added new parrotthread pmcs
rrot: r46171 | coke++ | branches/codestring/src/pmc (2 files):
passing codetest
rrot: r46172 | coke++ | branches/codestring/src/pmc/codestring.pmc:
Instead of re-using the existing FSA, see if making a new one is more

  (Was the old one hanging onto the old elements?)
sorear Coke: fwiw I'm *not* doing distcleans between branch switches 03:59
tewk is the gsok thread guy?
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.
sorear Coke: within 3 seconds, 800MB and climbing fast 04:03
this could just be a transient though - hold on 04:04
tewk Coke: threads are just plain broken, this is an attempt to slowly fix them. 04:05
sorear: I'm not the gsok guy. 04:06
sorear huh 04:07
top says 12% SY
I didn't know swapping was that CPU intensive
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?
I'm not complaining about fixes, just wish we had a ticket before 2.3.0 went out the door.
c'est le vie.
JimmyZ tewk++ for parallelism 04:10
sorear Coke: with your fix, rakudo build ran out of memory 25% faster. 04:11
only took 9 minutes this time.
JimmyZ sorear: how about trunk? 04:12
tewk tewk.com/pdd32_parallelism
sorear JimmyZ: Finishes without error in 12 minutes.
JimmyZ how about memory? 04:13
purl DOCTOR MEMORY!!!
sorear I don't know
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.
sorear I dozed off when I was supposed to be staring at top and all I have is the time output :(
tewk Coke: where do you want experimental notes.
dalek TT #896 closed by jimmy++: [patch]consting socket_win32.c
TT #896: trac.parrot.org/parrot/ticket/896
rrot: r46173 | jimmy++ | trunk/src/io/socket_win32.c:
random consting
 04:14
ttbot Parrot trunk/ r46173 i386-freebsd-64int make error tt.taptinder.org/file/cmdout/288788.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 04:15
04:19 kurahaupo joined
sorear tewk! you broke my build 04:19
make: *** No rule to make target `src/pmc/parrotrunningthread.pmc', needed by `src/pmc/parrotrunningthread.dump'. Stop.
svn status shows no '!'
tewk sorear: make realclean 04:20
Coke sorear: jezu. Ok, I'll leave it for chromatic to figure out. =-) 04:22
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:23
04:39 wagle joined 04:41 kurahaupo joined
dalek TT #1601 created by tewk++: Parallelism aka ParrotThreads 04:46
TT #1601: trac.parrot.org/parrot/ticket/1601
rrot: r46174 | tewk++ | trunk/DEPRECATED.pod:
Add thread and parallelism to experimental
 04:47
Coke tewk: if you're reusing an existing name, that's fine. the commit said "added". 04:49
so I assumed it was new.
tewk Well I removed it then added it again, so I think you may have a good point. 04:50
04:53 Andy joined 05:03 rurban_ joined 05:12 Andy joined
ttbot Parrot trunk/ r46174 cygwin-thread-multi-64int make error tt.taptinder.org/file/cmdout/288907.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 05:13
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
I pinged chromatic, but he is not swooping in to save the day.
(I assume Real Life is involved.)
ah. it wasn't pmichaud that requested the parrot room, it was particle. 05:22
(per pmichaud++)
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
JimmyZ Yeah
sorear I've looked at the implementation 05:24
it's... like watching a trainwreck
JimmyZ I'd very appreciate if you can fix it. 05:25
sorear I can't move.
Too... enthralling...
Coke expensive how? 05:28
a lot of that complexity is at build time, not run time.
if I'm just using ATTRs, does the default destroy cleaning that up from a GC perspective? 05:32
05:32 szabgab joined
tewk With a gc the problem is usually premature collection due to failing to mark correctly 05:34
Coke tewk: branches/codestring is consuming a ton of memory; I'm assuming I'm not freeing something. 05:36
or perhaps I'm overmarking. 05:37
if I allocate 1000 codestring pmcs, I end up with 2000 more ACTIVE_PMCS. 05:38
(that's if I allocate them in a tight loop and throw them out, and do a collect before I check again.
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
sorear If your goal here is performance why not start in C 05:40
?
Coke ... PMCs are in c. 05:41
tewk Coke: set string native creates a new RSA, just set its size to 0 and then push the string. 05:45
Coke tewk: that was a test - current version just resets it instead. that saves me 2 pmcs that weren't getting freed. 05:47
still leaking 7 PMCs when doing a new Codestring, .emit('foo') $S0 = $P0.
think I need a custom destroy. 05:48
and I think codestring might have been leaking linepos all this time.
tewk no, I think you need to define concatenate, I think you are getting the impl from scalar.
sorear Coke: I was under the impression CodeString was in PIR. 05:49
Coke sorear: no. 05:50
not for some ... what, 2 years now?
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?
ttbot Parrot trunk/ r46175 i386-freebsd-64int make error tt.taptinder.org/file/cmdout/288976.txt ( tt.taptinder.org//buildstatus/pr-Pa.../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.
sorear walking the heap in gdb isn't too hard 05:52
Coke blarghle. my demo wasn't running a gc.
dalek rrot: r46175 | jimmy++ | trunk/src/pmc/callcontext.pmc:
removed outdated comment
rrot: r46176 | coke++ | branches/codestring/src/pmc/codestring.pmc:
Avoid creating a new pmc that we were just leaking anyway.
Coke collect != sweep.
dalek rrot: r46177 | coke++ | branches/codestring/src/pmc/codestring.pmc:
don't call SUPER in init/mark - we're not built that way anymore.
Coke ok. pmc usage isn't increasing now. buffer usage is, though. 05:53
sorear: src/pmc/codestring.pmc 05:56
05:57 alexn_org joined
sorear Coke: mm? 06:01
Coke is the pmc definition for CodeString.
which is transformed to C and then compiled. 06:02
cotto Coke, how does it work that you use STRING *strings; in CodeString's set_string_native without initializing it? 06:08
dalek rrot: r46178 | coke++ | branches/codestring/src/pmc/codestring.pmc:
remove unused variable.
 06:09
Coke cotto: there's a GET_ATTR there.
ah, think I found my leak.
cotto the leak appears to be in my brain 06:10
too much garbage, not enough collection
nopaste "coke" at 192.168.1.3 pasted "this look right? Doesn't seem to help, sadly." (23 lines) at nopaste.snit.ch/20412 06:12
dalek rrot: r46179 | coke++ | branches/codestring/src/pmc/resizablestringarray.pmc:
When trying to shrink an array, forget about our previous contents.

it does seem correct.)		 06:25
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:28
Coke tewk: crud. you're right. 06:29
reverted. 06:32
tewk++
tewk wait, I'm not so sure.
no I'm right, the NULL loop that was already there is needed, your new one isn't 06:33
Time to go to bed. 06:34
Coke amen.
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 nopaste.snit.ch/20414
dalek rrot: r46180 | coke++ | branches/codestring/src/pmc/resizablestringarray.pmc:
fix typo. (no, still doesn't help with burning ACTIVE_BUFFERS when using
 06:41
rrot: r46181 | coke++ | branches/codestring/src/pmc/resizablestringarray.pmc:
Revert changes to this file;

the array anyway, so these should be GC'd.
Coke tewk: Why have N RSAs? 06:43
sorear Parrot has an extremely wrong notion of what "Unicode" means.
Coke tewk: instead of a single oen?
sorear: you're not helping.
If you have specific complaints, those are nice to hear and we can fix them. 06:44
If you have rants with no details, those are just frustrating.
tewk Coke: if (pos == 0 && percentPos < 0) just push the string, don't do substr.
thats effectively just a concat, no special formating
Coke tewk: isn't that just going to end up with /more/ temporary RSAs?
tewk: how dumb is substr? 06:45
that is a simple enough check, though, sure.
06:46 theory joined
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.
sorear: no, all of our charsets are not unicode. 06:47
moritz sorear: the latin1 charset is not Unicode
sorear: it is *in* Unicode, but it is not the same
Coke (they is us, btw. =-) 06:48
tewk: looks like anything that's doing a substr is leaking BUFFERs. 06:49
(at least in emit())
sorear What's the difference between an encoding and a charset? 06:50
moritz charset = character set = character repertoir
encoding = mapping from bytes into a character repertoir
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
moritz sorear: because some applications what small charsets for faster operations
Coke tewk: why?
oh. YOUR RSA, not mine. =-) 06:52
sorear Coke: you know about the substr optimization, right? could be relevant here
Coke I still think a single join at the end is more efficient.
I was just about to ping bacek, since he mucked with strings.
tewk Coke: your probably right.
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
Coke: Parrot_str_substr doesn't necessarily copy any data; it shares a reference to the old buffer 06:53
if you have a big string and substr out a few small pieces, you'll leak 06:54
is this what you're seeing?
Coke I thought chromatic & bacek fixed that issue. 06:55
bacek_at_work It will not leak.
(And single join is much more efficient)
sorear (for very conservative definitions of leak)
the big string will last as long as the pieces 06:56
bacek_at_work yes
sorear chromatic & bacek created this "issue"
it's a win in a lot of cases
bacek_at_work no
it's about same as old COW strings
sorear oh right, COW
I blissfully forgot about that 06:57
bacek_at_work actually, it's _exactly_ same as COWed strings
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. =)
bacek_at_work Coke, any "symptoms"?
dalek rrot: r46182 | mikehh++ | trunk/MANIFEST:
re-generate MANIFEST
 06:58
rrot: r46183 | mikehh++ | trunk/src/pmc (2 files):
add svn properties
rrot: r46184 | coke++ | branches/codestring/src/pmc/codestring.pmc:
Small optimization - if the whole string is %-free, avoid a substr call.

  tewk++ as this seems to fix the buffer leak in the simple case.
rrot: r46185 | mikehh++ | trunk/src/pmc/parrotthread.pmc:
fix codetest failure - line length and trailing spaces
rrot: r46186 | coke++ | branches/codestring/src/pmc/codestring.pmc:
fix comment oddity and bizarre in-situ assignment that must have been a cNpasto
rrot: r46187 | mikehh++ | trunk/src/thread.c:
fix codetest failure - line length
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.
tewk bacek_at_work: does Parrot_str_substr do the right optimization if you ask for a substr that is the whole string?
bacek_at_work tewk, str_substr just create new string header and reuse old buffer. 06:59
So, it doesn't really matter how big substring is
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.
nopaste "coke" at 192.168.1.3 pasted "sample script" (98 lines) at nopaste.snit.ch/20415
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.
purl Coke is channeling thoth!
Coke (the value of strings needs to persist over multiple calls to emit()"
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...
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."
if you detected a substr that was the same as the original string you could save a string header allocation. 07:03
Coke bacek_at_work: so, anyway; remaining cases all suspiciously use Parrot_str_substr, and buffer use grows. 07:05
nopaste "coke" at 192.168.1.3 pasted "output of that script." (20 lines) at nopaste.snit.ch/20416 07:06
tewk Coke does rakudo do codstring += string
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
sorear excessivelt?
Coke you can do emit a lot. it's ok. =-)
tewk if so you should implement concate in codestring, the one in scalar isn't
Coke tewk: possibly.
... though I doubt it, since the build completed for me. 07:08
(of rakudo using this branch.)
tewk the one in scalar is inefficient.
They probably generally use emit for concat.
Coke concat is just the simple emit() path with this new setup. 07:09
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>
Coke bacek_at_work: why does every suggest that? =-)
tewk temporal RSA doesn't exist.
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.
Coke (which is a more PMCs.)
and more strings, too.
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.)
tewk but that is really stretching it, and we don't have a generational GC.
Coke tewk: the objects go away as soon as some calls get_string()
s/go away/are collectable/
dalek rrot: r46188 | coke++ | branches/codestring/src/pmc/codestring.pmc:
fix the comment
 07:15
rrot: r46189 | mikehh++ | trunk/src/thread.c:
fix codetest failure - add c function docs
Coke ok. I'm supposed to be asleep 4 hours ago.
tewk So your comment " why does every suggest that? =-)" is justified,
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
moritz compilers/pct/src/POST/Compiler.pir +289
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
sorear rakudo just uses PCTR 07:17
PCT
it doesn't do += or anything
tewk <@moritz> btw it seems that there is a Codestring .= String operation in POST
moritz I have no idea how often it is called, though 07:18
tewk moritz justifies my suggestion.
good point.
Coke ok. if someone adds a (failing) test to t/pmc/codestring.t in the branch, that would be awesome.
(that does a .= String) 07:19
(no need to todo it even.)
ok. sleep now.
tewk Coke it wont fail, it will just be less efficient.
it will force a premature join 07:20
I'm realy going to bed now, nite.
dalek parrot: 1ae4402 | dukeleto++ | (4 files):
Attemp to use Parrot_load_bytecode to load P6object.pbc

call Parrot_load_bytecode(interp, "P6object.pbc") before we load our PIR that intercepts file I/O. This currently coredumps in parrot_split_path_ext, which is called by Parrot_load_bytecode.		 07:21
parrot: e39408d | dukeleto++ | plparrot.c:
The docs for Parrot_load_bytecode were wrong (the horror!), it takes a Parrot_String
parrot: 26766ad | dukeleto++ | plparrot.c:
Create a dummy packfile

  "load_bytecode" couldn't find file 'P6object.pbc'
parrot: 2a0d28c | dukeleto++ | plparrot (3 files):
Go back to load_bytecode in PIR and add an :immediate flag
parrot: fc4809c | dukeleto++ | (5 files):
First prototype of a working security system

around, such as not being able to load_bytecode in PIR which is called from the embedding interface, so P6object.pbc is loaded from C.
parrot: 17e2a82 | dukeleto++ | Makefile:
Remove some junk from Makefile
parrot: 54339f4 | dukeleto++ | HISTORY:
Add a trifle to HISTORY
parrot: 8b0266b | dukeleto++ | TODO:
Update TODO
parrot: 63472ee | dukeleto++ | (6 files):
Merge branch 'security'

  \tHISTORY
07:28 fperrad joined
dalek rrot: r46190 | fperrad++ | trunk (2 files):
[TAR] add full_path() & rename()
 07:31
cotto tosses dalek some ketchup 07:44
dalek izkost: 64df29f | sorear++ | src/pmc/ (8 files):
Reify nexuses as objects outside P5Interpreter

provides a platform to avoid destruction order dependencies, and gives me an excuse to use the word nexus more.		 07:47
ttbot Parrot trunk/ r46190 cygwin-thread-multi-64int make error tt.taptinder.org/file/cmdout/289272.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
dalek rrot: r46191 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] make tarball without copy in filesystem
 07:48
07:52 aukjan joined
cotto mai plan. let me show you it 07:55
dalek tracwiki: v1 | cotto++ | UsingGitAndSvnInTrac
tracwiki: trac.parrot.org/parrot/wiki/UsingGi...ction=diff
tracwiki: v2 | cotto++ | UsingGitAndSvnInTrac
tracwiki: fix wiki formattening
tracwiki: trac.parrot.org/parrot/wiki/UsingGi...ction=diff
tracwiki: v3 | cotto++ | UsingGitAndSvnInTrac
tracwiki: trac.parrot.org/parrot/wiki/UsingGi...ction=diff
cotto . o O (Couldn't have timed that better.)
dalek izkost: cca07ac | sorear++ | src/pmc/ (4 files):
Sever nexuses at the start of global destruction

interpreter created).		 07:58
cotto definitely time for sleep 07:59
night, humans
08:36 aukjan joined
dalek rrot: r46192 | jimmy++ | trunk/src (72 files):
manual optimization for old compiler
 08:38
08:53 allison joined
dalek rrot: r46193 | jimmy++ | trunk/src (19 files):
manual optimization for old compilers
 08:54
ttbot Parrot trunk/ r46193 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/289409.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 08:57
Infinoid wow, dalek is getting a workout these days 09:13
dalek rrot: r46194 | jimmy++ | trunk/src/sub.c:
localize vars
 09:43
09:51 iblechbot joined 10:07 aukjan joined 10:22 riffraff joined 10:43 aukjan joined 10:46 Andy joined
dalek rrot: r46195 | NotFound++ | trunk/src/pmc/parrotthread.pmc:
set_integer_native is void
 10:48
NotFound The Parrot_pmc_free_temporary in hashiterator.pmc shift_string looks suspicious. 11:09
Is a good candidate for the random segfaults. 11:10
11:49 JimmyZ joined 12:26 ruoso joined 12:29 whiteknight joined
dalek p-rx: 8712c4a | moritz++ | src/Regex/Cursor.pir:
create new match objects and arrays in separate methods that can easily be overridden from HLLs
 12:31
p-rx: 5c23708 | moritz++ | src/Regex/Cursor.pir:
Merge remote branch 'origin/mob2'

simplify generation of HLL-specific match objects. There's a proof-of concept Rakudo branch 'mob3' which uses this new facility.
p-rx: 3f00ce8 | moritz++ | (5 files):
update stage0 files
 12:37
12:38 bluescreen joined 12:45 khairul joined 12:48 khairul left, khairul joined
dalek rrot: r46196 | moritz++ | trunk/ext/nqp-rx/src/stage0 (4 files):
[nqp] update to get latest match object creation hooks
 12:59
rrot: r46197 | NotFound++ | trunk/src/pmc/fixedintegerarray.pmc:
avoid a temporary PMC in FPA set_string_keyed_int
13:03 mikehh joined, rurban_ joined 13:08 JimmyZ joined
Coke mentor jimmy? 13:13
rurban: hey, reini. 13:14
particle coke: what's this business with "the parrot room"? 13:25
mikehh tewk: ping 13:27
13:30 bkuhn joined
JimmyZ Coke: what? 13:31
mikehh getting a bunch of packfile test failures 13:33
13:34 atrodo joined
Coke JimmyZ: did you see chromatic's question about your --i vs. i-- patch? 13:39
you may be optimizing for compilers that we're not supporting.
particle: yapc2010.com/yn2010/event/674, yapc2010.com/yn2010/event/673, and yapc2010.com/yn2010/event/671 13:41
I understand that's your doing.
er, and yapc2010.com/yn2010/event/675 and yapc2010.com/yn2010/event/676 13:42
particle aye, i suppose it is
Coke SO, that's, what, 40 HOURS of ``content'' ? 13:43
I look forward to your gymnastic routine. =-)
particle i never got confirmation from patrick that it was workable, so my tentative 'yes' became definite without further input
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.
particle it will be a room to hack in and answer questions, most of the time, i imagine 13:44
either during BoF hours, tutorial days, or some conference sessions, there may be tutorial-style content. 13:45
it'd be nice to have a little something each day
msg pmichaud ping me when available for yapc-perl6workshop discussion 13:46
purl Message for pmichaud stored.
Coke if you're imagining something that needs manpower, we need to make sure there's staffing, etc.
particle i guess i'd better book flight/hotel... i'm in denver now, nyc later, urbana/champaign end of may
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
Coke wish I could take the train. *sigh*
particle why not?
dalek rrot: r46198 | NotFound++ | trunk/src/pmc/codestring.pmc:
avoid pmc_new_temporary in codestring emit method, maybe slower but less crashy. Also use fixed instead of resizable string array
 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.)
(hell, none of us may be there thur or fri.)
particle right... damian teaching perl 6 is compelling, but i expect the workshop room to be pretty empty then :) 13:49
JimmyZ Coke: Does that patch was wrong? 13:50
Coke JimmyZ: I don't see that it does anything.
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?
particle, answer the man's question.
=-)
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.
s/infix/prefix 13:52
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
NotFound Coke: What's the maintenance cost of having ++i instead of i++?
Coke purl, 2010 - 1998?
particle we're just on the cusp of cross-compiling parrot
purl coke: no idea
Coke 2010 - 1998
purl 12
JimmyZ msvc 6 doesn't suprrot postfix optimization
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
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
Coke hey, win 2, there you are. =-)
/necessary/ ? 13:56
i++ doesn't work in msvc 6?
NotFound Coke: well, people used to c++ like me usually think "why is that postfix"? ;)
darbelo 'cause ++c sucks as a name?
Coke NotFound: fair enough.
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.
So yoy use the prefix by default and tends to do right thing. 13:58
Coke even if your c++ compiler is compiling C? =-)
NotFound Coke: when is compiling C, can't be overlodaded ;) 13:59
dukeleto 'ello
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?
C89 is not C99
postfix optimization is for OBJECTS in C++, because postfix ++ needs to copy the object 14:01
prefix ++ doesn't
NotFound particle: no, in C++, but is the reason to get used to use prefix by default.
particle but parrot is written in C, not C++ 14:02
Coke particle: yes, but we have C++ people who work on prrot.
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.
NotFound particle: yes, but if we talk about what looks strange, the strangeness is in the eye of the beholder.
Coke parrot has a long history of prematurely optimizing things that turned out not to help so much.
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:04
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?
particle benchmark it before and after patch, post results to parrot-dev, and let the hoardes decide 14:06
14:06 zostay joined
particle i don't mind changing the mindset of developers to prefer prefix increment over postfix, if it makes sense 14:06
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
particle but it will get reverted over time
NotFound ?
Coke NotFound: check out branches/codestring
which does that slightly differently.
NotFound Coke: but we have random crasehs in trunk right now. 14:08
Coke those random crashes predate codestring.
er, chromatic's codestring.
NotFound Coke: some of them might have been fixed by r46197 14:09
Coke in any case, more eyes on codestring branch appreciated. =-) 14:10
NotFound I think pmc_new_temporary need lots of test... or alternatively, kill it. 14:12
Anyway, after those last fixes I'm no longer having crasehs on x86-64 14:16
Checking out branch 14:18
14:23 lucian joined 14:25 hercynium joined
NotFound Coke: no random crashes for a now with the codestring branch, amd64 both with and without --optimize 14:27
Coke danke. 14:28
any idea why it seems to be using more memory? =-)
14:29 bubaflub joined
particle JimmyZ: can you do the benchmarking? 14:30
JimmyZ particle: I don't have old compilers 14:31
particle: but from me, it's 0.01% faster, though it's not exact 14:34
particle: I guess I got wrong benchmarking
14:34 jan joined
JimmyZ is confused, why it get controversy 14:37
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.
JimmyZ then sorry for the wrong message ;)
darbelo Big patches with 'code cleanup' on the commit message get very little attention. 14:39
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' ;)
Coke see my previous send about historical ``optimizations'' 14:41
JimmyZ is feeling he was doing the wrong things.
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.
They've gotten used to me. 14:43
particle actually, the patch isn't that big, now that i look at it again 14:44
it's a micro-optimization, and perhaps premature, but it's harmless.
NotFound Coke: no idea about the memory usage. I suppose that codestring keeps refered somewhere long after used. 14:45
Looks big, but the changes are pretty little.
Coke NotFound: yup, see nothing obvious that would get kept.
particle is there some way for me to see a diff of trunk and branches/codestring online? 14:46
i have a little time to look for scoping problems or other memory-related changes
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.
particle thanks 14:48
Coke particle: trac.parrot.org/parrot/log/branches/codestring - click on "view changes" 14:49
it's not vs. trunk, but vs. the branch point. close enough.
(but branch point was just after chromatic's change to CS)
particle ah, yes, trac.parrot, not svn.parrot... thanks
and that's where you see the memory changes, vs the branch point?
14:52 JimmyZ joined 14:54 ash_ joined
JimmyZ good night,all 14:55
Coke night
particle: sorear reports that it tear through memory much faster building rakudo.
I can verify that Codestring's ' 14:56
particle hrmm, well, i can try that and see
Coke emit seems to be generating BUFFERS that are not let go.
see my nopastes from about 8 hours ago for sample code. 14:57
particle ok, bbi5m after i dial into a concall 14:59
NotFound Coke: I've found where the CodeString gets marked: in the context 15:45
Just insert a call to any function before sweep, and buufers gets cleaned.
In the CallContext PMC 15:46
15:48 theory joined
NotFound So looks like the poblem in other cases must also be that the CodeString keeps refered long before after his usage. 15:50
s/before/after
Coke NotFound: good find. can we fix this from inside codestring? 15:57
`/win 2 15:58
NotFound Coke: I don't think so, looks like a hole in PCC
moritz please remember to ticket it
NotFound A workaround for codestring can be to provide a method to release his content.
Coke NotFound: but then someone outside of CS would have to invoke it, yes? 15:59
NotFound Coke: yeah
Coke so, meh.
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.
Coke ... that is f'd up. 16:01
(verified, all the buffers go away then.)
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:02
Coke seems like we could clear it as soon as we checked the results. 16:03
(near get_results)
NotFound Mm... but get_results is omitted if no return is expected, isn't it? 16:04
BTW I found it just by inserting abort(); in CodeString mark 16:05
Coke ... which shows you when it got freed? 16:06
``freed''
NotFound The backtrace shows the call chain.
Coke neat trick.
purl pulls a rabbi out of her ass.
Coke shalom, purl.
purl shalom is probably at www.neurotrash.com/original/filmpla...tem_ID=101
NotFound Shows where a poiter to is retained.
Coke I imagine this will be a huge fix. you should totally beat chromatic to it. =-) 16:07
cotto forget shalom 16:09
purl cotto: I forgot shalom
16:12 brrant joined
cotto Coke, is parrot.org running apache? 16:13
Coke cotto: I believe so, eys. 16:15
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]
NotFound Uh... I was wrong, in the example parrot_debug isn't a sub, is a macro. 16:38
Coke still, if you do sweep 1 (.parrot_debug) sweep 1 (.parrot_debug), the last debug shows the BUFFERS were collected 16:40
NotFound: hey, you wanna see segfault? =-) 16:42
NotFound I already see a lot X-) 16:45
Coke trac.parrot.org/parrot/ticket/1602 16:46
so I can't check to see if the CURRENT_OBJECT is the issue or not. =-) 16:49
the same problem is occuring in trunk, btw. 16:51
dalek TT #1602 created by coke++: .INTERPINFO_CURRENT_OBJECT causes segfault: 16:52
TT #1602: trac.parrot.org/parrot/ticket/1602
NotFound Coke: nice catch 16:55
17:00 ruoso joined
Coke NotFound: opened 1603 to track the ACTIVE_BUFFERS issue; feel free to add your notes. 17:01
17:04 ash_ joined 17:09 ruoso joined 17:13 davidfetter joined
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:14
Ah, no, I was misreading. 17:15
Looks like the context signature is the problem. Somewhere the current_object is copied to it. 17:17
I mean, the context.... the callee context, maybe. 17:18
17:24 confound_ joined, particle joined
NotFound can't find HEADERIZER HFILE directive in "src/pmc/threadinterpreter.pmc" 17:25
dalek rrot: r46199 | NotFound++ | trunk (2 files):
Don't return NULL in interpinfo_p, TT #1602, Coke++
 17:38
cotto_work good morning 17:41
purl For you maybe.
dalek TT #1602 closed by NotFound++: .INTERPINFO_CURRENT_OBJECT causes segfault:
TT #1602: trac.parrot.org/parrot/ticket/1602
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:43
NotFound looking pdd03 17:44
17:45 joeri joined
Coke NotFound: I don't think it's the current object - the PMCs are around, the strings area. 17:47
er, BUFFERs.
could it be that the containers are getting recycled, but it's child strings are not, until the second sweep?
NotFound Coke: it was the current object during the method call.
Coke NotFound: I'm just looking at my interpinfo output - the PMC's aren't stacking up. 17:48
NotFound Coke: is hidden in the signature object of the current context, until some call overwrites it. 17:49
Coke freaky.
NotFound Now looking if the fix breaks some unrelated part. 17:50
dukeleto 'ello 18:09
Coke NotFound: you got it? 18:13
bubaflub afternoon dukeleto 18:14
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.
nopaste "NotFound" at 192.168.1.3 pasted "Fix for TT #1603" (14 lines) at nopaste.snit.ch/20417 18:16
NotFound Coke: here is. 18:17
cotto_work woohoo 18:20
NotFound I still don't understand well enough PCC details, allison must take some look.
Coke NotFound: no effect on the sample code.
NotFound Coke: Uh? For me ACTIVE_BUFFERS: 218 18:21
Coke hurm. did my rebuild not take?
double checking.
ACTIVE_BUFFERS.............: 4151 18:22
(it's the second print of ACTIVE_BUFFERS that's the bad one.)
18:22 kjeldahl joined
NotFound Let me rebuild, maybe there is some remaining of the previous attempts. 18:22
Stupid of me... was using a modified version of the example with two sweeps. 18:29
Let me found again what was the appropiate change. 18:30
Coke going to yapc? 18:38
purl See : going to yapc::na or yapc::whatever or cwest, uri, DrForr, dha, ology
Coke going to yapc::na?
purl See "going to YAPC::NA $year"
Coke going to yapc::na 12010?
going to yapc::na 2010?
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
Coke going to yapc::na 2010 is also coke or packy
purl okay, Coke.
rbuels purl: going to yapc::na 2010 is also dukeleto
purl okay, rbuels.
Coke going to yapc::na 2010 is also kolibrie 19:00
purl okay, Coke.
NotFound Even if I manage to avoid the codestring being marked, the buffers are not freed until the second sweep. 19:07
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.
Coke is our gc too lazy?
NotFound: I'm not sure that behavior is actually required anywhere.
going to yapc::na 2010 is also colomon 19:09
purl okay, Coke.
NotFound I think this problem wants an architect's eye.
The args and the return must be freed at some point, but I don't know what point. 19:10
And the second sweep frees them even without any fix, so they get freed at some other point %-) 19:12
Coke msg allison & chromatic - if you could check out TT #1603, that'd be spiffy. 19:13
purl Message for allison stored.
Coke msg chromatic & allison - if you could check out TT #1603, that'd be spiffy.
purl Message for chromatic stored.
allison Coke: ok 19:18
Coke allison: sneaky!
trying to speed up codestring in a branch, but even in trunk, it seems to be hanging on to things longer than needed. 19:19
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
NotFound The interesting part is that the codestring is marked in the first sweep, but not in the second. 19:22
Coke er, 2nd and 3rd? 19:24
(the first one was a baseline.)
NotFound Ah, yes.
Coke allison: (not sweeping) - but we're forcing the sweep in the example. 19:28
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
Coke: seems unlikely here, since the 3rd is catching i
Coke allison: that doesn't seem very optimal. =-) 19:36
allison Coke: it is if sweeping is expensive :) 19:37
NotFound Looks to me that on the contrary, usually parrot is doing too much sweeps. 19:40
allison NotFound: aye, highly likely 19:41
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. ;)
It might be helpful to put up a wishlist on the wiki. 19:43
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
And I fail to locate a point where safely clear the positional returns.
allison NotFound: returns only exist during the life of the call 19:46
NotFound: that is, they live in the call context, so as soon as that's gone, they disappear 19:47
NotFound: but they won't be swept while the call context is still active
NotFound allison: not if a pointer to the callee context is retained somewhere on the caller. 19:48
allison NotFound: aye
NotFound: so, try this...
NotFound: put a call to some other subroutine before that 2nd sweep 19:49
NotFound allison: that was the first thing I do.
allison NotFound: the call context is stored in the caller
NotFound: and?
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
19:50 hicx174 joined
NotFound No, the buffers aren't disposed, but the codestring mark vtable is not hit. 19:54
Without that call, the vtable mark is hit on mark_positionals(INTERP, SELF); at CallContext mark. 20:07
Which itself gets called as current_sig on the interpreter current context. 20:08
20:14 jsut_ joined
dalek kudo: d12eed6 | moritz++ | t/spectest.data:
run S06-operator-overloading/sub.t
 20:16
rrot: r46200 | fperrad++ | trunk (4 files):
[osutils] add catfile() & splitpath()
 20:22
20:33 eternaleye joined
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
s/freed/put in the free pool/
20:54 eternaleye joined
dalek rrot: r46201 | fperrad++ | trunk (5 files):
rename Archive/TAR to Archive/Tar
 20:55
21:01 eternaleye_ joined 21:03 rurban_ joined
sorear Coke: Where is this "feedback"? Is there a secret parrot-commits-replies@ list that's not mentioned on mailman? 21:15
moritz huh? people usually reply to commit messages on parrot-dev 21:16
sorear huh. I missed it. 21:21
moritz because it's secret :-) 21:22
21:25 fperrad joined
dalek tracwiki: v4 | cotto++ | UsingGitAndSvnInTrac 21:43
tracwiki: expand and organize
tracwiki: trac.parrot.org/parrot/wiki/UsingGi...ction=diff
cotto_work I'd appreciate feedback on that plan (as much as is planned, at least). 21:44
bacek ~~ 21:48
cotto, good plan
sorear as an outsider, nothing leaps out at me as revoltig 21:51
cotto_work high praise 21:53
allison: ping 22:04
22:04 donaldh joined
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:04
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
cotto: pong
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!
donaldh irc://irc.freenode.net/#perl6
allison I still hate it, and every time someone tries to demo how great git is, it breaks.
donaldh sorry 22:08
allison It ain't robust, stable, reliable, easy for newbies...
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
allison But, moving the whole project to it is... big
cotto_work I feel the same way about svn right now.
allison and, as far as I can tell, the move is entirely unnecessary 22:10
so, work in git
just use svn as the store
cotto_work you mean git-svn?
allison git-svn gives you a connection point, but from there you can just use the standard git workflow 22:11
I'm totally fine with people using git branches instead of svn branches
(instead of trying to manage svn branches through git, which is nutty) 22:12
cotto_work and applying them as a single big diff?
sorear every branch merge in svn is a single big diff 22:13
allison sure, why not
sorear svn merge is just a thin layer over "svn diff" and "patch"
with a smidge of logic to stop you from applying the same rev's diff twice
allison if we ever rolled it back, we'd want to roll it back as a unit
sorear: yup, that's one of the things I like about svn
it's clean 22:14
allison hears minds reeling in the background 22:15
cotto_work yes, you do
Coke ... clean is not a word I would use to describe svn's branching and merging. =-)
allison: have you seen github's "use this git repo via svn" interface? 22:16
it's like svn-git.
(as opposed to git-svn) 22:17
bacek (merging with git) You can rollout git merge as single unit. Just always merge with --no-ff. 22:20
22:20 chromatic joined
cotto_work just in time 22:21
chromatic -1 to svn, solely for its difficulty of branching and merging
allison cotto: I'm not quite clear on why the devs who like git are still bothering with svn branches
cotto: can you explain?
or chromatic or Coke 22:22
bacek because it's only one official way to share work
cotto_work yeah
allison no, we changed that
we officially blessed git branches
cotto_work de jure, yes. De facto, meh
allison cotto: explain? 22:23
as in, why isn't it being used?
(this is important, as git branches were the "toe in the water" for testing git)
Coke allison - I'm using svn branches because I wish to share my work with others.
allison: ... what? 22:24
purl Yada yada yada hasn't been implemented yet! (unless you run bleadperl)
chromatic Out of repository is out of mind.
cotto_work It might just be a bootstrapping issue (nobody's using them because nobody's using them), but ... what he said.
allison but, that's how git branches work
chromatic No it isn't.
purl oh yes it is!
allison everybody has their own, and share patches back and forth
Coke I love you, purl.
purl Coke: what?
allison that's what it was designed for
bacek no
it is not
chromatic A profile of building Rakudo's core.pm with trunk wgz.org/chromatic/tmp/rakudo_gen_core.cg.bz2 22:25
allison "Distributed Version Control"
distributed
purl distributed is definitely the way to go, it's what sets IRC apart from other chat things
Coke so, chromatic, you clobbered my working changes with your codestring updates. I like mine better. Any feedback?
bacek not "Local Patches Sharing Thingy"
Coke no, purl, distributed is <reply>
purl okay, Coke.
chromatic Coke, you're trading long-lived GCables for avoiding short-lived string header and buffer allocations. 22:26
sorear chromatic: 403
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.
Take away the centralized repository without changing all of those dependents and they break.
perms fixed on the file, by the way
allison chromatic: I agree on smolder 22:29
chromatic: sharing code and collaborating can go either way
chromatic Certainly they can change, but I'm only describing how things work now.
allison at the moment, I certainly find it easier to pull a clean diff of a branch in svn than git
for code review
chromatic That's because you don't know how to use git. 22:30
bacek git checkout <branch>; git diff master
allison no, I got a git expert to pull it for me, remember?
and got some 12k lines of diff
chromatic I'm not a git expert by any means. I learned how to use it is all.
22:30 davidfetter joined
allison if I saw a compelling advantage to git, I'd be there in a heartbeat 22:31
chromatic Branches and merges work.
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
(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?
allison I get that a handful of people love git
I understand, I accept
well
I don't understand *why*
but I understand that it is important to them 22:33
you
sorear probably these people don't have commit bits
allison whatever
purl whatever is easiest to type
bacek Because git is fast. And it just work
allison git is slow
I mean, it's doing a lot more work with a git pull than an svn update is doing
so, it's not a fair comparison 22:34
chromatic I don't even know how to respond to that.
allison I'm just saying that it's fair that it's slower 22:35
not a dis
chromatic Not true, either.
But even if it were true, it's irrelevant to my point, and likely irrelevent to bacek's point. 22:36
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.
allison well, he offered speed as an advantage
chromatic Speed *is* an advantage.
allison not really 22:37
chromatic You don't know how to use Git. How can you say this?
allison I don't understand why people are having so much trouble with svn branches
mine always merge cleanly
chromatic None of the rest of us can get them to merge cleanly.
allison maybe I have some deep mystical svn foo, but somehow I doubt it
it's just too dead simple 22:38
bacek Just because sometime you have to recreate new branch.
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.
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.
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.
allison will you at least look at Mercurial or Bazaar?
they're so much nicer than git
chromatic I've used hg.
Meh. 22:40
allison elaborate?
chromatic It's slower than git, and it didn't do anything substantially better than git for me to want to switch to it.
allison what I'd really like, is to move to bazaar running on parrot
really, really 22:41
bacek what for???
purl for fun.
allison eat our own dogfood 22:42
have a real practical project on parrot, that we're motivated to support
bacek It's not _our_ dogfood.
allison it would be if it was running on parrot
bacek Oookey.
Let's port Ruby and migrate to redmine. 22:43
chromatic If we ported Bourne shell, we could migrate to tla.
bacek Then we will have " real practical project on parrot, that we're motivated to support"
cotto_work I see charm in dogfooding but that sounds a lot like making a technical decision for a non-technical reason.
chromatic Does Trac have bzr plugins, out of curiosity?
cotto_work I think I saw some. 22:44
allison that's not the reason for the decision, it just a by-the-way
bacek it should have
cotto_work I didn't bother testing them.
chromatic Any chance the bzr plugins have the support or maturity of the git plugins?
cotto_work possibly. The git plugin is labeled as alpha.
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
git may be great in a year or two
(it has potential)
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.
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.
cotto_work It's not a huge change for Trac afaict.
Coke allison: and svn might be usable in another decade.
bacek Mua-ha-ha *cough*, GUI, *cough* 22:47
sorear I wonder if allison used github
bacek Linux, Perl5, Rakudo, 90% of languages on parrot uses Git.
allison sorear: yes
bacek Git is definitively *immature* for all this projects. 22:48
22:48 Whiteknight joined
allison what I would like to see is more developer workflow in git 22:48
cotto_work hio Whiteknight.
Whiteknight hello cotto_work
chromatic What do you mean by "developer workflow"?
cotto_work like the ones on the wiki?
allison chromatic: basically, git branches rather than svn branches
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
chromatic: I don't understand that
chromatic: if testers aren't willing to use git now, why would they be any more willing if we switched?
chromatic It's not a matter of willingness. It's discoverability. 22:50
allison we have to send around the name of the branch
chromatic and the location
purl You are in a maze of twisty passages, all alike.
allison a link isn't really more trouble
chromatic and its existence
And I know how this song ends.
22:51 plobsing joined
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!"
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)
allison I'm a skeptic, what can I say
I like cold, hard proof
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
bacek www.parrot.org/content/straw-poll-w...parrot-use
allison a little better in some things, a little worse in others
chromatic I can imagine, if you still think that SVN is faster than Git.
allison it just doesn't seem worth the pain of a transition
bacek Erm... What other reasons do we need?
cotto_work it's a longer process to check out a svn branch thana git branch
allison cotto: that I believe
cotto_work svn is causing enough pain right now that it's worth the transition 22:53
allison (copying individual file)
what pain?
purl hmmm... pain is spelt "pain"
allison I feel no pain
bacek usually works on 3-4 branches
allison and maybe that's the problem
chromatic I usually work on a handful of branches.
bacek And switch between them in seconds.
allison (I mean, maybe that's the reason for my skepticism)
chromatic Less than seconds.
allison bacek: I do too, and do a build on one while I'm working on the other 22:54
bacek In same checkout???
allison bacek: I don't *want* them in the same directory
bacek heh...
nice...
No more questions.
One size fit all solution ftw.
allison that'd be nice 22:55
chromatic He's being sarcastic.
allison maybe our next project will be a revision control system
allison groans at the thought
chromatic I'll say this. I'm never going to merge another branch with SVN again. 22:57
allison so, do it with git
chromatic I'm going to warn other committers against merging branches with SVN.
allison I'd warn them against using whatever merging strategy it is that's causing the problem 22:58
chromatic svn merge
purl svn merge is probably really losing :/
allison svn merge just makes a diff
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
it makes no sense
chromatic That's what I'm saying.
cotto_work and fails to account for files added to the parent since the last merge
chromatic Oh yeah, I forgot about that.
allison but presumably, people review their merges before they commit? 23:00
and can revert unintended changes?
I would expect them to do that with git too
chromatic Don't forget renamed files, those are awful! 23:01
allison those I agree on
I didn't ever see the demo I asked for on git with that feature
sorear yeah and git has no rename handling at all 23:02
chromatic Because git doesn't need rename handling.
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.
sorear git is about points, it doesn't handle edges at all
allison cotto: branch review isn't just about that, it's about code quality
someone should be reading through a diff of every branch before it goes into trunk 23:03
someone other than the main developer of the branch
chromatic That's what commit mail is for. 23:04
... except that's another piece of infrastructure we lose with git-only branches.
sorear Is chromatic arguing for or against git?
allison except for the merge back into trunk
sorear: he's arguing against a partial move 23:05
sorear: against git process on top of svn
I suspect git has some way of doing commit mail
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."
cotto_work Getting the message only after the branch is merged negates some of the benefits of working in a branch. 23:06
allison git branches can be set up to email the parrot-commits list 23:07
(if they can't, then we have a deeper problem)
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.
allison looks to me like Github provides default post-commit hooks including email 23:10
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:12
I notice two things. 23:13
First, that's a bit of ceremony.
allison that's pretty much git in a nutshell, as far as I can tell
chromatic Second, Git makes all of that possible -- reasonably easy, actually.
23:14 jan joined
allison I'm with sorear on this one, I can't tell what position you're arguing for anymore 23:14
chromatic You can't do anything like that with SVN. 23:15
allison why would you want to?
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.
sorear there are really two questions here
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
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.
sorear 2. is decentral web a better workflow for us than single hub?
23:16 atrodo joined
allison sorear: that's a good clear way of putting it 23:16
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/ =-)
allison Coke: there was general agreement at the time, probably because the memory was still fresh
(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
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
sorear: (an advantage shared by other DVCS) 23:20
cotto_work The it doesn't need to be argued.
*then
Coke let me rephrase this debate: is there anyone other than allison who doesn't want to move to git?
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
chromatic Why does that surprise you? That's not a painful thing for committers, and this is a discussion for committers.
allison Coke: there's a lot of people who are concerned about the change
Coke allison: All I hear is you.
chromatic Coke, kid51 doesn't want to move to Git either.
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.
allison I'm just vocal
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.
allison yes, I think you're right
Coke allison: you could be projecting.
certainly there's a lot of developers who don't want to argue with you about this because you're the architect.
allison chromatic: probably even true for most people who are averse to the idea 23:23
but remember that we're dealing with volunteers here, and discomfort drives people away
Coke allison: Yes. That's a good thing for all of us to remember.
chromatic So does a repository which says "Your patches aren't first-class citizens."
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?
bacek 2/3 of our developers _want_ to switch to git.
allison Coke: I haven't seen much hesitation in arguing ;)
Coke speaking of discomfort - see you guys later. 23:25
23:25 Coke left
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?
I'm still open to the idea
bacek Our front-end devs use Git without any problems.
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
s/have/has/
allison yes, but replacing it with a system that's still biting people
and has the potential to do more damage
I wish I could see it 23:27
chromatic Are you volunteering to merge svn branches now?
bacek Can you prove that "git has the potential to do more damage"???
allison bacek: it allows you to edit prior commits
bacek yes, so what?
chromatic I use that all the time. It's a useful feature.
allison which means a mistake can trash the entire repository 23:28
bacek Until it's pushed you can do whatever you want.
allison all the way back in time
bacek no
it can trash _your_ copy of repo
chromatic and only if you let it
allison and push it up
chromatic no
bacek and git-deamon will reject it
sorear every copy of the repo contains the entire history, and a cryptographic hash of the entire history 23:29
not only will other contributors have a backup, but they will know *immediately* that something is wrong
because the non- --force'd push will fail
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
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'
allison are there different permission levels for git 23:32
sorear that doesn't affect history
bacek are there different permission levels for svn?
sorear, ssh sv.parrot.org; rm -rf /var/lib/svn; 23:33
chromatic Sure, but you can disable forced fastforwards too.
sorear I think allison is talking about git reset --hard e927c24 # that's r1 in our git-svn ; git push --force --mirror
allison I'll tell you one thing that I *do* like about moving to git
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.
allison (there are others with access, but we do the admin work)
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.
allison (of course, that'd be the same on hg too)
sorear I'd like to argue against github
It has an abysmal uptime record
allison bacek: you don't do any admin on that server? 23:36
cotto_work That's not as important for a dvcs
bacek no one do.
allison bacek: never think about updime, upgrades, etc
uptime
cotto_work It'll be a minor annoyance. that's all.
bacek Apart from adding more repos.
allison installing the latest version of git?
cotto_work (not saying anything for/against github)
allison making sure all the repos are compatible with the latest version?
bacek allison, it's still running 1.5.something.
And I'm running 1.6.something 23:37
And they all compatible.
Welcome to modern world of non-braking changes.
allison bacek: probably time for an upgrade
bacek It's not bloody svn when update on central server require syncronous update of clients.
allison, no. We don't need it.
chromatic sidebar! 23:38
purl i heard sidebar was too big.
bacek It's just central storage.
chromatic allison, if we disabled the possibility of rewriting history on the central Git server, would you feel more comfortable?
bacek Clients can be updated. "Server" can stay
allison chromatic: yes
chromatic I believe that's a trivial configuration option.
allison (which is not to say "entirely comfortable", but a significant improvement) 23:39
chromatic I also believe it even disables the --force behavior.
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
I can learn anything, I've got an Einstein-level IQ
but, I'm very conscious of the fact that I'm strange
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
a *huge* difference
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.
allison I want to know our devs can make the transition painlessly
and I don't mean the early adopter types
(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
chromatic Hardly! I didn't want Rakudo to move to Git.
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
allison git has so many exceptions to the rule
Whiteknight and svn has so many known problems that need to be avoided
allison Whiteknight: but it's usually only advanced developers that run into them
Whiteknight: by which point, they can handle a little variation 23:45
cotto_work doing advanced things like merging branches?
chromatic renaming files
checking out branches
Whiteknight I've been bitten by file-renaming commits without branches before
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
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!
allison sorear: our disadvantage there is not using distributed techniques
branch merging on git is *not* for the newbie
bacek allison, it is.
cotto_work Will a newbie be doing something that necessitates a branch then?
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.
allison a recursive revert is sufficient to handle any mis-merge in svn
chromatic Ha.
allison with git, I've had to blow away my entire local copy
bacek never blowed away local git repo. 23:48
chromatic Ditto.
allison it can't even handle an update if I have local changes
just barfs
chromatic Shenanigans.
purl Come on in to Shenanigans, Indiana's Premier "Couples Only" Club!
bacek git stash; git pull; git stash apply;
_done_ 23:49
allison and that's more friendly to newbies than 'svn update'?
chromatic Though why you'd update with local uncommitted changes is odd.
allison so I can test them on the latest version before committing
chromatic That's what local branches are for. 23:50
allison (really, the thought of committing something before testing it hurts my stomachh)
bacek That's why you don't use git.
In git you always commit changes.
allison so you can commit a pile of stuff that might not actually work?
sorear the git-standard way to test is between 'commit' and 'push'
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.
sorear if the tests fail, commit --amend
allison hears fingernails on a chalkboard
chromatic Hang on, you're all confusing the issue.
Git doesn't force you to do that, allison.
allison I welcome all beliefs
sorear (this bugs me too)
allison it's fine
chromatic You can still use your own workflow.
I don't commit before testing, myself.
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
chromatic Sure.
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
Then you pull.
That implicitly rebases your changes to the remote HEAD.
Then you can test.
If you're happy, you can push.
bacek (rebase) it will not do it implicitely.
chromatic I know, I'm sort of lying to explain things. 23:54
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.
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
chromatic No one is saying "Push your commits before testing."
allison I have a chess-player brain, and I'm always thinking 7 steps ahead 23:56
one possibility is that we make the transition, it all goes smoothly, no trouble
everyone keeps on developing without a hitch
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
another possibility is just low-grade annoyance
chromatic We already have the latter.
allison no outright revolt, but sullen disgust, motivating early departures from the project 23:59
chromatic: I don't see it, commits are high, branches are progressing and being merged

Powered by Cro and the Raku® Programming Language.

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

Thank you!