»ö« 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.
jnthn :) 00:00
OK, sleep
night o/
.oO( I'm so going to be making a lot of coffee at $dayjob tomorrow... )
&
dalek kudo/nom: 34be331 | pmichaud++ | src/core/Mu.pm:
Fix default .Stringy() in Mu.
 00:03
kudo/nom: 94a7f2e | pmichaud++ | src/Perl6/Actions.pm:
Nil is a lexical symbol now.
kudo/nom: fb1f700 | pmichaud++ | / (2 files):
Merge branch 'nom' of github.com:rakudo/rakudo into nom
kudo/nom: b04c763 | pmichaud++ | / (3 files):
Merge branch 'nom' of github.com:rakudo/rakudo into nom
kudo/nom: 66c1021 | pmichaud++ | / (3 files):
Refactor Range, add the ability to exclude endpoints. Also remove the RangeIter class.

Since Range is immutable, it can serve directly as its own iterator and doesn't need a RangeIter helper to keep track of generated elements. This eliminates some duplication of code, and provides some much nicer optimization possibilities.
00:05 alyx left 00:07 icwiener left 00:08 kst left 00:10 ymasory joined 00:16 info left 00:24 daniel-s left 00:27 alyx joined, alyx is now known as Guest54464 00:33 lichtkind left 00:42 kst joined 00:50 Eglis joined
Eglis I'm curious in when will perl 6 be ready for prod, been programming perl for 10 years and for the past 8 years i saw perl6 being developped. any time frame ? 00:52
pmichaud it's ready for production now, if your idea of production is what we currently support. :) 00:53
TimToady semantically, it's already mostly a superset of Perl 5; we're mostly trying to get it faster now 00:54
Eglis Can we run old perl in perl6? most of my code is 5.8 or older
TimToady but realistically, when the several implementations agree on freezing a version of the spec tests at v6.0.0, that's when we have a production release of the *language* as opposed to an implementaiton 00:55
*tion
I think we're converging on that within a year or so
nom: say 1,2,3...* 00:56
p6eval nom: OUTPUT«Could not find sub &infix:<...>␤current instr.: '_block1002' pc 112 ((file unknown):63289482) (:1)␤»
TimToady aw
pmichaud I'm working on sequence later tonight, I think.
TimToady nom: say 1..*
p6eval nom: OUTPUT«1..Inf␤»
pmichaud that one works, though :)
TimToady haven't backlogged completely, but some of them could use the first few terms of the infinite series before giving up 00:57
pmichaud yes, I was going to experiment with that too
Eglis Will you be able to do the asynchron stuff like in the Go language ?
TimToady something similar, though probably not identical 00:58
Eglis :) reading "much better", i wear perl underwear
TimToady :)
that is one of the areas where different implementations will have different strengths, due to platform limitations 00:59
Eglis I just hope perl6 comes out before php6 ( as the php developpers always said that for sure php6 would come out before perl6 )
pmichaud technically, perl6 is out already
has been for a while 01:00
Eglis not scared about linux implementation
yeah but no 6.0.0 official release
01:01 noganex joined
pmichaud the releases of Rakudo star are "official releases". The language spec is likely going to be somewhat larger than any given implementation for some time. 01:01
but that doesn't mean that perl 6 isn't available or that it can't be used 01:02
Eglis it still needs to be adopted by linux distros 01:03
pmichaud it's already available in fedora
(fedora 14) 01:04
Eglis It's crucial that enterprise level distros have it, fedora is for the basement :)
does rhel6 have it ?
pmichaud that just takes time
and we don't get to tell the distros what to do.
that's entirely up to the distro.
Eglis i agree
01:04 noganex_ left
Eglis Fedora is nice, to experiment 01:04
pmichaud of course, people used to say similar things about linux in general: "It's nice to experiment, but no enterprise-level organization will use it" 01:05
there wasn't a specific linux release where everyone said "it's ready for the enterprise." It depends on the nature of the enterprise as to whether it meets your needs or not.
Eglis I started a new job and most of their public facing servers are rhel 8, fc 1,2,3
not updated 01:06
pmichaud sure
TimToady in our case, once we trim down the 6.0.0 spec to what people are actually going to implement first, the rest of it will serve as an excellent gameplan for after that.
Eglis :) 01:10
01:11 Eglis left
jdhore1 That's funny. 01:21
Considering RHEL 8 does not exist and probably will not exist for at least 6 years (if i had to guess) 01:22
01:29 ajoe47 joined
ajoe47 perl6: say 3 01:29
p6eval pugs, rakudo 248244, niecza v6-177-g365e216: OUTPUT«3␤»
01:30 ajoe47 left 01:37 cooper left 01:38 whiteknight left 01:39 cooper joined
colomon $Inf? 01:44
(looking at the Range patch.) 01:47
pmichaud: do I understand correctly that when you get the next Range iterator, it's just another Range with min incremented? 01:50
01:54 thou left 01:59 Guest54464 is now known as alyx, alyx left, alyx joined 02:04 envi_laptop joined 02:05 woosley joined 02:40 thou joined
thou perl6: my $foo = 'guten tag!'; <<a 'b c' '$foo' "$foo bar" d>>.perl.say; <a 'b c' '$foo' "$foo bar" d>.perl.say; 02:47
p6eval pugs: OUTPUT«("a", "b c", "\$foo", "guten tag! bar", "d")␤("a", "\'b", "c\'", "\'\$foo\'", "\"\$foo", "bar\"", "d")␤»
..niecza v6-177-g365e216: OUTPUT«["a", "'b", "c'", "'guten", "tag!'", ""guten", "tag!", "bar"", "d"].list␤("a", "'b", "c'", "'$foo'", ""$foo", "bar"", "d")␤»
..rakudo 248244: OUTPUT«("a", "'b", "c'", "'\$foo'", "\"\$foo", "bar\"", "d")␤("a", "'b", "c'", "'\$foo'", "\"\$foo", "bar\"", "d")␤»
thou is pugs right here? 02:57
03:04 ajoe47 joined
colomon Hmmm.... I seem to recall that rakudo doesn't implement << >> quoting correctly... 03:11
lue rakudo: my $foo = "ouais mec!"; 􏿽xABa 'b c' '$foo' "$foo bar" d􏿽xBB.perl.say; # me is curious now 03:13
p6eval rakudo 248244: OUTPUT«===SORRY!===␤Confused at line 22, near "\ufffda 'b c' '"␤»
lue locally I get this: Cannot form :w list from non-constant strings (yet) at line 1, near ".perl.say;" 03:15
thou rakudo, niecza and nom are all ganging up on pugs
lue ASCII-ifying the guillemots gets me the same line as above [ ("a", "'b", "c'", "'\$foo'", "\"\$foo", "bar\"", "d") ] 03:16
Maybe the << is being seen by rakudo as < instead of 􏿽xAB ? 03:17
colomon lue: I suspect that is it. 03:18
lue I wonder what breaks it, 'cos << is interpreted correctly otherwise (try say <<a b c> <d e f>> ) 03:20
03:23 Su-Shee_ joined 03:27 Su-Shee left 03:30 ajoe47 left 03:31 ajoe47 joined 03:46 ajoe47 left 03:51 ymasory left 03:55 wamba joined 04:02 yinyin joined 04:07 satyavvd joined 04:08 Shozan left 04:15 Chillance left 04:34 mberends joined
thou is up to S10. feeling like i'm starting to enter the inner sanctum. 04:36
i admit i did gloss over some of the details in S09. 04:37
i'm looking forward to S12, i think that'll help answer a lot of my current stack of questions 04:39
04:57 birdwindupbird joined 05:01 jaldhar left 05:07 wamba left 05:09 jaldhar joined 05:11 koban joined
sorear thou: S02 is the important one anyway 05:25
thou yeah 05:26
but i'm still understanding more of S02 as I make my way through the rest :-) 05:27
05:28 jaldhar left
thou that whole thing about minimizing forward references ... i guess it mostly worked, but there's still a heap o' stuff to keep on my stack :-) 05:28
05:29 mberends left 05:34 jaldhar joined 05:37 kaare__ joined 05:45 f00li5h is now known as f00li5h[squeeze]
dalek kudo/nom: e8405b0 | pmichaud++ | src/core/ (3 files):
Clean up some GATHER instances now that gather { ... } works again (jnthn++).
 06:02
kudo/nom: ddc0166 | pmichaud++ | / (2 files):
Add terms.pm .
kudo/nom: f991181 | pmichaud++ | src/core/MapIter.pm:
Improve the speed of MapIter a bit.
kudo/nom: 92fa939 | pmichaud++ | src/core/ (3 files):
Improve iterator dumpers a bit.
06:02 Woodi left, Woodi joined 06:13 Su-Shee_ is now known as Su-Shee, wtw joined 06:58 wamba joined 07:02 mj41 joined 07:08 wamba left 07:14 zby_home_ left 07:16 mj41 left 07:17 mj41 joined 07:18 fhelmberger joined 07:30 daniel-s joined 07:36 cooper left 07:45 azawawi joined
azawawi hi 07:45
why can i find some source code for a minimal Perl 6 syntax highlighter? 07:46
tadzik does perl6.vim count? 07:47
azawawi something simpler. 07:48
im working on Perl 6 lexer for scintilla in Wx::Scintilla
I released an initial Perl 6 syntax highlighter earlier this week in beta.metacpan.org/module/Wx::Scintilla 07:49
that's why im asking for a minimal lexer code to start with... a proof of concept to build a more complicated one
07:50 wamba joined
sorear perl6.vim doesn't work all that well 07:52
azawawi sorear: hi
sorear if you find ANYTHING that can highlight Perl 6 in real time significantly better than perl.vim... I'd love to see it
07:52 wamba left
sorear vim likes to rehilite files after each keypress, and, well, I type too fast for perl6.vim 07:53
07:54 wamba joined, daniel-s left
azawawi sorear: That's what I am working at in api.metacpan.org/source/AZAWAWI/Wx-...xPerl6.cxx 07:55
it is still experimental but i hope to get done by this weekend 07:56
once finished it means all wxWidgets editors (i.e. Padre, Kephra) can utilize it 07:57
I can backport it afterwards to Syntax::Highlight::Perl6::Fast 07:58
try.rakudo.org/ down?
sorear AFAIK it has been for a while
tadzik it's rarely up :/ 08:02
azawawi sorear: what's the average line count of Perl 6 files that you work on? 08:03
sorear: are we talking about STD.pm6?
sorear azawawi: it starts to become a problem at about 500 lines and is unusable for NieczaActions (3000) and STD 08:04
azawawi sorear: any hyperlinks so I can add it to my benchmarks? 08:05
08:05 aloha left
sorear github.com/sorear/niecza, src/NieczaActions.pm6 08:05
azawawi Thanks. I will use STD.pm6 and NieczaActions.pm6 while testing LexPerl6.cxx 08:11
sorear how well does it handle something like q:s'&infix:sym<$S>' ?
azawawi it doesnt handle anything at the moment. 08:12
08:17 wamba left, daxim joined 08:18 cotto left 08:35 Woodi left 08:36 Woodi joined 08:50 daniel-s joined 08:58 thou left, azawawi left 09:00 aloha joined 09:17 kst` joined 09:21 kst left 09:22 pothos joined 09:24 y3llow joined 09:37 cognominal_ left
flussence
.oO( bah, I make up easy-to-remember ssh passwords then can never remember them... )
 09:38
moritz generates easy-to-use ssh keys
flussence got it after 5 tries :) 09:39
09:39 JimmyZ joined
flussence hm, try.rakudo backend works fine, the website itself is down... :/ 09:42
there, all fixed 09:44
moritz was apache down?
flussence seems it wasn't running 09:45
probably got stopped after the main site got moved, the last log on here is April 22ish
moritz Rakudo REPL has timedout... reaping. 09:46
flussence those are just the standard "nobody's using this process" cleanup things 09:47
moritz uhm... feather3 runs sid?
flussence no idea
moritz Get:6 ftp.us.debian.org sid/main Sources/DiffIndex [2,038B]
flussence oof.
moritz is what 'aptitude update' is saying
moritz updates feather2 09:50
that's a debian stable, something that I dare to touch
flussence if it is sid, then it apparently hasn't been updated in a *long* time - screen complains about my 21-char $TERM being too long
moritz good, perl6.org still shows up after a security update of apache, openssl and perl 09:52
09:57 MayDaniel joined 10:08 woosley left 10:22 f00li5h[squeeze] is now known as f00li5h 10:30 Woodi left 10:31 MayDaniel left 10:32 Woodi joined 11:12 JimmyZ_ joined 11:15 JimmyZ left, JimmyZ_ is now known as JimmyZ 11:38 Moukeddar joined 11:39 Moukeddar left 11:43 satyavvd left 11:48 JimmyZ_ joined, domidumont left 11:51 JimmyZ left 11:52 JimmyZ_ is now known as JimmyZ 11:53 domidumont joined
takadonet morning all 11:55
12:06 leprevost joined 12:08 orafu left 12:12 orafu joined, Chillance joined
pmichaud good morning, #perl6 12:20
question of the morning: Is there a syntax so that a programmer can request inlining of a pblock? (I know that the compiler will someday be smart enough to figure it out on its own... until then, an explicit request mechanism might be helpful.) 12:22
moritz I don't think there is 12:23
pmichaud can we make one? :)
for now I'm thinking of just putting a comment inside the opening block marker
moritz what about INLINE <blorst> ?
pmichaud I'm really interested in pblock more than blorst atm 12:24
12:24 MayDaniel joined
pmichaud (i.e., if/else, while, and for) 12:24
or maybe xblock would be sufficient 12:25
moritz something like if $foo { #INLINE \n say $foo } ?
pmichaud yeah 12:26
12:26 MayDaniel left
pmichaud exactly that is what I was thinking for now :) 12:26
12:28 yinyin left
pmichaud iterators in nom are currently slow again... I'm thinking that inlining blocks might help (without having to resort to Q:PIR or funny parenthesized constructs) 12:28
moritz how slow are they? 12:29
pmichaud about 2x master
moritz 2x as fast? or as slow?
pmichaud 2x slow 12:30
moritz wow
pmichaud I'm only a little surprised -- we end up with a lot of block invocation overhead that master didn't have
moritz considering how much faster the rest of nom is, I'm surprised
pmichaud well, iterators in master were completely hand-tuned PIR, no extra lookups. In nom they're just generated code, lots of extra lookups 12:31
but I still suspect it may be the block invocation overhead that is causing the slowdown 12:32
for example, in nom if we process a 10000 element array, we get at least O(10000) block invocations that master doesn't have.
(in while and if loops)
PerlJam good * #perl6
pmichaud and O(10000) is really O(10000 * *), since there's the cost of the while loop itself and its nested if/then blocks 12:33
but beyond that, I'd really like to get to the point someday where
for @list { ... }
can inline the { ... }, and it would be good to start experimenting with that sooner rather than later in controlled conditions
PerlJam: o/ 12:34
PerlJam pmichaud: when *wouldn't* a pblock be inlined? 12:35
pmichaud PerlJam: when it's a closure
my $x = -> { ... }
PerlJam pmichaud: can't you determine that relatively easily now? 12:36
pmichaud PerlJam: it's more than that, we have to have lexpads for the pblock's lexicals.
in the case of
for @list -> $x, $y { ... } 12:37
JimmyZ PerJam: for @list { my $a; .... }
pmichaud we have to not online inline the code for the block, but we have to do a signature bind of $x and $y to the munched arguments of @list (more)
at present we don't have a way of doing that, and I don't want to wait for getting all of those invalidating assumptions in place before doing some inlining 12:38
*not only
afk for a bit 12:39
tadzik hrm. What more is needed than when a block does not take any parameters or does not declare variables? 12:46
PerlJam looks at pictures of NPW 12:48
moritz PerlJam: URL?
tadzik oh, pics! 12:49
pmichaud tadzik: none of its inner blocks use OUTER::, perhaps
tadzik oh, that too 12:50
PerlJam blogs.perl.org/users/claes_jakobsso...tters.html
Those aren't the pictures, but that's where I got the link from.
12:50 mtk joined
PerlJam pmichaud: Perhaps it's just my ignorance, but it really feels like "someday" could be today. Or, perhaps get you and jnthn looking at the same problem and "someday" could be in a matter of hours. 12:51
moritz PerlJam: problem is that many features that might prevent inlining are NYI
PerlJam moritz: that doesn't sound like a problem at all ;) 12:52
moritz PerlJam: so we kinda build up a hurdle for implementing them in future if we rely on their absence
pmichaud PerlJam: and the first step for that is likely to have a way to flag a block as inlinable, no?
PerlJam pmichaud: good point.
pmichaud or do we just assume that all blocks get inlined and then pessimize whenever something breaks? 12:53
that seems like... icky.
PerlJam I think I've become less patient in my old age.
pmichaud I'm saying I want to break the problem down into two parts: (1) have the ability to inline blocks without having the compiler have to figure out when to do it, and (2) get the compiler to figure out when to do it :) 12:54
12:55 smash joined
smash hello everyone 12:55
PerlJam smash: greetings 12:56
tadzik 1) looks either temporal, non-specy or both, something we might want to have like now, 2) is rather a long term goal 12:57
PerlJam wonders if it should be specced. 12:59
tadzik mebbe
pmichaud thus my question :-)
PerlJam I mean that's what we have $?vars
13:00 Holy_Cow joined, Holy_Cow left
PerlJam COMPILING::< 13:05
COMPILING::<$?INLINE> = True; # ?
pmichaud PerlJam: I don't understand, at least not for my use case.
tadzik INLINE {} 13:06
pmichaud tadzik: looks too much like a phaser, I think.
tadzik right. Hrm
PerlJam pmichaud: I was thinking you'd put that in any block you wanted inline.
pmichaud PerlJam: oh, maybe. We don't have those sorts of compile-time variables yet, I don't think. 13:07
moritz PerlJam: I think that requires too much effort on behalf of the compiler
tadzik if it wasn't supposed to be speccy, that wasn't a problem
pmichaud also, it needs to be attached to a block, not to the overall compiler (if it's to be done on a per-block basis, which is my use case)
tadzik s:2nd/wasn't/wouldn't/
.u moustache 13:08
phenny tadzik: Sorry, no results for 'moustache'.
tadzik dang
moritz .u beard 13:09
phenny moritz: Sorry, no results for 'beard'.
tadzik .u bear
phenny tadzik: Sorry, no results for 'bear'.
tadzik how boaring
moritz .u panda
phenny moritz: Sorry, no results for 'panda'.
moritz .u tiger 13:10
phenny U+2EC1 CJK RADICAL TIGER (⻁)
tadzik nice square
truly a radical tiger
13:21 wamba joined 13:22 mattp_ left 13:26 Woodi left 13:28 Woodi joined 13:40 bkolera joined 13:50 wtw left, dodododo joined
daniel-s .u lol 13:50
phenny daniel-s: Sorry, no results for 'lol'.
daniel-s .u phenny
phenny daniel-s: Sorry, no results for 'phenny'.
daniel-s .u perl
phenny daniel-s: Sorry, no results for 'perl'.
daniel-s .u irc 13:51
phenny daniel-s: Sorry, no results for 'irc'.
daniel-s .u anything
phenny daniel-s: Sorry, no results for 'anything'.
daniel-s .u suck
phenny daniel-s: Sorry, no results for 'suck'.
moritz .u disc
phenny U+2382 DISCONTINUOUS UNDERLINE SYMBOL (⎂)
moritz .u server
phenny moritz: Sorry, no results for 'server'.
perplexa .u swastika
phenny perplexa: Sorry, no results for 'swastika'.
perplexa :p
it's broken
13:53 PacoLinux joined
perplexa .u U+534D 13:54
phenny perplexa: Sorry, no results
13:54 broquaint joined
perplexa .u 21325 13:55
phenny perplexa: Sorry, no results for '21325'.
moritz .u 534D
phenny U+534D CJK UNIFIED IDEOGRAPH-534D (卍)
perplexa :p
hmkay
ლ(ಠ益ಠლ) 13:56
arnsholt Mmmm. Telugu?
14:06 Mowah_ left, Mowah_ joined 14:40 daniel-s left 14:41 kaare_ joined 14:42 wamba left, REPLeffect left, kaare__ left 14:50 koban left 14:56 REPLeffect joined 14:59 thou joined 15:02 lichtkind joined
TBA2 afternoon #perl6 15:06
moritz \o 15:07
15:08 cosimo joined
colomon \o 15:09
15:09 jaldhar left 15:10 jaldhar joined
lichtkind :) 15:10
15:19 leprevost left
lichtkind what do you think about the qp/../ ~~ :d syntax? 15:20
moritz thinks its dangerous
lichtkind moritz: why?
moritz lichtkind: because history tells us that it's very hard to make a good, usable and cross-platform path handling library 15:21
lichtkind: and since it's unlikely we get it right, it shouldn't be in core
lichtkind but qp is cor perl 6 as far as i know
moritz right, that's what makes it dangerous 15:22
lichtkind my question was more about to replace the .IO syntax
moritz it forces us to deal with paths in core
lichtkind i understand
moritz: but unless File::Spec ha broken things in it im not aware we have something to orient on 15:23
s/ha/has/
moritz is pretty sure that a bit of googling will show up many problems with File::Spec 15:24
I don't remember the exact discussions, but I do think there were good reason for not just copying its API
lichtkind theres always something to improve but i mean there are also some problems solved in it so we dont have to build anything from scratch 15:25
lichtkind reading rt.cpan.org/Public/Dist/Display.ht...=PathTools 15:28
colomon moritz: I guess I don't see how saying "filename".IO ~~ :d is somehow less dangerous than qp/filename/ ~~ :d 15:29
15:29 daniel-s joined
moritz colomon: I never made that comparison 15:30
colomon: "filename".IO is likely also wrong (considering that most OS don't have APIs for specifiying filenames as character strings) 15:31
15:33 leprevost joined 15:35 mattp_ joined
moritz the spec on it contains pearls such as: 15:35
The "Path" role covers both the path to the file, and the file metadata. They
are usually created with the qp{/path/to/file} syntax.
...
Note that @.Elements
can not be accessed unless $.Encoding is defined.
so I need something like
my $file = qp{/etc/passwd};
$file.Encoding = 'UTF-8'; 15:36
say $file.Elements[0]
except that $.Encoding isn't declared as 'is rw', so it won't work
jnthn evening, #perl6
moritz \o jnthn
S32/IO feels like it's doing some decent engineering, but doesn't actually solve the problems it should solve 15:38
moritz should stop ranting
jnthn pmichaud: (inlining bare blocks) Can you point me at the code where it's an issue? 15:39
TBA2 lichtkind: are the p6 tablets available as pdf anywhere? wanna stick a copy on my phone for mobile reading :) 15:40
TBA2 thinks ranting is a good way to highlight issues (or so I tell my boss!) 15:41
\o jnthn
moritz feels encouraged and continues... why does Path has a $.Target attribute, if it only makes sense for links? 15:42
TBA2 on the issue of filepaths, isn't that very OS specific, i.e. filepath handling on Amiga OS is entirely different to Linux, Windows, etc, so unless the intention is to cover *every* possibility, surely none would be better?
moritz and why are all the attributes in Path capitlized, but not in the rest of the spec?
TBA2 was someone drunk while writing IO specs? lol
15:43 dodododo left
lichtkind TBA2: not yet 15:43
TBA2 personally I'd rather implement my own filepath handling for each OS I want to code for, rather than have Perl do it and end up spending time fighting it
moritz TBA2: that is exactly the problem. If we can't cover everything, it shouldn't be core
TimToady that is very non-P5-ish thinking 15:44
PerlJam there's a reason the specs are editable :)
TimToady and non-URL thinking
colomon So, if you can only support 99.9% of the systems out there, you shouldn't support it at all? That's.... <deleted for politeness>
moritz TBA2: otherwise we're implicitly saying things like "Perl 6 is a language for windows and UNIX only"
TimToady there needs to be a universal layer that can be adequately mapped to an OS-specific layer, that's all 15:45
the correct answer is not "all OR one" 15:46
colomon +1
moritz another thing I don't like with the current approach is that it conflates path/filename with file metadata
so we might end up doing an IO operation for every path construction
TimToady I do agree that the OS-specific layer should be pluggable wrt the universal layer 15:47
moritz or we try to be clever and lazily defer it, but then it might become very hard to understand when and if an IO operation is involved
TBA2 TimToady: sounds good to me if it can work in practice 15:48
TimToady I believe the overriding concept here is one of identity, so as best to avoid race conditions and mutable/immutable failures
moritz and the "when" can be very important in IO land (see also: race conditions)
TimToady unfortunately files come in both value and object semantics 15:49
15:49 daniel-s left
TimToady so it will be very important, if this is an area that may evolve over time, to specify which version of io semantics we're thinking of 15:50
perhaps this can be tied to p6 versions
or maybe a given p6 version has a default io version
but overridable
I just don't want to evolve the Java way with 20 layers of indirection 15:51
TimToady wonders how many layers of indirection P5 as collected there
*has
wrt identity, the trend in Unixoid systems is to treat the file descriptor as the actual identity object, and add things like fchown 15:52
the logical extreme of that, though, is that you have to open a file to do anything with it, like stat it 15:54
15:55 icwiener joined
TimToady but much of the P6 design is to establish stable identities with stable semantics, and then try to attach everything to the correct "peg" 15:56
sounds kinda like a sociological theroy 15:57
*theory even
15:58 Mowah left
slavik1 TimToady: is there anything special being done for object serialization? 15:59
TimToady we can muddy the user view with tricks like Cool, but the system should keep an accurate view of identity
slavik1: you mean like making sure AOP is supported in the design? :) 16:00
slavik1 not sure what aop stands for
I was looking for something like java does but better
TimToady Aspect Oriented Design
slavik1 I guess, I am not familiar with that concept :( 16:01
TimToady think of it as compile-time monkey patching :)
jnthn pmichaud: for loops seem to leak memory
pmichaud: Do my $x = 0; for 1..50000 -> $n { $x = $x + $n }; say $x and watch. 16:02
TimToady the nice think about serialization is there are so many to choose from
slavik1 TimToady: yeah, the java kind sucks though since it doesn't appear to send the actual object through so if your object versions differ (fields don't match), it will fail 16:03
TimToady I am enough of an expert on the subject to know I am not an expert on the subject. 16:05
16:05 mj41 left
slavik1 TimToady: this is mainly in context of rmi 16:05
sbp avoiding the en.wikipedia.org/wiki/Dunning%E2%80...ger_effect 16:06
TimToady me hasn't a clue what rmi means
slavik1 and jmx (java management extensions), rmi (remote method invocation)
TimToady only collects other people's horror stories about Java, and prefers not to collect any of his own.
slavik1 TimToady: this is yet another one 16:07
16:07 tokuhirom joined
slavik1 I'm not going to bother you with it since I think it will give you nightmares and stiffle perl6 progress :P 16:07
TimToady: I will ask you this: Have you ever heard of MUMPS? (the language) 16:08
TimToady yes
slavik1 Java is worse than that 16:09
TimToady then why didn't MUMPS take over the world? :)
I submit that Java is better at something
slavik1 there wasn't a vm for mumps for all platforms 16:10
which is the reason .net is having a hard time, because microsoft has its head in its ass
which leads me to believe that either microsoft is lazy, or they don't know how to make something that can take over the world 16:11
benabik slavik1: Their view of "the world" is limited to machines running Windows. 16:12
slavik1 which makes me want to find the guys at ibm that designed the first AT and ask them if they would still pick intel and microsoft as their vendors
benabik: yeah, which is why they can't take it over
16:13 Chillance left
TimToady if IBM had managed to control that market, they'd've been broken up like Ma Bell 16:13
and then we'd be stuck with baby IBMs 16:14
slavik1 TimToady: reminds be of Stephen Colbert's AT&T map of 80s vs. today
gfldex Microsoft is a closed society. If you are not on the campus you cant talk to them. If you don't talk, how could you be important.
TimToady I talk to my son-in-law. :)
slavik1 X.X 16:15
gfldex you are not a closed society then
16:15 Mowah_ left
TimToady my son-in-law works in Redmond 16:15
slavik1 TimToady: -1 respect point 16:16
TimToady now you're just being religious :P
PerlJam TimToady: most of humanity seems to be so infected
moritz thinks that some of the Microsoft departments do really cool tech
slavik1 TimToady: says someone who put 'bless' as a keyword in a language to make hashes into fake objects. :P 16:17
PerlJam "fake objects"?
slavik1 fine, blessed hashes
pyrimidine I think MS set up a free VM farm for testing perl modules at one point (I think Alias helped), so they can't be completely evil 16:18
PerlJam They're not so much "fake" as they expose more of the underlying machinery to the user
slavik1 PerlJam: that's why they are awesome
pyrimidine I'm pretty sure other langs use similar mechanisms, they just aren't as exposed 16:19
TimToady if you read the documents, you'll find that "bless" is actually the corporate metaphor of bless, not the religious...as in the boss giving his approval to a proposed project of the underlings 16:21
slavik1 that's even worse!!! 16:22
:P
TimToady so it really means, "Yes, I recognize that this thing officially fits into my (class) organization." 16:23
16:23 JimmyZ left, JimmyZ joined 16:29 Moukeddar joined
Moukeddar Hello :) 16:29
JimmyZ hi
Moukeddar how are you?
16:32 wamba joined 16:33 cdarroch joined, cdarroch left, cdarroch joined 16:38 kst` is now known as kst 16:42 Mowah joined
pmichaud jnthn: the example you gave is almost exactly the one I've been playing with 16:44
16:44 cotto joined
pmichaud my $x = 0; for 1..50000 -> $n { $x = $x + $n }; 16:44
I'm not sure about "leaks memory"... or at least that it leaks memory in ways that it's not supposed to leak just yet :) 16:45
16:45 molaf joined
jnthn pmichaud: It leaked a load but I've worked out why and fixed it. 16:46
pmichaud: Along the way cached the sorted multi-dispatch list. 16:47
pmichaud: Shaved 30% off loops like the above, it seems.
pmichaud good
I have a few more improvements to make
the result of the for is 'leaky' too, because I don't have .sink yet
jnthn brb
pmichaud how costly are "isa" checks these days? 16:48
dalek kudo/nom: f6439e3 | jnthn++ | src/ (3 files):
Save sorted mutli-dispatch candidate list. Shaves 30% off a for 1..10000 -> $n { ... } style loop, and probably a decent bit off other bits.
pmichaud aye, 30% here also 16:50
jnthn++
jnthn pmichaud: They're cheap if you hit the cache, which you should be. 16:52
pmichaud: If you aren't, then it shows up in profiles. :)
pmichaud: They're pointer follows/comparisions.
pmichaud okay, good to know
my initial test with inlining blocks didn't show a massive improvement
that's both good and bad
it did eliminate the extra block invocations, but didn't make a significant difference in performance 16:53
jnthn May make more of one with 30% gone. 16:55
pmichaud well, the for 1..10000 -> $n { ... } loop was taking ~9 seconds on my machine when I startged 16:56
16:56 birdwindupbird left
pmichaud after changing listiter to inline its blocks and loops (where I expected most of the cost to be), it was still ~9 seconds 16:56
after your fix, it's around 6sec
so I suspect with inlining it'll be around 6sec also
current target is to make sure it's as fast as an equivalent while<> loop which is currently around 2sec 16:57
jnthn I'd bet the while loop went down with my multi improvements too.
pmichaud oh, and I figured out earlier a way to create 'for' in terms of 'while' -- i.e., to be able to inline the body of a for loop
(haven't implemented it yet, but it'll be available when we get to that point) 16:58
btw, I have the Null PMC access bug again... ran across it this morning 16:59
jnthn pmichaud: Boolification is costing us quite a bit.
according to the profile
pmichaud I'm not too surprised about that.
jnthn I can probably improve on that a bit, though. 17:00
pmichaud for the null pmc bug: apply the patch in gist.github.com/1036004 (making a reference to a non-existent type), recompile, and then execute my @a = 1..10; my $b = @a.iterator 17:01
result is:
> my @a = 1..10; my $b = @a.iterator
Null PMC access in get_pmc_keyed()
it should probably catch the non-existent MyListIter at core compile time, but seems to skip that 17:03
17:04 dukeleto left, avar left
jnthn nom: MyListIter 17:04
p6eval nom: OUTPUT«Could not find symbol '&MyListIter'␤current instr.: 'fail' pc 170302 (src/gen/CORE.setting.pir:42583) (:115)␤»
17:04 dukeleto joined, avar joined, avar left, avar joined
jnthn nom: class Foo { method m { MyListIter } }; Foo.m 17:05
p6eval nom: OUTPUT«Could not find symbol '&MyListIter'␤current instr.: 'fail' pc 170302 (src/gen/CORE.setting.pir:42583) (:115)␤»
pmichaud I could only get it to appear when compiling the core setting
jnthn Oddness.
pmichaud (so far)
jnthn OK, will put it on my list.
pmichaud the other tests I've tried out side of the core give the errors you've listed above :) 17:06
JimmyZ night
jnthn night, JimmyZ
pmichaud: Yeah. It doesn't make a great deal of sense to me why core would get special treatment in that regard. 17:07
oh
nom: my class Foo { method m { MyListIter } }; Foo.m
p6eval nom: OUTPUT«Could not find symbol '&MyListIter'␤current instr.: 'fail' pc 170302 (src/gen/CORE.setting.pir:42583) (:115)␤»
jnthn no, not that either.
pmichaud tried that also :)
I tend to prototype changes and significant refactors in files outside of the core, so that I'm not constantly recompiling the core. So things like "List" become "MyList" while I'm doing that. Then when I have things working, I copy the new code into the core and recompile... and if I forget to switch a MyList back to a List... I get the null pmc error 17:08
although it's happened enough times now that I know what to look for :) 17:09
(the one this morning occurred when I mistyped ListIter as ListITer )
17:09 ajoe47 joined, JimmyZ left
jnthn my $block := pir::perl6_decontainerize__PP($!block); # in MapIter - do you do this just for a little performance win, or is it needed? 17:10
pmichaud appears to be needed. take it out and you'll see the error. 17:11
jnthn OK, am a tad curious why.
pmichaud I was too, at the time.
jnthn I can normally spot where those are needed.
pmichaud also, I didn't know if the lexical lookup would be better than the attribute lookup 17:12
(inside the loop)
I know that .munch is also a little on the slow-side
btw, I can eliminate the Q:PIR there when we have &sub(|@foo) working :)
jnthn OK 17:13
hm
On .munch - it makes an RPA every time 17:14
So in a 1..10000 loop we make 10000 RPAs.
17:15 Sarten-X joined
TimToady wonders why it wouldn't just be "also is inline;" 17:17
pmichaud ...because I didn't see it anywhere? ;-)
jnthn TimToady: That'd make sense :)
17:19 alester joined
tadzik hello 17:20
jnthn o/ tadzik 17:22
tadzik dispatcher cache, nice. I wonder how will it like my stupidloop test :) 17:24
jnthn tadzik: It's not a cache per se, it just avoids re-sorting every time 17:25
tadzik 553 /* XXX TODO: Cache! */ 17:26
ah, I see
pmichaud jnthn: we're going to have the RPA no matter what, whether it's explicit or implicit inside of a Parcel
oh, you mean 10000 extra RPAs. yeah.
oh, no, we still end up with the RPA 17:27
I've been thinking of switching that code to do a splice instead of shift/push though
I'm not convinced it'll be any faster to do that, however. 17:28
we can avoid the extra rpas if we have partial binding in place, though :) 17:29
and then I might not need $block(|@foo) -- i'd use the partial binder instead :) 17:30
17:32 Moukeddar left
tadzik 30% speedup confirmed :) 17:34
pmichaud we're still slower than master, though. I'm sure that'll get fixed too . 17:35
tadzik are we? huh 17:38
17:40 daxim left
jnthn tadzik: On iteration. 17:40
tadzik 6.75 seconds on nom, 93,02s on master. Either my stupid test is too stupid, or I like your definition of "slower" :)
oh, mybe
17:41 cooper joined 17:42 cognominal joined
pmichaud oh, I know an optimization we need ... (/me patches) 17:42
17:42 smash left 17:43 kaare_ left
tadzik 'for (1..10000) {}' is 3.82 on master, 16.16 on nom 17:43
pmichaud tadzik: right
range generation is slower right now, for one
the range generator in master is really fast
17:43 ajoe47 left
pmichaud on my machine, 1..10000 takes 7sec on master, 23sec on nom 17:45
sorry, 1..100000
but I can speed that up in nom :)
jnthn: I've been wanting a pir:: syntax for pir:: numeric/string constants 17:51
so that we're not unpacking a constant just to pass to a pir opcode. worth the trouble, or do you think the current unboxing is fast enough?
e.g: pir::int(0) and pir::num(3.5) 17:52
17:57 cognominal_ joined
jnthn masak says hi 17:58
he has no laptop :(
pmichaud: I've been wanting that context-sensitive PAST node :)
pmichaud: That's the way that the above should be fixed :)
pmichaud: e.g. it'd know what to do for an I register and what to do for a P register 17:59
pmichaud: Can then do natively typed attrs far better also :)
Time for food - bbl
18:00 cognominal left, jaldhar left
pmichaud jnthn: okay, I'll prototype one up. 18:05
I agree that's easier/better/more general.
18:09 natureboy joined 18:12 cooper left 18:13 DarthGandalf left 18:16 cognominal_ left
tadzik ooh, idea. The Perl6::Cricic could probably be written as a Perl6::Grammar with custom (criticising) Perl6::Actions 18:16
18:17 fhelmberger left
flussence ponders the level of insanity needed to write a HTML5::Grammar 18:17
18:17 DarthGandalf joined
tadzik would that be so insane? 18:17
thou tadzik: almost like what STD does now
flussence tadzik: the HTML5 spec's "parsing" section is about a mile long :) 18:18
tadzik Besides <li> not having to be closed with </li> is there that much insanity in html5?
oh :)
thou: STD has actions now?
TimToady viv is all actions
tadzik istr it just has lots of "|| <.panic "bla bla">" in the regexes
oh
flussence and it specs about 20 years of browser error-tolerance cruft 18:19
thou i just meant that it will warn about unused vars, etc.
tadzik unused vars is more like a compiler job than a critic job, methinks
thou yeah 18:20
18:20 cognominal joined
pmichaud jnthn: how about this as an api for a context-sensitive node handler? gist.github.com/1036222 18:27
we can change the name
maybe PAST::Contextual
pmichaud fights to avoid "PAST::Contextual::Return"
dalek kudo/nom: 02d5f56 | pmichaud++ | NOMMAP.markdown:
NOMMAP update.
 18:35
tadzik pmichaud: about inlining blocks that use OUTER::, couldn't we just drop the OUTER:: part from them then? 18:38
TimToady nom: constant @a = 'A'..'Z'; 18:43
p6eval nom: OUTPUT«Constant type declarator not yet implemented at line 1, near "= 'A'..'Z'"␤current instr.: 'nqp;HLL;Grammar;panic' pc 23569 (src/stage2/gen/NQPHLL.pir:6311)␤»
18:47 mj41 joined 18:52 DarthGandalf left 18:56 icebattle joined
pmichaud I think I may optimize the numeric range case 18:56
(into pir-ish stuff)
lichtkind thou: great work 18:58
for a beginning :)
thou lichtkind: a small start :-)
18:58 DarthGandalf joined
lichtkind thou: there were some correctifying changes in between 18:59
jdhore1 pmichaud, did you notice the problem in nommap? 19:02
pmichaud jdhore1: which one? 19:03
(no.)
jdhore1 pmichaud, Last Updated 19 June 2001
pmichaud oh
jdhore1 pmichaud, Last updated: 10 years ago
pmichaud jdhore1: yes, this way we can say we've only been working on Perl 6 for a few months :-P
19:03 dukeleto left
pmichaud I'll fix it in my next update :) 19:03
jdhore1 hehe 19:04
19:04 dukeleto joined
pmichaud (thanks for noticing -- jdhore1++ ) 19:04
19:05 frettled left
jdhore1 You should pull a Top Gear moment and change the year to 2020 19:05
rakudo/nom: The only software project coming to you from 9 years into the future
TBA2 lol lets hope thats not actually true ;) 19:07
rakudo/nom: 20 years in the making...
it'll be older than half the developers using it :P
19:11 mj41 left
jdhore1 :( 19:12
19:17 envi_laptop left 19:25 birdwindupbird joined
dalek kudo/nom: bdfbe6b | pmichaud++ | src/core/Range.pm:
Use Q:PIR to hotpath the generation of int/num ranges.
 19:29
kudo/nom: e1a181c | pmichaud++ | src/core/ (2 files):
Add Int/Num specific versions of prefix:<++>, prefix:<-->, etc.
tadzik whoa whoa 19:30
I need to see this :) 19:32
19:32 wamba left
thou um, that sounds promising :-) 19:33
TBA2 updates his nom install 19:34
tadzik um. 'for (1..10000) {}' was 10.32s, is 8,76s 19:35
optimizations don't work for me :) 19:36
flussence throws his patience out the window and does a git checkout
19:36 ggoebel joined 19:37 miso2217 left
pmichaud tadzik: try: (1..10000).reify(*) 19:39
I didn't say for loops were faster, I just said that range generation was faster :)
TimToady depending on how you count, there will only ever be 0 or 1 high-level computer languages older than me...
tadzik I see :) 19:40
sorear good * #perl6
pmichaud I think you'll find that under the old system, (1..10000) was taking about 1.6s to generate :)
and now takes much less
19:40 miso2217 joined
tadzik awesome 19:40
pmichaud er, (1..10000).reify(*)
19:40 natureboy left
tadzik what's .reify? 19:40
thou good night, sorear 19:41
pmichaud that takes a list or iterator and turns it into its elements
i.e., it gets rid of the lazy parts
19:41 cooper joined
PerlJam TimToady: I'm sure the folks that worked on the ENIAC considered ENIAC short code a high-level computer language :-) 19:42
TimToady of course, for 1..10000 should never generate a list in the first place...
pmichaud it shouldn't? 19:43
what does .map.... map then?
TimToady I just mean that's something obvious to optimize into a simpler 1 variable loop 19:44
pmichaud ah, optimization. yes.
TimToady loop ($_ = 1; $_ <= 10000; $_++) {...}
or some such
or into some special internal form like p5 does 19:45
well, not suggesting we do that opt right now 19:47
pmichaud either way, I'm happy with a significant speed improvement on numeric ranges :-)
TimToady though it'd be nice to have *some* benchmarks blazing fast for the cheerleaders to cheer about 19:48
pmichaud when the p6 code gets within 50x of the Q:PIR, we can see about removing that optimization :-)
oh, I can still make the for loop faster
that's what all of this rewriting/refactoring is about :)
right now we're just trying to figure out where the (new) slow parts are
TimToady well, chances are it's something that redeciding things that only need to be decided once :) 19:49
esp where the side effect of deciding is to create something... 19:50
19:51 sftp left 19:53 sftp joined 20:00 donri left
sorear 2µs per range item? that's pretty good... 20:02
20:02 MayDaniel joined
sorear way better than what niecza currently has :D 20:02
pmichaud yes, I needed to check several times that the range elements were actually being created :) 20:03
20:10 molaf left 20:14 mj41 joined
flussence hm, nom doesn't like my normal build script... I have to make install *before* make spectest 20:15
sorear does nom pass any spectests?
flussence that's what I'm curious about :)
pmichaud not yet
we're not to the point of being able to run Test.pm yet. 20:16
sorear trying to implement MY:: et al in niecza has balooned into a redesign of the low-level package system
pmichaud that happens a lot in p6, I've found :)
20:17 wamba joined
flussence bah, generating the core thingy still takes forever and a day in nom :) 20:17
PerlJam flussence: are you sure you're compiling nom? Or are you speaking in relative terms? 20:18
20:20 birdwindupbird left 20:24 MayDaniel left
jnthn pmichaud: WOW! Nice optimization 20:28
pmichaud: One little request.
Please can you leave the original Perl 6 code above the Q:PIR in these cases, with a "ETOOSLOW" note? 20:29
pmichaud: Such things will be really useful to have to hand when it comes to working on the optimizer.
flussence PerlJam: I'm on a netbook :) 20:32
hm, nom perl6 -e 'for (1..10000) {}' takes 34 seconds on this and master takes 11 seconds on my server (not quite the same, but it's still an Atom CPU...) 20:35
jnthn flussence: With the latest patch from pmichaud++?
tadzik yeah, that's related to Range iteration, not Range creation
sorear flussence: do not use "for" 20:36
tadzik see my doubts :)
sorear flussence: try perl6 -e '(1..10000).reify(*)'
flussence I'm just surprised it goes way off in the other direction compared to those numbers tadzik got
tadzik no, it doesn't
flussence oh,
tadzik oh, it does
wait, I dunno anymore 20:37
Whatever! I don't care!
tadzik pretends he's learning for the exam again
flussence but still 11 -> 34 is a bit bigger than 8 -> 10 *shrug*
ooh, .reify is fast
tadzik my comparison was nom-nom, yours is nom-master
flussence oh, right 20:38
jnthn pmichaud: API for contextual looks good. Only cooler thing could be if it took a slurpy hash 20:41
pmichaud: So we could do :Ii(...), :Ss(...)
pmichaud: I think I'd prefer that, if it can be made to work. 20:42
nqp: foo(a => 1)
p6eval nqp: OUTPUT«Could not find sub foo␤current instr.: '_block1000' pc 31 ((file unknown):32)␤»
jnthn Ah, even nicer with that notation.
Ii => ..., Ss => ...
dalek kudo/nom: 4cbf8cb | jnthn++ | NOMMAP.markdown:
Comment on a nommap item. Also, it's not 2001. :-)
pmichaud jnthn: I'm not sure it can be made to work well with pair notation. 20:45
that was my first attempt, yes.
but some of the signature characters aren't alphanumeric
20:46 Sarten-X left
lichtkind thou: ping 20:46
thou pong
lichtkind thou: seen my question? 20:47
pmichaud I guess we could switch them to alphameric equivs if needed
jnthn: the original P6 code is in the else block 20:48
(for the range optimization)
jnthn pmichaud: ah, yes :)
pmichaud I can put a comment that it's the unoptimized version
I guess I can also reverse the test
jnthn pmichaud: Sure, I'll probably go trawling for Q:PIR at some point when working on the optimizer. 20:49
pmichaud okay
I'm doubtful that particular one will go away anytime soon
the difference between 7.5sec and 0.02sec is just too great
(7.5sec is what I get after optimizing ++/--) 20:50
my next set of optimizations are going to eliminate some O(n**2) behavior in lists :)
any opinions +/- on using opcodes for performance optimizations? ;-)
jnthn I don't have a problem with custom ops. 20:51
pmichaud okay, I'm about to add another
20:51 aindilis left 20:52 aindilis joined
pmichaud this one is converting an operation currently taking 5.3sec into one that takes 0.003sec :-) 20:53
(and it's very commonly used) 20:54
jnthn is curious which one :)
pmichaud it's used in .iterator and .munch -- the repeated shifting of elements from an RPA 20:55
that's an O(n**2) operation in Parrot.
I'm making it linear.
jnthn \o/
pmichaud and then I'll be able to use it to avoid a ton of other O(n) operations that we currently do :)
i.e, making O(20n) into about O(2n) 20:56
20:56 Sarten-X joined 21:01 wamba left
tadzik wouldn't it be good to optimize it in Parrot instead of reimplementing it? 21:04
unless we don't want that directly 21:05
pmichaud it's not a reimplementation, exactly, it's an additional operation 21:06
tadzik I see
pmichaud it just turns out it has higher-level knowledge that enables it to be smarter about it than using the parrot primitives repeatedly 21:07
I'm working on a slightly different approach that might not need the opcode at all, though. we'll see.
lichtkind what is .munch? 21:15
tadzik it's like .take methings 21:18
rakudo: (1, 2, 3, 4).munch(2) 21:19
p6eval rakudo 248244: OUTPUT«Method 'munch' not found for invocant of class 'Parcel'␤ in main program body at line 22:/tmp/fkiOR2YSdM␤»
tadzik pff
rakudo: (1..4).munch(2)
p6eval rakudo 248244: OUTPUT«Method 'munch' not found for invocant of class 'Range'␤ in main program body at line 22:/tmp/vTcO2Bfdwd␤»
tadzik aroo
21:24 spq1 left 21:29 dukeleto left, dukeleto joined, simcop2387 left 21:31 simcop2387 joined
pmichaud rakudo uses a somewhat different API than nom 21:34
21:34 sftp left 21:35 sftp joined
lichtkind tadzik: thanks nevertheless :) 21:36
rakudo: (1..4).take(2) 21:37
p6eval rakudo 248244: OUTPUT«Method 'take' not found for invocant of class 'Range'␤ in main program body at line 22:/tmp/SDGCRT1o2u␤»
lichtkind rakudo: (1,2,3,4).take(2)
p6eval rakudo 248244: OUTPUT«Method 'take' not found for invocant of class 'Parcel'␤ in main program body at line 22:/tmp/a9TftOVbh7␤»
lichtkind :)
std: (1,2,3,4).take(2)
p6eval std 37a0cdd: OUTPUT«ok 00:01 121m␤»
lichtkind std: (1,2,3,4).munch(2)
p6eval std 37a0cdd: OUTPUT«ok 00:01 121m␤»
21:38 Mowah left, impious joined 21:57 ilogger2 joined, ChanServ sets mode: +v ilogger2, dukeleto joined, Tanktalus joined, PacoLinux joined 21:59 charsbar__ joined 22:00 whiteknight joined 22:07 DarthGandalf joined, jrockway joined 22:10 chitragupt joined 22:13 frettled joined
pmichaud jnthn: ping 22:31
jnthn pmichaud: pong 22:32
pmichaud I have an patch you might want to play with a bit for performance (more)
gist.github.com/1036768
this patch changes the ListIter so that instead of repeatedly shifting from $!rest, it maintains an $rest_pos pointer that keeps track of the element of $!rest that is currently being processed, and then does one big shift at the end (via splice) 22:33
jnthn pmichaud: Iterable.ACCEPTS($x) 22:34
pir::type_check__IPP($x, Iterable)
pmichaud I can change that, but that's not the interesting part
jnthn pmichaud: Similar for Parcel.ACCEPTS($x)
pmichaud sure thing
jnthn Whatever.ACCEPTS($n) too
Well, they're in the while loop 22:35
pmichaud with this patch in place, the benchmark at gist.github.com/1036772 runs about 10% slower than before
jnthn So they save a method invocation per call frame.
pmichaud in other words, repeatedly shifting the RPA is faster than maintaining an index pointer
jnthn while pir::islt__III($rest_pos, pir::elements($!rest)) 22:36
I think that falls into the coercion vs unbox trap.
pmichaud coercions are *that* expensive? 22:37
I can fix and find out... just a sec
jnthn Well, it goes through the Parrot v-table. While the lookup over the code that overrides it is fast, that bit of code just calls .Int
And then unboxes that 22:38
pmichaud oh, it's resulting in a method call?
jnthn Yes
That's why there's explicit unbox instructions.
pmichaud is there a way that vtable method could short-circuit if it knew it already had a int repr available?
jnthn Well, the repr is P6opaque, just one that knows how to unbox as an int. 22:39
We *could* maybe do something like that.
pmichaud building, testing with explicit unboxes
jnthn But I fear it's magic that'll come back to hurt us.
My separation of unboxing vs coercion was very deliberate.
sorear unboxing and coercion are different things but it completely makes sense to have a "coerce and unbox" vtable 22:40
pmichaud it's going to make the code really ugly if we're sprinkling pir::repr_unbox_int__IP all over the place 22:41
yeah, seems to me it'd be okay for the get_integer_native vtable to be smart about unboxing things it can determine to be int reprs
jnthn They're *not* int reprs...
It doesn't work like that. 22:42
pmichaud that's not what I meant.
I meant things that it can determine are ints
jnthn Yes, I could make it "just work". No, I'm not sure it's a good idea in the long run.
pmichaud okay, I'm not going to push it yet.
jnthn sorear: Depends what we decide the v-tables should really be doing. 22:43
pmichaud okay, explicitly unboxing the repr makes the difference go down from ~10% to 1.6%
jnthn sorear: If we put this in, we deny langauges a chance to intercept int coercion on any type that can just expand itself to a native int. 22:44
pmichaud s/repr/int/
jnthn gah
s/expand/unbox/
sorear I recommend adding a function (NOT an op) to Rakudo's C code that implements coercion+unboxing for Rakudo's Int type
jnthn sorear: ?
sorear then connect the .Int method to a NCI (rather than Sub) PMC
pmichaud jnthn: I think you're looking to have the vtable do more than what I'm suggesting 22:45
sorear then make the vtable override logic know how to call NCIs without runops
(ideally, a very direct call if the signatures match up)
jnthn sorear: That sounds nasty and maybe a premature opt right now. 22:47
pmichaud I'm not saying the vtable should shortcut for just any type that can unbox to a native int, I'm saying that we have a flag or something for individual types that says it does so for those.
jnthn Also, whose .Int method?
sorear Int's .Int
jnthn pmichaud: Ah, I see
pmichaud i.e., it short-circuits for an Int, but does the call to .Int for everything else.
(and I can even go so far as to say *only* an Int, and not its derived types) 22:48
is repr_unbox_int currently polymorphic?
sorear I endorse pmichaud's proposal too.
jnthn pmichaud: On the repr, yes.
pmichaud i.e, if I do repr_unbox_int on something that isn't an Int, does it still work?
jnthn pmichaud: Only if it has a repr that knows how to unbox. 22:49
pmichaud well, like a Num
jnthn pmichaud: If you don't know that you have a type that knows how do, you shouldn't be using that op.
No, a Num needs repr_unbox_num
pmichaud right
that's kind of my point
the only place I'd be doing explicit unboxing is when I know I have Int
and if I know that already, it'd be nice if the vtable could detect it and do the unbox for me in that particular case 22:50
jnthn Well, it's not to do with having an Int
repr_unbox_int doesn't care what type you have, it just cares that the underlying representation understands unboxing to an Int.
That op is 6model primitive level, not Rakudo level. 22:51
pmichaud yes, I get that.
jnthn s/Int/int/
pmichaud when I set up the Int class in Rakudo, is there a way I can tell 6model "and it's okay for the get_integer vtable to directly grab my native int instead of going through the .Int method that everyone else has to use"? 22:52
jnthn I just have a bad feeling about making some v-table overrides specialer than others, in order to deal with something that the PAST::Contextual node will deal with in the literal cases, and where we can generally be sure what we have and use repr_unbox_int in the other cases.
Not unless we implement such a primitive in 6model, no.
We could put it in. I'm just not sure it'll pull its weight. 22:53
pmichaud I think it would make the code more portable and readable
jnthn I agree with the readability argument, and don't get the portability one. :) 22:54
pmichaud usable by other p6 implementors
in some sense I'm starting to see our core.setting as a likely reference implementation for Perl 6 libraries 22:55
jnthn I'd kinda expect other p6 implementors to have an unbox op. ;)
pmichaud I'd kinda expect unboxing to be handled at a slightly lower level :)(
and I'm hoping that these ops become nqp:: ops
I guess at that level they become nqp::unbox_int, hopefully. 22:56
but even better would be nqp::islt($a, nqp::elements($array)) where I don't have to worry about unboxing $a 22:57
as I said, I won't push it now (more)
sorear do you expect to have a core.setting forever?
pmichaud a lot of this also resolves if I can declare $rest_pos as my int $rest_pos and it stays native throughout 22:58
jnthn Right :)
Which is another real solution :)
Essentially though, it looks like adding what you're asking for is probably adding a set of flags on the S-table, if it's per type.
Which means that every s-table would get a word bigger or so. No biggie but I do worry a lot about keeping the core small. :) 22:59
pmichaud right
you sound disinclined to make the change and I'm happy to go with your instinct on this one
it'll make the code uglier for a while, but I suppose we can live with that. I am also looking at hackability by others, though. 23:00
jnthn Yes, and the ugly can go away when we do native types.
So it's just an incentive for us to do those sooner. ;-)
pmichaud any idea of eta on that?
jnthn Post-nom 23:01
pmichaud yeah, I was kind of afraid of that :)
jnthn Well, maybe we can pull it pre-nom if you really want.
pmichaud I'd like cleaner code somehow pre-nom. :)
and reasonably fast
I can do clean but slow or ugly and fast
and I'm not sure which one I want to emphasize right now 23:02
jnthn pmichaud: With PAST::Contextual I may be in a better place to take a shot at some initial native type support. 23:03
pmichaud I'm going to have a PAST::Contextual tonight.
jnthn OK
pmichaud I still can't decide re hash vs other interface
the hash-based interface kind of flies-in-the-face of the way other attributes are handled in PAST 23:04
jnthn Yeah, true :)
But it looks prettier ;)
pmichaud I was thinking we wanted to get rid of using a hash to store the attributes in favor of actual attributes
but we can't really do that with 'IiNn' => .... 23:05
jnthn I'm not sure I see the connection... :)
class PAST::Contextual { has %!mappings; }
:)
pmichaud yes, and we muck with .new to do something different than the standard build
jnthn Yes, true
pmichaud it's the .new that is radically different.
jnthn aye
Maybe it's too much effort for a little cuteness
Laying the code out well can get about the same effect anyway. 23:06
pmichaud I also don't quite like having the string nodes in the middle of the children either, so it does go both ways :-)
jnthn To me, I'll just be exceptionally happy to have such a node at all, whatever the interface. ;-)
pmichaud and having a .add_mapping on the node seems really icky
I'd really want to be able to specify most everything in the .new( ) call. 23:07
jnthn yeah
nom: Q:PIR { .lex '$x', $P0 }; say 1
p6eval nom: OUTPUT«1␤»
jnthn nom: Q:PIR { .lex '$x', $I0 }; say 1
p6eval nom: OUTPUT«error:imcc:Cannot use I register with .lex␤ in file '(file unknown)' line 69␤»
jnthn Dåligt.
pmichaud yes, I suspect native lexicals involves (1) updating parrot support them, or (2) abandoning .lex/find_lex/store_lex in favor of our own lexical pad management. 23:08
I'm fine with either. :)
sorear *mumble* find_lex_fast 23:09
pmichaud I have a slight bias towards the latter, since we may need that anyway for other VMs
tadzik find_lex_fast_and_correct
pmichaud jnthn: okay, that answered my questions. thanks. 23:11
23:18 cooper joined 23:38 daemon joined 23:39 daniel-s joined 23:41 aindilis joined 23:42 pjcj joined 23:44 thou joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!