»ö« 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«11111» | ||
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 | |
TimToady | is there an etr then? | ||
19:36
birdwindupbird joined
|
|||
diakopter | niecza: my @x; @x[0][0] = 42; # i wonder | 19:37 | |
p6eval | niecza v9-8-gd3b0031: ( no output ) | ||
PerlJam | TimToady: I have vague recollections that autoviv would be fixed within a few weeks but only jnthn/pmichaud would really know. | 19:39 | |
(the vague recollection is tied to jnthn in my head) | |||
19:42
wayland76 joined
|
|||
pmichaud | actually, I'm the autoviv guy, I think. | 19:50 | |
I can fix it tonight, np. | |||
19:52
mkramer left
19:54
cexsum joined,
lucs is now known as lurcs
19:56
lurcs is now known as lucs
19:57
saaki left
|
|||
pmichaud | mls / cotto_work: the profiler seems to work fine on my 64-bit box. mls++ cotto_work++ | 19:57 | |
mberends | \o/ | 19:58 | |
pmichaud | the sub-profiler branch is behind master by about 58 commits, though. | ||
github.com/parrot/parrot/branches/...b-profiler | |||
afk, lunch | |||
lue | is nom still in the nom branch ? | 20:00 | |
sorear | afaik yes | 20:05 | |
20:07
saaki joined
20:15
bluescreen10 left
20:16
molaf left
20:18
ab5tract left
|
|||
cotto_work | pmichaud: thanks for noticing. I thought I pulled before branching. looks like an easy merge. | 20:18 | |
20:19
birdwindupbird left
20:29
bluescreen10 joined
20:37
kaare_ left
|
|||
sorear | I've finished reading the C# overloading resolution spec, and I kindof like it better than Perl 6's current multimethod resolution | 20:46 | |
it's certainly a simpler definition | |||
20:49
PacoLinux_ joined
20:51
wolfman2000 joined
|
|||
moritz | sorear: is it symmetric in the arguments? | 20:51 | |
20:52
itz joined
|
|||
sorear | moritz: yes | 20:54 | |
both the C# and Perl6 models start with a poset of possible functions | 20:55 | ||
C#: Pick the unique greatest element, or error. | |||
moritz | isn't that what Perl 6 does too? :-) | 20:56 | |
I mean, for some definition of "greatest element", that already takes "is default" into account | |||
sorear | Perl6: Assign the elements of the poset into a list of buckets using a specific greedy topological sort, such that every element is put into the least bucket consistent with the partial order. Then find the first bucket which contains a usable candidate, or error if there are more than one in the same bucket | 20:57 | |
moritz: no | |||
the Perl6/Rakudo algorithm seems like it's trying to implement that, but it doesn't really | |||
moritz | how is that "greatest element" defined in C#? | 20:58 | |
20:58
mtk left
|
|||
flussence | .oO( maybe we should just copy the css selector specificity algorithm ) |
20:58 | |
sorear | candidate which is better than all other valid candidates | 20:59 | |
let me try and find a specific example of a case where they differ | |||
21:00
PacoLinux_ left
|
|||
mberends | sorear: does this document whhat you're describing? msdn.microsoft.com/en-us/library/aa...71%29.aspx | 21:00 | |
sorear | mberends: It appears to be equivalent | 21:01 | |
mberends: except too short | |||
I'm reading §14.4.2 of ISO/IEC 23270:2006(E) | 21:03 | ||
21:04
colomon joined
|
|||
sorear | which is identical to the section of the same number in Ecma-334 | 21:04 | |
about 4 pages | |||
moritz | so they count number of subclasses, right? | ||
sorear | moritz: ...number of subclasses? | 21:05 | |
moritz | erm, depth of inheritance hierarchies | ||
sorear | mberends: ah, yes, if you count subsections it's the same | ||
moritz: yes | |||
moritz | is that like manhattan sort? | ||
moritz -> sleep | 21:06 | ||
sorear | I cannot find any references to a concept called "Manhattan sort" on google | ||
21:11
cognominal left
|
|||
mberends | I guess it relates to "manhattan distance" in "Taxicab geometry" en.wikipedia.org/wiki/Manhattan_distance | 21:12 | |
im2ee | Have a nice day/night. Bye! :) | 21:14 | |
mberends | o/ im2ee | ||
im2ee | \o :) | 21:15 | |
21:15
im2ee left,
cognominal joined
21:17
wooden joined
|
|||
mberends | "manhattan distance" is a kind of hop count if the blocks are equal sized, so you could sort by that. I'm not sure whether such a distance applies to the number of arguments that need implicit conversion. | 21:19 | |
cotto_work | iirc the calculation done by Parrot takes conversions into account | ||
21:20
colomon left
|
|||
sorear | they don't *count* anything. | 21:21 | |
it's a purely relational analysis. | |||
mberends | true, jnthn++ calls it "topological sort" in one of his talks | 21:23 | |
TimToady | p6 used to use manhattan distance, but it was rejected as to much bad dwimmery | 21:24 | |
*too much | |||
jnthn back from $trip | 21:26 | ||
Exhausted, but that's nothing sleep won't fix :) | |||
mberends | o/ | ||
pmichaud | jnthn: o/ | ||
jnthn | (And yes, that was the last trip for a while. I can actually get back to doing stuff again...like, writing code. :-)) | 21:27 | |
o/ pmichaud | |||
pmichaud | jnthn: I have a quick (and should be easy-ish) question for you, if you're awake enough for it :) | ||
jnthn | pmichaud: I feel surprisingly awake, which may or may not be a good sign. ;-) | ||
tadzik | lolitsjnthn! | 21:28 | |
pmichaud | we're going to move master->ng, but considering leaving 'nom' branch as 'nom' (and not having a 'master' branch at all) | ||
jnthn | That feels like it'll surprise too many people. | ||
pmichaud | we'll set git so that a repo clone defaults to 'nom' | ||
jnthn | I still think it'll surprise too many people. | ||
What's the motivation? | |||
I know "master" is just a convention. | |||
But...people get used to conventions. | 21:29 | ||
pmichaud | well, for one it means we don't have confusion regarding 'master' | ||
it also means we don't have to tell folks to re-clone their repos | |||
jnthn | Will folks get a relatively decent message telling them they need to do that? | 21:30 | |
sorear | rakudo: role A {}; role B does A {}; role C {}; class X does A does C {}; multi f(A) { "A" }; multi f(C) { "C" }; say f(X) | ||
p6eval | rakudo 2bac6a: OUTPUT«Ambiguous dispatch to multi 'f'. Ambiguous candidates had signatures::(A):(C) in sub f at /tmp/KWmDLA9A9S:1 in <anon> at /tmp/KWmDLA9A9S:1 in <anon> at /tmp/KWmDLA9A9S:1» | ||
pmichaud | I've drafted two messages, depending on which way we go | ||
sorear | rakudo: role A {}; role B does A {}; role C {}; class X does A does C {}; multi f(A) { "A" }; multi f(B) { "B" }; multi f(C) { "C" }; say f(X) | ||
p6eval | rakudo 2bac6a: OUTPUT«C» | ||
sorear | I hope at least one person in #perl6 agrees that this is wrong. | ||
pmichaud | pmichaud.com/sandbox/nom2.txt # assuming we keep 'nom' as 'nom' | ||
oops | |||
pmichaud.com/sandbox/nom-2.txt # assuming we keep 'nom' as 'nom' | |||
sorear | adding a candidate which cannot be used changes the ambiguous overloading detection | 21:31 | |
pmichaud | pmichaud.com/sandbox/nom.txt # assuming we rename 'nom' as 'master' | ||
sorear | with C#'s rules, which are similar enough that they could be trivially adopted, this problem does not exist. | ||
jnthn | sorear: The ambiguity for the first one looks correct. Looking at the second one... | 21:32 | |
pmichaud | discussion of the branch rename: irclog.perlgeek.de/perl6/2011-08-31#i_4352409 | ||
sorear | jnthn: C# rules will treat both of them as ambiguous. | ||
jnthn: they are also much simpler to specify. | |||
jnthn | sorear: I dont' realy see how that's relevant. | 21:33 | |
sorear | jnthn: how what is relevant? | ||
jnthn | What C# does. | ||
sorear: Have you tried asking nom? | |||
TimToady | simpler is potentially relevant :) | ||
sorear | jnthn: because I'm going to change the perl 6 spec to follow the C# spec. it's simply better. | ||
jnthn | sorear: No, you're not. | ||
sorear | right, I have to fight you first. | 21:34 | |
jnthn | Again, did you check what nom thinks? | ||
sorear | nom: role A {}; role B does A {}; role C {}; class X does A does C {}; multi f(A) { "A" }; multi f(B) { "B" }; multi f(C) { "C" }; say f(X) | ||
pmichaud | note that "rakudo:" in p6eval is now nom. | ||
jnthn | ah | ||
jnthn looks a little more | |||
pmichaud | and there is no "nom:" target (but there needs to be) | ||
jnthn | sorear: oh, I see what's going on. | 21:35 | |
I think. I need to draw out the DAG normally to really be sure. | |||
Anyway, in the second example, B and C end up tied, with A narrower. | |||
Note that the candidate ordering is *static*. | 21:36 | ||
I don't know whether the C# one is. | |||
(Yes, it is in so far as it decides everything at compile time. But that's orthogonal to whether the list is statically sortable.) | |||
So arguments along the lines of "the one with B could never be called" aren't really relevant. At sort time - which is once ever - it is relevant. | 21:37 | ||
21:38
wolfman2000 left
|
|||
jnthn | I'd also be extremely reluctant to change semantics that so far have suited many real world cases, when I'm looking at an example here that seems relatively contrived. | 21:38 | |
pmichaud: Checking the release announces. | |||
pmichaud | jnthn: note that if we leave 'nom' as 'nom' and discover that people are really confused by it, we can still do 'nom'->'master' later (with no additional work) | 21:39 | |
jnthn | pmichaud: I'm having trouble saying exactly why, but something makes me uncomfy about not having a "master" | ||
pmichaud | jnthn: does it help to know that p5 doesn't have a 'master' ? | ||
jnthn | pmichaud: Well, but then we'd be deferring the re-clone. | ||
pmichaud | I mean "no additional work" relative to making that decision today. | ||
jnthn | pmichaud: Well, it's a fact I wasn't aware of :) | 21:40 | |
Ah, in that case you're correct. | |||
pmichaud: When do we need to decide by? | 21:41 | ||
pmichaud | sooner is better -- I'd like to get some sort of announcement out, well, yesterday. | 21:42 | |
jnthn | pmichaud: I know masak++ had some discomfort about the "no master" issue, and he may have actual reasoned arguments rather than my knee-jerk discomfort. :) | ||
pmichaud | when I asked masak++ about it, it was primarily the "most people expect a 'master'" argument | ||
I'm not sure who 'most people' will be in this case, though. | 21:43 | ||
also, I suspect that when projects grow to a certain size, the argument for having 'master' as default might break down. | |||
although it definitely depends on workflow | |||
also, I'm highly persuaded by TimToady++'s strong opposition to a rename. | 21:44 | ||
jnthn | Ah, OK, you already discussed with with masak. | 21:45 | |
pmichaud | well, only briefly. I had some followup questions there too but we've been missing each other on #perl6 | ||
jnthn | Got a link to TimToady++'s reasons for not wanting to do a rename? | ||
What will happen to people who have a checkout of "master" today? | |||
pmichaud | irclog.perlgeek.de/perl6/2011-08-31#i_4352409 | 21:46 | |
jnthn | Who just "git pull"? | ||
pmichaud | they'll get a note that master no longer exists | ||
which is definitely better than it trying to do a merge with a new master | |||
(a new nom-based master) | |||
at least, that's what I suspect will happen. Let me try it out. | |||
jnthn | pmichaud: I'm probably 0 on "no master", but -1 on "call it nom". Largely the "we think it's cute today" argument. :-) Yes, it is cute, but I think a name that better indicates its role as the current actively developed head may be better. "bleed" in Perl 5 does that, for example. (iiuc the Perl 5 approach, anyway...) | 21:48 | |
otoh, it is what people get by default...I can just imagine dozens of "why is it called nom?" questions needing answering int he future ;) | 21:49 | ||
sorear | -1 to giving anything a long-term name with the word "new" in it | ||
jnthn | Well, yeah. The "n" in "nom" is for "new" :) | ||
sorear | anyone remember New Executables? | ||
jnthn | Or New York? :) | ||
pmichaud | for developer names, I don't mind occasional cuteness. -Ofun and all that. | ||
21:49
molaf joined
|
|||
jnthn | (Yes, OK, it *is* newer than my York... :)) | 21:50 | |
pmichaud: Cute is nice. I like cute things. I just worry it'll be tiresome to explain style of cute. :) | |||
pmichaud | explain to _who_, exactly? | 21:51 | |
aloha | positive: nothing; negative: nothing; overall: 0. | ||
jnthn | pmichaud: People who show up here and ask "why is it called nom?" :) | ||
Maybe I overestimate the risk of that. | |||
pmichaud | Attempting to pull when master is removed gives: | 21:53 | |
TimToady | I'm not opposed to having 'master' be an alias for whatever the current "approved" version, but I just really like for major versions to have permanent names too...and "nom" feels like one of those permanent names to me | ||
pmichaud | pmichaud@kiwi:~/ren$ git pull | ||
Your configuration specifies to merge with the ref 'master' | |||
from the remote, but no such ref was fetched. | |||
TimToady | "We are now in the Nom Era." | 21:54 | |
pmichaud | afaik git doesn't have a way to alias branch names in the way we want | ||
21:54
sahadev joined
|
|||
TimToady | "That was back in the [Alpha|Ng] Era..." | 21:55 | |
sorear | nomic? nomous? | ||
and is that pronounced like "gnome"? | |||
TimToady | it's pronounce by eating heartily | ||
jnthn | :) | 21:56 | |
TimToady | and how do you pronounce "gnome" anyway? | ||
tadzik | gnołm | ||
jnthn treats the "g" as silent, fwiw. | |||
sahadev | hello all. is this how to read input by paragraphs? for $*IN.lines(nl => "\n\n") -> $para { say $para } | 21:58 | |
TimToady pronounces the "g" | |||
21:58
dark_x left
|
|||
TimToady | for the softward, not for the garden gnome :) | 21:58 | |
*ware | |||
tadzik | sahadev: looks neat, does it work? | ||
sahadev | that still reads my input by line. | ||
jnthn | TimToady: Oh, I'd always figured they should be said the same ;) | ||
TimToady also pronounces the 'k' on Knuth :) | |||
tadzik | okay then | ||
sahadev | tadzik: no. i was hoping someone here would correct my error if there was any. | 21:59 | |
jnthn | pmichaud: I think I object less to the "no master" thing that I initially did. | ||
s/that/than | |||
tadzik | sahadev: I have a feeling nl is NYI in Rakudo | ||
sahadev | oh, well. | 22:00 | |
jnthn | pmichaud: tbh, if people do "git clone" and they get the Right Thing, then that's "enough". And we have a fairly tight commit policy, and tend to take patches over fork requests, so it's not so many people we'll need to point out that "no, you don't do git push origin master" to | ||
TimToady | perl6: for $*IN.lines(nl => "\n\n") -> $para { .say; exit } | ||
lue | I personally like the idea of "no master", and if you want to avoid *new*, rename s/nom/jom (jnthn's object model) perhaps | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«Potential difficulties: $para is declared but not used at /tmp/cU5Mbc8Dww line 1:------> for $*IN.lines(nl => "\n\n") -> ⏏$para { .say; exit }Unhandled exception: Excess arguments to CORE TextReader.lines, unused named nl at /home/p… | ||
..pugs: OUTPUT«*** No such method in class Scalar: "&lines" at /tmp/xh2tOz4BNT line 1, column 5-30» | |||
..rakudo 2bac6a: OUTPUT«Any()» | |||
jnthn | lue: oh no! :P | 22:01 | |
TimToady | niecza++ is much more careful about complaining about NYI stuff than rakudo is | ||
jnthn | TimToady: For one, I didn't know nl existed. :) But also Niecza fails for the wrong reason. | 22:02 | |
TimToady | well, the first message is not a failure | ||
jnthn | TimToady: Unexpected arguments to methods should be ignored. | ||
er, *named* arguments | |||
Due to implcit *%_ | |||
Which is why Rakudo ignores it. | |||
lue | .oO(perhaps I'd like getting rid of master because I'm a whovian.) |
22:03 | |
jnthn | lue: :) | ||
pmichaud | jnthn: (less objection to no master) okay, noted. | 22:04 | |
if we want to call the branch something other than 'nom', we can do that. But I think TimToady++ is somewhat correct about too much renaming taking place, and that would be another instance of it. | |||
otoh, if we don't want this to be known as the "nom era", we need a new name for it. | |||
TimToady | jnthn: maybe niecza was expecting it :) | ||
lue | I can't come up with any real reason why I'd like it gone (much like jnthn in the other direction), except that it gets rid of the only stable-implying branch name, which better communicates the wobbly nature of implementing P6. | 22:05 | |
jnthn | TimToady: Maybe ;) | ||
pmichaud | I have to agree that rakudo gets the above one correct, with the exception of not warning about unused $para | ||
jnthn | pmichaud: Unless nl is spec, and NYI :) | ||
TimToady | niecza: for $*IN.lines(blurgh => "\n\n") -> $para { .say; exit } | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«Potential difficulties: $para is declared but not used at /tmp/2keHW6reGQ line 1:------> for $*IN.lines(blurgh => "\n\n") -> ⏏$para { .say; exit }Unhandled exception: Excess arguments to CORE TextReader.lines, unused named blurgh at… | ||
TimToady | heh | ||
jnthn | :) | 22:06 | |
pmichaud | for $*IN.lines(nl => "\n\n") -> $para { $para.say; exit } | ||
rakudo: for $*IN.lines(nl => "\n\n") -> $para { $para.say; exit } | |||
p6eval | rakudo 2bac6a: OUTPUT«Land der Berge, Land am Strome,» | ||
pmichaud | rakudo gets it right. | ||
well, not really. | |||
should be a paragraph and not a line | |||
jnthn | Right | ||
TimToady | and \n\n is wrongish for paragraph mode anyway | ||
jnthn | I'm trusting nl actually is in the spec and I just missed it :) | ||
pmichaud | yes, there's a :$nl argument to lines in the spec. | 22:07 | |
jnthn | ok | 22:08 | |
TimToady | perl6: for $*IN.lines(nl => /\n\n+/) -> $para { .say; exit } | ||
p6eval | pugs: OUTPUT«*** No such method in class Scalar: "&lines" at /tmp/a8kxHHNShe line 1, column 5-31» | ||
..rakudo 2bac6a: OUTPUT«Any()» | |||
..niecza v9-8-gd3b0031: OUTPUT«Potential difficulties: $para is declared but not used at /tmp/JwgDK3baEm line 1:------> for $*IN.lines(nl => /\n\n+/) -> ⏏$para { .say; exit }Unhandled exception: Excess arguments to CORE TextReader.lines, unused named nl at /home/… | |||
TimToady | that's a more correct definition | 22:09 | |
22:10
donri left
22:11
Limbic_Region joined
|
|||
lue | in any case, put my vote down for "master" removal. | 22:12 | |
TimToady looks around for a handy putdown... | |||
pmichaud | lue: noted | 22:14 | |
diakopter hands TimToady a put handmedown | |||
pmichaud | I'll make a decision (and the related switches) tonight, likely. | ||
Limbic_Region | Um - been away for some time now - have there been any major changes in status of Rakudo/Parrot in say - the last 18 months? | 22:18 | |
oh, and salutations all btw | |||
tadzik | yes, hello | 22:19 | |
TimToady | yes, we've done yet another 80% of the work :) | 22:29 | |
Limbic_Region | TimToady - you are well into the next 80% I imagine? | 22:30 | |
diakopter | well much of that 80% is rework at each cycle | 22:31 | |
22:31
sahadev left
|
|||
sorear | Limbic_Region: 18 months you say? Did you leave before or after ng landed? | 22:32 | |
Limbic_Region | sorear - I never really left but I have had almost no visibility to anything going on - so, no - I don't remember ng landing | 22:33 | |
TimToady | decommuting & | 22:34 | |
o/ # L_R btw | 22:35 | ||
Limbic_Region | for those of you who know me and care - last July I lost my Mother. I have lost about 90 pounds in an effort to get back in shape (I run 2 miles in under 16 minutes now). My oldest daughter - Jasmine, started Kindergarten and several promotions at work have left with me almost no time for distractions | ||
sorear | "almost no visibility to" is unidiomatic US or UK English. I wonder where you're from. | ||
Limbic_Region is US based | |||
sorear | anyway, yes, everything has changed. Except the things that haven't. | ||
Limbic_Region | well, that clears everything up - next you will be telling me MAD has been changed names to MUD | 22:36 | |
:P | |||
22:36
donri joined
|
|||
sorear | MAD has been essentially forgotten. | 22:36 | |
Limbic_Region assumed as much | |||
sorear | TimToady tells me it's only dormant, not dead | ||
Limbic_Region | without champions who refuse to give up or without communities that reach critical mass to carry on without champions - it happens | 22:37 | |
sorear | most of #perl6 now looks to STD::P5 as the way forwards for source compat | ||
Limbic_Region: as far as I'm concerned, the largest change in the Perl 6 community has been my entrance. :D | 22:39 | ||
Limbic_Region | sorear - awesome - how long you been on-board? | 22:40 | |
sorear | Limbic_Region: about 18 months. | ||
Limbic_Region: about 12 months ago I started writing an implementation of Perl 6 | 22:41 | ||
Limbic_Region assumed when you mentioned ng | |||
sorear | insufficient context to interpret statement | 22:42 | |
niecza: say "Hi" | |||
p6eval | niecza v9-8-gd3b0031: OUTPUT«Hi» | ||
Limbic_Region googled and filled in the blanks | |||
sorear | niecza: sub foo() { } | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«Potential difficulties: &foo is declared but not used at /tmp/pd0vsvqunG line 1:------> sub foo⏏() { }» | ||
pmichaud | okay, switching lineof() to use a binary search causes it to drop out of the profiling for the most part | 22:43 | |
sorear | niecza: say "foobar" ~~ / foo | foobar / | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«#<match from(0) to(6) text(foobar) pos([].list) named({}.hash)>» | ||
sorear | niecza: say ~ "foobar" ~~ / foo | foobar / | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«#<match from(0) to(6) text(foobar) pos([].list) named({}.hash)>» | ||
sorear | hmm | ||
niecza: say ~ do "foobar" ~~ / foo | foobar / | 22:44 | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«foobar» | ||
sorear | niecza: my $s = times[0]; loop (my $x = 0; $x < 1e8; ++$x) { }; say (times[0] - $start) / 1e8; | 22:45 | |
p6eval | niecza v9-8-gd3b0031: OUTPUT«===SORRY!===Variable $start is not predeclared at /tmp/sN7lczk79l line 1:------> 0; $x < 1e8; ++$x) { }; say (times[0] - ⏏$start) / 1e8;Potential difficulties: $s is declared but not used at /tmp/sN7lczk79l line 1:… | ||
sorear | niecza: my $s = times[0]; loop (my $x = 0; $x < 1e8; ++$x) { }; say (times[0] - $s) / 1e8; | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«(timeout)» | ||
sorear | niecza: my $s = times[0]; loop (my $x = 0; $x < 1e7; ++$x) { }; say (times[0] - $s) / 1e7; | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«6.136384E-07» | ||
jnthn | pmichaud: Was it quite high before? | 22:46 | |
pmichaud | jnthn: yes, but the profiling numbers were artificial somehow | ||
i.e., they seemed to indicate a lot of time was spent there... but optimizing it doesn't provide a substantial performance improvement | 22:47 | ||
(and direct instrumentation showed that it really wasn't as expensive as the profiling seemed to indicate anyway) | |||
anyway, it was O(n**2) for computing line numbers, now it's O(n**log(n)) | |||
and I can likely make it so that it's O(n) for most hits with some smart caching | 22:48 | ||
sorear | I hope you mean O(n*log(n)) | ||
pmichaud | yes, n*log(n) (thanks) | 22:49 | |
Limbic_Region chuckles | |||
22:50
wamba left
|
|||
donri | sorear: you should check for ttyness before you throw around ansi escapes *braindump* | 22:57 | |
mberends | donri: those ansi escapes in Niecza error messages are mostly from STD, you should take it up with TimToady | 22:59 | |
donri | ah :) | ||
sorear | irssi can interpret ansi escapes | 23:00 | |
if there's a big demand, I can patch p6eval to remap color codes | |||
donri | it would be cool, though this is just mild annoyance so don't go overboard :) | 23:01 | |
lue | what's annoyed me is that my irc clients of choice (first Konversation and now xchat) won't interpret those escapes properly, not the fact they're there. | ||
sorear wonders if mIRC color codes are actually more widely supported than ANSI | |||
lue | [in short, I blame my client, not the output] | ||
donri | i think it would be best to just strip all sorts of control codes | 23:02 | |
flussence | huh, I'm pretty sure xchat supports colours :/ | ||
donri | but maybe that's just me | ||
needs more <BLINK> though | 23:03 | ||
lue | not the ones from STD, though I should play around with the settings and possible modules before condemning xchat (Konversation had no such features :/) | 23:04 | |
23:04
Moukeddar joined
|
|||
Moukeddar | hi guys :) | 23:04 | |
sorear | hello, Moukeddar | ||
donri uses smuxi | |||
Moukeddar | i missed you | 23:05 | |
23:05
whiteknight joined
|
|||
sorear wonders what feature ey should demo to impress Limbic_Region | 23:05 | ||
Moukeddar | you should probably demo the BIG RED BUTTON feature | ||
sorear | doesn't have one. | 23:07 | |
yet. | |||
Moukeddar | you should make one | ||
everyone loves the BIG RED BUTTON | |||
23:09
sjn is now known as resistor,
resistor is now known as sjn
|
|||
jnthn | sleep & | 23:09 | |
sorear | niecza: sub infix:<§>($,$) { say '§' }; sub infix:<¤>($,$) is tighter<§> { say '¤' }; sub infix:<¶> is looser<¤> { say '¶' }; 1 § 2 ¤ 3 ¶ 4 | 23:11 | |
p6eval | niecza v9-8-gd3b0031: OUTPUT«¤Unhandled exception: Excess arguments to MAIN infix:<¶>, used 1 of 2 positionals at /tmp/hPjABSfoYc line 0 (MAIN infix:<¶> @ 0)  at /tmp/hPjABSfoYc line 1 (MAIN mainline @ 2)  at /home/p6eval/niecza/lib/CORE.setting line 2045 (CORE C954_ANON @ 2)  … | ||
sorear | niecza: sub infix:<§>($,$) { say '§' }; sub infix:<¤>($,$) is tighter<§> { say '¤' }; sub infix:<¶>($,$) is looser<¤> { say '¶' }; 1 § 2 ¤ 3 ¶ 4 | ||
p6eval | niecza v9-8-gd3b0031: OUTPUT«¤¶§» | ||
sorear | maybe that, Limbic_Region? | 23:12 | |
Limbic_Region | ? | 23:13 | |
sorear | Limbic_Region: user defined precedence levels! | ||
even pugs didn't do that. | |||
Limbic_Region | if I remember correctly, Pugs was waiting on a new version of Haskell's Parsec for that before Audrey went *poof* | 23:14 | |
sorear | does anyone remember what happened to Audrey? | ||
23:15
jevin left
23:17
Moukeddar left
23:18
jevin joined
|
|||
Limbic_Region | yes | 23:18 | |
23:23
[Coke] left
|
|||
sorear | Limbic_Region: did something specific happen or just burnout? | 23:23 | |
Limbic_Region | sorear - mostly personal reasons that are not appropriate to discuss in the channel but yes, burnout was a mitigating factor as well | 23:24 | |
23:25
[Coke] joined
|
|||
Limbic_Region | she is alive and well working for Socialtext by the way | 23:27 | |
23:28
ashleyde1 joined,
cexsum left
23:29
cexsum joined
|
|||
sorear | Limbic_Region: audrey has visited #perl6 occasionally, and for the most part it's even really been her. :) | 23:29 | |
23:30
mberends_ joined
23:31
mberends left,
ashleydev left
23:36
mberends_ is now known as mberends
23:37
Patterner left
23:38
cexsum left
23:40
Psyche^ joined,
Psyche^ is now known as Patterner
23:52
cexsum joined
23:54
molaf_ joined
23:57
molaf left
|