»ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by Juerd on 28 August 2009.
01:16 orafu left 01:49 simcop2387 is now known as cubert, cubert is now known as simcop2387 06:26 ilbot2 joined
moderator »ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: | irclog: irc.pugscode.org/ | UTF-8 is our friend!
06:28 zloyrusskiy joined, szabgab joined 06:37 viklund joined 06:40 viklund joined 06:41 viklund joined 06:42 viklund joined
moritz_ \\o/ 06:44
sjohnson hi 06:48
06:54 mberends joined 07:06 mariuz joined
moritz_ jnthn: make spectest reports: 07:08
t/spec/S06-signature/slurpy-params.rakudo 07:09
Failed tests: 49, 59
TODO passed: 48, 56
07:15 rfordinal joined 07:35 hanekomu joined 07:40 riffraff joined, xenoterracide left 07:41 xenoterracide joined
jnthn oh morning 07:46
moritz_: heh, lose two, win two...
Matt-W morning 07:47
07:48 msmatsko joined 07:50 msmatsko joined 07:51 msmatsko_ joined 07:54 msmatsko_ joined
sjohnson hi 07:57
08:08 mtve joined 08:18 payload joined
jnthn std: sub foo(Int ::T $x) { } 08:24
p6eval std 28649: OUTPUT«[31m===[0mSORRY![31m===[0m␤Multiple prefix constraints not yet supported at /tmp/X2Aq0iVTDC line 1:␤------> [32msub foo(Int ::T [33m⏏[31m$x) { }[0m␤ expecting type_constraint␤FAILED 00:01 98m␤»
jnthn Hmm. Since ::T is a type capture, not a constraint, here, I think this is probably bogus. OTOH, Rakudo matches STD too at the moment...
moritz_ I think the error message makes sense, somehow 08:28
but not quite sure
08:31 nbrown joined
jnthn I'm leaving Rakudo as is for now, but I think that may want to change. 08:35
08:38 alexn_org joined 08:55 rfordinal left
jnthn rakudo: for &infix:<...>.candidates { say .signature.perl } 09:36
p6eval rakudo 8d6337: OUTPUT«:(@lhs, @rhs)␤:(Any $lhs, @rhs)␤:(Any $lhs, Code $generator)␤:(@lhs, Code $generator, Any :$limit?)␤:(Any $lhs, Any $rhs where all({ ... }))␤»
Matt-W wooo 09:37
09:37 Whiteknight joined
jnthn Matt-W: Yeah, the difference between that and my local output I think pinpoints the bug... 09:38
Matt-W :)
jnthn has just managed to change a bunch of code he hated to be something he can follow more easily, as well as avoiding loads of creating silly unrequired junctions. 09:39
09:39 Ryan52 joined
jnthn Now I just need to fix the bugs... 09:39
Between this and yesterday's change, even though they're just initial refactors, I'm seeing roughly 10% shaved off startup time.
Matt-W ooooh 09:42
jnthn++
More understandable AND faster 09:43
jnthn Well
Matt-W Wish that could happen more often
jnthn Basically in a sig like :(Int $x), we really, really don't need to build a junction containing Int, only to pull it out again later on and decide we didn't need to the junction anyway.
(it made the signature binder a tad simpler, but not enough to justify the waste) 09:44
09:44 |Ryan52 joined
Matt-W No you probably don't 09:48
Was that to handle the possibility of it being a junctive type in the signature
I suppose an all() or any() with one element in it matches the same as the lone element, so it kind of makes sense
jnthn Well, in something like :(Int $x where { $x < 42 })
Then we would make an all(Int, {$x < 42}) 09:49
Matt-W oh
okay I hadn't considered that
jnthn This is useful for the single dispatcher, since it has one thing to call ACCEPTS on.
Matt-W but not so much for the multi dispatcher?
jnthn But the multi-dispatcher needs the nominal type and the constraint type separate.
Matt-W because it needs to sort by narrowness 09:50
jnthn Right.
So it was taking the junction apart to find the nominal type.
But in reality it meant we were building loads of all(Int) style junctions.
Only to throw them away alter
Well, not even that actually
Because we kept hold of the extracted type (which is fine, it's just a pointer to a proto) and also the junction. 09:51
Matt-W You still don't want to be building all these objects you don't need
jnthn Now we never create that junction in the first place - the compiler keeps the two separated out.
And only creates a junction _if_ there are any constraint types.
Matt-W So how does it handle a junctive type?
09:51 eMaX joined
Matt-W Just out of curiosity 09:51
jnthn Junctive types? 09:52
Note those don't appear on the LHS anyway.
So they only apply to constraint types.
Basically though, now when we add the paramter to the sig, we pass along the Int and an all({ $x < 42 })
If we know there's one constraint, we can likely drop the junction too. 09:53
And if it's just :(Int $x) we pass along Int and a null PMC.
Matt-W nice
jnthn Yeah
Matt-W so what if it was :(Int|Str $x)
jnthn No point throwing away stuff we already know.
:(Int|Str $x) is invalid in Perl 6.0.0. 09:54
Matt-W Really?
Oh
jnthn Yes.
std: sub foo (Int|Str $x) { }
p6eval std 28649: OUTPUT«[31m===[0mSORRY![31m===[0m␤Unable to parse signature; couldn't find final ')' at /tmp/X9N8mWFcJ8 line 1:␤------> [32msub foo (Int[33m⏏[31m|Str $x) { }[0m␤ expecting any of:␤ constraint␤ param_sep␤ parameter␤ trait␤ type_constraint␤
..whitespace␤FAILED 00:02 99m␤»
jnthn std: sub foo ($x where Int|Str) { }
p6eval std 28649: OUTPUT«ok 00:01 98m␤» 09:55
Matt-W Oh so you can get the same effect using where
jnthn Yes, but note that (other than "I have a constraint") these types don't play into candidate sorting in a multi.
(that is, it's tighter than sub foo($x) { } but only because of the constraint) 09:56
Matt-W so the interaction with other constrained candidates might be a little different than expected?
jnthn Depends what you expect. ;-) 09:57
Matt-W To be honest I'm not sure I'll actually end wanting to do it very much, but I've always had it in my head as one of the things we can do
Along with things like has Int|Str @.things
jnthn Well, at one time it was proposed in the spec.
Matt-W But I guess I'm out of date
jnthn But nailing down the semantics of such things gets a bit fun. 09:58
Especially with relation to candidate sorting.
We may do so in the future, and the syntax is reserved (e.g. and error now).
Matt-W But right now there are other things to worry about 09:59
jnthn Aye.
Much more important things.
10:26 NorwayGeek joined 10:46 xenoterracide joined, allbery_b left 11:16 patspam1 joined
nothingmuch @tell ruoso SMOP's IR can be fast because it has a direct correspondence to typed lisp and that can be made fast, that doesn't mean it won't require a real compiler ;-) 11:31
lambdabot Consider it noted.
11:33 mikehh joined
jnthn is very confused 11:35
Why does git log show a commit I made just fine, but "git push origin master" doesn't commit it?
nothingmuch git log --decorate origin/master..HEAD 11:36
jnthn (says everything up to date)
oh hmm
git branch -a shows "* (no branch)"
nothingmuch so your head is floating
jnthn nothingmuch: that command shows the commit I made
nothingmuch: Ah. :-/ 11:37
nothingmuch: What is one meant to do about that?
nothingmuch git rev-parse HEAD
get the sha1 of it
git checkout master
git merge that sha1
(or git merge HEAD@{1} -- the value of HEAD before last... see git help reflog if you want to learn more)
jnthn nothingmuch++ # thanks, that helped 11:38
nothingmuch i find gitx/gitk to be very helpful
git log --decorate --graph is the same but harder to view 11:39
but the key option to pass to any of these is --all
also git log --pretty=oneline --graph --decorate --all
jnthn Nice to know. Thanks :-) 11:40
dalek kudo: cf8884d | jonathan++ | src/ (3 files):
Keep the main nominal type and constraint type(s) separated out at parse time. This simplifies signature construction and also avoids creating a bunch of one-elements junctions that we don't really need. Between this and yesterday's refactor, we shave about 10% or so off Rakudo's startup time.
 11:43
nothingmuch btw the reason you were on a floating head is that either you did git checkout origin/foo or git checkout 1234 or you are in the middle of a rebase 11:44
jnthn nothingmuch: Yes, I had done the second of those...I probably after looking back at a previous revision should have done git checkout master rather than git checkout <latest sha1 here>.
nothingmuch yep, otherwise it creates a linked list of commits but updates no pointers but HEAD 11:45
moritz_ git is a beast if you don't grok the graph + pointers structure 11:46
nothingmuch when you do a checkout of a named local branch then HEAD is a symbolic reference to that branch, so any commit you make updates that branch, instead of HEAD
jnthn Aha. 11:51
jnthn is still working on grokking git. 11:52
Time to do some non-Rakudo tasks...more Rakudo hacking later. :-)
nothingmuch jnthn: i like the 'git for computer scientists' doc 11:53
it explains how the graph model works
everything else in git makes sense once that does 11:54
so assumptions generally lead to the right place
(e.g. "blah should be possible" or "git probably does it by ..."
moritz_ there's also "git from the bottom up"
nothingmuch yeah, same material but in much higher detail
blog.woobling.org/2009/05/become-git-junkie.html 11:55
12:01 masak joined
jnthn lolitsmasak 12:02
moritz_ spetests rakudo on 4 cores
masak I'm out of sync with the day/night cycle. :/
phenny masak: 00:43Z <carlin> tell masak (re the 'use' bug) that's alright, the original ticket doesn't mention 'is export' as the cause so it's good to get to the bottom of that
masak carlin: oh, good point. 12:03
jnthn masak: Oh, it's itneded to be sync'd with?
*intended
masak that's a good question. 12:04
I don't really have any hard reason to make it sync right now.
12:11 takadonet joined
takadonet morning all 12:11
moritz_ morning' takadonet 12:12
masak o/
takadonet how are you moritz_?
masak jnthn: in transforming :(Int $x where { $x < 42 }) to all(Int, {$x < 42}), don't you throw away important ordering information?
moritz_ takadonet: a bit tired, but all in all just fine
masak jnthn: say I have an object with a custom-made '<' operator which blows up the universe. 12:13
moritz_ the all() junction should really be an also() junction
which is an all()-junction but with guarantued ordering
s/ordering/order of execution/
jnthn Ah, probably, yes, though for now (1) our all's are ordered and (2) we don't have also yet. 12:14
masak or we just use an array like everyone else.
jnthn masak: Anyway, we don't transform it to that now.
masak ok.
jnthn The all only has one element now.
The Int out front is handled separately.
That was the point of the changes. :-)
moritz_ rakudo: say 1 12:15
p6eval rakudo cf8884: OUTPUT«1␤»
moritz_ that's the newest version
masak jnthn++ 12:16
moritz_ rakudo: class A { method foo { 3 } }; multi sub f(A $x where { .foo }) { }; f(3) 12:17
p6eval rakudo cf8884: OUTPUT«No applicable candidates found to dispatch to for 'f'␤in Main (/tmp/mjSbc83YnM:0)␤»
moritz_ that used to complain that it can't call method .foo on an Int, iirc
rakudo: class A { method foo { 3 } }; multi sub f(A $x where { .foo }) { }; f(A.new)
p6eval rakudo cf8884: ( no output )
moritz_ rakudo++
jnthn++
jnthn oh 12:18
I didn't mena to fix any bugs...
:-)
moritz_ spectest run on quadcore finished in 14m25.688s. \\o/
12:20 vigith joined, vigith left
masak wow. that parallelism thing really does pay off. 12:20
takadonet !!!
should try it on my machine.... 12:21
colomon now if there were just a quadcore MBP...
Matt-W I need to remember that
I have a quadcore box... 12:22
although I usually do rakudo stuff on my dualcore
colomon Matt-W: same here.
takadonet going to try it on a dual quadcore right now!
Matt-W because the quadcore's usually in windows 12:24
but the dualcore laptop only has linux
pmichaud good morning, #perl6 12:25
moritz_ I think the parallel testing thing doesn't work on windows
at least jnthn reported that it's not faster than than a serial one
good morning pmichaud
masak morning, pmichaud
pmichaud parallel testing gives me about a 40% (wall clock) improvement 12:26
(dual core)
spectesting is much less painful lately; I can get a spectest done in about 15 mins on my notebook
moritz_ rakudo: say (50*60 + 8) / (14 * 60 + 26) 12:27
slavik2 <?{$0 < 100}> ?
p6eval rakudo cf8884: OUTPUT«3.47344110854503␤»
slavik2 rakudo: say 2^64
p6eval rakudo cf8884: TIMED_OUT
slavik2 slow :(
perl6: say 2^64 12:28
Matt-W The very thought of doing Rakudo dev work on Windows fills me with horror. It's bad enough doing it at work...
moritz_ pmichaud: then you notebook is about twice as fast as mine (also a dual core)
p6eval sprixel 28649: OUTPUT«Sprixel Error: /_Junctive_or_/ not yet implemented; apologies from the crew!␤»
..elf 28649: OUTPUT«66␤»
..pugs: OUTPUT«one(VInt 2,VInt 64)␤»
..rakudo cf8884: TIMED_OUT
pmichaud I have a very speedy notebook, yes.
jnthn Matt-W: Indeed, it's be impossible for anyone to work productively on Rakudo on Windows.
pmichaud ...and jnthn likes doing the impossible. :) 12:29
Matt-W jnthn does the impossible on a regular basis
It's just me
jnthn ;-)
takadonet heh
Matt-W I learned to code on a Linux box (well, a BBC Micro, then a Linux box) and I just don't feel that Windows offers me any good options
slavik2 aww ... still no bignum in parrot?
pmichaud I'm soooo happy about the nqp-rx progress last night... I might be able to have a self-hosting p6 regex parser before the day is out
moritz_ woot
slavik2 pmichaud: sweet, with assertions? ^^ 12:30
pmichaud slavik2: probably not today for assertions
slavik2 tomorrow, I can wait till tomorrow
moritz_ :-)
pmichaud at least, not p6-like assertions
Matt-W pmichaud: Wow! Well done
pmichaud pir assertions become much more possible
jnthn pmichaud: Ooh, nice work. :-)
slavik2 pmichaud: how can I embed those into perl6 code? 12:31
pmichaud slavik2: ...regexes?
jnthn pmichaud: Think we'll switch to that by the next Rakudo release?
slavik2 yes
pmichaud slavik2: um, the normal way to put a regex into perl6 code is to use / ... / :)
jnthn: I don't know if we'll be able to switch by next release. The switch will have a huge impact. 12:32
slavik2 token byte { [\\d+] ... } # <?{0 <= $0 <=255}>
masak pmichaud: src/Regex/P6Regex/Grammar.pm line 19: \\w [ \\w+! <?before \\w> ]? -- could you give an example of when the thing within the brackets would match?
pmichaud slavik2: oh. when we're done (many days hence) it'd just be like you wrote
slavik2 pmichaud: when you say many ... is that more than 365? 12:33
pmichaud masak: sure... for "abcdef" the brackets would match "bcde"
masak oh, ah, because of backtracking. gotcha.
12:33 NorwayGeek joined
moritz_ what does the ! mean in a regex? 12:33
12:33 synth joined
moritz_ confused 12:33
masak moritz_: it's the default mode. 12:34
pmichaud that expression matches a sequence of word characters except for the last one
masak greedy.
pmichaud moritz_: ! forces greedy backtracking
12:34 rblasch joined
masak moritz_: I didn't know about it either until I started reading S05 with a fine comb. :) 12:34
slavik2 so wordchar, followed by as many wordchars but leaving out the last one
pmichaud slavik2: exactly
masak moritz_: it's needed here because we're in a token, which turns off greed and turns on ratcheting.
moritz_ ah, if it's the default, it might explain why I never needed it explicitly :-)
Matt-W I still get confused about tokens and rules and regexps 12:35
pmichaud the purpose of that expression is to optimize a regex like / foobar* / a bit
slavik2 also, regex { a } # matches " a " not "a" ... is this the intended behavior?
pmichaud instead of converting that to / 'f' 'o' 'o' 'b' 'a' 'r'* /
slavik2 don't regexes do :x mode by default?
pmichaud it converts it to / 'fooba' 'r'* /
moritz_ they do
slavik2 or /x in perl5
moritz_ rakudo: say 'a' ~~ / ^ a $ / 12:36
p6eval rakudo cf8884: OUTPUT«a␤»
moritz_ works, no?
slavik2 hmm
masak pmichaud: ah. you answered my next question ("why?") without my having to ask it. :)
12:36 payload joined
moritz_ note that ' a ' ~~ /a/ because it's not anchored 12:36
slavik2 rakudo: regex blah { a }; say 'a' ~~ /<blah>/;
p6eval rakudo cf8884: OUTPUT«a␤»
slavik2 rakudo: rule blah { a }; say 'a' ~~ /<blah>/; 12:37
p6eval rakudo cf8884: OUTPUT«a␤»
moritz_ pmichaud: I noticed there are no tests in nqp-rx - not yet written? or forgotten to commit?
pmichaud moritz_: nyi
moritz_ ok
slavik2 hmm, I think one of them did not do /x
pmichaud I've thought about testing individual components, but it's a bit tricky at the moment
also, I'd like the tests to all be written in nqp 12:38
anyway, lack of tests is not to be taken as an indication that tests aren't important :)
very soon I'll be importing the entire pge test suite :) 12:39
Juerd If anything, lack of tests will usually quickly show that they are in fact important
Matt-W Juerd: well said 12:40
Matt-W is hugely impressed with pmichaud's progress
12:48 rblasch joined 12:49 rblasch_ joined
jnthn pmichaud: (switch) OK. I'm thinking that at a minimum we'll have switched to the new signature representation by the next release, and very possibly the new binder. 13:03
pmichaud ..."new binder" == "new signature binder"?
jnthn pmichaud: Indeed.
pmichaud OK.
next release is +15 days, fwiw 13:04
jnthn How many days before the release would you want to see something like that land in master?
pmichaud I suspect the grammar changes will have to take place in a branch. That's going to be one ugly branch.
jnthn I'm thinking if I can have it landed a week before release, it'll be fine? 13:05
pmichaud I'm fine with it at any point before the release
jnthn (and yes, I know, that's ambitious...)
pmichaud rakudo doesn't (yet) have parrot's weird timeframes
jnthn OK, I'd like some buffer to fix any horrors the test suite somehow fails to identify.
pmichaud sure. check with the release manager (PerlJam) to see how much lead time he'd like to see 13:06
moritz_ jnthn: so you don't depend on the pcc-refactoring to land before this step?
jnthn moritz_: Ssshhh.
:-)
13:06 PerlJam joined
moritz_ shuts up :-) 13:06
PerlJam greetings!
pmichaud wonders if PerlJam has some special indicator for when his nick gets mentioned
(while he's "off-chan") 13:07
moritz_ maybe he has a client that parses the HTML irc logs :-)
PerlJam Why? What were y'all saying about me?
pmichaud 13:06 <pmichaud> sure. check with the release manager (PerlJam) to see how much lead time he'd like to see
in response to jnthn++ talking about putting a major refactor in place :) 13:08
13:05 <pmichaud> I'm fine with it at any point before the release
jnthn PerlJam: See irclog, but since you're release manager this month: if I'm going to land a major refactor, how long before the release would you like to see it land?
pmichaud as long as spectests pass, I'm happy.
PerlJam jnthn: sooner is better, but like pm said, as long as it's before the release.
:)
jnthn OK.
13:09 rblasch joined
jnthn I'll see how things go. 13:09
pmichaud wfm
jnthn I don't know how painful it's going to be yet.
PerlJam jnthn: I've noticed the last few releases that you seem to do a flurry of activity between the parrot release and the rakudo release. Are the odds good that you'll do that again? :)
moritz_ "just like any other task deep down in the parrot's guts"? 13:10
jnthn PerlJam: I'd want to land this branch before the Parrot release
The flurry is usually mostly bug fixes to try and get a higher quality release.
PerlJam jnthn: good deal. this is the signature refactor stuff you were talking about the other day?
jnthn PerlJam: Yes. 13:11
PerlJam excellent
jnthn The initial pre-refactors have already shaved about 10% off startup time. :-)
pmichaud yay
jnthn pmichaud: We construct a lot less pointless junctions now. :-) 13:12
pmichaud yes, I noticed that.
solves a couple of other problems as well.
13:12 ruoso joined
Matt-W jnthn: fewer 13:14
:P
moritz_ grammar nazi :-)
pmichaud Matt-W: ...and the ones that we do construct are "less pointless" than they were before :)
moritz_ uhm, the ones we construct now have never been pointless 13:15
Matt-W no, the ones that are still there are just as pointless as they ever weren't
moritz_: and yes, although unfortunately I fail to use grammar correctly 100% of the time myself
13:15 felipe left
jnthn Sorry, I'll try and make less grammar errors. 13:16
;-)
Matt-W throws up his hands in despair 13:17
moritz_ jnthn: don't, then we wouldn't have nice things to fret about
13:17 PerlJam joined
PerlJam hrm 13:18
13:19 [bjoern] joined
[bjoern] Shouldn't this work? 13:19
rakudo: say map &infix:<+>.assuming(3), (1,2,3)
p6eval rakudo cf8884: OUTPUT«No applicable candidates found to dispatch to for 'map'␤in sub map (src/gen_setting.pm:328)␤called from Main (/tmp/D63TBV1Qi2:0)␤»
jnthn rakudo: say &infix:<+>.assuming(3).WHAT
p6eval rakudo cf8884: OUTPUT«Code()␤»
jnthn rakudo: say &infix:<+>.assuming(3).PARROT
p6eval rakudo cf8884: OUTPUT«Sub␤»
jnthn aww 13:20
[bjoern]: yes
Matt-W Perl6MultiSub is what we wanted to see there, I take it?
jnthn Matt-W: No, just that the sub was re-blessed into a Perl 6 type.
moritz_ no
you can't reduce with an unary function
Matt-W ah, so Perl6<something>
moritz_ oh, wait 13:21
jnthn [bjoern]: anyway, that's a Rakudo bug, it appears
moritz_ you can map, yes
moritz_ confused
Matt-W rakudo: (1,2,3).map: &infix:<+>.assuming(3)
p6eval rakudo cf8884: OUTPUT«No applicable candidates found to dispatch to for 'map'␤in Main (/tmp/V2nKsZCyTx:0)␤»
Matt-W thought so
pmichaud rakudo: say &infix:<+>.assuming(3).signature 13:22
p6eval rakudo cf8884: OUTPUT«No signature found␤␤»
jnthn rakudo: say &infix:<+>.signature
p6eval rakudo cf8884: OUTPUT«No signature found␤␤» 13:23
jnthn ah, .signature on a multi.
pmichaud we don't yet do .signature on multis
jnthn I think it's meant to be a junction of 'em all.
forget which type of junction...will have to chekc spec.
Matt-W guesses 'any'
jnthn That'd be my guess too 13:24
Matt-W 'all' would be a bit odd
pmichaud I was rooting for 'none' :-P
Matt-W 'none' would be an interesting concept 13:25
here's a function with none of the following signatures
so how do you call it
PerlJam mentions the "one" junction so that the list is complete.
[bjoern] hehe 13:26
Matt-W 'one' would make sense in the case of you only call one of them at once... except when you don't
PerlJam oh crap ... I have to come up with a name for the Rakudo release. Any suggestions? 13:29
pmichaud there's a list in the release guide
PerlJam or, let me rephrase, any suggestions along with reason(s) why that PM group? 13:30
pmichaud the p6 folks here in the north dallas area are about ready to suggest "Dallas". But we probably need/want to create a "Dallas.pm" first. And we should be careful not to offend the "DFW.pm" organizers 13:31
moritz_ PerlJam: you could surely use the organizers of YAPC::Asia or YAPC::EU
I also added a link to one of the groups in release_guide.pod
pmichaud although, given the fact that none of us here actually live in "Dallas" itself, nor do we meet there, perhaps we should create an "Allen.pm" or "Plano.pm" instead :) 13:32
moritz_ and I'd like to encourage others to do that too if the add pm groups there
PerlJam moritz_: ThousandOaks?
moritz_ PerlJam: rright, that one 13:33
PerlJam (any PM group doing perl6 hackathons certianly gets my favor :)
jnthn I planned to add Seoul.pm to the release name ideas list.
(Seoul.pm)++
PerlJam It's there now.
jnthn \\o/ 13:34
moritz_ jnthn: any good reason wich fits in one paragraph?
pmichaud I think that Seoul.pm was suggested to me earlier in the year 13:36
I don't think I have anything written about it
we could also invite suggestions from the Padre folks, since they're doing a fair bit of rakudo and p6 integration 13:37
moritz_ aye
pmichaud that might get us a middle-east and/or australian locatoin 13:38
*location
we should probably get szabgab and/or Alias to suggest names for our list :) 13:39
moritz_ I can ask in #padre
pmichaud lurks to see what gets said :) 13:40
PerlJam #padre is quiet this morning. 13:41
pmichaud PerlJam: anyway, you have two weeks to decide. If we get to the release date and still don't have an obvious candidate, I suggest either Seoul or ThousandOaks
both of those are excellent candidates
jnthn moritz_: I gave a Perl 6 talk there recently. :-) 13:42
PerlJam barring other suggestions, I'm going with ThousandOaks because of the perl 6 hackathon and I just like the name :)
pmichaud I know they'll be excited to see it
moritz_ jnthn: that's what the IRC logs find when I search for Seoul.pm :-)
#padre is also publicly logged, FYI 13:43
pmichaud the Seoul.pm suggestion came to me in-person at a hackathon or workshop
jnthn I was rather surprised to discover that one of them had a printed copy of the Perl 6 spec too!
Made into a book.
pmichaud I'll double-check my logs
PerlJam: feel free to update the release guide with your current candidate 13:44
(same goes for any release candidates)
er, release managers
13:49 iblechbot joined
masak meeting tonight to brainstorm about a Perl 6 book. 18 UTC. any interested parties are welcome to attend. 13:50
moritz_ let's say #perl6book?
masak what moritz_ said. #perl6book. 13:51
pmichaud masak/moritz: have either of you been in touch with chromatic and/or allison about a book?
moritz_ not me
masak neither
pmichaud okay
masak but I imagine our plans are less ambitious than theirs.
pmichaud I need to include the two of you on some discussions
dalek kudo: a0d1e55 | moritz++ | docs/release_guide.pod:
[docs/release_guide.pod] suggest Lisbon.pm
 13:52
13:59 breinbaas joined 14:08 szabgab joined, KyleHa joined 14:11 alester joined
KyleHa Smolder ought to hide test results that are exactly the same as some other test results. 14:13
14:17 SmokeMachine joined 14:19 Psyche^ joined 14:23 ilbot2 joined
moderator »ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Gothmog_ joined 14:24 mariuz joined 14:25 hugme joined
moritz_ or at least identify them as such 14:26
KyleHa Good morning Moritz!
moritz_ good localtime() KyleHa :-)
KyleHa I got that Test::Util thing done-ish. 14:27
moritz_ that's great
KyleHa It probably needs better names (is_run and get_out).
masak who is Jeremiah Foster? he's to hold a talk on Perl 6 at FSCONS '09. fscons.org/node/64
which is great, but I don't think I've heard the name before.
KyleHa It's also painfully slow.
moritz_ masak: I've heard that name before, but I can't manage to get an association with it 14:28
KyleHa Otherwise, barring some feedback, I'm going to leave it as-is.
mberends masak: I'm very interested in contributing to a Perl 6 book. If I miss tonight's meeting because of network-- please know that you can count on my enthusiastic support, and tuits :) 14:29
moritz_ KyleHa: I think the next step is to write some simple tests to use it, and get feedback from windows users (like jnthn++)
masak mberends: excellent. as with all efforts of this kind, your contributions will be warmly accepted. 14:30
moritz_ mberends: there will be public logs
mberends: and yes, it will be great to have you on board
PerlJam is itching to write something for perl 6 too, but needs to find the time to sit down and do it.
mberends :-)
KyleHa I wrote some simple tests in pugs/t/03-test-util/is_run.t Some of them could reasonably move to the spectest suite. 14:31
moritz_ please do 14:32
14:33 justatheory joined, abra joined 14:36 xenoterracide joined
pugs_svn r28650 | kyle++ | [t/spec] turn some todo lives_ok tests to skipped tests and fudge regressions 14:39
14:50 synth^2 joined 14:58 r0bby_ joined
pugs_svn r28651 | kyle++ | [t/spec] Test "die" with is_run() 14:58
r28652 | rblasch++ | [t/spec] Fixed typo. 14:59
colomon moritz_, masak: is the book meeting in two hours? 15:02
masak no, three.
moritz_ colomon: three, actually
date --utc helps :-)
masak not on OS X :/
jnthn not on windows :/ 15:03
colomon what masak said.
moritz_ inferior operating systems.. :-)
masak ah, date -u
KyleHa can never remember how to spell UTC.
colomon but it works great on my Linux box.
masak KyleHa: Z-u-l-u :P
KyleHa Yeah, it's always 'date -u' for me. 8-) 15:04
colomon the good news here (at least from my perspective) is that I'm a lot more likely to be available in three hours than in two. :) 15:05
moritz_ wow, I didn't know we'd attract so many people with our small brainsstorming meeting
pmichaud my irssi client tells me the current utc :) 15:07
[particle] foxclocks++
jnthn pmichaud: Heh, how'd you get it to do that? 15:09
TimToady well, for my irssid, I have env TZ=America/Los_Angeles 15:12
*irssi 15:13
an irssid would be cool though
moritz_ isn't that spelled 'screen'? :-)
pugs_svn r28653 | kyle++ | [t/spec] more specific fudge message after some "git bisect" goodness 15:14
KyleHa (slurpy-params.t regressions were introduced by 41bc84f00d, if that helps anyone.) 15:15
moritz_ if you fudge out rakudo regressions, please open a ticket for that
KyleHa OK. 15:16
15:16 felipe joined
moritz_ (our unstated motto is "we only move forward unless stated otherwise" :-) 15:16
KyleHa I think my brain just tried a summersault. 15:17
jnthn I'm was pondering the failures may be bogus.
The message iirc suggests it's a call time failure.
Wehreas it probably wants to be a compile time one.
15:17 lanny joined
moritz_ care to explain? 15:19
15:20 envi^office joined, nbrown joined
jnthn Later 15:21
(busy)
moritz_ sure
15:24 nihiliad joined
pugs_svn r28654 | kyle++ | [t/spec] Add reference to RT 69622 15:29
15:36 ejs joined 15:45 zloyrusskiy joined 15:49 pmurias joined
TimToady jnthn: I agree that ::T shouldn't count as a constraint; working on a STD patch 15:53
jnthn TimToady: OK, cool...I'll patch Rakudo too at some point for it. 15:54
TimToady: Plus no dobut I'll need to work on converging with the parameters with of STD a bit more too.
TimToady we'll have to do something similar in any case if we add coercive types, since Int(Any) is really more like Any where *.coerce_to(Int) 15:55
pugs_svn r28655 | lwall++ | [STD] don't count ::T as type constraint as suggested by jnthn++ 16:02
r28655 | [gimme5] naively remove comma from map and grep
r28655 | [STD_P5] start hacking in a P5 grammar by cutting down P6 grammar
r28655 | (compiles, but nothing invokes the non-regex part yet)
jnthn TimToady: Yes, true. 16:04
TimToady: Not entirely sure what the chances of those appearing in Rakudo * are yet.
I'd rather like 'em to, but we'll see. 16:05
TimToady if it's a simple desugar to a nominal plus a constraint, it's probably pretty easy
KyleHa Is there any functional difference between ?1 and Bool::True ? 16:06
jnthn yhmm, true
16:06 zaphar_ps joined
jnthn Well, actually that's what I do with :(42) today 16:06
TimToady I guess it's more like *.=Int
jnthn (de-sugar it to two things) 16:07
Hmm. That does make it all rather simple. :-)
Means it can all be done in the actions and no changes to signatures.
OK, in that case it can certainly be in Rakudo *.
TimToady++
16:07 mberends joined
jnthn TimToady: I am curious though, if .Foo is The Way to coerse. 16:08
quietfanatic KyleHa: ?1 is Bool::True.
KyleHa Cool, thanks!
jnthn TimToady: Mostly because if I have a class Foo::Bar { } and I want to write a coercion to it, what is the method that I write called?
TimToady hmm, perhaps I'm oversimplifying
16:08 cahek joined
jnthn TimToady: I'm wondering if we want more like a COERCE multi. 16:09
TimToady .'Foo::Bar' maybe
jnthn How do you define a method of this name?
quietfanatic KyleHa: But anything that requires a Bool will take 1 to mean true.
TimToady well Foo::Bar() should always work
jnthn Yeah, true.
TimToady but it occurs to me that a simple desugar of Int(Any) isn't quite what it wants to mean
jnthn But I think we had Foo($x) as just calling $x.Foo anyway.
KyleHa quietfanatic: Yeah, that's what I figured. I'm just thinking about an unambiguously boolean value without the verbosity of 'Bool::'. 16:10
TimToady suppose you have foo(Int(Any) $x, Int(Any) $y) {...}
quietfanatic KyleHa: Aye.
16:11 zloyrusskiy joined
TimToady suppose there's also a (Num,Num) variant 16:11
quietfanatic KyleHa: just plain True ought to do it too.
rakudo: say True
p6eval rakudo a0d1e5: OUTPUT«1␤»
KyleHa Oh, that's good too.
TimToady if you say foo(1,1) you want it to pick the coerced to Int variant, not pick the Num variant
jnthn The Num,Num variant is tighter.
TimToady than Any Any 16:12
jnthn Oh
Hmm
TimToady but I think we'd have to insert narrow versions in the candidate list as well
jnthn Do you really want it to pick that?
TimToady so maybe it's not so simple
jnthn Well, the problem is that this may blow up exponentially, no?
TimToady I think so
depends
might get away with just two variants, most general and most specific 16:13
jnthn Hmm
Maybe.
I'm a bit wary about extra candidates magically appearing.
TimToady I think that works for most of Perl builtins, but I could be misdesigning
it's a kind of way of specifying which specific case should be used as the default 16:14
without having to write the Any,Any variant and delegate back to Int,Int
jnthn Hmm, I see the point.
We just don't generate extra candidates anywhere else. 16:15
I'm not worried from an impl point of view.
More a user one.
I mean, what if the user writes their own :(Int,Int) variant too? 16:16
Our generated one will then cause an ambiguous dispatch.
TimToady that would be ambiguous, yes
quietfanatic Isn't it almost as easy to have one candidate added, and then have the MMD treats it like two?
TimToady I'm currently thinking that the Int,Int is the actual one, and the Any,Any is generated
since it just delegates
jnthn quietfanatic: That's more an implementation detail. 16:17
TimToady quietfanatic: not if it has to be sorted to two different places in the candidate list
16:17 iblechbot joined
jnthn quietfanatic: Yes, they can share the same chunk of code, but still, it'll still be two entries in the ordering. 16:18
quietfanatic jnth: Didn't you say you weren't worried from an implementation point of view, but a user point of view?
jnthn TimToady: Generating the Any,Any could work.
quietfanatic If I type &sub.candidates it'd matter.
jnthn quietfanatic: Hmm, true. It was the dispatch semantics that bothered me more than the introspection ones. :-) 16:19
TimToady Any,Any :> Num,Num :> Int,Int, but the outer two might be the same function, albeit with the Any version coercing
so it's not really the same function at that point
jnthn Well, they have different signatures, but the same .do I guess.
TimToady not if we want to eliminate useless coerion on (1,1)
*coercion
jnthn (if we say that binding the signature is what drives the coercion, anyway) 16:20
TimToady hmm
jnthn I think that'd mean two Routine objects (well, some subclass of that) though.
16:20 cahek joined
TimToady (Int,Int)|(Any where *.=Int, Any where *.=Int) 16:20
does a multisig insert multiple candidates? 16:21
jnthn I'm still hadn't really figured out how the whole multi-sig thingy plays into it.
Well, it needs to insert more than one thing into the candidate list.
TimToady I suspect it has to
jnthn They likely would share something.
16:21 Zloy_russkiy joined
jnthn But it'd be two entries. 16:21
TimToady if the sig matcher does the coercion before the .do, then it might work 16:22
jnthn Since the two sigs could sort very differently.
Yeah.
Though this actually brings up a copule more questions...
TimToady so maybe we can desugar Int(Any) to a multisig
assuming we can get that to work
jnthn Like, if the binding executes before the .do, whose lexpad holds the parameters?
TimToady always the .do's lexpad 16:23
quietfanatic Would Int(Any), Int(Any) generate two sigs or four?
jnthn quietfanatic: TimToady suggested I think two.
TimToady: OK.
TimToady: On a related note, if I have a default value, is it OK to take that and promote it to a closure that returns that value? 16:24
TimToady sigs are the only place where lexicals leak outside their block :)
jnthn At least, in any non-literal case?
(we can optimize literals...)
TimToady isn't that required in any case?
jnthn TimToady: I think it is to get the right semantics. 16:25
TimToady: We may well get the wrong ones in Rakudo today. ;-)
TimToady it has to be at least a thunk of some sort that is lazy
jnthn OK, good.
TimToady it's not evaluated unless needed
jnthn I'll thunk everything initially.
And them if it's like :($foo = 1) then we can optimize it later.
TimToady just like with has $.foo = bar()
jnthn Right. 16:26
TimToady bar isn't called unless un-inited
jnthn *nod*
OK, seems like I'm on the right track.
TimToady in fact, I think the has case specs autoclosure
jnthn Yes, that one is spec'd, I'm quite sure of it. 16:27
I'm not so sure the default parameter value case is, which is why I wanted to check I was doing something sane. :-)
TimToady the proper way to fire off code 'en passant' would be with a where, not with a default 16:28
jnthn TimToady: Sorry if I caused confusion - this was a separate question to the coercions stuff. 16:29
TimToady and it's inefficient to calculate unneeded defaults, so there's really no use case for being eager
jnthn Yes, agree.
TimToady oddly, not confused, for once :)
jnthn Ah, I see.
TimToady either that, or more confused than I think I am :)
jnthn Yes, I thought I had confused you. But no, you were way ahead of me. :-)
I guess this leaves my tricket issue being "make the parameter lexicals go in the right place during the binding" 16:31
(Almost certainly not a problem, just needs some thought.)
TimToady hmm, I wonder...
std: multi foo ($a,$b)|($b,$a) {...} 16:32
p6eval std 28655: OUTPUT«ok 00:01 97m␤»
jnthn heh heh. What if the multi sigs introduce different varialbes.
TimToady now why didn't I get a useless redeclaration...
jnthn TimToady: Actually, that's one other thing that confused me on multi sigs.
TimToady then they get declared
jnthn std: multi foo ($a,$b)|($a) { say $b } 16:33
p6eval std 28655: OUTPUT«ok 00:01 99m␤»
TimToady just dups are colesced under the 'my $x; my $x' rule
jnthn std: my $x; my $x;
p6eval std 28655: OUTPUT«Potential difficulties:␤ Useless redeclaration of variable $x (from line 1) at /tmp/pgRIa3o3eK line 1:␤------> [32mmy $x; my $x[33m⏏[31m;[0m␤ok 00:01 97m␤»
TimToady it would, of course, be undefined if the second sig matched
jnthn But without the warning?
TimToady I was expecting the warning, but STD is smarter than I am, it would seem :)
jnthn OK, so we're taking the union of the possible variables.
TimToady yes
jnthn OK. 16:34
I think however I implement multi sigs, is how coercions should probably happen.
masak I'm on #perl on irc.perl.org today -- interesting experience.
TimToady seem likely
16:34 abra joined
jnthn masak: Do they talk about Perl there? 16:34
masak jnthn: sometimes.
jnthn Wow.
16:35 stephenlb joined
TimToady spread the butterflies 16:35
masak mst asked a nice question: which features do I think Perl 6 would have that Perl 5 does not have already, and might never have?
I thought I'd bring that question over here for general mulling.
I've already said macros, the op overloading syntax, parametric roles ("we've had that for ages!" said mst)...
16:36 zloy_russkiy joined
TimToady optimizable semantics :P 16:36
16:37 abra joined
masak TimToady: so far, I've avoided conflict with people who express a distaste of the butterfly, and sort of mingled with those who don't. :) 16:37
TimToady the union of Perl 5 extensions rather than the intersection :)
masak yes, that's something that I wanted to express as well.
TimToady I'm sure I could come up with a more concrete list given time
16:37 cognominal joined
masak that union/intersection thing could be seen as the "Final Argument" for Perl 6. 16:38
meaning that, sure, you can get most of the cool things in Perl 5 too. but not as nicely packaged and not as consistent and coherent.
TimToady yeah, you can shoehorn most any single Perl 6 feature in, but to shoehorn all of them in is impossible
also, anything depending on a sane type system, and deep multi-dispatch semantics 16:39
masak aye.
TimToady native types, maybe 16:40
16:40 meppl joined
masak why is that good? 16:40
and what can't Moose emulate?
TimToady if Moose turns into an optimizer, it'll be too slow 16:41
I think P5 could easily get contextual variables 16:42
but I doubt it'll ever manage to acquire twigils 16:43
obra_ TimToady: please tell chromatic or lathos it's impossible for perl5 to grow twigils. ;)
TimToady not without some severe refactoring of syntax, which is never gonna happen
obra_ grins 16:44
masak I'll mention twigils to mst. :)
TimToady there are many, many ramifications...
jnthn manges to explode the Parrot dynop compiler 16:45
TimToady including switching to . for methods, switching to ~ for concat, etc, etc. 16:46
dukeleto jnthn: what are you doing to the poor dynops?
quietfanatic What about perl 6 regexes?
moritz_ they are great ;-) 16:47
TimToady more doable, on some level, since p5 considers regexen to be strings
quietfanatic They (once implemented, will) completely outstrip perl 5 regexes.
Hmm.
TimToady but again, depends on twigilness for $<foo>
jnthn dukeleto: Creating combinatoric pain. :-)
moritz_ quietfanatic: perl 5 supports pluggable regex engines 16:48
by pragma
TimToady which implies use of .<> for subscripting
quietfanatic Is multiple dispatch doable in 5?
TimToady which implies required whitespace before infix:«<»
16:48 payload joined
moritz_ which breaks a hell lot of code out there 16:49
TimToady at some point, you can break these consistencies of P6 and substitute different twigils or different subscripting constructs, but then the whole design goes insane(r)
Perl5: "Look, I can juggle one ball at once, and sometimes two!" 16:50
16:51 Chillance joined
quietfanatic Oh, and named arguments! 16:52
16:52 lmc joined
moritz_ TimToady: can I assume that Int ~~ Num doesn't hold true anymore? 16:52
but rather Int ~~ Real and Num ~~ Real instead
[particle] depends if you've overloaded ~~ :) 16:53
moritz_ slaps [particle] with +2 stick of obviousness 16:54
[particle] you probably know this, but that hurts a little.
TimToady actually, S02 currently has Int ~~ Integral but not Real 16:55
moritz_ so what's the type that encompasses Int and Num, but not Complex? 16:56
I'd thought that'd be Real
TimToady define "encompass" in terms of capabilities
moritz_ I'm caring about type constraints right now, not capabilities (though I know that the two are related) 16:57
TimToady depend on how you define it, there are things Integral can do that Real can't, and vice versa
roles are primarily about capabilites, I suspect 16:58
so we might actually have to split up the capabilities differently than standard type theory would suggest
moritz_ what can a Num do that an Int can't?
TimToady remember a fractional part 16:59
justatheory types
moritz_ well, that can be implied to be 0 on an Int - but you've got a point
I thought more in terms of standard functions
sqrt, floor, sign, abs etc.
17:00 cdarroch joined
TimToady an Int value can almost always be *used* as a Num, sure 17:00
but tagmemics says we can make that work without necessarily saying that one is the subset of the other 17:01
we know how to verb nouns without making all nouns into verbs or all verbs into nouns 17:02
and, in fact, we give a consistent meaning to verbing nouns in P6. Int($x) is a verbed Int 17:03
moritz_ that doesn't quite solve the problem on how to write a signature that excepts every number that can act as a real value (in the mathematical sense) 17:07
TimToady std: sub foo (Int ::T $x) {...}
p6eval std 28655: OUTPUT«ok 00:03 99m␤»
jnthn \\o/
quietfanatic I notice rakudo's qx captures stderr as well as stdin. Is this specced?
TimToady moritz_: well, it's all still negotiable :) 17:08
moritz_ TimToady: that's good ;-)
TimToady but perhaps the type you're looking for is Real() rather than Real, meaning anything that coerces to Real 17:09
which is what jnthn and I have been, er, negotiating
moritz_ no, I don't 17:10
because I want to write functions that reject Complex numbers on multi dispatch
TimToady so there's something in there about not losing info
which is probably heading into some kind covariant/contravariant swamp :) 17:11
quietfanatic I don't know if Complex should coerce to Real.
moritz_ OH NOEZ
TimToady Complex.re already does that
quietfanatic I mean implicitly. 17:12
moritz_ that's more cutting, less coercing
TimToady well, define what the coercion should do
quietfanatic Fai.
moritz_ I can't think of any sane, universal way to coerce 1+2i to Real
quietfanatic *fail.
That's what I think it should do.
moritz_ that's what Rakudo currently does
rakudo: say (3+4i).Num
TimToady then Complex !~~ Real()
p6eval rakudo a0d1e5: OUTPUT«You can only coerce a Complex to Num if the imaginary part is zero␤␤»
quietfanatic Thus Real() does not match Comlexes.
moritz_ rakudo: say (3+9i).Num 17:13
p6eval rakudo a0d1e5: OUTPUT«You can only coerce a Complex to Num if the imaginary part is zero␤␤»
moritz_ rakudo: say (3+0i).Num
p6eval rakudo a0d1e5: OUTPUT«3␤»
PerlJam rakudo++
TimToady rakudo: say (1.5).Int
moritz_ that was the most sane I could think of, which doesn't mean much
PerlJam (whoever added that)++
p6eval rakudo a0d1e5: OUTPUT«1␤»
TimToady inconsistent 17:14
PerlJam TimToady: yes, but is it a foolish inconsistency?
moritz_ well, for Num -> Int it's a wee bit more obvious
PerlJam :)
moritz_ how to do it
TimToady beg to differ
pmichaud same here
PerlJam truncating the Complex part seems "reasonable" too
pmichaud looks equally obvious :)
TimToady to many people, rounding is obvious 17:15
pmichaud or equally non-obvious
quietfanatic I certainly don't want +sqrt(-1) to be silently 0!
17:15 brunov joined
quietfanatic I mean Num(sqrt(-1)) 17:15
PerlJam quietfanatic: you want it to be loudly 0 or something else?
moritz_ for a physicist there's a huge difference between discretizing and throwing away one dimension completely 17:16
pmichaud quietfanatic: but you're willing to allow Int(1/2) to be silently 0?
moritz_ quietfanatic: sqrt(-1) is NaN
rakudo: say sqrt(-1)
p6eval rakudo a0d1e5: OUTPUT«NaN␤»
quietfanatic pmichaud: yes.
TimToady to a mathematician the reals are closer to infinity than they are to integers
moritz_ and you can reduce two dimensions to one by using a cantor fractal, I know ;-) 17:17
still it felt wrong to just use .re or .abs for coercion to me 17:18
TimToady I'm inclined to think that information-losing transformations ought to generally be explicit
dalek kudo: 30e2cfd | jonathan++ | (4 files):
Add in ops that allow for fast construction of low level signatures.
 17:19
TimToady integer trunction might be an exception for practical reasons
17:19 mberends left
PerlJam TimToady: what do you mean by "explicit"? 17:19
17:19 mberends joined
moritz_ sounds sane 17:19
colomon I'm with PerlJam on this one. 17:20
pmichaud jnthn: ...ops?
jnthn: why use dynops here?
jnthn: simply to avoid method call overhead?
jnthn pmichaud: Indeed.
pmichaud hmmmm
jnthn pmichaud: We're not talking a couple of method calls here.
17:20 icwiener joined
TimToady I mean that .re is explicit, and Real() isn't 17:21
jnthn pmichaud: We're talking a *lot*.
pmichaud: And I rather suspect that's a big part of my startup on my box is running to 0.95-ish seconds currently (down from 1.05-ish with a couple of the recent refactors I've done.) 17:22
moritz_ I see that sigguts.h was added, and my first thought was "did jnthn work on signals?"
jnthn pmichaud: Yes, I know it's a big...eww. But that's why I factored the code generation for signatures out, so it's only one method emitting this stuff. :-)
colomon TimToady: Would Real() be okay if the Complex's imaginary part was 0?
jnthn s/big/bit/
pmichaud: Overall, though, signatures - unless we really need a high level object - are becoming more low level. 17:23
pmichaud what do you mean by "low level"?
jnthn pmichaud: We can't just go on doing tens of hash lookups every time we call a sub with a couple of parameters.
I mean, we're stashing the data in a c-struct. 17:24
PerlJam TimToady: so ... what are coercions then? To me, when down-coercing, it always seems like you're asking to take this big thing and put it in a smaller box. whatever fits, fits. Ergo, Real($complex) tries to fit a complex number into a Real-sized box and all that fits is the real portion.
TimToady maybe, depending on how we define ~~ Real()
pmichaud I don't have a problem with it being in a c-struct
it's the ops specifically that are weirdish
TimToady to be consistent Int(1.0) would work, and Int(1.5) wouldn't
pmichaud why dynops instead of methods?
jnthn pmichaud: Mostly overhead.
PerlJam TimToady: now *that's* a foolish consitency if ever I saw one 17:25
pmichaud I think I'd prefer to deal with overhead issues after pcc branch has landed, though
jnthn pmichaud: The difference between going through a bunch of PCC, or just doing a bunch of pointer assignments.
pmichaud: I'd rather write this once.
pmichaud why "a bunch of PCC"?
colomon TimToady: taking that to the next level -- if a Rat cannot be exactly expressed as a Num, it can't be converted to one using .Num?
TimToady Multiple foolish consistencies are the hobgoblins of large minds. :) 17:26
jnthn pmichaud: Because we have hundreds of methods in the setting. Add up their parameters, and you're getting into a lot of calls.
pmichaud: Plus there's a C boundary issue here.
pmichaud I was hoping that we'd come up with a way to have the signatures frozen into the pbc anyway
so it doesn't matter if there are hundreds of methods in the setting, because that cost is compile-time and not startup-time 17:27
PerlJam coercing downwards as truncation works for me if no one else.
jnthn pmichaud: We may be able to have *some* aspects of them frozen.
pmichaud: However, I see that more as a long-term goal.
quietfanatic If Complex downgrades implicitly to Real, then we'll need a Realal role to go along Integral. :)
s/along/along with/ 17:28
jnthn pmichaud: The thing is that we can't freeze things like references to type objects so easily.
colomon TimToady: I'm inclined to think not allowing Complex.Num (er Complex.Real?) is the right choice.
TimToady Really
PerlJam And as a general principle, coercions should not work only at the points of intersection between the types and fail everywhere else.
jnthn pmichaud: And I don't see that changing too soon.
PerlJam IMHO
colomon PerlJam: yes, it seems like that would encourage a lot of ugly code, if nothing else. 17:29
jnthn pmichaud: Anyway, the refactor I did means the code gen for this is in one method.
PerlJam Or, another foolish consistency is to not provide coercion at all ;) 17:30
jnthn pmichaud: If this approach somehow turns out horrible, it's not going to be hard to switch to a method call based approach.
pmichaud: I'm just making a pragmatic decision based upon our need to win some performance and my expectations of what Parrot will provide us.
pmichaud jnthn: and PCCMETHODS are that slow? 17:31
jnthn pmichaud: You have all the PCC overhead as usual, plus the fact that you're crossing the PIR/C boundary.
pmichaud it just really feels like a very premature optimization. 17:32
also it feels like we just went a bit too far down a slippery slope
jnthn I fail to see how.
pmichaud architecturally I think we just start writing all of our primitives as dynops
jnthn Parrot provides more than one way to deal with C data structures from within PIR. One is dynops, another is vtable methods, another is PCC methods. 17:33
pmichaud okay, some comments/questions then
what does get_signature_elem do exactly? It appears to have the same documentation as set_signature_elem
quietfanatic jnthn: there's more than one way? I have to learn these ways. 17:34
pmichaud oh, I see
jnthn pmichaud: The first paragraph marks the difference.
pmichaud set is a set, get is a fetch
jnthn pmichaud: It's for introspection.
pmichaud so it's a fast lookup of lots of attributes 17:35
jnthn Right.
pmichaud instead of "get_signature_size" op, why not just VTABLE_get_integer ?
jnthn pmichaud: That one would be ammenable to being a vtable method. 17:36
pmichaud: But it'd be the "odd one out".
pmichaud instead of "allocate_signature", why not $P0 = new ['P6LowLevelSig'] and assign $P0, int ?
jnthn But yes, that'd not be an issue.
Could do it that way also. 17:37
17:37 abra joined
pmichaud that would at least be consistent with other PMCs like FixedPMCArray and the like 17:37
17:37 abra joined
pmichaud unless we want to say that the existing FPA mechanism is a poor one (which is possible) 17:37
PerlJam keeps mentally inserting a G into FPA for some reason 17:38
17:39 abra joined
jnthn Well, after I figured the set_signature_elem and get_signature_elem would be dynops, the other two kinda just followed along in a "just build a small op-based interface to low level signatures" kinda way. 17:39
pmichaud well, I'm not going to veto it now. (more) 17:40
jnthn FPA relation - well, thing is we aren't really supporting the array interface. 17:41
At least, not for now.
pmichaud But this seems to me as though we have extremely little faith in Parrot's ability to perform, especially in the realm of attribute and hash lookups
jnthn Note that we'll never expose this PMC directly to Perl 6 code.
17:42 abra joined
pmichaud and if attribute/hash lookups aren't performant enough, then the hope of ever having a reasonable speed regex engine is fairly moot. 17:42
afk, gotta grab lunch before 18h00 17:43
jnthn I think the difference here is that there's an expectation that the regex engine is being written in something running on top of Parrot, whereas the things that primarily care about signatures (the multi-dispatcher and the signature binder) are in C. 17:44
It's kinda silly, to me, to build up a bunch of objects and hashes, when the things that need the data much more naturally use structs. 17:45
pmichaud objects are structs
jnthn Parrot high level objects?
No, every time you look up an attribute in one of those ATM it's a hash lookup. 17:46
pmichaud right
17:46 abra joined
pmichaud thus my point about performance 17:46
jnthn We can have a really efficient hash implementation, I'm sure.
pmichaud perhaps we really need a more efficient object implementation
jnthn Probably.
pmichaud I know that attribute lookups in object PMCs are currently hash lookups. I think that's a problem with the design. 17:47
PerlJam sic chromatic on it :)
jnthn But the thing that we do an awful lot of at the moment is calling things.
pmichaud because I guarantee that Cursor and Match objects all have attributes
TimToady "if it's good enough for P5, it's good enough for Parrot" :P
jnthn Every operator dispatch and method dispatch is influenced by binding performance.
So yes, we probably do want to target objects for improvements too. 17:48
pmichaud jnthn: I understand that. But I think it's also the case that we expect an ability to write (some portions of) dispatch in P6, same as how we do the regex engine
i.e., at one time it wasn't expected that the regex engine would be written "on top of Parrot"
it was expected that the regex engine would be integral to Parrot
TimToady you mean embedded in Parrot, as in P5 17:49
pmichaud yes
TimToady I remember tromping on that one pretty hard at one design meeting
pmichaud "tromping on" == "don't do that" ?
or "tromping on" == "that's the only way to do it"? 17:50
TimToady stomping into the ground such that the idea won't be resurrected :)
17:50 abra joined
pmichaud would you say similar things about dispatch? or are dispatchers different from regex engine in that sense? 17:50
jnthn I think for now we have to pick our primitives.
e.g. the things we'll make fast - at the cost of not writing them in Perl 6 - to enable other things to be written in Perl 6. 17:51
And still be performant.
TimToady I think dispatchers also have to give the appearance of being in the same runloop, even if they aren't
17:52 abra joined
TimToady but only if someone is looking 17:52
pmichaud jnthn: okay, here's my conclusion for now
17:52 parduncia joined
pmichaud jnthn: first, it's OK to continue on this path 17:52
TimToady in a sense, the dispatcher wants to be inlined and optimized away on every call 17:53
17:53 stephenlb joined
pmichaud alarm bells are going off in my head that "this is the wrong approach" and that it's really trying to work around something that absolutely will have to be fixed in parrot anyway 17:53
17:53 abra joined
pmichaud but I don't want it to become a template for how we solve other problems in parrot 17:54
I agree that it'll be easy to switch it to something else later
i.e., the encapsulation is fine
TimToady we can assume that a special declaration will be required if you wish to open up the dispatcher to monkeypatching
under the prepessimal principle 17:55
moritz_ book brainstorming meeting in 5 in #perl6book
jnthn I agree it's not desirable to have a dynop explosion. 17:56
And yes, I hope that we'll hit a point where we can perhaps switch to a method interface instead. 17:57
pmichaud it's not just the dynop, it's this struct/hash duality that keeps being entrenched (more)
we already have a lot of PMCs that act as structs
17:57 abra joined
pmichaud and then we write a bunch of "inspect" vtable methods to be able to fetch information out of those structs 17:57
and we do this because we don't have an efficient mechanism for storing attributes 17:58
so every time a speed issue pops up we move things away from the standard interface and into special-purpose PMCs 17:59
PerlJam pmichaud: a foolish inconsistency? :)
pmichaud which seems to tell me that we ought to be addressing the source of the speed issue
instead of constantly adding workarounds to avoid it
jnthn pmichaud: There's probably a lot of truth in that. 18:01
moritz_ jnthn: #perl6book?
jnthn moritz_: p6book or perl6book?
moritz_ perl6book
18:02 NorwayGeek joined
jnthn heh, I was still in the other one, waiting for the meeting to start. ;-) 18:02
18:03 abra joined 18:06 Dyuran joined, Dyuran left 18:07 abra joined 18:11 abra joined 18:15 rfordinal joined 18:16 quietfanatic joined 18:24 rfordinal left 18:32 abra joined
cj pmichaud: I heard your name the other day. are you related to UW in any way? 18:41
pmichaud cj: no, that's probably the other "Patrick Michaud"
cj didn't you register with ARIN or IANA or something? 18:42
masak IANA what? 18:44
:)
18:45 viklund joined
jnthn IANA pmichaud you're looking for, I guess... :-) 18:46
pmichaud I don't think I registered with anything. I tend to grab "pmichaud" wherever I can, yes, but there are a lot of places where others beat me to it :)
[particle] cj: that's patrick a michaud, who works on 'Solstice' (cpan name), aka 'Catalyst' (internal UW name) 18:52
18:58 abra joined
moritz_ hugme: reload 19:06
hugme moritz_: reloaded successfully
moritz_ hugme: show book
hugme moritz_: sorry, I don't know anything about 'book'
moritz_ hugme: reload
hugme moritz_: reloaded successfully
moritz_ hugme: show book
hugme moritz_: the following people have power over 'book': PerlJam, TimToady, [particle], jnthn, masak, mberends, moritz_, pmichaud. URL: github.com/perl6/book/
masak mmm, power over 'book'. :)
[particle] i can make him write really screwed up code anytime now. muhahahahahahah!!!! 19:08
19:09 nihiliad joined
pmichaud (IronMan from #perl6book) -- I've been thinking of bundling my commit messages into blog posts :) 19:12
19:17 abra joined
moritz_ README commit pushed 19:19
we need dalek to report to #perl6book 19:25
colomon Getting away from the book for a moment -- I asked in the middle of the night, and missed any response that might have happened. 19:28
As far as I know, we don't have tests for operator overloading? I mean all the things we are enabling moving operators to the setting. 19:29
(I guess not just operators, for that matter.)
It seems like it might be worthwhile to add to the spectest? (Or is it there and I just don't know where?)
moritz_ colomon: we have tests for overloading some operators 19:30
colomon: and we also have tests for calling positional parameters by names for many builtins (frew++, iirc) 19:31
colomon yes, frew.
moritz_ which also requires them to be in the setting, though they don't work yet
colomon where are the current overloading tests? 19:32
moritz_ S06-operator-overloading/*.t
pmichaud S13-overloading, perhaps?
moritz_ and S13-overloading/*.t 19:33
colomon sigh; I've been looking in S03-operators
pmichaud S13 is the synopsis that describes operator overloading, iirc
moritz_ that's not where the spec puts it ;-)
colomon S06-operator-overloading/imported-subs.t appears to be defining new operators. 19:34
pmichaud colomon: feel free to put things where they make more sense :)
colomon pmichaud: I'm just trying to figure out the lay of the land right now. 19:35
pmichaud yes, but if the lay of the land isn't conducive to "figuring it out", then it needs changing
we not only create maps of the land, but we sometimes terraform and bulldoze to get the land to fit what we want the maps to look like.
colomon I always assume that I'm just being dense until proven otherwise. :) 19:36
It looks like a couple of the basic operators are overloaded in S06-operator-overloading/subs.t
Ditto for S13-overloading (though weirdly, in multiple-signatures.t rather than operators.t) 19:37
moritz_ you know, they say that 90% of everything is crud. Since I made 22% of the commits of the test suite, at least half of what I did there was crud 19:38
probably much more 19:39
"arguing with flawed arguments for dummies, part 1"
colomon I would like to emphasize that I am not criticizing the current tests, I'm looking for more tests that need to be written. 19:40
d:)
moritz_ colomon: I know. But I wanted to put your "assume that I'm just being dense until proven otherwise" into perspective
PerlJam cleans up some spam on rakudo.org 19:41
moritz_ I think currently we'd be better of with disabling comments on rakudo.org altogether
PerlJam Probably 19:42
Certainly on some pages.
Is there an easy-ish way to delete many comments? 19:44
moritz_ I haven't found one
except opening the confirmation-for-delete page in a new tab for every comment
so you don't have to wait for two pages loading to proceed to the next one 19:45
pugs_svn r28656 | diakopter++ | [sprixel] made a bunch more tests pass, er smth. 19:58
pmichaud phone 20:00
diakopter mberends: 304 tests passing 20:01
pugs_svn r28657 | diakopter++ | [sprixel] updated spectest.data 20:02
mberends \\o/ 20:03
20:17 r0bby joined 20:22 xenoterracide joined
cognominal svn perl6 does not build anymore. complains of a missing sigguts.h 20:34
I meant git perl6 20:35
make: *** No rule to make target `src/pmc/sigguts.h', needed by `src/pmc/perl6_group.bundle'. Stop.
jnthn cognominal: huh. It's in the repo... github.com/rakudo/rakudo/tree/master/src/pmc/
jnthn thought he'd forgot to check it in, but it's there... :-S 20:36
moritz_ cognominal: did you reconfigure before running make?
PerlJam cognominal: did you git pull ? :)
cognominal perl Configure.pl --gen-parrot # what I do 20:37
jnthn cognominal: The file is really not there on disk?
cognominal maybe that's a make realclean that erased it. 20:38
jnthn oh!!
Yes :-/
moritz_ try 'git checkout src/pmc/sigguts.h' to bring it back
jnthn A make clean with the old make file removed any *.h, not just pmc_*.h
Or a reset if yo've no other local diffs.
cognominal my script does a realclean after the pull 20:39
jnthn ah.
cognominal usually it helps, but not this time apparently
jnthn Yeah...sorry. 20:40
cognominal no problem :)
thx. bed time& 20:45
quietfanatic In Perl 5, you can change the use semantics by defining an import sub.
How does one do this in Perl 6?
20:52 anniyan joined, SmokeMachine joined
TimToady quietfanatic: not yet specced, though likely to be similar 20:54
quietfanatic Alright.
It's not something that can't easily be worked around. 20:55
21:03 xenoterracide joined 21:06 meppl joined 21:07 Whiteknight joined 21:10 xenoterracide joined 21:30 tak11 joined
jnthn OK, I now have a branch with us switched over to building the new signature objects, plus enough tweaks to get the stage 1 compiler to run again. Multi dispatch takes its info from the new style sig objects too, as does !SIGNATURE_BIND (eventually going away, but one step at a time). Tomorrow I'll try and get us properly compiling the setting again, and then get the branch passing the test suite. Hopefully by the end of this week, I'll have this first sta 21:40
diakopter I'll have this first sta... 21:41
moritz_ truncated after... what diakopter wrote ;-)
jnthn ...I'll
have this first stage merged, and after that it'll be on to
writing our own custom binder, which will probably take much of
next week. :-)
gah, fail
well, it's readable. :-)
moritz_ but readable fail
moritz_ too slow tonight
jnthn I expect the custom binder will handle binding nameds to positionals right from the start. 21:42
moritz_ now *that* would be good new
jnthn So if I can get that done before the next release (decent chance) then we can win a bunch of tests from that too. :-)
moritz_ cool 21:43
quietfanatic Can I introspect signatures soon?
jnthn quietfanatic: Are you wanting to?
quietfanatic Yeah, for Gamebase.
moritz_ we already won a few thousand tests since last release thanks to colomon++'s tireless testing and implementing the trigonometric functions
jnthn quietfanatic: It needs a spec. I'll try and get one proposed.
quietfanatic Alright! :) 21:44
moritz_ but pmichaud hasn't updated the spectest graph to show it :)
jnthn quietfanatic: And a prototype implementation. Then you can play with it and see how it feels. :-)
21:44 EvanCarroll joined
moritz_ jnthn: care to push that branch to github? 21:44
quietfanatic I want to say "event multi method collision ($target) { ... }"
moritz_ git push origin $yourbranchname
quietfanatic and have it look at the signature to see when to call the event.
EvanCarroll I'm banned from irc.perl.org, thanks to mst. I wanted to submit a bug about parrot.org site though 21:45
You can't see the comments unless you're logged in. If you click on a post, you always get the same prompt, "login or register to post comments." Upon, logging in you'll be prompted with a box to enter your comment, if it is your first time you're OK. However, if you've already posted and you're looking for your old comment you'll be inclined to retype and resubmit. When you resubmit you'll be brought back to the post, this time logged in, and you'll se
quietfanatic Hmm.
jnthn moritz_: done.
quietfanatic I don't know if this is the right place for a parrot.org bug report.
moritz_ EvanCarroll: please get a track account account, and submit the ticket at trac.parrot.org/parrot/newticket 21:46
EvanCarroll Well, again I'm klined from irc.perl.org, so someone will have to cross post if they care
moritz_ EvanCarroll: your message was truncated due to IRC limitations 21:47
21:47 lumi joined
jnthn moritz_: I plan some clean-up in the PIR files, this was more a "get the stage 1 compiler to run again" jobby. :-) 21:47
EvanCarroll moritz_: is there an email address for the trac bugs? 21:48
moritz_ EvanCarroll: no, you have to use the web interface
at least for submission
EvanCarroll trac--
21:50 EvanCarroll left
moritz_ rakudo: sub a($a, $a) { } 21:54
p6eval rakudo 30e2cf: ( no output )
moritz_ rakudo: sub a($a, $a) { $a + $a }; say a(2, 3)
p6eval rakudo 30e2cf: OUTPUT«6␤»
jnthn std: sub a($a, $a) { } 22:00
p6eval std 28657: OUTPUT«Potential difficulties:␤ Useless redeclaration of variable $a (from line 1) at /tmp/kO9C5VJP5r line 1:␤------> [32msub a($a, [33m⏏[31m$a) { }[0m␤ok 00:01 97m␤»
jnthn only a warning, huh. 22:01
diakopter rakudo: my $a + $a 22:03
p6eval rakudo 30e2cf: OUTPUT«Use of uninitialized value␤Use of uninitialized value␤»
diakopter std: my $a + $a
p6eval std 28657: OUTPUT«ok 00:01 97m␤»
diakopter hrm
sprixel: my $a + $a
p6eval sprixel 28657: OUTPUT«Sprixel Error: TypeError: Cannot call method 'add' of undefined␤»
moritz_ unlike in perl 5, a declaration make the variable visible immediately
22:06 takadonet left
diakopter rakudo: sub a ($b, $c = $b, $b = $c) { $b + $c }; say a 5 22:07
p6eval rakudo 30e2cf: OUTPUT«Null PMC access in isa()␤in sub a (/tmp/eHTYynJY4L:1)␤called from Main (/tmp/eHTYynJY4L:0)␤»
diakopter rakudo: sub a ($b = $b) { }; say a 22:10
22:10 FOAD_ joined
p6eval rakudo 30e2cf: OUTPUT«Null PMC access in isa()␤in sub a (/tmp/DalKSx8DVO:1)␤called from Main (/tmp/DalKSx8DVO:0)␤» 22:10
jnthn heh 22:11
diakopter: Feel free to file rakudo bug, though I suspect those may be known.
Expect they're fixable in the new binder.
moritz_ this one is 22:13
masak++ reported it about a week ago 22:14
22:18 am0c joined 22:26 nihiliad joined 22:48 lmc joined 23:05 payload joined 23:12 ShaneC joined
ShaneC does rakudo have a way to check for errors or exceptions from an eval? 23:12
Juerd ShaneC: It's in $! 23:13
ShaneC thanks
jnthn rakudo: eval('lol'); say $! 23:14
p6eval rakudo 30e2cf: OUTPUT«Could not find non-existent sub lol␤»
jnthn rakudo: eval('die "omfg lol"'); say $! 23:15
p6eval rakudo 30e2cf: OUTPUT«omfg lol␤»
jnthn :-)
ShaneC awesome job on rakudo btw ;-) giving p6 a serious shot for the first time and really enjoying it! 23:19
Juerd \\o/ 23:20
ShaneC hopefully once i catch up on my p6 i'll get some time to actually help with rakudo
Juerd agrees that rakudo is awesome
jnthn ShaneC: Glad you're finding Perl 6 fun. :-)
It's a fun language to use, and to implement. 23:21
Though maybe different kinds of fun. ;-)
23:23 FOAD_ joined
quietfanatic The fact that neither caller() nor $?FILE seem to work in Rakudo is making it hard to cache generated code. 23:42
Tene eh? how are those related? 23:43
ShaneC why do you need those two cache generated code?
to*
quietfanatic To save it in a file related to either the module or the calling program.
ShaneC ah, thought you meant caching in memory
Tene quietfanatic: what information do you need, exactly? 23:44
quietfanatic Ah, yeah, I meant disk. :)
Preferably, the name of the program that use'd this module.
If not, at least the directory the module is in.
Tene quietfanatic: will some embedded PIR be acceptable? 23:49
quietfanatic For now, yeah.
Tene kk
quietfanatic (incidentally, most of my generated code is embedded PIR) 23:50
lisppaste3 tene pasted "fetch the filename of the caller" at paste.lisp.org/display/88361 23:54
Tene quietfanatic: will that do?
erm, drop the .local pmc and loop: 23:55
of course
quietfanatic I fugyred :)
er...
Tene I was going to take a different approach, but simple is better.
quietfanatic *figured
%r is the return value or something?
Tene yes 23:56
so you use: $filename = Q:PIR { ... };
quietfanatic I see. Thanks!
Tene np
doesn't look like that gives you a path, just whatever filename you called the program with 23:57
"./foo.pl" in my case

Powered by Cro and the Raku® Programming Language.

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

Thank you!