Camelia, the Perl 6 bug

IRC log for #parrot, 2009-09-10

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:05 * darbelo thinks about how nice it would be to be able to install git without the bastard pulling in half (and counting) of the GNU userland as build-deps
00:06 NotFound Forget the question, too late for me now.
00:06 purl NotFound, I didn't have anything matching question, too late for me now
00:07 dukeleto joined #parrot
00:07 cotto '40 is starting to look suspicious
00:08 darbelo cotto: Nothing after '40 touches anything even remotely related...
00:09 darbelo And somebody needs to revise the git developer's idea of 'portable'
00:09 cotto I'm checking '39
00:09 cotto darbelo, can you build it from source without the extra GNU stuff?
00:10 cotto (I imagine you wouldn't want to maintain such a build on your system, but I wonder if it's possible.)
00:11 pmichaud http://pmichaud.com/sandbox/speed-1.png  # Rakudo number of spectests run versus time to run
00:11 darbelo Haven't really tried, I just used the makefile in the ports tree. But I would expect the port author to have checked that.
00:12 pmichaud http://pmichaud.com/sandbox/speed-2.png  # spectests per second
00:13 rhr joined #parrot
00:13 darbelo I mean, I doubt anyone would list bloody *GNU tar* as a build-dep if it wasn't really needed.
00:15 pmichaud NotFound: I don't think of exception handlers as normally being run from the context where the exception was _thrown_
00:15 pmichaud often the handlers are run in the context where the exception is caught
00:16 darbelo There. I have git now. Let's go grab ourselves some rakudo!
00:18 pmichaud NotFound: if you mean that throwing an exception causes a handler to be invoked, and the caller to the handler is the context that threw the exception, then yes.
00:21 whoppix joined #parrot
00:21 NotFound pmichaud: I'm ruminating if a change in that will simplify things, storing the continuation of the throwing point in the exception object and accesing it when required.
00:24 NotFound And running the handler in the context where the push_eh was done.
00:26 NotFound If that scheme may works, the inner runloop problem can be isolated from other issues.
00:28 NotFound Going to bed, will elaborate some more the idea tomorrow
00:41 sri_ joined #parrot
00:43 GeJ_ joined #parrot
00:44 TiMBuS joined #parrot
00:47 whoppix joined #parrot
00:49 cotto it's either '38 or '39, and I'll be very confused if it's '38
00:51 darbelo not that '39 isn't confusing.
00:51 cotto it's '39
00:52 darbelo How in hell does initializing coredata->flags make the profiling runcore 10x slower?
00:54 cotto I'd *love* to know.
00:55 whoppix joined #parrot
00:56 sri joined #parrot
00:56 cotto The plot thickens.  If I make realclean, build 41138, svn up to 41139 and make install, rakudo is fast
00:57 Whiteknight what's amazing is that my coretest times keep going down
00:57 Whiteknight yet everybody else is losing performance
00:57 Whiteknight (I just ran coretest again in 37s)
00:58 cotto This is going to be an odd bug.
00:58 Whiteknight so we really need to figure out what the HLLs are relying on that coretest doesn't exercise
01:00 cotto I'd settle for "how on earth did bacek's obviously correct patch cause such oddness?"
01:00 szbalint Test::Harness matters a lot for coretest, so maybe it should be compared against the installed harness version too?
01:11 mikehh_ joined #parrot
01:14 Zak joined #parrot
01:15 Coke NotFound: #995 still happening for me.
01:19 hercynium joined #parrot
01:41 rhr joined #parrot
01:42 Zak joined #parrot
01:48 sri joined #parrot
01:56 bacek_at_work cotto: probably because flags should be runcore specific...
01:57 rhr joined #parrot
02:08 chromatic joined #parrot
02:14 rhr joined #parrot
02:28 Andy joined #parrot
02:28 dalek partcl: r709 | coke++ | trunk/runtime/builtin/glob.pir:
02:28 dalek partcl: initial version of [glob]
02:28 dalek partcl: parses (and ignores) all options, supports multiple patterns.
02:28 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=709
02:35 janus joined #parrot
02:59 Zak joined #parrot
03:15 chromatic All of the Parrot_str_to_cstring() calls in the profiling runcore are spendy.
03:35 JimmyZ joined #parrot
04:14 dukeleto 'ello
04:23 Tene hi leto
04:23 dukeleto how goes it?
04:30 Tene took a nap when I got home.  Now helping the gf with her homework and thinking about hacking.
04:39 Tene Okay, checking out the patches on TT757
04:39 Tene I don't actually undrestand enough of what's going on there to know whether it's a correct fix or not, but I can at least run parrot's tests.
04:43 kyle_l5l well, with a hll, you can at least make it a little further through clone_interpreter().  That's all that matters, right?
04:43 Tene kyle_l5l: depends on what happens next. :)
04:44 Tene get_pmc_keyed_str() not implemented in class 'Signature'
04:44 Tene yay!
04:48 Tene kyle_l5l: does tt757.pir work for you with patches 1 and 3 applied?
04:49 Tene kyle_l5l: I get a failed assertion in src/packfile.c:3071
04:50 Tene oh, nm, I think.
04:51 Tene Yeah, I was doing something stupid, nm.
04:51 kyle_l5l with just those patches at around rev 40736, yes.  I get some weird stuff with the current rev.  (But I've also added plenty of my own weird stuff.)
05:11 Zak joined #parrot
05:15 kjeldahl joined #parrot
05:37 Tene kyle_l5l: interested in helping me to debug the next error with threads?
05:37 kyle_l5l sure
05:38 Tene kyle_l5l: add a .loadlib statement to the start of tt757.pir
05:38 Tene like: .loadlib 'libsqlite3'
05:39 nopaste "tene" at 24.10.252.130 pasted "like this for kyle_151++" (16 lines) at http://nopaste.snit.ch/17901
05:39 Tene This ends up failing in the clone_libraries branch of parrotinterpreter.pmc:117
05:40 Tene that gives:
05:40 Tene get_pmc_keyed_str() not implemented in class 'UnManagedStruct'
05:40 Tene when trying to clone the interpreter with perl6.pbc loaded, I've also recieved all of the following errors from that code path:
05:40 Tene Null PMC access in get_string()
05:40 Tene get_pmc_keyed_str() not implemented in class 'Integer'
05:40 Tene get_pmc_keyed_str() not implemented in class 'ResizablePMCArray'
05:40 lnostdal joined #parrot
05:41 Tene The first two interchangeably, if I keep running it and I don't have CLONE_CLASSES turned on, the latter if I do have clone_classes turned on
05:42 kyle_l5l ok, that works for me
05:43 kyle_l5l Let me see if I can track down the fix for that.
05:44 Tene :) Thank you.  I'll keep looking, but I'm a little lost.
05:50 nopaste "kyle_l5l" at 72.230.232.130 pasted "incremental in-progress parrotinterpreter.pmc patch" (44 lines) at http://nopaste.snit.ch/17902
05:50 cotto It looks like Parrot_str_to_cstring should be expensive, but it's basically a thin wrapper around memcpy
05:52 kyle_l5l Tene, try that.  I think that's all you need...
05:55 cotto The culprit in the slowdown seems to be RUNCORE_JIT_OPS_FLAG, which was serendipitously set when coredata->flags was uninitialized.
05:56 dalek parrot: r41180 | petdance++ | trunk/lib/Parrot/Pmc2c/PCCMETHOD.pm:
05:56 dalek parrot: fixed indent
05:56 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41180/
05:56 kjeldahl joined #parrot
05:59 Tene kyle_l5l: does that modified tt757.pir work for you with that patch?
05:59 Tene It still gives me the same behavior.
05:59 Tene I also have patches 1 and 3 from tt757 applied, if that's relevant.
06:00 cotto and it seems to have an effect even when Parrot's built with jitcapable=0
06:00 shockwave joined #parrot
06:04 shockwave I'm having an issue, which I'm sure is very simple to resolved, but I don't know how: http://pastebin.com/m7ec950ae
06:04 shockwave That simple snipped gives me the error at the bottom.
06:04 Tene kyle_l5l: you updated the clone_classes fork down at line 133.  This failure happens before that, up at line 117
06:05 shockwave I don't understand the error.
06:05 kyle_l5l Tene, yeah. I'm missing another little something.
06:06 Tene shockwave: addattribute adds a field to a class; setattribute sets the value of that field on an *object* of that class.
06:06 Tene you're trying to set it on the class itself.
06:06 shockwave ah!
06:07 shockwave So that means that if I want to implement default values on instance member, I must add them everytime I make an instance?
06:08 Tene shockwave: That sounds right to me, yes.
06:08 Tene shockwave: To be specific, you must *set* them every time you instantiate.
06:08 Tene you run addattribute once on the class, and setattribute every time on the instances.
06:08 shockwave yeah, sorry. THat's what meant.
06:08 Tene Just didn't want to lead you wrong. :)
06:10 shockwave Well, then, hopefully IMCC can detect the objects' member being set once, that value not being used, and then being set again, and optimize that out.
06:11 shockwave I'm talking about in the HLL when setting default variables, and the setting them again in the constructor.
06:11 Tene I wouldn't have any hopes of IMCC doing that.  Future optimizers probably will, though.
06:11 shockwave That would map to 2 setattributes.
06:11 shockwave I'll learn to live with it.
06:11 shockwave Thanks.
06:12 Tene shockwave: iirc, Perl 6 stores the defaults somewhere else, and on object instantiation, it uses the provided value if given, or the default if no value was provided.
06:13 Tene So it doesn't do two setattributes.  Maybe.  If I remember correctly.  :)
06:13 shockwave Tene, cool. I'll try to go for something like that.
06:14 treed shockwave: What language are you working on?
06:14 shockwave treed, my own concoction. It's for programming 3D games.
06:14 shockwave I'm calling it Gem.
06:17 treed Interesting.
06:18 treed Let me know when it's usable.
06:18 treed (Or I guess playable-with.
06:18 shockwave treed, well, it's actually a generic, class based language, like a combo of Java and Ruby.
06:18 shockwave So I'm hoping to make it so that it can be embeddable into anything.
06:19 shockwave So, that eventually I can write helper scripts to run from the command line, program my website it, do my laundry ... that kinda thing.
06:19 shockwave But, for now (the first few years), it's just to drive the 3D engine I'm using.
06:20 shockwave Though, I wouldn't hold my breath. I just started last friday on it.
06:20 treed Oh, of course.
06:20 purl Indubitably.
06:20 treed Shut up, purl.
06:20 purl make me
06:21 treed I will.
06:21 treed maybe.
06:21 shockwave (I mean, on the language. The engine is working.)
06:24 nopaste "kyle_l5l" at 72.230.232.130 pasted "more patches for tt757.pir + .loadlib" (24 lines) at http://nopaste.snit.ch/17903
06:25 cotto it looks like Parrot may be switching runcores on me when that flag is set
06:25 Tene Didn't someone say that get_pointer is evil?
06:25 kyle_l5l Tene, ok, so if I apply that patch, and the previous one, on the current rev of parrot, no luck.  But if I apply them to r40736, and run with -G, it works.
06:25 Tene Hmm.
06:27 Tene kyle_l5l: It more looks to me like some things are ending up in iglobals[dyn_libs] that shouldn't be there.
06:28 cotto yup.  stupid parrot was running more quickly because it switched to the fast runcore.
06:29 cotto maybe if I instrument the fast runcore...
06:33 kyle_l5l Tene, happening in revs after 40736?
06:33 kyle_l5l is it reasonable for a Class to have a name of '' ?
06:33 Tene kyle_l5l: anonymous subclass or something, I think...
06:34 Tene kyle_l5l: I've only been working against the latest Parrot.
06:34 cotto all is sane, though disappointing
06:35 Tene I'm in #llvm right now... they just noticed our wiki page, and were shocked that we were considering libjit.
06:35 kyle_l5l aha.  I tried to update to the latest one today, but I ended up with too many new bugs
06:35 cotto bacek++ for clearing those flags and exposing that issue
06:35 cotto Tene, #llvm on which network?
06:35 treed Tene: libjit that bad?
06:35 Tene I pointed them to allison's recent mail about JIT in the archives.
06:35 Tene cotto: irc.oftc.net
06:36 Tene treed: according to llvm devs, yes.  They also disputed "Some developers claim it is difficult to use" with "where 'some developers' == 'libjit developers'"
06:39 treed Heh.
06:40 Tene kyle_l5l: new bugs?  'make test' in parrot is all passing...
06:40 Tene kyle_l5l: if there are bugs in the latest parrot, can you submit tests for them or open tickets?
06:42 kyle_l5l Tene, ah, by new bugs I mean with latest parrot + my work in progress patches, I get crashes much earlier.
06:42 Tene Ah.
06:42 cotto Tene, what does "bad" mean?  non-portable, simple, buggy?
06:43 chromatic joined #parrot
06:43 Tene "Pros: Easier to use then LLVM. Faster code compilation then  LLVM. Active development team." wow. not one of those is  true :)
06:43 Tene Tene: sorry if i sound overly negative-- i'm not opposed to  non-llvm solutions in general, but libjit in particular  holds a special place in my heart.
06:44 Tene aiee! libjit!
06:45 szbalint there sure are some strong feelings
06:47 cotto chromatic, you said that Parrot_str_to_cstring is expensive.  It's just a wrapper around memcpy.  I'm not saying that it's good as-is, but that's where it is now.
06:48 chromatic I'm running profiles.
06:48 cotto It didn't even show up when I ran the profiling runcore under valgrind.
06:49 fperrad joined #parrot
06:49 chromatic Valgrind or cachegrind?
06:50 Tene chromatic: With the llvm jit plan, we'll be generating llvm IR ourselves, instead of using llvm-gcc or clang, right?
06:50 cotto valgrind
06:50 purl valgrind is probably not only astonishingly clever, but also has a beautifully written manual. or http://developer.kde.org/~sewardj/ or an open-source memory debugger or see also cachegrind or kcachegrind or No Silver Bullet or a time saver or mostly working on FreeBSD or not working on windows
06:50 cotto (callgrind)
06:51 chromatic Tene, I believe so.
06:52 chromatic cotto, my profile agrees with you.  The expensive one is Parrot_Context_get_info.
06:53 cotto yeah.  I'm looking into how to cheaply get the info I need without it.
06:53 chromatic Exactly.
06:54 chromatic Looks like we only need line and file information.
06:54 cotto I'm also tempted to use more concatenation to avoid fprintf.
06:54 chromatic First things first... half of our runtime goes to Parrot_Context_get_info.
06:56 cotto Half?  running what?
06:57 chromatic More than half... 3/4, running examples/benchmarks/oofib.pir
07:00 iblechbot joined #parrot
07:01 chromatic It looks like we could extract src/sub.c lines 239 to 263.
07:07 mikehh joined #parrot
07:20 dalek TT #998 created by moritz++: Recent parrot changes cause lots of Rakudo spectests to abort with status ...
07:21 moritz chromatic: that one might be for you ;-) (tt #998)
07:21 chromatic I looked at it a bit yesterday, but didn't have a good range to bisect.
07:21 chromatic How confident are you about that range?
07:22 moritz very
07:22 chromatic That helps a lot.
07:22 moritz the good revision (r41083) is directly after the the pluggable_runcores merge, everything was fine there
07:23 moritz oh, forgot to mention on the ticket that I configured with --optimize
07:23 chromatic Good, then it's *probably* not pmc_attrs or context_pmc3.
07:39 cotto chromatic, why do you use oofib as a test of the profiler?
07:39 cotto is it likely to be representative?
07:39 cotto and of what?
07:40 chromatic It has loops and function calls and method dispatch.
07:40 moritz chromatic: actually I suspect the default runcore switch
07:40 chromatic It doesn't have complex control flow or exceptions, but it's substantive.
07:40 moritz but it's just a guess
07:40 chromatic moritz, I hope it's not that.
07:44 cotto g'night
07:46 moritz chromatic: now running spectest with latest parrot but slow core - we'll know in about an hour :/
07:47 chromatic Thanks!
07:48 HG` joined #parrot
07:56 muixirt joined #parrot
07:57 muixirt good morning
07:57 purl And good moroning to you, muixirt.
07:58 muixirt are there any plans for some bindings for gui toolkits?
07:59 chromatic Yes... but they seem to be early plans.
07:59 payload joined #parrot
08:00 muixirt hopefully not this xlib library in examples
08:00 muixirt or what does it holding back?
08:00 chromatic Time and volunteers, more than anything.
08:01 moritz muixirt: Tene++ write some bindings for one of the enlightenment libraries
08:01 muixirt was progress made?
08:01 moritz s/write/wrote/
08:01 moritz it was kinda usable from rakudo
08:03 muixirt and mainstream toolkits like gtk or qt?
08:03 moritz chromatic: switching to slow core didn't make the rakudo failures go away
08:03 Tene muixirt: They will be fairly straightforward to write wrapper libraries for.
08:03 Tene Nobody has done it yet, but I'd be glad to help you with it if you'd like to try.
08:03 chromatic moritz, hooray... I think.
08:04 chromatic moritz, I've had a lot of trouble reproducing it.
08:05 moritz chromatic: I see the same on two independent amd64 boxes - I can give you a temporary account on one of them if you promise not to break anything :-)
08:06 chromatic If we had one test file that demonstrated it, I could have an easier time bisecting.
08:07 chromatic I turned your list of files into a shell script that continues only until something exits with non-zero, but they all pass through a bisect of your range.
08:07 chromatic Those are the kinds of sentences that make the non-geeks in the Big Blue Room look at me as if I've sprouted wings.
08:09 moritz :-)
08:09 muixirt Tene, what would you prefer gtk, qt or wx?
08:10 moritz chromatic: but do you also see those failures when you run a full spectest?
08:10 Tene muixirt: I don't know enough about using any of them to have an informed opinion. :)
08:10 Tene I have vague memories of disliking wx and qt, and not minding gtk...
08:10 chromatic I did last time I ran a full spectest, moritz... but I didn't run one during the bisect.  It's 1 am and I'm lazy.
08:10 Tene but that was years ago
08:10 moritz chromatic: maybe I can come up with a way to bisect - will comment on the ticket if I do
08:12 chromatic Maybe if there's a way to modify the harness to stop on a non-zero exit, that'd make it easier.
08:12 moritz I put a selection of those files in t/localtest.data, and with that I can reproduce the non-zero wait status in a sensible time
08:12 chromatic It sounds like the list of affected files moves around.
08:19 allison joined #parrot
08:23 moritz yes; but if my selection is large enough, chances are that at least one of them is always affected
08:23 chromatic True.
08:58 mikehh dukeleto: I just updated Math::BigRat yesterday and you got a new version today
09:04 allison joined #parrot
09:35 muixirt ping Tene
09:35 purl I can't find Tene in the DNS.
10:04 Whiteknight joined #parrot
10:05 * Whiteknight pops in for about 5 minutes
10:13 Whiteknight ...and away!
10:20 MoC joined #parrot
10:31 HG` joined #parrot
10:40 muixirt moritz, ping
10:40 moritz muixirt: pong
10:41 muixirt moritz, on the topic of bindings ...
10:41 muixirt those nci bindings have to be made manually?
10:41 moritz muixirt: no, there's a NCI generator
10:42 moritz don't know how well it works, though
10:42 moritz or how much it bitrotted
10:42 muixirt that doesn't work
10:42 moritz then please open a ticket
10:42 muixirt even in the simple case of gtk/gtkenums.h
10:43 muixirt this nci interface is subject to change or is that stable?
10:44 moritz no idea; I fear I'm the wrong person to ask
10:47 mokurai left #parrot
10:47 muixirt I wonder if a 1 to 1 approach for gui bindings are the right thing to do
10:51 moritz it's probably not "right" in the sense that it's best API you can offer for the HLL
10:52 moritz but it's little work, and it means that you can refer to the original toolkit documentation instead of writing your won
10:52 moritz s/won/own/
11:03 kjeldahl joined #parrot
11:06 payload joined #parrot
11:10 quek joined #parrot
11:32 quek left #parrot
11:50 bacek joined #parrot
11:51 MoC` joined #parrot
12:00 whiteknight joined #parrot
12:06 masak joined #parrot
12:15 JimmyZ joined #parrot
12:17 moritz debian only wants to ship "stable" parrot releases
12:18 moritz and rakudo can't be installed with the last stable parrot release
12:18 moritz so rakudo distribution on debian waits for parrot-2.0. Sigh.
12:21 muixirt only a matter of time
12:28 muixirt anyone who knows nci well?
12:29 bacek o hai
12:31 muixirt how is something like "void gtk_init (int *argc,char ***argv);" translated w.r.t. nci?
12:32 dalek TT #139 closed by bacek++: Move executable code out of jit_emit.h for IA64
12:32 dalek TT #140 closed by bacek++: Move executable code out of jit_emit.h for ALPHA
12:36 bacek muixirt: you probably have to edit src/call_list.txt and add signature for such functions
12:37 muixirt hmm
12:39 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41180 - Ubuntu 9.04 amd64 (g++)
12:39 muixirt ManagedStruct?
12:42 bacek muixirt: I'm not sure about ManagedStruct.
12:43 mikehh moritz: hey how about reporting the parrot revision in the rakudo Configure.pl like partcl does
12:43 moritz mikehh: sure, patches welcome
12:44 mikehh I just built and tested rakudo without running make install-dev and only noticed when I tried with partcl
12:45 mikehh moritz: i'll have a look :-}
12:45 moritz well, we already have a warning for that one
12:46 nopaste "moritz" at 132.187.31.74 pasted "Configure.pl warning for mikehh++" (16 lines) at http://nopaste.snit.ch/17905
12:46 moritz note that it might not work if you have an older version of parrot install-dev'ed
12:53 mikehh moritz: I installed and tested on r41173 then built and tested parrot 41180 (but forgot to install) so I tested again on r41173
12:53 Coke anyone looking for JIT tickets to close, check  out RT.
12:54 Coke (->_
12:54 Coke er, afk.
12:55 dalek TT #145 closed by bacek++: Move executable code out of jit_emit.h for SUN4
12:56 dalek TT #144 closed by bacek++: Move executable code out of jit_emit.h for PPC
12:56 dalek TT #143 closed by bacek++: Move executable code out of jit_emit.h for MIPS
12:56 dalek TT #142 closed by bacek++: Move executable code out of jit_emit.h for HPPA
12:56 dalek TT #141 closed by bacek++: Move executable code out of jit_emit.h for ARM
12:56 bacek cheap karma :)
12:56 HG` joined #parrot
12:57 ruoso joined #parrot
12:59 mikehh rakudo (5960161) builds on parrot r411780 - make test / make spectest (up to r28216) PASS - Ubuntu 9.04 amd64 (g++)
12:59 mikehh rakudo - t/spec/S03-operators/arith.rakudo - TODO passed:   120, 131-132
12:59 dalek TT #189 closed by bacek++: deprecated: random PMC
13:01 * whiteknight hasn't even thought about RT in a while
13:01 whiteknight I guess I should go back there eventually and see about closing some low-hanging fruit
13:03 dalek TT #375 closed by bacek++: FREEZE_ASCII doesn't work
13:03 bacek This was very-low-hanging fruit :)
13:06 whiteknight still exciting! We're moving forward on JIT finally!!
13:06 dalek TT #353 closed by bacek++: fix jit 386 set_i_n
13:06 dalek TT #352 closed by bacek++: fix jit i386 with long double
13:07 moritz whiteknight: after some discussion in #llvm I think that llvm-gcc or clang could initially replace our lorito prototype
13:07 moritz because it can compile C code to LLVM code
13:07 whiteknight I think we could write a pure-ASM NCI function dispatcher and not need JIT for that
13:07 whiteknight moritz: yes, that's an idea we've kicked together too. The problem is that we don't require LLVM and we allow people to build with other compilers
13:07 moritz so all the PMCs could be JITted without need for lorito
13:08 moritz whiteknight: that's why I said "initially"
13:08 whiteknight so we would have a C version, and check the LLVM ops versions into the repository like we do with our flex/bison files
13:08 whiteknight yes
13:08 moritz for a prototype it's OK to require llvm-gcc or so
13:08 moritz and once we are convinced that llvm really works for us, we can look into replacing it
13:10 dalek TT #356 closed by bacek++: better detect jit cpuarch with possible cmdline overrides
13:13 dalek TT #530 closed by bacek++: Failure of atan2 in jit core - ref TT #38
13:13 dalek TT #501 closed by bacek++: t/op/trans.t failures with jit on *BSD
13:15 whiteknight irclogs?
13:15 purl it has been said that irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
13:15 whiteknight moritz: what network is #llvm on?
13:15 moritz whiteknight: irc.oftc.net
13:16 whiteknight awesome
13:17 whiteknight is that chatroom logged?
13:17 moritz if so it's not listed in the topic
13:18 whiteknight of course, the logs aren't listed in our topic either
13:19 moritz in #perl6 they are
13:20 dalek TT #672 closed by bacek++: PASM1 compiler needs tests.
13:23 dalek TT #795 closed by bacek++: Kill Parrot_sub structure
13:24 tokuhirom___ joined #parrot
13:33 payload joined #parrot
13:40 dalek TT #983 closed by bacek++: JIT code incorrectly access registers
13:41 bacek ok. Enough cheap karma for today.
13:41 * moritz changes bacek's day to tomorrow
13:41 moritz see, now you can continue :-)
13:42 bacek moritz: it's still 20 minutes till tomorrow!
13:42 bacek clock?
13:42 purl bacek: LAX: Thu 6:42am PDT / CHI: Thu 8:42am CDT / NYC: Thu 9:42am EDT / LON: Thu 2:42pm BST / BER: Thu 3:42pm CEST / IND: Thu 7:12pm IST / TOK: Thu 10:42pm JST / SYD: Thu 11:42pm EST /
13:42 bacek moritz: see? :)
13:57 whiteknight joined #parrot
13:59 whiteknight go bacek go bacek go!
14:00 bacek whiteknight: no way. I'm going to bed. It's tomorrow already :)
14:03 whiteknight whatever, you've done enough going for one day
14:03 whiteknight bacek++
14:05 bacek I did almost nothing. Just skimmed over TT and closed few tickets.
14:10 whiteknight but that's very valuable
14:10 whiteknight closing old tickets is something that we have never done well
14:11 dalek TT #356 reopened by doughera++: better detect jit cpuarch with possible cmdline overrides
14:19 theory joined #parrot
14:39 kjeldahl joined #parrot
14:45 Tene joined #parrot
14:46 Tene muixirt: ping
14:50 Psyche^ joined #parrot
15:03 Andy joined #parrot
15:11 payload joined #parrot
15:33 hercynium joined #parrot
15:42 dukeleto mikehh: i put out another version of Math::BigRat because I forgot to update the SIGNATURES files with md5sums, so people that used Module::Signature complained
16:07 Coke whiteknight: all the low hanging fruit on RT has already fallen and rotted.
16:07 whiteknight awesome
16:08 whiteknight or maybe not awesome,I don't really understand the metaphore
16:09 Tene whiteknight: There was discussion abot Parrot's JIT plan on #llvm last night.
16:09 * whiteknight is very sorry he missed that
16:10 whiteknight I looked around and coulnd't find any logs for that chatroom
16:10 Tene whiteknight: They were *shocked* that we even had libjit on the wiki list of options... very against libjit.
16:10 Tene There aren't any.
16:10 Tene Except personal logs, like mine. :D
16:10 whiteknight oooohhh! I CAN HAZ?
16:10 Tene They also said that the "libjit is easy / llvm is hard" stuff was very out-of-date.
16:10 Tene Sure.  'sec
16:12 Tene sent.
16:12 whiteknight Tene++
16:14 dukeleto Tene: mind sending me a copy of that as well ?
16:16 Tene whiteknight: Um, did i send the right log?  I'm no longer sure that I did.
16:16 whiteknight looks like it
16:17 whiteknight it's a log of you talking to xxxprincess1234xxx about sex?
16:17 whiteknight still reading, but I'm wondering when you're going to mention LLVM or Parrot :(
16:17 whiteknight :)
16:18 Tene :)
16:22 whiteknight I chatted with the libJIT people, and they said the same stuff about LLVM!
16:22 * whiteknight detects a feud
16:22 Tene orly?
16:22 purl YA RLY.
16:22 Tene I'm very curious to see that discussion.
16:22 whiteknight I don't think that got logged either
16:23 Tene HAY LETS TRADE LOGS.  I'LL SHOW ME MINE IF U SHOW ME YOURS.
16:23 whiteknight and I definitely don't think we need to trigger some kind of war between them
16:23 Tene what were there specific complaints/objections about llvm?
16:23 whiteknight just that it was hard to use mostly
16:24 darbelo joined #parrot
16:25 Coke I think it is not surprising that two "competing" project don't think highly of the other's work.
16:25 whiteknight luckily parrot doesn't yet have a lot of competition in the "dynamic language virtual machine" landscape
16:26 Tene whiteknight: that's a different objection... at leat they're complimentary, not symmetric. :)
16:26 Coke whiteknight: (no competition). sure, depending on how you define competition or dynamic. =-)
16:27 japhb muixirt, NCI/Utils.pbc exists for handling toolkit init functions .... :-)
16:27 whiteknight right, for a very narrow defnition of those things
16:30 cotto joined #parrot
16:30 ilia joined #parrot
16:31 ilia joined #parrot
16:47 mikehh dukeleto: I wasn't complainin' or anything like that :-}, just comentatin'
16:52 KatrinaTheLamia joined #parrot
16:57 KatrinaTheLamia I am going to assume this server has custom services?--the user nickserv does not appear to exist.
16:58 jan joined #parrot
17:00 Coke no nickserv here, sfaik.
17:00 PerlJam KatrinaTheLamia: this network is a tad wilder than freenode :)
17:00 muixirt japhb, thanks, I must have overlooked it in the docs :-)
17:01 muixirt Tene, pong
17:01 KatrinaTheLamia PerlJam, hmmm... I may have to step up on working on luv-utils then--just so I don't return to find stuff hijacked on me ^.^
17:02 KatrinaTheLamia or... I could just splurge and grab a dedicated hosting account, and simply run irssi/screen off of that, instead of xchat on my lappy ^.^
17:04 MoC joined #parrot
17:05 PerlJam KatrinaTheLamia: you could ask Juerd for an account on feather.perl6.nl
17:05 KatrinaTheLamia PerlJam, could work? What all would I get with that?
17:06 PerlJam KatrinaTheLamia: feather is for people doing parrot/perl6 dev.  you'll get an account.  The ability to login and do stuff.  :)
17:07 KatrinaTheLamia PerlJam, so it is a shell account then. Yay!
17:07 KatrinaTheLamia PerlJam, there will be no issues with IRC traffic on it then?
17:08 PerlJam no
17:08 KatrinaTheLamia ah, okay ^.^
17:08 KatrinaTheLamia I'll work into figuring something out then ^.^
17:08 PerlJam But if you start doing Bad Things, there will be bunches of people upset at you though.
17:09 KatrinaTheLamia Okay, so far in projects I've racked up with Perl6/Parrot: Kind::Threads, Jerl 6, SSBZ and now likely Luv IRC stuffs ^.^
17:10 KatrinaTheLamia PerlJam, yeah, I don't crap where I sleep--or some such saying to that effect.
17:10 KatrinaTheLamia PerlJam, I recognise that it is not my server, and .'. not my place to go crazy with things.
17:11 muixirt japhb, well at least the list of features is easy to remember
17:14 KatrinaTheLamia heh, I still want to make the joke, once I get around to nicing in Kind::Threads that with a default nice value of 1, Kind::Threads is inherently nice to your code--you may all lynch me now, for what will only be an onslaught of bad jokes btw ~.^
17:15 duk3leto PerlJam: what is Juerd's email ?
17:15 pmichaud purl:  juerd?
17:15 purl juerd is root or at http://juerd.nl/ or mailto:juerd@juerd.nl
17:18 KatrinaTheLamia alright, will be looking into this... thankies ^.^
17:19 dalek partcl: r710 | coke++ | trunk/runtime/builtin/ (2 files):
17:19 dalek partcl: Add 'flush' to the list of things that socket's can't do. =-)
17:19 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=710
17:20 ilia joined #parrot
17:20 Coke hurm. ran a spectest that seems to show some speed improvement. have to rerun after partcl r710 to reclaim a failed test, but here's hoping someone fixed my speed problems. =-)
17:26 joeri joined #parrot
17:38 mokurai joined #parrot
17:45 Tene muixirt: You were pinging me last night, and then my shell server was rebooted.
17:49 MoC joined #parrot
17:49 Tene KatrinaTheLamia: I find access to feather rather slow.  I can offer you an account on one of my servers located in the US, if you're in NA and would prefer that.
17:50 Tene KatrinaTheLamia: Or I can create an account on feather for you right now.
17:51 muixirt Tene, never mind
17:51 Tene OK. :)
17:52 Tene muixirt: you've started on gtk bindings?
17:52 muixirt Tene, I'm still looking for clues how this nci stuff works
17:52 muixirt yes
17:52 Tene muixirt: you might want to look at my http://github.com/tene/parrot-elementary/
17:52 Tene e17 gui bindings
17:52 Tene That should be a very good example to start with.
17:54 muixirt looked into the Xlib example and sdl too
17:54 Tene I think that my example is a lot easier to follow and nicer to use than Xlib and SDL, personally.
17:55 muixirt I look into it, thanks
18:00 NotFound Xlib example is basic functionality, not very useful for a GUI.
18:00 chromatic joined #parrot
18:01 Tene Also, Xlib.pir is a lot longer than Elementary.pir
18:01 Tene Xlib is a lot more complicated to deal with than a high-level toolkit.
18:03 NotFound You just need to memoize all 3 books of Xlib Programming/Reference/Protocol and you'r fine ;)
18:04 Tene I'd object to that if I hadn't memorized at least an equal volume of other esoteric details. :)
18:06 muixirt I looked into Xlib.pir not because to use it for a gui but to find clues how to properly design the bindings and how to handle those obnoxious C-structs and pointers
18:07 Tene Right.  Where XLib.pir has a lot of other protocol stuff in it.
18:07 muixirt but it may be the case that Xlib.pir is the wrong thing to look at :-)
18:07 Tene Elementary.pir has two parts... the first just loads all of the right functions, the second makes some classes to deal with them.
18:08 NotFound muixirt: What lib are you planning to wrap?
18:08 muixirt gtk
18:10 NotFound muixirt: I don't think some basic gtk usage must be difficult
18:11 NotFound A full gtk wrapper will be a lot of job, though
18:11 Tene Elementary.pir is just about the simplest thing you can have if you want nice Parrot classes for toolkit widgets.
18:11 Tene Show show to hide the struct pointers in a private attribute of the class, etc.
18:14 muixirt ok, thanks, bbl
18:17 Tene KatrinaTheLamia: Sorry, looks like I lied.  I don't actually have sudo privs on feather, so you'd have to contact juerd.
18:22 pmichaud KatrinaTheLamia: several people on #perl6 might be able to help with a feather acct
18:31 mberends joined #parrot
18:38 japhb muixirt, Well, the idea is that over time as we discover new common tasks for NCI, they would get added to NCI::Utils.  Toolkit initialization was just the first and most common desire.
18:39 muixirt ok thanks
18:39 japhb muixirt, also, as an example of wrapping a LARGE API, there are the OpenGL bindings.  Note that due to current NCI limitations, there are things that don't work yet, or at least require more thought to get working cleanly.
18:40 japhb (and there are things the current NCI simply can't support at all, but we'll get there)
18:41 NotFound I don't hink OpenGL is a good example for more common usages, because of his dependance on specific callbacks.
18:41 japhb NotFound, um what?
18:42 japhb GTK+ may be a lucky case ... the callbacks may actually fit the "opaque data pointer callback argument" style that is the only one supported by core NCI.  I had to write the annoying glutcb library to work around the fact that GLUT callbacks don't work that way.  :-(
18:43 NotFound japhb: OpenGL uses callbacks without giving a way to pass arguments to them.
18:43 japhb NotFound, right, that's what I meant.
18:44 NotFound Well, lots of libraries doesn't have such specific problem, so OpenGL is a too complex example.
18:44 japhb NotFound, sure.
18:45 duk3leto NotFound: i would like to work on GSL bindings for parrot. most of GSL has simple function signatures, but some subsystems require callbacks.
18:51 NotFound duk3leto: as japhb said, it that callbacks fit the opaque pointer style you're lucky
18:53 duk3leto japhb: i am not sure, what is the exact definition of "opaque pointer" ?
18:53 * Coke ponders again switching to PCT.
18:53 Coke (instead of TGE)
18:53 PerlJam Coke: do it!  :)
18:53 NotFound duk3leto: you pass a pointer to the function that set the callback, and the callback is called with that argument
18:54 Coke PerlJam: if it were easy, it'd be done already. :|
18:54 japhb duk3leto, when you register a callback, you also register a pointer that the API will hand back to you verbatim on every callback.
18:54 japhb The API must not treat the pointer as anything other than a void *.
18:54 NotFound "opaque" as long as the library does nothing more than passing it
18:55 japhb I keep thinking NotFound and I need to sing a chorus now or something.  :-)
18:55 Tene Once we have a nicer JIT, I want to investigate better ways of generating more diverse callback functions.
18:56 jrtayloriv joined #parrot
18:56 japhb Tene, I'm all for it.
18:56 Coke are there better pct docs than http://docs.parrot.org/parrot/latest/html/​docs/book/pct/ch03_compiler_tools.pod.html ?
18:56 Tene but, that's wild speculation at this point. :)
18:57 japhb Actually, we had a few ideas for doing better callbacks, but all of them required JIT or non-portable C hacks
18:57 Coke (it's recommending what I think is a dead 'create a language script' and assumes you'll be using the script instead of rolling your own.)
18:57 Tene Coke: dunno... I've never used that.  I've read the pdd and perldoc of the PCT .pir
18:57 Coke ok. if that's helpful, it should end up in the bundled html docs. =-)
18:58 Coke compilers/pct/README.pod thinks rakudo still lives in parrot repo
18:58 japhb Coke, pmichaud is doing PGE/NQP/PCT work this month, so add that to his stack.  Or don't, maybe, I think we need him to be elbow deep in code for a while.  ;-)
18:59 Coke Tene: which file, exactly?
18:59 Coke (top level, second level are just placeholders)
18:59 Coke (under compilers/pct)
18:59 Tene Coke: PCT/Node.pir
19:00 Tene Coke: I *really* don't know wtf is going on with html generated docs...
19:00 Tene I've never used them or looked at them.
19:00 Tene I know that treed has run into trouble several times by trying to use docs on the website.
19:00 Coke Tene: Node.pir seems to assume I already have things already setup.
19:00 pmichaud Coke: how much does tcl currently rely on TGE?
19:01 Tene Coke: treed is probably the most-significant most-recent person to learn PCT, so you might ask him about his learning experience.
19:01 Coke pmichaud: ... I don't know how to answer that question other than "some"
19:01 pmichaud okay.  let me browse partcl a bit
19:01 Tene Coke: Sure, it's documentation for the PCT Nodes...
19:01 Coke the .tg files are in src/grammar/expr
19:01 Coke Tene: I don't need docs for the nodes.
19:01 * treed still doesn't really know PCT.
19:01 Coke I need docs for "using pct"
19:01 treed I know a great deal about using PIR.
19:01 Tene Coke: you weren't very specific in asking for "PCT docs"
19:02 treed But PCT is mostly still magic for me.
19:02 Coke Tene: Assume I know nothing about PCT and wish to use it. =-)
19:02 duk3leto NotFound,japhb: that sounds like that would work. Can additional params be passed to callbacks? some GSL functions require callbacks to take a variable number of args
19:02 Tene Coke: then I'd recommend that you look at existing uses of PCT, as that's where I'd go to learn about how to use it.
19:02 Tene :)
19:03 Tene AFK teaching
19:03 treed Learning by example is only good to a certain extent.
19:03 Coke looking at rakudo to figure out how use PCT strikes me as... crazy.
19:03 Coke there's a LOT in rakudo. how do I know what is PCT and what isn't?
19:03 treed My favored learning technique is: Learn some of the theory, see examples, try it out. Maybe ask some questions.
19:03 treed Rinse. Repeat.
19:04 treed If you learn only from examples, you might interpret things incorrectly.
19:04 treed So, here's this code that looks like it does this thing, but does it really? And why was it done this way?
19:05 NotFound duk3leto: some example code?
19:05 treed What are the other options for getting this job done, and why choose this one?
19:05 treed etc
19:07 japhb duk3leto, IIRC core NCI callback functionality is really limited.  Only callback registration functions that take a function pointer and an opaque data pointer work.  You may have to look at the glutcb stuff to see what to do otherwise -- but note that glutcb is a hack that does *not* allow multiple functions (or multiple threads) to be registered for the same function.
19:07 japhb OK, AFK for a while
19:08 Coke pmichaud: thanks for looking; One of the things I want to do is, whenever a certain rule completes, immediately execute the code for that rule. That seems like it should be doable for actions. no?
19:08 Coke s/for ac/with ac/
19:08 MoC` joined #parrot
19:13 duk3leto NotFound: here is an example: http://www.gnu.org/software/gsl/manual/htm​l_node/Numerical-integration-examples.html
19:13 pmichaud yes, it's very doable.
19:13 pmichaud (rakudo does it for BEGIN blocks and the like)
19:14 Coke k. that would help me solve one big partcl ticket (and several dozen spec tests.)
19:18 pmichaud what's an incredibly simple tcl program I can use to start with?
19:18 pmichaud something as simple as  [puts 'ok']   (given that I don't know tcl syntax)
19:18 Coke puts ok
19:18 pmichaud no brackets?
19:18 Coke right.
19:19 Coke brackets are subcommands. (run that command and return the result)
19:19 Coke so "set a 2; puts [set a]" would print out 2, e.g.
19:19 KatrinaTheLamia thanks ^.^
19:19 NotFound duk3leto: ¿Cuáles son esos múltiples argumentos?
19:19 NotFound Uh, sorry
19:20 pmichaud with "puts ok", the bare 'ok' is a string?
19:20 NotFound duk3leto: What are the multiple arguments for the callback?
19:20 Coke yes. You could do
19:21 Coke puts "ok"
19:21 duk3leto NotFound: that is one of the simple examples that doesn't need that. I can find one of the more complicated ones
19:21 Coke which does the same thing if the quotes make you feel better, but they are redundant in this case.
19:21 pmichaud well, it's a matter of being able to trace it easily through the parse tree
19:21 pmichaud I'm thinking "ok" might be easier to follow to begin with than the bare ok
19:22 Coke it should add another parse step, converting the "ok" to just ok.
19:22 Coke but both are valid, ja.
19:22 duk3leto NotFound: it might not actually need varargs for callbacks, but it does have many different flavors of callbacks. Here is a more complicated example: http://www.gnu.org/software/gsl/manu​al/html_node/Multimin-Examples.html
19:24 duk3leto NotFound: IIRC, the more complicated GSL callbacks require 2 gsl_vector's, one for the current state and one for params. these can be of any size, but fixed for a fixed problem, so not quite the same as varargs
19:26 Coke pmichaud: ooc, are you just following through in the current TGE based version?
19:26 pmichaud I'm looking at the current set of transformations and seeing how difficult it would be to migrate to pct
19:26 pmichaud first glance, it looks very doable
19:27 pmichaud we'd end up replacing the current *.tg files with nqp equivalents
19:27 NotFound duk3leto: that may be complicated, but looks like a good familiarity with the library will be needed to evaluate the difficult.
19:27 pmichaud caveat:  this might make things even slower.  then again, it might make them faster.  :-)
19:28 pdcawley_ joined #parrot
19:28 pmichaud iiuc, most of what partcl does is convert things into function calls anyway, yes?
19:28 Coke pmichaud: at the moment, yes.
19:28 pmichaud seems like it ought to be workable then
19:28 Coke we have to have SOME way to avoid that for the builtin commands at some point.
19:28 pmichaud last question for the moment -- can I haz commit bit?
19:29 Coke absolutely. same rules as parrot.
19:29 pmichaud I'll just work in a branch
19:29 Coke +1.
19:29 purl 1
19:29 Coke purl, you idiot, I knew that.
19:29 purl Coke: excuse me?
19:29 Coke pmichaud: need a google account id.
19:29 pmichaud pmichaud@pobox.com should work
19:29 duk3leto NotFound: the good thing about GSL is that it is broken up into about 45 subsystems, some have very simple function signatures and require no callbacks, so the low-hanging fruit can be picked first. This is what I did with Math::GSL
19:30 KatrinaTheLamia purl, he refered to you as an idiot... take it how you will ^.^
19:30 purl KatrinaTheLamia: sorry...
19:30 Coke pmichaud: added.
19:30 pmichaud yay
19:30 Coke pmichaud: (there are mailing lists if you care to get commit emails, that sort of thing. linked to off the front page.)
19:30 Coke no, yay me!
19:30 pmichaud if I can get the basic puts to work, I think that may be enough of an illustration to start moving the rest over
19:31 pmichaud but my initial inclination is that the nqp version of the transformations are likely to be much more straightforward than the tge implementation
19:31 Coke pmichaud: there's a lot of boilerplate in tge code.
19:31 chromatic That was my impression as well.
19:31 pmichaud right
19:31 Coke so, easier to maintain is better than speed just now. And if PCT gets faster, then I win too.
19:31 pmichaud and besides, rakudo (and I) owe a lot to partcl, so I don't mind investing some energy back :)
19:32 pmichaud I probably won't get to do anything with it today, but tomorrow looks promising.
19:32 dalek partcl: r711 | coke++ | trunk/docs/spectest-progress.csv:
19:32 dalek partcl: update spec test numbers.
19:32 dalek partcl: Looks like a definite speed improvement, which is probably all due to parrot.
19:32 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=711
19:32 Coke pmichaud: um. you said pobox?
19:32 pmichaud yes
19:32 pmichaud google probably converted it to my gmail addr
19:32 Coke ... it seems to have changed it to your ... yah.
19:33 Coke making sure i'm not crazy. thank you. =-)
19:33 Coke 13433/7720
19:33 purl 1.74002590673575
19:33 Coke chromatic: that's the speedup between parrot 41154 and 41180
19:33 Coke (running 'make spectest')
19:34 pmichaud does tcl use pct::hllcompiler at all?
19:34 pmichaud I suspect no, based on previous comments.
19:34 chromatic Coke, how do I interpret those numbers?
19:35 chromatic Oh, a 42.5% speedup.  That's nice.
19:36 Coke pmichaud: nope.
19:36 Coke chromatic: yup.
19:37 chromatic Coke, random guess: r41164.
19:37 * pmichaud runs a spectest to see if we can bump rakudo to r41180
19:38 pmichaud afk, errands
19:38 chromatic r41159 won't hurt much either.
19:38 dalek parrot: r41181 | chromatic++ | trunk/src/sub.c:
19:38 dalek parrot: [sub] Coalesced repeated calls to Parrot_pcc_get_pc() in
19:38 dalek parrot: Parrot_Context_get_info(); it's a minor optimization.
19:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41181/
19:45 Coke chromatic: another data point:
19:45 Coke r41161 took 9855s
19:46 chromatic Likely both of them then.  Good to know.
19:47 Coke I live to serve.
19:50 Tene pmichaud: think of tcl as kinda like bash... text is a literal quote, require special syntax to make text special.
19:53 dalek partcl: r712 | coke++ | trunk/config/PARROT_VERSION:
19:53 dalek partcl: this version somewhat speedier.
19:53 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=712
19:56 chromatic Grr, Debian bought into the magical flying rainbow-flavored ponies hoo-hah "stable" moniker on the twice-a-year-releases and won't ship Rakudo.
19:57 chromatic Given that the intent of the candy-colored fairy dust sprinkled on our release process was to *encourage* distributions to ship our software, perhaps... ah, forget it.
19:57 Tene chromatic: what's this?
19:57 purl this is probably different
19:58 Tene purl: shut up
19:58 purl make me
19:58 Tene purl: make: *** No rule to make target `me'.  Stop.
19:58 purl You forgot to ./configure PREFIX=/usr/local/Tene/ass
19:58 Tene Ah, OK
20:00 chromatic moritz said earlier that Debian won't include Rakudo until after Parrot 2.0 because Rakudo depends on monthly (thus "OOH SCARY WILL EAT YOUR BRANE!! DO NOT USE!!") releases.
20:01 Tene ;,;
20:02 chromatic Dear Debian, have you see the Ruby core test suite?  I reproduce it here in its entirety:  #!/bin/bash make ruby echo "It probably compiled" exit 0
20:03 Tene srsly?  I thought I remembered seeing at least some "the program starts and shit" tests.
20:03 chromatic It's improved a lot, but Rakudo and Parrot are both much better tested.
20:03 pmichaud chromatic: (debian)  allison and I had a conversation about this off-list as well.  It's very unlikely that Debian will include Rakudo Star until 2.6.
20:04 chromatic That's unfortunate.
20:04 allison chromatic: it makes sense from a packaging perspective
20:05 allison rakudo will go in their "experimental" package repository until then
20:05 chromatic Why?
20:05 allison because it makes it really easy for people to test it
20:05 allison (better than asking them to manually download the packages)
20:05 chromatic No, why wait for 2.6?
20:06 allison oh, because that's 3 months after the "stable" release
20:06 pmichaud because Rakudo Star is unlikely to build on Parrot 2.0
20:06 chromatic Debian "stable" or Parrot "supported"?
20:06 allison Rakudo Star
20:06 allison (whatever adjective we use for it)
20:07 chromatic I thought the point of the name "Rakudo Star" was to avoid all of the magical thinking around the term "stable".
20:07 allison I did put it in quotes :)
20:07 allison I can call it the chocolate sauce release if that helps
20:08 chromatic I prefer that, in all seriousness.
20:08 pmichaud why not the "*" release?  ;-)
20:08 chromatic That's fine, too.
20:08 allison okay, well the very first chocolate sauce release is likely to have a few bugs to shake loose
20:08 chromatic So?
20:08 allison (much like Parrot 1.0)
20:08 chromatic Much like every other package in Debian stable.
20:09 allison so, we package it, get loads of testing
20:09 pmichaud actually, I'm guessing that the April 2010 release won't be the "first release"
20:09 pmichaud we'll probably have a couple of testing releases before it
20:09 allison good idea
20:09 purl allison: Good Idea: Playing the piccolo in a marching band. Bad Idea: Playing the piano in a marching band.
20:10 allison so, once we have a pretty solid package going, we submit it to debian 'unstable' (the next step up from experimental)
20:10 chromatic What makes a package "solid"?
20:10 pmichaud and while it's likely there will be another Rakudo Star release in July (corresponding with Parrot 2.6), that's by no means definite at this point.
20:10 allison then, they test it on all their platforms, and if it gets green flags on all of them, it moves to Debian 'testing'
20:11 allison then, fingers crossed, it makes it into the next Debian 'stable' release
20:11 allison which takes time
20:11 allison (Parrot 1.4 just moved into 'testing', and we've been in the pipeline since a few days after 1.0)
20:13 chromatic Are you suggesting that Debian not distributing Rakudo until next year is more a function of Debian's fetish for abandonware than their misreading of the word "supported" on our twice-a-year releases?
20:13 HG` joined #parrot
20:13 allison yah
20:13 chromatic Okay.  I don't like that, but I'm not going up against all of Debian.
20:14 allison better men than you have tried and failed at that one ;)
20:14 chromatic Logical fallacy in the leading noun phrase, but I agree with the sentiment.
20:14 Coke are you saying it's a tautological misstep to refer to anyone as a better man than you?
20:14 Tene Of course.
20:14 purl Indubitably.
20:14 allison more chococolately goodnessy men than you...
20:15 pmichaud "less stable"
20:15 allison :)
20:15 chromatic More Finnish men than you...
20:15 pmichaud r41180 seems to pass rakudo spectests.... but let's try r41181 for its minor optimization as well :-)
20:16 * Tene officially gives up on tt757 work again
20:16 Coke pmichaud: how long does your spec test run take atm?
20:16 chromatic http://bugs.debian.org/cgi-b​in/bugreport.cgi?bug=413685
20:16 Coke (are you tracking that in your cvs?)
20:16 chromatic http://modeemi.fi/~tuomov/b/a​rchives/2007/03/03/T19_15_26/
20:16 Coke (csv)
20:17 pmichaud last run took 42min user time, 22min wall-clock time
20:17 pmichaud (because I can test in parallel)
20:17 pmichaud I don't track the times in my csv because I don't have a dedicated platform to give apples-to-apples numbers
20:17 Coke 7720/60
20:17 purl 128.666666666667
20:17 Coke 7720/60/60
20:17 purl 2.14444444444444
20:18 chromatic pmichaud, r41181 probably won't get you any speed benefit.  It helps the profiling runcore and anything that does a lot of Context introspection, but that's very minor.
20:18 Coke yah, I just picked feather for that because it was there.
20:18 NotFound allison: So maybe a woman must try ;)
20:18 pmichaud Coke: yes, but even feather can be affected by load at times :)
20:19 Coke yah. just a placeholder until something better comes along.
20:19 pmichaud http://pmichaud.com/sandbox/speed-1.png   # spectest timings for rakudo, 05-27 to present
20:19 Coke anyone know if youc an create a new Interpreter from PIR and actually run things on it?
20:20 allison NotFound: :)
20:21 pmichaud usefully, the large increase in the number of spectests this past week didn't result in an equivalent increase to the time to run them
20:21 chromatic I'm working hard to keep you running in place.  Soon I can move you backwards.
20:21 pmichaud http://pmichaud.com/sandbox/speed-2.png   # average tests per second, 05-27 to present
20:23 chromatic I did notice that the use of PMCs for local_branch in PGE looked expensive.  If we had a cheap way to recycle those, I bet we could reduce GC pressure dramatically.
20:23 pmichaud is it the creation of the PMCs or the use of them that is expensive?
20:24 chromatic Neither one.  Most precisely: it's burning through the free pool of PMCs and having to mark and sweep everything that's expensive.
20:24 pmichaud okay, it's the cost of mark+sweep the huge number of them that are created
20:24 Coke so, it's just general PMC pressure?
20:24 chromatic Yes.
20:25 pmichaud I could set PGE to recycle them
20:25 chromatic If we had escape analysis and could identify immediate, transient collectable garbage, we wouldn't have this problem.
20:25 Coke is it me or did profiling get MUCH faster since it was merged back.
20:25 Coke ?
20:26 pmichaud actually, now that I think about it, recycling them is hard
20:26 chromatic How so, pmichaud?
20:26 pmichaud I don't know when they're no longer use(ful)
20:26 pmichaud I guess I would know it upon completely failing a match
20:27 chromatic That's one case.
20:27 pmichaud and that's the more common case, so that'd be helpful
20:27 chromatic Especially in the Perl 6 grammar's ws rule.
20:27 chromatic That was the expensive one, in my profiles.
20:27 chromatic Even a simple hand-edit to that rule's generated PIR could be a useful as a proof of concept.
20:28 Coke chromatic: docs on working with .pprof ? (wasn't there a tool for that?)
20:28 pmichaud I think it'd be easier to do the PGE modification than hand-edit :)
20:28 chromatic dev/tools/pprof2cg.pl I think.
20:28 pmichaud I can totally see how it would result in a performance improvement
20:28 chromatic Whatever's easiest for you, pmichaud.  It seemed worth a small test to me.
20:28 pmichaud if mark+sweep is the costly part, we can definitely do something about it
20:29 chromatic It looked like every rule call created three or four transient PMCs.  If you call a lot of rules....
20:29 Coke chromatic: AH. it's not marked executable, so bash completion was ignoring it.
20:29 pmichaud backtracking rules and rules with captures definitely create them
20:29 pmichaud because we need a place to store the backtrack information
20:30 pmichaud anyway, I will give it a try tonight.  I suspect it will only take an hour or so to implement and test
20:30 pmichaud how can I find out if things are improved (short of rakudo spectest showing a dramatic speed improvement)?
20:31 pmichaud afk for 15 mins (errand)
20:32 chromatic Anything that uses PGE should show a measurable improvement, if it works.
20:33 kjeldahl joined #parrot
20:44 dalek partcl: r713 | coke++ | trunk/runtime/builtin/flush.pir:
20:44 dalek partcl: cleanup PIR
20:44 pmichaud r41181 saved about 30 seconds from the previous run.
20:44 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=713
20:44 dalek partcl: r714 | coke++ | trunk/tools/profiler.pl:
20:44 dalek partcl: profiling parrot code in their trunk, can now get cg-compatable output from it.
20:44 dalek partcl: ditch our cheapo version.
20:44 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=714
20:47 chromatic Wow.  pmichaud, what do you use Parrot_Context_get_info() for?  Do you know offhand?
20:47 dalek rakudo: 8ea834f | pmichaud++ | build/PARROT_REVISION:
20:47 dalek rakudo: Bump to 41181, to (hopefully) get some speed improvements.
20:47 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​ea834f7b900bebca048191ae67a98b762d06fb6
20:50 chromatic I can get you another 4.8%, if my numbers are right.
20:50 payload joined #parrot
20:53 bacek joined #parrot
21:01 chromatic 4.55%.  That'll do.
21:02 dalek parrot: r41182 | chromatic++ | trunk/src/call/context.c:
21:02 dalek parrot: [pcc] Added static, inlineable get_context_struct_fast() for use only in this
21:02 dalek parrot: file to avoid the function call overhead of calling the exportable
21:02 dalek parrot: Parrot_pcc_get_context_struct().  Billions of calls to the latter (almost all
21:02 dalek parrot: from within this file itself) add up; one Rakudo spectest shows a 4.55%
21:02 dalek parrot: performance improvement.
21:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41182/
21:06 chromatic Hm, am I misunderstanding -DNDEBUG?
21:09 chromatic Apparently so.
21:11 chromatic http://www.ralfebert.de/blog/​tools/visual_git_tutorial_1/
21:11 darbelo bacek: ping
21:14 japhb joined #parrot
21:14 nopaste "darbelo" at 200.49.154.172 pasted "Leftover from r41178 for bacek++" (16 lines) at http://nopaste.snit.ch/17910
21:16 darbelo msg bacek Looks like I missed a FREEZE_ASCII removal in my last patch. see http://nopaste.snit.ch/17910
21:16 purl Message for bacek stored.
21:16 dalek parrot: r41183 | NotFound++ | trunk/src/pmc/fixedpmcarray.pmc:
21:16 dalek parrot: [pmc] Workaround for FixedPMCArray sort method, TT #218
21:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41183/
21:18 bacek Good morning
21:18 purl And good moroning to you, bacek.
21:18 bacek darbelo: You sent a CLA, didn't you?
21:19 darbelo Yup, but no response yet.
21:19 bacek chromatic: ping.
21:19 darbelo Looks like you're stuck with my patches :)
21:20 bacek darbelo: not only me :)
21:20 darbelo It was a plural "you" ;)
21:21 darbelo I guess it's y'all over there.
21:23 dalek parrot: r41184 | bacek++ | trunk/t/pmc/sub.t:
21:23 dalek parrot: [t] Add todoed ticket for TT#132
21:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41184/
21:23 dalek parrot: r41185 | bacek++ | trunk/src/pmc_freeze.c:
21:23 dalek parrot: Remove last reference to FREEZE_ASCII. Patch courtesy of darbelo++
21:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41185/
21:27 kid51 joined #parrot
21:28 muixirt chromatic, in order to understand nci bindings I looked into SDL.pir, the macro store_nci_func is only used once. Why?
21:28 joeri left #parrot
21:37 dalek rakudo: d0355a5 | pmichaud++ | src/classes/Num.pir:
21:37 dalek rakudo: Enable hll_map for Float->Num.  This enables us to pass some tests
21:37 dalek rakudo: and doesn't seem to kill performance too much.
21:37 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​0355a5dde0973e01834d58de099e53b97fe70a6
21:39 ruoso joined #parrot
21:47 chromatic muixirt, I have no good answer for that.  Maybe the code is out of date and needs updating.
21:51 bacek chromatic: can you check that CLA of bloody annoying darbelo arrived and give him commit bit? :)
21:53 chromatic Nothing where I can see it.  Did he mail, fax, or email it?
21:53 bacek darbelo: ping.
21:53 chromatic Did you like r41182, bacek?
21:53 darbelo chromatic: email
21:53 darbelo bacek: pong
21:53 chromatic Where did you mail it, darbelo?
21:54 darbelo legal@parrot.org, from arbelo@gmail.com
21:54 bacek chromatic: yeah. Can you try replace CURRENT_CONTEXT macro with direct poking to interp?
21:55 chromatic I'll take a look, bacek.  Where do you recommend?
21:55 darbelo I think I mailed it Sep 7
21:55 bacek chromatic: nm. It's already in this way
21:55 chromatic darbelo, I don't see anything.  You could mail me directly if you like; mynick @wgz.org
21:56 bacek chromatic: src/call/context.c:1316. We can avoid VTABLE call here. 0.001% win
21:57 chromatic 0.04% to be precise!
21:58 bacek Still win :)
21:58 fperrad left #parrot
21:59 bacek chromatic: line 1143 also.
22:00 chromatic 1143 won't work; see the comment.
22:00 bacek Just wrap it into if(!PMC_IS_NULL).
22:01 Coke bacek: I'm on legal, I got nothing.
22:01 Coke whoops
22:01 bacek It's usually not-null, so manual inlining will help.
22:01 Coke darbelo: I'm on legal, I got nothing.
22:02 dalek partcl: r715 | coke++ | trunk/ (2 files):
22:02 dalek partcl: fix [namespace tail]
22:02 dalek partcl: grab a few more passing spec tests, make sure we don't regress.
22:02 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=715
22:02 dalek partcl: r716 | coke++ | trunk/t/cmd_namespace.t:
22:02 dalek partcl: Add test to catch proper errors on NS deletion of invalid items.
22:02 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=716
22:03 chromatic Makes sense, bacek.
22:06 bacek chromatic: clear_regs can accept Parrot_Context* instead of PMC*.
22:06 chromatic 0.82% performance improvement with that PMC_IS_NULL trick.  That's worthwhile; pushes the fast context fetch results to over 5.3%.
22:06 darbelo chromatic: set a mail to you @wgz.org just now. Let me know if it reaches you.
22:06 chromatic I see it, darbelo.
22:07 dalek partcl: r717 | coke++ | trunk/runtime/builtin/namespace.pir:
22:07 dalek partcl: Move [namespace delete] inline.
22:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=717
22:07 dalek partcl: r718 | coke++ | trunk/runtime/builtin/namespace.pir:
22:07 dalek partcl: Modify PIR heavily to use hllmacros
22:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=718
22:07 dalek partcl: r719 | coke++ | trunk/runtime/builtin/namespace.pir:
22:07 dalek partcl: [namespace delete] should error when deleting a non-existant ns.
22:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=719
22:07 dalek partcl: r720 | coke++ | trunk/runtime/builtin/info.pir:
22:07 dalek partcl: add [info procs]
22:07 dalek partcl: (like info commands, but only reports items originally written in tcl)
22:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=720
22:09 bacek chromatic: manual inlining in Parrot_push_context should provide measurable speed-up
22:10 Coke hurm. kcachegrind is not in my immediate future. should I just be able to run cg_annotate on the resulting .out. file?
22:10 Coke (because that errors)
22:10 chromatic darbelo, you should have SVN commit access now.  Please feel free to add yourself to CREDITS to test.  Your trac credentials should work.
22:10 chromatic Coke, it should work.
22:11 Coke Line 1: missing command line
22:11 Coke (after: cg_annotate parrot.out.32261)
22:11 chromatic bacek, looks like a 0.12% improvement on this benchmark.
22:11 bacek chromatic: with push_context inlined?
22:12 chromatic Yes.
22:13 chromatic Coke, I don't understand that.  My parrot.out.PID files have a cmd: line in the header.
22:13 bacek chromatic: next idea: inline in pop_context
22:14 Coke chromatic: yes, so does mine. :|
22:14 chromatic bacek, they're just not that expensive in the profiles here.
22:14 chromatic Let me find a benchmark that uses a lot more subs.
22:15 Coke http://feather.perl6.nl/~coke/parrot.out.32261
22:15 bacek chromatic: oooo! Split Parrot_alloc_context into static guts and public function. Invoke static version from Parrot_set_new_context
22:16 chromatic That file works for me, Coke.
22:17 darbelo Hmm looks like I'm already there, can't remember when that happened...
22:17 Coke cg_annotate-3.4.1-Debian
22:17 darbelo Guess I'll break the build, then...
22:18 bacek darbelo: In Soviet Russia build brakes YOU!
22:18 * darbelo wields a +1 bit of commiting!
22:19 dalek parrot: r41186 | darbelo++ | trunk/CREDITS:
22:19 dalek parrot: Correct my email address in the CREDITS file.
22:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41186/
22:19 * Coke rolls against build borkage
22:19 bacek Hooray! darbelo, welcome aboard! :)
22:19 moritz darbelo++
22:20 chromatic Rule #1: don't break the build
22:20 chromatic Rule #2: increase the awesome
22:20 chromatic Welcome.
22:20 purl Welcome to #perl.  You will never find a more wretched hive of scum and pedantry.
22:20 moritz Rule #3: There is no Rule #3
22:21 chromatic Rule #3 is a lazy thunk.
22:21 darbelo Increase the build, don't break the awesome. Got it.
22:24 Coke chromatic: (I'm trying this on feather, fwiw.)
22:24 Coke afk dinner
22:24 chromatic feather might have an ancient callgrind_annotate.
22:25 pmichaud bumping rakudo's PARROT_REVISION from 41089 to 41181 results in a 5.10% speed improvement.  (This also includes a change to hll_map Parrot Float to Num, which should be slowing things down a bit)
22:26 moritz are the non-zer exit status things fixed?
22:26 moritz *zero
22:26 bacek moritz: I can't reproduce it on my box :-/
22:28 nopaste "pmichaud" at 72.181.176.220 pasted "patch to recycle PGE "cstack" arrays" (57 lines) at http://nopaste.snit.ch/17911
22:29 dalek parrot: r41187 | chromatic++ | trunk/src/call/context.c:
22:29 chromatic Clever.
22:29 dalek parrot: [context] Replaced a Context VTABLE call in Parrot_pcc_constants() with a
22:29 dalek parrot: get_context_struct_fast() call and revised code in init_context() to use
22:29 dalek parrot: get_context_struct_fast() when possible -- thanks to bacek for the suggestion.
22:29 dalek parrot: The result is another ~1.5% performance improvement.
22:29 pmichaud chromatic:  see nopaste #17911
22:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41187/
22:29 dalek parrot: r41188 | chromatic++ | trunk/src/interp/inter_misc.c:
22:29 dalek parrot: [src] Tidied a bit of documentation and worked around a compiler warning for a
22:29 dalek parrot: use of an uninitialized value.  No functional changes.
22:29 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41188/
22:29 pmichaud we can put limits on the size of the pool if we wish
22:31 pmichaud I'm trying it on my timing box to see what the improvement will be
22:31 chromatic Me too.
22:32 pmichaud just watching the spectest run it "feels" faster.  but the proof will be in the numbers.
22:32 nopaste "bacek" at 114.73.187.138 pasted "static alloc_context patch for chromatic++" (74 lines) at http://nopaste.snit.ch/17912
22:32 nopaste "chromatic" at 72.87.39.97 pasted "Files to add to svn:ignore" (13 lines) at http://nopaste.snit.ch/17913
22:32 bacek chromatic: can you benchmark nopasted patch?
22:33 chromatic I will in a bit.
22:33 bacek chromatic: ok
22:38 dalek parrot: r41189 | allison++ | trunk/src/packfile.c:
22:38 dalek parrot: [hll] Add language-specific library search path when 'load_language' is
22:38 dalek parrot: called.
22:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41189/
22:41 dalek parrot: r41190 | darbelo++ | trunk/src (3 files):
22:41 dalek parrot: Adjust svn:ignore on src/interp src/runcore and src/call. chromatic++ for noticing this.
22:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41190/
22:44 rg joined #parrot
22:46 mtk joined #parrot
22:46 mtk left #parrot
22:51 cotto Coke, lmk if you have any problems with the profiling runcore.
22:52 cotto (my tuits are a little short atm, but I'll be glad to fix/enhance it when I have time)
22:57 dalek parrot: r41191 | mikehh++ | trunk/MANIFEST.SKIP:
22:57 dalek parrot: manifest_tests failure - run tools/devc/mk_manifets_and_skip.pl
22:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41191/
22:57 dalek parrot: r41192 | cotto++ | trunk/tools/dev/pprof2cg.pl:
22:57 dalek parrot: [pprof2cg] make pprof2cg script executable
22:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41192/
22:57 pmichaud initial timing on my box seems to have made rakudo spectest run slower
22:57 pmichaud (with the cpool patch)
22:58 pmichaud I'll run the timings again to verify
22:58 pmichaud (but won't have results until I return home a couple of hours from now)
23:01 Coke cotto: I can't use cg_annotate on that file. does it have a minimum version requirement?
23:01 Coke (I'm on feather, using cg_annotate-3.4.1-Debian)
23:05 hercynium joined #parrot
23:05 Coke I installed kde for windows hoping that'd get me kcachegrind, but it doesn't seem to.
23:08 mikehh chromatic: I am getting a codetest failure for src/call/context.c - missing doicumentation - I am not sure of the fix here
23:08 Coke presumably someone added a function but forgot to document it.
23:09 * mikehh check before hitting the Enbter key
23:09 * mikehh as you see
23:09 Coke I would do an svn blame on the function, see who added it, and then open a trac ticket and assign it to them.
23:09 chromatic It's probably me.
23:10 Coke ... what, are you sting?
23:10 Coke (esoteric 90s lyrics for 100, alex.)
23:10 mikehh last modified by chromatic r41187
23:11 mikehh and it's in the headerizer part
23:16 chromatic It has documentation, though.  Why doesn't the test see it?
23:17 Coke could be finicky. did you hand roll it or let headerizer do it?
23:17 Coke I can take a look. moment.
23:19 chromatic I did it.
23:21 Coke fixed.
23:21 Coke thank you for writing documentation. =-)
23:21 Coke chromatic++
23:22 mikehh space before *
23:23 Coke the version darbelo sent to legal /just/ showed.
23:23 Coke (but is dated 3 days ago)
23:23 bacek Coke: too late :)
23:23 Coke I assume that means someone is manually monitoring that list for blockages, and I'm guessing it's allison.
23:24 darbelo Coke: parrot.org mail has been arriving late and/or out of order for a few days now. It could be related.
23:24 dalek parrot: r41193 | coke++ | trunk/src/call/context.c:
23:24 dalek parrot: fix function signature in docs
23:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41193/
23:24 dalek parrot: r41194 | chromatic++ | trunk/src/call/context.c:
23:24 dalek parrot: [call] Fixed VERY PICKY structure of documentation for an inline function
23:24 dalek parrot: specific to this file so that the VERY PICKY documentation test can find it.
23:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41194/
23:24 Coke darbelo: thos complaints were both from yahoos.
23:24 dalek parrot: r41195 | chromatic++ | trunk/t/codingstd/c_function_docs.t:
23:24 dalek parrot: [t] Made C function documentation test report what it *expects* to see, for
23:24 dalek parrot: debugging the very nitpicky formatting it wants.
23:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41195/
23:25 Coke chromatic: did your fix get beaten by my fix?
23:25 Coke (and yet still get svn dcommited?)
23:25 chromatic MERGE POWERS!!!
23:25 chromatic You get to be the bucket of water.
23:25 Coke active. form uf... YOU BASTARD>
23:25 Coke I'm always the water.
23:25 Coke You left me in that guy's room as a chamber pot the last time for a WEEK!
23:27 chromatic Too slow, so sad.
23:27 darbelo Coke: Well... I'm no yahoo and I'm conplainin' too.
23:28 Austin joined #parrot
23:29 Austin Thanks, purl
23:29 purl sure thing Austin
23:30 Austin seen masak?
23:30 purl masak was last seen on #parrot 8 days, 10 hours, 39 minutes and 37 seconds ago, saying: 'xactly.  [Sep  2 12:43:27 2009]
23:30 Austin yowza.
23:30 bacek $dayjob time
23:30 bacek See you!
23:31 Austin Bye bacek.
23:31 Austin And hello, bacek_at_work
23:31 Austin :)
23:31 dalek parrot: r41196 | bacek++ | trunk/src/pmc/cpointer.pmc:
23:31 dalek parrot: [cage] Remove redunant CPointer.destroy. Fix CPointer.clone to use allocated attributes.
23:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41196/
23:33 allison Coke: yup, it's me admining the directors list
23:33 allison Coke: happy to add anyone else who wants to review
23:34 allison Coke: (it's me admining all the parrot lists, and happy for volunteers on any of them, with appropriate privacy considerations on who admins which lists)
23:35 allison Coke: we don't get a horrible lot of spam, maybe 20 messages a week
23:35 Coke Feel free to add me to the lists.
23:36 Coke (on the admin side). I presume emails are forward to list admins saying "look, messages?"
23:36 allison aye
23:36 Coke partcl needs 'uname -r' from parrot. it's not in there, is it.
23:36 allison Coke: which list(s) do you want to be added to?
23:37 Coke <shrug> I can reject spam on any of the lists, not a problem.
23:37 Coke (or let messages through.)
23:37 Coke feel free to add me to all of them.
23:38 darbelo Coke: It isn't there. But why do you need it?
23:38 allison Coke: okay, doing now. I sent out the admin password to the directors when the lists were created, but can resend if needed
23:40 Coke darbelo: [puts $tcl_platform(osVersion)]
23:40 allison Coke: on parrot-commits, the only unusual thing is that the fake email address of each new committer needs to be added to the permanent "accepts" list
23:41 allison Coke: (their first commit message will hit the moderator queue)
23:41 Coke darbelo: also, http://www.tcl.tk/man/tcl8​.5/TclCmd/tclvars.htm#M21
23:42 dalek partcl: r721 | coke++ | trunk/runtime/tcllib.pir:
23:42 dalek partcl: Update issue #12
23:42 dalek partcl: adding tcl_platform(pointerSize)
23:42 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=721
23:46 allison darbelo: I've been seeing my posts back instantly, so maybe the mail delay is yahoo-related
23:49 payload joined #parrot
23:51 mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41196 - Ubuntu 9.04 amd64 (g++)
23:53 bacek joined #parrot
23:55 bacek Hello Austin :)
23:55 Austin hello, bacek. :)

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

Parrot | source cross referenced