pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
bacek pugs: index("Hello World", "x") 01:25
p6eval pugs: RESULT[-1]
scrottie grr. 01:31
dduncan question: what toolkit do you presenters recommend or are currently using: eg, Spork, or XUL, or something else? I see talks in both formats in the Pugs repo. I'm inclined to try Spork first, but I'm concerned about CPAN showing it has a lot of failing tests with recent Perls, though that may just be the tests ... is anyone using Spork right now? 06:27
rindolf Hi all. 09:07
clkao: here? 09:09
pmurias rindolf: hi 09:13
rindolf Hi pmurias 09:16
pmurias: what's up?
pmurias last minute registering for university ;) 09:17
i'll propably make pixie pass more tests ones i get that done 09:20
rindolf: and what's up for you? 09:21
rindolf pmurias: chatting.
pmurias: trying to be able to send email again to @perl.org
I can receive email.
pmurias rindolf: you're trying to get unbanned? 09:23
rindolf pmurias: yes. :-(
pmurias you can always get a new email adress :(
rindolf pmurias: I did.
[email@hidden.address]
But I like shlomif. 09:24
pmurias pixie: say 'hi' 10:13
p6eval pixie: No output (you need to produce output to STDOUT)
pmurias moritz_: what does the recompilation of implemenations in the evalbot? 10:17
moritz_ pmurias: cron 10:19
pmurias: sudo chroot /new_chrrot; su - evalenv; crontab -e 10:20
don't know if I've installed oone for pixie yet
pmurias pixie: say 'hi' 10:21
p6eval pixie: No output (you need to produce output to STDOUT)
moritz_ pugs: .print if $_ % 2 for ^11; 11:18
p6eval pugs: OUTPUT[*** ␤ Unexpected "for"␤ expecting operator␤ at /tmp/OhQtSW0ba7 line 1, column 18␤]
FadeAway7 hi, audreyt 11:29
moritz_ rakudo: my $x = sub { 1; }; say $x.WHAT 11:39
p6eval rakudo 28889: OUTPUT[Sub␤]
moritz_ rakudo: my $x = { 1; }; say $x.WHAT 11:40
p6eval rakudo 28889: OUTPUT[Code␤]
ruoso starts today on the SMOP grant work ;) 13:04
kolibrie ruoso++ 13:08
moritz_ TimToady: maybe you could/should add a clause to statement_control:unless that warns nicely about 'else' 13:23
s/warns/croaks/, more likely
rakudo_svn r28895 | pmichaud++ | [rakudo]: 13:27
r28895 | pmichaud++ | * spectest-progress update: 75 files, 1172 passing tests
ruoso @tell pmurias how far have you gone with the alternative sm0p parser? is it producing code already? 14:37
ops... E_NO_BOT
pugs_svnbot r21129 | ruoso++ | [SMOP] Starting to write the test for p6opaque. Currently it is created and destroyed, but nothing is called 14:45
pmichaud anyone know how many tests are in the pugs test suite (approximate number)? 15:12
[particle] 18k-20k
pmichaud okay, works for me.
[particle] so we're 5+% done :) 15:13
moritz_ I can confirm that 15:15
pmichaud thanks :-)
I'll say 19k then. 15:17
any estimates for how many have made it into t/spec ? 15:18
[particle] looking now...
moritz_ by sheer file size a quarter to third
pmichaud that's probably good enough
since it's a rapidly moving target anyway 15:19
moritz_ not as rapidly as I'd hoped for
but still not bad
[particle] ack plan t/spec -wh 15:20
should be a way to add those quickly enough
[particle] there are at least 4500 tests in t/spec atm 15:38
ack plan t/spec -wh | perl -nle"$_=~m/(\d+)/;$x+=$1;print$x" 15:39
... 15:40
4525
running that on t/ gives 19389
moritz_ ok, between 1/5 and 1/4 15:41
pmichaud perfect
[particle] some plan()s have expressions in them, so it's not exact
moritz_ aye 15:42
pmichaud I'm saying ~19,000 in pugs and ~5,000 in t/spec
we're within 10% :-)
(er, those numbers are within 10% of the actual numbers)
[particle] yep
btw stevan says the t/oo/from_moose/ tests should be removed--they're way too out of date 15:43
pmichaud stevan++ 15:44
are all of the tests in t/ for Perl 6, or do some of them test other things (such as moose)?
moritz_ [particle]: will you rip them out? or should I?
stevan_ [particle]: soon we will have better tests for you guys
moritz_ stevan_: if you want to be the hero of the realm, formulate them language agnostic ;-) 15:46
[particle] ok, 18864 tests in pugs/t/ now 15:47
pugs_svnbot r21130 | particle++ | these are way out of date, and will be updated soon, so sayeth the Moooooooose
stevan_ moritz_: one second, let me clone myself first ...
moritz_ ;)
[particle] don't forget to clone your threads
we don't need another ingy around here
pugs_svnbot r21131 | moritz++ | [t] operators/inc.t: shanged tests from dies_ok to eval_dies_ok
stevan_ moritz_: the idea is that we will move the class defs into their own files, and associate them with some .pl files that run the actual tests 15:48
they we have small test-runner that basically is the code for your .t file
moritz_ sounds sane
stevan_ so while they wont be language agnostic,.. they will be cleaned up such that mechanical translation should be easier
pugs_svnbot r21132 | moritz++ | [spec] moved operators/inc.t to spec/. rakudo says "Null PCM access in type()" 15:53
moritz_ t/operators/repeat.t sys that $str x -1 should be '', rakudo say "Cannot repeat with negative arg" 15:54
the former seems to be more in line with perl 5
pmichaud is there a ticket for the Null PMC access in type() yet?
okay, we can fix repeat. Feel free to file a ticket for it -- it should be an easy fix. 15:55
I need to refactor the Str class anyway.
moritz_ pmichaud: Ovid++ reported something with the same error message
pmichaud okay. That probably needs to be passed over to jonathan++
I'll see if I can find it and do that. 15:56
pugs_svnbot r21133 | moritz++ | [spec] moved operators/repeat.t to t/spec/, fixed POD 16:02
moritz_ rakudo: say ( (1, 2) xx 2 ).perl 16:06
p6eval rakudo 28901: OUTPUT[[1, 2, [1, 2]]␤]
moritz_ that's so wrong ;)
pmichaud yes, lists of captures has an issue with it. I have no idea what that problem is right now, but since I just updated Array handling it might be ripe for fixing now. 16:07
pugs: say ( (1,2) xx 2 ).perl
p6eval pugs: OUTPUT[(1, 2, 1, 2)␤]
pmichaud I might just get infix:<xx> to work in list context for now and worry about slicing context a bit later. 16:08
pugs_svnbot r21134 | moritz++ | [spec] fudged and corrected S03-operators/repeat.t
moritz_ funny, rakudo has infix:<x=>, but no infix:<xx=> 16:09
pmichaud STD.pm constructs the inplace assignment operators from the infixes automatically -- at present Rakudo has to identify them individually
that will undoubtedly be fixed as part of the STD.pm convergence effort. 16:10
rakudo_svn r28902 | moritz++ | [rakudo] one more file for spectest_regression 16:12
pugs_svnbot r21135 | moritz++ | [spec] moved ternary.t to spec/ 16:15
pugs_svnbot r21136 | moritz++ | [spec] fixed (aka removed) POD from ternary.t 16:16
pugs_svnbot r21137 | moritz++ | [spec] fudged ternary.t 16:19
r21138 | moritz++ | [spec] S29-list/grep.t fixed adverbial closure test 16:22
rakudo_svn r28903 | moritz++ | [rakudo] tests for ternary now in spectest_regression 16:23
moritz_ pmichaud: I see you added "### refactored to t/spec/S03-operators/equality.t" note to some tests - is there a good reason not to delete those? 16:26
pmichaud you can delete them now. I was trying to keep people from saying "oh, we need equality tests here too" and duplicating the tests. 16:27
moritz_ ok
pmichaud might leave a note that "tests for equality are in S03-operators/equality.t" though.
moritz_ don't think it's worth, since the tests are moving away from plain t/ anyway 16:28
pmichaud that's fine.
pugs_svnbot r21139 | moritz++ | [t] removed redundant tests 16:31
pugs_svnbot r21140 | moritz++ | [spec] moved short_circuit.t to spec/, fixed POD, shortened test descriptions 16:34
r21141 | moritz++ | [spec] fudged short-circuit.t 16:37
moritz_ moving tests to spec/ and fudging is much more rewarding when it leads to inclusion into spectest_regression 16:38
I just see one problem as the test suite grows: speed
pmichaud we'll be fixing that soon, too. I expect within the month. 16:40
we can quickly shave about 60% on each test file by precompiling Test.pm
moritz_ YaY
[particle] what's the remaining hurdle for that?
pugs_svnbot r21142 | moritz++ | [spec] added ticket number to fudge message in repeat.t
pmichaud [particle]: hurdle*s*, plural
at the moment the big hurdle is lexical handling 16:41
after that it'll be :load :init handling
but I can't fix :load :init until lexicals get resolved
every time I try to do something with fixing Rakudo to handle precompiled modules better, it comes back to an issue with lexical bugs in parrot 16:42
moritz_ should +'Inf' return a numeric Inf?
[particle] obviously they're undertested
numeric Inf is 'Inf' no?
moritz_ it seems rakudo doesn't do Inf at all 16:43
[particle]: think so
[particle] parrot doesn't handle Inf and NaN in a consistently yet 16:44
it relies on platform-dependent representation
s/representation/behavior/
pmichaud afk, errands
pugs_svnbot r21143 | moritz++ | [spec] moved numify.t to spec/, started fudging 16:46
ruoso just realised that the default object dispatcher for Perl 6 in SMOP will also be written in Perl 6 17:03
method dispatch($meta: $object, $identifier, $capture --> Any) 17:04
in the metaclass
it would be nice if someone could write a dispatch implementation in smop/src-s1p/P6Meta.pm
moritz_ why --> Any and not --> Object?
ruoso moritz_, not sure... maybe it should be --> Object 17:05
rakudo_svn r28906 | moritz++ | [rakudo] two more files for spectest_regression 17:06
ruoso it's cool that as I make progress in the low-level of SMOP, more things are to be defined in a higher level...
it's also cool that as this high-level parts are written, I can have a more precise idea of exactly which minimum features the runtime needs 17:07
moritz_ ruoso: how on earth could dispatch() written in perl 6 work? Surely it has to call methods, and take care not loop 17:10
ruoso by using the REPR api
it has means of introspecting the actual object contents
and all that is available by method calls only... 17:11
since the same metaclass can be used by different representations...
moritz_ so the methods for introspection would be dispatched by a different dispatcher? 17:12
ruoso yes, because the dispatcher is always object-specific
then I can break the loop by having low-level objects behaving as high-level objects
the REPR API is usually implemented directly in C 17:13
actually.... in p6opaque, the REPR calls are intercepted by the C code, and only the other calls go to "dispatch"
but from the outside, they're all simply method calls 17:14
moritz_, want to write a dispatcher? ;) ;) ;) ;) 17:15
moritz_ ruoso: I considered it. But I think I understand too little of introspection and mmd 17:19
ruoso understands less 17:20
;)
maybe that's a task for TimToady ;) 17:21
moritz_ hey, you know of the REPR API, I don't ;)
ruoso hides
pmurias ruoso: hi, it great that you started your grant ;) 18:09
pmurias @tell ruoso the alternative sm0p parser produces code for the stuff that was in KP6Grammar 18:23
nfffn
sorry
ingy hola 18:48
moritz_ an ingy!
hi
ingy hi moritz_ 18:49
I R A P 6 PORGAMMR!
anyone here use TimToady's new parser on a regular basis? 18:51
moritz_ ingy: pixie (a clone of "elf") does
ingy url? 18:52
who hacks on pixie?
moritz_ ingy: pmurias does
ingy thanks
moritz_ ingy: url is misc/pixie in the pugs repo
pixie: say "hi"
.oO( hope it works )
p6eval pixie: No output (you need to produce output to STDOUT)
moritz_ seems to be b0rked atm, and pmurias is on vacation 18:53
ingy moritz_: what is pixie in a nutshell? just a bot?
moritz_ ingy: no, it's a mostly bootstrapped compiler 18:53
ingy: p6eval is just a frontend, as it is to about every other implementation we have ;) 18:54
ingy perl 6 compiler?
DietCoke hopes ingy has pants on.
ingy undies
ingy works from home
moritz_ ingy: aye
DietCoke better'n'nothing.
ingy :)
ingy is writing a new porgamming lang 18:56
hoping to use p6 stuff for parser
moritz_ ingy: PGE is fairly stable. It's on parrot, but uses (mostly) Perl 6 rules 18:57
ingy well my backend code is already written 18:57
a long long time ago :)
moritz_ rakudo: say Bool::True 20:03
p6eval rakudo 28911: OUTPUT[1␤]
moritz_ rakudo: say <1 4 5> 20:04
p6eval rakudo 28911: OUTPUT[./parrot: error while loading shared libraries: /home/evalenv/parrot/blib/lib/libparrot.so.0.6.3: invalid ELF header␤] 20:05
moritz_ rakudo: say <1 4 5> 20:05
p6eval rakudo 28911: OUTPUT[145␤]
moritz_ rakudo: say <<1 2 3>> 20:06
p6eval rakudo 28911: OUTPUT[Statement not terminated properly at line 1, near ">"␤current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)␤]
moritz_ rakudo: my Int $x = 0; say $x.does(Int) 20:08
p6eval rakudo 28911: OUTPUT[Method 'does' not found for invocant of class 'Int'␤current instr.: '_block11' pc 118 (EVAL_13:51)␤]
moritz_ rakudo: my Int $x = 0; say $x.isa(Int)
p6eval rakudo 28911: OUTPUT[1␤] 20:09
pugs_svnbot r21144 | moritz++ | [spec] added simple tests for Enums, for jonathan's next rakudo day 20:12
pugs_svnbot r21145 | moritz++ | [spec] moved S12-enums to spec/, mistakenly added it to t/ first. moritz-- 20:15
Auzon moritz_: I think there are some enum tests already lurking about 20:15
moritz_ Auzon: yes, I let me inspire by them. But the test too much at once to be of any real use for jonathan, I think 20:17
actually they are quite thoroughly tested, it seems 20:18
the tests seem logically fine, but have a lot of cruft
I'm going to remove a ton of evals ands :todo<feature>s 20:19
moritz_ from S12: $x does day; 20:21
moritz_ does that mean we have an inifx:<does>? 20:21
Auzon brb
and yes, there is a does somewhere
moritz_ scary ;) 20:22
rakudo: say 1.2 !~~ Int
p6eval rakudo 28916: OUTPUT[1␤]
pugs_svnbot r21146 | moritz++ | [spec] moved oo/enum.t to spec/ 20:27
pugs_svnbot r21147 | moritz++ | [spec] updated t/state.t - need more review before moving it to spec/ 20:33
moritz_ rakudo: say ('' eq ('' & '')) 20:34
p6eval rakudo 28917: OUTPUT[1␤] 20:35
moritz_ rakudo: say ('' eq ('' & 'd'))
p6eval rakudo 28917: OUTPUT[0␤]
rindolf Hi all. 20:39
I'm so unbeliavably pissed off atm!
Somebody should calm me down. 20:40
moritz_ rindolf: I think that's easier for somebody in RL
rindolf moritz_: maybe.
moritz_: first KDE 3 got hanged up on Cooker. Twice! 20:41
moritz_: then I tried to talk about my @perl.org banning on irc.perl.org and Robrt-- was not there.
moritz_: and now he first banned and then K-lined me.
moritz_: so far he seems like he has a missing screw. 20:42
Well, maybe I'm more calm now.
I took a few deep breathes.
pugs_svnbot r21148 | moritz++ | [spec] started to move junction tests (and upate POD). Much more work need 20:45
pugs_svnbot r21149 | moritz++ | [spec] fudged S03-junctions/misc.t 21:09
rindolf is doing CBT 21:15
vixey hey rindolf 21:16
pugs_svnbot r21150 | moritz++ | [spec] a bit more fudge fiddling 21:17
rakudo_svn r28921 | moritz++ | [rakudo] first junction tests in spectest_regression
rindolf Hi vixey 21:18
moritz_ d'oh, t/junction/associative.t seems totally borked to me 21:19
it assumes that Junction.values returns the item in the order they were put it
rindolf TimToady: here? 21:21
moritz_ even more "d'oh', Junction.values is neither in in S03 not in S29
pugs_svnbot r21151 | moritz++ | [t] junctions/associative.t is b0rked 21:24
moritz_ rakudo: +(1..2)
Auzon moritz_: Am I correct in assuming that p5=> doesn't quote the LHS like the Perl 5 version?
p6eval rakudo 28922: RESULT[2]
moritz_ Auzon: I think it does (otherwise it would just be a comma) 21:25
on the other hand, infix:«p5=>» doesn't do any special handling in STD.pm 21:26
so actually I dunno
Auzon S03:1465 says that it's the same as a comma
moritz_ "This operator, which behaves exactly like the Perl 5 fatarrow in being equivalent to a comma" 21:27
I interpret that as "it constructs a list, not a pair"
and the p5 fatarrow does quote its LHS 21:28
Auzon perl6: say (1,2) !~~ Pair 21:30
p6eval elf 21151: OUTPUT[No viable candidate for call to multimethod infix__33_126(#,#,$) at (eval 123) line 3␤ at ./elf_f line 3861␤]
..kp6 21151: OUTPUT[syntax error at position 10, line 1 column 10:␤say (1,2) !~~ Pai␤ ^ HERE␤]
..pugs: OUTPUT[1␤]
..rakudo 28922: OUTPUT[1␤]
rindolf vixey: have you contributed stuff to Parrot lately? 21:30
moritz_ Auzon: I suppose you've seen rakudo.de/progress.png (or the similar graph rakudo.org)? part of it is your progress ;-) 21:31
Auzon Yep, I saw it on one (or more ;)) RSS feed 21:32
I'm simply amazed by everyone++'s progress 21:33
moritz_
.oO( t/junctions/chained_operators.t - what's the connection between file name and contents? )
 21:34
moritz_ decides that working on t/junction/* isn't very productive atm 21:35
I'd actually have to *think* ;-) 21:36
Auzon moritz_: In your graph, the yellow is mostly fudge, correct? 21:37
moritz_ Auzon: I think *all* of it is fudge ;)
moritz_ I'm running tools/test_summary.pl now, and it seems that most fudges are spread out over various files 21:40
which mean it's probably mostly done right 21:41
Auzon great :)
moritz_ well, exp.t passes 2 and skips 44 21:42
pmichaud Junction.values was discussed in p6l, I believe. 21:43
moritz_ but that should be fixed as soon as somebody applies bacek++'s patches for various Complex methods, including prefix:<->
pmichaud: pretty much everything has been discussed on p6l ;-) 21:44
pmichaud: what do we do with #56230 ? 21:45
(bacek's patches for Complex stuff)
vixey rindolf, no never 21:46
pmichaud I was thinking that bacek was going to move some of the operators into src/classes/Complex.pir, but apparently he didn't do that yet.
i.e., I think the complex stuff belongs in complex.pir, as opposed to the main operators file.
moritz_ I can do some of the moving, and apply it
moritz_ the question is if we stick to multis (for example for exp), or use a :multi(_) with a pmc as the param 21:47
Auzon perl6: my @arr = 1 .. 4; my %hash = @arr; %hash.perl.say
pmichaud what do we do if we get a pmc type that doesn't understand the 'exp' opcode?
p6eval elf 21151: OUTPUT["1E0"␤] 21:48
..kp6 21151: OUTPUT[syntax error at position 45, line 1 column 45:␤my @arr = 1 .. 4; my %hash = @arr; %hash.perl.sa␤ ^ HERE␤]
..pugs: OUTPUT[\(\("1", 2), \("3", 4))␤]
..rakudo 28922: OUTPUT[{"1" => 2, "3" => 4}␤]
moritz_ elf++ # most creative output ;)
cjfields perl6 : for [1..3, 4..6] { say $_.WHAT} 21:49
Auzon Yeah... I don't get it. Pugs's output is interesting as well
cjfields perl6: for [1..3, 4..6] { say $_.WHAT}
p6eval elf 21151: OUTPUT[Array␤]
..kp6 21151: OUTPUT[syntax error at position 4, line 1 column 4:␤for [1..3, 4..6] { say $_.WHAT␤ ^ HERE␤]
..pugs: OUTPUT[Array␤]
..rakudo 28922: OUTPUT[Int␤Int␤Int␤Range␤]
cjfields Rakudo's wrong
moritz_ and very interesting ;-) 21:50
cjfields perl6: for [1..3, 4..6] { say $_}
p6eval elf 21151: OUTPUT[123456␤]
..kp6 21151: OUTPUT[syntax error at position 4, line 1 column 4:␤for [1..3, 4..6] { say $_␤ ^ HERE␤]
..pugs: OUTPUT[1 2 3 4 5 6␤]
..rakudo 28922: OUTPUT[1␤2␤3␤456␤]
pmichaud I'm not sure that any of them are correct. :-) 21:51
moritz_ I think that for [...] -> {...} should always do only one iteration
pmichaud seems to make sense
I bet I can fix that one. 21:52
cjfields So what would be the expected answer
pmichaud if only one iteration, then pugs has it correct
"1 2 3 4 5 6\n"
cjfields That's what I thought
moritz_ OTOH, how would one iterate over an array ref?
for @$ref -> { stuff } ?
pmichaud perhaps for =[...] ?
Auzon for @ [...] ?
pmichaud prefix:<=> is the standard "iterator operator" 21:53
rakudo: for @ [1..3,4..6] { say $_; }
p6eval rakudo 28922: OUTPUT[1␤2␤3␤456␤]
pmichaud oh, that's weird.
cjfields rakudo: for [1..3, 4..6, 7..9] { say $_.WHAT} 21:54
p6eval rakudo 28922: OUTPUT[Int␤Int␤Int␤Range␤Range␤]
pmichaud rakudo: say @ [1..3, 4..6]
p6eval rakudo 28922: OUTPUT[1 2 3 4 5 6␤]
pmichaud rakudo: say (@ [1..3, 4..6]).WHAT
p6eval rakudo 28922: OUTPUT[Array␤]
pmichaud that looks a little funny to me. 21:55
rakudo: say (list [1..3, 4..6]).WHAT
p6eval rakudo 28922: OUTPUT[List␤]
pmichaud rakudo: say [1..3,4..6].list.WHAT;
p6eval rakudo 28922: OUTPUT[Array␤]
pmichaud that's definitely not what I expect. 21:56
cjfields rakudo: say @ [1..3, 4..6].elems
p6eval rakudo 28922: OUTPUT[6␤]
pmichaud oh, hrm. 21:57
cjfields rakudo: for 1..3, 4..6 { say $_.WHAT} 21:58
p6eval rakudo 28923: OUTPUT[Int␤Int␤Int␤Range␤]
cjfields same thing 21:59
moritz_ cjfields: make it a test, if it's not there in the suite yet
pmichaud rakudo: for (1..3, 4..6) { say $_.WHAT }
p6eval rakudo 28923: OUTPUT[Int␤Int␤Int␤Range␤]
pmichaud rakudo: say 1..3, 4..6;
p6eval rakudo 28923: OUTPUT[1234 5 6␤]
cjfields it's only expanding the first Range; any after are not expanded 22:00
pmichaud obviously a problem with listcontext there.
cjfields yep
moritz_: where should the test go?
Auzon Does it only happen with 'for'? If so, probably t/statements/for.t 22:01
pmichaud there are two problems here
one is what is happening with ranges inside of list contexts
i.e., say 1..3, 4..6; should result in 1\n2\n3\n4\n\5\n6\n 22:02
the other problem is how 'for' is iterating over Array
perl6: for [1,2,3,4,5,6] { say $_; }
p6eval elf 21151: OUTPUT[123456␤]
..kp6 21151: OUTPUT[no method 'APPLY' in Class 'Undef'␤ at compiled/perl5-kp6-mp6/lib/KindaPerl6/Runtime/Perl5/MOP.pm line 345␤ ]
..pugs: OUTPUT[1 2 3 4 5 6␤]
..rakudo 28923: OUTPUT[1␤2␤3␤4␤5␤6␤]
pmichaud pugs is correct.
(assuming that we think of iterating over an Array as being a single element, which I think it should be.) 22:03
cjfields I agree
moritz_ t/statements/for.t for that one, as Auzon++ suggested
the other one... do we have range tests?
pmichaud yes, in range.t, right? 22:04
Auzon /t/spec/S03-operators/range.t
or maybe t/spec/S02-builtin_data_types/range.t
Auzon looks to see the difference
pmichaud I think it's a question of whether we're testing the operator or the type 22:05
cjfields So should 'for 1..3, 4..6 { say $_.WHAT}' give a single Array, or two Ranges? 22:06
pmichaud neither. six Ints
cjfields So it should expand
pmichaud yes, because it's in list context.
moritz_ yes
cjfields the ranges
cjfields That's what I thought 22:07
cjfields perl6: for [1..3] { say $_.WHAT} 22:09
I think I killed it
p6eval elf 21151: OUTPUT[Array␤] 22:10
..kp6 21151: OUTPUT[syntax error at position 4, line 1 column 4:␤for [1..3] { say $_.WHAT␤ ^ HERE␤]
..pugs: OUTPUT[Array␤]
..rakudo 28923: OUTPUT[Int␤Int␤Int␤]
Auzon No, p6eval seems slower recently
cjfields perl6: for [1..3], [4..6] { say $_.WHAT}
p6eval elf 21151: OUTPUT[Array␤Array␤]
..kp6 21151: OUTPUT[syntax error at position 4, line 1 column 4:␤for [1..3], [4..6] { say $_.WHAT␤ ^ HERE␤]
..pugs: OUTPUT[Array␤Array␤]
..rakudo 28923: OUTPUT[sh: ./parrot: Permission denied␤]
Auzon rakudo: 1.say 22:11
p6eval rakudo 28923: OUTPUT[1␤]
cjfields rakudo: for [1..3], [4..6] { say $_.WHAT}
p6eval rakudo 28923: OUTPUT[Array␤Array␤]
cjfields ?!?
definitely a list context issue
moritz_ that last one is right
cjfields yes, but...
rakudo: for [1..3] { say $_.WHAT} 22:12
p6eval rakudo 28923: OUTPUT[Int␤Int␤Int␤]
pmichaud right
the comma is imposing list context
when the comma isn't there, the for statement is defaulting to item context, which is wrong.
Auzon rakudo: for ([1..3],) { say $_.WHAT}
p6eval rakudo 28923: OUTPUT[Array␤]
cjfields bingo
pmichaud yes. sorry for not explaining it earlier. I even know how to fix it, but I'm trying to figure out why 1..3,4..6 isn't working first. :-) 22:13
cjfields sorry to unload that one on you. 22:13
pmichaud testing spectest_regression now with fix for 1..3,4..6 22:15
moritz_ runs spectest_regression with the Complex patches applied 22:17
rakudo_svn r28924 | moritz++ | [rakudo] Implement prefix:+, prefix:-, sqrt() and exp() for Complex. 22:20
r28924 | moritz++ | Patch curtesy of bacek++, Vasily Chekalkin [email@hidden.address]
pugs_svnbot r21152 | moritz++ | [spec] unfudge complex.t 22:21
rakudo_svn r28925 | moritz++ | [rakudo] S29-num/complex.t is now pure. bacek++ 22:22
scrottie dammit. missed the reply to ingy's "anyone using TimToady's p6?". 22:25
moritz_ scrottie: that's what the good lord invent IRC logs for ;-) 22:26
scrottie: last URL in /topic
Auzon moritz_++ # irclog 22:31
rakudo_svn r28926 | pmichaud++ | [rakudo]: 22:32
r28926 | pmichaud++ | * Fix list context flattening when a lazy element (e.g., a Range)
r28926 | pmichaud++ | increases the number of items in the resulting list.
r28926 | pmichaud++ | * cjfields++ for finding this and providing useful test examples.
pugs_svnbot r21153 | moritz++ | [spec] fixed tests for return of failed Str.index(). bacek++, pmichaud++ 22:39
moritz_ actually all of these builtins need to be tested with named arguments 22:41
pugs_svnbot r21154 | moritz++ | [spec] tests for return type of index()
moritz_ so not only index($s1, $s2) but also index(string=>$s1, substring=>$s2) 22:42
Auzon Can I safely .pop an item off the end of an infinite array? 22:46
moritz_ no, don't think so
perhaps my @x = *..1; pop @x; might work 22:47
Auzon also, does reverse(1 .. *) go from Inf down to 1? 22:48
moritz_ no
it'll loop, I fear 22:49
unless you have a clever reverse(Range) multi
Auzon S03 says that reversed Ranges are still lazy
moritz_ maybe I should look into the specs before spilling bullshit ;)
Auzon S03:2650 is the section that I'm looking at 22:52
or it begins the section that is
pmichaud a reversed range is still lazy, yes. 22:54
pmichaud I suspect that reverse() will be implemented such that it (lazily) reverses all of the elements of the list 22:54
Auzon S03 says that there is a .min, .max, .to, and .from, which would be enough to do that without iterating it. 22:55
pmichaud also need .by 22:56
Auzon yeah, forgot that one.
pmichaud but what would be interesting is whether (1.1 .. 4.5).reverse starts at 4.1 22:57
(I'm assuming it will.)
Auzon I don't think so, since (1.1 .. 4.5).pop gives 4.5, and reversing a range only flips the to and from. 22:58
pmichaud actually, 1.1 .. 4.5 gives 4.1
Auzon oh, but there's .min and .max. Not sure :-/ 22:59
pugs_svnbot r21155 | moritz++ | [spec] unfudge passing tests 23:12

Powered by Cro and the Raku® Programming Language.

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

Thank you!