Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-08

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 Whiteknight let me look
00:00 jrtayloriv If it did, I'm sorry. I meant to commit the changes to the branch, just to sync up with trunk.
00:00 Whiteknight nope, you're good
00:01 Whiteknight on a related note, I'm having trouble loading trac.parrot.org
00:02 nopaste "darbelo" at 200.49.154.172 pasted "Happines for Whiteknight++, All tests pass. next_for_gc is one step closer to death." (279 lines) at http://nopaste.snit.ch/17876
00:02 jrtayloriv SVN has been causing problems for me for hours. This is the first time I've been able to do the merge since about 5 hours ago.
00:02 jrtayloriv trac is on the same server right?
00:02 Whiteknight darbelo: so no commit bit?
00:03 Whiteknight jrtayloriv: yes, same server i believe
00:03 darbelo Whiteknight: No CLA yet :)
00:03 Whiteknight darbelo: mind if I commit this patch then (after a little local testing)?
00:04 dalek parrot: r41144 | whiteknight++ | trunk/src/gc/gc_private.h:
00:04 dalek parrot: [gc] remove the #ifdefs that specially handle the fixed-size allocator on Windows. It's been working on that platform for a while now. This commit resolves TT #940
00:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41144/
00:05 * darbelo forgot to label his patch "Commmit only after testing, may contain breakage"
00:05 jrtayloriv Whiteknight, I'm seeing a bunch of messages in the changeset that look say "Property svn:mergeinfo changed" ... Is that a problem?
00:05 Whiteknight jrtayloriv: no, not in general
00:06 jrtayloriv ok
00:08 Whiteknight darbelo: patch applies cleanly and tests fine on my system.
00:08 Whiteknight I'll commit now (and then get to work on the GC stuff to remove the rest of it)
00:09 darbelo Cool. Let me know if you want help with that.
00:09 * darbelo likes to remove stuff.
00:09 Whiteknight darbelo: Send in a damn CLA already!!
00:10 darbelo Heh. Working on it.
00:11 Whiteknight jrtayloriv: if I remove next_for_GC, will that mess up your work?
00:11 jrtayloriv Whiteknight, Shouldn't.
00:11 dalek parrot: r41145 | whiteknight++ | trunk/src/pmc_freeze.c:
00:11 dalek parrot: [gc] remove references to the PMC field next_for_GC from src/freeze.c. Patch courtesy darbelo++
00:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41145/
00:11 bacek Whiteknight: remove it. I'll help with fixing if anything will break.
00:12 Whiteknight okay, I'm ack'ing all references to it now
00:12 jonathan Is it me, or are PMCs shrinking lots? :-)
00:13 darbelo Whiteknight: You forgot to run the headerizer.
00:13 rhr joined #parrot
00:13 jonathan morning, btw :-)
00:13 * jrtayloriv goes for a walk with the dog ... be back in a bit!
00:13 zerhash joined #parrot
00:13 Whiteknight damnit
00:13 japhb pmichaud, how do I create an executable from an NQP?  I was using 'parrot $NQP_PBC --target=pir -o foo.pir foo.nqp; parrot -o foo.pbc foo.pir; pbc_to_exe foo.pbc', and that does produce an executable -- which doesn't work, because it can't find the NQP builtins (my test file is just doing a say() call)
00:14 Whiteknight good morning jonathan
00:15 jonathan Whiteknight: Ah, you figured out what that field is for?
00:15 * jonathan never quite got it..
00:15 jonathan Looks like now I'll never have to.
00:15 Whiteknight jonathan: I didn't darbelo did. Apparently it isn't used for anything
00:15 jonathan lol
00:15 Whiteknight It was used for two different things in two different places. In the GC it was a half-hearted attemp to add priority marking
00:15 jonathan I hadn't actually considered that option.
00:16 * jonathan shoulda known better
00:16 Whiteknight in the freeze/thaw system it was an awful code obfuscation attempt
00:17 darbelo Whiteknight: Should Parrot_gc_cleanup_next_for_GC() die along with next_for_GC or does that need a deprecation cycle?
00:18 mikehh wrok?
00:18 Whiteknight darbelo: where is that function defined?
00:18 dalek parrot: r41146 | whiteknight++ | trunk (2 files):
00:18 dalek parrot: [gc] make headerizer after my last commit like I should have. darbelo++, again
00:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41146/
00:18 mikehh bacek wrocks
00:18 dalek parrot: r41147 | mikehh++ | trunk/include/parrot/context.h:
00:18 dalek parrot: fix codetest failure - unerapped macro argument
00:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41147/
00:18 mikehh dammit e instead of w
00:19 darbelo src/gc/api.c along with a few relatives.
00:19 jonathan .oO( a c woulda been worse )
00:19 mikehh * must check typing more carefully
00:20 darbelo Basically it walks the pools doing "PMC_next_for_GC(p) = PMCNULL" to undo whatever shit the freeze code did there.
00:21 jonathan omfg
00:21 jonathan That sounds..."efficient"
00:21 Whiteknight s/efficient/retarded/
00:22 Whiteknight I dont doubt that at one point it was used for great things
00:22 Whiteknight but now it's a huge waste of time and code space
00:23 bacek_at_work Bah! :)
00:26 japhb Anyone know how to create an executable from NQP source?  (See my question ~12 minutes ago)
00:28 darbelo Well, looks like Parrot_gc_cleanup_next_for_GC() is amputable too. I get the feeling that function was there only to return the gc system to oprating condition after the freeze code was done.
00:29 darbelo I'll wait for coretest to finnish and nopaste a patch.
00:31 hudnix joined #parrot
00:32 kid51 joined #parrot
00:33 jonathan japhb: The steps you described should work, but I suspect it's a library loading issue (the load ain't making it into the executable or some oddness); does the PBC work?
00:33 jonathan BTW, somebody building Rakudo just got this Parrot build fail: http://paste.lisp.org/display/86734
00:33 japhb jonathan, checking
00:33 jonathan (Platform: OS X)
00:34 japhb jonathan, nope, not even the pir
00:34 japhb so clearly the pir is broken somehow.
00:34 * japhb reads ...
00:35 Whiteknight darbelo: way ahead of you
00:35 japhb Wow, that's ... minimalist
00:35 Whiteknight I've already ripped that function out
00:36 jonathan japhb: Hmm. I guess it maybe is missing a load_bytecode directive or something.
00:37 nopaste "japhb" at 76.191.190.8 pasted "The sum total of the PIR file generated from NQP 'say("Hello there!")'" (6 lines) at http://nopaste.snit.ch/17877
00:37 Whiteknight damnit, test failures already
00:37 jonathan japhb: Nice! :-)
00:38 jonathan japhb: But I fear it may be missing something to load the NQP built-ins.
00:38 darbelo Whiteknight: You look like you know what you are doing, I'll leave the rest to you.
00:38 darbelo :)
00:39 dalek partcl: r698 | coke++ | trunk/docs/spectest- (2 files):
00:39 dalek partcl: spec test with new parrot; 2% slowdown...
00:39 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=698
00:39 nopaste "Whiteknight" at 69.249.176.251 pasted "kill next_for_GC patch for bacek++ and darbelo++" (441 lines) at http://nopaste.snit.ch/17878
00:40 Whiteknight darbelo: take a look at the nopaste. parrot builds but fails some tests and seems to hang on one of them
00:40 Whiteknight so I might not know as much as I thought I d
00:40 Whiteknight did
00:41 darbelo Whiteknight: what tests?
00:41 purl WRITE THE TESTS FIRST DICKBRAIN, yeah, I'm talking to you darbelo
00:42 Whiteknight I don't know. A bunch
00:42 Whiteknight it froze on t/pmc/float.t
00:43 Whiteknight a lot of segfaults in t/pmc/object.t
00:43 Whiteknight purl forget what tests
00:43 purl Whiteknight, I didn't have anything matching what tests
00:43 Whiteknight purl forget what tests?
00:43 purl Whiteknight, I didn't have anything matching what tests
00:43 japhb purl forget what tests\?
00:43 purl japhb, I didn't have anything matching what tests\
00:43 japhb purl forget what tests\\\?
00:43 purl japhb, I didn't have anything matching what tests\\\
00:44 japhb purl forget 'what tests?'
00:44 purl japhb, I didn't have anything matching 'what tests?'
00:44 japhb sheesh
00:44 darbelo It's probably special-cased.
00:48 japhb jonathan, pmichaud: found a workaround for the NQP executable problem: add this line at the top of the source file: Q:PIR{load_language 'nqp'};
00:52 jrtayloriv purl: "What tests" is "Sorry I couldn't study for the test, my grandma died"
00:52 purl OK, jrtayloriv.
00:52 darbelo What tests?
00:52 purl You succeed.
00:52 darbelo What tests?
00:52 purl You fail.
00:52 darbelo What tests?
00:52 purl WRITE THE TESTS FIRST DICKBRAIN, yeah, I'm talking to you darbelo
00:52 darbelo What tests?
00:52 purl http://dev.catalyst.perl.org/wiki/Testing
00:54 Whiteknight hmmm, it appears next_for_GC is doing more then I thought
00:55 treed What tests?
00:55 purl You barely pass.
00:55 treed Heh.
00:55 treed Tests?
00:55 purl WRITE THE TESTS FIRST DICKBRAIN, yeah, I'm talking to you treed
00:55 treed tests
00:55 treed Tests
00:55 treed ests?
00:55 treed tests?
00:55 purl WRITE THE TESTS FIRST DICKBRAIN, yeah, I'm talking to you treed
00:55 treed Hm.
00:55 treed tests? some other text
00:56 darbelo I din't break it. I get to sleep with a clear consience.
00:56 * darbelo goes to catch some Z's
00:56 Whiteknight goodnight
00:57 darbelo left #parrot
01:09 dukeleto should this be so? : push_integer() not implemented in class 'FixedPMCArray'
01:10 TiMBuS joined #parrot
01:11 treed I wouldn't expect push_* to be implemented in Fixed*Array.
01:11 treed But, I'm pretty new here.
01:12 Whiteknight treed: you can push up to a fixed size
01:12 treed Huh.
01:12 treed Okay.
01:16 Whiteknight what type number is Null PMC?
01:16 Whiteknight is it 0?
01:19 Whiteknight purl msg darbelo We can't remove next_for_GC. it's necessary in the GC
01:19 purl Message for darbelo stored.
01:25 jrtayloriv bacek_at_work, I will be going to bed in an hour or two, but just wanted to let you know that I sync'ed up the gc-refactor branch with trunk. Thanks again.
01:25 Whiteknight jrtayloriv: I'm going to look the branch over tomorrow morning before #ps too
01:25 Whiteknight On the east coast, it's bedtime now :)
01:26 bacek_at_work jrtayloriv: yeah, thanks
01:26 jrtayloriv Whiteknight, thanks
01:27 Whiteknight np. Goodight
01:27 jrtayloriv night
01:27 mikehh purl msg darbelo - that patch fails to build on i386 - src/jit_debug.c -src/jit_debug.c: In function ‘void write_types(FILE*, parrot_interp_t*)’: - src/jit_debug.c:172: error: ‘INTERP’ was not declared in this scope - make: *** [src/jit_debug.o] Error 1
01:27 purl Message for darbelo stored.
01:29 mikehh purl msg darbelo - it's also in src/jit_debug_xcoff.c though I didn't get that far
01:29 purl Message for darbelo stored.
01:31 mikehh All tests PASS (pre/post-confif, smoke, nqp_test, fulltest) at r41147 - Ubuntu 9.04 i386
01:32 mikehh s/confif/config/
01:32 pdcawley_ joined #parrot
01:35 dalek parrot: r41148 | dukeleto++ | trunk/t/pmc/fixedpmcarray.t:
01:35 dalek parrot: [t] Convert t/pmc/fixedpmcarray.t to PIR and add tests
01:35 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41148/
01:36 sri joined #parrot
01:37 sri joined #parrot
01:46 mikehh partcl r698 builds on parrot r41147 - make test PASS - Ubuntu 9.04 i386 (g++)
02:12 dalek parrot: r41149 | dukeleto++ | trunk (2 files):
02:12 dalek parrot: [TT #991] Throw an exception when the creation of a negative length FixedPMCArray is attempted and prevent core dump
02:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41149/
02:15 dalek TT #991 closed by dukeleto++: Parrot dumps core when attempting to create a FixedPMCArray with negative ...
02:16 Andy joined #parrot
02:35 janus joined #parrot
02:36 dukeleto this is usually bad, right? : parrot(23876) malloc: *** error for object 0x4500200: non-page-aligned, non-allocated pointer being freed
02:41 cotto that doesn't sound like an expected behavior
02:44 dukeleto cotto: what is supposed to happen when you eval code that has a :vtable method?
02:46 cotto good question.
02:46 purl Yeah, it is. I'm stumped.
02:46 cotto what tries that?
02:49 dukeleto cotto: me :)
02:50 dukeleto incoming!
02:50 purl rumour has it incoming is https://pause.perl.org/incoming/
02:51 cotto dukeleto, what happens when it's a valid vtable?
02:52 dalek TT #992 created by dukeleto++: Memory errors when evaling :vtable methods
02:52 dukeleto cotto: i am not sure, since i don't eval the code that doesn't generate exceptions. i can try that tho'
02:54 dukeleto cotto: could be the implementation of throws_like(). how does a namespace declaration effect surrounding code when it is eval'ed ? if I eval code that changes the namespace, do I have to change the namespace back?
02:57 dukeleto removing the namespace line makes the test pass
02:59 cotto I don't understand the eval process well enough to say
03:14 beta left #parrot
03:25 sri_ joined #parrot
03:29 Andy joined #parrot
03:51 dukeleto i am falling into all kinds of yakholes tonight
04:03 jrtayloriv I am falling into all kinds of sleep right now -- night night.
04:03 * jrtayloriv zzzzzzzzzzzzz
04:04 jhelwig joined #parrot
04:16 dalek TT #993 created by dukeleto++: attempt to access code outside of current code segment in vtable init ...
04:27 bacek_at_work dukeleto++ # Just don't forget to add this bugs as proper tests!
04:27 dukeleto bacek_at_work: don't worry
04:27 cotto dukeleto++ #if you find them now, other people won't find them later
04:29 dukeleto bacek_at_work: they are all test cases in my translation of t/pmc/parrotobject.t
04:40 bacek_at_work dukeleto: it's good idea to add them also explicitly. It "t/pmc/parrotobject.t" will be changed in future we still will have coverage for such regressions
04:46 dukeleto bacek_at_work: yeah, it looks like i m not going to translate all of parrotobject.t
05:19 ttbot joined #parrot
05:19 mj41 joined #parrot
05:30 Tene Okay, I want to move SQLite3.pir into runtime/parrot/library/ so that it can be installed and used, etc.
05:30 Tene it's currently in ext/SQLite3/
05:30 Tene There's some other stuff in there that I don't know what to do with...
05:30 Tene So I think I'll just copy it, I guess.
05:41 dalek parrot: r41150 | tene++ | trunk (2 files):
05:41 dalek parrot: [library]
05:41 dalek parrot: * Move SQLite3.pir from ext/ to library/ so it can be installed
05:41 dalek parrot: * I'm not sure what to do with the leftovers still in ext/SQLite3/
05:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41150/
05:42 shockwave joined #parrot
05:43 shockwave From an embeeding up, is it possible to grab a reference from a class created in a HLL and call methods of that class?
05:54 jonathan Should be, yes.
05:54 jonathan To create an instance call VTABLE_instantiate
05:54 jonathan And then you can use VTABLE_find_method to get hold of the method, and then one of the run_meth calls (forget the name exactly) to run the method that find_method hands back.
05:55 shockwave @jonathan, thanks alot. That's the info I needed.
05:57 jonathan Welcome. :-)
06:14 masak joined #parrot
06:16 fperrad joined #parrot
07:12 cotto Running the profiler in a profiler is fun, but I have to wonder if there aren't quite enough layers involved.
07:19 chromatic joined #parrot
07:19 cotto chromatic, is there anything wrong with breaking the profiling runcore out into its own file?
07:21 chromatic There should be no problem at all.
07:22 cotto excellent.
07:25 cotto now for the customary infrastructure wrestling
07:33 iblechbot joined #parrot
07:41 cotto This isn't quite as painful as I was hoping.
07:47 chromatic Happy birthday.
07:47 purl for (('to you', 'dear '.shift)[0,0,1,0]) { print "Happy birthday $_" }
07:47 shockwave When compiling a HLL, is it recommended or expected to compile all to one file?
07:48 dalek rakudo: a0c8a44 | moritz++ | C (2 files):
07:48 dalek rakudo: [build] fix \ to / in paths passed to parrot's Configure.pl
07:48 dalek rakudo: Patch courtesy by azawawi++. Also fix up his CREDITS entry
07:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​0c8a44eb4f1578f03bd7d521ee91ee75581a0a0
07:50 chromatic I'd try to build it all into one file, shockwave.
07:51 jonathan Aye. Then a thingy.pbc can be installed.
07:51 shockwave @chromatic, to be honest, that actually works a bit better for me. But doesn't that cause problems if my HLL app has tons of files and it assembles into a 10 meg file (I'm exagerating, but you...)
07:52 jonathan shockwave: Rakudo runs to a 4MB PBC file at the moment.
07:52 jonathan shockwave: And doesn't cause us any problems.
07:52 moritz and rakudo is not small[tm]
07:52 shockwave Rakudo is a compiler?
07:53 jonathan Rakudo is a Perl 6 on Parrot compiler.
07:53 jonathan The 4MB includes the "standard library" as well I guess.
07:53 cotto there we are
07:54 cotto easy as pi
07:54 dalek parrot: r41151 | cotto++ | trunk (4 files):
07:54 dalek parrot: [profiling] split the profiling runcore code into separate C and header files
07:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41151/
07:55 shockwave Like I mentioned, I like the idea of assembling the HLL into only one file. But, just for curiosity: I've been looking in the examples directories and I haven't seen a way to load external PIR code from within some .pir file. Is it possible?
07:55 jonathan .include "foo.pir"
07:55 shockwave sweet. Thanks.
07:57 dalek parrot: r41152 | cotto++ | trunk/MANIFEST:
07:58 dalek parrot: [MANIFEST] update manifest after profiling runcore split
07:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41152/
08:14 chromatic cotto, we need to make sure to install the profiling rewriter tool with install-dev at least.
08:26 cotto chromatic, agreed.  I don't know how to do that.
08:27 jonathan iirc by editing some manifest file.
08:31 moritz MANIFEST.generated, iirc
08:31 chromatic It's not a generated file though.
08:33 moritz uhm, simply add a [devel] in front of it in MANIFEST? (just guessing here)
08:34 chromatic I think that's right.
08:35 cognominal joined #parrot
08:40 dalek parrot: r41153 | chromatic++ | trunk/MANIFEST:
08:41 dalek parrot: [project] Added pprof2cg.pl to [devel] files in MANIFEST so that it gets
08:41 dalek parrot: installed.
08:41 purl somebody said installed was easy as well.
08:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41153/
08:41 dalek parrot: r41154 | mikehh++ | trunk/runtime/parrot/library/SQLite3.pir:
08:41 dalek parrot: set svn properties
08:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41154/
08:48 cotto chromatic, thanks
08:49 moritz purl: ignore dalek
08:49 purl moritz: i'm not following you...
08:49 moritz you should.
08:53 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41153 - Ubuntu 9.04 i386
08:54 mikehh bah that should be r41154 - cofetest failed at r41153
08:54 mikehh codetest
08:54 purl somebody said codetest was part of fulltest,  distro_tests is part of fulltest, but not of codetest
08:58 barney joined #parrot
08:58 HG` joined #parrot
09:27 mikehh rakudo (a0c8a44) buikds on parrot r41154 - make test PASS / make spectest 3 failures - Ubuntu 9.04 i386 (g++)
09:27 mikehh rakudo - t/spec/S03-operators/arith.rakudo - Failed test:  120 - Bad plan.  You planned 200 tests but ran 120.
09:27 mikehh rakudo - t/spec/S12-attributes/class.rakudo and t/spec/S14-roles/basic.rakudo - Non-zero wait status: 11 (Segfault after passing tests)
09:27 mikehh rakudo - ./perl6 t/spec/S03-operators/arith.rakudo - not ok 120 - -2147483648 == 2147483648 - Floating point exception - exits
09:29 gaz joined #parrot
09:31 Ron joined #parrot
09:40 cotto 342/173
09:40 purl 1.97687861271676
09:48 cotto 136/41
09:48 purl 3.31707317073171
09:51 barney 3.31707317073171*41
09:51 purl 136
09:51 bacek joined #parrot
09:52 bacek o hai
10:00 bacek jrtayloriv: ping
10:08 bacek msg jrtayloriv You are using vim, aren't you? :) Parrot_gc_ptr_is_pmc is reindented in gc-refactor branch. src/hash.c contains redundant check left after removing WRITE_BARRIER on lin 1304. Line 1422 - added redundant {} in if (conflicting with coding standards).  Same for src/list.c:1333. src/pmc_freeze.c:1401 added new code for write barriers, can be removed.
10:08 purl Message for jrtayloriv stored.
10:09 bacek msg jrtayloriv Apart from those - green light from me. And I have "todo" list for next few branches :)
10:09 purl Message for jrtayloriv stored.
10:24 cognominal is there a official logo for parrot?
10:27 bacek cognominal: one on www.parrot.org
10:27 bacek afaik, someone did it in vector format
10:30 cognominal making slides for a presentation about Perl 5-6, Parrot/Rakudo
10:44 bacek cognominal: ok... I can't find parrot logo in vector format.
10:50 cognominal pnc is good enough
10:50 cognominal *png
10:58 cghene joined #parrot
11:00 zostay_ joined #parrot
11:06 shockwave In the docs at the website it mentions: "The :load modifier tells Parrot to run the subroutine when it loads the current file as a library. The :init modifier tells Parrot to run the subroutine only when it executes the file as a program (and not as a library)."
11:07 shockwave DOes that mean that :load get's executed in an '.include' optcode, but not :init?
11:07 shockwave Further, it means that :init get's executed when running the file that contains that subroutine directly, but :load wouldn't run in that case?
11:21 gerd joined #parrot
11:24 gerd by building parrot I get: undefined reference to `clock_gettime'; there is needed to add '-lrt' would somebody do that
11:29 gerd left #parrot
11:36 NotFound shockwave: .include is not an opcode, is a directive
11:40 quek joined #parrot
11:44 whiteknight joined #parrot
11:45 allison joined #parrot
11:45 whiteknight good morning #parrot
11:54 jrtayloriv mornin'
11:55 whiteknight jrtayloriv: don't you ever sleep?
11:55 jrtayloriv just woke up :) -- but I don't sleep much, no.
11:55 jrtayloriv Actually got a full 8 hours last night.
12:08 whiteknight I'm looking at your branch now
12:15 whiteknight all looks very good, mostly structure/function renames and not a lot of functional changes
12:16 jrtayloriv whiteknight, thanks for taking a look -- yes, other than getting rid of the preprocessor directives and adding the GC subsytem struct, not much changed.
12:18 NotFound joined #parrot
12:18 jrtayloriv I originally wanted to add the --gc command line switch, but couldn't figure out how to do that due to the way the args are parsed by imcc
12:19 whiteknight I'll take a look at that a little later
12:19 whiteknight I need to get familiarized with that code myself if I plan to refactor it soon.
12:20 whiteknight urg, I had a bunch of questions that I wanted to ask at #ps today, but I didn't write them down and now I can't remember them
12:20 whiteknight irclogs?
12:20 purl i think irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
12:21 NotFound whiteknight: that happens to me almost all weeks, but it doesn't matter because I surely don't have time to work on all answers X-)
12:22 whiteknight NotFound: Yeah, I never have the time either. But I can write the answers somewhere on the wiki and try to trick somebody else to working on it for me :)
12:25 NotFound I think my report for the past two weeks will be: "fxing, fixing, fixing"
12:32 gaz joined #parrot
12:35 whiteknight jrtayloriv: you should post a report today
12:36 jrtayloriv whiteknight, OK - will do.
12:40 ruoso joined #parrot
12:41 jrtayloriv whiteknight, looking around, I can't find the proper method for posting a report -- do I just post it like a regular IRC conversation, email it to a certain place, or what?
12:41 whiteknight The meeting will be in #parrotsketch channel
12:41 moritz jrtayloriv: you just /join #parrotsketch (more)
12:41 moritz jrtayloriv: then write something like "preposting my report"
12:41 NotFound jrtayloriv: whatever, as long as you put a link in the channel
12:41 moritz then a few lines summary of what you did
12:42 jrtayloriv moritz, NotFound -- ok thank you.
12:42 moritz http://irclog.perlgeek.de/parrotsketch/2009-09-01 example from last week
12:44 jrtayloriv moritz, Yes, I've seen what the reports look like, just didn't know if they had been posted on another page or emailed in, and then pulled into IRC automatically.
12:44 NotFound A link to a site that doesn't require to create an account, that is ;)
12:44 NotFound But most of us just put the text in the channel
12:45 jrtayloriv brb -- dog walking time
12:51 Coke seen andya?
12:51 purl andya was last seen on #yapc 35 days, 12 hours, 7 minutes and 16 seconds ago, saying: Thank you. Obviously having such beautiful models helps :)  [Aug  4 00:37:15 2009]
12:52 Coke msg andya leeds.pm? beer? october?
12:52 purl Message for andya stored.
12:55 quek left #parrot
12:55 Coke parrot is getting EVEN SLOWER.
12:55 moritz aye
12:55 moritz I think rakudo's time for 'make spectest' doubled since the last release
12:55 Coke while.test is now running at 90s from 50s.
12:55 Coke (in the past week.)
12:56 moritz and it doesn't run twice as many tests
12:56 Coke yah.
12:57 * Coke kicks off another spectest run, see you in 3 hours.
12:58 Coke shitov?
12:58 purl rumour has it shitov is known person here :-) http://andy.sh/
12:59 Coke "the certificate is not issued by a trusted authority".
12:59 Coke huh.
13:04 Coke msg kid51 Might be a good idea to ditch the "old-school" merge advice from the branching guide and rely on the new svn:mergeinfo hooks that are supposed to make it all JFW.
13:04 purl Message for kid51 stored.
13:14 whiteknight so what we're saying is that this week we should focus on performance?
13:14 NotFound I don't think so. We must still focuse on stability
13:15 whiteknight performance *and* stability
13:17 NotFound Coke: Do you know if the fix for TT #150 is impacting partcl speed?
13:38 jhelwig joined #parrot
13:42 whiteknight I haven't even looked at any of the new pluggable_runcore code. I need to check that out
13:42 Coke whiteknight: amongst our focurs are speed, performance, and a fanatical devotion to the pope.
13:42 Coke "focuses"
13:42 whiteknight the space pope?
13:42 purl somebody said the space pope was a reptilian figure who is apparently the future head of the Roman Catholic Church. He has only appeared twice, once at the start of the show, sponsoring the episode ("in association with The Space Pope"), and later in "I Dated a Robot" as a sponsor of the anti-robots-and-humans-dating video. He is mentioned another time (A Bicyclops Built for Two), when Bender rhetorically...
13:43 Coke whoa, padre is making me reboot.
13:43 whiteknight tell padre to cut it the hell out
13:43 Coke whiteknight: What revision was that fix?
13:43 whiteknight Coke: which fix
13:43 Coke partcl progress?
13:43 whiteknight (there are too many fixes)?
13:43 Coke whiteknight: whoops, that was for NotFound.
13:44 Coke partcl progress is http://partcl.googlecode.com/svn/​trunk/docs/spectest-progress.csv
13:44 Coke NotFound: that shows the parrot revision and the timings for the full spec test run.
13:44 szabgab Coke, when does Padre want to reboot?
13:45 szabgab and on what os?
13:45 whiteknight purl msg chromatic: Could we use the fixed-size allocator for Parrot_runcore_t instead of mem_allocate_typed?
13:45 purl Message for chromatic stored.
13:47 Coke szabgab: windows, after installing via the MSI
13:49 cognominal is someone successful building parrot on snow leopard?
13:52 cognominal Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
13:52 cognominal 0   test_78245                    0x0000000100000ee6 Parrot_memcpy_aligned_mmx_code + 6
13:52 cognominal 1   test_78245                    0x0000000100000ca2 main + 146 (test_78245.c:94)
13:52 szabgab it did not want me to reboot
13:52 szabgab what windows?
13:52 purl rumour has it windows is one hell of an event
13:52 cognominal hum, I remove old parrot sur in /usr/lib that may cause problems
13:53 NotFound Coke: r41115... out of that chart
13:53 cognominal when building I get :  error:imcc:The opcode 'getattribute_s_p_sc' (getattribute<3>) was not found. Check the type and number of the arguments
13:54 mj41 bacek_at_work: TapTinder MacOX box is back. Thanks to our VMWare guru.
13:55 Coke msg purl partcl progress?
13:55 purl Message for purl stored.
13:56 Coke NotFound: so, it's already slower. you're saying there's something to make it /even slower/? woot.
13:56 MoC joined #parrot
13:57 Coke NotFound: I'm doing a run against 41154 now.
13:57 NotFound Coke: I don't think so, but I'm interested in data to confirm
13:57 Coke k. I'll push the spectest results when I haz'em.
13:57 Coke give me another 2 hours. :|
13:58 NotFound Coke: BTW if you have some workaround for that problem is time to try to remove it
13:59 Coke for which problem?
13:59 Coke TT #150?
13:59 NotFound Coke: yeah
14:02 Coke I doubt that's related to speed; I load my own stuff for tcl once at tcl startup, just a one time cost.
14:04 Coke -> reboot
14:08 Coke <- back
14:10 theory joined #parrot
14:13 dalek parrot: r41155 | jrtayloriv++ | branches/gc-refactor (7 files):
14:13 dalek parrot: Fixed coding standards errors and removed leftover write barrier checks (bacek++)
14:13 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41155/
14:14 jhorwitz joined #parrot
14:26 Coke made it up to the i's...
14:29 cognominal joined #parrot
14:40 Coke l's!
14:41 Coke I need someone to a) have a multicore box to run these tests on that doesn't mind chewing up all their CPUs, and b) write code to run the .test stuff in ||
14:41 Andy joined #parrot
14:42 kjeldahl joined #parrot
14:43 Topic for #parrotis now http://www.parrot.org | Prepare for 1.6.0: Improve test coverage for FixedPMCArray and NameSpace PMCs / Stability! / Port tests to PIR / Performance! / No more big branch merging until after 1.6.0
14:44 bubaflub joined #parrot
14:51 Coke mj41++
14:51 Coke whiteknight: hey. what happened to "fix coke's segfaults" ?
14:51 Psyche^ joined #parrot
14:52 whiteknight I include that under "Stability"
14:52 whiteknight we want to fix everybody's segfaults
14:52 Coke I'll forgive you if you fix one of mine.
14:52 whiteknight okay, which is the highest-priority one in your list?
14:53 mikehh Coke: that's what I am trying to set up - however I can't get my VM (kvm/VirtualBox) to work on my wireless connection
14:54 Coke whiteknight: the one that actually stops passing tests from being counted, checking...
14:54 Coke partcl segfaults?
14:54 purl i heard partcl segfaults was http://code.google.com/p/p​artcl/wiki/SpecTestStatus
14:54 Coke no partcl segfaults is http://code.google.com/p/partc​l/wiki/SpecTestStatus#segfault
14:54 Coke partcl segfaults?
14:54 purl rumour has it partcl segfaults is http://code.google.com/p/p​artcl/wiki/SpecTestStatus
14:54 Coke are you serious, purl?
14:54 purl OK, Coke.
14:54 Coke ?
14:55 Coke whiteknight: https://trac.parrot.org/parrot/ticket/965
14:55 Coke thanks in advance. =-)
15:01 whiteknight oh great, a PCC segfault
15:02 whiteknight ...and the backtrace is just wonderful
15:03 whiteknight 7 runcores on the stack
15:04 whiteknight two of which are old-style Parrot_run_meth_fromc_args
15:05 whiteknight You're recursively calling Parrot_TclString_get_bool three times, at least
15:08 iblechbot joined #parrot
15:09 NotFound Waht's a " .local object ..." ?
15:13 whiteknight I assume a .local pmc of type Object
15:13 whiteknight although I've never seen that before
15:14 NotFound Yet another time, the problem of TODOed tests...
15:16 whiteknight We definitely need to triage all our TODO tests, make sure they make sense
15:16 whiteknight and make sure they all have descriptions and tickets
15:16 NotFound That one doesn't have a ticket, or at least the test doesn't mention it
15:17 Coke that's really old syntax.
15:17 particle yeah... really old.
15:17 NotFound dalek: ping
15:17 cognominal joined #parrot
15:18 dalek parrot: r41156 | NotFound++ | trunk/t/compilers/tge/grammar.t:
15:18 dalek parrot: [t] make TODO test at least compile
15:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41156/
15:18 NotFound This one
15:18 purl hmmm... This one is bugged too now
15:18 Coke bah. getting segfaults on redhat (but not feather.)
15:20 mj41 this machine is probably special to segfaults ... http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk
15:28 Coke ooh, segfault with pbc2exe
15:28 Coke (can't even build tclsh)
15:29 Coke ... unless I do it again. freaky.
15:31 allison joined #parrot
15:52 whiteknight particle: I added a note about no more branch merges to the /topic. I think that's something you mentioned earlier
15:54 Coke allison: https://trac.parrot.org/parrot/ticket/965 might be of interest to you.
15:57 allison Coke: thanks, will look
15:57 whiteknight the website isn't loading for me
15:59 whiteknight oh, there it went
15:59 allison Coke: it looks a bit like one of the infinite exception loops
16:01 whiteknight is TclString.get_bool calling TclString.get_bool recursively?
16:04 Coke It should not be, obviously. checking.
16:04 whiteknight I didn't realize you could do that, write a single PMC type in both C and PIR
16:04 jrtayloriv joined #parrot
16:05 * Coke hurls http://code.google.com/p/partcl/source/b​rowse/trunk/src/class/tclstring.pir#199
16:05 Coke also http://code.google.com/p/partcl/source​/browse/trunk/src/pmc/tclstring.pmc#38
16:05 whiteknight Coke: what type does true_s return in the 'get_bool' override?
16:05 Coke true_s is: http://code.google.com/p/partcl/source/brow​se/trunk/src/grammar/expr/expression.pg#102
16:06 cognominal joined #parrot
16:07 Coke whiteknight: if there's recursion, it might be do to the exception handler-in-a-vtable issue allison was mentioned.
16:07 Coke "due to"
16:08 Coke I don't see anywhere in the PIR override where it would call get bool again.
16:08 whiteknight Coke: do you have String HLL mapped to TclString?
16:09 whiteknight if so, if PGE called is_bool on a string match anywhere, it would cause recursion
16:10 Coke yes, the TclString is mapped to String.
16:10 Coke no, if it called get_bool on a String, it would get String's get_bool.
16:10 Coke s/would/should/
16:10 Coke HLL mapping just deals with boxing, not method dispatch.
16:11 whiteknight yes, and PGE is going to box all it's strings to TclString
16:12 Coke shouldn't, no.
16:12 Coke because PGE doesn't run in the Tcl HLL.
16:12 Coke and I only map them in 'tcl' and '_tcl'
16:13 whiteknight your grammar is running in "tcl" because it can find methods from there
16:13 Coke grammar's running in 'parrot', 'Tcl::Expr' or somesuch.
16:13 whiteknight maybe I'm wrong about that
16:14 whiteknight tclstring is defined in .HLL "parrot"
16:14 whiteknight tclstring.pir:7
16:14 Coke .HLL 'parrot'
16:14 Coke .include 'src/grammar/expr/expression.pir'
16:14 Coke so the generated PGE rules are in 'parrot'
16:14 Coke yes. PMCs are defined in 'parrot', not the HLL that you're using them in.
16:14 NotFound I'm getting intermitent segfaults in t/compilers/tge/grammar.t at Eval.destroy, linux i386
16:15 payload joined #parrot
16:16 Coke (but even with the PMCs and the grammarr defined under HLL 'parrot', the mappings themselves are only in effect in 'tcl' and '_tcl')
16:17 NotFound BTW, there is a ticket for the TODO test in that file?
16:17 Coke (the _tcl ones are defined in runtime/tcllib.pir; the tcl ones are defined in C in the pmc files)
16:18 Coke (the classes that have no PMC counterpart are defined in src/class/*.pir)
16:18 particle whiteknight: i didn't see any listmails about other branch merges... what else merged besides context_pmc3?
16:18 NotFound "unresolved bug" isn't a very informative description
16:18 whiteknight kill_parrot_cont merged, I mentioned that in the same email as context_pmc3
16:18 whiteknight pluggable_runcore also merged, I don't think there was an email about that
16:19 * Coke whinges again about the slowdowns.
16:19 whiteknight Coke: where does the actual mapping happen?
16:19 particle was there much fallout from the smokers?
16:19 Coke whiteknight: I just said. =-)
16:19 Coke whiteknight: for TclString, for example, the mapping for the 'tcl' namespace occurs in the PMC definition.
16:19 Coke (hll tcl maps String)
16:20 Coke for _tcl, it occurs in runtime/tcllib.pir
16:20 Coke (since I don't think I can map both in the PMC definition itself.)
16:21 Coke (lunch)
16:21 whiteknight Coke: I don't see mapping code anywhere
16:21 whiteknight oh wait, I see it now
16:21 Coke whiteknight: http://code.google.com/p/partcl/source​/browse/trunk/src/pmc/tclstring.pmc#18
16:22 Coke (as a side note, the only reason I have those PMCs at this point is that I cannot move them into PIR-only. :|)
16:22 Coke (having tried multiple times and failed due to various "classes aren't PMCs" issues.)
16:25 dalek parrot: r41157 | NotFound++ | trunk/src (3 files):
16:25 dalek parrot: [cage] fix or assert conditions mentioned in Simon Cozen's email about clang static analyzer
16:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41157/
16:37 allison joined #parrot
16:38 japhb Aaugh.  Anyone happen to remember the correct tags to make use.perl.org journals display code blocks properly, line breaks and all?
16:40 dalek rakudo: 9c449f6 | pmichaud++ | docs/spectest-progress.csv:
16:40 dalek rakudo: spectest-progress.csv update: 436 files, 14273 (69.3% of 20599) pass, 0 fail
16:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​c449f6390940d7c441b59c9ee9f651638677b75
16:41 Tene jhorwitz: are you blocking on anything from me for mod_parrot?
16:42 whiteknight What's the status of the Parrot debugger?
16:42 whiteknight does it work usably?
16:42 jhorwitz Tene: not at all.  i should have the tuits this week to work on your compile issue
16:42 pmichaud japhb: <ecode>, I think
16:43 Tene whiteknight: iirc, it works, but doesn't actually respect breakpoints, so isn't very useful.
16:43 whiteknight ok
16:43 japhb pmichaud: Works!  Thank you.
16:49 particle pmichaud: trouble reaching the 70% threshold, it seems
16:49 particle rakudo is perennially close, but never above
16:50 darbelo joined #parrot
16:50 particle 20599 * 0.007
16:50 purl 144.193
16:50 particle need 145 more tests to get there :)
16:53 whiteknight Coke: in conversions.pir you are calling into parrot::TclExpr::Grammar::number with a TclString argument
16:54 whiteknight at least, I am reasonably certain that you are
16:56 whiteknight .local string str
16:56 whiteknight str = number
16:57 japhb Who owns dalek?
16:57 whiteknight no wait, I'm being retarded
16:57 darbelo Hmm. Does anyone know on what platform is http://irclog.perlgeek.de/p​arrot/2009-09-08#i_1478677 happening?
16:57 whiteknight japhb: Infinoid, I think
16:57 Infinoid hi!  I don't own dalek, I just stab it with scripts once in a while
16:58 japhb Infinoid, can you add http://gitorious.org/parrot-plumage/parrot-plumage to dalek?
16:58 Infinoid japhb: I can.  Please keep hitting me with a stick until it gets done (I'm at work right now)
16:58 japhb Infinoid, roger that.
16:58 * japhb adds "Hit Infinoid with a stick" to the Plumage TODO
16:59 Infinoid japhb: It's going to require adding a "parser" so it can understand gitorious's directory layout and all of that stuff... see http://github.com/Infinoid/dalek-plugins/​blob/master/modules/local/githubparser.pm for the github version of the same thing
16:59 Coke holy (*&@#$ is parrot slow.
16:59 whiteknight Coke: if you have nothing nice to say...
17:00 japhb Infinoid, ah, interesting.
17:01 Infinoid what's Plumage?
17:01 japhb The Parrot module ecosystem that I am working in, coded in NQP.
17:02 Infinoid hmm, cool.
17:02 japhb Mostly so far I've been mired in yak shaving, as my upcoming u.p.o post will elucidate.  :-)
17:02 Infinoid dalek has support for learning about new languages by scraping the Languages page from the wiki.  But I think we need a Plugins page or something like that too, for the parrot-related things that are not languages
17:04 whiteknight Infinoid: who does own dalek then?
17:05 japhb Infinoid, nodnod
17:05 Infinoid I don't know.  diakopter is the next link in the list, he might be the owner or it might be Juerd (?)
17:09 Coke whiteknight: partcl's test suite, with changes only in parrot, takes 150% as long to run as it did a week ago.
17:09 Coke between 40982 and 41154
17:10 Coke only changes in partcl in that time were in the docs saying "how long do the spec test runs take"
17:10 Coke (sorry, spec test, not regular make test.)
17:12 Coke msg mikehh still not seeing segfaults on feather - I am seeing some on redhat, though.
17:12 purl Message for mikehh stored.
17:12 whiteknight we've made a lot of progress architecturally in that time. The optimizations need to follow en masse now
17:12 whiteknight I think we'll be able to make improvements, but I don't know if we'll cut 33% off our current by the release
17:13 whiteknight (to get us back to where we were at 1.5.0)
17:13 dalek partcl: r699 | coke++ | trunk/docs/spectest-progress.csv:
17:13 dalek partcl: At parrot/r40982 we ran .95 tests/s
17:13 dalek partcl: At parrot/r41154 we ran .62 tests/s
17:13 Coke ugh.
17:13 dalek partcl: (running same spec test files - only partcl differences between those runs are
17:13 dalek partcl: in these doc files.)
17:13 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=699
17:13 mikehh Coke: I was getting lots on amd64 (but NotFound++ says his was ok) not getting them on i386 (where I am at the moment)
17:13 Coke we had improved performance through 40982 over 1.5.0
17:14 Coke (was running .9 test/second instead of .8)
17:14 NotFound Coke: What part of that time can be test that now run full and before segfaulted?
17:14 Coke NotFound: ?
17:14 whiteknight which branch brought the biggest slowdown for you?
17:14 bubaflub left #parrot
17:14 NotFound mikehh: I'm having random failures like yours, but on i386
17:15 Coke whiteknight: it takes 4 hours to run the test suite. I only do it occasionally.
17:15 Coke if it will help, I can run it for some specific parrot versions.
17:15 Coke (at least, NOW it takes 4 hours. =-)
17:15 Coke NotFound: none of those test times include time spent running a segfault test.
17:16 Coke I strip those out and rerun if that happens.
17:16 japhb http://use.perl.org/~geoffrey/journal/39598
17:16 Coke (the last several runs have not changed which files get run, either.)
17:16 mikehh NotFound: my last run at r41152 was fine - am rebuilding on r41157 now (i386)
17:16 whiteknight We need to put together a list of of all branches that have landed this month: auto_attrs, the unionval one, the Sub one, kill_parrot_cont, context_pmc3, pluggable_runcores
17:17 Coke japhb: glad to see the json stuff getting used.
17:17 japhb Coke, :-)
17:17 japhb Coke, were you the original implementor?
17:17 jrtayloriv Coke, I'd be glad to run testing in the background if that would help. You need any testing on Linux amd64?
17:17 Coke japhb: I think so. =-)
17:18 japhb heh
17:18 Coke japhb: was a long time ago. =-)
17:18 NotFound Coke: if there are more test that pass, they eat more time, isn't it?
17:18 whiteknight auto_attrs pmc_sans_unionval  should have been a net improvement for performance. the rest should have been neutral or worse
17:18 Coke NotFound: yes.
17:18 Coke parrot progress?
17:18 Coke partcl progress?
17:18 purl hmmm... partcl progress is http://partcl.googlecode.com/svn/​trunk/docs/spectest-progress.csv
17:18 japhb Coke: I was just glad to see it had already been done, and I didn't have to shave that yak as well.
17:18 Coke look at the last 3 lines there; same 100 tests running each time.
17:19 Coke when I was saying time/test, I was comparing total tests (not test files) and total time.
17:19 sri joined #parrot
17:19 Coke so if you look at r40625, you'll see we were doing about .8tests/second, but we were trying about 1/4 as many tests.
17:19 whiteknight I can't see any of those branches adding 50% to our runtime though, in any case
17:19 Coke but if you look at the last 3, time has gone from 8756s to 13443s with no changes in partcl or what tests are running.
17:20 Coke 13443/8756
17:20 purl 1.53529008679762
17:20 Coke so, 50% slowdown.
17:20 Tene mikehh: you're having VM troubles?
17:20 Coke whiteknight: parrot's test suite is not comprehensive, we already covered that. =-)
17:21 whiteknight Coke: I'm not talking about our test suite at all
17:21 mikehh Tene: I can't get it to work on my wireless connection
17:21 whiteknight I can't think of anything that changed between 1.5.0 and now that would lead to a 50% performance hit
17:21 whiteknight I can account for maybe a 10% hit in my head
17:21 Coke it could be that feather added the other 40%, but that's highly unlikely.
17:21 Coke (competing for CPU or other resources)
17:22 Coke should be easy enough to benchmark one of the smaller .test files a few dozen times at multiple revisions.
17:22 whiteknight Coke: Could you do that?
17:22 mikehh Tene: it will talk to wired ethernet (but I don't have that at the moment)
17:22 Coke s/easy/straightforward/
17:22 whiteknight If we can narrow down where the big performance hits happened, we can target them
17:23 Coke sure. just requires a lot of busywork. won't be in time for #ps.
17:23 Tene mikehh: what distro/vm?
17:23 mikehh Tene - am looking at getting a plug connection (ethernet through electric cables) my son has one setup
17:24 mikehh Tene: Ubuntu 9.04 amd64 as a base
17:24 whiteknight Coke: as of this performance, I run all my personal benchmarks /faster/ then I did at 1.5.0
17:25 Coke whiteknight: parrot core usage != "real world" usage.
17:25 mikehh Tene - kvm reports something like wireless drivers unreliable for sharing)
17:25 whiteknight so we need to find whatever partcl is doing that I am not, and make sure we get that tested and added to our benchmark suite
17:25 Tene mikehh: does ubuntu have virt-manager, or setting it up yourself?
17:25 whiteknight Exactly! So we need to add more real-world cases to our core tests
17:25 Coke whiteknight: right. as I said, parrot's test suite is not comprehensive. =-)
17:25 Coke You're free to use partcl itself to test. =-)
17:26 mikehh Tene - I tried VirtualBox - even installed Ubuntu 9.04 i386 as a guest but couldn't get the wireless connection to work to update
17:26 Tene mikehh: for wireless, sharing the same physical device doesn't work... you need to set up bridging.
17:26 mikehh Tene: probably missing something but can't devote forever to it
17:27 Tene I know that in virt-manager, it's exposed as a radio box. 'Virtual network' vs 'Shared physical device', and you need to choose the former.  I haven't set it up by hand, though.
17:27 Tene but, yeah, you need to set up a virtual network device and have it routerd.
17:28 chromatic joined #parrot
17:28 mikehh Tene: so I understand - but not sure how to do that without breaking something
17:28 mikehh Tene - it took me long enough to get wireless working in the first place
17:30 mikehh Tene - it now works "out of box" so to speak and am very reluctant to change too much
17:31 Coke can I use 'git bisect' to run something for /every/ revision between 2 revisions?
17:32 mokurai joined #parrot
17:32 Tene mikehh: I recommend installing the virt-manager package and using it to configure your vm.
17:33 Tene Coke: No, I don't think that you can.  I'd be surprised.
17:34 mikehh Tene I had that - but I will try again (tomorrow)
17:34 Tene OK.
17:34 NotFound Coke: if they are n and n+2, you can X-)
17:34 Coke NotFound: :P
17:34 mikehh I have some $work pending and can't affore to break the machine until it is done :-}
17:35 joeri joined #parrot
17:35 Tene Coke: for i in $(git rev-list COMMIT1..COMMIT2) ; do git checkout $i; do_stuff.sh ; done ; git checkout HEAD
17:35 Tene mikehh: Yes, I've definitely been there. :)
17:36 Tene mikehh: but, please feel free to ask me for help when you do want to work on it again.
17:36 Tene Coke: will that work for you?
17:36 * Tene AFK lunch
17:36 Coke tene; very  likely, thanks!
17:37 Coke as soon as I verify my benchmark script works, i'll kick that off.
17:37 mikehh Tene: thanks I will
17:44 Coke timethis 3: 77 wallclock secs ( 0.00 usr  0.00 sys + 53.07 cusr 21.26 csys = 74.33 CPU) @  0.04/s (n=3)
17:44 Coke ww
17:46 Coke (that's a lot of checkouts between 1.5.0 and head)
17:46 whiteknight yeah, it has been a busy month
17:47 whiteknight you could filer on the log message, avoiding commits [t] or [docs] or [cage]
17:47 Coke 275 commits * several minutes to build and at least 1 minute to test.
17:47 whiteknight there were a lot of [t] commits in there
17:47 Coke I'll do a subset of some kind.
17:48 whiteknight Coke: howabout we just get a list of specific commits?
17:49 whiteknight 40625 was the release
17:49 whiteknight 40626: auto_attrs
17:50 whiteknight 40643: tt795_kill_parrot_sub
17:50 whiteknight 40726: pmc_sans_unionval
17:51 Coke sure.
17:52 whiteknight 40958: context_Pmc3
17:53 whiteknight 41039: kill_parrot_cont
17:54 whiteknight 41081: pluggable_runcore
17:54 whiteknight There were a few changes in trunk between these that would affect performance but if we can narrow down a range to the big milestones that would be good
17:56 pmichaud context_pmc3 could (does) easily account for 10%-20% slowdown
17:56 pmichaud just on its own
17:56 whiteknight yes, that's true
17:56 chromatic We clawed a lot of that back.
17:56 pmichaud I'm not seeing it in rakudo
17:56 whiteknight A big portion of the issue is that there are now a lot more API calls where we were previously doing direct struct acesses
17:57 whiteknight so we gain encapsulation but lose performance. I think there are plenty of ways we can improve that now
17:57 Andy joined #parrot
17:58 pmichaud of course, it's very hard to judge with Rakudo because we have so many things changing at once
17:58 pmichaud but Rakudo's spectest suite is definitely running slower in the past week
17:58 pmichaud part of that is because we're running more tests
17:58 pmichaud but part of it is also Parrot changes
17:58 purl okay, pmichaud.
17:58 whiteknight if we had a better idea of Rakudo's hot spots, we could cross reference that with areas changed most by context_pmc3 and optimize the hell out of them
17:59 pmichaud whiteknight: hint:  Parrot calling conventions
17:59 dalek TT #994 created by Util++: Fix SVN properties for git-svn users
17:59 whiteknight pmichaud: yeah, but we have to narrow it down more then that
18:00 pmichaud whiteknight: right now Rakudo has to do a lot of calling conventions work in PIR that really ought to be done in C
18:00 pmichaud whiteknight: but we can't do that until the pcc_rewiring branch lands
18:00 whiteknight I suspect argument processing took a hit, specifically
18:00 pmichaud I guarantee Rakudo pays the price on argument processing
18:00 Coke so we keep hearing (about pcc_rewiring. :P)
18:00 Coke partcl is going to feel any slowdown on calling conventions a lot. (also anything involving the PIr compiler.)
18:00 pmichaud every Rakudo sub that gets called results in numerous calls to other support-level subs just to handle the argument processing
18:03 chromatic pmichaud, do you build Parrot with debugging?
18:03 whiteknight what I think we need right now from Rakudo and Partcl are good, representative tests that we can profile
18:03 pmichaud chromatic: we just take whatever Configure.pl gives us by default
18:04 pmichaud whiteknight: There's a suite of 400 test files to play with :-)
18:04 chromatic You ought to see a speed improvement by avoiding -DNDEBUG.
18:04 pmichaud ...how does one avoid that?  ;-)
18:04 whiteknight pmichaud: I don't want a pile of 400 tests, I want one good representative one
18:04 pmichaud whiteknight: pick one and try it.  :-)
18:05 Ron joined #parrot
18:05 pmichaud if you want me to pick one....
18:05 whiteknight the problem with Parrot's core tests and benchmarks is that they aren't representative of how Rakudo is using parrot
18:05 whiteknight i would like you to pick one, yes
18:05 dalek parrot: r41158 | chromatic++ | trunk/examples/benchmarks/oofib.pir:
18:05 dalek parrot: [examples] Sped up oofib PIR benchmark by 17.81% by reducing unnecessary PMCs
18:05 dalek parrot: created in the PIR code; no changes to Parrot itself.
18:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41158/
18:05 dalek parrot: r41159 | chromatic++ | trunk (3 files):
18:05 dalek parrot: [runcore] Moved default runcore selection to Parrot_runcore_init() and made the
18:05 whiteknight I don't want my bias to influence the decision
18:05 dalek parrot: fast runcore the default runcore for non-debug builds.
18:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41159/
18:06 * moritz would blindly propose t/spec/S06-signature/passing-arrays.t
18:06 pmichaud I was going to propose trig.t :-)
18:06 whiteknight okay, those are two good tests
18:06 pmichaud t/spec/S32-trig/trig.t
18:06 whiteknight I'll use them both, assuming they exercise different things
18:07 pmichaud trig.t exercises quite a bit
18:07 whiteknight okay, all the better
18:07 moritz trig.t is huge - profiling that will take tons of time
18:07 pmichaud yes, it is big
18:07 whiteknight moritz: but it only needs to be done once :)
18:07 moritz then I won't stop you ;-)
18:07 pmichaud but it definitely will hit the compiler itself, Perl 6 multimethods, argument dispatch, built-in opcodes and functions, etc.
18:07 pmichaud class definitions
18:08 * Coke must be doing something wrong.
18:08 pmichaud a trimmed version of trig.t could certainly be made to reduce its size
18:08 pmichaud #ps in 22
18:08 Coke (since he's running his own benchmarks, but rakudo is passing them off. =-)
18:08 whiteknight no trimming, we want representative
18:14 * Coke smacks particle.
18:17 MoC joined #parrot
18:27 Coke allison: I'll be in the UK in about 4 weeks. (up near leeds, though.)
18:27 allison Coke: ah, neat
18:28 allison Coke: will you be passing through london?
18:28 Coke very likely not. =-)
18:28 Coke unless my boss has a day trip planned. (flying into manchester)
18:28 Coke Willbe trying to hook up with leeds.pm, though, if I can find AndyA before then.
18:28 chromatic Manchester, England?  England?  Across the Atlantic?
18:29 allison Coke: excellent idea
18:29 Coke chromatic: yes.
18:29 Coke ... assuming my boss doesn't cancel this, the third potential trip there also.
18:29 mikehh #ps time
18:35 whiteknight dukeleto: how are you measuring test coverage?
18:36 cotto coverage?
18:36 purl coverage is probably http://cv.perl6.cz
18:37 Topic for #parrotis now http://www.parrot.org | Prepare for 1.6.0: Improve test coverage for NameSpace and Continuation PMCs / Stability! / Port tests to PIR / Performance! / No more big branch merging until after 1.6.0
18:46 Coke src/sub.c line 169 is unreachable.
18:46 Coke bah. no it isn't.
18:46 chromatic It isn't?
18:47 Coke I was looking at the condition starting on 126, but its tied to 121.
18:47 chromatic Right.  I read it the same way at first.
18:48 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41157 - Ubuntu 9.04 i386 (g++)
18:51 dalek parrot: r41160 | cotto++ | trunk/src/sub.c:
18:51 dalek parrot: [sub] remove an unreachable return
18:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41160/
18:51 dalek parrot: r41161 | cotto++ | trunk/src/sub.c:
18:51 dalek parrot: [sub] cotto-- jumped the gun
18:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41161/
18:51 bacek joined #parrot
18:52 Coke hah!
18:54 pmichaud hmmm, I wonder if the following would work...
18:54 pmichaud "The JIT code in Parrot is unreachable."
18:54 * pmichaud waits for a commit removing JIT :)
18:55 chromatic After 1.6.
18:55 chromatic Note how easy it is to do with the new runcore switcher....
18:55 pmichaud Aw, shucks.  :)
19:00 Coke whiteknight: bah. my benchmark does NOT reflect the slowdown in the overall 'make test'
19:00 chromatic Maybe we just fixed it, Coke.
19:01 mberends joined #parrot
19:01 nopaste "coke" at 72.228.52.192 pasted "timings for whiteknight (running concat.test 3 times each)" (27 lines) at http://nopaste.snit.ch/17887
19:02 whiteknight Coke: See why I made such a deal about finding a good representative sample to test?
19:02 whiteknight because finding one that mirrors the overall trends in the test suite will be non-trivial
19:02 Coke whiteknight: do you know how long it would take me to try every single .test file? you should just run "make spectest". =-)
19:02 Coke it will take less time.
19:03 whiteknight we aren't looking for the perfect test, just a representative one
19:03 whiteknight one that follows the overall trends, mostly
19:03 Coke whiteknight: yes. given that it takes me 4 hours now to run the test suite for a single version of parrot...
19:04 whiteknight find a test that is slower now then it was at 1.5.0
19:04 Coke to find one that trends the same is days just for data gathering. and there's no guarantee that it will remain representative.
19:04 Coke chromatic: checking the changes that went in between 41161 and 41154
19:06 dalek rakudo: ef31fec | moritz++ | .gitignore:
19:06 dalek rakudo: add some windows specific files to .gitignore, azawawi++
19:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​f31fec556364f6aada34a5f9c1c707d75174394
19:06 dalek rakudo: 62879bb | moritz++ | :
19:06 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
19:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​2879bb25e6ecc2aa5dcc8f376eff7d974386c50
19:06 xenoterracide joined #parrot
19:07 Coke chromatic: looks like the only thing that would account for that is defaulting to the fast core.
19:08 chromatic That's only if you build with an optimized Parrot, too.
19:08 jrtayloriv whiteknight, So can I just go ahead and completely remove all references to GMS and IMS from everywhere in the gc-refactor branch?
19:08 Coke chromatic: I always do.
19:08 whiteknight jrtayloriv: Kill with great speed
19:08 jrtayloriv whiteknight, gracias
19:08 chromatic There's a 15% speedup then.
19:09 mberends joined #parrot
19:09 moritz I just spectested rakudo with parrot r41159 - about 50 test files which pass but abort with status 11 in the end
19:09 moritz normal are about 3
19:09 whiteknight chromatic: building an optimized parrot and running with a better core only hides the performance issue
19:10 whiteknight and next time we make parrot 15% slower, we won't have that option to fall back on
19:10 Coke I was about to co mention that and also say "but I'll take it for now."
19:10 chromatic I understand that, but I'd like the released versions to perform reasonably well.
19:10 chromatic I'd also like to see the fast core become the default core everywhere.
19:10 whiteknight agreed 100%
19:10 whiteknight I think we're well past the point where the slow core is helping us diagnose basic control flow problems
19:12 chromatic moritz, I'm happy to look at those.
19:12 Coke I'm all for killing it. =-)
19:13 moritz chromatic: I'm on amd64 and built with --optimize, FYI
19:13 Coke AIUI, the various cores were partially chosen to try out different methods of dispatch to see what's faster. if fast is just as portable as slow and is faster and is amenable to debugging...
19:13 chromatic I think the various cores were because it was fun to write new cores.
19:14 Coke chromatic: I'm being generous.
19:15 Coke chromatic: is fast now going to be the default core if I had an optimized bird and used pbc2exe ?
19:15 chromatic Yes.
19:17 Coke chromatic: while.test benchmark just ran in 2m, compared to 50s earlier this month.
19:17 chromatic Good to know.
19:17 Coke using r41161
19:18 Coke which includes the fastcore changes.
19:18 whiteknight that sounds like a great representative test for profilin'
19:18 pmichaud moritz: I find that "abort with status 11" is often cleaned up by completely removing parrot/ and parrot_install/ and rebuilding
19:18 whiteknight there are going to be distinct differences in performance of different types of cores for different platforms
19:19 moritz pmichaud: trying that now
19:19 pmichaud the "normal 3" actually abort with status 6
19:19 whiteknight I know that PPC is going to treat fast/switch different in a relative way from x86
19:20 chromatic Fast isn't sufficiently radically different from slow to make that a difference.
19:20 whiteknight no, there probably isn't any
19:21 whiteknight it's mostly to do with differences in how different branch predictors handle indirect local jumps compared to indirect function call/return
19:21 chromatic Right.
19:22 whiteknight hopefully this pluggable runcore stuff makes it easier to write better cores in the future
19:23 chromatic It should.
19:23 NotFound pmichaud: I find the same sometimes, maybe both parrot lib are linked :?
19:23 chromatic Note how nicely it would allow us to write a Lorito core.
19:23 whiteknight a good context threading core, which I would love to add, will reduce dispatch latency to a minimum
19:23 whiteknight chromatic: yes, a Lorito core would be killer too
19:24 chromatic A Lorito core and lorito.ops....
19:24 whiteknight actually multiple Lorito cores (switched Lorito core, slow Lorito core, etc)
19:24 chromatic It may not seem like it to a disinterested observer, but that's part of my long term plan to replace the JIT.
19:25 NotFound I'd like to have Lorito real.
19:25 NotFound ("Lorito real" is an old child song/joke in Spain)
19:25 whiteknight chromatic: mine too. I specifically mention it in the wiki page
19:25 whiteknight Lorito is a key component of a future JIT
19:26 whiteknight I should write up some examples on the wiki so people can see how easy code generation will become with it
19:26 chromatic A little Parrot dollar?
19:29 allison whiteknight: from your comments, it looks like you're still thinking of JITing ops
19:29 NotFound chromatic: no, I think "Real" was the old name of some sort of parrot, with the colors of the King, or something like that.
19:29 Coke lorito real is that new james bond movie, yes?
19:29 whiteknight allison: yes
19:29 allison whiteknight: but a real JIT doesn't JIT ops, it JITs user functions
19:29 allison whiteknight: that is Sub
19:30 chromatic Those are written in ops.
19:30 whiteknight well, I'm simplifying. We will JIT at the Sub-level
19:30 allison aye, but the way to JIT a sub isn't to JIT all it's contained ops
19:30 chromatic How do you JIT a sub then?
19:30 whiteknight with each op representing a code template to use to do that
19:30 allison (though you do need a way to translate the ops)
19:31 whiteknight we'll generate code at the op level, generate and optimize at the Sub level
19:31 whiteknight (I should be more clear about all this on the wiki)
19:31 allison chromatic: it's a question of scale, you don't want a hundred JIT blocks, one for each op call, you want one JIT block for the Sub
19:31 chromatic Why would you have a hundred JIT blocks if you know how to JIT each op?
19:31 whiteknight each op will represent a series of statements. At runtime we'll put all the statements together as a single Sub block, and generate code for that
19:32 chromatic I don't think we should do it at the Sub level, but yes.
19:32 whiteknight the idea that I am thinking about would allow us to do it either way
19:32 whiteknight we'll generate the JIT thunks at build time and assemble them however we want at runtime
19:33 dalek TT #601 closed by cotto++: pluggable runloops
19:33 allison chromatic: it's not a JIT if we can't JIT user functions on the fly at runtime
19:33 chromatic Yes, but that's not what I asked.
19:33 chromatic (And thus we *don't* have a JIT now on *any* platform.)
19:34 allison whiteknight: I'm really not keen on the "two implementations for every op" idea either
19:34 whiteknight allison: that's what we have now and what I am trying to avoid in the future
19:34 allison chromatic: it depends on what you're JIT compiling
19:34 whiteknight We write the ops once in an interchange format, parse that, and generate multiple forms automatically at build time
19:35 allison chromatic: I'm mainly just making sure we aren't still lingering on with our existing JIT mentality
19:35 chromatic Why would anyone write a JIT that wrote a separate assembly block for each op?
19:35 whiteknight ...why did they?
19:35 allison chromatic: yes, it's insane, agreed, that's why I'm making sure that's not what whiteknight meant
19:35 chromatic My most charitable guess is that it was an easy proof of concept.
19:36 whiteknight Ideally I would like parrot to have proper JIT and AOT, so we can get around having "fakecutables" at all
19:37 whiteknight LLVM has that ability, libJIT is developing it
19:37 moritz chromatic, pmichaud: realcleaning parrot/ and deleting parrot_install/ didn't  make the many "Non-zero wait status: 11" go away
19:38 allison whiteknight: I would be a lot more confident in LLVM if tewk's GSOC project had gone ahead
19:38 whiteknight agreed, but I'm not going to let that affect my optimisim
19:38 Coke how much of that was LLVM, how much parrot, how much tewk?
19:38 whiteknight 100% tewk
19:39 chromatic Given that he didn't even start, I'm inclined to agree.
19:39 whiteknight if he had the time to devote to it, I have high confidence that it would have succeeded
19:40 chromatic I have less confidence, given the current design of our JIT and the way we manage ops.
19:40 whiteknight actually from what I've been hearing from developers, libJIT is supposedly much easier to use
19:40 particle i have high confidence we'd have a list of lessons learned, but not necessarially success
19:40 allison particle: on that I agree completely
19:41 whiteknight We're in a better position now then we would have been for the summer: more then one developer and no time limit
19:41 chromatic Don't forget: the will and a plan to make Parrot JITtable.
19:41 duk3leto any chance that someone can get Tewk to write down what he was planning to do?
19:41 Coke whiteknight: does libJIT have a web page we could link to (in addition tot he ftp link?)
19:41 whiteknight We get the green light, and good JIT will happen. it's not an "if", it's a "when"
19:42 chromatic The only way I can see LLVM or any other JIT backend working without Lorito is using Clang to compile *all* of Parrot to LLVM bytecode.
19:42 allison of the options, LLVM is the one I'd like to try first
19:42 particle duk3leto: isn't that what his gsoc application was?
19:42 allison even if it doesn't work out
19:42 chromatic ... though Clang excludes other backends for obvious reasons.
19:42 whiteknight allison: as good an option as any
19:43 whiteknight I've tried to include pros/cons for each on the wiki
19:43 mikehh I just checked out llvm and clang and having a look again
19:43 whiteknight LLVM is more feature-rich, but apparently harder to use
19:43 whiteknight but we're not exactly novices here either
19:43 allison there's an additional one not mentioned on the wiki, and that is we have a chance to become the dynamic language component for LLVM, if we're integrated well
19:44 whiteknight allison: is that a direction we want to take?
19:44 whiteknight (I'm not against it, just looking for direction
19:44 mikehh that sounds excellent
19:44 allison it's a good one to take, yes
19:44 whiteknight so then it might make sense for "Lorito" to be LLVM ops
19:44 whiteknight without us doing anything new or different
19:44 allison Parrot is a powerful tool in need of use cases
19:45 allison whiteknight: I'm not so sure about that
19:45 allison LLVM ops are terrible syntax
19:45 allison and, we're used to working in an abstraction layer that hides the headaches
19:45 whiteknight terrible syntax, but a direct way for us to communicate, without translation, to our JIT backend
19:45 allison I suspect Lorito could be a sanity layer of abstraction over LLVM ops, though
19:46 whiteknight that's fine too. We have the parser technology at our finger tips to translate anything into anything
19:46 allison sort of like the PIR
19:46 allison (a thin layer over PASM)
19:47 whiteknight okay, we have a direction, we have solid goals, we have an initial target platform. That's all we really need to get started
19:47 moritz you forgot one important point: tuits ;-)
19:48 whiteknight I don't think that's as huge a limiting factor
19:48 mikehh llvm at r81222
19:49 whiteknight I think our overall speed of development has increased recenty and is continuing to increase
19:50 chromatic We've added three contributors (counting darbelo) in the past month.
19:50 whiteknight and the developers we do have are improving in terms of knowledge, skillset, and capabilities
19:50 allison whiteknight: so this part goes away "Use miniparrot to parse the .ops files and output both C language and JIT definition code for each op."
19:51 whiteknight allison: that's a miswording of what I was intending
19:51 jan joined #parrot
19:51 allison whiteknight: aye
19:52 allison whiteknight: also, none of the generation has to be done with miniparrot, it can be done with full parrot
19:52 allison whiteknight: (the generated C, etc. files just need to be checked in, like we do with IMCC)
19:54 whiteknight true. all reasonably-good options
19:54 whiteknight but we do have a miniparrot
19:54 whiteknight so whatever we need to do
19:55 allison PGE won't run on miniparrot
19:55 whiteknight as is evidenced by that wiki page, we have lots of options :)
19:55 whiteknight allison: would be trivial to add another bootstrapping step, a "mostlyparrot" that does run PGE
19:56 whiteknight not arguing for it, including generated files in the repo is fine too
19:56 allison perhaps, but there's not much advantage to it
19:56 allison even to get miniparrot running you'll need a core set of ops working
19:56 chromatic I don't see much advantage to it either.
19:57 allison so, you can't delay op generation until after miniparrot anyway
19:57 chromatic We should take advantage of PCT for this.
19:57 allison and, once you've done op generation in advance, you might as well take full advantage of parrot to do it
19:57 whiteknight okay, then that's what we'll do. No bootstrapping via miniparrot. Instead we'll include generated files in the repo
19:57 chromatic Yep.
19:57 chromatic We can use a two-stage compile then if we want.
19:58 whiteknight gets us away from a multistage bootstrapping build a la GCC
19:58 Coke does this mean we can now kill miniparrot?
19:58 whiteknight no
19:58 Coke or does it still have some use?
19:58 allison Coke: at the moment we still need it for generating the configuration information
19:58 whiteknight it just won't be getting an additional use
19:59 allison Coke: but there's a chance we could, eventually
19:59 allison Coke: it all depends on what we use for the config and build process once we eliminate Perl 5
20:00 allison if it's not miniparrot, then we don't have much reason to keep miniparrot around
20:00 allison (I would argue that miniparrot is actually far more complex than the build tool needs to be)
20:01 Coke days until release?
20:01 Coke (curses, no smart bots)
20:02 cotto Coke, 7
20:02 Coke ITWBNI if someone added all the pending release datest to the comp.lang.parrot calendar.
20:02 cotto literal good idea
20:02 purl cotto: good idea =is= <rss="http://hachi.kuiki.net/rss​/randline.pl/gibi_long.txt">
20:02 cotto someone could use that to add a smart "days until release" fact to purl
20:02 hachi yup
20:04 cotto I don't think it it'd be a "good idea". ;)
20:04 cotto s/it //
20:05 whiteknight good idea
20:05 purl whiteknight: Good Idea: Kissing a loved one. Bad Idea: Kissing a total stranger.
20:05 whiteknight good idea
20:05 purl whiteknight: Good Idea: Finding Easter eggs on Easter morning. Bad Idea: Finding Easter eggs on Christmas morning.
20:11 whiteknight I like LLVM a lot
20:11 whiteknight and it's broken into multiple libraries, so we can pick and choose what all features we want from it
20:12 mikehh I was very interested in both the llvm GSOC project and the decimal project - unfortunately we only seem to have had results on the decimal one
20:13 whiteknight mikehh: there was no LLVM GSOC project
20:13 whiteknight but darbelo did kick ass with the decimal one
20:13 Coke http://www.google.com/calendar/render?cid=ldhct​damsgfg5a1cord52po9h8@group.calendar.google.com (parrot calendar) now shows the releases through 2.0
20:14 Coke (so they'll show up on www.parrot.org, etc.)
20:14 whiteknight (we should make sure we get as many GSOC slots as possible next year, because we have good turnaround for students turning into committers)
20:14 mikehh I thought we had something going on that at one stage
20:14 Coke I recommend we remove the list from the doc in the repo and just point to the calendar.
20:14 * whiteknight is going home now. Talk to y'all later
20:14 cotto I like having it in the repo
20:14 mikehh cul8r
20:15 Coke cotto: duplication bad. meta docs in real docs, bad. ease of use? +1
20:17 cotto true
20:17 nopaste "coke" at 72.228.52.192 pasted "timings for while.test (3x each)." (21 lines) at http://nopaste.snit.ch/17888
20:18 cotto Wow.  I started tcl hello world with the profiling runcore in valgrind before #ps and it's still going
20:19 cotto Coke, do you have any idea why that runcore might cause such a huge slowdown in tcl when Rakudo's slowdown is only ~10x?
20:20 Coke cotto: because tcl is insanely slow?
20:20 Coke note that 'hello world' isn't just calling "puts". you're also loading this file:
20:21 Coke http://code.google.com/p/partcl/so​urce/browse/trunk/library/init.tcl
20:21 Coke so it's doing all the runtime/tcllib.pir startup, plus loading and running all that tcl.
20:21 Coke (before it gets to anything passed in via -e.
20:22 Coke I do find it amusing that the guy that wrote the profiling core, who is running the profiling core, is asking me what's making the code he's running it on slow. =-)
20:23 cotto Coke, I'm looking into it, but you'd best know where to start.
20:23 cotto I do like that irony, though.
20:23 Coke cotto: PCC and compreg 'PIR'
20:25 Coke I can try to add a "--no-init" flag.
20:26 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41161 - Ubuntu 9.04 i386 (g++)
20:28 cotto That sounds like it's papering over the problem.
20:28 Coke cotto; the problem being that tcl is slow? yes. =-)
20:28 Coke but it might help us get over the hump.
20:29 chromatic Hm, Parrot_str_split is sloooooow.
20:29 cotto btw, make -jn doesn't work very well on partcl.
20:29 Coke cotto: works here.
20:29 Coke well, -j3.
20:29 Coke cotto: aha. real tcl has -q :: quick init.
20:29 Coke there you go, not even a hack.
20:30 cotto I love callgrind
20:31 cotto well, kcachegrind
20:31 purl kcachegrind is GUI?
20:33 cotto crud.  Rakudo hello world is exploding again under the profiler.
20:38 Coke cotto: shortly, ./tclsh -q -e 'puts hi' will run much faster han ./tclsh -e 'puts hi'
20:38 Coke (just testing first)
20:43 cotto the fix appears to be simple
20:43 nopaste "coke" at 72.228.52.192 pasted "for cotto:" (11 lines) at http://nopaste.snit.ch/17890
20:44 cotto I like it.
20:45 mikehh rakudo (62879bb) builds on parrot r41161 - make test / make spectest (up to 28207) PASS - Ubuntu 9.04 i386 (g++)
20:45 mikehh rakudo - t/spec/S03-operators/arith.rakudo - TODO passed:   131
20:45 mikehh rakudo - t/spec/S12-attributes/class.rakudo and t/spec/S14-roles/basic.rakudo - Non-zero wait status: 11 (Segfault after passing tests)
20:46 hercynium joined #parrot
20:47 Coke cotto; of course, I can only find -q on a sco.com man page.
20:47 Coke but, enjoy. hopefully you can make it obsolete. =-)
20:50 duk3leto msg whiteknight re: gsoc slots for next year: parrot needs to decide if it is going to be its own org next year or stay under the umbrella of The Perl Foundation
20:50 purl Message for whiteknight stored.
20:51 dalek partcl: r700 | coke++ | trunk/src/tclsh.pir:
20:51 dalek partcl: Support -q command line option.
20:51 dalek partcl: (quick) - don't load init.tcl
20:51 dalek partcl: Useful for initial profiling attempts.
20:51 Coke I would tend to vote umbrella.
20:51 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=700
20:52 darbelo umbrella++
20:52 cotto good #ps question
20:53 duk3leto Coke,darbelo: umbrella is good, but if we have >15 slots next year, that is a lot of work for a single organization admin
20:53 duk3leto come to think of it, 9 was pushing it
20:54 Coke duk3leto: we could have one on paper but 2 in practice.
20:54 Coke but yah, if it's too much, we can split; my conern with that is that parrot will appear as 'new guy on block'
20:55 Coke afk
20:56 darbelo Precisely, 'new guy' organizations ussually get fewer slots than old timers.
20:56 duk3leto darbelo: that may have been true in the past, but gsoc also wants to welcome fresh blood as well.
20:57 cotto The sooner we start, the sooner we'll be better off.
20:57 darbelo OTOH, "fewer than TPF" == "plenty enough for PaFo"
20:58 duk3leto how many slots does parrot think it can fill next year? that is something to think about
20:58 mikehh Coke: whatever you did at r700 broke things for me on i386
20:58 duk3leto i am thinking, a lot more than this year, if our current dev velocity/acceleration continues
20:59 darbelo duk3leto: most likely. I would expect arround 4.
20:59 dalek parrot: r41162 | cotto++ | trunk/src/runcore/profiling.c:
20:59 dalek parrot: [profiling] fix another off-by-one error
20:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41162/
20:59 mikehh partcl r699 builds on parrot r41161 - make test PASS - Ubuntu 9.04 i386 (g++)
21:03 mikehh partcl r700 builds on parrot r41161 - make test FAIL (18 files - 4subtests) looks like all segfaults - Ubuntu 9.04 i386 (g++)
21:03 cotto 4 would be awesome
21:05 moritz is there a real benefit from splitting up TPF and parrot foundation as mentoring organizations?
21:06 particle re gsoc slots: since google admitted fewer orgs this year, we were forced to use tpf as umbrella to get any slots at all
21:06 particle who knows what policies google will have in place next year that will influence our decision
21:07 dalek parrot: r41163 | chromatic++ | trunk/src/pmc/resizablestringarray.pmc:
21:07 dalek parrot: [PMC] Replaced some VTABLE calls with macrod attribute access in
21:07 dalek parrot: ResizableStringArray PMC.
21:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41163/
21:07 dalek parrot: r41164 | chromatic++ | trunk (2 files):
21:07 dalek parrot: [string] Made string_rep_compatible() static within src/string/api.c; this
21:07 dalek parrot: means an optimizing compiler can inline it.  It's only called from other
21:07 dalek parrot: functions in this file and it doesn't follow the Parrot_* external naming
21:07 dalek parrot: policy.  This produces a 3.295% performance improvement in the STRING-heavy
21:07 dalek parrot: examples/benchmarks/vpm.pir.
21:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41164/
21:07 Whiteknight joined #parrot
21:09 fperrad left #parrot
21:10 duk3leto particle: all good things to think about.
21:11 duk3leto particle: just want to get us in the habit of think of gsoc before the deadline is next week :)
21:11 particle yes, and i will continue to think about them :)
21:12 NotFound chromatic: Will not be better to add PARROT_INLINE? That hint may help some compilers.
21:12 user_3238 joined #parrot
21:12 particle hopefully having a student that dropped out won't be a strike against pafo getting accepted in a future year
21:12 chromatic Does PARROT_INLINE do anything?  Last I remember, it never expanded to anything.
21:12 sjn joined #parrot
21:12 duk3leto particle: nah, it happens to every org.
21:12 particle however, our stand-alone successes are small
21:13 NotFound chromatic: supposedly it exapands to inline if the compiler supports it.
21:13 chromatic Be my guest then.
21:13 jhelwig joined #parrot
21:13 chromatic (in the middle of something else at the moment)
21:13 duk3leto particle: from all the stories I hear, having a student get accepted but then totally disappear is a very common story. i think that is the whole point of the mid-term
21:14 particle things to address at the summit
21:14 particle *these are things...
21:15 duk3leto google cares a lot more about how an org does it's organizing/outreach.
21:15 particle yep, and we need a little help in the outreach dept
21:15 particle organizing we have down.
21:17 joeri left #parrot
21:17 iblechbot joined #parrot
21:18 duk3leto particle: yes. it would be nice if more people went out and talked to university students next year about being part of GSoC.
21:18 particle that'd be easier if instructors knew about parrot
21:18 cotto Ooh.  Good idea.
21:18 purl cotto: Good Idea: Tossing a penny into a fountain to make a wish. Bad Idea: Tossing your cousin Penny into a fountain to make a wish.
21:18 duk3leto particle: i think academia is currently more friendly to parrot than perl5/perl6
21:19 duk3leto particle: that being because they have never heard of parrot, but they have all kinds of FUD in their head about perl
21:19 cotto That sounds like it'd be a pretty easy sell for a bunch of CS students eager for some experience.
21:19 particle nobody uses parrot in compilers courses yet afaik
21:19 duk3leto particle: we can fix that ;)
21:19 particle we must fix that.
21:19 cotto It'd be ideal.  They'd need a new textbook every semester.
21:20 particle pct book, anyone?
21:20 duk3leto cotto++ for the lulz
21:20 darbelo seen mikehh
21:20 purl mikehh was last seen on #parrot 17 minutes and 45 seconds ago, saying: partcl r700 builds on parrot r41161 - make test FAIL (18 files - 4subtests) looks like all segfaults - Ubuntu 9.04 i386 (g++)
21:21 duk3leto particle: are you saying that we should advertise PCT as a textbook?
21:21 payload joined #parrot
21:21 darbelo mikehh: ping
21:21 particle need to write a pct book, or at the least more tutorials and reference docs
21:21 chromatic I would be happy to edit and publish a PCT book.
21:22 particle but, due to impending refactor, the reference will be difficult now
21:22 mikehh darbelo: pong
21:22 particle however, the tutorials should be easier, as the api won't change
21:22 darbelo mikehh: can you retest the (now smaller) patch in TT#986 ?
21:22 cotto particle, you should go to UW and see if you can do some recruiting.
21:23 particle yes, i should, as i know a number of cs geeks there
21:23 particle no profs yet, though
21:23 mikehh darbelo: ok will do
21:23 particle cotto: where are you moving to?
21:23 cotto a little closer to work, but only a few miles away.
21:24 cotto http://maps.google.com/?q=loc%3A+%34%30%30%3​2+West+Lake+Sammamish+PKWY+NE++Redmond+WA+US
21:24 particle ah, locally, good.
21:24 particle where's work?
21:24 purl Work - the curse of the drinking class.  (Oscar Wilde)
21:24 cotto MS
21:24 particle wow, really close to marymoor
21:24 cotto I'm going back to the Open Source lab (now renamed the Open Source Technology Center)
21:24 particle i've biked by there many times
21:25 particle oh, nice!
21:25 particle i need to meet with anandeep, it's been too long
21:25 particle and our msdn subscriptions are up for renewal :)
21:25 cotto I'll be able to arrange that.
21:25 NotFound We need a creative PR department. For example a "Get a parrot" song by the Pet Shop Boys will be great X-)
21:25 particle i'll be biking 100mi on saturday, not far from you
21:26 particle wanna join? ;)
21:26 cotto Is the logo we have now what we want long-term?  I'd hope for something a little more cartoony and professional-looking.
21:26 cotto particle, I'd die.
21:26 chromatic Not the word "professional" again!
21:26 particle professional cartoon... like snoopy?
21:26 NotFound Parrotbert?
21:27 szbalint Maybe the Penny Arcade guys would draw us something. Like, totally man!
21:27 cotto sorry, by "professional" I meant "made by a graphic artist"
21:27 chromatic My nephew likes Camelia, a lot.
21:27 cotto bonus points if it's dead or smoking
21:28 NotFound Or both
21:28 cotto or running
21:29 particle let's get the xkcd author to give us a logo
21:30 cotto Who was that artist who was offering to make artwork on use.perl a while back?  He might be good to hit up.
21:31 dalek parrot: r41165 | NotFound++ | trunk/src/string/api.c:
21:31 dalek parrot: [cage] add PARROT_INLINE to string_rep_compatible to document the intention and maybe give a hint to some compiler
21:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41165/
21:42 cotto There he is: http://use.perl.org/comments​.pl?sid=41743&amp;cid=66182
21:43 duk3leto etherboot's gsoc wrapup has a lot of good stuff: http://etherboot.org/wiki/soc/2009/wrapup . i think they are the most mature gsoc org
21:43 cotto Should I contact him?
21:44 duk3leto cotto: go for it
21:46 allison rebranding should wait until we have customers to brand for
21:47 Coke mikehh: 700 shouldn't have changed anything unless you're running with -q
21:50 cotto allison, you think we shouldn't ask for a new logo?
21:51 allison cotto: yes, it's too soon
21:51 allison cotto: which doesn't mean we'll have the same logo forever
21:52 cotto The sooner we get a new one, the more widespread it'll be.
21:52 allison that's why we got a new logo for 1.0
21:53 allison for 2.0 we need to build on what we have
21:53 allison and changing our identity twice in one year doesn't help
21:54 cotto I'll take your word for it.  When would be the appropriate time to start the rebranding process?
21:56 allison After 3.6, we have spare bandwidth for infrastructure and identity kinds of changes
21:56 allison Might be fun to have a "design a Parrot mascot" contest.
21:57 chromatic No infrastructure changes until August 2011 because... ?
21:57 allison because we can't afford the disruption
21:58 chromatic I find the word "disruption" very curious when applied to a logo.
21:59 allison you said "infrastructure"
21:59 chromatic You're right.  I did.  My mistake.
21:59 chromatic I still don't understand the "disruption" criteria.
22:00 chromatic We migrated from RT to Trac and SVN on perl.org to SVN on parrot.org in the months before the 1.0 release for, as I understand it, marketing and identity reasons.
22:00 allison on changing source control, ticket tracking, and website infrastructure?
22:00 chromatic Right, website too.
22:00 chromatic What makes 3.6 so special?
22:01 cotto I'd like to see a new logo before then (i.e. around 2.0), but that my preference and I'm content to leave it at that.
22:01 allison after 3.6 development shifts more into maintenance mode
22:02 allison (not to say that we won't have new development)
22:02 cotto That's how we think it'll be now.
22:02 allison sure, plans change
22:02 jrtayloriv I've deleted three files from the GC refactor branch. I'm trying to do "perl tools/dev/mk_manifest_and_skip.pl" to update the MANIFEST. But this doesn't seem to be working -- I am still getting errors from Configure.pl and during make about the "missing" files.
22:02 chromatic I'm not willing to commit to any vision of the future in two years.
22:02 jrtayloriv Is this not the proper way to do this?
22:02 allison but, this isn't a statement of "we'll instantly make X and Y changes at 3.6"
22:02 cotto jrtayloriv, did you do svn add?
22:03 cotto allison, of course not.  That kind of promise wouldn't make sense.
22:03 jrtayloriv cotto, No I didn't.
22:03 allison It's "we know we have rapid development cycles through 3.6, so we'll delay these kinds of changes for now, and consider them then"
22:04 cotto jrtayloriv, highly recommended. ;)
22:04 mikehh darbelo: looks good - make test and make testj PASS running fulltest
22:04 jrtayloriv Would I do that for deleting files?
22:04 cotto svn del
22:04 jrtayloriv ah :) thanks
22:04 cotto (then reupdate the manifest)
22:05 chromatic 3.6 smells like an arbitrary magic number.
22:05 allison chromatic: is is
22:05 allison it is
22:05 allison I'm mainly just saying "not now"
22:05 chromatic How many of the rest of us have to say "We could really use this now?" before you'll consider relenting?
22:05 darbelo mikehh++ # Testing the random whims of other people :)
22:06 allison chromatic: you really need a new logo?
22:06 chromatic Consider it a general question not tied to anything specific.
22:06 allison then 5
22:06 chromatic The architect gets five votes and other committers get one?
22:07 allison no, seriously, if there is an infrastructure piece that's a serious blocker, we can work it into the plan
22:07 allison so far I haven't seen one
22:08 chromatic Nine months of no trac2email hampered me severely.
22:08 allison aye, but keep in mind that that was aftermath of the last infrastructure changes
22:08 chromatic Yes, and I'm not pleased with how those happened.
22:08 allison it took us that long to enable all the functionality that various developers needed
22:09 allison the "no infrastructure changes until 3.6" is largely a reaction to the change overload leading up to 1.0
22:09 chromatic I think that's the wrong lesson to take from that overload.
22:10 allison the main lesson I took away is "change distracts developers from their real work"
22:10 allison which doesn't mean all change is bad
22:11 allison just that it comes with a cost
22:11 chromatic The arbitrariness of those changes were the worst part, for me.
22:11 allison arbitrary how?
22:11 chromatic No one asked "Hey, does this change help you?"
22:11 chromatic No one asked "Hey, does this change hurt you?"
22:12 chromatic All I heard was "We have to make this change before 1.0, because *marketing*."
22:12 allison I don't think "arbitrary" is exactly the word you're looking for
22:12 allison and, it had nothing to do with marketing
22:12 chromatic Getting perl.org out of the domain names seems like a lot to do with marketing.
22:13 allison somewhat, but we could have installed RT on the new servers
22:13 allison but, everyone had been complaining about RT for years. It *was* a blocker
22:13 chromatic Sure, now I'm complaining about TT.
22:13 chromatic It still doesn't do what RT did.
22:13 allison and nothing is perfect
22:13 chromatic RT was not a problem for me.  Migrating from RT to TT was arbitrary, for me.
22:13 allison it does a lot more than RT did
22:13 Tene Not even Parrot?
22:14 allison Tene: not even Parrot :)
22:14 chromatic svn.perl.org was not a problem for me.  Migrating to svn.parrot.org was arbitrary, for me.
22:14 allison chromatic: that one was a very lo-cost change
22:14 allison and, it bought us some good features
22:14 chromatic The SVN one was, as it turned out.
22:14 allison I use the Trac source browser all the time
22:14 allison it's wonderful
22:14 beta joined #parrot
22:14 chromatic ... after we bought a week for other people to prepare and effectively forced Rakudo to switch to Git.
22:15 allison Rakudo could have stuck with SVN
22:15 allison Ask and Robert even had a repo set up for it
22:15 chromatic But they didn't.
22:15 allison no, but that was their choice
22:16 chromatic Sure, but the *timing* of their choice wasn't their choice.
22:16 allison it was about to happen anyway
22:16 allison we had been talking about it for months
22:16 chromatic Okay, let's get more concrete.
22:17 chromatic Are you willing to consider migrating to Git before the magic number 3.6 if five other committers ask for it?
22:17 allison Honestly, my biggest hold on Git has nothing to do with release numbers.
22:17 allison Git isn't ready for prime-time.
22:17 chromatic In English, please.
22:17 allison Git sucks
22:18 allison but, it might be better in a couple of years
22:18 chromatic Are you willing to consider migrating to Git before the magic number 3.6 if *ten* other committers ask for it?
22:18 allison no
22:18 chromatic Are you willing to consider migrating to Git before the magic number 3.6 if *twenty* other committers ask for it?
22:18 allison no
22:19 allison what would migrating to git buy us
22:19 chromatic Branching and merging that works.
22:19 allison the git users have a git interface
22:19 allison people can create git branches now
22:20 chromatic Sure, and working with branches through git-svn is exceedingly painful because Subversion branches are exceedingly painful.
22:20 dalek parrot: r41166 | mikehh++ | trunk/src (2 files):
22:20 dalek parrot: codetest failures - Found tab in leading whitespace
22:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41166/
22:20 szbalint in which ways is git inadequate? just general curiosity...
22:20 allison subversion branches are basically just patch sets
22:20 chromatic Which is why subversion branches do not work.
22:20 allison you can create a patch set from anything
22:20 allison even git
22:21 allison it's why they do work
22:21 chromatic Not if you want to merge without babysitting them.
22:21 allison I don't have any trouble with svn merging
22:21 jrtayloriv cotto, I deleted the files using svn del, ran mk_manifest_and_skip and am now getting errors about missing the object files for the source files I deleted. Is there something else I needed to do? Should I just manually edit the Makefile to remove the references to them?
22:21 chromatic Try merging your PCC branch back to trunk then.
22:21 chromatic You will not enjoy it.
22:22 allison not straight, I'll create a fresh branch before merging it back in
22:22 chromatic QED.
22:22 mikehh darbelo: fulltest passes with the patch (except codetest, not your fault - just fixed that)
22:22 allison actually, I'll probably do that soon anyway
22:22 darbelo mikehh++ # FULL-Testing the random whims of other people :)
22:23 darbelo jrtayloriv: try running Configure.pl again, that wil regenerate the makefile for you.
22:23 allison choosing between a simple task of creating a fresh branch  a couple times a year and the pain of git every day? not difficult.
22:23 cognominal joined #parrot
22:23 jrtayloriv darbelo, I did -- I ran make realclean; perl Configure.pl; make
22:23 jrtayloriv (after doing svn del and mk_manifest_and_skip)
22:24 chromatic Back to the concrete questions though.
22:24 darbelo Can you do a mk_manifest_and_skip again?
22:24 chromatic Are there other things besides Git where the architect gets more than five votes and every other committer gets one?
22:25 jrtayloriv darbelo, yes. just did.
22:25 allison huh?
22:26 darbelo I'm out of ideas then. Try fire.
22:26 jrtayloriv :)
22:26 chromatic You said there's no way you'll let Parrot migrate to Git for a couple of years, even if twenty committers think it's the right thing for the project.
22:26 NotFound jrtayloriv: What files?
22:26 purl rumour has it files is reduntant, imho
22:26 allison that's not exactly what I said
22:26 chromatic Okay.  What did you mean?
22:26 jrtayloriv NotFound, generational_ms.c, incremental_ms.c
22:26 duk3leto i find that svn gives me way more pain than git. it's all relative
22:27 chromatic I found that Git was painful to learn, but after a few days, it made a lot more sense and made many things much easier.
22:27 szbalint Git lacks a proper learning curve, it just dumps a full blown DVCS on you from the 1st second. But svn is terribly slow and fragile. Sharing code sucks, branching sucks.
22:28 NotFound jrtayloriv: I think you must hand edit the template for the Makefile
22:28 allison chromatic: (you know, these kinds of long running hyperbolic no resolution conversations were more fun in person)
22:28 cognominal joined #parrot
22:28 chromatic I'm not interested in hyperbole.  I just want to know the rules.
22:28 duk3leto git is scary for the new user, but exponentially more powerful for the power user.
22:28 jrtayloriv NotFound, OK -- thank you.
22:28 Tene szbalint: the main thing is that some people just really hate git.  I've never really heard any real objections beyond "It's bad, and some people don't know it."
22:29 duk3leto allison: yeah, then at least beer can be involved :)
22:29 allison duk3leto: the one thing we can't afford now is scaring new developers
22:29 NotFound My objection is: I don't know how to use it, and I haven't seen any suggestion of a good quick guide or tutorial.
22:29 pmichaud "scaring new developers" hasn't been an issue for rakudo, fwiw
22:29 jrtayloriv NotFound, edit config/gen/makefiles/root.in, correct?
22:29 chromatic I find the phrase "scaring new developers" hyperbole myself.
22:29 szbalint Parrot is more scary than git tbh
22:29 NotFound jrtayloriv: that is, yes
22:29 chromatic szbalint, exactly.
22:30 allison pmichaud: I tried making a couple of patches for Rakudo and gave up
22:30 allison SVN gives people lots of options
22:30 pmichaud allison: fair enough.  Did you follow our guidelines for creating patches on the wiki page?
22:30 duk3leto allison: i started submitting patches to rakudo as soon as it went to git, so it is all relative
22:30 allison if you like git, you can use a git interface
22:30 chromatic allison, that was my first experience with Git and Rakudo too, but it's really not that difficult.  It's a different way of thinking in one step and that's about it.
22:31 duk3leto if we have more devs using git-svn to commit to parrot than svn, then we have a problem.
22:31 szbalint actually, with git-svn git users have to go the extra mile not to break svn. So it's svn^2...
22:31 Tene szbalint: I disagree.
22:31 allison "different way of thinking" == time to adjust == code not written
22:32 pmichaud I think it's just "code delayed"
22:32 szbalint at least wrt to branches
22:32 pmichaud but after that point more code happens quicker.
22:32 allison I don't buy it
22:32 chromatic Better code too, I think.
22:32 Tene szbalint: git-svn eases the pain of svn, not makes it worse.
22:32 duk3leto szbalint: git users have to go the extra mile to shoot missiles through a pea-shooter :)
22:32 allison a source control system doesn't have the power to make people write better code
22:32 Tene Hyperbole.
22:33 pmichaud allison:  fair enough, again.  But my experience with git has been that it has made it much easier for us to incorporate new developers into Rakudo
22:33 duk3leto i can honestly say that my parrot productivity hinges on the ability for me to make local branches and work on many things simultaneously, which svn makes extremely difficult
22:33 szbalint Tene: It fixes some points, but makes others worse. It imposes svn like workflow on git users and that feels highly unnatural...
22:33 allison duk3leto: I don't see why
22:33 chromatic Yep, local branches (and shareable local branches) make a huge different in productivity.
22:33 chromatic s/different/difference/
22:33 duk3leto allison: don't see why about what?
22:33 allison duk3leto: in theory, git is great at merging changes, so why can't you merge on a current fresh copy of trunk?
22:34 allison then commit that back
22:34 Tene szbalint: the workflow is still nicer for me than a plain svn workflow is.
22:34 duk3leto allison: i think we are talking past each other. i don't quite get what you are getting at
22:34 Tene duk3leto: I do a lot of local branching with git-svn.
22:35 duk3leto Tene: yes, that is what i am talking about
22:35 allison duk3leto: I don't see that it makes any difference what format the ultimate "master" repo is in
22:35 Tene duk3leto: and allison's point is "You can already do that with git-svn, so why do you need to migrate parrot's repo to git?
22:35 allison duk3leto: you can make an infinite number of git branches
22:36 chromatic Git was just an example.
22:36 chromatic All I want to know is the list of decisions where the architect has super veto powers.
22:36 allison I was just reading "Market Forces"
22:37 duk3leto allison: i honestly think that it a git repo will make the release manager's job easier, as well as those that merge branches. just my opinion
22:37 allison had this sudden picture of us road racing for it... :)
22:37 allison chromatic: take a step back, what are you looking for?
22:38 chromatic I want to know what not to bother working on, because you will reject it even if everyone else is neutral or positive about it.
22:39 allison being the architect isn't about veto power, it's about being the person willing to take the overall perspective, think through all the options, and sometimes make a decision that a few people don't like because it's better for the whole
22:39 duk3leto allison: i think chromatic would like to know "when can the parrot architect veto the opinions of other devs?" always,never,sometimes, in these subsystems....
22:39 allison it's about listening to everyone
22:39 duk3leto allison: we all value your leadership, some of use just want clarification about it
22:40 chromatic duk3leto has it.
22:40 allison so, I could both say "on anything" and "on nothing" and both would be true
22:41 duk3leto allison: can I observe you so that you settle on one of those states? ;)
22:42 allison I am the Quantum Superposition :)
22:42 rg joined #parrot
22:43 NotFound allison: just be carful with that black box.
22:43 allison chromatic: I'll never reject arbitrarily, and will always explain my reasoning
22:43 Whiteknight I'm fine with the architect model we're using, in so far as it hasn't blocked useful development and allison has been able to give a very high-level perspective on some issues
22:44 duk3leto perhaps we need to make a group decision like (for example): when X% of core parrot devs are using version control system Y, then we should switch to Y
22:44 allison duk3leto: ultimately that leads to a mess
22:44 pmichaud duk3leto: except that "core parrot devs" aren't the reason given for not switching to git :)
22:44 Whiteknight that's no less arbitrary then decison by fiat
22:44 allison it's not about voting, it's about the health of the project
22:44 chromatic Apache projects seem to handle voting.
22:45 NotFound duk3leto: and annoy (100 - X)% ?
22:45 Whiteknight I could turn around immediately and say "why not mercurial?"
22:45 allison if 51% of developers agree on something, chances are it's actually the right thing
22:45 * Tene votes for rewriting the config system in ruby.
22:45 allison I prefer mercurial to git
22:45 allison bazaar too
22:45 chromatic Let's vote on the JIT deprecation and removal then.
22:45 NotFound Whiteknight: yeah, keying just 'hg' is a lot less repetitive effort
22:46 allison chromatic: the reason I asked for time there is to look over the options
22:46 duk3leto allison: if there are more parrot devs that want to use HG over git, i will learn HG.
22:46 NotFound 2/3 of svn
22:46 allison (that "take the big picture" thing that is my job)
22:46 Tene I learned SVN to work on Perl 6.
22:46 allison chromatic: I'm about half-way through a message to the mailing list
22:47 allison or was, before I got into this
22:47 allison would have had it sent already
22:47 Whiteknight Any particular solution to the JIT dilemma is less important to me then having *a solution*
22:47 chromatic Basically I dislike all decisions by fiat.
22:47 duk3leto NotFound: annoying (100-X)% is better than annoying X% when X>50 :)
22:47 Whiteknight and if it's not a solution I like, I just won't work on it like I would have. I vote with my tuits
22:48 Whiteknight and when I run out of things I am interested in doing for parrot, I will disappear into the night
22:48 NotFound duk3leto: but nothing talked aout majority, just about greater than some arbitrary value.
22:48 allison Whiteknight: yup, it's a volunteer project, that's how it works
22:49 Tene Whiteknight: I've disappeared into the night dozens of times... I always keep coming back.
22:49 NotFound Batman!
22:49 Limbic_Region joined #parrot
22:49 Whiteknight I have a personal interest in learning new things and developing cool new features. So long as that engine keeps running, I'll be a parroteer
22:49 duk3leto NotFound: the arbitrary value was assumed to be approaching 100% :) like if 75% of our devs are using git-svn, WTF?
22:49 allison chromatic: most things around here just happen, there's only a few critical points that really need the extra thought processes
22:50 duk3leto Whiteknight++ # vote with your tuits
22:50 NotFound duk3leto: I don't know why you are assuming that, even when several people here is talking in other direction.
22:50 allison chromatic: I tend to think of it as a useful service to the group
22:50 Whiteknight and a lot of things we run past allison for a quick sanity check before they "just happen"
22:51 Tene NotFound: he said "if".
22:51 chromatic I have no objection to sanity checks.
22:51 duk3leto NotFound: it is just a gedankenexperiment, dude :)
22:51 Tene I have objections to sanity.
22:51 allison it's interesting though, I had an idea a couple of months ago, about deputizing sub-architects for particular domains
22:52 chromatic I don't like that idea.
22:52 allison like, say, a sub-architect for the I/O subsystem
22:52 allison the risk is inconsistency
22:52 Tene We already have that, informally.  If I want to talk about IO, I ask Whiteknight.
22:52 ruoso joined #parrot
22:52 chromatic Yep.
22:52 Tene If I want to talk about segfaults, I ask chromatic.
22:52 chromatic Why make it more formal?
22:52 duk3leto NotFound: if 90% of parrot devs used mercurial, does it make any sense to stay in svn? that is all I was trying to get at. i am not trying to push git on people
22:52 NotFound Hey, I'm not upset :)
22:52 allison the gain is if someone has a question about something, they can get an answer from more sources
22:52 allison yeah, that's fair
22:52 Tene We could certainly make a wiki page of some of the shared knowledge.
22:52 Whiteknight allison: I don't like the idea of sub-architects. at least not official ones
22:53 allison it does work pretty well now
22:53 Whiteknight some people will be recognized as experts on their merits
22:53 allison Tene: I like that
22:53 Tene "Here's some people who have done extensive work on some systems"
22:53 Tene If someone wants to talk about exceptions, they usually end up asking me.
22:53 chromatic I much prefer consensus among committers, at least those who care enough to express an opinion.
22:53 Whiteknight and we definitely want to reduce the ivory tower effect. knowledge and responsibility should be spread
22:53 allison yeah, kind of "if you have questions about X, these people are good resources"
22:53 Tene Or HLL interop.
22:53 purl i think hll interop is largely unaddressed and unsolved
22:53 Whiteknight chromatic: it is nice to have somebody to break up a bikesheding session though
22:53 pmichaud rakudo has informal sub-architects, it works great.
22:53 Tene purl: Eh, not quite so much anymore.
22:53 purl Tene: excuse me?
22:54 chromatic Sure, you need that.  I recognize that.
22:54 duk3leto getting our tribal knowledge on a publicly searchable wiki is definitely A Good Thing
22:54 Tene So who's the "wiki page namer architect"?
22:54 allison Tene: Chaos?
22:54 purl Chaos is _the_ answer
22:54 duk3leto tene: so nice of you to volunteer :)
22:54 chromatic If we can't come to a near unanimous consensus, we need someone to recognize that.
22:55 duk3leto purl, chaos is also sensitive dependence on initial conditions
22:55 purl okay, duk3leto.
22:55 Tene duk3leto: https://trac.parrot.org/pa​rrot/wiki/l3to_is_a_hoser
22:55 chromatic I don't think that necessarily implies we need to feed all decisions through one person.
22:55 allison yeah, unanimous consensus is ideal, but isn't always possible
22:55 chromatic I don't like blockers like that and I don't like decisions by fiat.
22:55 NotFound BTW some people talked about blog entries on www.parrot.org but no one give a clue on how to do that.
22:55 allison chromatic: my brain is here to serve
22:55 Whiteknight the architect team model works in so far as we have the right person for the job. I don't think we would suffer it under many people besides allison
22:56 Whiteknight (not that we are suffering under allison, we would likely suffer witout her)
22:57 chromatic I don't think we especially *need* an architect role though.
22:57 allison when I go away for a while, things get mixed up
22:57 chromatic We need someone to keep our minds on the ultimate vision and to help us figure out milestones toward that vision....
22:57 chromatic But "architect" in the sense of "lead designer"?
22:57 NotFound Duck architecting?
22:57 chromatic I don't see it.
22:58 chromatic Duchitecture?
22:58 allison chromatic: that's semantics
22:58 chromatic Yes, words mean things.
22:58 allison chromatic: well, I've seen you as taking on the project manager role lately
22:58 allison but, that's different than architect
22:59 chromatic Maybe the word I want is more "Goal Downer" or "Visionary".
22:59 allison is this you volunteering for a role?
23:00 jrtayloriv sockem boppers ... we need sockem boppes
23:00 chromatic That wasn't my intent, no.
23:00 allison that's what it sounds like
23:00 allison we could revive the project manager role
23:00 allison by whatever name
23:01 pmichaud istr we had a discussion about this at yapc::na
23:01 Tene Aw, everything happens at yapc.
23:01 cotto the discussion was summarized on the wiki
23:01 kid51 joined #parrot
23:01 cotto https://trac.parrot.org/parrot/wiki/Yapc10Bof
23:02 cotto (my that was a lot of backscroll)
23:02 Tene next I'll hear they had free pie and cocoa butter foot massages at yapc.
23:02 Whiteknight a project manager role might be nice. I've been hoping release managers would take more of an active management stance during "their" month
23:02 Tene that's a good idea to try.
23:03 chromatic My biggest understanding from the YAPC meeting is that we needed to experiment with new approaches to #ps to focus our development.
23:03 NotFound Just make sure parrot development doesn't become a role playing game ;)
23:03 chromatic I think that's shown some success.
23:03 allison Whiteknight: some do, but not all
23:03 pmichaud istr we also decided that "project manager" role didn't feel like the right answer
23:03 allison I do like the new #ps structure
23:03 Tene NotFound: take that up with masak. ;)
23:03 allison it's more focused
23:03 chromatic That's my understanding too, pmichaud.
23:04 allison ooh, wait, I have a photo of the notes here...
23:04 NotFound cotto: the conclussion from that wiki page is: our meetings lack a good hait stylist X-)
23:04 chromatic Ultimately, my preference is that any "architect" or "Goal Donor" or "Visionary" role be able to help us prioritize milestone tasks.
23:05 NotFound s/hait/hair
23:05 chromatic Perhaps that means we need to do more collective design and code review.
23:05 chromatic That came up in the YAPC meeting too.
23:05 allison the hard part there is getting anyone to pay attention to the priorities
23:05 Tene Anyone willing to express a preference on "Parrot Gurus" as a name for the "Ask these people about these subjects" wiki page name?
23:05 chromatic +0
23:05 purl 0
23:06 darbelo 0+5i
23:06 NotFound -NaN
23:06 Tene ;_;
23:07 chromatic I think we've improved our focus on priorities, largely after the #ps changes.  Does anyone else have opinions?
23:07 Whiteknight agree
23:08 NotFound I like the idea of short test coverage goals, it gives short task to do when a free moment happens.
23:09 cotto It seems to be effective, modulo our small sample size.
23:09 * allison gives up the fruitless search for the photo, ah well, they're on my wall back in the ON office
23:10 Whiteknight no matter what our "priorities" are, people are still going work on whatever catches their fancy
23:10 Whiteknight it's not so much about simply having priorities as it is motivating people to tackle them
23:10 Tene Maybe a CurrentParrotCommitters page, listing a map from active committers to subsystems/topics?
23:10 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41166 - Ubuntu 9.04 i386 (g++)
23:10 Whiteknight a "project manager", while maybe not ideal, could do a lot to motivate people
23:11 allison Tene: ParrotResources?
23:11 Tene That works.
23:11 allison Tene: ParrotOralDocumentation?
23:11 allison er, OralTradition
23:11 Tene re l3to, TribalKnowledge or CommunityKnowledge
23:11 darbelo TribalKnowledge++
23:12 allison CommunityKnowledge has a nice ring
23:12 NotFound PetShopKnowledge
23:12 jrtayloriv The Knowers
23:13 Tene anyone willing to express an opinion on whether it should be a map from topics to people or from people to topics?
23:13 bacek joined #parrot
23:13 darbelo BikeShedKnowledge!
23:13 Tene Heh.
23:13 chromatic Topics -> people
23:13 * Tene agree.
23:14 pmichaud perhaps I'm misreading things, but my impression of discussions in the past few weeks has been more about "removing blockers" than "figuring out priorities"
23:14 cotto darbelo++
23:14 allison removing blockers is one priority
23:14 pmichaud current deprecation policy has been seen as a blocker.  JIT has been seen as a blocker.  Etc.
23:15 pmichaud (I'm not arguing merits here -- I'm meta-discussioning an observation)
23:15 allison I see
23:16 allison there's a balance between constraints and freedom
23:16 pmichaud and most of the tension seems to be about finding that balance
23:16 allison a certain level of constraints improves productivity (coding standards, for example)
23:16 pmichaud some feel (rightly or wrongly) that svn is an ongoing constraint to their productivity, for example
23:17 allison excessive constraints, can hinder it
23:17 NotFound The problem with JIT is the ratio benefit/annoying is extremely low.
23:17 allison yes, but so far they haven't put forth very convincing arguments that svn is hampering their productivity
23:17 pmichaud I suspect that they would claim the reverse is true :)
23:18 pmichaud I hate to tangent off like this and then leave, but there's a family priority occuring here so I have to disappear :-|
23:18 allison and you have to balance that against the certain effects of change hampering productivity
23:18 dalek parrot: r41167 | jrtayloriv++ | branches/gc-refactor (9 files):
23:18 dalek parrot: Removed everything related to GMS/IMS ... bye bye
23:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41167/
23:19 duk3leto Tene: i like TribalKnowledge, but the name isn't that important
23:19 * kid51 reads backscroll and wonders:
23:19 kid51 jrtayloriv:  Are you still having problems with mk_manifest_and_skip.pl?
23:19 Coke allison: I find the 'merging is often hard and broken' a compelling argument.
23:19 duk3leto coke++
23:19 jrtayloriv kid51, no -- I got it worked out. I just had to manually edit the Makefile template.
23:20 Coke I don't often have that trouble myself, but I certainly think it's a valid reason for others.
23:20 Tene https://trac.parrot.org/parrot​/wiki/ParrotCommunityKnowledge -- Everyone please go add and remove yourself as appropriate. :)
23:20 Coke s/often/recently/ (actually used to have it quite a bit.)
23:20 allison Coke: I would too, if I thought git would solve it
23:20 pmichaud allison: the argument seems to be coming from people who have used both git and svn; I think they're qualified to speak to their experience
23:20 allison Coke: in my experience a simple one line patch in git is more pain than the most extensive svn branch
23:21 kid51 Coke:  Here I agree with Allison.  I suspect that you can have < optimal branching practices in any VCS.
23:21 kid51 and that's what makes merging painful.
23:21 chromatic Subversion's handling of file contents makes merging painful.
23:21 Coke kid51: ok. now find me an optimal way to do it in svn. =-)
23:21 duk3leto allison: perhaps that is because you have a grudge against git? ;)
23:21 dalek tracwiki: v1 | tene++ | ParrotCommunityKnowledge
23:21 dalek tracwiki: First draft; please review.
23:21 dalek tracwiki: https://trac.parrot.org/parrot/wiki/ParrotC​ommunityKnowledge?version=1&amp;action=diff
23:21 kid51 Coke:  I've probably done more branches and merges here than anyone else.
23:22 pmichaud kid51: you haven't done more than I.
23:22 allison duk3leto: I don't like it, but I wouldn't call it a grudge, any more than I'd say you have a grudge against svn
23:22 pmichaud kid51: perhaps you've done more *in Parrot* than me
23:22 chromatic Yes, but duk3leto has actually *used* SVN successfully.
23:22 kid51 pmichaud:  That's what I was referring to.
23:22 hercynium joined #parrot
23:22 pmichaud kid51: that's kind of a circular argument, then, isn't it? ;-)
23:23 kid51 But I also do SVN branching and merging extensively on $job, and have trained others there as well.
23:23 chromatic I've *renamed files* in a SVN branch.
23:23 chromatic This is the part where you all shudder.
23:23 Coke chromatic: that's hardcore.
23:23 Coke (seriously. svn blows for that.)
23:23 chromatic West siiide.
23:23 pmichaud okay, I have to go... back later, hope you all can work it out.
23:23 Coke core svn developers say "don't do that."
23:23 chromatic I'm inclined to agree with them.
23:23 Coke me too.
23:23 duk3leto allison: i use svn all day at work every day. I might have a "grudge" against svn, but that is because I use it extensively. it seems that you base a lot of your git experience on trying it a very small number of times
23:24 Coke here's a thought experiment.
23:24 allison duk3leto: if everyone used git-svn how would that differ from hosting git?
23:24 Coke git-svn NE git.
23:25 chromatic git-svn ameliorates many of the pains of SVN.
23:25 duk3leto allison: we would all want to die :) seriously, git-svn is like sitting in an iron maiden.
23:25 dalek tracwiki: v2 | dukeleto++ | ParrotCommunityKnowledge
23:25 dalek tracwiki: https://trac.parrot.org/parrot/wiki/ParrotC​ommunityKnowledge?version=2&amp;action=diff
23:25 chromatic Less hyperbole I think would help the discussion.
23:25 allison hyperbole, but I understand what you mean
23:25 * Tene is starting to notice that l3to is fond of hyperbole.
23:25 szbalint git-svn disallows git - git development
23:25 Whiteknight I have yet to see something reasonably approaching a new users guide to git
23:25 * duk3leto takes it easy on the hyperbole
23:25 Tene Coke: thought experiment?
23:25 Coke (thought experiment) have the official svn repo. have a single git-svn repo that sits on top of that..
23:25 duk3leto Whiteknight: specific to parrot or for git in general?
23:25 szbalint or at least it is recommended not to do that
23:26 Coke (TE) give ouut commit bits to that repo only to folks with CLAs.
23:26 Whiteknight all documentation I've seen wants to show me dozens of graphs, but nothing that says "type X to do Y"
23:26 Coke (TE) they treat it just as git. eventually all commits to master there are pushed to svn trunk.
23:26 Whiteknight duk3leto: git in general. I have no idea in hell how to use it
23:26 Whiteknight I might use it if I could learn how
23:26 duk3leto we currently have a git-svn mirror of parrot that is updated every day (this is different than my github mirror, which is pure git). i need to get people the info for that
23:26 NotFound Whiteknight: I said the same some pages ago and no one asked
23:27 Whiteknight I'm tired of looking at page after page of repository modification graphs, and hearing paragraphs about how great git's system is
23:27 allison Coke: ah, that raises the question that keeps coming back to me. If git is distributed source control, why do people keep asking for a centralized git server?
23:27 szbalint because git-svn disallows git - git development
23:27 Coke at this point? I want ... right.
23:27 Coke because it's svn at the bottom.
23:27 cotto jrtayloriv++
23:27 Whiteknight allison: that's a decision that projects can make
23:27 Tene allison: git happens to not enforce any specific model.  that doesn't mean that an official server isn't useful.
23:27 szbalint person A using git cannot collaborate with person B using git if it has to end up in svn eventually
23:28 allison szbalint: and what is git - git development?
23:28 allison szbalint: why not?
23:28 chromatic Suppose szbalint starts a branch in Git and publishes it, and I want to work on that branch too.
23:28 allison (I'm collecting information here)
23:28 Coke and also, parrot is going to have a single "master" at some point.
23:28 chromatic git - git I could clone his branch and work on it.
23:28 szbalint because svn is flat WRT commits, git isn't
23:28 allison yes, and why doesn't that work with git-svn?
23:28 chromatic git - git I could even push some or all of my changes back to a master repository or *any other repository* anywhere.
23:28 Coke (because, presumably, that's where we'll cut the release from. but we don't /have/ to do it that way.
23:29 Util Whiteknight: http://use.perl.org/~jdavidb/journal/36220 says about http://www-cs-students.sta​nford.edu/~blynn/gitmagic/ :
23:29 Coke allison: because git-svn isn't git. =-)
23:29 Util Git Magic is sort of a "Git Cookbook" in that it focuses on short, simple Git "recipes," often demonstrating powerful things you can do with Git that you could not have done with other VCS systems, and often demonstrating applications you would not have thought of for "version control."
23:29 allison Coke: well, the way Linux does it, the way git was designed to work, releases are cut from Linus's Git repo
23:29 Tene whiteknight, notfound: http://gist.github.com/183330
23:29 Coke allison: that's fine. you can be the master.
23:30 allison and, that's determined by linus deciding what does and doesn't make it it
23:30 NotFound Util: I don't like poweful things that no other system can do, I just want plain simple rutinary tasks.
23:30 allison Coke: curiously, that was my original objection to Git, that I didn't have time to be the Git master
23:31 Coke that's fine. I don't think git is going to force us to have a linus. that makes the master convenient, because we don't have that guy.
23:31 Tene allison: we can do it however we like.  The traditional way to work is to have a master server that some number of committers have rights to push to.
23:31 allison I'm asking alot of questions because I really want to understand
23:32 Tene (in linux's case, just one person, linus)
23:32 Coke which we can do just like svn. anyone with a CLA can have comit bits to mastr.
23:32 szbalint git history isn't linear, so merging changes back to svn is risky because it has to flatten things, which ends up wiping out history and worse afaik. There is a big don't do it recommendation for git-git collaboration coming with git-svn at least...
23:32 dalek tracwiki: v96 | jkeenan++ | WikiStart
23:32 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​WikiStart?version=96&amp;action=diff
23:32 dalek tracwiki: v3 | jkeenan++ | ParrotCommunityKnowledge
23:32 dalek tracwiki: https://trac.parrot.org/parrot/wiki/ParrotC​ommunityKnowledge?version=3&amp;action=diff
23:32 Tene it's *convenient* to have a central server we can all push to.
23:32 Util NotFound: In general, me too; I am a SVN holdout, and taught Atlanta.pm to reject DVCS until they had a real need for the 'D'. Whiteknight wanted something like a cookbook, and I just helping.
23:32 allison Git is supposed to be a powerful merging took, and I don't see why it can't merge between two separate branches created from the same SVN root
23:33 duk3leto Whiteknight: i think your cookbook idea is very good. if you push me enough, I might write it for you :)
23:33 chromatic Because you throw away information when you go from Git -> SVN.
23:33 duk3leto allison: because svn loses information
23:33 Coke embedding is jhorwitz
23:33 Tene allison: It can, the problem is that things go all screwey when you push it down into SVN.  You *can* do it, it's just not convenient.
23:33 allison sure, but you have that information in the git repos
23:33 * darbelo pushes duk3leto
23:33 * duk3leto falls down
23:33 purl I swear *hic*, you just made the earth *hic* move for me.
23:34 NotFound Util: but that description sounds like a Master in High Cuisine more than like a cookbook ;)
23:34 chromatic There's also something screwy when you go from SVN -> Git, at least if you update, which looks like it requires a rebase.
23:34 Tene allison: What ends up happening is that you lose the commits and recreate them in SVN, so anything anyone else did on top of your branch needs to be re-applied on top of the re-made new svn branch.
23:34 Tene iirc
23:34 chromatic You don't want to rebase anything anyone else has branched from, lest you orphan some of their committed objects.
23:34 Whiteknight duk3leto: I need a cookbook that can do 4 things: checkout, commit, update, merge
23:35 Whiteknight and I might like diff and patch too
23:35 Coke Whiteknight: for git only, or for git-svn on parrot?
23:36 Tene We already have that for git-svn on parrot.
23:36 Whiteknight Coke: I can't currently do either, so...both
23:36 Tene So I think he wants git on its own.
23:36 Tene I'll start a wiki page for it.
23:36 duk3leto Whiteknight: ok, written down.
23:36 Coke there's a wiki page for git-svn on parrot that we can add to.
23:36 duk3leto Coke: that page is getting a bit crazy
23:36 Coke yah, needs editorial cleanup.
23:37 Coke we've got the "vomitous mass of information" down!
23:37 Tene It seems a bit messy to put them both on the same page.
23:37 allison hmmm.... those sorts of problems (with git-svn) sound like the reasons I don't find git appealing
23:37 duk3leto Tene: i agree. i will make a seperate page
23:37 duk3leto allison: the problems are with svn, not git :)
23:38 Tene duk3leto: NO IM DOING IT
23:38 NotFound For git - git on parrot when that things exist, or supposing it already exists
23:38 Coke NO KITTY!
23:38 duk3leto Tene: do it, i dare you :)
23:38 Tene duk3leto: https://trac.parrot.org/parrot/wiki/GitCookbook
23:38 szbalint http://utsl.gen.nz/talks/git-svn/intro.html # this description of git-svn is pretty good
23:39 dalek tracwiki: v1 | tene++ | GitCookbook
23:39 dalek tracwiki: first draft real fast to beat l3to
23:39 dalek tracwiki: https://trac.parrot.org/parrot/wiki/G​itCookbook?version=1&amp;action=diff
23:39 cotto Tene wins.
23:39 allison has anyone here tried mercurial or bzr?
23:40 Tene I've used hg a couple of times... I don't remember anything notable about it.
23:40 chromatic I've used hg.  It's decent.
23:40 allison would you consider a change to one of them an equal solution to branching?
23:40 duk3leto Tene: yay for reverse psychology :)
23:40 chromatic Branching yes, probably.
23:40 chromatic Speed... no.
23:40 Tene Made a repo, made a few commits, made another checkout... it was pretty much the same as git.
23:41 Coke chromatic: incoming karma for you.
23:41 jrtayloriv Tene, Is that wiki page for git-svn, or git, or both?
23:41 allison there's a specific reason I ask, in that Parrot could be the speed solution for one or both of them
23:41 Coke I am tempted to move partcl to git.
23:41 allison so, it could be a case of eating our own dogfood
23:41 Tene jrtayloriv: https://trac.parrot.org/pa​rrot/wiki/git-svn-tutorial
23:41 Coke (note to past self: this is not a joke.)
23:42 jrtayloriv gotcha -- Thanks.
23:42 chromatic I don't think hg's slowness compared to Git is implementation language.
23:42 Coke allison: (speed solution) are we using the same parrot? =-)
23:42 Tene allison: "speed solution ... both" -- "both" means hg and what else?
23:42 Tene allison: nm, reading fail
23:42 allison http://code.google.com/p/support/wiki/DVCSAnalysis
23:43 allison Tene: Parrot is fast, PCT and PGE are slow
23:43 Tene allison: I think you meant that for Coke.  I was missing the fact that you mentioned bzr earlier, and then I noticed it.
23:44 dalek partcl: r701 | coke++ | trunk/docs/spectest- (2 files):
23:44 dalek partcl: YA spec test run. (chromatic++, as timings are now heading in the right
23:44 dalek partcl: direction)
23:44 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=701
23:44 Whiteknight allison: you're talking about writing our own VCS on top of parrot?
23:44 allison Whiteknight: no, at least not from scratch
23:44 allison just using somebody elses
23:44 Whiteknight like a wrapped library?
23:44 duk3leto allison: git has hand-tuned assembly to make sha1 computations as fast as possible
23:44 allison how is Git's Windows support these days?
23:45 szbalint I was just about to ask that
23:45 Coke there is tortoiseGit. meant to try it out, haven't yet.
23:45 duk3leto allison: it is a lot better
23:46 duk3leto allison: i don't use windows, so I don't know the specific, but I watch the git mailling list, and it seems that windows support is getting lots of attention. i think they had a gsoc student this summer working on win-stuff as well
23:47 * darbelo wonders if making imge_io a PMC could help clean that godawful mess in pmc_freeze-land
23:48 bacek Good morning
23:48 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
23:48 duk3leto bacek: howdy
23:48 bacek duk3leto: g'day
23:48 darbelo 'cause Y'know that yak needs a shave...
23:48 Coke so, enough of this meta-stuff. is anyone working on my poor, poor, segfaults?
23:48 Tene allison: if you can give me some specific workflows that you're concerned about, I can give you a log of running through them in git.
23:48 cotto allison, encouraging contributions seems like a non-issue.  Cloning is trivial and generating a patch is equally trivial.  From there, they can nopaste it here and people with the necessary know-how can take over.
23:48 szbalint git was written by people very close to the metal and with a specific focus on speed. The core of git is not a VCS but rather only a file tracking system...
23:49 duk3leto szbalint: you mean content-tracking system
23:49 Tene szbalint: yes, but the core of git isn't particularly relevant when using it.
23:49 szbalint yeah, content is better worded
23:49 duk3leto szbalin: also correct :) svn tracks files, git tracks content.
23:49 allison Tene: it's the basic "update" "commit" that are 10 times more complicated than they need to be
23:49 bacek Just my $0.02 about git vs svn: I've migrated Sub to ATTRibutes in one day. I've spent whole Sunday (and 2 hours on Monday) fighting with svn.
23:50 duk3leto bacek: read backscroll to know what you are diving into here :)
23:50 allison For the record, a Mercurial move before 3.6 might be a possibility.
23:50 chromatic Less hyperbole please.
23:50 Tene allison: I'm really curious about where you're getting this "10x more complicated" data from.  I really don't want to come across as saying "NO UR DOIN IT WRONG".
23:50 allison Git still doesn't sound like it's ready.
23:51 szbalint Tene: absolutely right, I just ment to hilight the fact that git is fast because of the implementor focus/knowledge
23:51 * duk3leto cranks down the hyperboleometer
23:51 * szbalint shuts up :)
23:51 chromatic Not you this time, duk3leto.
23:51 bacek for the record: not everyone willing to use Mecurial
23:51 Coke Tene: best bet on that is to write down the commands for the workflow.
23:51 Coke then we have a target we can discuss.
23:51 allison bacek: not everyone is willing to use Git either
23:51 Tene allison: Do you want mail to you or mail to the list or web page with link to you on IRC, or...
23:51 NotFound Talking about Windows, be careful with your lanmates, boys: http://seclists.org/fulldis​closure/2009/Sep/0039.html
23:51 allison we can keep talking about it until we reach consensus, though
23:52 bacek allison: Perl5, Rakudo uses git without any problems afaik.
23:52 Coke Tene: wiki seems ok.
23:52 Whiteknight as a general note, if we weren't using SVN already, I doubt there is any way we would ever switch to it
23:52 allison Tene: mail about?
23:52 chromatic Or at least the point where everyone who wants Git is so tired of the discussion that we all give up and agree with the one person who wants Hg.
23:52 allison chromatic: or bzr
23:52 allison though, really prefer svn
23:52 Tene allison: basic git workflow.
23:53 chromatic s/(one person who wants Hg)/$1 or bzr/
23:53 allison I have only heard a few people who want Git
23:53 allison maybe 3 vocal advocates
23:53 chromatic Count again.
23:53 Whiteknight a subset of people are here on IRC tonight
23:53 cotto FTR, I'd be happy to deal with the learning curve if we switched to git.
23:53 * chromatic is afk
23:54 Whiteknight a strawpoll on parrot.org would be more informative
23:54 cotto Whiteknight++
23:54 allison Whiteknight: sounds useful
23:54 duk3leto I volunteer to be Camp Counseler at the Git Re-Education Camp
23:54 * darbelo doesn't care about the VCS, solong as the commands aren't more than 3 letters long
23:54 Tene I'll be the creepy guy hanging out in the trees at night.
23:55 allison to the git advocates, can you set up a demo of handling a long-running branch merge in git
23:55 duk3leto darbelo: you want to switch to rcs?
23:55 duk3leto allison: what does that even mean?
23:55 bacek darbelo: git config --help; /alias
23:55 allison I hear people saying that git will handle the merges better, but I don't see any evidence.
23:55 darbelo duk3leto: I have installed already, so it has a headstart on git ;)
23:56 allison so, show me a demo of a handful of git branches off the same base
23:56 allison it can be a totally contrived example, doesn't have to be the parrot code base
23:56 duk3leto allison: please give me a more specific description of what you want to see
23:56 duk3leto allison: ok, i can do that
23:57 allison rename some files on one branch, overwrite the same lines of code multiple times in several branches
23:58 szbalint Btw, I'm not sure how relevant is "newbie contributor" here, since Parrot requires paperwork for a commit bit therefor it already imposes a limit on "ease of contribution" and git diff is the same as svn diff
23:58 allison especially, merge in several branches to the main, and then merge in the old and heavily modified branch
23:58 szbalint From a newbie perspective it would be a bonus to be able to develop locally with ease
23:58 cotto szbalint, we accept patches via nopaste here all the time.
23:58 duk3leto allison: ok, that is nice and specific. i am on it
23:58 bacek $dayjob time
23:58 cotto yay!  progress!
23:58 allison szbalint: we're pretty liberal in handing out commit bits
23:59 allison the worst is renaming files in one branch, and modifying lines of those same files in another branch
23:59 Tene they even gave one to me.

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

Parrot | source cross referenced