»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend!
Set by sorear on 4 February 2011.
00:00 Alias left 00:03 Alias joined
felher Whats the preffered idiom to do something x times? 'for ^x { do_something() }'? 00:03
donri 5.times do something end # nowait 00:05
00:10 molaf joined
[Coke] nom: for ^5 { say 1} 00:13
TimToady you mean rakudo: now
donri that sucker be merged eh
TimToady not a merge, a replacement 00:14
rakudo: say 1 for ^5
p6eval rakudo 2bac6a: OUTPUT«1␤1␤1␤1␤1␤»
TimToady rakudo: ^5 ==> map: say 1 00:15
p6eval rakudo 2bac6a: OUTPUT«===SORRY!===␤Confused at line 1, near "^5 ==> map"␤»
[Coke] missed the party, being all $DAYJOBby with cold fusion and sql and jquery, oh my.
donri rakudo: class it{}; say it is so True 00:16
p6eval rakudo 2bac6a: OUTPUT«===SORRY!===␤Confused at line 1, near "say it is "␤»
felher k, so i'll stick with for ^x. :) 00:19
[Coke] whoops. I've been testnig nom branch last few days.
Can we send an email to the dev list or get a blog post or something? 00:20
should we able to just checkout master in an existing clone, or do we need to reclone? 00:23
benabik You should be able to check it out in an existing clone. 00:29
[Coke] sees lots of updates to t/spectest.data that don't actually show the error message. do we not want those anymore? 00:34
(rant: no updates to master's RSS feed in google reader) 00:40
... so, I'm confused. 00:41
github.com/rakudo/rakudo/commits/master does not look like nom.
is it just the eval robot that was updated?
PerlJam [Coke]: must be 00:46
master may actually go away.
I don't know what pm decided.
00:48 uasi joined 00:52 uasi left 01:02 donri left 01:10 drbean joined 01:12 uasi joined 01:13 uasi left 01:15 uasi joined 01:33 wolfman2000 joined 01:55 Sarten-X joined 02:00 tokuhirom left 02:01 woosley joined
pmichaud I've still been waiting to hear from jnthn++. But I may simply make a decision for him. 02:01
s/for/without/
02:14 jevin left 02:15 jevin joined 02:26 cexsum left 03:00 Tedd1 left
lue Hm. "master" suggests to me "mainstream --- use this if you're not a hardcore rakudo dev", but I wouldn't mind too much if it disappeared (no more "hey, it's not nom anymore, it's master!!") 03:07
03:26 DarthGandalf joined
pmichaud yeah, I'm inclined to not have a master, at least for a while. 03:26
03:27 Su-Shee left
lue "There's no such thing as 'mainstream' right now, at least not until we're Perl 6" 03:28
03:28 Su-Shee joined 03:32 zappepcs_ joined 03:33 odoacre joined
lue
.oO(would current master become "beta" or "ng" (or some other -Ofun name?))
03:34
benabik b: say 'hello' 03:35
p6eval b a55346: OUTPUT«hello␤»
sorear good * #perl6
lue: no "beta".
lue: beta is -Ono-fun
lue: because people are conditioned to think beta = leading-edge
lue ah, yes, forgot about that. 03:37
sorear phenny: tell mberends Separate solutions for separate problems. 03:39
phenny sorear: I'll pass that on when mberends is around.
sorear phenny: tell masak Str per se is immutable but there's... something... between Str and Cursor that is mutable. See also <cut>. 03:43
phenny sorear: I'll pass that on when masak is around.
03:44 zappepcs_ left, zappepcs_ joined
sorear seen colomon 03:45
aloha colomon was last seen in #perl6 8 hours 23 mins ago saying "\o".
sorear o/ colomon 03:46
03:46 zappepcs_ left 03:47 zappepcs_ joined 03:55 kfo_ left 03:56 ZaphrodZenovka left, kfo joined 04:00 abercrombie left 04:01 ZapZ joined 04:03 ZapZ left 04:15 wolfman2000 left 04:16 satyavvd joined 04:20 Trashlord left 04:22 Trashlord joined 04:53 am0c left 05:04 sftp_ left 05:06 am0c joined 05:09 dhaivat joined
dhaivat When's Perl6 gonna be done? I'm sick of using PHP for work. 05:10
05:10 molaf left
moritz good morning 05:24
dhaivat: when is Perl 5 gonna be done? or C++? or Java? 05:25
05:25 mberends joined
sorear morning moritz 05:25
mberends morning moritz and hi, pre-thanks sorear 05:26
phenny mberends: 03:39Z <sorear> tell mberends Separate solutions for separate problems.
mberends sorear: did yesterday's discussion leave you with something to work with, or a bikeshed color scheme? 05:27
sorear yes 05:32
mberends :) 05:33
plobsing moritz: they just formally approved a new version of the fortran standard last year. apparently it can take over 50 years for a language to be "done". 05:34
moritz
.oO( lisp )
05:35
TimToady we're not really interested in "done", so much as "competitive" 05:36
plobsing lisp is not a language. it is a philosophy.
lue "done" implies there's a fixed, concrete end-goal. From where I stand, there isn't one. 05:38
mberends "practical" is what I want 05:39
in my view we will have succeeded when Ubuntu includes some Perl 6 based GUI apps in the place of the current Python based ones. 05:53
05:54 araujo left
lue in my view we'll have succeeded when emerge uses P6 instead of python+bash :) 05:56
benabik We'll have succeeded when people spent time talking about how they use P6 instead of talking about when we'll have succeeded. 06:08
dhaivat lue: what's emerge? 06:09
sorear lue: Ada is done.
lue it's the package manager for gentoo, a linux distro.
sorear although they might be designing a successor, I dunno
06:16 koban` joined 06:17 koban` left
sorear dhaivat: The point is that your question is ill-defined because "done" is ill-defined. 06:17
dhaivat: If you ask a well-defined question about a definable concept like speed, memory usage, library support, etc, we can try to make forecasts. 06:18
of course this is a volunteer project. we don't have HR or employment contracts, and the amount of work being done on Perl 6 fluctuates wildly from month to month, which means any forecasts will be of only approximate utility 06:19
06:21 mberends left 06:22 ralfradio left 06:24 mberends joined 06:25 wayland76 joined 06:27 Tedd1 joined 06:35 ralfradio joined 06:36 wayland joined, wayland76 left 07:02 cognominal___ left, cognominal___ joined 07:05 jevin left 07:07 birdwindupbird joined 07:08 jevin joined 07:09 dark_x joined 07:11 araujo joined, agentzh joined 07:18 ralfradio left 07:27 mj41 joined 07:29 rhr left 07:38 wamba joined 07:42 saaki joined 07:46 wamba left
bbkr mberends: FYI Lion 10.7.1 upgrade installed. No detailed changelog from Apple is available except "we fixed many, many things, worship us now". 07:49
07:55 daxim joined 07:56 rhr joined
moritz rakudo: augment class IO::Socket::INET { method foo() { } } 08:00
p6eval rakudo 2bac6a: OUTPUT«===SORRY!===␤augment not allowed without 'use MONKEY_TYPING' at line 1, near "{ method f"␤»
moritz rakudo: use MONKEY_TYPING; augment class IO::Socket::INET { method foo() { } }
p6eval rakudo 2bac6a: ( no output )
mberends bbkr: thanks! Some installation suggestions - mono (for Niecza), valgrind, JSON.pm. Also you may like some mberends/.profile bits stolen from Debian :) 08:04
bbkr mberends: which JSON.pm - from P5? 08:10
mberends yes, so it varies per installed p5 version I suppose
bbkr installation started: p5-json p5-json-xs mono mono-basic valgrind. JSON is common for all P5 versions. I'm not sure if you need also valgrind-devel 08:14
mberends 'git pull' has also slowed down again from bbrk.org - is this another ssh problem? It works, but the delay is about 35 seconds. 08:15
valgrind-devel is probably only for devs who are changing valgrind. I think valgrind does use libc-devel on Debian. 08:17
Debian valgrind depends on libc6-dbg 08:20
bbkr Yes, I know about git slowdowns. I'll try to figure out what is causing it. 08:21
mberends it's only a minor matter 08:22
08:27 bbkr left
mls morning perl6! 08:27
phenny mls: 01 Sep 16:52Z <pmichaud> tell mls would you be able to do the same sort of callgraph analysis for compilation of Rakudo ng's setting?
mls: 01 Sep 16:53Z <pmichaud> tell mls it would be really useful to be able to compare the differences between ng and master
mls ok, generating... 08:28
08:49 ab5tract joined 08:50 wayland left
flussence lue: it's funny you should mention portage... one of their GSoC projects was a libbash to make it easier to write a package manager in other languages. turns out it's also a million times faster than calling the shell too. 08:50
08:51 wayland_ joined
tadzik hello #perl6 08:52
moritz o/ 08:53
09:10 woosley left, orafu left, orafu joined
mls phenny, tell pmichaud www4.informatik.uni-erlangen.de/~ml..._ng.out.gz 09:17
phenny mls: I'll pass that on when pmichaud is around.
09:28 pernatiy left 09:31 fhelmberger left 09:35 Mowah_ joined 09:37 fhelmberger joined
mls wow, the number of calls to as_post has grown quite a bit 09:43
tadzik flussence: ping
moritz I wonder if that's related to how we store literals 09:45
tadzik flussence: I guess we've come to the conclusion that Pod AST is not neceserilly HTML-friendly (see Lists in Pod). I thought about Markdown parsing today, and wondered if we want some sort of unified AST for Documents generally. Then we can write a Pod -> DocAST compiler and generate HTML easily from whatever we can compile to DocAST. So that'd work for Markdown as well, and whatever we want 09:48
mberends tadzik: +1 good thinking 09:52
daxim compare with the parsing work done by rjbs on pod and autarch on markdown resulting in events 09:56
sometimes, an ast is inconvenient
tadzik I think having a HTML emmiter for every possible format on earth is inconvenient 09:57
mls moritz: could be the PAST::Want nodes
unfortunately the pir seems to have no annotations, so kcachegrind doesn't show the file/line 09:58
(the compiler should auto-generate annotations for subs that don't have any...) 10:00
moritz speaking of annotations... somehow in nom all reported files seem to be the current script, never modules
tadzik oh, speaking of which. We're not really into installing .pirs anymore, are we? 10:01
10:02 nebuchadnezzar left
mls (manually intserting .annotate statements...) 10:02
moritz tadzik: you mean we should be installing .pbcs instead? 10:03
tadzik moritz: I don't know, but we don't install e.g. Test.pir, do we?
I think there's a reason for that 10:05
also, IoC doesn't work when installed with pirs
gist.github.com/1188309 10:06
10:08 espadrine joined, uasi left 10:10 am0c left 10:11 wamba joined, nebuchadnezzar joined
flussence tadzik: maybe we should just have a docbookxml emitter, and let that figure out how to convert to other formats :) 10:15
10:16 MayDaniel joined 10:29 Trashlord left
bbkr_ mberends: do you want mono LTS 2.6.7 or latest stable 2.10.5? 10:37
10:38 daxim left 10:39 daxim joined
tadzik flussence: if it's good enough? I mean, I don't know, never used it. And I'm much more towards the AST than a stringy format 10:40
10:40 MayDaniel left
tadzik maybe a sensemaking docbookxml emmiter is the first step 10:40
10:43 uasi joined
bbkr_ mberends: and bad news - valgrind is not yet released for Lion 10:44
10:45 uasi left, uasi joined 10:49 uasi left
mberends bbkr_: mono latest stable please :) 2.6.7 has the old Boehm GC whilst 2.10.x has generational. sorear++ mostly uses latest mono 10:50
bbkr_ mberends: no problem. i see 2 packages - MRE and MDK. do you need both? 10:52
mberends bbkr_: I think MDK is to develop mono itself, if so then not required 10:53
bbkr_: the Mono C# compiler might be in a separate 'mcs' package 10:54
espadrine mberends: Do you know whether Boehm is still actively developed btw? 10:56
/me wonders if they think about implementing more advanced features in it.
10:57 lateau_ joined
mberends espadrine: I think the Boehm main code is very mature and stable, but other people are producing experimental derivatives from it for SMP, NUMA etc. 10:58
10:59 flussence_ joined 11:01 flussence left
mberends espadrine: Hans Boehm is quite active with other memory management projects nowadays. www.hpl.hp.com/personal/Hans_Boehm/gc/ 11:03
mls does pbc_merge really strip the annotations?
11:04 thelazydeveloper joined 11:05 Trashlord joined 11:08 aduitsis joined
bbkr_ mberends: please check if mono MRE is installed correctly. 2.10.5 version, mcs is present, i'm not sure if anything else is required 11:11
mberends bbkr_: starting Niezca build... 11:13
11:13 thelazydeveloper left 11:17 woosley joined
mberends bbkr_: Niecza built ok and passed all tests :) 11:18
bbkr_ \o/
11:21 agentzh left 11:31 fhelmberger left 11:32 fhelmberger joined, flussence_ is now known as flussence 11:34 daniel-s left 11:35 mtk left
pmichaud good morning, #perl6 11:48
phenny pmichaud: 09:17Z <mls> tell pmichaud www4.informatik.uni-erlangen.de/~ml..._ng.out.gz
mberends \o pmichaud 11:49
11:49 cognominal joined 11:51 cognominal___ left
flussence uh oh, my graph data contains negative values... 11:52
11:53 JimmyZ joined, satyavvd left
mberends pmichaud: moving pir::time__N calls around in lib/Test.pm works, and produces timings between 5% and 95% lower than the currently committed version, but clutters Test.pm with timing code. Some may find this undesirable, justifying it depends on how much we want the feature. 11:54
some tests execute in 16 microseconds on the OS X server :) 11:55
tadzik wow, Rakudo is fast! :P
flussence I've been computing fails from ($plan - $pass - $skip - $todo)... looks like that's wrong. github.com/flussence/specgraphs/co...a16#diff-0
(maybe I should just omit them altogether and consider any test not accounted for a fail) 11:56
pmichaud seems to me that fails should be counted directly 11:57
not computed
11:58 ab5tract left
flussence I'm doing it using TAP::Parser::Aggregator - didn't see an option to account for fails in the .pod, maybe I just missed it... 11:59
pmichaud mls: ping
12:10 mtk joined 12:30 MayDaniel joined 12:40 wamba left 12:41 daniel-s joined 12:48 donri joined 12:52 wamba joined 12:53 mtk left 12:57 bluescreen10 joined 13:06 mtk joined
pmichaud mberends: could I get a diff of your Test.pm with the additional pir::time__N calls, so I can see how cluttered it is? 13:07
mberends ok
pmichaud gotta run a few errands -- bbiaw 13:10
(mberends: I don't need the diff immediately -- just whenever you get a chance) 13:11
mberends about to paste it anyway, but no hurry here
pastebin.com/tDqSx0gZ 13:12
13:19 daxim left 13:29 apejens left 13:30 wayland_ left 13:31 apejens joined 13:32 im2ee joined
im2ee Hello perl's world! :) 13:34
mls pmichaud: hi!
mberends pmichaud: if the pir::time__N clutter is unwelcome I can work around it by making tools/test_summary.pl switch in its own Test.pm instead of the standard one in lib/, perhaps even by simply tweaking PERL6_LIB. There would be a bit of maintenance skew, but nothing serious. 13:37
13:46 woosley left 13:47 Mowah_ left
tadzik hello im2ee 13:47
[Coke] learns how to say "I don't know" in chinese. 13:48
JimmyZ [Coke]: ;) 13:49
tadzik now as you long as you act as a very dumb person, you can perfectly resemble a native chinese speaker :) 13:50
13:50 aduitsis left 13:51 Holy_Cow joined, Holy_Cow left 13:52 aduitsis joined
JimmyZ there are hundreds of dialects in china, but I can only say two of them 13:55
13:55 aduitsis left
JimmyZ s/say/say && understand/ 13:55
mberends pmichaud: either way I plan to add some reporting to tools/test_summary.pl in a --view option. Current thoughts are a menu, sort by test time, speedup/slowdown since earlier test or % change, view in 'less'. 13:57
13:58 Alias left 13:59 odoacre left 14:02 risou_awy is now known as risou 14:05 jaldhar left 14:15 molaf joined 14:16 mkramer left 14:35 woosley joined 14:37 sftp joined 14:49 ggoebel joined 14:53 DerHartmut joined
DerHartmut Hi together 14:53
moritz hello
14:55 birdwindupbird left 15:11 scorpil joined 15:17 woosley left 15:35 scorpil left 15:36 im2ee left 15:37 im2ee joined 16:04 Aridai joined, scorpil joined 16:10 Aridai left 16:13 dark_x left 16:24 dhaivat left 16:25 mj41 left 16:28 im2ee left 16:29 im2ee joined, dark_x joined 16:32 colomon left, JimmyZ left 16:55 envi left
mls pmichaud: the as_post calls showing up highest in the profile are just PAST::Block, PAST::Stmts, PAST::Stmt. Nothing suspicious. 16:56
16:57 DerHartmut left, scorpil left
im2ee <.space> in tokens is the same what \s in p5? :) 17:02
PerlJam im2ee: yes 17:04
im2ee PerlJam, thanks :)
PerlJam well, <.space> is the same as \s in Perl 6. Perl 6's \s differes slightly from Perl 5's \s 17:05
17:05 uasi joined
im2ee Ok. :) 17:05
17:18 uasi left 17:22 lucs joined 17:26 mj41 joined
pmichaud back again 17:33
It's not the as_post calls that concern me so much (although if we have a lot more as_post for PAST::Block|Stmts|Stmt than for the others, *that* would be odd) 17:36
apparently we create 3x as many PCT::Node objects in nom as we do in ng
and that's probably why the past->post stage of compilation is taking so much longer
in ng, we end up creating 465,609 PCT::Node objects (calls to 'new'). in nom, that number is 1,198,256 17:37
mls Yes, that's also what the profiles say. There are twice as many objects created for nom, thus it takes twice as long. 17:39
(probably not twice, but 3x many object. It takes twice as long because the parsing time stays constant) 17:40
pmichaud I'd like to be able to get profiles for ng and nom where we compile the setting using --target=past instead of --target=pir 17:41
that would remove the creation of POST nodes out of the profile
but _really_ I'd like to be able to generate these profiles myself :) 17:42
moritz mls: could you share your parrot patches?
mls Sure, I'll upload the (ugly) patch...
17:42 buubot_backup left
pmichaud mls: how does your way of creating the profiles differ from Parrot's profiling runcore option, other than it seems to work in places where the profiling runcore doesn't and is apparently a ton faster? 17:43
mls It's not that different. I looked at the parrot profile code, but it seems to print a line for every op instead of incrementing counters.
(And I also use the TSC instead of doing a syscall. Highly unportable, but fast) 17:44
(That's for counting cycles, op counting is portable, of course) 17:45
pmichaud I think it would be very valuable to get your code in as a runcore option
even if it's only available for certain platforms to begin with 17:46
mls Yes, it shouldn't be that hard to integrate. It'll only report ops for platforms with no TSC.
pmichaud what do the numbers under "Incl." and "Self" represent?
tadzik TSC?
pmichaud oh, it's "ops" and "cycles" 17:47
cooool
what are "cycles"?
mls en.wikipedia.org/wiki/Time_Stamp_Counter
pmichaud hmmmmm 17:48
moritz what you get from (mutual) recursion, I thikn
pmichaud I think there must be something wrong, then.
mls what's wrong?
pmichaud should that be "ops" and "ticks" instead of "ops" and "cycles"?
(to avoid the pun with "cycles" as used in callgraph cycle detection?) 17:49
mls Yes, ticks is probably the better name.
pmichaud okay, I'll use "ticks" here.
The profile seems to indicate that the lineof function is responsible for the greatest number of ticks
mls ops
sorear good * #perl6 17:50
mls Hi sorear!
pmichaud when I switch to displaying ticks instead of ops, lineof jumps way to the top 17:51
(in the ng profile)
mls In my kcachegrind it's the other way round.
Oh, ng.
looking...
Yes, it's number one both for ops and ticks 17:52
cotto_work mls: where's your patch?
pmichaud currently lineof is implemented using a linear search, which is O(n**2). I switched it to be a binary search so that it's O(n*log(n)) but saw hardly _any_ impact on overall performance.
mls working on it...
Yes, that's to be expected
pmichaud and I put in some other tracing code into lineof to find out why it's taking a long time there.... and it still didn't seem to be a source of slowdown 17:53
so I'm curious why it appears so high in the profile
mls lineof isn't slow
You should look at 'Incl.'
(Speaking of lineof, I've also optimized it a bit. I store the position of the last match, because the lineof queries seem to be done in ascending order most of the time 17:54
PerlJam Are you guys still looking at the same kcachegrind file that mls posted yesterday?
pmichaud yeah, I thought about doing that approach also.
PerlJam: yes, and a new one posted this morning for ng that I'm using as comparison. 17:55
17:55 mberends left
mls you can do that on top of the binary search 17:55
pmichaud I'll apply my binary search patch so we can get that artificial slowdown out of the profiles.
mls But lineof is not the responsible for the slowness. I once patched it to just return 0, and the compilation was just a couple of seconds faster 17:56
(back to patch creation...)
pmichaud right, so I'm wondering why it shows up high on the ticks count 17:57
according to the profile, it's 25% of the ticks
mls Just for "Self"
pmichaud no, in Incl
(looking at ng here)
mls Checking...
pmichaud main has 296,492,734,685 Incl. ticks. lineof has 55,251,168,511 Incl. ticks 17:58
oh, sorry, 16% of the ticks. Still.
(mental calculation error)
mls ticks have to be taken with a grain of salt 17:59
(not the animal ;) )
cause other processes interfere with the measurement
pmichaud like gc?
mls it's like gettimeofday() etc.
Yes, gc as well. 18:00
18:00 donri left
pmichaud yeah, so it looks like we can't really use ticks as a good measure of where things are slow. 18:00
mls Well, it's better than nothing
pmichaud sure, but it also means it can lead us down false optimization paths 18:01
PerlJam It's too bad you can't get actual timings.
(except on a gross scale)
pmichaud PerlJam: yeah, this is one of those areas where I've been disappointed with parrot profiling. figuring out where things are slow is really hard. 18:02
18:02 frettled left
pmichaud not that profiling is easy, mind you :) 18:02
18:02 frettled joined
TimToady let's add threading and make it even harder! :) 18:02
pmichaud makes a little noose out of threads for TimToady++ 18:03
mls If the parrot run takes a long time, chances are that influences like gc will not matter much
PerlJam TimToady: it gets easier if you first project into 10 dimensions and then back out again.
pmichaud but I wonder why lineof gets such a disproportionate amount of the cost 18:04
mls if gc always hits the same function, it's probably the function's fault
PerlJam mls: you have some statistical evidence to back up that claim? :)
mls ;)
Did you do your lineof optimization in ng?
pmichaud actually, if gc is a function of number of ops executed, then lineof gets hit more often simply because it's executing so many ops (even though those ops are fast)
the lineof optimization goes in Parrot 18:05
mls gc gets triggered by PMC allocation
tadzik pardon me, what's lineof()?
pmichaud well, that can't be it then. when lineof is called, it's not allocating PMCs
mls (gc = parrot's garbage collection, right?)
tadzik mls: right
pmichaud yes, gc == parrot's garbage collection
mls yes, so it's not a gc issue.
18:06 mkramer joined
pmichaud lineof() is the function in HLLCompiler that calculates line numbers for source 18:06
18:06 buubot_backup joined
pmichaud i.e., given a string of source code and a position offset, determine the line number of the offset 18:06
tadzik whoa
mls I can re-run the ng profiling to see if anything changes
but first, i'll upload the patch...
tadzik do we need that for anything besides annotations? 18:07
pmichaud tadzik: error messages, but those are rare
at least, they're rare when compiling the setting
tadzik aye
TimToady tadzik: the main reason for lineof() is actually reliability
pmichaud and I'm fairly certain that lineof itself isn't eating up 16% of compilation time
TimToady it's very, very difficult to enforce line number counting in a parser
tadzik I thought that's it, but I didn't think that'd be so expensive in action
pmichaud tadzik: right, which is why I think it's a profiler artifact and not reality 18:08
tadzik may be
TimToady but we can always be pretty sure of the current parser position
pmichaud and I'm trying to figure out the source of the artifact
TimToady I don't suppose there's anything in the profiling code that calls lineof() surreptitiously?
pmichaud doesn't seem likely. 18:09
the profiler is in C, while lineof() is PIR.
and lineof() is strictly compile-time.
that's a good thought, though, so I'll explore it a bit. 18:10
PerlJam I bet someone could build a chart of the necessary timing information for each parrot op and then marry that with mls' data to figure out where the real slow-down is.
It would take a bit of work to do it by hand though
pmichaud PerlJam: I think it's not so simple. 18:11
PerlJam: remember that parrot ops sometimes call into PIR.
so "timing information for each parrot op" gets convoluted really quick.
PerlJam well, how about "timing for each parrot-level sub" instead? 18:12
cotto_work Yeah. Dealing with nested runloops took a lot of thought.
pmichaud "timing for each parrot-level sub" is also somewhat convoluted. See gc.
If GC occurs in the middle of a sub, do we charge the sub with the cost of GC?
PerlJam pmichaud: it would have to be stastical
with large error bars I guess
pmichaud what might be really helpful is if the profiler could treat GC as a separate subcall 18:13
so then if, for example, GC is occurring within lineof, it shows lineof as a caller and charges the expense of the GC to the phantom GC sub instead of lineof itself
(the Incl. total would still include the cost of the GC, but we'd be able to separate the GC cost from the "actual work" cost) 18:14
PerlJam I haven't seen mls' patch, but it sounds like he could intercept GC calls and do something special. 18:15
pmichaud maybe. I suspect the profiling patch works at the level of intercepting things at the level of op dispatch. GC takes place in another area, iiuc. 18:16
mls yes 18:17
18:17 plobsing left 18:18 mberends joined 18:19 plobsing joined, kaare_ joined
PerlJam isn't there an op to force a GC run? 18:19
Couldn't you call it periodically so that GC runs are more predictable?
cotto_work collect iirc
mls diff: www4.informatik.uni-erlangen.de/~ml...ofile.diff 18:21
pmichaud we probably could, yes. but based on what mls++ said above, I doubt that gc is occurring during lineof
mls Use: parrot -R slow will dump the valgrind data to stderr
not very confty, but it works for now 18:22
PerlJam I wonder how much the GC system knows about the state of parrot when it's called? Maybe the GC system itself could be instrumented for profiling such that the results could be subtracted from the cachegrind stuff
cotto_work mls: do you mind if I start a branch on parrot.git with that?
mls no, go ahead
the patch is now in public domain ;) 18:23
pmichaud cotto_work++ cotto_work++ a branch with that is exactly what we need
plobsing mls: why do you manually handle the annotations and then call PackFile_Annotations_lookup? 18:24
pmichaud just a sec, I'm about to commit my binary search patch
mls see the discussion on #parrot
plobsing mls when?
cotto_work mls: what's the difference between this profiler and the one in parrot now? 18:25
plobsing oic, it handles the sub lines. sorry
18:25 rlb3 joined
mls Didn't you suggest the null annotations? 18:25
cotto_work is it just sub-level?
plobsing yes. I didn't put 2 and 2 together 18:26
pmichaud binary search patch pushed. 18:27
mls (for reference: that was my lineof patch: gist.github.com/1189409) 18:30
pmichaud I think we can get a bit better if we simply cache lastline and not lastpos 18:32
and compare linepos[lastline] against pos
18:33 rlb3 left
pmichaud if linepos[lastline] < pos, then we start from lastline. 18:33
mls You need to check that lastline is in bounds first
pmichaud in bounds?
mls lastline < elems(linepos) 18:34
pmichaud it has to be, if we're caching
well, I suppose it could be elems(linepos) exactly
mls yes 18:35
pmichaud which would be "out of bounds". but that's still a pretty easy check.
it gives us a better start position for 'line' (or 'lo' in the binary search)
cotto_work mls: I'll push as soon as I've verified a clean(ish) build. Thanks!
mls I hope it works also on 64bit builds, I've just tested 32bits 18:36
cotto_work mls: I'd appreciate it if you'd send a quick note to parrot-dev about what it does.
I believe pmichaud can answer that question. ;)
and pushed 18:37
pmichaud well, I'm waiting for the branch to arrive :)
because then it's easy to do in nom
just --gen-parrot=branchname
18:38 ab5tract joined
mls I think I stored lastpos so that lookups between lastpos and linepos[lastline] also are fast 18:38
i.e. if you lookup the same value twice, the second lookup is fast 18:39
pmichaud I suspect "look up the same value twice" almost never happens, though.
18:39 lateau_ left
pmichaud well, it might happen, now that I think about it. 18:39
mls well, you can just subtrace one from lastline 18:40
then you also don't run into problems with elems(linepos)
pmichaud might run into problems on line 0, though.
so still need the check.
mls ;) yes, but that's a simple == 0 check
pmichaud well, checking against elems() isn't hard either, since we have to get that value anyway 18:41
18:41 donri joined
pmichaud I'll add a 'lastline' patch here shortly 18:41
mls subtracting one will help the "lookup same value" case 18:42
but implement it any way you like ;)
18:43 MayDaniel left 19:05 mkramer left 19:06 mkramer joined 19:12 jevin left 19:13 jevin joined
mls cotto_work: mail sent. 19:18
ok, weekend ;) 19:21
lue hello Camelialand o/ 19:28
tadzik o/ 19:32
sorear hello
19:33 mj41 left
TimToady nom: my @x; @x[0][0] = 42; 19:33
rakudo: my @x; @x[0][0] = 42;
p6eval rakudo 2bac6a: OUTPUT«Cannot assign to a non-container␤ in <anon> at /tmp/Dcv4MRlqCV:1␤ in <anon> at /tmp/Dcv4MRlqCV:1␤␤»
TimToady is there an eta on autoviv in nom?
PerlJam TimToady: when it's ready. ;) 19:34