»ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: , or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by diakopter on 25 January 2010.
quietfanatic rakudo: say 3 00:00
p6eval rakudo 324f56: OUTPUT«3␤»
quietfanatic huh
oh nvm 00:01
dalek kudo/master: e7a395b | jonathan++ | t/spectest.data:
Add S06-signature/tree-node-parameters.t to spectest.data.
 00:02
kudo/master: 5d43a30 | jonathan++ | docs/ROADMAP:
Move unpacking arguments to completed section of ROADMAP.
00:03 aindilis left, aindilis joined
lue hello jnthn. 00:04
(a lot of things have been timing out today,weird)
jnthn hi lue
Yeah, it happens now and then.
00:05 supernovus left
lue ...oops. I missed the ping-pong ball. What's gonna happen? o.o 00:06
00:11 masak joined
masak rakudo: say (4..^5).perl # should be 4 3 2 1 0 1 2 3 4, according to TimToady 00:12
phenny masak: 17 Feb 22:04Z <TimToady> tell masak r29770 answers your take question; resumably exceptions don't trigger LEAVE blocks
lue Hello masak! o/
p6eval rakudo 5d43a3: OUTPUT«4..^5␤»
masak heh :)
lue: hi! :)
rakudo: say (4...^5).perl # should be 4 3 2 1 0 1 2 3 4, according to TimToady
p6eval rakudo 5d43a3: OUTPUT«Method 'perl' not found for invocant of class 'GatherIterator'␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
masak ooh! 00:13
masak submits rakudobug
rakudo: my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to TimToady
p6eval rakudo 5d43a3: OUTPUT«[4, 3, 2, 1]␤»
masak submits rakudobug
two flies with one stone! nice!
s/flies/birds/ # wrong language 00:14
diakopter birds > flies
masak diakopter: hello.
lue More like two grains of sand in one Perl :)
jnthn lolitsmasak
diakopter could not find nonexistent sub &hello
masak I'm onlt here to turn backlogs into rakudobugs. 00:15
s/t/y/
then I'm off to sleep.
diakopter yurn those bugs
oh, onlt
masak you can look forward to my '1024 Rakudobugs' talk in 2011 :) 00:16
or 2012, depends on how many bugs we turn up.
diakopter 2048, too 00:17
masak diakopter: my guess is that the second 1024 will be *much* tougher.
but yes, sure. I'll give a '2048 Rakudobugs' talk, if I ever amass that many rakudobugs.
jnthn rakudo: Rat.^add_method('lol', method ($what) { say "lol$what" }); 3/4.lol('cat') 00:18
p6eval rakudo 5d43a3: OUTPUT«lolcat␤»
diakopter by then it will be "second system syndrome done even better"
masak: I meant 2048 A.D.
jnthn \o/
masak diakopter: that was less than clear. even knowing you did, I have trouble mapping your ', too' to something. 00:19
diakopter rakudo: Rat.^add_method('lol', method ($what) { say "lol$what" }).lol('cat')
p6eval rakudo 5d43a3: OUTPUT«Null PMC access in find_method('lol')␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
masak submits rakudobug
jnthn fwiw, that's not supposed to work. :-)
(shouldn't npmca, though)
masak bla bla bla Null PMC access bla bla... yes
rakudo: Rat.^add_method('x', method () {}).x 00:20
p6eval rakudo 5d43a3: OUTPUT«Null PMC access in find_method('x')␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
00:20 rgrau left
jnthn masak: It's just that it's a method written in PIR with no .return 00:21
masak :)
jnthn We either need (a) a blanket solution or (b) to go and find/tweak each method/sub that does that
masak reads that as "It's just that it's a [black box]"
jnthn Or ot write less in PIR :-)
*to
No, it's quite hackable on. :-) 00:22
00:22 sjohnson sets mode: +o jnthn
masak jnthn: hey, I don't tell you the specifics of bug submitting! :P 00:22
00:22 sjohnson sets mode: +o masak, sjohnson sets mode: +o TimToady
masak sjohnson: thanks. it'll wear off soon, though. :/ 00:22
sjohnson :)
jnthn masak: :-P
lue How to submit a bug:
jnthn 1) summon masak
lue 1) Find HypnoGlasses
2) Find Bug
3) Submit Bug (to your will) 00:23
masak you make it sound so sterile and clinical.
it's an Art, see.
jnthn At least you get HypnoGlasses.
jnthn ponders writing a quick blog post
00:23 Juerd joined
Juerd rehi 00:23
jnthn Juerd: ohhai 00:24
00:24 sjohnson sets mode: +o Juerd
lue it's a pun. 00:24
sjohnson so many familiar faces all at once!
Juerd We had lots of packetloss earlier today. Replacing the fiber patch didn't help, replacing the SFP didn't help, replacing the switch did help.
masak lue: I've submitted puns as rakudobugs, too :)
Juerd Sorry for the outages :)
masak rakudo: (1..2).perl
p6eval rakudo 5d43a3: ( no output )
masak rakudo: (1..^3).perl 00:25
p6eval rakudo 5d43a3: ( no output )
lue Bolton is a pun as well :D
jnthn Juerd++ # thanks for fixing!
masak rakudo: (1...2).perl
p6eval rakudo 5d43a3: OUTPUT«Method 'perl' not found for invocant of class 'GatherIterator'␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
diakopter rakudo: //\// 00:27
p6eval rakudo 5d43a3: OUTPUT«Null regex not allowed at line 11, near "\\//"␤current instr.: 'perl6;HLL;Grammar;panic' pc 500 (ext/nqp-rx/src/stage0/HLL-s0.pir:328)␤»
masak lue: maybe bolt on the hypnoglasses, that way one doesn't have to find them each time.
diakopter: that is a null regex, you know. 00:28
diakopter which one
jnthn std: //\//
masak that last one.
lue masak: oh no, no, its... a palindrome!
p6eval std 29773: OUTPUT«===SORRY!===␤Null regex not allowed at /tmp/T98DvESUDL line 1:␤------> //⏏\//␤FAILED 00:01 105m␤»
jnthn \o/ 00:29
masak lue: 'bolton' is *not* a palindrome.
jnthn notlob
lue masak: you never see the Monty Python dead parrot sketch, have you?
masak sure I did. 00:30
oh :)
lue "The palindrome of Bolton is Notlob!" said John Cleese
masak ok. fair enough.
TimToady std: say "foo" ~~ / <+<alpha> - [A..Za..z] >+ /
p6eval std 29773: OUTPUT«===SORRY!===␤Unrecognized regex assertion at /tmp/i8E3BA11Rb line 1:␤------> say "foo" ~~ / <+⏏<alpha> - [A..Za..z] >+ /␤ expecting character class element␤FAILED 00:01 107m␤»
TimToady std: say "foo" ~~ / <+alpha - [A..Za..z] >+ /
p6eval std 29773: OUTPUT«ok 00:01 106m␤»
TimToady pausenclown: ^^^
masak rakudo: sub is_palindrome($s) { $s eq $s.flip }; say is_palindrome('bolton') ?? "YEA" !! "NO WAI" 00:31
TimToady rakudo: say "foo" ~~ / <+alpha - [A..Za..z] >+ /
p6eval rakudo 5d43a3: OUTPUT«NO WAI␤»
rakudo 5d43a3: OUTPUT«␤»
TimToady rakudo: say "f00" ~~ / <+alpha - [A..Za..z] >+ /
p6eval rakudo 5d43a3: OUTPUT«␤»
diakopter rakudo: say "___" ~~ / <+alpha - [A..Za..z] >+ /
p6eval rakudo 5d43a3: OUTPUT«___␤»
TimToady rakudo: say "föö" ~~ / <+alpha - [A..Za..z] >+ / 00:32
p6eval rakudo 5d43a3: OUTPUT«öö␤»
masak föö?
jnthn rakudo: say "fl" ~~ / <+alpha - [A..Za..z] >+ /
p6eval rakudo 5d43a3: OUTPUT«␤»
jnthn gah
masak that's like the Swedish version of 'foo'.
TimToady masak: pronounced the same as 'feh'?
jnthn rakudo: say "öl" ~~ / <+alpha - [A..Za..z] >+ /
p6eval rakudo 5d43a3: OUTPUT«ö␤»
jnthn
.oO( why yes, that is the only Swedish word I know with ö in it )
masak TimToady: no, more like 'fur', actually.
diakopter or 'pho' 00:33
lue rakudo: sub is_palindrome($s) {$s eq ($s.flip | "notlob")}; say is_palindrome('bolton') ?? "YEA" !! "NO WAI"
p6eval rakudo 5d43a3: OUTPUT«Method 'Str' not found for invocant of class 'Junction'␤current instr.: 'perl6;Mu;' pc -1 ((unknown file):-1)␤»
lue :/
masak lue: nice try.
TimToady I was thinking Deutsch, not Svensk
masak 'Svenska' for the language.
TimToady ah 00:34
diakopter rakudo: say try try try die die die
p6eval rakudo 5d43a3: OUTPUT«Null PMC access in type()␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
masak (since the full phrase is 'svenska språket')
diakopter++
masak submits rakuodbug
at this rate I'll never get back to bed.
jnthn Getting up to submit bugar? That's dedication! 00:35
masak better believe it.
('buggar')
jnthn aww
lue considers calling it rakuda-do just to bug everyone
jnthn masak: bugg singular? 00:36
masak yes.
jnthn Ah, phew. :-)
Not scary pluralization fun. :-)
masak not in this case.
jnthn parsed that as grammatical case at first 00:37
masak maybe that's what I meant... :P 00:38
TimToady if you want to bug us you'd have to call it chouchou-do
masak whatever that is, it sounds cute. 00:39
rakudo: try die
p6eval rakudo 5d43a3: ( no output )
masak rakudo: try try die
p6eval rakudo 5d43a3: ( no output )
masak rakudo: try try die die
p6eval rakudo 5d43a3: ( no output )
lue alpha: die
TimToady 'course, that's not to say that a rakuda doesn't have bugs...
p6eval alpha 30e0ed: OUTPUT«No applicable candidates found to dispatch to for 'die'␤in Main (file <unknown>, line <unknown>)␤»
masak rakudo: say try die
p6eval rakudo 5d43a3: OUTPUT«Null PMC access in type()␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
masak ah.
TimToady masak: Way of the Butterfly 00:40
well, actually chouchou-dou
chōchōdō 00:41
masak 蝴蝶道 in Mandarin.
TimToady yeah, but they pronounce it wrong :) 00:42
masak uhn.
rakudo: say try {} 00:43
p6eval rakudo 5d43a3: OUTPUT«Null PMC access in type()␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
jnthn We should really try to do better with that construct. :-/
masak rakudo: my $a = try {}
00:43 quietfanatic left
p6eval rakudo 5d43a3: OUTPUT«Null PMC access in can()␤current instr.: '&infix:<=>' pc 16112 (src/builtins/Junction.pir:207)␤» 00:43
TimToady 蝶蝶道 in Japanese
jnthn Yeah, it's all the same underlying bug. :-|
masak jnthn: just checking.
TimToady also just 蝶道 00:44
masak (and had I not realized it's all the same underlying bug, you'd have seen more '* masak submits rakudobug' fly by)
TimToady it's flies now is it?
masak sorry, birds. 00:45
diakopter albatrosses
or macaws
TimToady you can say that again
diakopter with a lodestone, even 00:46
masak rakudo: say 'albatrosses. or macaws.'.comb.Bag<a> 00:47
p6eval rakudo 5d43a3: OUTPUT«Method 'Bag' not found for invocant of class 'GatherIterator'␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
masak rakudo: Bag
p6eval rakudo 5d43a3: OUTPUT«Could not find non-existent sub &Bag␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
masak makes note 'implement Bag'
lue aɪ θeɪŋk θɪs ɪs ɑːnɔɪɪŋ 00:48
masak lue: I agree. it is.
but it's scary that I can read it. :/
lue masak: It took me forever to write that. How do you...? 00:49
diakopter rakudo: .say for $_
p6eval rakudo 5d43a3: OUTPUT«Missing block at line 11, near ""␤current instr.: 'perl6;HLL;Grammar;panic' pc 500 (ext/nqp-rx/src/stage0/HLL-s0.pir:328)␤»
masak lue: permanent brain damage, I suppose.
diakopter std: .say for $_
p6eval std 29773: OUTPUT«ok 00:01 106m␤»
masak lue: also, I'm quite tired. that helps.
masak submits rakuodbug
diakopter: oh, for...! :)
diakopter ..how wide and how deep..
what's this new rakuodbug 00:50
masak diakopter: the one you just p6eval'd?
with '.say for $_'? 00:51
diakopter just got '<@TimToady> you can say that again'
masak oh wait. I don't need to submit that.
masak stands down
statement_mod_loop for are known to be TODO.
diakopter oh
masak and the spectests will catch them. 00:52
lue IPA is a great way to `encrypt' messages (like ROT13 back in the day).
The translator (for english) would be hell to program, though. :D
Juerd jnthn: Haven't actually done anything myself, except watch and provide coffee to the externel engineer who did fix it 00:54
masak ok, good night, people. o/ 01:07
01:07 masak left
lue good night, masak o/ 01:08
01:09 xomas left 01:10 ihrd joined, ihrd left
lichtkind good nicht 01:18
01:18 lichtkind left
jnthn -> sleep, ngiht 01:19
*night
lue g'night o/ 01:20
or is it this hand: \o
01:58 pausenclown left 02:01 lue left 02:06 jferrero left 02:07 justatheory left 02:08 alester left 02:27 rv2733 joined 02:49 ShaneC1 left 02:50 stephenlb left 02:51 mssm left
dalek kudo/master: 351d3d8 | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 172 files, 4816 (29.1% of 16525) pass, 1 fail

S29-conversions/ord_and_chr.rakudo aborted 1 test(s)		 02:55
02:58 cdarroch left 03:10 ggoebel left 03:15 wknight8111 left 03:20 gabiruh_ joined 03:21 cosimo_ joined 03:22 arlinius left, cosimo left 03:26 jaldhar left, gabiruh left 03:27 jaldhar joined 03:32 maerline joined 03:33 athenot left
dalek kudo/master: 1a05eae | pmichaud++ | docs/announce/2010.02:
Add draft 2010.02 release announcement.
 03:35
kudo/master: 9be7890 | pmichaud++ | docs/release_guide.pod:
Update release guide to note that we now use dots instead of hyphens
03:38 azca joined 03:42 nihiliad left 03:51 redicaps joined
azca hello 03:53
colomon hello! 04:02
azca how are you? 04:11
so is there a timeframe for when perl6 will come out?
colomon The regular monthly release is tomorrow. 04:27
There is intended to be a major release two months from now, Rakudo *.
dalek kudo/master: b4824f3 | (Solomon Foster)++ | t/spectest.data:
Turn on trig tests.
 04:33
azca does major release mean the final release (i.e. not beta) 04:37
colomon no. 04:38
We haven't really been thinking in alpha/beta terms, but this release is intended to be more of a stepping stone. 04:39
azca will perl6 interpreter be compatible at all with perl5 code?
colomon a point where people will be able to jump on and do useful things with it, but by no means "done".
04:40 Trashlord joined
colomon None of the current p6 implementations are working on p5 compatibility at all at the moment. 04:40
azca ok 04:41
is there a link to some info on difference (or new features) of perl6 versus perl5? or is it still very early in development phase?
colomon It's planned to come along eventually, but I would suspect p5 support in p6 is a couple of years off. 04:42
Hmmm... I'm not aware of a summary page.
perl6.org has a lot of info.
perlgeek.de/en/article/5-to-6 04:43
perl6advent.wordpress.com/2009/12/0...-calendar/ gives a lot of examples of cool stuff in Perl 6.
I need to be getting to bed. Good luck! 04:44
azca cool thank you 04:45
04:45 maerline left
azca I will check those out 04:45
04:46 azca left 04:47 needlinux joined 04:54 needlinux left, kcwu joined 04:55 rv2733 left 04:56 kcwu left 04:58 kcwu joined 05:02 arlinius joined 05:03 lue joined
lue please respond if you are of existence. 05:06
Trashlord define existence 05:07
lue thank you. Anyone else?
05:09 tylerni7 left
lue I really would like to ping-timeout everyone who stays logged on w/o so much as marking themselves as away. 05:10
I'm guessing ≈90% of the logged in people (read: PEOPLE, not bots) are not here. 05:11
05:13 kcwu left 05:14 kcwu joined 05:51 lue left
TimToady my existence comes and goes randomly 05:58
s1n lue seems harsh, i frequently lurk, mainly because i don't have much to add but enjoy the conversations 06:04
bkeeler I'd forgotten about the /away command 06:14
06:18 aindilis left
vamped no, it's just that the rest of us are pondering existence 06:26
06:53 kaare joined, kaare is now known as Guest68103 06:55 [synth] joined 06:57 synth left 06:59 viklund left 07:13 uniejo joined 07:14 Su-Shee joined
Su-Shee good morning 07:14
07:21 cjk101010 joined 07:23 am0c joined 07:28 tusooa__ joined, tusooa__ left, Su-Shee left 07:30 Su-Shee joined
sjohnson hi 07:46
07:51 iblechbot joined 08:13 [particle] joined 08:14 bkeeler left
mathw Good localtime, #perl6 08:17
vamped o/ 08:20
08:24 clausi joined 08:25 wanradt_ left 08:26 [particle] left 08:50 mssm joined
moritz_ good morning 08:52
08:54 dakkar joined
mathw hai moritz_ 09:01
moritz_ wonders why the charts on rakudo.de are not updated 09:02
ah, 'git pull' was reporting that I was in the middle of a conflicting merge. Tough beans. 09:04
mathw :( 09:15
09:25 jferrero joined 09:27 vamped left 09:36 Woody2143 joined, Schwern joined 09:53 crazed left 10:05 crazed joined 10:13 payload left 10:14 johnz left, johnz joined 10:22 masak joined
masak oh hai, #perl6. 10:22
moritz_ oh hai 10:23
10:25 orafu left
masak ooh, jnthnhazblogged! 10:26
10:26 orafu joined
moritz_ urlz? 10:26
masak use.perl.org/~JonathanWorthington/journal/40190
moritz_ kthx 10:30
masak np 10:32
10:51 ruoso left
masak by some cosmic coincidence, the most vehement Perl 6 haters on Twitter often turn out to be Python people. 10:53
by another cosmic coincidence, those who dislike Camelia at first sight are invariably men, and those who like Camelia at first sight are very often women. 10:55
jnthn oh hai 11:00
masak o/
jnthn++ # nice blog post
jnthn ooh...my blog post had a noticed!
moritz_ and at least two readers :-)
masak three, if you count the Python Twitterer :) 11:01
he said this: twitter.com/robotpony/status/9265036226 -- I asked this: twitter.com/carlmasak/status/9278573748 -- no reply yet. 11:02
'debates' over Twitter, or any situation where two people differ in opinion, don't have a high chance in changing anyone's mind. but it's still an interesting exercise to try to be coherent in 140 chars. 11:03
11:03 gfx joined
masak in this case, he will reply 'no, my criticism is that they rewrite all the time without shipping anything' 11:04
and I will say 'Rakudo has had 25 releases, and will have its 26th release today' 11:05
jnthn I love how people with no experience working on a Perl 6 compiler seem to think they have something wrothwhile to say about how to go about developing one.
masak and he will say 'no, I mean a REAL release, one where you ship production-ready stuff, like Python 3000'
11:05 xalbo joined
masak jnthn: perhaps the general rule is that the farther away you're standing from a given effort, the easier and more obvious it seems. 11:06
jnthn :-)
11:07 meppl joined
masak that would explain the vehemence of the Python people, too. whereas regular people are just an indeterminate distance from Perl and Perl 6, Python people are in a culture where being far away from Perl is culturally rewarded. 11:09
mathw It is interesting how the culture has lined up as showing Perl and Python worlds as being very different 11:10
jnthn It's convenient how we chose to ignore the point in my post that all of the changes were in order to do things on the roadmap to a release. 11:12
11:12 mathw sets mode: +o masak
mathw I guess from my perspective, I've watched this happen so I just know why all this was done 11:12
I have no need to even think about the reasoning
jnthn s/we/he
11:13 Schwern left
masak jnthn: yeah, why you have to rewrite all the time so you can reach the promised deliverables? it makes no sense! :P 11:13
mathw Of course on the other side of things, when you're watching the camel train from the top of a nearby mountain through a dirty telescope, you're going to miss things
jnthn: why can't you just write it properly the first time? What kind of stupid amateur coder are you?
*cough* Python's OO support *cough* 11:14
hey I'm arguing with an imaginary version of myself
it must be Thursday
What's best is knowing that Rakudo is moving in the right direction, and that you're not afraid to take a regression in order to get the core set up to move on. 11:17
I wish we could do more of that at work.
jnthn I decided quite a while ago that a bredth-first approach was, by and large, a good way to approach Perl 6 implementation.
mathw breadth-first? I'm not sure how to envisage that on a language implementation 11:18
moritz_ many features first 11:20
jnthn mathw: Kinda like, "Get a first cut of many language features, then incrementally improve them/fill them out/make them more complete"
As opposed to "focus on getting the whole of one feature done first"
mathw Ah yes, that way
It helps you make sure you have room for all the stuff you've not done yet
Without having to spend a year or two designing the system on paper 11:21
jnthn Well, more important to me was that it meant it was a shorter time before we had something people could actually start to use.
mathw that's important too
especially when you're working on a language spec that's still in flux and untested in practical use
the same value which we got from Pugs 11:22
colomon o/
jnthn Yes, IIRC Pugs also went through a process of quite a few refactors.
mathw yes I believe it did 11:23
I always wanted to get involved, but never quite got round to it 11:24
would've been a good place to play with my Haskell knowledge though
colomon has anyone tried running spectest since I turned ontrig last night?
it made my machine crawl when I ran it last night.... 11:25
jnthn colomon: not yet
11:26 pmichaud joined
dalek kudo/master: 303323e | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 194 files, 24167 (67.6% of 35727) pass, 0 fail
 11:28
jnthn 'tis early for a pmichaud! :-)
colomon I guess pmichaud has run it. :)
11:28 mberends_ joined
jnthn colomon: running it here. 11:28
moritz_ also run it 11:29
pmichaud yes, pmichaud up early today
but may head back to bed shortly
11:29 moritz_ sets mode: +oo pmichaud colomon, moritz_ sets mode: +v dalek
mathw 24,167 pass? that's not bad 11:29
jnthn Yeah :-) 11:31
Lots of trig tets
*tests
masak lunch &
11:31 masak left
jnthn pmichaud: Did you re-enable the \c[...] ones too? 11:31
moritz_ did
mathw \o/ 11:32
this is quite an exciting release coming up
moritz_ at least some of them - not sure
pmichaud jnthn: I didn't re-enable the \c[...] ones yet
moritz_ (charts on rakudo.de are updated btw)
pmichaud we can probably re-enable some of S05-mass, though.
moritz_ d5d58cc77e5ec2cd433012585f331455a4d7a6d3 enabled char-by-name.t 11:33
jnthn pmichaud: Wonder fi there's a quick fix for
rakudo: say 'foo' ~~ /o/; # works 11:34
p6eval rakudo b4824f: OUTPUT«o␤»
jnthn rakudo: say 'foo' !~~ /o/; # fails
p6eval rakudo b4824f: OUTPUT«logical_not() not implemented in class 'Capture'␤current instr.: 'perl6;Mu;REJECTS' pc 2008 (src/builtins/Mu.pir:370)␤»
pmichaud looking
jnthn pmichaud: That's what stops S05-mass/rx.t working.
Well
5 tests into it.
I already re-fudged it to remove compile fails. 11:35
mberends_ was there a popular suggestion for doing a deep test only sometimes, and keeping the spectest short (without lots of trig)? I can afford only so much testing time, and making long spectest runs results in me not running them as often, which is a loss. The trig usually seems to pass anyway, so re-testing seems to waste a lot of time.
moritz_ S05-mass/named-chars.t fails with regex assertion not terminated by angle bracket at line 31, near "]>/, 'Char" 11:36
jnthn mberends_: Yes, that topic seems to be coming up quite a bit of late. :-)
So I think there's something in it. :-) 11:37
mathw just take that go_slow() function out of Parrot
mberends_ jnthn: low me as the 3rd (or is it 4th) reader of you blog post ;) nice one, btw 11:38
*log
colomon the trig tests were a lot less relatively painful when the rest of the spectest took more than a half hour. :)
pmichaud ooc, are the trig tests slow due to parsing or execution? 11:39
has anyone checked?
colomon almost certainly execution
mberends_ colomon, do the trig tests detect fails from time to time, or do they almost always pass?
pmichaud (detect fails) I suspect it's too soon to tell in ng :)
mathw jnthn: for the record, I read your blog post before it was even mentioned in here :)
colomon once working they tend to continue to work 11:40
pmichaud > say 'foo' !~~ /o/;
0
mberends_ I expected as much
jnthn Yay
colomon afk
pmichaud until/unless we can get overall speed improvements, I'm in favor of two-tier (or multi-tier) spectesting 11:41
*generally in favor
mberends_ +1
moritz_ is in favour of speed improvements 11:42
mathw buys everyone a faster computer. job done.
pmichaud well, I'm in favor of speed improvements also, but those are a bit harder :)
mathw and it's features first 11:43
I seem to recall
mberends_ shorter edit+test cycles === more productivity
mathw true
moritz_ mathw: to a certain extend, yes. But Rakudo * was supposed to be usable and useful
jnthn I reckon the !to-radians and !from-radians are probably kinda slow, fwiw.
pmichaud well, even now -- I just did a 1-line change to fix the bug jnthn++ just mentioned, but we'll have to wait 30 minutes for me to commit+push :)
mathw moritz_: true, but I'm not sure I ever believed it would run fast 11:44
moritz_ mathw: yes, but now you're not talking about goals anymore, but about believe
mathw True 11:45
And it would be nice if it went faster.
pmichaud I agree, slowness must be because of execution speed 11:47
(for trig.t)
we really ought to be able to improve that quickly-ish
pmichaud decides to go take a look 11:48
colomon The big LHF for that (I think) is replacing the Str $base arguments with an enum. 11:50
Right now, almost every trig test requires the construction of a Str and at least two regex matches.
seems like that must be a lot slower than just passing around enums would be. 11:51
pmichaud well, on my system it also appears to be eating up a fair bit of memory
colomon pmichaud: same here. around a gig a test file, I think....
11:52 payload joined
arnsholt While waiting for enums you could fudge it by passing around numeric constants, like C tends to do, perhaps? 11:52
pmichaud we can certainly define the constants in the same way we do 'pi' and 'e'
jnthn pmichaud: I've just tried re-writing to-radians and from-radians to measure what that wins.
(will report back when I has numbers) :-) 11:53
pmichaud yes, it's almost certainly execution speed. parsing+compiling only takes a few seconds
jnthn cos.t here has passed the 600mb point. :-/ 11:54
mberends_ the memory consumption is usually Parrot avoiding garbage collection delays, by just growing the heap instead of recycling released objects, I think.
colomon arnsholt: good idea! 11:55
pmichaud oh, given/when can also be a bit slow.
colomon I've been figuring enums were going to land any day (masak++) so hadn't given much thought to working around them.
pmichaud (doesn't mean we shouldn't use it, but it does incur some exception handling overhead)
mathw :( 11:57
given/when is one of my favourite things
colomon pmichaud: given that (groan), perhaps optimizing for the radians case would make sense?
pmichaud when /:i degrees/ { self * (312689/99532)/180.0 } # Convert from degrees.
when /:i gradians/ { self * (312689/99532)/200.0 } # Convert from gradians. 11:58
when /:i radians/ { self + 0 } # Convert from radians.
when Num { self * 2.0 * (312689/99532) } # Convert from revolutions.
...any chance we could pre-fold those constant expressions?
colomon pmichaud: don't see why not.
pmichaud that would save a lot of time, since we end up computing constant Rats
colomon needs to remember that not all compilers automatically pre-fold.... ;)
pmichaud jnthn: did you do the .lc trick to avoid the regex matches? 11:59
personally, I think we don't even need the .lc :-)
jnthn pmichaud: yup 12:00
pmichaud: And stopped using given/when
colomon I really like arnsholt++'s idea of just making temporary constants for TrigBase.
pmichaud oh, also, if radians is the common case, we should test it first
colomon pmichaud: in testing, anyway, radians happens twice as often as any of the other cases.
pmichaud since radians is the default, it should be handled first
mberends_ ;-) even Bill Gates knew that programming trick ;-) 12:01
moritz_ when we use enums, we can give them the numerical values 0..$n
then use an array of numerical constants, and index them by enum value
pmichaud also, I wonder how much slowness is being introduced by the test itself 12:02
colomon moritz_: er, if we patched in constants now, we could do that today, no?
moritz_ colomon: er, right
colomon pmichaud: yes, the tests are less than efficient as well.
pmichaud I think it's worthwhile to patch in constants right away
colomon +1
pmichaud especially since "make spectest" is currently making my computer unusable. 12:03
mathw sounds like a sensible idea
but better is the one that has me going to get some lunch
&
colomon pmichaud: ah, so that wasn't just my test run last night that was like that. :(
jnthn Before: 276s 12:04
pmichaud who'll work on the constant conversions? I'm willing to do it if nobody else is eager.
jnthn After: 238s
pmichaud good improvement but not huge
jnthn Those ones simply by getting rid of given/when and using a sequence of ?? !!
colomon pmichaud: I think I can do it, and that would free you up for something else.
jnthn pmichaud: No, though add reordering + constant folding as well may together get it further down.
12:06 patspam left
colomon I 12:06
I'll bet we can get it below 200s on your system in an hour.
jnthn colomon: gist.github.com/307599 12:07
moritz_ putting a 'constant radians = 0;' on top of Any-num.pm doesn't make that available in the Perl 6 program 12:09
12:10 SmokeMachine joined
pmichaud I'm not sure 'constant' is implemented yet. 12:10
jnthn I don't think it is, no
moritz_ rakudo: constant a = 3; say a;
p6eval rakudo 303323: OUTPUT«Could not find non-existent sub &a␤current instr.: '_block14' pc 29 (EVAL_1:0)␤»
pmichaud but one can do it in PIR like was done for 'pi' and 'e'
colomon compiling that now, as a matter of fact. :) 12:11
moritz_ will have to leave soon 12:12
mberends_ Generally, testing time should be of the same order of magnitude as editing and compiling (within a factor of 2 or so) to not become the dominant bottleneck. If the trend of escalating test times continues, we should consider alternative development and testing workflows. For example, a subset of spectests could be the requirement before Rakudo commits. Or otherwise, our commits go to a staging system that thoroughly tests each commit before passing it th 12:13
rough to the main codebase. I don't know the answer, but the trend bothers me a lot.
colomon > say Radians 12:16
0
> say Degrees
1
> say Gradians
2
> say Circles
3
pmichaud ...shouldn't those be in a namespace, ooc?
pmichaud hasn't read the latest spec 12:17
12:17 athenot joined
pmichaud guess not -- they're exported 12:17
moritz_ thought they were in an enum
colomon pmichaud: I copied and pasted your pi code.
they are in an enum by Spec
pmichaud enum TrigBase is export <Radians Degrees Gradians Circles>;
I was just wondering if "Radians" as a bareword would be recognized in any scope. Looks like "yes". 12:18
moritz_ so if you have a name clash, you can refer to them as TrigBase::Radians
dalek kudo/master: fa44b5a | pmichaud++ | src/builtins/Mu.pir:
Update .REJECTS to avoid logical_not vtable.
 12:19
12:20 iblechbot left
pmichaud just to give a lower-bound -- after short-circuiting the cos() and acos() functions to basically be no-ops, cos.t runs on my system in 55 seconds 12:21
(but also segfaults... hmm)
colomon okay, sin.t takes 2m20 on my system before changes 12:22
12:22 athenot left
pmichaud tries sin.t for comparison 12:22
colomon what's the cleanest way to make an array once for both to-radians and from-radians to use? 12:24
pmichaud our @array ....
sjohnson mine!
pmichaud or if you want it private, our @!array ...
(sin.t = 2m12 on my system) 12:25
colomon can I initialize it in the our statement?
pmichaud might want to use an INIT block to begin with
I'd try it without -- if that doesn't work then try with.
12:28 Lorn joined, Lorn left, Lorn joined
colomon wow, you know that feeling you get when you know your code is right? 12:28
12:29 Lorn left, Lorn joined
lisppaste3 colomon pasted "Current experimental versions of to-radians and from-radians" at paste.lisp.org/display/95170 12:29
colomon Of course, that doesn't work currently.... ;) 12:30
pmichaud well, that shold end up being a lot faster if only because the values are all Num instead of Rat
*should
12:32 Chandu joined
colomon > say sin(180, Degrees) 12:33
1.22464679914735e-16
Chandu ls -ltr
clear
hi
pmichaud /: no such file or directory
Chandu hi
12:34 Chandu left
snarkyboojum heh 12:34
12:34 Chandu joined
mberends_ Chandu: hi, this is not Linux! 12:35
Chandu Hi
how do i get started
please help me
mberends_ ok, read a bit of perl6.org and rakudo.org first 12:36
pmichaud afk for a while
Chandu where can i get them
?
12:36 barney joined
mberends_ Chandu, see rakudo.org/how-to-get-rakudo 12:37
Chandu thank u so much
12:37 ruoso joined 12:38 Chandu left
jnthn eww 12:47
jnthn finds Nasty Bug and tries to fix it.
(can't store List and Array proto-objects in a list or array or it tries to flatten them and then NPMCAs.)
12:52 alinbsp joined
lisppaste3 colomon annotated #95170 "Failing attempt to initialize" at paste.lisp.org/display/95170#1 12:53
12:54 araujo left
colomon wait, if my class has our @a, how do I reference it in a method? 12:54
12:54 araujo joined 12:56 redicaps left
jnthn Just as @a should work. 12:56
colomon okay, in that case how do I initialize @a just once? the paste has my current attempt, but that gets me Null PMC access in getprop() when I try to use it.
jnthn :-/ 12:57
Odd.
our @a = (); # may work, but I dunno why our @a doesn't.
colomon nope, same error. 12:59
(and I get the error when I try to use @a in a method, I should add)
13:00 gfx left 13:03 bluescreen joined
colomon seems like our @a just doesn't work -- I just tried using it but initializing it in the methods, and it still gives that error. 13:03
rakudo: say pi / 180.0 13:06
p6eval rakudo fa44b5: OUTPUT«0.0174532925199433␤»
colomon rakudo: say pi / 200.0
Juerd Tonight our network will be down between 3 and 4 CET. www.timeanddate.com/worldclock/fixe...&p1=16
p6eval rakudo fa44b5: OUTPUT«0.015707963267949␤»
colomon rakudo: say 2.0 * pi
p6eval rakudo fa44b5: OUTPUT«6.28318530717959␤»
13:06 bluescreen left
jnthn colomon: Hmm. Not sure what's wrong there. :-/ 13:08
rakudo: class Foo { our @a = 1,2,3; method bar() { say @a.perl } }; Foo.bar;
p6eval rakudo fa44b5: OUTPUT«Null PMC access in find_method('perl')␤current instr.: 'perl6;Foo;bar' pc 514 (EVAL_1:207)␤»
jnthn rakudo: class Foo { my @a = 1,2,3; method bar() { say @a.perl } }; Foo.bar;
p6eval rakudo fa44b5: OUTPUT«Null PMC access in find_method('perl')␤current instr.: 'perl6;Foo;bar' pc 505 (EVAL_1:203)␤»
jnthn rakudo: my @a = 1,2,3; class Foo { method bar() { say @a.perl } }; Foo.bar; 13:09
p6eval rakudo fa44b5: OUTPUT«Lexical '@a' not found␤current instr.: 'perl6;Foo;bar' pc 505 (EVAL_1:205)␤»
jnthn wtf
That's probably fairly telling though.
13:10 masak joined
jnthn lolitsmasak 13:11
masak :)
pugs_svn r29774 | jnthn++ | [t/spec] Updates to S12-introspection/parents.t for current spec. 13:12
13:12 athenot joined
masak had I not had $WORK, I'd probably have sat down with named enums today. as it stands, I'll have to save it for tonight. so I'll probably miss the release. :/ 13:12
jnthn masak: Don't worry, there's The Next Release. 13:14
masak aye.
which, by the way, will be Awesome.
jnthn If we can all keep up current pace, the March release should be awesome.
masak :)
and one whole month before the April Star release :)
13:14 takadonet joined
jnthn rakudo: say ('Great minds', 'All fools').pick 13:14
p6eval rakudo fa44b5: OUTPUT«All fools␤»
jnthn damm! 13:15
takadonet hehe
masak the new rakudo is more honest than the last one :P
jnthn :-P
13:15 iblechbot joined
masak rakudo: say 'We are all ', ('expert programmers', 'incompetent hacks').pick, '!' 13:16
p6eval rakudo fa44b5: OUTPUT«We are all incompetent hacks!␤»
masak told ya. :)
.oO( new pick has a more conservative implementation... )
13:16 IllvilJa left
jnthn After spectesting, got fixes that get S12-introspection/parents.t all running and passing again. :-) 13:18
+54 more passing tests. :-)
masak \o/
jnthn Oops...need to remember to have lunch before Slovak class... 13:20
masak I always forget that myself. 13:21
13:21 bluescreen joined
colomon jnthn: I went back to your code, upgrading it with our fake-enum rather than strings and making radians the first casew 13:24
jnthn You have Slovak class too? ;-)
colomon: ah, cool
colomon 1m29 (vs 2m20 originally)
jnthn \o/
Roughly 40% shaved off.
I'll take that. 13:25
colomon and I'm pretty sure I can do better than that by doing sim opts for the test code
though at the moment I'm using computer to play music videos for my boy. :) 13:28
masak jnthn: no, I don't. so for me the statement is vacuously true :) 13:31
13:35 IllvilJa joined
jnthn :-) 13:35
jnthn wonders if the spectests will complete before class so he can push
masak there oughta be a sort of conditional push mechanism. 'run spectests and push if they pass'. 13:37
guess that's not very hard to set up. it's basically making proper use of exit codes.
mberends_ masak: that's a very good idea, worthy of some exploration 13:38
masak mberends_: my unreleased top sekkrit version of tote does that, but on the commit level. 13:39
mberends_ nice. 13:40
masak though it doesn't do it through exit codes, it does it whenever the length of the unbroken chain of passing tests from the start of the test file onwards increases.
using that metric, the system can differentiate between 'regression', 'no apparent change', and 'progress'. 13:41
13:42 coke joined
coke I'm looking at RT# 72914 and the synopses, trying to figure out /why/ that should work that way. Anyone have any pointers to docs that would help explain it? 13:43
(... operator by itself seems to make sense, though it talks about using a function on the RHS. ^ in a range makes sense. putting them together and getting that list makes my head explode.
masak coke: it's not a .. range, it's a ... sequence. 13:45
masak should maybe write C<..> and C<...>.
jnthn heh, tests still going. I'll push when I get back. bbl 13:46
masak jnthn: enjoy the Slovak!
coke masak, yes, I know it's ... and not .. ; my apologies for confusing range and sequence. 13:55
masak coke: just making sure. :)
coke: what exactly is your concern? 13:56
coke (except of course that seems like an easy mistake for someone who doesn't understand how larry's brain works to make.)
masak;... what the hell is it doing?
masak coke: :)
coke why is it going back down to 0 and then up to 5?
masak coke: ^5 counts from 0 up to 4.
it's short for 0..^5
infix:<...>, unless in special circumstances, counts from the left operand to the right operand. 13:57
and those operands may be lists, and the operator will still DTRT.
colomon at least, in some happy far off future day when the operator is sufficiently smart. 13:58
masak so `4 ... ^5` expands to `4 ... 0..^5`, which becomes `4, 3, 2, 1, 0, 1, 2, 3, 4`
13:58 ignacio_ joined
colomon Does that mean if there's list on the RHS, you do ... on the first element and just pass the rest of the list along? 14:01
masak thinks so, yes
colomon that ought to be relatively easy to code, actually. Hmmmm....
masak that's how things like `0 ... 10, 20 ... 100` work
(which yields `0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100`) 14:02
colomon notes that sin.t runs really fast when the first test crashes....
14:02 snarkyboojum left
colomon 1m20 now, another 9 seconds shaved off. 14:06
mathw \o/ 14:10
14:13 ignacio_ left 14:15 [particle] joined 14:16 iblechbot left
coke masak - ok. that almost makes sense. 14:19
when reporting bugs, I don't know if you want to include that sort of information to educate people like me reading the list. =-)
though I'm happy to come here and bug you. =-) 14:20
masak coke: after almost 700 bugs, I'm aware my bug reporting style has become somewhat... streamlined. 14:23
coke: I'm happy to include information about expected semantics, and often do. in thise case, I limited myself to what TimToady had said about it, and didn't delve into excessive details.
14:26 ignacio_ joined, tylerni7 joined, tylerni7 left, tylerni7 joined 14:28 cosimo_ left, cosimo joined
colomon wonders if masak will break 1000 in March... 14:29
masak no chance. :) late this year or early next year is more likely.
my average rakudobug rate is one per day. 14:30
colomon yes, but that's in the old, pre-ng days.
PerlJam colomon: you think ng has increased the number of bugs?
colomon you're in a target-rich environment now, I'm sure you can up your game.
masak colomon: that may be, but that's after a several-month slump of not many new bugs :) 14:31
colomon PerlJam: it has certainly increased the number of unimplemented or partially implemented features. 14:32
masak: sure, but you're at 700 now, right?
masak almost.
so realistically, about a year away from 1024. :)
14:35 ignacio_ left
pugs_svn r29775 | colomon++ | [t/spec] Update trig tests to use the new fake TrigBase. 14:36
pmichaud re-good morning, #perl6 14:37
colomon \o 14:38
shaved something like 45% off of sin.t on my machine so far.
pmichaud that's more reasonable
[particle] i still have to find that presentation, paper, or the source for that test reduction technique 14:39
pmichaud I still wonder what is (was?) causing it to eat so much ram
colomon had a bad time trying to use "our @a" in a class definition, however.
14:40 athenot left, athenot joined
pmichaud really? "our @a" in a class definition should work. 14:40
dalek kudo/master: bf29be0 | (Solomon Foster)++ | src/core/ (5 files):
Optimize Any!to-radians and Any!from-radians, switch default base to Radians (instead of 'radians').
kudo/master: 60c14fe | (Solomon Foster)++ | src/cheats/constants.pir:
Add Radians, Degrees, Gradians, and Circles to emulate what TrigBase will look like when enums are available.
colomon If you look in the backlog, jnthn++ distilled some one-line fails based on what I was trying to do. 14:41
(I managed to erase my backlog here somehow. :( )
pmichaud yes, reading backlog now :)
oh! you might need to repeat the our inside of the INIT block 14:42
colomon irclog.perlgeek.de/perl6/2010-02-18#i_2004325
14:43 [particle] left
colomon pmichaud: am I correct in thinking that the our declaration means there is one copy of the array shared by every instance of the class? 14:44
pmichaud yes
colomon adding our inside the INIT did not help. :( 14:45
pmichaud rakudo: class Foo { say 'here'; method bar() { say 'there'; } }; Foo.bar;
p6eval rakudo fa44b5: OUTPUT«here␤there␤»
pmichaud rakudo: class Foo { my @a = 1,2,3; say ~@a; method bar() { say ~@a; } };
p6eval rakudo fa44b5: OUTPUT«1 2 3␤»
pmichaud rakudo: class Foo { my @a = 1,2,3; say ~@a; method bar() { say ~@a; } }; Foo.bar; 14:46
p6eval rakudo fa44b5: OUTPUT«1 2 3␤␤»
pmichaud hmmmmmmm
I bet the problem is that whatever Parrot sub gets installed in class isn't the one that gets the capture_lex performed on it 14:47
i.e., the Parrot sub that gets installed in the class is a clone of the other one
so it refers to the wrong lexical @a 14:48
14:48 Trashlord left 14:49 ignacio_ joined
pmichaud if that's the case, then "our @a" isn't going to work either. 14:49
colomon nod 14:50
pmichaud we could always let PIR ride to the rescue, however.
colomon ? 14:51
pmichaud pir::get_global('@a')[$base]
probably needs
pir::get_global__Ps('@a')[$base]
let me try that quickly
rakudo: say ^5; 14:54
p6eval rakudo fa44b5: OUTPUT«01234␤»
pmichaud (rebuilding rakudo to get baseline timing) 14:55
14:56 [particle] joined
mberends_ about memory consumption, this used 1253MB: my $a=0; for 1..100000 { $a += $_ }; say $a 14:56
pmichaud mberends_: sure -- for loops are eager still 14:57
so the 1..100000 gets computed eagerly and eats up lots of space
14:57 nihiliad joined
mberends_ now trying this, 2001MB and still climbing: my $a=0; my $b=0; while $b < 100000 { $a += $b }; say $a 14:57
er, $b++ 14:58
pmichaud well, that's pretty horrible
I don't know why that would be eating up so much memory.
we should definitely look into that.
sin.t currently takes 1m15 on my system
14:58 johnz left 14:59 johnz joined
colomon btw, I'm starting to wonder if given / when isn't really so inefficient. 15:01
mberends_ correction, 522MB doing: my $a=0; my $b=0; while $b < 100000 { $a += $b++ }; say $a
pmichaud mberends_: that still seems high to me. does the number go up if you increase 1000000 ?
mberends_ it was climbing, will try now
colomon I just removed a bunch of them by using a nested ?? !! structure, and it didn't make any appreciable difference to the timing of the test run... 15:02
15:03 ignacio_ left
colomon oh, wait, I don't think I actually tested that! 15:03
pmichaud after switching to use a conversion array, 1m7s
15:03 xomas joined, xomas left, xomas joined
colomon pmichaud: \o/ 15:03
pmichaud only 8 second improvement there 15:04
so something else must be imposing time costs
colomon that's better than 10% off of what you had.
pmichaud true
anyway, I'll make spectest and commit.
15:05 PZt joined
colomon and if you can make it work in to-radians, then I can make the same method work in the tests for another improvment, perhaps not quite as big... 15:05
pmichaud yes, it's working in to-radians
it's a little ugly, but it works :)
we do need to figure out why lexicals in classes aren't working.
mberends_ 1691MB doing: my $a=0; my $b=0; while $b < 1000000 { $a += $b++ }; say $a
pmichaud mberends_: sounds to me like parrot isn't gc'ing properly. either that or somehow we're leaving pointers to a bunch of things... but its hard to see that from this simple example 15:06
colomon yeah, it's actually a great example for optimization, isn't it? 15:07
pmichaud ooc, how about
colomon so simple...
pmichaud my $a=0; my $b=0; $a += $b++ while $b < 1000000; say $a
i.e., w/o the block
mberends_ ok, running that now 15:08
15:10 Guest68103 left
mberends_ 1690MB doing: my $a=0; my $b=0; $a += $b++ while $b < 1000000; say $a 15:12
pmichaud okay, so it's not the block itself that is doing it
that tends to point more to a parrot issue
[particle] what is it with 100,000?
pmichaud I'm trying a pir-based version now
[particle] how linear is it
mberends_ will try 500000 for a 50% figure 15:13
colomon [particle]: geez, I hadn't even considered the idea we could have a greater than linear memory leak... 15:14
15:14 ignacio_ joined 15:15 jferrero left
mberends_ 1154MB doing: my $a=0; my $b=0; $a += $b++ while $b < 500000; say $a 15:16
pmichaud mberends_: how are you finding the memory used, ooc?
mberends_ watching top in another window, it's a bit manual and crude ;) 15:17
pmichaud okay.
colomon "ooc"?
out of curiosity?
[particle] so that won't work well for a value of 1
colomon++
colomon is used to ooc being "out of character"... 15:18
masak I like that example. in theory, a whazzy enough code optimizer could roll that into a constant :)
15:18 uniejo left
pmichaud it's definitely some sort of leak or lack of gc in parrot 15:19
I have a pure-pir program to demonstrate 15:20
colomon pmichaud++
pmichaud let's see if it's in calling conventions or something else
masak pmichaud++
mberends_ 139MB doing: my $a=0; my $b=0; $a += $b++ while $b < 1000; say $a 15:21
jnthn is back 15:22
15:23 xomas left
mathw \o/ jnthn 15:23
there's a parade of awesomeness going on in here 15:24
masak mberends_: that's more than for 500000 o.O
pmichaud masak: 139 versus 1154 (you're dropping a 1?)
mberends_ masak, no, 139MB < 1154MB
masak oh! 15:25
pmichaud okay, this looks like a very generic gc problem
masak dons the "can't read numbers" hat
pmichaud as in "parrot isn't doing gc"
mathw that's about as generic as it gets
mberends_ parrot was always like that, with looping type programs
masak <masak> in this case, he will reply 'no, my criticism is that they rewrite all the time without shipping anything' 15:26
twitter.com/robotpony/status/9287507924
:)
jnthn pmichaud: Thing is... :-|
Even this leeks:
.sub 'main'
call:
'foo'()
goto call
.end
.sub 'foo'
.end 15:27
dalek kudo/master: 43909a0 | jonathan++ | src/ (2 files):
Fixes that get .^parent working. Also .WHAT always now gives back things wrapped in a scalar container. Why? So Iterable proto-objects don't go trying to flatten, and subsequently go KABOOM.
kudo/master: fec6ec9 | jonathan++ | t/spectest.data:
Turn S12-introspection/parents.t back on.
jnthn er, leaks
pmichaud jnthn: yes, but I have a problem that does no function calls that leaks
s/problem/program/
which means the leakage is due to gc in general, not due to pcc
(i.e., anything that creates objects ends up leaking) 15:28
jnthn pmichaud: heh, me too
.sub 'main'
ohno:
$P0 = new ['Integer']
goto ohno
.end
leaks!
coke does it leak past 1MB?
pmichaud all of the programs we're trying seem to leak w/o bound 15:29
coke ISTR a recent change that didn't bother to run the GC until we allocated a full meg.
jnthn coke: Taht one I just pasted quickly gets to hundreds before I kill it.
coke hokay, something else, then. =-)
jnthn Not GC-ing until a full meg is allocated or so is probably a sensible approach.
pmichaud I'm running jnthn++'s version now 15:30
jnthn But yes, somehting else here.
pmichaud 309m
257m
er, 357m
424m
453m
"Houston, we have a leak."
[particle] ...maybe it was 1 gig...
pmichaud 521m
15:30 REPLeffect joined
pmichaud decides to wait to blow through the 1g barrier :) 15:31
723m
15:31 bkeeler joined
masak <masak> and I will say 'Rakudo has had 25 releases, and will have its 26th release today' 15:32
coke also, is this trunk or 2.1?
masak twitter.com/carlmasak/status/9287902991
pmichaud trunk
I can try 2.1 shortly (still building it)
coke k. hopefully it's just trunk. :P
pmichaud 2.0.0 doesn't have the leak (already had that one built) 15:33
15:33 ggoebel joined
pmichaud 1.1g 15:33
1.2g 15:34
TimToady
.oO(Memory too cheap to meter.)
pmichaud 1.3g 15:35
coke and, first level tech support question: you're not running with parrot -G, right? 15:37
jnthn parrot_install\bin\parrot.exe bug.pir
pmichaud plain parrot
./parrot z.pir
jnthn Though running with -G is insightful. 15:38
TimToady "We didn't tell you we flipped the meaning of -G last release? You have to add -G now to get GC..."
dalek kudo/master: 181d5f9 | pmichaud++ | src/core/Any-num.pm:
Refactor to-radians and from-radians to use a pre-initialized array.
kudo/master: dbaa79b | pmichaud++ | (3 files):
Merge branch 'master' of [email@hidden.address]
colomon \o/
jnthn pmichaud: Is that a ~10% on the time after colomon++ got us 40% earlier? :-) 15:39
pmichaud jnthn: yes.
went from 1m15s to 1m8s
15:39 justatheory joined
jnthn \o/ 15:39
pmichaud (previously I was in the 2m30 range)
jnthn If you add -G it consumes memory and then runs out of it really, really fast.
pmichaud 2.1.0 leaks. 15:40
jnthn Which shows how much time we spend in the GC. :-|
coke (2.1.0) argh. 15:41
masak <masak> and he will say 'no, I mean a REAL release, one where you ship production-ready stuff, like Python 3000' 15:42
twitter.com/robotpony/status/9288139528
pmichaud interestingly, 2.1.0 seems to leak memory faster than trunk 15:43
maybe I'm just misjudging the rate of increase, though
moritz_ you can set a ulimit, and measure the time until it dies
jnthn masak: lol.
masak: So we're meant to be production ready in the wild, whatever that means, but we're not supposed to do the refactors needed to get us to that point? 15:44
Wow.]
masak jnthn: to his credit, he's more friendly than I predicted.
pmichaud how much was python 3000 in the wild 2 years ago?
I guess I should file a trac ticket for the memory leak issue? 15:45
moritz_ yes 15:46
coke please. 15:47
15:48 jaldhar left, barney left
jnthn I guess part of our performance issue is, GC doesn't sweep a bunch of stuff, so working set size increases, meaning the next GC run has more stuff to look over and fail to sweep....repeat quite a few times...and you're starting to run quite slowly. 15:49
pmichaud correct
or, at least on my machine, once we reach a certain threshold of memory consumption my entire machine becomes unusable 15:50
jnthn Yes, same.
mberends_ "sweep early, sweep often" should be the new GC motto
pmichaud running the trig tests this morning (pre-optimization) with TEST_JOBS=3 made my workstation basically unusable
oops, I need to re-verify the leak with current trunk. 15:51
(unless someone else has tested it with parrot head this morning)
actually, trunk just failed to build just now -- realclean and try again 15:52
15:53 |Jedai| left, colomon left 15:54 Psyche^ joined, colomon joined 15:55 Patterner left, Psyche^ is now known as Patterner
mathw I do think a lot of people get confused by the messages sent out about Rakudo 15:56
It's all very well to say there have been 25 Rakudo releases
but that's just because a release goes out every month
none of them are something you can really use
but some people will see 'release' and think we mean it's production-ready 15:57
jnthn What are we meant to call them, then?
mathw it's like this thing with it being 'finished', and Rakudo *
moritz_ development release?
mathw I don't think we're speaking the same language as certain groups outside the Perl 6 world
I'm not saying there's a better way to do it, I'm just saying I think that's why we get so much misunderstanding
pmichaud TT #1465 created 15:58
(not speaking same language) Part of the problem is that people say "no progress" when what they really mean is "not yet ready for my needs". 15:59
15:59 uniejo joined
pmichaud in other words, if a given release doesn't yet meet their needs, then to them it's the same as "not released" 15:59
coke I'm not sure how much we can do other than smile and keep making releases. 16:00
bkeeler People also read meaning into version numbers
They see something like 1.6 and think, hey 1.0 was probably the first stable release, so it's probably a mature product 16:01
mathw bkeeler: In that case, I think Rakudo's doing it right, just saying 'Rakudo release 26'
pmichaud bkeeler: and this is one reason I'm absolutely avoiding 1.x numbering schemes
mathw because it doesn't look like an ordinary producty version number
Parrot, however, is doing it wrong
bkeeler True
pmichaud my experience with 1.x numbering schemes is that they try to serve too many masters.
bkeeler The rakudo way is certainly better 16:02
16:02 payload left
jnthn OK, for today's Rakudo release...what's urgent? 16:02
.oO( oops, I said release :-) )
bkeeler Still, I think people try it, find out it's not ready for prime time then resent it for wasting their time and become biased against it
jnthn pmichaud: Tweaking the ROADMAP is the only "must do" I can immediately think of. 16:03
mathw has masak++ fixed enums yet?
masak mathw: only anon ones.
pmichaud jnthn: yeah, I didn't get around to ROADMAP work last night
mathw ah well
jnthn pmichaud: That's fine.
mathw not that I care, I use git master anyway :)
coke parrot has tried to separate "developer" releases from "supported" releases. I'm not sure that has helped us.
masak mathw: named ones coming up. in my compious free time. :)
s/mp/p/
jnthn mathw: That's more than we'd have had if masak++ hasn't worked on them. :-)
mathw oh yes definitely 16:04
some enums is better than no enums
pmichaud on the good side, I'm feeling much better this morning, so I'm hoping my productivity/energy will re-approach normal levels again today
mathw \o/
I should stop moaning and do some hacking
masak who will cut the release?
coke fof . o O (rawr)
pmichaud I haven't heard from Su-Shee -- is she still on for toding today's release?
mathw but right now I have a tram to catch
o/
pmichaud s/toding/doing/ # ack!
jnthn Tram! \o/ 16:05
masak Su-Shee++: where are you? are you in a release-y mood?
pmichaud I drafted a release announcement yesterday evening -- it needs some attention.
We could probably grab notes from jnthn++'s use.perl post :)
jnthn pmichaud: I read it and it looked overall good, apart from the incomplete bit. :-)
But right idea.
pmichaud contributions to the release announcement welcomed :) 16:06
jnthn pmichaud: I don't mind doing the roadmap tweaks, if we can agree what we want to do. :-)
pmichaud jnthn: I saw that you did some tweaks already...?
TimToady I wonder if multi-dispatch is up to doing the switching on radians, degrees, etc. in the signature as constants 16:07
pmichaud TimToady: I thought about that -- I think it would work, but probably wouldn't be a significant improvement for us
jnthn pmichaud: I moved some items I was comfortable were completed to the bottom "done" section
TimToady not till someone invents an Optimizer, I guess :)
jnthn pmichaud: There's a few others that I wanted to know if you felt were done.
pmichaud jnthn: reviewing ROADMAP now
jnthn TimToady: I suspect Rakudo's multi-dispatcher can handle them just fine, but it's not one of the cases that it is really well optimized for yet. 16:08
TimToady: It's far more optimized for type-based dispatch.
TimToady since we'll usually know which at compile time, could even inline the correct code
pmichaud yes, it could be optimized nicely 16:09
TimToady well, just thinking out loud...
pmichaud right now I'm wondering if our trig test slowness is due to the parrot gc bug
TimToady how long are the .t files?
pmichaud not very long
also, parsing+compiling doesn't seem to be the slow part
(which surprised me a bit)
TimToady maybe we should do our own GC on top of parrot, just copy over the whole interpreter and then delete the old one periodically. :) 16:10
pmichaud (ouch, hurts when I lol)
sin.t is 285 lines, Rakudo compiles it in ~4 sec. 16:11
(but the 285 line file has ~1700 tests -- lots of loops)
16:13 [[synth]] joined
masak TimToady: a topic from yesterday: if different things should look different, why do the quotes in "$foo."$bar"()" look so similar, even leading to possible runaway quote problems with their corresponding fixes? 16:13
TimToady the inside ones are in their own expression, so the outside ones don't see it 16:14
if you don't like it, use different quotes
masak not only will I not like it, but syntax highlighters won't either.
pmichaud DIHWIDT ? ;-) 16:15
jnthn masak: It's localized though :-)
masak: There's two matching sets of quotes.
TimToady syntax highlighters are in the business of cheating, and cheaters often get caught
masak jnthn: that's a fair point.
pmichaud I have a question that just occurred to me after viewing the ROADMAP 16:16
my $x; $x[0] = 'abc'; say $x.WHAT; # what happens here?
masak TimToady: least surprise. my eye scans the string and finds a closing quote mark after the dot. it doesn't see the threshold between ordinary-string and expression you mention.
moritz_ I guess .[] forces autovivification to Array
TimToady THEN CHANGE THE OUTER QUOTE!!!
sheesh 16:17
16:17 [synth] left
pmichaud moritz_: that's my guess. Now consider... 16:17
masak TimToady: sorry to upset you. there might be other good reasons for using double quotes there.
pmichaud my $x; $x{'abc'} = 'def'; say $x.WHAT; # autovivify to Hash ?
TimToady in which case, only the human gets confused--the parser is still fine.
moritz_ pmichaud: aye
pmichaud okay, then we also have
my Any $x; say $x.WHAT; # ??? 16:18
16:18 iblechbot joined
moritz_ Any() 16:18
masak I'm 100% fine with laying this issue to rest, and never complaining again. just thought I'd get it all out at once first. :)
pmichaud because $x is initialized to the Any protoobject, yes?
moritz_ yes
pmichaud but postcircumfix curlies on protoobjects already have a different meaning.
(at least, they did at one point) 16:19
jnthn my $x; is init'd to the Mu proto-object though, no?
moritz_ oh, what do they mean?
jnthn WHENcE
er, *C
pmichaud and postcircumfix brackets on protoobjects also have a different meaning
(sorry, "type objects")
TimToady "All progress depends on at least two unreasonable men in the same room."
jnthn pmichaud: Only for role ones. :-)
Class type objects have little clue about them.
oh wait 16:20
oh yes, that's right.
pmichaud so, it appears we have a conflict, or I'm overlooking something obvious.
masak Perl 6 is about eliminating lists of strange exceptions that the user has to memorize. in this case, quotes of the same kind within a string must be backwhacked... *except* when it's a double quote and you want to double-quote-interpolate a method name... o.O
TimToady no, except when it's a part of an interpolated subexpressoin 16:21
which is a very general subexception
masak a subexpression which isn't explicitly indicated in any way.
pmichaud the dot indicates it.
TimToady rakudo: say "%*ENV{"HOME"}"
masak pmichaud: right. and lookahead.
p6eval rakudo dbaa79: OUTPUT«%*ENVHOME␤»
TimToady should work fine 16:22
masak nod.
the braces are a big tip-off, though.
jnthn pmichaud: Feels like one to me too. :-/
TimToady and the fact that the ."" form requires () inside quotes fits right in with that rule
16:23 nbrown left
pmichaud jnthn: I guess I need to formulate a pm.txt question for it. 16:23
jnthn pmichaud: I guess so.
I have no immediate thoughts on an answer.
16:23 nbrown joined
jnthn pmichaud: My other problem is 16:23
masak TimToady: ok. I'm out of arguments. I'll just create a module where double-quotes in double-quoted strings are forbidden. :)
TimToady generally the user will see enough context around an interpolated expression to know whether a " is ending or not, especially if the user has a decent whitespace policy 16:24
jnthn my Int $x; $x<foo> = 42; # if this does somehow end up meaning auto-viv, surely type check fail?
pmichaud jnthn: that doesn't bother me so much -- yes, it's a typecheck fail
16:24 clausi left
pmichaud jnthn: that one is fairly easy to handle :) 16:25
jnthn pmichaud: The only other possibility is that TypeObject{ ... } and TypeObject[...] could be syntactic, but I don't like that and it _will_ break assumptions we already make in the codebase.
pmichaud jnthn: yes, I hadn't been thinking of them as syntactic.
TimToady and chances are, if you need the indirection of ."$foo"(), you're probably wanting to pass more arguments in the () too, further insulating the inner "" from the outer visually
16:25 Trashlord joined
pmichaud personally I'd write it as "{$foo."bar"()}" anyway :-) 16:26
TimToady then you don't ned the ()
*need
(I think)
std: say "{$_."bar"}"
p6eval std 29775: OUTPUT«===SORRY!===␤Quoted method name requires parenthesized arguments at /tmp/r82WQSREJz line 1:␤------> say "{$_."bar"⏏}"␤FAILED 00:01 108m␤»
pmichaud I couldn't remember. My point is more that complex interpolations read better in curlies anyway :) 16:27
TimToady oh, maybe we made that a general rule
jnthn oh yes you do :-)
TimToady right
moritz_ would use printf instead - easier to parse visually
jnthn rakudo: say "{$_."bar"}"
p6eval rakudo dbaa79: OUTPUT«Quoted method name requires parenthesized arguments at line 11, near "}\""␤current instr.: 'perl6;HLL;Grammar;panic' pc 500 (ext/nqp-rx/src/stage0/HLL-s0.pir:328)␤»
pmichaud woo hoo!
jnthn Was sure I remembered copying that bit of STD recently. :-)
pmichaud rakudo++
TimToady need more coffee, or maybe just more neurons
jnthn Coffee sounds less invasive. :-) 16:28
TimToady std: $_."bar"
p6eval std 29775: OUTPUT«===SORRY!===␤Quoted method name requires parenthesized arguments at /tmp/iXMRUbGZp3 line 1:␤------> $_."bar"⏏<EOL>␤FAILED 00:01 106m␤»
TimToady yeah, general rule
I must have been a genius when I was younger.
masak moritz_: chromatic once claimed in a Tweet that printf is for C-entrenched programmers. I'm glad someone besides me uses it in Perl. :) to me, it's just the next step above double-quoted strings.
pmichaud jnthn: (ROADMAP review) I just looked it over, I think I can make some reasonable changes to the ROADMAP but need a short rest break first
moritz_ masak: the Perl6ish way would be to use .fmt, maybe :-) 16:29
pmichaud I may just do lunch real quick, then come back and do ROADMAP refactor
masak moritz_: .fmt is just sugared sprintf anyway :)
moritz_ masak: but yes, I prefer printf over too complicated interpolation
masak moritz_: if Form.pm were more evolved, I'd probably use that sometimes too. 16:30
pmichaud anyway interested in serving as Su-Shee's backup in case things fall through there?
*anyone
arnsholt masak: For interpolating complex expressions, I prefer printf too
16:30 Trashlord left
moritz_ needs to go offline in 30minutes or so, so he wouldn't be a great backup 16:30
arnsholt: do you have time, by chance? 16:31
pmichaud well, it doesn't have to happen soonish -- we still have a fair bit of time remaining today
and I'm okay if it occurs early tomorrow
jnthn Who's tomorrow? :-)
moritz_ if it's not done by tomorrow morning (UTC+1) I can do it 16:32
jnthn pmichaud: (ROADMAP) wfm
pmichaud as long as it's Feb 18 _somewhere_ in the world, which really gives us until about 1200 UTC on the 19th :)
arnsholt moritz_: Probably. When should it be done, and what is supposed to be done?
TimToady for interpolating really complex expressions, I prefer calling a function :)
masak arnsholt++
moritz_ arnsholt: today or early tomorrow. What needs to be done is documented in docs/release_guide.pod 16:33
pmichaud arnsholt: have you done a release before? it's not at all hard and... what moritz_++ said
TimToady as for printf, any call that involves counting more than about 2 arguments is not human friendly
moritz_ arnsholt: and I guess pmichaud++ needs to give you commit privs first
arnsholt Not done one yet
pmichaud oh, for commit privs I probably need a CLA
moritz_ TimToady: I've long thought that we need printf with named arguments
pmichaud although I could certainly grant them provisionally or temporarily
arnsholt moritz_: Or Common Lisp's format() 16:34
I like format() ^^
pmichaud printf with named arguments sounds a lot like closure interpolation to me :-P
masak moritz_: PIR code generation has that. it's quite OK. not extremely legible, but good for half a screen of interpolated code.
moritz_: see PGE's Exp.pir (or GGE's equivalent) for lots of examples. :) 16:35
pmichaud my $fmt = -> $foo, $bar { "The $bar ran over the $foo." }; say $fmt('dog', 'car');
16:36 cjk101010 left
dalek kudo/master: cb56224 | jonathan++ | docs/announce/2010.02:
Tweaks to release announcement.
 16:36
pmichaud say $fmt(:bar<car>, :foo<dog>);
masak the twitter debate got a happy ending! :) twitter.com/robotpony/status/9288139528 twitter.com/carlmasak/status/9288531147 twitter.com/robotpony/status/9290510075
TimToady is now thinking about how to use a sig instead of a string for formatting...
pmichaud say "And inside of double-quoted strings: $fmt(:bar<car>, :foo<dog>)"; 16:37
moritz_ pmichaud: nice one
pmichaud I think the language designer gets credit for this one :)
moritz_ TimToady++ then :-)
TimToady probably works pretty good for internationalization too 16:38
pmichaud say "And perhaps other &plural('nouns'), too?" 16:39
er, *'noun'
(definitely need a break)
mberends_ arnsholt, moritz_: I didn't leap forward as backup release manager because I'm doing a Linux install and cannot guarantee continuous connectivity, but I can do a release and can do commit. Whatever you prefer. 16:40
jnthn masak: :-)
moritz_ mberends_: then just do what you can, and we'll let arnsholt++ do a release after he submitted a CLA 16:41
mberends_: and if you don't manage to do the release today, I'll finish it early tomorrow
(fsvo "early")
mberends_ moritz_: good plan, I'll enjoy the first-time experience :) 16:42
pmichaud excellent plan. and this also assumes Su-Shee absence 16:43
arnsholt And a CLA is? =)
pmichaud www.perlfoundation.org/contributor_..._agreement
bkeeler It's where you sign over your first-born to be sold into slavery to fund jnthn's next grant ;) 16:44
jnthn \o/
pmichaud afk for a short bit
jnthn is currently reviewing his current grant deliverables to see what's left to do :-)
ah, mostly "binding return values against a signature" 16:45
arnsholt Ah I see
jnthn creates a branch to do that in.
masak pmichaud: in src/Perl6/Grammar.pm, there's a heading comment '## Nouns', followed by a large number of... terms. is there a reason behind that discrepancy in terminlology?
jnthn masak: Hysterical raisons, I guess. 16:46
masak backs away from those raisins
mberends_ terminLOLogy ;)
masak oops :) 16:47
bkeeler Not nouninology?
PerlJam greets all
jnthn masak: Feel free to change it. :-) 16:48
masak jnthn: goodie. I'll do that, and the plural->singular change in the glue/ dir.
PerlJam listens to Bill Gates' TED talk 16:49
16:49 moritz_ sets mode: +ooo PerlJam masak mberends_
PerlJam Grr. until the sound cuts out chrome-- 16:50
16:50 kthakore joined
kthakore hi 16:50
I have parrot installed from trunk
moritz_ hi there
masak kthakore: hi!
kthakore but I can't seem to get rakudo installed on that
masak: hi!
moritz_: hi 16:51
masak kthakore: should just be downloading it via git and building.
moritz_ kthakore: what errors do you get?
kthakore moritz_: well it saves my reviision is too old
masak kthakore: then you need to update Parrot.
kthakore masak: I did
masak kthakore: and do 'make install'?
kthakore but not --gen-parrot way
I have parrot instaleld seperatly 16:52
coke do you have a copy of parrot lying about in the rakudo checkout?
masak kthakore: that should work too. I don't do it the --gen-parrot way either.
coke (could be finding the old copy and then giving up.)
kthakore masak: I have the latest trunk
masak kthakore: but did you do 'make install' on it?
kthakore coke: how do I tell which is it finiding
masak: yes
coke kthakore: gotta run, masak wil lhelp you. =-)
kthakore which parrot gives /usr/local
masak kthakore: then I'm officially confused. what Parrot does Rakudo find for you? 16:53
moritz_ kthakore: the you need to configure with perl Configure --parrot-config=/usr/local/bin/parrot_config
kthakore cthanks
ah pah ok
sorry my ssh is laggy
moritz_ erm, perl Configure.pl ... (forgot the file extension)
dalek kudo/master: 84d6b02 | masak++ | src/Perl6/Grammar.pm:
[Grammar.pm] slight wording fix
16:54 ewilhelm joined 16:55 uniejo left
bkeeler Hullo Eric! 16:55
kthakore moritz_: that seemed to work
moritz_ kthakore: great
16:56 uniejo joined
pugs_svn r29776 | lwall++ | [S04] unmuddying requested by Richard Hainsworth++ 17:01
kthakore masak: moritz_ seen the new SDL stuff lately?
moritz_ not me 17:02
kthakore is philandering while rakudo is compiling
masak hasn't
moritz_ did you blog about it?
TimToady if git does Unicode properly in messages, that might be enough motivation for me to switch. :)
moritz_ TimToady: it has very decent UTF-8 support 17:03
TimToady: but I think svn is OK to, just the bot is a bit broken
kthakore moritz_: yes
jnthn Rakudo is so going to use pigeons carrying clay tablets.
TimToady++ 17:04
kthakore moritz_: see yapgh.blogspot.com/ especially the 2nd last lpost
17:07 Su-Shee left
colomon arnsholt: note that the address on the CLA is wrong. It should be a place in Michigan. 17:08
pmichaud the more I use git, the happier I am with it :) 17:09
kthakore moritz_: masak: gist.github.com/301949 17:10
pmichaud: \o high five
masak kthakore: oh, it's Perl 5... :) 17:11
pmichaud rakudo: say chr(171); 17:12
p6eval rakudo 84d6b0: OUTPUT«\xAB␤»
pmichaud fixes.
kthakore masak: I am sorry
masak kthakore: no worries. :) just looking forward to when people do that in Perl 6, is all.
kthakore masak: SDL for parrot is comming ... just need to build up community support for SDL in perl
masak: then I can get them to hack on parrot SDL 17:13
perl5 sdl perl is the only way to build up mindshare irightn o
masak nod.
17:15 Su-Shee joined
kthakore hi Su-Shee 17:15
masak I gotta head out for lunch 17:16
masak Su-Shee: hi! rumour has it you'll be today's release manager.
kthakore masak: I would love your toughts
masak kthakore: on the Perl 5 code? 17:17
17:17 athenot left
kthakore masak: on the easy to use and read commendted intro to new SDL API 17:18
masak kthakore: I must have missed that one. URL?
kthakore masak: gist.github.com/30194 17:19
masak: I am preparing it for a perl mongers meeting
masak looks
kthakore goes for lunch 17:20
17:21 payload joined
masak kthakore: that URL goes to a gist of one very long line of Javascript. was it really what you meant to paste? 17:21
if it was, I'm not sure I can endorse such an API :P 17:22
kthakore oh
masak: gist.github.com/301949 17:23
oops forgot the 9
masak right. that's the Perl 5 code you showed before.
I must be missing something here.
17:23 mberends__ joined
masak kthakore: you are aware that this is #perl6, right? 17:23
kthakore oh right
masak :)
kthakore blushes 17:24
I thought I was somewhere else
oops
mberends__ testing testing 1 2 3
kthakore sorry guys
jnthn :-)
kthakore hi jnthn
jnthn hi
kthakore masak: man rakudo is still going
....
ok I gtg to lunch 17:25
caio
17:25 kthakore left
masak those trig tests really slow down the computer... :) 17:25
mberends__ (re-)reads github.com/rakudo/rakudo/blob/maste..._guide.pod
masak couldn't we pull out the trig tests into their own test suite, and only run them at festive holidays or something?
just an idea. 17:26
mberends__ masak++
pmichaud I'm still not sure why they're as slow as they are.
colomon masak: do you have the updated ones yet? we've cut the run time down by a bit more than half this morning...
pmichaud but yes, they're must faster now than they were.
*much
mberends__ we'll put them in for the release statistics and then take 'em out again 17:27
pmichaud I already did release statistics this morning -- we could use those for the release.
masak colomon: yes, I think I do.
colomon mberends_: I must admit that was sort of my working plan....
masak colomon: not complaining about the run time, but about the load on the processor.
pmichaud we should keep them in for the release also, though.
masak gtg, swimming &
pmichaud masak: is it cpu bound or memory bound, ooc?
masak pmichaud: I have 4GB of RAM, so I suppose it's the former. but I haven't checked. 17:28
colomon masak: my experience is that the current version puts significantly less stress on my system.
pmichaud masak: are you running parallel tests?
masak yes.
pmichaud I suspect it's the latter
masak ok.
pmichaud given that Parrot seems to be not doing full gc
it could be the former as well, though. 17:29
masak aha.
masak goes swimming
17:29 masak left
colomon running multiple tests at the same time, each of which uses more than a gig of memory... 17:29
mberends__ colomon: could you envisage of a kind of brief trig "canary" test that we always do as a general health check, and then a "make trigtest" for the detailed verification of all functions? 17:30
colomon mberends__: honestly, I had just been picturing turning them back off again manually (at least locally) once the release was done. 17:32
mberends__ colomon: ok
has a release name been chosen for #26? Copenhagen?
jnthn pondered that could be an ideal one 17:33
colomon It would certainly be fairly easy to set up a sort of random sampling of the trig tests for a quick version.
pmichaud haven't chosen a name. I was going to let jonasbn decide which release he wants to have named Copenhagen.
I'd be fine with naming it for a group with the nlpw, though. 17:36
mberends__ colomon: random sampleing is a great idea. for repeatability of pseudo random numbers, I've had good results seeding with the date (and not the time)
colomon mberends__: actually, I was thinking just doing the random sampling once and creating a new test file from it -- so perfectly repeatable. :) 17:37
pmichaud we could name this release "Amsterdam" in honor of dutch perl workshop and Juerd++ :)
clearly something as useful as "perl6.nl" deserves a mention :) 17:38
jnthn perl6.nl++
PerlJam +1 17:39
mberends__ that's fine. I'm not a member of a Dutch pm group, but Juerd++ definitely deserves recognition
(I'm at a friend's place in London, and he's intrigued by these activities)
pmichaud London.pm also deserves a nod at some point, I think. 17:40
anyway, I suggest Amsterdam unless the release managers come up with a better one.
mberends__ picking a name is the hardest part, right? ;)
PerlJam one of these days a pm meeting and a release date are going to conincide :)
17:40 cotto_work left, [[synth]] left, nihiliad left
pmichaud I actually like it when releases are a few days before a meeting. 17:41
It's like a free meeting announcement :)
so, Minneapolis was just before Frozen Perl
and last year Oslo was just before NPW
mberends__ that's why I thought Copenhagen, they're very good to us. Where is jonasbn when you need him? 17:42
pmichaud maybe email him?
pmichaud emails.
Juerd The Dutch Perl Workshop is in Arnhem though :P
pmichaud yeah, Arnhem.pm is another candidate 17:43
Juerd There isn't actually an Arnhem.pm group afaik
If I recall correctly, it's a placeholder
pmichaud but you've been such a long-time contributor to perl 6 it's worth mentioning your .pm group if you want
Juerd Thanks :)
The group has two names :)
Amsterdam.PM and NL-PM 17:44
pmichaud you can pick either one, then :)
you can even draft what you'd like said about it. If it's not this release, I'm sure it will be used soon.
jnthn suddenly realizes that in two weeks, he'll be in Arnhem!
mberends__ heh
pmichaud yes, in two weeks I'll be in CPH
Juerd Neither is really appropriate. Let the RNG decide :)
The meetings are not in Amsterdam, they're in Diemen, and it's also no longer all Dutch Perl mongers since there's now also Groningen.PM :) 17:45
17:45 cotto_work joined
[particle] in two days i'll be at the olympics 17:45
Juerd I like the name "Amsterdam" best I think
pmichaud wfm!
Juerd Everybody knows Amsterdam
17:46 am0c left
Juerd should prepare that box for jnthn soon 17:46
mberends__ Juerd: then Amsterdam had better be grateful for this bequest ;)
arnsholt Speaking of CPH, is there anything in particular that is the goal of the hackathon? 17:47
17:47 cotto_work left
pmichaud Review where we are for Rakudo *, finalize any planning details, and get a good ways along with that. 17:47
17:47 cotto_work joined
Juerd arnsholt: Releasing both the first and the second ever production releases of Perl 6, of course :) 17:47
pmichaud I suspect we'll want to nail down an approach for module management.
pugs_svn r29777 | colomon++ | [t/spec] Further optimizations to the trig tests. 17:48
pmichaud I just emailed jonasbn -- he may show up here with his preferences. 17:49
mberends__ arnsholt: the goal is also helping new hackers get started with Perl 6 according to conferences.yapceurope.org/hack2010dk/ 17:51
colomon Is the plan to release Rakudo * two months from today, more or less? 17:54
pmichaud NO
no
(sorry, capslocked again)
jnthn
.oO( I thought he was shouting at us :-) )
pmichaud my plan is Rakudo #28 release
Juerd Hm, not more or less... so it'll be released in *exactly* two months from today? :P
pmichaud on April 22
Rakudo * releases between April 22 and April 30 17:55
my current target is April 29
[particle] i wonder what the april 1 release will be called
pmichaud "No! You Fool!"
colomon [particle]: Rakudo 3000
Juerd [particle]: "Production ready"
pmichaud "Finished" 17:56
[particle] "Stable"
jnthn "Perfect" 17:57
PerlJam "Next!"
[particle] Rakudo [*] 17:58
17:58 synth joined
jnthn Rakudo Rocket 17:58
17:58 stephenlb joined
[particle] i guess that should really be "[*] Rakudo" 17:58
Juerd == 1? 18:02
18:04 xalbo left
mberends__ Writing the rakudo/docs/ChangeLog for #26, I see the 2009-12 release has no mention at all. Can anyone find the missing paragraphs? 18:05
pmichaud I'm not sure anything was added for 2009-12 18:06
18:06 ShaneC joined
mberends__ understandable, since ng was getting all the attention. We'll skip it then. 18:06
pmichaud could just put in an item that says "no significant changes in master, ng was getting all of the attention" :) 18:07
for when someone else notices the missing month :)
mberends__ ok. and this one is 2010.02 instead of 2010-02
pmichaud correct
rpm and other package managers don't like hyphens in release numbers, it seems. 18:08
mberends__ is there any chance of plugging the parrot memory leak before the release? 18:12
jnthn mberends__: Sadly not, since the Parrot release we're building against was on Tue. :-( 18:13
18:14 cdarroch joined, cdarroch left, cdarroch joined 18:16 athenot joined
pmichaud afk, lunch, then roadmap 18:21
dalek kudo/master: 968011b | pmichaud++ | src/cheats/setup-io.pm:
Default $*IN, $*OUT, $*ERR to utf8 encoding.
 18:26
mberends__ that's either a long lag or a short lunch 18:27
18:27 Trashlord joined
colomon long lag, it seems to be about five minutes on average these days. 18:27
mberends__ yeah 18:28
TimToady good chance I'm changing 1,2,4 ... *, 256 to be 1,2,4,* ... 256 instead, see p6l email 18:29
mberends__ nice, that's more readable 18:30
TimToady or just 1,2,4 ... 256, since the * can be intuited
colomon what mberends__ said.
TimToady and makes 1,2,4 ...^ 256 work better
if we add ^ notation to ...
which will be What They Mean 18:31
PerlJam needs to read faster
TimToady++
colomon TimToady: nod.
18:31 dakkar left
TimToady does lengthen fibonacci to 1, 1, &[+] ... * though, maybe that's good documentation 18:34
18:34 h1dd3n joined
TimToady or 1, 1, *+* ... * after we break * meaning the same thing on both sides of *+* 18:34
colomon I think I'm against *+* 18:35
couldn't fib be 1, 1 ... &[+] ?
PerlJam *+* is fine ... it's *** that's annoying ;)
TimToady if we move the generator to the left side, it wouldn't have to look on the right for one 18:36
18:36 uniejo left
TimToady so the first value would always be the limit 18:36
I'm not sure it would be a good idea to keep the old generator on the right notation
PerlJam I'm sure it would not be a good idea 18:37
colomon on the other hand, looking for a code or whatever generator there is pretty trivial, unless there's some additional complication I'm missing.
It's even already implemented in the arity-1 version.
rakudo: (1 ... { $_ + rand }).batch(10).perl.say 18:38
p6eval rakudo 968011: OUTPUT«(1, 1.66239000074299, 1.9783948093078, 2.25003949271973, 3.04569168167439, 3.88831642489605, 4.3093383773266, 4.79331349399676, 4.85023542473887, 5.28266882999033)␤»
18:38 cnhappier joined 18:39 cnhappier left
colomon hmmm... I can see arguments both ways. 18:39
TimToady that would be (1, * + rand ... *).batch(10) in the newthink
well, assuming * + rand generates a new rand each time 18:40
which it would if infix whatevers were always handles as compile-time rewrite to { $_ + rand }
*handled
which is part of the *+* --> { $^a + $^b } proposal is 18:41
basically, you'd mark those operators that you *don't* want to be autocurried, like maybe ..
and everything else would *-curry for free 18:42
including *.method
sort *.lc 18:43
instead of methods being a special case as they are now
also can autocurry metaops without having to write out bazillings of Whatever sigs
colomon I have to admit those last five comments have completely lost me. Could you give a couple of examples of how it is now and how you envision it? 18:44
TimToady so I think it's an allaround win
okay, currently * is curried by actually calling the function and discovering at run time that we match a Whatever sig 18:45
which has the disadvantage that it's hard to optimize 18:46
also, we *can't* do the * dispatch for methods because we don't know the class yet...
*.foo doesn't know what to do, other than the compiler rewriting to { $^a.foo }
so currently that's special cased 18:47
but method calls are just postfixes
if all unary and binary ops default to compile-time rewrite, *.foo falls out of it
for the other problem 18:48
arnsholt mberends__: Thanks for the info. In that case I'll sign up
TimToady if we have a hardwired prefix:<+>(Whatever $x) {...}
colomon TimToady: Aha. I think you're proposing it works the way I already thought it did. :)
TimToady we can say sort +* to get numeric
arnsholt CPH isn't that far away, and I was a bit disappointed when I couldn't attend the Oslo hackathon in may
TimToady but we can't automatically use +<< * 18:49
mberends__ arnsholt: excellent :-)
18:49 Schwern joined
TimToady to get a curried hypernumeric 18:49
PerlJam That's the biggest win IMHO
TimToady I think we can keep the current mechanism as a fallback for operators that still want to curry at run time 18:50
but most simple operator curries should probably be done at compile time with *
PerlJam (bazillion Whatever sigs)--
TimToady but that implies that we need to break the current *+* semantics that mean { $^a + $^a }
and make it mean { $^a + $^b } instead 18:51
or x and y, to be consistent
shower & 18:53
dalek kudo/master: 0fabacb | (Martin Berends)++ | docs/ChangeLog:
[docs/ChangeLog] draft of the 2010.02 entry
 19:01
19:05 ive joined, lichtkind joined 19:06 cotto_w0rk joined 19:08 cotto_work left
colomon is getting distressed that his $code appears to be slower than the trig tests at the moment... 19:13
19:17 coke left 19:19 cognominal left
colomon ah, it was the classic "XP error popup doesn't show up on the mac screen" problem 19:22
19:36 Exodist_ joined 19:37 Exodist left 19:39 rgrau joined, ruoso left
jnthn Well isn't this cool... 19:45
> class TreeNode { has $.left; has $.right; }
> our sub foo() { return TreeNode.new(left => 42, right => 69) }
> my ($node (:$left, :$right)) := foo(); say "L: $left, R: $right";
L: 42, R: 69
bkeeler Nice
So := is implemented now?
jnthn bkeeler: Yes and no. 19:46
colomon jnthn: looks like magic to me.
jnthn bkeeler: Not for normal variable bindings.
bkeeler Just signatures?
jnthn colomon: Just sufficiently advanced technology.
bkeeler: Yeah
colomon jnthn: how can you tell the difference? ;)
jnthn bkeeler: Though hopefully normal variable bindings should come along in the next week.
colomon: I can implement SAT, but I can't do magic. :-)
ENOWAND 19:47
19:47 chromatic joined
chromatic We're going to cherry-pick Parrot r44142 to create a Parrot 2.1.1. 19:50
mberends__ a fully up to date #26 trial release tarball builds fine locally and passes 24653 tests and shows no failures :)
colomon errr... GC fix? (he said hopefully?)
19:50 uniejo joined
chromatic That's the one. 19:51
19:51 coke joined
coke hey, rakudo folks - when is the release? 19:51
colomon supposed to be in three or four hours, I believe.
mberends__ confirmed
chromatic If you want to grab the patch and apply to your local Parrot for testing, it's at trac.parrot.org/parrot/changeset/44142 19:52
coke if you can wait a bit, we can get you a parrot 2.1.1 that kills that leak.
jnthn I'm inclined to wait for that.
mberends__ we can wait, that way we test the proper build procedure as well
colomon yeah, that sounds great.
jnthn chromatic++ # thanks for the quick fix! 19:53
chromatic Thanks for reporting.
jnthn chromatic: Ah, an optimization gone awry? 19:54
chromatic Yeah, missed one case.
colomon trying to build parrot with the changeset now.
coke there will be a 2.1.1 RC branch with that applied shortly. 19:55
colomon at a first test, that looks drastically better. chromatic++ 19:56
jnthn colomon: Memory consumption wise, I guess, but faster too? 19:57
chromatic It should retain some of the speed.
colomon I don't have times for the old version (I'm rerunning mberends__++'s tests in the REPL) 19:58
19:58 mberends_ left
jnthn Ah, OK. 19:58
colomon but I haven't seen memory usage go over 75M yet
jnthn I was thinking ont he trig ones.
*on, the
colomon he was reporting 1000+M this morning.
jnthn \o/
colomon I'm try it with sin.t to see what happens once this run is done. 19:59
jnthn OK, cool.
(I've just been doing some stuff in a branch, which I'm spectesting, so can't do anything immediately.)
pmichaud I recommend we hold the Rakudo release for 2.1.1, if 2.1.1 will be released in the next few hours. 20:03
I'm even willing to wait until tomorrow.
20:03 mberends__ is now known as mberends
coke svn.parrot.org/parrot/branches/release_2_1_1_RC 20:03
colomon okay, for sin.t, the timing isn't appreciably better -- might even be a touch worse -- but it max'd out at less than 200M memory used, which is vastly better than before.
coke that has the bug fix that was applied to trunk, with a bumped version #.
tarball coming. 20:05
chromatic The tarball should let you make the release on your schedule.
coke if they're going to require it, they probably want a full release. 20:06
jnthn coke: It's no problem for us to wait for that, I don't think. :-) 20:11
20:12 alinbsp left
jnthn pmichaud: If you're doing ROADMAP updates, I've got a push coming in a moment that will also let us move these ones to "complete": 20:13
3 * nested signatures (B)
2 * captures in signatures and return values (B,H)
pmichaud jnthn: I've been sidetracked a bit -- will likely be another hour before I can look at it 20:14
(feel free to move those to "complete", though :)
jnthn pmichaud: ah, ok, I can - I didn't want to make a conflict for you, that's all.
pmichaud: I'm *very* happy to have landed this.
pmichaud: They were the last tasks for my grant, afaict. :-)
20:16 Exodist_ left, Exodist__ joined, nihiliad joined
coke running a fulltest before I do the tarball. feather is slow. 20:17
20:18 jonasbn joined
jonasbn evening all 20:19
pmichaud jonasbn! 20:20
hello!
jnthn oh hai jonasbn
pmichaud jonasbn: you get to pick which release is called "Copenhagen" :) 20:21
jonasbn I have just booked the venue for Sunday
pmichaud jonasbn++ # excellent!
20:21 Exodist__ is now known as Exodist
jonasbn we talked about monday, do you want a session to yourself for monday? 20:21
pmichaud: what are my options? 20:22
pmichaud I expect many of us will be having a variety of discussions on saturday and sunday. I'd like to devote Monday to Rakudo * release planning.
jonasbn okay
pmichaud jonasbn: Feb, Mar, Apr, -- whatever month you'd like!
jonasbn I would like March then
pmichaud okay, it's yours. And I think we'll go with "Amsterdam" for today's release. 20:23
jonasbn post hackathon
thanks :)
my only goal is reached then
apropos goals we need to set some goals for the hackathon
pmichaud well, on Saturday I'm guessing there are presentations and hallway discussions 20:24
jonasbn moritz_: had some ideas, but I need something to sell the hackathon
pmichaud Sunday I'm thinking we devote to people who want to hack on or with Rakudo, and orientation about the current state of things
jonasbn so Saturday will be general, and Sunday more specific
pmichaud so, early part of Sunday (or some dedicated portion of Saturday) we bring along newbies into Rakudo building and kind of "where things are". We can usually get people hacking on specific problems within just an hour or so.
jonasbn sounds great, since the OSD is ongoing Saturday 20:25
pmichaud Monday is a continuation of that, although I expect the "core hackers" will be discussing and prioritizing issues for Rakudo *. All others are welcome to join that as well.
We might have some of that discussion on Sunday afternoon/evening, if there are people who want to participate in it but can't be there Monday.
Sunday and early Monday may also be ticket triage 20:26
jnthn pmichaud: mberends++ will be around on Sunday but not Monday - we should consider the discussion of installation standards etc for Sunday I guess.
pmichaud jnthn: good point; I'll keep that in mind (and we'll work accordingly)
let me recheck the osd schedule a bit 20:27
jonasbn: I'll draft a schedule and put it on the wiki
jnthn jonasbn: Are the talks scheduled yet (e.g. what time they'll be at)?
mberends the module storage, loading and packaging interests me the most
jonasbn jnthn: I have not heard anything, but I can investigate and schedule in Act accordingly
I guess Perl hackers are living in their own little world :) 20:28
jnthn :-)
mberends: I figured, thus why I think it matters that we do it when you're around. :-)
jonasbn the people who have indicated interest are all really clever people, so we might be able to cover some ground
pmichaud if people aren't too tired, perhaps we could start discussions on modules on Saturday evening 20:29
hmmm, perhaps in addition to my Rakudo talk I should give a "building compilers with nqp" tutorial on saturday 20:30
jonasbn the venue for Sunday is close to a really nice cafe with good food and beer, I guess we can wrap up the hackathon there Sunday evening
the official part I mean
pmichaud newbies can come to that tutorial on saturday, and be ready to go on Sunday morning
jonasbn that would be me
pmichaud I suspect the "core group" doesn't need my tutorial, so they can rest then :)
20:31 jonasbn is now known as jonasbn00b
pmichaud jonasbn00b: :) 20:31
would 90 minutes be too long? 20:32
40 minutes is generally a little too short
jonasbn00b pmichaud: I think it should be fine
pmichaud checks act
oh, wait, carl already has a "parsing with perl 6" talk 20:33
jonasbn00b pmichaud: put the schedule up and I will take it with the OSD people
pmichaud er, moritz has that
carl has "only Perl can parse Perl 6"
jonasbn00b hehehe
20:33 Su-Shee left
coke feather.perl6.nl/~coke/parrot-2.1.1.tar.gz 20:33
jonasbn00b it is all about parsing
pmichaud so I don't need to do the parsing part so much as the compiler/backend stuff 20:34
jonasbn00b I wonder, would you like to have some parrot presence at the hackathon?
pmichaud okay, I'll draft a proposed schedule and activities tonight, post it to the wiki, and send a message to the mailing list
coke please let me know if you find any problems with the release candidate.
pmichaud from there we can likely build a more detailed schedule with feedback from masak++, moritz++, etc. 20:35
I have to go pick up kid from school -- bbi20
mberends afk & # dinner
jnthn jonasbn00b: Good food and beer! \o/
jonasbn00b :)
jnthn yay 20:37
jnthn pushes Shiny New Features.
20:37 JoWie joined 20:38 Su-Shee joined 20:39 jferrero joined
dalek kudo/master: d41ed4c | jonathan++ | src/ (5 files):
Start to recognize my (...) := foo(); as a special form that needs to promote the signature in the reducecheck for := and operate on that; add in infix:<:=> with an error for the non-Signature case and stub in Signature!BIND.
 20:40
kudo/master: 10e5b56 | jonathan++ | src/ (3 files):
First cut of binding a signature against the return values of a function. Kinda works. :-)
kudo/master: 83542c0 | jonathan++ | src/ (2 files):
Handle sub-signatures in returns so we can do unpacking, plus other little tweaks.
kudo/master: 3ad4e2c | jonathan++ | src/ (5 files):
Merge branch 'bindrets'
jnthn Going for cheezburger, back in a bit. 20:41
20:42 dukeleto joined
dalek kudo/master: 6357018 | jonathan++ | docs/ROADMAP:
Move a couple more items on the ROADMAP to completed.
 20:46
20:53 nihiliad left 20:55 sjohnson left, nihiliad joined
coke the parrot 2.1.1 tarball seems ok to me. Expect a release by ... 7pm or so EST. Complain before then if necessary. (I'll check back here before doing the actual announcement.) 21:00
21:02 SmokeMachine left, Su-Shee left
colomon coke: what will the svn version for it be? 21:09
21:09 bluescreen left
colomon (and BTW, coke++, chromatic++, this is awesome support.) 21:10
coke colomon: it will not have an svn revision on trunk. 21:11
21:11 Su-Shee joined
[particle] it will still have an svn rev # 21:11
coke ... not on trunk.
[particle] right
coke which probably makes it useless to them. =-)
[particle] that's a bit problematic for rakudo, i think...
yeah
coke there will be a tag.
[particle] it *can* have a trunk revision 21:12
coke [particle]: no.
[particle] it'd be a bit of a pita to do, though
coke there's been a TON of stuff merged back to trunk since 2.1.0; not gonna happen. 21:13
[particle] yeah, sigh, there's a first time for everything
colomon [particle]: I'll bet it's not that bad to make it work.
frettled *reads backlog* jnthn++ - I suppose congratulations are in order! 21:14
chromatic Rakudo can jump to a trunk commit after the release, I suspect. 21:15
jnthn back
frettled: Yes, getting cheeseburger is an incredible achievement. My stomach is has a happy. 21:16
[particle] does rakudo work with parrot trunk head?
frettled jnthn: :(
jnthn: :), I mean
nasty typo there
colomon jnthn: but your stomach does happy?
frettled but at least I managed to balance the parentheses
jnthn [particle]: Not sure. 21:17
There's no particular technical reason I know of why the svn rev # and the Parrot version number have to match up fwiw. 21:18
21:18 h1dd3n left
pmichaud in PARROT_REVISION, the Parrot version number is used when the parrot_config binary is unable to report a svn revision number 21:19
otherwise it's pretty much ignored
(and then, it's only used to say "your version of Parrot isn't new enough")
[particle] right, but that's where it breaks
"not new enough" is on a branch, not trunk
a "newer" parrot may not work with rakudo 21:20
jnthn Ah...I see.
[particle] if 1) the gc patch is applied to parrot trunk, and 2) rakudo works with parrot trunk head, then you're ok
pmichaud currently we set the revision number to a parrot revision *on trunk* that is known to work with Rakudo.
Yes, it's entirely possible that there is no trunk revision that will work with Rakudo, in which case we have to patch Rakudo.
[particle] pmichaud: so are you good to keep the current parrot revision the same? 21:21
jnthn tbh
pmichaud [particle]: I'm testing parrot trunk now.
[particle] ok
mberends back, nom has been num. Ready to begin procrastinating the release until Parrot 2.1.1 is out
[particle] i,m not sure trunk has the gc patch applied
21:21 bluescreen joined
pmichaud then we'll probably end up sticking with the 2.1.0 release 21:21
we don't have a way to target releases that are outside of trunk, at least not for the --gen-parrot option. 21:22
jnthn Is there any reason why the GC patch can't go into trunk?
pmichaud I might be able to add one, but I'm not sure it's worth the trouble at this point.
chromatic Trunk has the GC patch applied.
jnthn Oh, there we are then.
pmichaud okay, then trunk is what we should be looking at :)
chromatic We cherry picked it for the 2.1.1 release.
colomon but trunk has a bunch of other stuff as well, if I understand them correctly.
jnthn Right
jnthn tries it too
PerlJam pmichaud: what if this happened around Rakudo * time? :)
chromatic Sure, trunk has lots of merges.
pmichaud colomon: sure -- we need to see if rakudo will build against current trunk. We'd have to do that anyway sometime in the next week or so, that's nothing new. 21:23
21:23 patspam joined, nbrown left, nbrown joined
jnthn chromatic: Did that s/pmc_new/Parrot_pmc_new/ branch land yet? 21:24
pmichaud PerlJam: We should have a week between the Parrot release and the Rakudo * release to resolve any issues.
colomon pmichaud: but it does interfere with our policy of Rakudo releases being tied to a specific Parrot release, no?
chromatic jnthn, it hasn't landed yet. I asked Whiteknight to hold off until after the release.
jnthn chromatic++
pmichaud (until after the Rakudo release :)
colomon: as long as the rakudo release works with the 2.1.1 release, we're good. 21:25
The point is that we don't want to release a rakudo that doesn't work with a Parrot release.
(that doesn't work with _any_ Parrot release)
colomon pmichaud: ah, okay, so if we work with 2.1.1 but prefer trunk HEAD, that's okay, then. :)
jnthn Yeah, that's our only issue. If we have to patch up for trunk in a way that somehow broke things in 2.1.1.
pmichaud the svn revision number is really only used when checking out a fresh copy of Parrot under --gen-parrot
and when verifying that a given installation of parrot is recent enough 21:26
rakudo builds against parrot head, now spectesting
(r44147 for those following along) 21:27
jnthn pmichaud: Same in process here on Win32 also. 21:28
pmichaud looks like we pass 21:29
colomon \o/ 21:30
pmichaud has anyone heard from Su-Shee today?
(I'm up through S32 already with no issues)
colomon pmichaud: she popped in for a bit earlier this afternoon.
pmichaud okay, reading backscroll 21:31
and I think we settled on Amsterdam for this release?
JoWie O.o amsterdam
21:32 awwaiid left
jnthn Confirm successful build on Win32 also. 21:32
pmichaud oh, I think I forgot to pull jnthn++ Shiny New Features before this test
either way, I think it confirms that we'll be able to use whatever svn number corresponds to the branch and/or tag 21:33
and, we _could_ still mark the release as being tied to 2.1.0, but recommend that people use 2.1.1 or later. :) 21:34
chromatic Not if we pull 2.1.0 from the site. 21:35
frettled Accidentally gone, whooops?
pmichaud rakudo itself never downloads a Parrot release.
jnthn pmichaud: I get one new failure here. 21:36
t\spec\S04-statements\terminator.rakudo ....................... Dubious, test re
turned 150 (wstat 38400, 0x9600)
Failed 10/14 subtests
pmichaud ....returned 150?!?
probably some silly Win32 thingy :)
jnthn pmichaud: Oh.
pmichaud: It runs from the shell to completion.
pmichaud not a blocker then. 21:37
jnthn pmichaud: Random segv maybe? :-/
pmichaud could be
those still show up from time to time :-|
jnthn Yes, though fixing the pool compaction thingy solved a bunch of them recently.
That aside I'm through to S32 now. 21:38
So think we're looking good.
colomon I bet fixing the GC leak probably helps as well.
dalek kudo/master: 6663abf | (Martin Berends)++ | docs/compiler_overview.pod:
[docs/compiler_overview.pod] clarified some explanations, total around 85% complete
pmichaud I'm into the OMGTHESETESTSARESOSLOW S32-trig section
jnthn Yeah :-|
21:39 Chillance joined
chromatic If someone extracted some trig tests into standalone PIR files (ah, how I dream!), I'd happily profile and optimize Parrot where possible. 21:39
pmichaud we're not sure exactly why they're slow yet 21:40
I don't think it's the trig itself, although that's possible
My guess is it's either the test harness itself doing things in a slow way, or something about how we have to set up for trig operations
colomon I suspect we could learn a lot from a good profile, even if a parrot fix is not called for.
chromatic I fixed a handful of String PMC malfeasances late Tuesday from some Rakudo profiling. 21:41
21:41 uniejo left
jnthn perl tools\benchmark.pl shows an overall slow-down in method calls and sub calls. 21:41
I know part of why that is.
(Slurpy hash creation got expensive. I can make it cheaper again though.)
colomon chromatic: how many tests would you like to get? 21:42
chromatic Two or three, if they exercise different things. 21:44
mberends colomon: you mean "how many thousand tests"?
colomon mberends: that is actually more or less what I was thinking, yes. :)
chromatic Anything that takes more than three or four wallclock seconds to run is harder to profile. Callgrind is not speedy. 21:45
21:45 alinbsp joined
colomon chromatic: okay, that will require some severe pruning, but let me see what I can do. 21:45
pmichaud with r44147
All tests successful.
colomon \o/ 21:46
jnthn Yay
pmichaud: Looks to be heading that way here too. :-)
coke if you word your announcement properly, I suppose you can just go whenever, and when 2.1.1 shows up, yay.
colomon does think it's a little odd that everyone is getting excited about test speed now, when the spectest runs routinely took an hour on master...
pmichaud coke: I'm thinking we'll likely hold until much later tonight or early tomorrow 21:47
there are a few other things we'd like to get in place, and our likely release managers tend to be positive longitude
colomon has hacked-sin.t down to 177 tests, 11 wall seconds. 21:48
pmichaud colomon: I think it's more that we have an increased number of active committers now 21:49
colomon: but yes, we're performing much better than master was
colomon pmichaud: well, we're not testing a lot of stuff.
pmichaud colomon: it's also just that it's obvious that this particular section of tests are slow for some reason
colomon I admit I've gotten spoiled by quick spectests, and would love if they would continue to be quick. 21:50
21:50 pjcj left
mathw hello hello 21:50
jnthn hi mathw :-) 21:51
21:51 pjcj joined
pmichaud need reboot here -- bbiab 21:51
jnthn Tests finished and looked fine. 21:54
colomon now how to generate PIR from a .t file?
jnthn --target=pir 21:55
colomon and just pipe that to a file?
21:56 patspam left
jnthn yes 21:56
colomon chromatic: how would you like me to get this to you? 21:57
chromatic nopaste is fine, direct mail is okay (chromatic wgz org) 21:58
pmichaud back again 22:00
mathw wb pmichaud 22:03
Su-Shee mberends: thanks for jumping in, I totally forgot about it. :/ 22:05
hi all.
mberends Su-Shee: we'll catch you another time ;)
jnthn hi Su-Shee
colomon is having difficulty uploading a file. stupid computers. 22:06
[particle] nopaste 22:07
heck, parrot/tools/utils/nopaste.pl
mathw Su-Shee: next month
Su-Shee mberends: I didn't even realize that it's feb. already.
mathw: it's not booked until 2012? ;) 22:08
mathw I have no idea :) 22:09
mberends Su-Shee: smash is booked for March, pmichaud for April. That's all
Su-Shee mberends: this is the first ng-made-master release? 22:10
mberends yes :) and looking good!
pmichaud and I'm only tentative for April :-)
(only because I don't know what will happen around the Rakudo * release) 22:11
Su-Shee mberends: *pew* :)
dalek kudo/master: c69aeb9 | pmichaud++ | docs/release_guide.pod:
Update release_guide.pod with more names.
 22:13
pmichaud German Perl Workshop is likely in early June, perhaps a .de person can do the May or June release :)
(and yes, I'm planning to attend :-)
mathw oooh
German Perl Workshop
Su-Shee and yapc eu is in july.
mathw wonders if he could afford that 22:14
jnthn pmichaud: Planning to attend GPW? 22:15
pmichaud yapc eu is in ... july?
jnthn: yes.
jnthn pmichaud: August.
Right at start of. 22:16
pmichaud right, august is normal for yapc::eu
mathw GPW would make sense for me because I know I can survive in Germany.
jnthn pmichaud: Pondering GPW instead of YAPC::EU?
pmichaud: Or aiming for both if pos?
pmichaud aiming for both -- depends on sponsorships
jnthn OK.
22:16 ggoebel left
Su-Shee
.oO(where the hell is "schondorf"..)
 22:17
22:17 ggoebel joined
dalek kudo/master: 2663b19 | (Martin Berends)++ | docs/ (2 files):
[docs/] additions to ChangeLog and announce/2010.02
 22:18
colomon chromatic: e-mail off to you, apologies for the delay -- file selection is broken in OS X chrome now or something. 22:19
mathw Su-Shee: near Stuttgart, it says 22:20
chromatic Thanks.
Su-Shee mathw: never heard of it. can't be large. ;)
22:21 ive left, snarkyboojum joined, ggoebel left 22:32 wknight8111 joined
lichtkind Su-Shee: you did parrot release? 22:34
22:36 Su-Shee left 22:38 bluescreen left, jonasbn00b left
jnthn oh lol 22:39
I've just done two silly little optimizations. 22:40
Between them they take the spectest run for me from 21 minutes to 13 and a half.
chromatic You still can't have my trophy.
pmichaud wheeee!
I can do an optimization that cuts the spectest time even lower. 1,$s/^/#/ on t/spectest.data :-P 22:41
jnthn :-P
lichtkind chromatic++
dalek kudo/master: a04aba2 | jonathan++ | src/pmc/p6opaque.pmc:
Since we wrapped out Parrot routines in our own wrappers, we added an extra PIR invocation as a re-direct every time. Optimizing that path to save the extra invocation seems to save us > 30% in some benchmarks.
kudo/master: 15ba550 | jonathan++ | src/builtins/Mu.pir:
Since we've no custom metaclasses yet, we can cheat in the default BUILD a bit (when we do have them, we can probably move this BUILD into the meta-class and continue to cheat, albeit at tail-call cost or so.
jnthn OH NOES I missed a closing paren! :-O 22:42
...in the commit message.
:)
mberends ^ extra closing paren :)
jnthn :) 22:43
oh noes, unbalanced again
lichtkind chromatic: can i asky you several questions? 22:44
chromatic Yes.
lichtkind thanks
chromatic jnthn, that first patch there in P6Opaque looks like something Parrot should be able to handle.
22:44 iblechbot left
jnthn chromatic: "able to handle"? 22:45
chromatic You're basically looking for an overridden invoke somewhere in MRO, right? 22:46
jnthn chromatic: I overrode that because I didn't like Parrot's vtable-invoke behavior at the time, but that may have changed.
chromatic: But the optimization was to detect and optimize for a particular hot-path. 22:47
chromatic Right, I see that.
jnthn But possibly these days we can just remove most of that and delegate up to Parrot.
chromatic I think we have a "is there a vtable override?" cache per class.
jnthn Does Parrot's vtable invoke unshift the PMC that was invoked onto the start of the call signature? 22:48
chromatic That I don't know without reading the code.
jnthn OK. That was the primary reason I overrode it.
Well, we used to do it differently than that, actually...my original override set it as a property on the sub, back before the PCC refactor. 22:49
And then once call signatures landed and it was easy to twiddle them, I switched to that approach instead.
chromatic Is this to stuff the invocant at the start of @_?
jnthn Right.
pmichaud Perl 6 expects the invocant as the first positional argument
jnthn Well, the problem is specific to vtable invoke. 22:50
chromatic In that you need access to the invocant in the vtable at the PIR level.
jnthn I don't know if Parrot changed, but a while back vtable invoke in PIR was useless because you didn't have a way of knowing what the $P0 that had been invokved in $P0(a,b,c) was. 22:51
Well
22:51 sjohnson joined
jnthn Less useful than I needed it to be, I should say. :-) 22:51
chromatic Yes, I remember that bug.
mberends all 4 of our talks have been confirmed at conferences.yapceurope.org/hack2010dk/talks
chromatic Okay. I won't promise that the code in P6Opaque can go away now, but I think there's a good chance it can disappear in the near future. 22:52
pmichaud the design of vtable invoke is slated to change, but I don't know if that's happened yet
(allison and I discussed this during a conference call last november)
jnthn Current code looks as though it may do something like what Rakudo does. 22:53
though it's marked
/* Experimental code. See DEPRECATED.pod */ 22:54
chromatic Right, and the way we check for vtable overrides will change to something much cheaper.
jnthn But it does a VTABLE_unshift_pmc(interp, call_sig, SELF);
So looks like it might be right.
chromatic Agreed.
jnthn Trouble is, I dunno if that means vtable invoke has changed, or if further changes are planned.
pmichaud istr there was a trac ticket for it. I'm certain I can get the relevant irc log, though. 22:55
jnthn But if it's going to have the same semantics as there, then yes, I can simply P6opaque.pmc
*simplify
chromatic It should have the same semantics, yes. 22:56
pmichaud wants to try out jnthn++'s speedup for himself :) 22:57
jnthn pmichaud: Another little one on the way soon too.
pmichaud 13.5 minute spectest run of 24k tests is... quite reasonable
jnthn pmichaud: Well, depends what you had before.
pmichaud not great, but reasonable
jnthn pmichaud: I had 21 minutes before. 22:58
chromatic Under 10 would be nice.
pmichaud the 44174 test I did a while ago was just under 20 minutes 22:59
coke ok. anyone try the 2.2.1 tarball?
pmichaud coke: I'll try it shortly. and surely it's 2.1.1, right?
(since 2.2.0 hasn't come out yet...?) 23:00
coke ... yes. 23:01
ok. I'
ll hold off on a release until you give it a whirl.
pmichaud what's the url for the tarball?
chromatic ~8 minutes to run spectest for me against Parrot HEAD, running 5 parallel test jobs. 23:09
23:11 ignacio_ left
jnthn has only 4 cores so isn't sure bumping beyond 3 parallel test jobs will be a huge win, given we seem to be fairly CPU-bound in the tests. 23:11
May be worth a try though. 23:12
pmichaud 12m30 for me to run against PARROT 44147, non-parallel 23:21
23:22 Juerd left, Juerd joined
colomon btw, I get the impression (from top) that 3 parallel test jobs is the default, even for dual core systems? 23:22
pugs_svn r29778 | lwall++ | [Spec] simplify series operator by moving generator function to the left side
r29778 | (any function on right side will now be a limiting conditional)
r29778 | * is no longer required to intuit series on the left, merely absence of generator before ...
r29778 | first argument on right is always a limiter argument
pmichaud colomon: that's the default used by t/harness, yes.
pugs_svn r29778 | add new ...^ form to exclude a literal limiter for convenience
23:22 athenot left
pmichaud yay! more spec changes!!! :-) 23:23
TimToady I don't expect them to get into this release. :)
but it is, in fact, a simplification
23:23 am0c joined
pmichaud well, *I* didn't promise which version of the spec we'd support in April. :-P 23:23
(yes, I'm sure it will be done in the next few days :) 23:24
23:25 Schwern left
jnthn pmichaud: That's non-parallel? Wow! 23:25
colomon how long is the released delayed for? ... ;)
pmichaud jnthn: yeah, I don't think I have TH3 installed on my notebook. 23:26
it doesn't appear to be running parallel there at the moment.
yeah, my notebook still has TH2.64 23:27
and yes, my notebook tends to be pretty speedy 23:28
jnthn Time to spectest my latest opt (make slurpy hash creation faster) 23:29
Between this opt I'm now spectesting and the previous two I pushed an hour or so ago, 10,000 method dispatches benchmark now takes approx a *third* of the time I did before.
chromatic Looks like there's some fat in P6Opaque's find_method() too. 23:30
Any reason Whatever can't override that itself? 23:31
jnthn chromatic: I've got plans for doing that in the future 23:32
chromatic: I want to work it into some more general "writing customer dispatcher" stuff that needs doing anyway.
But yes, I'd like that to go away too.
chromatic The other thing I notice there is that building and caching a hash of "Methods this shouldn't be!" would be cheaper than those string comparisons.
jnthn chromatic: Yeah, it probably would. That special list has kinda grown organically...I still sorta half feel they're a design smell as well as a performance issue. 23:34
23:34 payload left
chromatic Nothing in the trace really jumps out at me as an obvious win from the Parrot side. 23:34
There are a handful of 2-3% potential improvements. 23:35
pmichaud 2.1.1 tarball passes spectest against rakudo head just fine. 23:36
run spectests in 12m0s (non-parallel) 23:37
*ran
jnthn chromatic: You got the trace of Rakudo's bits of C too?
chromatic: Any info on the relative costs there?
chromatic Most of what's expensive is in Parrot, as you might expect. 23:38
find_method() is where Rakudo's C starts to get expensive.
jnthn How does stuff in bind.c figure?
OK, that's useful to know.
pmichaud afk, dinner fetch
chromatic The most expensive one is Rakudo_binding_bind_one_param() and it's pretty cheap. 23:39
jnthn OK, good.
And yes, I'd expect that to be the more costly spot.
With this patch, spectest is now down under 9 minutes for me. \o/ 23:40
chromatic I can squeeze out a little more. 23:41
mberends jnthn++
23:41 hatsefla1s is now known as hatseflats
jnthn \o/ 23:41
Pushed.
My spectest run before these patches took 1258s. My latest one took 517s.
Meaning I can now do a spectest run in 40% of the time I could earlier. 23:42
I think I can haz a beer now.
lichtkind jnthn: excellent idea 23:43
23:43 snarkyboojum left 23:45 Chillance left
dalek kudo/master: e77b754 | jonathan++ | src/ (2 files):
Optimize hash - especially slurpy hash - creation.
 23:46
23:50 snarkyboojum joined
lichtkind jnthn: zravičko 23:50
jnthn: zdravičko
jnthn :-)
snarkyboojum dobar dan 23:51
jnthn snarkyboojum: dobry večer :-) 23:53
snarkyboojum :)
jnthn Slovanske jazyky FTW. :-)
23:55 johnz left 23:58 johnz joined
jnthn chromatic: Another thing I wish was faster is Rakudo startup... 23:58
Granted it's better now than it has been in the past.
chromatic No kidding.
Is that mostly PMC freeze/thaw?
jnthn Parrot got a load better there.
Not sure.
Part of it is that we do so much work at startup
Through not having persisted stuff. 23:59
23:59 snarkyboojum is now known as aeschylus, aeschylus is now known as snarkyboojum

Powered by Cro and the Raku® Programming Language.

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

Thank you!