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
Set by moderator on 8 September 2009.
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:05
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
cotto '40 is starting to look suspicious 00:07
darbelo cotto: Nothing after '40 touches anything even remotely related... 00:08
And somebody needs to revise the git developer's idea of 'portable' 00:09
cotto I'm checking '39
darbelo, can you build it from source without the extra GNU stuff?
(I imagine you wouldn't want to maintain such a build on your system, but I wonder if it's possible.) 00:10
pmichaud 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.
pmichaud pmichaud.com/sandbox/speed-2.png # spectests per second 00:12
00:13 rhr joined
darbelo I mean, I doubt anyone would list bloody *GNU tar* as a build-dep if it wasn't really needed. 00:13
pmichaud NotFound: I don't think of exception handlers as normally being run from the context where the exception was _thrown_ 00:15
often the handlers are run in the context where the exception is caught
darbelo There. I have git now. Let's go grab ourselves some rakudo! 00:16
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:18
00:21 whoppix joined
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:21
And running the handler in the context where the push_eh was done. 00:24
If that scheme may works, the inner runloop problem can be isolated from other issues. 00:26
Going to bed, will elaborate some more the idea tomorrow 00:28
00:41 sri_ joined 00:43 GeJ_ joined 00:44 TiMBuS joined 00:47 whoppix joined
cotto it's either '38 or '39, and I'll be very confused if it's '38 00:49
darbelo not that '39 isn't confusing. 00:51
cotto it's '39
darbelo How in hell does initializing coredata->flags make the profiling runcore 10x slower? 00:52
cotto I'd *love* to know. 00:54
00:55 whoppix joined 00:56 sri joined
cotto The plot thickens. If I make realclean, build 41138, svn up to 41139 and make install, rakudo is fast 00:56
Whiteknight what's amazing is that my coretest times keep going down 00:57
yet everybody else is losing performance
(I just ran coretest again in 37s)
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
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 01:14 Zak joined
Coke NotFound: #995 still happening for me. 01:15
01:19 hercynium joined 01:41 rhr joined 01:42 Zak joined 01:48 sri joined
bacek_at_work cotto: probably because flags should be runcore specific... 01:56
01:57 rhr joined 02:08 chromatic joined 02:14 rhr joined 02:28 Andy joined
dalek rtcl: r709 | coke++ | trunk/runtime/builtin/glob.pir:
initial version of [glob]
 02:28
02:35 janus joined 02:59 Zak joined
chromatic All of the Parrot_str_to_cstring() calls in the profiling runcore are spendy. 03:15
03:35 JimmyZ joined
dukeleto 'ello 04:14
Tene hi leto 04:23
dukeleto how goes it?
Tene took a nap when I got home. Now helping the gf with her homework and thinking about hacking. 04:30
Okay, checking out the patches on TT757 04:39
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.
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. :)
get_pmc_keyed_str() not implemented in class 'Signature' 04:44
yay!
kyle_l5l: does tt757.pir work for you with patches 1 and 3 applied? 04:48
kyle_l5l: I get a failed assertion in src/packfile.c:3071 04:49
oh, nm, I think. 04:50
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 05:15 kjeldahl joined
Tene kyle_l5l: interested in helping me to debug the next error with threads? 05:37
kyle_l5l sure
Tene kyle_l5l: add a .loadlib statement to the start of tt757.pir 05:38
like: .loadlib 'libsqlite3'
nopaste "tene" at 24.10.252.130 pasted "like this for kyle_151++" (16 lines) at nopaste.snit.ch/17901 05:39
Tene This ends up failing in the clone_libraries branch of parrotinterpreter.pmc:117
that gives: 05:40
get_pmc_keyed_str() not implemented in class 'UnManagedStruct'
when trying to clone the interpreter with perl6.pbc loaded, I've also recieved all of the following errors from that code path:
Null PMC access in get_string()
get_pmc_keyed_str() not implemented in class 'Integer'
get_pmc_keyed_str() not implemented in class 'ResizablePMCArray'
05:40 lnostdal joined
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:41
kyle_l5l ok, that works for me 05:42
Let me see if I can track down the fix for that. 05:43
Tene :) Thank you. I'll keep looking, but I'm a little lost. 05:44
nopaste "kyle_l5l" at 72.230.232.130 pasted "incremental in-progress parrotinterpreter.pmc patch" (44 lines) at 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
kyle_l5l Tene, try that. I think that's all you need... 05:52
cotto The culprit in the slowdown seems to be RUNCORE_JIT_OPS_FLAG, which was serendipitously set when coredata->flags was uninitialized. 05:55
dalek rrot: r41180 | petdance++ | trunk/lib/Parrot/Pmc2c/PCCMETHOD.pm:
fixed indent
 05:56
05:56 kjeldahl joined
Tene kyle_l5l: does that modified tt757.pir work for you with that patch? 05:59
It still gives me the same behavior.
I also have patches 1 and 3 from tt757 applied, if that's relevant.
cotto and it seems to have an effect even when Parrot's built with jitcapable=0 06:00
06:00 shockwave joined
shockwave I'm having an issue, which I'm sure is very simple to resolved, but I don't know how: pastebin.com/m7ec950ae 06:04
That simple snipped gives me the error at the bottom.
Tene kyle_l5l: you updated the clone_classes fork down at line 133. This failure happens before that, up at line 117
shockwave I don't understand the error. 06:05
kyle_l5l Tene, yeah. I'm missing another little something.
Tene shockwave: addattribute adds a field to a class; setattribute sets the value of that field on an *object* of that class. 06:06
you're trying to set it on the class itself.
shockwave ah!
So that means that if I want to implement default values on instance member, I must add them everytime I make an instance? 06:07
Tene shockwave: That sounds right to me, yes. 06:08
shockwave: To be specific, you must *set* them every time you instantiate.
you run addattribute once on the class, and setattribute every time on the instances.
shockwave yeah, sorry. THat's what meant.
Tene Just didn't want to lead you wrong. :)
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:10
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.
shockwave That would map to 2 setattributes.
I'll learn to live with it.
Thanks.
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:12
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.
treed shockwave: What language are you working on? 06:14
shockwave treed, my own concoction. It's for programming 3D games.
I'm calling it Gem.
treed Interesting. 06:17
Let me know when it's usable. 06:18
(Or I guess playable-with.
shockwave treed, well, it's actually a generic, class based language, like a combo of Java and Ruby.
So I'm hoping to make it so that it can be embeddable into anything.
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
But, for now (the first few years), it's just to drive the 3D engine I'm using.
Though, I wouldn't hold my breath. I just started last friday on it. 06:20
treed Oh, of course.
purl Indubitably.
treed Shut up, purl.
purl make me
treed I will. 06:21
maybe.
shockwave (I mean, on the language. The engine is working.)
nopaste "kyle_l5l" at 72.230.232.130 pasted "more patches for tt757.pir + .loadlib" (24 lines) at nopaste.snit.ch/17903 06:24
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?
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.
Tene Hmm.
kyle_l5l: It more looks to me like some things are ending up in iglobals[dyn_libs] that shouldn't be there. 06:27
cotto yup. stupid parrot was running more quickly because it switched to the fast runcore. 06:28
maybe if I instrument the fast runcore... 06:29
kyle_l5l Tene, happening in revs after 40736? 06:33
is it reasonable for a Class to have a name of '' ?
Tene kyle_l5l: anonymous subclass or something, I think...
kyle_l5l: I've only been working against the latest Parrot. 06:34
cotto all is sane, though disappointing
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
cotto bacek++ for clearing those flags and exposing that issue
Tene, #llvm on which network?
treed Tene: libjit that bad?
Tene I pointed them to allison's recent mail about JIT in the archives.
cotto: irc.oftc.net
treed: according to llvm devs, yes. They also disputed "Some developers claim it is difficult to use" with "where 'some developers' == 'libjit developers'" 06:36
treed Heh. 06:39
Tene kyle_l5l: new bugs? 'make test' in parrot is all passing... 06:40
kyle_l5l: if there are bugs in the latest parrot, can you submit tests for them or open tickets?
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.
cotto Tene, what does "bad" mean? non-portable, simple, buggy?
06:43 chromatic joined
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: 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.
aiee! libjit! 06:44
szbalint there sure are some strong feelings 06:45
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:47
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
chromatic Valgrind or cachegrind? 06:49
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
purl valgrind is probably not only astonishingly clever, but also has a beautifully written manual. or 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
cotto (callgrind)
chromatic Tene, I believe so. 06:51
cotto, my profile agrees with you. The expensive one is Parrot_Context_get_info. 06:52
cotto yeah. I'm looking into how to cheaply get the info I need without it. 06:53
chromatic Exactly.
Looks like we only need line and file information. 06:54
cotto I'm also tempted to use more concatenation to avoid fprintf.
chromatic First things first... half of our runtime goes to Parrot_Context_get_info.
cotto Half? running what? 06:56
chromatic More than half... 3/4, running examples/benchmarks/oofib.pir 06:57
07:00 iblechbot joined
chromatic It looks like we could extract src/sub.c lines 239 to 263. 07:01
07:07 mikehh joined
dalek TT #998 created by moritz++: Recent parrot changes cause lots of Rakudo spectests to abort with status ... 07:20
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.
How confident are you about that range?
moritz very 07:22
chromatic That helps a lot.
moritz the good revision (r41083) is directly after the the pluggable_runcores merge, everything was fine there
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.
cotto chromatic, why do you use oofib as a test of the profiler? 07:39
is it likely to be representative?
and of what?
chromatic It has loops and function calls and method dispatch. 07:40
moritz chromatic: actually I suspect the default runcore switch
chromatic It doesn't have complex control flow or exceptions, but it's substantive.
moritz but it's just a guess
chromatic moritz, I hope it's not that.
cotto g'night 07:44
moritz chromatic: now running spectest with latest parrot but slow core - we'll know in about an hour :/ 07:46
chromatic Thanks! 07:47
07:48 HG` joined 07:56 muixirt joined
muixirt good morning 07:57
purl And good moroning to you, muixirt.
muixirt are there any plans for some bindings for gui toolkits? 07:58
chromatic Yes... but they seem to be early plans. 07:59
07:59 payload joined
muixirt hopefully not this xlib library in examples 08:00
or what does it holding back?
chromatic Time and volunteers, more than anything.
moritz muixirt: Tene++ write some bindings for one of the enlightenment libraries 08:01
muixirt was progress made?
moritz s/write/wrote/
it was kinda usable from rakudo
muixirt and mainstream toolkits like gtk or qt? 08:03
moritz chromatic: switching to slow core didn't make the rakudo failures go away
Tene muixirt: They will be fairly straightforward to write wrapper libraries for.
Nobody has done it yet, but I'd be glad to help you with it if you'd like to try.
chromatic moritz, hooray... I think.
moritz, I've had a lot of trouble reproducing it. 08:04
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:05
chromatic If we had one test file that demonstrated it, I could have an easier time bisecting. 08:06
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
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.
moritz :-) 08:09
muixirt Tene, what would you prefer gtk, qt or wx?
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. :)
I have vague memories of disliking wx and qt, and not minding gtk...
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.
Tene but that was years ago
moritz chromatic: maybe I can come up with a way to bisect - will comment on the ticket if I do
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
chromatic It sounds like the list of affected files moves around.
08:19 allison joined
moritz yes; but if my selection is large enough, chances are that at least one of them is always affected 08:23
chromatic True.
mikehh dukeleto: I just updated Math::BigRat yesterday and you got a new version today 08:58
09:04 allison joined
muixirt ping Tene 09:35
purl I can't find Tene in the DNS.
10:04 Whiteknight joined
Whiteknight pops in for about 5 minutes 10:05
...and away! 10:13
10:20 MoC joined 10:31 HG` joined
muixirt moritz, ping 10:40
moritz muixirt: pong
muixirt moritz, on the topic of bindings ... 10:41
those nci bindings have to be made manually?
moritz muixirt: no, there's a NCI generator
don't know how well it works, though 10:42
or how much it bitrotted
muixirt that doesn't work
moritz then please open a ticket
muixirt even in the simple case of gtk/gtkenums.h
this nci interface is subject to change or is that stable? 10:43
moritz no idea; I fear I'm the wrong person to ask 10:44
10:47 mokurai left
muixirt I wonder if a 1 to 1 approach for gui bindings are the right thing to do 10:47
moritz it's probably not "right" in the sense that it's best API you can offer for the HLL 10:51
but it's little work, and it means that you can refer to the original toolkit documentation instead of writing your won 10:52
s/won/own/
11:03 kjeldahl joined 11:06 payload joined 11:10 quek joined 11:32 quek left 11:50 bacek joined 11:51 MoC` joined 12:00 whiteknight joined 12:06 masak joined 12:15 JimmyZ joined
moritz debian only wants to ship "stable" parrot releases 12:17
and rakudo can't be installed with the last stable parrot release 12:18
so rakudo distribution on debian waits for parrot-2.0. Sigh.
muixirt only a matter of time 12:21
anyone who knows nci well? 12:28
bacek o hai 12:29
muixirt how is something like "void gtk_init (int *argc,char ***argv);" translated w.r.t. nci? 12:31
dalek TT #139 closed by bacek++: Move executable code out of jit_emit.h for IA64 12:32
TT #140 closed by bacek++: Move executable code out of jit_emit.h for ALPHA
bacek muixirt: you probably have to edit src/call_list.txt and add signature for such functions 12:36
muixirt hmm 12:37
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41180 - Ubuntu 9.04 amd64 (g++) 12:39
muixirt ManagedStruct?
bacek muixirt: I'm not sure about ManagedStruct. 12:42
mikehh moritz: hey how about reporting the parrot revision in the rakudo Configure.pl like partcl does 12:43
moritz mikehh: sure, patches welcome
mikehh I just built and tested rakudo without running make install-dev and only noticed when I tried with partcl 12:44
moritz: i'll have a look :-} 12:45
moritz well, we already have a warning for that one
nopaste "moritz" at 132.187.31.74 pasted "Configure.pl warning for mikehh++" (16 lines) at nopaste.snit.ch/17905 12:46
moritz note that it might not work if you have an older version of parrot install-dev'ed
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
er, afk.
dalek TT #145 closed by bacek++: Move executable code out of jit_emit.h for SUN4 12:55
TT #144 closed by bacek++: Move executable code out of jit_emit.h for PPC 12:56
TT #143 closed by bacek++: Move executable code out of jit_emit.h for MIPS
TT #142 closed by bacek++: Move executable code out of jit_emit.h for HPPA
TT #141 closed by bacek++: Move executable code out of jit_emit.h for ARM
bacek cheap karma :)
12:56 HG` joined 12:57 ruoso joined
mikehh rakudo (5960161) builds on parrot r411780 - make test / make spectest (up to r28216) PASS - Ubuntu 9.04 amd64 (g++) 12:59
rakudo - t/spec/S03-operators/arith.rakudo - TODO passed: 120, 131-132
dalek TT #189 closed by bacek++: deprecated: random PMC
whiteknight hasn't even thought about RT in a while 13:01
I guess I should go back there eventually and see about closing some low-hanging fruit
dalek TT #375 closed by bacek++: FREEZE_ASCII doesn't work 13:03
bacek This was very-low-hanging fruit :)
whiteknight still exciting! We're moving forward on JIT finally!! 13:06
dalek TT #353 closed by bacek++: fix jit 386 set_i_n
TT #352 closed by bacek++: fix jit i386 with long double
moritz whiteknight: after some discussion in #llvm I think that llvm-gcc or clang could initially replace our lorito prototype 13:07
because it can compile C code to LLVM code
whiteknight I think we could write a pure-ASM NCI function dispatcher and not need JIT for that
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
moritz so all the PMCs could be JITted without need for lorito
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
yes
moritz for a prototype it's OK to require llvm-gcc or so
and once we are convinced that llvm really works for us, we can look into replacing it
dalek TT #356 closed by bacek++: better detect jit cpuarch with possible cmdline overrides 13:10
TT #530 closed by bacek++: Failure of atan2 in jit core - ref TT #38 13:13
TT #501 closed by bacek++: t/op/trans.t failures with jit on *BSD
whiteknight irclogs? 13:15
purl it has been said that irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
whiteknight moritz: what network is #llvm on?
moritz whiteknight: irc.oftc.net
whiteknight awesome 13:16
is that chatroom logged? 13:17
moritz if so it's not listed in the topic
whiteknight of course, the logs aren't listed in our topic either 13:18
moritz in #perl6 they are 13:19
dalek TT #672 closed by bacek++: PASM1 compiler needs tests. 13:20
TT #795 closed by bacek++: Kill Parrot_sub structure 13:23
13:24 tokuhirom___ joined 13:33 payload joined
dalek TT #983 closed by bacek++: JIT code incorrectly access registers 13:40
bacek ok. Enough cheap karma for today. 13:41
moritz changes bacek's day to tomorrow
see, now you can continue :-)
bacek moritz: it's still 20 minutes till tomorrow! 13:42
clock?
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 /
bacek moritz: see? :)
13:57 whiteknight joined
whiteknight go bacek go bacek go! 13:59
bacek whiteknight: no way. I'm going to bed. It's tomorrow already :) 14:00
whiteknight whatever, you've done enough going for one day 14:03
bacek++
bacek I did almost nothing. Just skimmed over TT and closed few tickets. 14:05
whiteknight but that's very valuable 14:10
closing old tickets is something that we have never done well
dalek TT #356 reopened by doughera++: better detect jit cpuarch with possible cmdline overrides 14:11
14:19 theory joined 14:39 kjeldahl joined 14:45 Tene joined
Tene muixirt: ping 14:46
14:50 Psyche^ joined 15:03 Andy joined 15:11 payload joined 15:33 hercynium joined
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 15:42
Coke whiteknight: all the low hanging fruit on RT has already fallen and rotted. 16:07
whiteknight awesome
or maybe not awesome,I don't really understand the metaphore 16:08
Tene whiteknight: There was discussion abot Parrot's JIT plan on #llvm last night. 16:09
whiteknight is very sorry he missed that
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.
There aren't any.
Except personal logs, like mine. :D
whiteknight oooohhh! I CAN HAZ?
Tene They also said that the "libjit is easy / llvm is hard" stuff was very out-of-date.
Sure. 'sec
sent. 16:12
whiteknight Tene++
dukeleto Tene: mind sending me a copy of that as well ? 16:14
Tene whiteknight: Um, did i send the right log? I'm no longer sure that I did. 16:16
whiteknight looks like it
it's a log of you talking to xxxprincess1234xxx about sex? 16:17
still reading, but I'm wondering when you're going to mention LLVM or Parrot :(
:)
Tene :) 16:18
whiteknight I chatted with the libJIT people, and they said the same stuff about LLVM! 16:22
whiteknight detects a feud
Tene orly?
purl YA RLY.
Tene I'm very curious to see that discussion.
whiteknight I don't think that got logged either
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
Tene what were there specific complaints/objections about llvm?
whiteknight just that it was hard to use mostly
16:24 darbelo joined
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
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. =-)
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, ilia joined 16:31 ilia joined
mikehh dukeleto: I wasn't complainin' or anything like that :-}, just comentatin' 16:47
16:52 KatrinaTheLamia joined
KatrinaTheLamia I am going to assume this server has custom services?--the user nickserv does not appear to exist. 16:57
16:58 jan joined
Coke no nickserv here, sfaik. 17:00
PerlJam KatrinaTheLamia: this network is a tad wilder than freenode :)
muixirt japhb, thanks, I must have overlooked it in the docs :-)
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 ^.^
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:02
17:04 MoC joined
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?
PerlJam KatrinaTheLamia: feather is for people doing parrot/perl6 dev. you'll get an account. The ability to login and do stuff. :) 17:06
KatrinaTheLamia PerlJam, so it is a shell account then. Yay! 17:07
PerlJam, there will be no issues with IRC traffic on it then?
PerlJam no 17:08
KatrinaTheLamia ah, okay ^.^
I'll work into figuring something out then ^.^
PerlJam But if you start doing Bad Things, there will be bunches of people upset at you though.
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:09
PerlJam, yeah, I don't crap where I sleep--or some such saying to that effect. 17:10
PerlJam, I recognise that it is not my server, and .'. not my place to go crazy with things.
muixirt japhb, well at least the list of features is easy to remember 17:11
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:14
duk3leto PerlJam: what is Juerd's email ? 17:15
pmichaud purl: juerd?
purl juerd is root or at juerd.nl/ or mailto:juerd@juerd.nl
KatrinaTheLamia alright, will be looking into this... thankies ^.^ 17:18
dalek rtcl: r710 | coke++ | trunk/runtime/builtin/ (2 files):
Add 'flush' to the list of things that socket's can't do. =-)
 17:19
17:20 ilia joined
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:20
17:26 joeri joined 17:38 mokurai joined
Tene muixirt: You were pinging me last night, and then my shell server was rebooted. 17:45
17:49 MoC joined
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:49
KatrinaTheLamia: Or I can create an account on feather for you right now. 17:50
muixirt Tene, never mind 17:51
Tene OK. :)
muixirt: you've started on gtk bindings? 17:52
muixirt Tene, I'm still looking for clues how this nci stuff works
yes
Tene muixirt: you might want to look at my github.com/tene/parrot-elementary/
e17 gui bindings
That should be a very good example to start with.
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.
muixirt I look into it, thanks 17:55
NotFound Xlib example is basic functionality, not very useful for a GUI. 18:00
18:00 chromatic joined
Tene Also, Xlib.pir is a lot longer than Elementary.pir 18:01
Xlib is a lot more complicated to deal with than a high-level toolkit.
NotFound You just need to memoize all 3 books of Xlib Programming/Reference/Protocol and you'r fine ;) 18:03
Tene I'd object to that if I hadn't memorized at least an equal volume of other esoteric details. :) 18:04
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:06
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 :-)
Tene Elementary.pir has two parts... the first just loads all of the right functions, the second makes some classes to deal with them.
NotFound muixirt: What lib are you planning to wrap? 18:08
muixirt gtk
NotFound muixirt: I don't think some basic gtk usage must be difficult 18:10
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.
Show show to hide the struct pointers in a private attribute of the class, etc.
muixirt ok, thanks, bbl 18:14
Tene KatrinaTheLamia: Sorry, looks like I lied. I don't actually have sudo privs on feather, so you'd have to contact juerd. 18:17
pmichaud KatrinaTheLamia: several people on #perl6 might be able to help with a feather acct 18:22
18:31 mberends joined
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:38
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.
(and there are things the current NCI simply can't support at all, but we'll get there) 18:40
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?
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:42
NotFound japhb: OpenGL uses callbacks without giving a way to pass arguments to them. 18:43
japhb NotFound, right, that's what I meant.
NotFound Well, lots of libraries doesn't have such specific problem, so OpenGL is a too complex example. 18:44
japhb NotFound, sure.
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:45
NotFound duk3leto: as japhb said, it that callbacks fit the opaque pointer style you're lucky 18:51
duk3leto japhb: i am not sure, what is the exact definition of "opaque pointer" ? 18:53
Coke ponders again switching to PCT.
(instead of TGE)
PerlJam Coke: do it! :)
NotFound duk3leto: you pass a pointer to the function that set the callback, and the callback is called with that argument
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.
The API must not treat the pointer as anything other than a void *.
NotFound "opaque" as long as the library does nothing more than passing it
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
japhb Tene, I'm all for it. 18:56
Coke are there better pct docs than docs.parrot.org/parrot/latest/html/...s.pod.html ?
Tene but, that's wild speculation at this point. :)
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.)
Tene Coke: dunno... I've never used that. I've read the pdd and perldoc of the PCT .pir
Coke ok. if that's helpful, it should end up in the bundled html docs. =-)
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. ;-)
Coke Tene: which file, exactly? 18:59
(top level, second level are just placeholders)
(under compilers/pct)
Tene Coke: PCT/Node.pir
Coke: I *really* don't know wtf is going on with html generated docs... 19:00
I've never used them or looked at them.
I know that treed has run into trouble several times by trying to use docs on the website.
Coke Tene: Node.pir seems to assume I already have things already setup.
pmichaud Coke: how much does tcl currently rely on TGE?
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"
pmichaud okay. let me browse partcl a bit
Tene Coke: Sure, it's documentation for the PCT Nodes...
Coke the .tg files are in src/grammar/expr
Tene: I don't need docs for the nodes.
treed still doesn't really know PCT.
Coke I need docs for "using pct"
treed I know a great deal about using PIR.
Tene Coke: you weren't very specific in asking for "PCT docs"
treed But PCT is mostly still magic for me. 19:02
Coke Tene: Assume I know nothing about PCT and wish to use it. =-)
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
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.
:)
AFK teaching 19:03
treed Learning by example is only good to a certain extent.
Coke looking at rakudo to figure out how use PCT strikes me as... crazy.
there's a LOT in rakudo. how do I know what is PCT and what isn't?
treed My favored learning technique is: Learn some of the theory, see examples, try it out. Maybe ask some questions.
Rinse. Repeat.
If you learn only from examples, you might interpret things incorrectly. 19:04
So, here's this code that looks like it does this thing, but does it really? And why was it done this way?
NotFound duk3leto: some example code? 19:05
treed What are the other options for getting this job done, and why choose this one?
etc
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
OK, AFK for a while
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
s/for ac/with ac/
19:08 MoC` joined
duk3leto NotFound: here is an example: www.gnu.org/software/gsl/manual/htm...mples.html 19:13
pmichaud yes, it's very doable.
(rakudo does it for BEGIN blocks and the like)
Coke k. that would help me solve one big partcl ticket (and several dozen spec tests.) 19:14
pmichaud what's an incredibly simple tcl program I can use to start with? 19:18
something as simple as [puts 'ok'] (given that I don't know tcl syntax)
Coke puts ok
pmichaud no brackets?
Coke right.
brackets are subcommands. (run that command and return the result) 19:19
so "set a 2; puts [set a]" would print out 2, e.g.
KatrinaTheLamia thanks ^.^
NotFound duk3leto: ¿Cuáles son esos múltiples argumentos?
Uh, sorry
pmichaud with "puts ok", the bare 'ok' is a string? 19:20
NotFound duk3leto: What are the multiple arguments for the callback?
Coke yes. You could do
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
Coke which does the same thing if the quotes make you feel better, but they are redundant in this case.
pmichaud well, it's a matter of being able to trace it easily through the parse tree
I'm thinking "ok" might be easier to follow to begin with than the bare ok
Coke it should add another parse step, converting the "ok" to just ok. 19:22
but both are valid, ja.
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: www.gnu.org/software/gsl/manual/htm...mples.html
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:24
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
first glance, it looks very doable
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.
pmichaud caveat: this might make things even slower. then again, it might make them faster. :-)
19:28 pdcawley_ joined
pmichaud iiuc, most of what partcl does is convert things into function calls anyway, yes? 19:28
Coke pmichaud: at the moment, yes.
pmichaud seems like it ought to be workable then
Coke we have to have SOME way to avoid that for the builtin commands at some point.
pmichaud last question for the moment -- can I haz commit bit?
Coke absolutely. same rules as parrot. 19:29
pmichaud I'll just work in a branch
Coke +1.
purl 1
Coke purl, you idiot, I knew that.
purl Coke: excuse me?
Coke pmichaud: need a google account id.
pmichaud pmichaud@pobox.com should work
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
KatrinaTheLamia purl, he refered to you as an idiot... take it how you will ^.^ 19:30
purl KatrinaTheLamia: sorry...
Coke pmichaud: added.
pmichaud yay
Coke pmichaud: (there are mailing lists if you care to get commit emails, that sort of thing. linked to off the front page.)
no, yay me!
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
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.
chromatic That was my impression as well.
pmichaud right
Coke so, easier to maintain is better than speed just now. And if PCT gets faster, then I win too.
pmichaud and besides, rakudo (and I) owe a lot to partcl, so I don't mind investing some energy back :)
I probably won't get to do anything with it today, but tomorrow looks promising. 19:32
dalek rtcl: r711 | coke++ | trunk/docs/spectest-progress.csv:
update spec test numbers.
Coke pmichaud: um. you said pobox?
pmichaud yes
google probably converted it to my gmail addr
Coke ... it seems to have changed it to your ... yah.
making sure i'm not crazy. thank you. =-) 19:33
13433/7720
purl 1.74002590673575
Coke chromatic: that's the speedup between parrot 41154 and 41180
(running 'make spectest')
pmichaud does tcl use pct::hllcompiler at all? 19:34
I suspect no, based on previous comments.
chromatic Coke, how do I interpret those numbers?
Oh, a 42.5% speedup. That's nice. 19:35
Coke pmichaud: nope. 19:36
chromatic: yup.
chromatic Coke, random guess: r41164. 19:37
pmichaud runs a spectest to see if we can bump rakudo to r41180
afk, errands 19:38
chromatic r41159 won't hurt much either.
dalek rrot: r41181 | chromatic++ | trunk/src/sub.c:
[sub] Coalesced repeated calls to Parrot_pcc_get_pc() in
Coke chromatic: another data point: 19:45
r41161 took 9855s
chromatic Likely both of them then. Good to know. 19:46
Coke I live to serve. 19:47
Tene pmichaud: think of tcl as kinda like bash... text is a literal quote, require special syntax to make text special. 19:50
dalek rtcl: r712 | coke++ | trunk/config/PARROT_VERSION:
this version somewhat speedier.
 19:53
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:56
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?
purl this is probably different
Tene purl: shut up 19:58
purl make me
Tene purl: make: *** No rule to make target `me'. Stop.
purl You forgot to ./configure PREFIX=/usr/local/Tene/ass
Tene Ah, OK
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:00
Tene ;,; 20:01
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:02
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.
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.
chromatic That's unfortunate. 20:04
allison chromatic: it makes sense from a packaging perspective
rakudo will go in their "experimental" package repository until then 20:05
chromatic Why?
allison because it makes it really easy for people to test it
(better than asking them to manually download the packages)
chromatic No, why wait for 2.6?
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
chromatic Debian "stable" or Parrot "supported"?
allison Rakudo Star
(whatever adjective we use for it)
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 :)
I can call it the chocolate sauce release if that helps
chromatic I prefer that, in all seriousness. 20:08
pmichaud why not the "*" release? ;-)
chromatic That's fine, too.
allison okay, well the very first chocolate sauce release is likely to have a few bugs to shake loose
chromatic So?
allison (much like Parrot 1.0)
chromatic Much like every other package in Debian stable.
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"
we'll probably have a couple of testing releases before it
allison good idea
purl allison: Good Idea: Playing the piccolo in a marching band. Bad Idea: Playing the piano in a marching band.
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"?
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.
allison then, they test it on all their platforms, and if it gets green flags on all of them, it moves to Debian 'testing'
then, fingers crossed, it makes it into the next Debian 'stable' release 20:11
which takes time
(Parrot 1.4 just moved into 'testing', and we've been in the pipeline since a few days after 1.0)
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
20:13 HG` joined
allison yah 20:13
chromatic Okay. I don't like that, but I'm not going up against all of Debian.
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.
Coke are you saying it's a tautological misstep to refer to anyone as a better man than you?
Tene Of course.
purl Indubitably.
allison more chococolately goodnessy men than you...
pmichaud "less stable" 20:15
allison :)
chromatic More Finnish men than you...
pmichaud r41180 seems to pass rakudo spectests.... but let's try r41181 for its minor optimization as well :-)
Tene officially gives up on tt757 work again 20:16
Coke pmichaud: how long does your spec test run take atm?
chromatic bugs.debian.org/cgi-bin/bugreport.cgi?bug=413685
Coke (are you tracking that in your cvs?)
chromatic modeemi.fi/~tuomov/b/archives/2007/...T19_15_26/
Coke (csv)
pmichaud last run took 42min user time, 22min wall-clock time 20:17
(because I can test in parallel)
I don't track the times in my csv because I don't have a dedicated platform to give apples-to-apples numbers
Coke 7720/60
purl 128.666666666667
Coke 7720/60/60
purl 2.14444444444444
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.
NotFound allison: So maybe a woman must try ;)
pmichaud Coke: yes, but even feather can be affected by load at times :)
Coke yah. just a placeholder until something better comes along. 20:19
pmichaud pmichaud.com/sandbox/speed-1.png # spectest timings for rakudo, 05-27 to present
Coke anyone know if youc an create a new Interpreter from PIR and actually run things on it?
allison NotFound: :) 20:20
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.
pmichaud pmichaud.com/sandbox/speed-2.png # average tests per second, 05-27 to present
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?
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
Coke so, it's just general PMC pressure?
chromatic Yes.
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.
Coke is it me or did profiling get MUCH faster since it was merged back.
?
pmichaud actually, now that I think about it, recycling them is hard 20:26
chromatic How so, pmichaud?
pmichaud I don't know when they're no longer use(ful)
I guess I would know it upon completely failing a match
chromatic That's one case. 20:27
pmichaud and that's the more common case, so that'd be helpful
chromatic Especially in the Perl 6 grammar's ws rule.
That was the expensive one, in my profiles.
Even a simple hand-edit to that rule's generated PIR could be a useful as a proof of concept.
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 :)
chromatic dev/tools/pprof2cg.pl I think.
pmichaud I can totally see how it would result in a performance improvement
chromatic Whatever's easiest for you, pmichaud. It seemed worth a small test to me.
pmichaud if mark+sweep is the costly part, we can definitely do something about it
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.
pmichaud backtracking rules and rules with captures definitely create them
because we need a place to store the backtrack information
anyway, I will give it a try tonight. I suspect it will only take an hour or so to implement and test 20:30
how can I find out if things are improved (short of rakudo spectest showing a dramatic speed improvement)?
afk for 15 mins (errand) 20:31
chromatic Anything that uses PGE should show a measurable improvement, if it works. 20:32
20:33 kjeldahl joined
dalek rtcl: r713 | coke++ | trunk/runtime/builtin/flush.pir:
cleanup PIR
 20:44
pmichaud r41181 saved about 30 seconds from the previous run.
rtcl: r714 | coke++ | trunk/tools/profiler.pl:
profiling parrot code in their trunk, can now get cg-compatable output from it.
chromatic Wow. pmichaud, what do you use Parrot_Context_get_info() for? Do you know offhand? 20:47
dalek kudo: 8ea834f | pmichaud++ | build/PARROT_REVISION:
Bump to 41181, to (hopefully) get some speed improvements.
chromatic I can get you another 4.8%, if my numbers are right. 20:50
20:50 payload joined 20:53 bacek joined
chromatic 4.55%. That'll do. 21:01
dalek rrot: r41182 | chromatic++ | trunk/src/call/context.c:
[pcc] Added static, inlineable get_context_struct_fast() for use only in this

Parrot_pcc_get_context_struct(). Billions of calls to the latter (almost all from within this file itself) add up; one Rakudo spectest shows a 4.55% performance improvement.		 21:02
chromatic Hm, am I misunderstanding -DNDEBUG? 21:06
Apparently so. 21:09
www.ralfebert.de/blog/tools/visual_...utorial_1/ 21:11
darbelo bacek: ping
21:14 japhb joined
nopaste "darbelo" at 200.49.154.172 pasted "Leftover from r41178 for bacek++" (16 lines) at nopaste.snit.ch/17910 21:14
darbelo msg bacek Looks like I missed a FREEZE_ASCII removal in my last patch. see nopaste.snit.ch/17910 21:16
purl Message for bacek stored.
dalek rrot: r41183 | NotFound++ | trunk/src/pmc/fixedpmcarray.pmc:
[pmc] Workaround for FixedPMCArray sort method, TT #218
bacek Good morning 21:18
purl And good moroning to you, bacek.
bacek darbelo: You sent a CLA, didn't you?
darbelo Yup, but no response yet. 21:19
bacek chromatic: ping.
darbelo Looks like you're stuck with my patches :)
bacek darbelo: not only me :) 21:20
darbelo It was a plural "you" ;)
I guess it's y'all over there. 21:21
dalek rrot: r41184 | bacek++ | trunk/t/pmc/sub.t:
[t] Add todoed ticket for TT#132
 21:23
rrot: r41185 | bacek++ | trunk/src/pmc_freeze.c:
Remove last reference to FREEZE_ASCII. Patch courtesy of darbelo++
21:27 kid51 joined
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
21:28 joeri left
dalek kudo: d0355a5 | pmichaud++ | src/classes/Num.pir:
Enable hll_map for Float->Num. This enables us to pass some tests
 21:37
21:39 ruoso joined
chromatic muixirt, I have no good answer for that. Maybe the code is out of date and needs updating. 21:47
bacek chromatic: can you check that CLA of bloody annoying darbelo arrived and give him commit bit? :) 21:51
chromatic Nothing where I can see it. Did he mail, fax, or email it? 21:53
bacek darbelo: ping.
chromatic Did you like r41182, bacek?
darbelo chromatic: email
bacek: pong
chromatic Where did you mail it, darbelo?
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?
chromatic I'll take a look, bacek. Where do you recommend? 21:55
darbelo I think I mailed it Sep 7
bacek chromatic: nm. It's already in this way
chromatic darbelo, I don't see anything. You could mail me directly if you like; mynick @wgz.org
bacek chromatic: src/call/context.c:1316. We can avoid VTABLE call here. 0.001% win 21:56
chromatic 0.04% to be precise! 21:57
bacek Still win :) 21:58
21:58 fperrad left
bacek chromatic: line 1143 also. 21:59
chromatic 1143 won't work; see the comment. 22:00
bacek Just wrap it into if(!PMC_IS_NULL).
Coke bacek: I'm on legal, I got nothing. 22:01
whoops
bacek It's usually not-null, so manual inlining will help.
Coke darbelo: I'm on legal, I got nothing.
dalek rtcl: r715 | coke++ | trunk/ (2 files):
fix [namespace tail]
 22:02
rtcl: r716 | coke++ | trunk/t/cmd_namespace.t:
Add test to catch proper errors on NS deletion of invalid items.
chromatic Makes sense, bacek. 22:03
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%.
darbelo chromatic: set a mail to you @wgz.org just now. Let me know if it reaches you.
chromatic I see it, darbelo.
dalek rtcl: r717 | coke++ | trunk/runtime/builtin/namespace.pir:
Move [namespace delete] inline.
 22:07
rtcl: r718 | coke++ | trunk/runtime/builtin/namespace.pir:
Modify PIR heavily to use hllmacros
rtcl: r719 | coke++ | trunk/runtime/builtin/namespace.pir:
[namespace delete] should error when deleting a non-existant ns.
rtcl: r720 | coke++ | trunk/runtime/builtin/info.pir:
add [info procs]
bacek chromatic: manual inlining in Parrot_push_context should provide measurable speed-up 22:09
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
(because that errors)
chromatic darbelo, you should have SVN commit access now. Please feel free to add yourself to CREDITS to test. Your trac credentials should work.
Coke, it should work.
Coke Line 1: missing command line 22:11
(after: cg_annotate parrot.out.32261)
chromatic bacek, looks like a 0.12% improvement on this benchmark.
bacek chromatic: with push_context inlined?
chromatic Yes. 22:12
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
Coke chromatic: yes, so does mine. :| 22:14
chromatic bacek, they're just not that expensive in the profiles here.
Let me find a benchmark that uses a lot more subs.
Coke 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
chromatic That file works for me, Coke. 22:16
darbelo Hmm looks like I'm already there, can't remember when that happened... 22:17
Coke cg_annotate-3.4.1-Debian
darbelo Guess I'll break the build, then...
bacek darbelo: In Soviet Russia build brakes YOU! 22:18
darbelo wields a +1 bit of commiting!
dalek rrot: r41186 | darbelo++ | trunk/CREDITS:
Correct my email address in the CREDITS file.
 22:19
Coke rolls against build borkage
bacek Hooray! darbelo, welcome aboard! :)
moritz darbelo++
chromatic Rule #1: don't break the build 22:20
Rule #2: increase the awesome
Welcome.
purl Welcome to #perl. You will never find a more wretched hive of scum and pedantry.
moritz Rule #3: There is no Rule #3
chromatic Rule #3 is a lazy thunk. 22:21
darbelo Increase the build, don't break the awesome. Got it.
Coke chromatic: (I'm trying this on feather, fwiw.) 22:24
afk dinner
chromatic feather might have an ancient callgrind_annotate.
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:25
moritz are the non-zer exit status things fixed? 22:26
*zero
bacek moritz: I can't reproduce it on my box :-/
nopaste "pmichaud" at 72.181.176.220 pasted "patch to recycle PGE "cstack" arrays" (57 lines) at nopaste.snit.ch/17911 22:28
dalek rrot: r41187 | chromatic++ | trunk/src/call/context.c:
[context] Replaced a Context VTABLE call in Parrot_pcc_constants() with a

get_context_struct_fast() when possible -- thanks to bacek for the suggestion. The result is another ~1.5% performance improvement.		 22:29
chromatic Clever.
pmichaud chromatic: see nopaste #17911
rrot: r41188 | chromatic++ | trunk/src/interp/inter_misc.c:
[src] Tidied a bit of documentation and worked around a compiler warning for a
pmichaud we can put limits on the size of the pool if we wish
I'm trying it on my timing box to see what the improvement will be 22:31
chromatic Me too.
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 nopaste.snit.ch/17912
"chromatic" at 72.87.39.97 pasted "Files to add to svn:ignore" (13 lines) at nopaste.snit.ch/17913
bacek chromatic: can you benchmark nopasted patch?
chromatic I will in a bit. 22:33
bacek chromatic: ok
dalek rrot: r41189 | allison++ | trunk/src/packfile.c:
[hll] Add language-specific library search path when 'load_language' is
 22:38
rrot: r41190 | darbelo++ | trunk/src (3 files):
Adjust svn:ignore on src/interp src/runcore and src/call. chromatic++ for noticing this.
 22:41
22:44 rg joined 22:46 mtk joined, mtk left
cotto Coke, lmk if you have any problems with the profiling runcore. 22:51
(my tuits are a little short atm, but I'll be glad to fix/enhance it when I have time) 22:52
dalek rrot: r41191 | mikehh++ | trunk/MANIFEST.SKIP:
manifest_tests failure - run tools/devc/mk_manifets_and_skip.pl
 22:57
rrot: r41192 | cotto++ | trunk/tools/dev/pprof2cg.pl:
[pprof2cg] make pprof2cg script executable
pmichaud initial timing on my box seems to have made rakudo spectest run slower
(with the cpool patch)
I'll run the timings again to verify 22:58
(but won't have results until I return home a couple of hours from now)
Coke cotto: I can't use cg_annotate on that file. does it have a minimum version requirement? 23:01
(I'm on feather, using cg_annotate-3.4.1-Debian)
23:05 hercynium joined
Coke I installed kde for windows hoping that'd get me kcachegrind, but it doesn't seem to. 23:05
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.
mikehh check before hitting the Enbter key 23:09
mikehh as you see
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.
chromatic It's probably me.
Coke ... what, are you sting? 23:10
(esoteric 90s lyrics for 100, alex.)
mikehh last modified by chromatic r41187
and it's in the headerizer part 23:11
chromatic It has documentation, though. Why doesn't the test see it? 23:16
Coke could be finicky. did you hand roll it or let headerizer do it? 23:17
I can take a look. moment.
chromatic I did it. 23:19
Coke fixed. 23:21
thank you for writing documentation. =-)
chromatic++
mikehh space before * 23:22
Coke the version darbelo sent to legal /just/ showed. 23:23
(but is dated 3 days ago)
bacek Coke: too late :)
Coke I assume that means someone is manually monitoring that list for blockages, and I'm guessing it's allison.
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 rrot: r41193 | coke++ | trunk/src/call/context.c:
fix function signature in docs
rrot: r41194 | chromatic++ | trunk/src/call/context.c:
[call] Fixed VERY PICKY structure of documentation for an inline function
Coke darbelo: thos complaints were both from yahoos.
dalek rrot: r41195 | chromatic++ | trunk/t/codingstd/c_function_docs.t:
[t] Made C function documentation test report what it *expects* to see, for
Coke chromatic: did your fix get beaten by my fix? 23:25
(and yet still get svn dcommited?)
chromatic MERGE POWERS!!!
You get to be the bucket of water.
Coke active. form uf... YOU BASTARD>
I'm always the water.
You left me in that guy's room as a chamber pot the last time for a WEEK!
chromatic Too slow, so sad. 23:27
darbelo Coke: Well... I'm no yahoo and I'm conplainin' too.
23:28 Austin joined
Austin Thanks, purl 23:29
purl sure thing Austin
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]
Austin yowza.
bacek $dayjob time
See you!
Austin Bye bacek. 23:31
And hello, bacek_at_work
:)
dalek rrot: r41196 | bacek++ | trunk/src/pmc/cpointer.pmc:
[cage] Remove redunant CPointer.destroy. Fix CPointer.clone to use allocated attributes.
allison Coke: yup, it's me admining the directors list 23:33
Coke: happy to add anyone else who wants to review
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:34
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.
(on the admin side). I presume emails are forward to list admins saying "look, messages?" 23:36
allison aye
Coke partcl needs 'uname -r' from parrot. it's not in there, is it.
allison Coke: which list(s) do you want to be added to?
Coke <shrug> I can reject spam on any of the lists, not a problem. 23:37
(or let messages through.)
feel free to add me to all of them.
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
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
Coke: (their first commit message will hit the moderator queue) 23:41
Coke darbelo: also, www.tcl.tk/man/tcl8.5/TclCmd/tclvars.htm#M21
dalek rtcl: r721 | coke++ | trunk/runtime/tcllib.pir:
Update issue #12
 23:42
allison darbelo: I've been seeing my posts back instantly, so maybe the mail delay is yahoo-related 23:46
23:49 payload joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r41196 - Ubuntu 9.04 amd64 (g++) 23:51
23:53 bacek joined
bacek Hello Austin :) 23:55
Austin hello, bacek. :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!