»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend!
Set by sorear on 4 February 2011.
flussence forums.gentoo.org/viewtopic-t-901474.html 00:04
flussence whoops, ww 00:04
diakopter [Coke]: the problem with the first idea is that redo/next/last lose their meaning inside loops (usually redo/next/last are enclosed in conditional blocks after all) 00:13
I like the second idea
dalek kudo/nom: ef4702d | Coke++ | t/spectest.data:
track failure modes
00:17
shachaf preflex: seen sorear 01:33
preflex sorear was last seen on #perl6 9 hours, 25 minutes and 11 seconds ago, saying: pir::setprop(...)
dalek odel: 80d077d | diakopter++ | lua/ (7 files):
decent perf improvements
02:02
cognominal I have to grok the sigiless silliness. 03:42
diakopter you have *yet to? 03:46
cognominal indeed. 03:49
sorear shachaf: hello! 04:27
good * #perl6
shachaf sorear: Happy birthday!
sorear Thanks. 04:28
niecza: say "hi" 04:29
p6eval niecza v11-22-gbebf7a0: OUTPUT«hi␤»
sorear \o/ p6eval is back
diakopter brrr 05:06
[Coke] nom: say "nom: say 'nom'" 05:17
p6eval nom ef4702: OUTPUT«nom: say 'nom'␤»
moritz happy sorear++ 05:55
moritz [Coke]: at your convenience, could you please add gist.github.com/1340539 to the top of rakudo's tools/build/Makefile.in and see if it still builds after a reconfigure? thank you 06:04
moritz [Coke]: on windows that is 06:15
sorear moritz: thanks 06:27
TimToady: do we have a good way to quantify the completeness of Unicode support? 06:30
or just S05 in roast hmm
tadzik good morning #perl6 09:40
happy birthday sorear!
moritz I have some trouble understanding how native ints and Int mix 10:28
in particular, if I write 1233 * 456, are these two numbers native ints? 10:29
or can they be used both as native ints and Int, as rakudo does?
trouble is that if they are interpreted as native ints, and are a bit larger than in my example, they can overflow
erm, not they, but the result of the operation 10:30
moritz nom: pir::say pir::typeof__SP(3) 11:04
p6eval nom ef4702: OUTPUT«Int␤»
moritz jnthn++ # factoring SymbolTable (and its usage in the actions) very nicely 11:24
moritz I have hopes that the codegen changes for the bigint things doesn't become too ugly 11:25
dalek kudo/bigint: 29eeaf8 | moritz++ | src/Perl6/ (2 files):
start to generate bigints in the actions.

Does not compile the setting yet
12:47
kudo/bigint: e2c2af5 | moritz++ | src/Perl6/Actions.pm:
switch radcalc to bigints

now dies in quote_escape:sym<hex>
moritz "get_integer() not implemented in class 'Int'" 12:49
that error message has a certain irony
dalek p/bigint: 05d6ab2 | moritz++ | / (3 files):
add nqp::isbig_I op, and nqp:: variants for bigint <-> str conversion
13:10
p/bigint: 9647ef9 | moritz++ | src/HLL/Actions.pm:
make ints_to_string a method, so that it can be overridden in subclasses
dalek kudo/bigint: e68268b | moritz++ | src/Perl6/Actions.pm:
fix hex escapes; restore compilation of the setting
13:25
dalek kudo/bigint: b147776 | moritz++ | src/Perl6/SymbolTable.pm:
move bigint serialization to the proper place
13:54
smash hello everyone 13:55
moritz hi smash 14:01
nom: say 9999999999999999999999999 + 1
p6eval nom ef4702: OUTPUT«Use of uninitialized value in string context␤Use of uninitialized value in string context␤===SORRY!===␤error:imcc:eval_ins: op 'add_i_n_i' not found␤␤ in file '(file unknown)' line 58506025␤»
moritz huh :-)
b: say 9999999999999999999999999 + 1
p6eval b 1b7dd1: OUTPUT«1.59089797835941e+18␤»
moritz locally:
$ ./perl6 -e 'say 9999999999999999999999999 + 1' 14:02
10000000000000000000000000
there's still a decent degree of brokenness in that branch
but at least the codegen for ordinary int literals seems fine 14:03
nom: say 9999 ** 10
p6eval nom ef4702: OUTPUT«-9223372036854775808␤»
tadzik moritz++ 14:28
moritz the radcalc code looks a bit weird/redundant 15:03
the cases that creates a Rat, that is
moritz return $*ST.add_constant('Rat', 'type_new', 15:04
$*ST.add_numeric_constant('Int', $iresult)<compile_time_value>,
$*ST.add_numeric_constant('Int', $fdivide)<compile_time_value>,
moritz :nocache(1) 15:04
);
moritz why the the add_numeric_constant calls when the result is discarded? 15:05
and it seems the Rat case is special-cased anyway to serialize the nu and de 15:06
tadzik what do you mean: discarded?
moritz I mean that only $thing<compile_time_value> is passed on to $*ST.add_constant 15:07
but $thing (return value from add_numeric_constant) isn't used
but $iresult and $fdivide already are compile-time values
tadzik but it's in the symboltable 15:08
the 'call add_constant and use only the <compile_time_value>' seems quite common in Actions, methinks
hmm, I may see your point
moritz $ST.add_constant special-cases the codegen for the arguments when the type is 'Rat' 15:10
tadzik oh 15:12
moritz and the trouble with that special case is that it assumes that Int round-trips on unboxing to int, and then boxing again 15:14
which is broken by bigints
which is why Rat literals for big numbers are just as broken in the bigint branch as in nom
nom: say 3.14444444444444444444444444444444444
p6eval nom ef4702: OUTPUT«===SORRY!===␤bigint_get_long: number too big␤»
moritz ok, broken in a different way :-) 15:15
$ ./perl6 -e 'say 3.14444444444444444444444444444444444'
Segmentation fault
tadzik I completely don't understand grammars in nom
moritz let's wait 'til after the rebuild
tadzik b: gist.github.com/1358234 15:16
p6eval b 1b7dd1: OUTPUT«keys: ("zebra")␤elems: 3␤elems2: 1␤"whatever"␤»
tadzik nom: gist.github.com/1358234
p6eval nom ef4702: OUTPUT«keys: ().list␤elems: 1␤elems2: 0␤"whatever"␤»
tadzik seems that captures are lost more often than we thought 15:16
moritz try $/.list.keys 15:17
erm
$/.hash.keys
tadzik still () 15:18
moritz the bigints + rat business is rather fiddly :/ 15:28
when I call a nqp::something_I() op with something that isn't a bigint, it segfaults 15:29
moritz jnthn: moritz.faui2k3.org/tmp/rat-bigint.patch on the bigint branch (needs newest nqp/bigint) makes the arguments to Rat.new() come out as Mu instead of Int while compiling the setting, and I don't understand why. Maybe you can take a look... 15:45
moritz nom: BEGIN my $*QSIGIL = 5; $y 17:54
p6eval nom ef4702: OUTPUT«(signal SEGV)» 17:55
moritz oops.
dalek kudo/bigint: 3d97eda | moritz++ | src/core/Int.pm:
use new nqp::pow_I opcode
18:26
kudo/bigint: 7c6a4a6 | moritz++ | src/Perl6/Actions.pm:
use add_numeric_constant for numeric constant
kudo/bigint: 933a1a5 | moritz++ | src/Perl6/Actions.pm:
document some assumptions; remove unused variable

no functional changes
moritz perl6: say 9 ** -10 18:29
p6eval niecza v11-22-gbebf7a0: OUTPUT«1/3486784401␤»
..rakudo ef4702: OUTPUT«2.86797199079244e-10␤»
..pugs b927740: OUTPUT«*** ␤ Unexpected "-"␤ at /tmp/d5IRG5jOst line 1, column 10␤»
moritz infix ** seems to work nicely in the bigint branch 18:36
moritz now if I could only get these f#### Rat literals working... 18:37
moritz nom: nqp::say(my $x) 19:12
p6eval nom ef4702: OUTPUT«Use of uninitialized value in string context␤␤»
moritz mqp: say(my $x)
nqp: say(my $x)
p6eval nqp: OUTPUT«␤»
clsn nom: "e u a u e u a" ~~ /:sigspace ("a") ([<[aeiou]> ]+)$/ 19:13
p6eval nom ef4702: ( no output ) 19:14
clsn nom: say ("e u a u e u a" ~~ /:sigspace ("a") ([<[aeiou]> ]+)$/)
p6eval nom ef4702: OUTPUT«=> < a u e u a>␤ 0 => <a>␤ 1 => <u e u a>␤␤»
clsn nom: say ("e u a u e u a" ~~ /:sigspace .("a") ([<[aeiou]> ]+)$/)
p6eval nom ef4702: OUTPUT«#<failed match>␤»
clsn Does that make sense to anyone? The only difference was adding a . before the ("a"), and if you look at the prior match, there IS stuff before it.
std: say ("e u a u e u a" ~~ /:sigspace ("a") ([<[aeiou]> ]+)$/) 19:15
p6eval std be1f10e: OUTPUT«Potential difficulties:␤ [<[aeiou]> ] appears to be an old-school character class; please use <[<[aeiou]>\x20]> if you␤ mean a character class, or quote it like '<[aeiou]> ' to match␤ string as a unit at /tmp/Olyn9W30q8 line 1:␤------> e u a" ~~ /:sigspac…
moritz clsn: it seems that it doesn't backtrack when it should 19:15
clsn Yeah. It gets weirder:
nom: say ("e u a u e u a" ~~ /:sigspace .?("a") ([<[aeiou]> ]+)$/) 19:16
p6eval nom ef4702: OUTPUT«=> < a u e u a>␤ 0 => <a>␤ 1 => <u e u a>␤␤»
clsn But
nom: say ("e u a u e u a" ~~ /:sigspace (.?)("a") ([<[aeiou]> ]+)$/)
p6eval nom ef4702: OUTPUT«#<failed match>␤»
clsn So it fails *only* if you're trying to capture that part.
sorear niecza: say(my $x) # is this entirely wrong, then?
p6eval niecza v11-22-gbebf7a0: OUTPUT«Potential difficulties:␤ $x is declared but not used at /tmp/Z_dLBnm2XM line 1:␤------> say(my ⏏$x) # is this entirely wrong, then?␤␤Any()␤»
moritz so another instance of "backtracking over capures wrongly"
erm 19:17
modulo English
sorear: not at all
TimToady niecza: say ("e u a u e u a" ~~ /:sigspace (.?)("a") ([<[aeiou]> ]+)$/)
p6eval niecza v11-22-gbebf7a0: OUTPUT«#<match from(3) to(13) text( a u e u a) pos([#<match from(4) to(4) text() pos([].list) named({}.hash)>, #<match from(4) to(5) text(a) pos([].list) named({}.hash)>, #<match from(6) to(13) text(u e u a) pos([].list) named({}.hash)>].list) named({}.hash)>␤»
clsn Is this stuff known, or worth sending in? 19:17
TimToady niecza: say ("e u a u e u a" ~~ /:sigspace .("a") ([<[aeiou]> ]+)$/)
p6eval niecza v11-22-gbebf7a0: OUTPUT«Match()␤»
moritz sorear: I've only tested nqp and nom with pir::say
sorear needs to invent a less verbose syntax for Match.perl
moritz clsn: worth reporting
sorear: for Match.gist at least
sorear ...right that's what I meant :|
clsn Thanks. I live in deathly fear of sending in an extraneous bug report... 19:18
moritz clsn: don't be. We sometimes get duplicate bug reports, and they don't kill us
clsn: the search facility of rt.perl.org sucks, so it's inevitable
and with > 500 tickets it's simply impossible to track in your head what's submitted and what not 19:19
clsn OK. Thanks for the encouragement. 19:20
TimToady niecza: say ("e ! a u e u a" ~~ /:sigspace .("a") ([<[aeiou]> ]+)$/)
p6eval niecza v11-22-gbebf7a0: OUTPUT«Match()␤»
TimToady niecza: say ("e !!a u e u a" ~~ /:sigspace .("a") ([<[aeiou]> ]+)$/) 19:21
p6eval niecza v11-22-gbebf7a0: OUTPUT«#<match from(3) to(13) text(!a u e u a) pos([#<match from(4) to(5) text(a) pos([].list) named({}.hash)>, #<match from(6) to(13) text(u e u a) pos([].list) named({}.hash)>].list) named({}.hash)>␤»
TimToady this is arguably correct behavior for bare .
if <ws> matches real ws it probably should not match '' on either end of it
clsn I was just looking at that. using ". " instead of "." works... Is . not allowed to match space under :sigspace? 19:22
TimToady that's not the problem 19:23
moritz nom: say :10<3*10**3>
p6eval nom ef4702: OUTPUT«3000␤»
moritz nom: say :10<3*10**3>.WHAT
p6eval nom ef4702: OUTPUT«Num()␤»
TimToady <ws> matches one way or the other, but does not imply a backtrack inside it 19:24
moritz TimToady: should that prodcue a Num (in analogy to 3e3)?
or an Int instead?
and :10<3.0*10**3>? Rat? Num? Int? 19:25
TimToady S02:3287
moritz so even :10<0.1*10**1> produces an Int 19:28
TimToady according to current spec, yes
sorear TimToady: iirc, we want <.ws> <.ws> to mean the same thing as <.ws> 19:29
TimToady well, sure, since you can put two spaces in a row into sigspace patterns pretty easily
std uses memos to handle that, generally 19:30
sorear yeah, just saying that we need <.ws> to match "" on the _right_ side of "real ws" 19:31
TimToady sure, but it's still not backtracking either of them
clsn Does the space after the :sigspace adverb count as a <.ws> space? I would expect not. 19:31
TimToady it currently does, though we've considered changing it
it would make some things easier, and also harder to explain :) 19:32
clsn In that case, the problems I'm seeing do make some sense, but then how does one make a :sigspace pattern that does not start with <.ws>?
TimToady put the :s after what you want to match without it, for one
or use an unspace 19:33
but in general, it would help rules participating in LTM if we changed it to ignore ws before the first subtoken
STD has a bunch of token decls with :s that could just be rules if that were the case
assuming that the 'ignore ws after :s' also applies to the implicit :s of "rule" 19:34
it would be a sane default, and one can always force it the other way with [ ] or <ws> if needed 19:35
clsn (these matches worked differently in past rakudos, btw, but if the current behavior can be claimed to be correct that isn't so important a point.)
TimToady but as I said, the only thing preventing it that I can see is that it'd be harder to explain
clsn I don't know; that the adverb has to be delimited by whitespace (which doesn't count) seems pretty intuitive to me. 19:36
TimToady I'd also note that the initial whitespaces in *any* alternation should probably be ignored, to keep LTM sane 19:36
I think std and niecza do this implicitly without telling anyone in any case
when you write a rule { stuff [ a | b | c ] } it really turns into rule { stuff [a |b |c ] } 19:38
it might only do that if there's ws outside the []; don't recall offhand
so perhaps the actual rule we should advertize is that sigspace will be ignored anywhere something can be used as an alternative under LTM 19:39
TimToady and since any token or rule could in theory be used in such an alternation, initial sigspace there is ignored 19:39
clsn Can you use an unspace inside a rule, btw? I tried putting a backslash after the :s and it didn't work. (putting the :s after the first element did) 19:40
TimToady there is potentially some ambiguity there, so may be outlawed unspace where it looks like a quoted space 19:41
std: / foo\ bar /
p6eval std be1f10e: OUTPUT«===SORRY!===␤No unspace allowed in regex; if you meant to match the literal character, please enclose in single quotes (' ') or use a backslashed form like \x20 at /tmp/Yg2saDkZHQ line 1:␤------> / foo\⏏ bar /␤Parse failed␤FAILED …
TimToady heh, doesn't say what to do if you wanted unspace
so nevermind about that suggestion; I'm just going senile (hopefully slowly) 19:42
clsn OK, fair enough. :) 19:42
TimToady well, there's always [:!s ]
std: / foo[:!s ]bar / 19:43
p6eval std be1f10e: OUTPUT«ok 00:01 120m␤»
TimToady std: / foo#`( )bar /
p6eval std be1f10e: OUTPUT«ok 00:01 120m␤»
TimToady there's embedded comments too
clsn Turns out that in the original case I was working with, I actually had /:sigspace ^.../, i.e. search anchored at the head of the string, which natually would always fail when that first space is counted!
TimToady yes, another argument for ignoring initial ws 19:43
TimToady I think I'll spec it that way and see who panics this tie 19:44
diakopter pmurias: hi 19:45
clsn ok. 19:46
clsn nom: "e u a u e u a" ~~ /:sigspace^.*?("a") ([<[aeiou]> ]+)$/ 19:49
p6eval nom ef4702: ( no output )
clsn nom: say ("e u a u e u a" ~~ /:sigspace^.*?("a") ([<[aeiou]> ]+)$/)
p6eval nom ef4702: OUTPUT«=> <e u a u e u a>␤ 0 => <a>␤ 1 => <u e u a>␤␤»
clsn nom: say ("e u a u e u a" ~~ /:sigspace^(.*?)("a") ([<[aeiou]> ]+)$/)
p6eval nom ef4702: OUTPUT«#<failed match>␤»
clsn Still a problem that the capture parens make it fail. 19:50
dalek odel: c52987f | diakopter++ | lua/ (3 files):
minor improvements
19:52
clsn Looks like I can do without that capture in my single perl6 program... Now once the recursion thingy is fixed it will work again. 19:55
dalek ecs: d7e1a70 | larry++ | S05-regex.pod:
generalize rule relating sigspace to LTM
19:57
TimToady this spec change means that much of STD is now wrongish :) 19:58
sorear: ^^ 19:59
TimToady tries hard to avoid the "But we already have 11 users" syndrome :) 20:00
TimToady though we should not have much code depending on ws being significant at the front of rules, except maybe the TOP 20:01
where we might need an extra <.ws> to get LTM started up right 20:02
TimToady once we've fixed this, we can then relax our token { :s } instances to mere rules 20:02
dalek kudo/bigint: 3014678 | moritz++ | src/Perl6/Actions.pm:
fix calling of radcalc for radix literals; make them produce the right type, I hope
20:04
dalek odel: 66ccb5f | diakopter++ | lua/compiler/Makefile:
Makefile oopsie
20:13
TimToady oh, and clsn++ for reminding me that I wanted to do that... 20:23
clsn Thanks! 20:24
TimToady we might simplify it further and say that we look for significant whitespace only after an explicit matcher, never after declarations or syntactic functors like brackets 20:30
a quantified atom would count as a matcher for this, presumably 20:32
TimToady this might simplify both the semantics and the teaching 20:33
above I use "declaration" to mean things like :my and :sigspace, not in the declarational sense we use when discussing LTM 20:34
in rule { 'foo' } the 'foo' is declarational but not a declaration :)
sorear but metachar:sym<[ ]> is a quantified atom
so is metachar:p6adv
TimToady true, so just the opening [ is exempt 20:35
as a degenerate case rule {'' ... } would give the current semantics 20:36
I think this simplification can also cut down on some of the <ws> pressure 20:37
and clarify the semantics of ws around ** and % 20:38
that is, we could just make those follow the same rule, and not special-case them
as we don now 20:39
*do
as for p5adv, we'd have to rethink that one, I imagine
a lexical scope might have to eat the initial ones explicitly 20:41
sorear I think we have :my as a quantified atom too
TimToady or normspace eats them
but this seems like a good simplification to me, and worth a little agony 20:42
TimToady maybe it's just a lexer state, and any real matcher enables a 1-shot sigspace 20:46
well, wouldn't be lazy, rather a use-it-or-lose-it 20:47
but maybe that's just syntax
TimToady -> catfood acquisition mode & 20:49
PerlJam That sigspace change seems useful but it also looks like it has a small gotcha: token foo { :s [ foo | bar | baz ] ... } # did the sigspace do its job or get ignored? 21:04
moritz I've been struggling with the Rat codegen for half a day, and giving up now 21:28
there's what seems to be an optimization for Rat in Perl6::SymbolTable.add_constant
removing it causes segfaults
moritz changing it to deal with bigints in any way that I can imagine makes it die with opaque errors 21:29
TimToady PerlJam: only the trailing whitespace would be recognized, so it depends on what you think its job is 21:29
your declaration would be indistinguishable from a rule declaration 21:30
PerlJam TimToady: token blah { ... [:s [ foo | bar | baz ] ] ... } # then. What I'm trying to get at is that sometimes the regex author may need to be explicit about the <.ws> when they're trying to use :s 21:37
(the ellipses are meta in this example :)
TimToady that will ignore whitespace before foo, bar, or baz 21:39
that is, not expect whitespace
use :s '' [ ] to mean the other thing now
dalek odel: 8a63edd | diakopter++ | lua/runtime/ (3 files):
clone fixups
odel: 7ecd0ed | diakopter++ | lua/compiler/Makefile:
Merge branch 'master' of github.com:diakopter/6model
PerlJam ah 21:40
PerlJam Still that's likely to surprise people 21:43
TimToady it 21:49
it's impossible to never surprise people :)
unless maybe when you're dead
and sometimes even then...
I just hope I'm never surprisingly boring :) 21:50
tkr hi. what about PDL for perl6? 23:13
what is it's replacement.
?
TimToady S09, but not implemented yet 23:14
tkr Hm, let me peek.
dukeleto does Rakudo have any plans to implement S09 any time soon? 23:15
TimToady they're working up to it with 6model and native types 23:16
tkr TimToady: Im talking about superfast Linear Algebra libraries 23:17
Ah. Im probably confused in the discussion as I just joined the channel. 23:18
TimToady sorry, on the phone at the moment 23:19
tkr on a wireless phone or normal? 23:20
do you dial the number using your index finger? 23:21
TimToady: np. :) 23:22
dukeleto tkr: you want superfast linear algebra in perl 6? 23:23
tkr dukeleto: well, not that I really need it. I was just curious.
dukeleto: Ive been attending the Machine Learning class online and learnt a lot of linear algebra that used to be "black" magic for me. 23:24
dukeleto tkr: there are some bindings to BLAS from Parrot that you could probably use in Rakudo. I say probably. I don't think anybody has ever tried.
tkr dukeleto: than I was delighted to hear that perl5 can do about the same as Matlab/Octave, when it comes to performance related to number crunching, and I got curious if perl6 had something cool that I wasnt aware of yet. :)
dukeleto: ok. 23:25
dukeleto tkr: perl5/matlab/octave are all basically C, so yeah, *roughly* the same performance, but different memory overheads 23:26
tkr: nobody can number crunch like Fortran, still.
really, all we need is for ingy to port Inline::Fortran to Parrot and then Rakudo will get it for free... 23:27
what could go wrong?