»ö« 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.
00:01 fgomez left 00:02 fgomez joined
dalek ast: e2fb70e | pmichaud++ | S32-str/sprintf.t:
[sprintf] Correct tests for %g, fudge %F for Rakudo (NYI).
 00:11
colomon pmichaud++ # I believe the %g tests are indeed now correct, but I completely fail to understand why the C/Perl5/Perl6 specs work that way for %g 00:16
pmichaud the important thing is the number of significant digits
i.e., %5.2g means output a number with two significant digits
colomon but why doesn't that also apply to %e
?
pmichaud %e is the number of digits following the decimal point, iirc.
colomon or %f, for that matter?
pmichaud because with %e, we always know there's one digit before the decimal point. 00:17
00:17 Entonian left
pmichaud I think %g came much later from %e and %f 00:17
originally %f was designed to say "in this many characters, with this number of digits after the decimal point". Thus it gets trailing zeroes.
But there wasn't a way to say "this many significant digits" -- that's the slot that %g files 00:18
*fills
colomon rn: say sprintf("%5.2g", 31415345)
p6eval niecza v19-9-g4b9c017: OUTPUT«3.14e+007␤»
..rakudo 6ec88f: OUTPUT«3.1e+07␤»
colomon rn: say sprintf("%5.2g", 31415) 00:19
p6eval niecza v19-9-g4b9c017: OUTPUT«31415.00␤»
..rakudo 6ec88f: OUTPUT«3.1e+04␤»
colomon rn: say sprintf("%5.2g", 3141)
p6eval niecza v19-9-g4b9c017: OUTPUT«3141.00␤»
..rakudo 6ec88f: OUTPUT«3.1e+03␤»
colomon rn: say sprintf("%5.2g", 31)
p6eval rakudo 6ec88f: OUTPUT« 31␤»
..niecza v19-9-g4b9c017: OUTPUT«31.00␤»
colomon rn: say sprintf("%5.2g", 310)
p6eval niecza v19-9-g4b9c017: OUTPUT«310.00␤»
..rakudo 6ec88f: OUTPUT«3.1e+02␤»
colomon rn: say sprintf("%5.2g", 311)
p6eval niecza v19-9-g4b9c017: OUTPUT«311.00␤»
..rakudo 6ec88f: OUTPUT«3.1e+02␤»
pmichaud the "precision" modifier means different things to different conversions. 00:20
colomon yeah
does it always default to 6 if not present? 00:21
rn: say sprintf("%g", 31415)
p6eval rakudo 6ec88f, niecza v19-9-g4b9c017: OUTPUT«31415␤»
colomon rn: say sprintf("%g", 314155)
pmichaud it depends on the conversion.
p6eval niecza v19-9-g4b9c017: OUTPUT«3e+005␤»
..rakudo 6ec88f: OUTPUT«314155␤»
colomon rn: say sprintf("%g", 3141554)
p6eval rakudo 6ec88f: OUTPUT«3.14155e+06␤»
..niecza v19-9-g4b9c017: OUTPUT«3e+006␤»
pmichaud for e, f, and g, it's 6, yes. 00:22
colomon great
pmichaud for d, i, o, u, x, and X, it's 1
(at least according to C)
I'm being called afk -- bbl 00:24
00:24 atrodo left 00:31 tokuhiro_ joined
dalek ecza: 7559ad4 | (Solomon Foster)++ | lib/Printf.cs:
Get %g format closer to correct.
 00:39
colomon pmichaud++ 00:48
nr: say 1.exp 00:58
p6eval rakudo 6ec88f: OUTPUT«2.71828182845905␤»
..niecza v19-9-g4b9c017: OUTPUT«2.7182818284590451␤»
00:58 fgomez left 01:03 scott__ joined
dalek ast: 8bbf6aa | (Solomon Foster)++ | S32-str/sprintf.t:
Add tests for default precision in floating point formats.
 01:04
ecza: 9c29580 | (Solomon Foster)++ | lib/Printf.cs:
Get correct default precision of 6 for the sprintf floating point formats.
 01:05
sisar the f in sprintf means 'formatted'? What does the 's' stand for ? 01:06
'special' ?
flussence hungarian notation
sisar flussence: really? or are you kidding? /me is bad at detecting sarcasm sometimes :-) 01:07
s/sarcasm/puns
flussence I really don't know, but it sounds possible 01:08
colomon string
sisar oh, ok.
colomon it's like printf, but it prints to a string. sprintf 01:09
sisar colomon: ah. hmm, printf doesn't print to a string ? What does it print "to" ? 01:10
colomon stdio
sisar oh
colomon fprintf prints to a file. sprintf prints to a string. it all makes a certain Unix-y sense
sisar colomon++
aha, en.cppreference.com/w/c/io/fprintf explains it all. 01:13
btw, perl6 documentation like ^ would be nice and easy to read. Just saying. 01:14
01:15 Guest59503 left
colomon does throws_like count as two tests? 01:39
apparently yes 01:44
dalek ast: 1a4be3d | (Solomon Foster)++ | S32-num/rand.t:
Fudge for niecza.
 01:51
colomon rn: say "\t".perl 01:58
p6eval rakudo 6ec88f, niecza v19-10-g7559ad4: OUTPUT«"\t"␤»
colomon rn: say "\0".perl
p6eval rakudo 6ec88f: OUTPUT«"\x[0]"␤»
..niecza v19-10-g7559ad4: OUTPUT«"\x[]"␤»
01:59 sisar left
colomon rn: say "\0".perl.eval.perl 02:00
p6eval rakudo 6ec88f: OUTPUT«"\x[0]"␤»
..niecza v19-10-g7559ad4: OUTPUT«Unhandled exception: Unrecognized backslash sequence: '\x'␤ at /home/p6eval/niecza/boot/lib/CORE.setting line 1402 (die @ 5) ␤ at /home/p6eval/niecza/src/STD.pm6 line 5628 (STD.sorry @ 7) ␤ at /home/p6eval/niecza/src/STD.pm6 line 4254 (qq.backslash:misc…
colomon rm: say sprintf("%c", 1101).perl 02:02
rn: say sprintf("%c", 1101).perl
p6eval rakudo 6ec88f, niecza v19-11-g9c29580: OUTPUT«"э"␤»
colomon rn: say sprintf("%c", 1).perl
p6eval rakudo 6ec88f, niecza v19-11-g9c29580: OUTPUT«"\x[1]"␤»
colomon rn: say sprintf("%c", 2).perl
p6eval rakudo 6ec88f, niecza v19-11-g9c29580: OUTPUT«"\x[2]"␤»
colomon oh, I think I introduced that bug! 02:04
dalek ast: 235d9e1 | (Solomon Foster)++ | S32-str/sprintf.t:
Add simple %x test that would have prevented my last nieczabug.
 02:12
ecza: f36d743 | (Solomon Foster)++ | lib/Printf.cs:
Don't delete the leading zero in a hex number if the hex number is just 0.
02:14 fgomez joined 02:16 FireFly joined 02:30 tokuhiro_ left, tokuhiro_ joined 02:35 tokuhiro_ left 03:01 cognominal_ joined 03:04 cognominal left 03:42 Khisanth left, Khisanth joined 03:47 sudokode left 03:51 thou joined 04:30 am0c_ joined 04:31 telex left 04:34 cognominal__ joined 04:35 sudokode joined 04:36 cognominal__ left, cognominal__ joined 04:37 cognominal_ left, telex joined 04:42 telex left 04:45 telex joined 04:53 telex left 04:58 kaleem joined 05:01 sudokode left 05:04 telex joined 05:08 birdwindupbird joined 05:10 gardnan joined 05:13 kaleem left
gardnan are there any other perl6 implementations other than rakudo, pugs, or niecza? 05:14
sorear those are the most complete ones. 05:20
there are others, like yapsi, perlito, mildew/smop 05:21
gardnan thanks
05:36 fhelmberger joined
moritz \o 05:43
05:43 kaare_ joined
sorear o/ moritz 05:44
colomon: which libraries were you having trouble with? 05:45
05:49 GlitchMr joined 05:58 gardnan left 06:03 kaleem joined 06:05 kaleem left 06:06 sisar joined 06:08 _jaldhar joined 06:12 seldon joined 06:15 kaleem joined
dalek c: b63269b | moritz++ | lib/Signature.pod:
[Signature] talk about where-blocks; add some sub-headings
 06:22
06:31 stephenlb left 06:32 sudokode joined
dalek c: 7f16b18 | moritz++ | lib/Signature.pod:
[Signature] explain passing of positional and named arguments; parameter aliasing and renaming
 06:36
moritz nr: sub should-fail($x is rw) { }; should-fail 5 06:41
p6eval niecza v19-12-gf36d743: OUTPUT«Potential difficulties:␤ $x is declared but not used at /tmp/lw8rGqikB9 line 1:␤------> sub should-fail(⏏$x is rw) { }; should-fail 5␤␤Unhandled exception: Binding '$x' in 'should-fail', cannot bind read-only value to is rw parameter␤ …
..rakudo 6ec88f: ( no output )
moritz niecza++
06:49 dayangkun joined 06:54 Gesh joined 07:04 bruges left 07:05 brrt joined 07:10 thou left 07:17 araujo joined 07:19 fridim_ left 07:21 PZt left 07:26 kresike joined
kresike good morning all you happy perl6 people 07:27
07:30 fridim_ joined
felher o/ 07:31
kresike felher, o/ 07:32
07:33 araujo left 07:34 araujo joined
felher oh, nice. [&func] got into spec some days ago. awesome :) 07:34
and we have spurt now <3 07:35
moritz now somebody just need to implement and test it 07:41
sorear niecza already has spurt 07:44
arnsholt spurt?
moritz spew, spit, writeall... opposite of slurp :-)
sorear niecza has had spurt since back when I thought it was spelled spew
arnsholt Right 07:45
felher I like spurt. I sounds a bit like slurp. :) 07:47
07:50 dayangkun left
moritz but I disagree with the current spec 07:50
it says it fail()s if the file already exists 07:51
which is totally inconsistent with open()
and one can :append, but there's no way to overwrite the file
sorear: does niecza do it the same way?
I mean, as now specced?
sorear I didn't actually read the spec 07:53
moritz :-)
sorear I didn't make it quite that insane, anyway :D
jnthn morning o/ 07:56
moritz \o jnthn
felher o/ 07:57
07:58 seldon left
sorear o/ jnthn 07:59
masak morning, World. (and Grammar and Actions, too.) 08:04
moritz \o masak
masak moritz: :overwrite should be easy to add. 08:05
moritz: in what way is fail()ing inconsistent with open? ooc.
moritz masak: open() simply overwrites existing files 08:06
much like the system call
felher o/ masak
sorear o/ masak
masak moritz: oh, you'd prefer that to be the default? hm. 08:08
moritz masak: yes 08:09
masak I can see the case for that.
moritz masak: also because not overwriting requires non-atomic operations
(existence check followed by open)
masak would you like to have an option, something like the opposite of :overwrite, to make it fail() if the file exists?
08:09 kaare_ left
moritz I personally don't need such an option 08:10
masak ok.
moritz but I'd prefer it to what is specced now
masak :)
moritz :preserve maybe?
or :createonly
masak :new :) 08:11
moritz :youthinkthisiscutetoday :-)
sorear moritz: O_CREAT|O_EXCL 08:12
masak well, :new tells you exactly the inmportant bit that's going on. it's a new file.
it's not an old file, which is getting replaced. it's a new one, written now.
moritz masak: yes, :new is good 08:13
masak \o/
masak changes the spec
dalek ecs: 4137ad6 | masak++ | S32-setting-library/IO.pod:
[S32/IO] spurt now overwrites by default

It fails on existing files only if you pass it the new `:new` option.		 08:17
masak agreed, the en.cppreference.com/w/c/io/fprintf documentation is seriously nice and clean. 08:21
dalek kudo/nom: 737fb0f | moritz++ | src/core/IO.pm:
[IO.open] make the $path optional
 08:25
kudo/nom: b1aa031 | moritz++ | src/core/IO.pm:
[IO] implement sub form of spurt
moritz so, what should happen if .spurt on a file handle that has been opened for reading? fail()? 08:26
masak what happens if you do it with open()? 08:27
sorear .spurt doesn't make any sense on file handles
only paths
moritz hm, right 08:28
so IO::Path should have one
but not IO
masak +1
moritz oh, and did I mention that I want to rename IO to IO::Handle?
sorear +\infty
moritz it means well have to change the $str.IO ~~ :e pattern 08:29
I'd like to change it to $str.path.e
oh, and I want to create long names too 08:30
.exists in addition to .e
masak yes, please rename IO to IO::Handle. 08:35
masak commutes
08:36 sergot joined
sergot morning o/ 08:36
felher o/ 08:37
Timbus <moritz> I'd like to change it to $str.path.e
yessss
yes this is a good thing
08:38 am0c_ left
moritz seems I'm The Big IO Changer these days 08:39
Timbus some have greatness piped into them 08:40
moritz doesn't 08:44
08:51 baest joined, PZt joined
tadzik home! \o/ 08:57
09:00 adu left 09:02 am0c_ joined
sisar I was writing some C++ right now, and I realized, I seriously hate coming with new names for variables, classes, objects, struct definitions, struct instantiations, enums, enum keys, and whatnot. 09:09
sisar sucks at coming up with new names
tadzik start naming them after animals 09:10
or star wars characters :)
sisar for example, if I want to return more than one value from a function, I use a structure, and then I need to comeup with three new names :( One for the struct definition, one in the caller, one in the returning function. Phew. 09:11
tadzik: :-) I would like that, but I'm not the only one who will read/use this code. 09:12
so I need to come up with "meaningful" and "descriptive" names. :/ 09:13
tadzik :) 09:14
sisar hehe, found this "advice": "A simple manner in which to return multiple values is to return them as a concatenated string, and parse them when they are returned. " :D 09:16
09:16 baest_ joined
moritz well, if you happen to program in TCL... :-) 09:16
sorear sisar: std::pair 09:17
09:17 baest left
sisar moritz: sorry, what about TCL ? I'm not familiar with TCL syntax/stly of programming. 09:17
sorear sleep&
sisar sorear: wow, std::pair looks usable in my case ! 09:18
sorear: thanks ! and good nigth :-)
Timbus sisar, TCL is a string based language 09:21
you could almost call it truly homoiconic
but not really
sisar Timbus: oh. So how al numeric values are considered strings ? Then what happens to arithmetic ? 09:22
all*
tadzik String Typing
I guess they're converted, like in Perl 09:23
moritz arithemtics convert to number and then back to string again
tadzik r: my $a = "5"; my $b = "7"; say $a + $b
p6eval rakudo b1aa03: OUTPUT«12␤»
sisar moritz++, tadzik++, Timbus++: thanks for explaining. 09:24
Timbus s'alright
09:25 fridim_ left
kresike sisar, consider it a great opportunity for obfuscating your code :) 09:27
sisar, that was for the var names from backlog
sisar kresike: yes it is an opputunity, provided that I myself don't get lost in the code :-) 09:28
09:29 baest_ is now known as baest
kresike by the time you get lost, you probably have to rewrite it anyway ... 09:30
09:32 am0c_ left 09:41 fgomez left
dalek kudo/nom: 501e8a2 | moritz++ | src/core/IO.pm:
[IO] Add :new flag to &spurt
 09:51
09:55 Gesh left
dalek ecs/io-refactor: fb68e55 | moritz++ | S (2 files):
[IO] start IO refactoring with an overview over the new design

The rest of S32::IO still reeks of over-engineering		 10:02
ecs/io-refactor: 1aa555e | moritz++ | S32-setting-library/IO.pod:
bring some sanity to IO::Handle
moritz IO refactoring TODO: describe IO::Path, IO::FileTests 10:05
move everything into the correlection
delete all the crap about IO::Readable, IO::Writable etc. 10:06
10:08 scott__ left
moritz move all the sections about OS specific roles and all the handwavy stuff to a "future ideas, but not yet spec" section 10:08
masak is this the first time we've had a branch in the 'specs' repository?
moritz it might be 10:09
masak I think it is. 10:11
felher moritz: if you have a bit of spare time: gist.github.com/3059358 and tell me what you think. I'm sorry it took me so long. I just forgot about it over some exam and $job stuff :/ 10:16
If a nonzero imaginary part is the only way such a coercion can fail, the $.reason attribute should probably get removed :)
moritz other non-real classes might have their own reasons 10:17
I think it looks good, at first glance
will try to get more than a glance on it later (or over the weekend) 10:18
felher++
felher moritz: okay. btw: I spectested it, and didn't introduce more failures. There were a bunch of old failures, though :) 10:20
+it 10:21
masak lunch &
10:22 Patterner left
felher i added the log to the gist 10:22
lunch &
10:25 Psyche^ joined, Psyche^ is now known as Patterner
dalek ecs/io-refactor: c2eea90 | moritz++ | S32-setting-library/IO.pod:
move &slurp and &spurt to functions; move file tests to IO::FileTests
 10:25
hoelzro I've been reading the regex and grammar parts of the Perl6 book, and I noticed the :ratchet feature. This is probably a stupid question, but why would you want to disable backtracking? 10:47
jnthn When you're parsing some kind of programming language or many other things, you generally don't want backtracking. It means you save a lot of state which slows the parse, but also means that something that should fail immediately can take a long time to fail as it attempts to backtrack. 10:49
hoelzro jnthn: so is it only for efficiency reasons? 10:53
jnthn It matters for efficiency, but it's semantic too...often you want to commit at certain points. Not doing so may get you a different outcome. It'd likely also harm error reporting quite a bit. 10:54
hoelzro hmm 10:56
could you give me a concrete example?
bbkr hoelzro: for example you want to parse some template language with syntax "abc{tag}some text{tag}". you should disable backtracking after parsing text, otherwise broken syntax "abc{tag}some text{tag" will try to backtrack "some text" because it cannot match {tag} properly. not what you want - code was valid up to point of "some text". 10:59
11:00 spider-mario joined
hoelzro oh, I think I get it 11:02
I think I just need more experience with more complex grammars
11:05 brrt left
bbkr hoelzro: if you like p6 grammars but you still need to use p5 - there is search.cpan.org/~dconway/Regexp-Gra...rammars.pm that offers a lot of syntax backported from Perl6 11:07
11:08 spider-mario_ joined, spider-mario_ left
hoelzro bbkr: I've tried using Regexp::Grammars in the past; it's quite nice 11:11
but I still have a lot to learn about grammars =)
colomon phenny: tell sorear I haven't gotten gtk# or glib# to work since I installed the mac os x build of mono from the mono website. not even when I tried uninstalling it and installing from macports.... 11:12
phenny colomon: I'll pass that on when sorear is around.
11:14 fhelmberger left
arnsholt Oooh, the Rakduo build with --stagestats is pretty nice 11:27
jnthn: *prod*? 11:29
11:33 DarthGandalf joined
jnthn arnsholt: ohhai 11:34
arnsholt After something of a hiatus, I'm trying to get back to Zavolaj hacking 11:36
I'm looking at CStruct and thinking I can ditch the STRING array for embedded strings 11:37
11:37 pyrimidine left
arnsholt I think CArray did something similar that I killed after adding support for pointer-based objects 11:38
Sound reasonable?
jnthn arnsholt: I guess we just create a new STRING * each time we're asked for the value? 11:39
arnsholt CArray only creates/gets a STRING * when the value is bound, actually 11:41
masak sorear: do you have anything to say about Curry's paradox? I'm surprised the Wikipedia page on it says that it's basically still unresolved, or that there is at least no consensus view of a resolution.
moritz r: say foo; say $*OUT.outs
p6eval rakudo 501e8a: OUTPUT«===SORRY!===␤CHECK FAILED:␤Undefined routine '&foo' called (line 1)␤»
moritz r: say 42; say $*OUT.outs
p6eval rakudo 501e8a: OUTPUT«42␤No such method 'outs' for invocant of type 'IO'␤ in block <anon> at /tmp/AROGWNqZkn:1␤␤»
felher moritz: just wanted to say that i updated some stuff in the gist. Just to make sure that you reload it when you look at it :) 11:42
moritz felher: will do
11:44 GlitchMr42 joined
masak arnsholt++ # zavolaj hacking 11:45
11:45 GlitchMr left
jnthn arnsholt: OK, then it sounds reasonable. 11:47
11:53 pyrimidine joined 11:55 kaare_ joined 11:58 cognominal__ left, cognominal joined 12:03 skids left 12:05 _jaldhar left
masak spec inconsistency found: danger, danger, Will Robinson. 12:08
moritz the more I think about it, the less sense the distinction between IO::Path, IO::File and IO::Dir makes
masak all(S02, S05, S29) meantion &ucfirst as if it still exists. S32/Str mentions (under &titlecase) that it's now un-spec'd because it is not useful under Unicode. 12:09
rn: say ucfirst "aie!"
p6eval rakudo 501e8a, niecza v19-12-gf36d743: OUTPUT«Aie!␤»
masak submits rakudobug
masak submits nieczaissue
moritz I think I'll just unify them back into IO::Path, and have unsupported methods (like .open on a directory) fail
masak: S32 is the newer one 12:10
masak yes.
that said, I think &titlecase is a poor substitute for &ucfirst, and I don't understand what's so useless about &ucfirst.
but the spec specs and I oblige.
moritz but I don't buy the "not useful under Unicode semantics" either
masak :)
moritz there are still many, many cases where even an ASCII-Only ucfirst can be useful
masak yes! 12:11
moritz even if it's just for compatibility with all the other "legacy" systems out there :-)
jnthn This feels like a pragmatism fail at first glance. :/
masak yes.
moritz hopes we can change TimToady's mind
masak but I'm still submitting that rakudobug, because that's what the spec says right now.
moritz please also submit a specbug 12:12
masak ok.
submitting bugs, now that I can do ;)
dalek ecs/io-refactor: 8082097 | moritz++ | S32-setting-library/IO.pod:
document IO::Path; move more stuff around
moritz 1 files changed, 211 insertions(+), 309 deletions(-)
looks like the right direction :-)
masak \o/ 12:13
12:16 trist4n joined
masak rakudobug, nieczabug, and specbug submitted. all is well in the world. 12:21
moritz now fix 'em all :-)
masak I'd love to, but we have a strong TimToady dependency on the whole dependency tree of this issue. 12:23
he was the one deprecated ucfirst, he should have a say in defending that decision.
masak has gotten in to the habit of deliberately dropping relative 'who' in sentences, and doesn't know why 12:24
rn: say titlecase "aie!" 12:25
p6eval rakudo 501e8a: OUTPUT«===SORRY!===␤CHECK FAILED:␤Undefined routine '&titlecase' called (line 1)␤»
..niecza v19-12-gf36d743: OUTPUT«===SORRY!===␤␤Undeclared routine:␤ 'titlecase' used at line 1␤␤Unhandled exception: Check failed␤␤ at /home/p6eval/niecza/boot/lib/CORE.setting line 1402 (die @ 5) ␤ at /home/p6eval/niecza/src/STD.pm6 line 1147 (P6.comp_unit @ 37) ␤ at…
masak rn: say "aie!".titlecase
p6eval niecza v19-12-gf36d743: OUTPUT«Unhandled exception: Unable to resolve method titlecase in type Str␤ at /tmp/dF3EoDVTkl line 1 (mainline @ 3) ␤ at /home/p6eval/niecza/lib/CORE.setting line 3918 (ANON @ 3) ␤ at /home/p6eval/niecza/lib/CORE.setting line 3919 (module-CORE @ 562) ␤ at /h…
..rakudo 501e8a: OUTPUT«No such method 'titlecase' for invocant of type 'Str'␤ in block <anon> at /tmp/xeK3BTNWDI:1␤␤»
dalek ecs/io-refactor: ce9cbc7 | moritz++ | S32-setting-library/IO.pod:
chdir, get, lines

also remove more crazy stuff, and warn about the unreviewd stuff
12:25 cognominal left
masak mark one up for the argument "if we rescue ucfirst now and try to forget about titlecase, no ecosystem code will break" :) 12:25
12:26 cognominal joined
masak I don't get it. ucfirst seems to me to be the more fundamental operation. you can build titlecase from ucfirst, basically with .words>>.ucfirst.join 12:26
colomon TimToadynote that $s.lc.ucfirst is not capable of capitalizing correctly, since lc loses info needed to choose appropriate titlecase 12:27
17:41and lcfirst was always rather useless
irclog.perlgeek.de/perl6/2011-11-07#i_4673465
masak going the other way, hm, you'd have to extract the first word, titlecase it, and put it back.
colomon: thank you. colomon++
moritz masak: well, titlecase is more than just... what colomon pasted
masak ok, s titlecase has merit. but that doesn't mean ucfirst doesn't.
so* 12:28
moritz right
masak I agree lcfirst doesn't have much reason to exist. 12:29
nO-ONE wRITES lIKE tHIS.
um, hm. that would be untitlecase, I guess :P
moritz titleuncase :-) 12:31
masak .oO( as a biologist, I read that as an enzyme that can splice titleunc ) :P 12:32
colomon the screen starting at irclog.perlgeek.de/perl6/2011-11-07#i_4674253 seems to give the most useful explanation. 12:33
crazily enough, the example implementation of titlecase depends on ucfirst.
masak ahahaha. *sob*
colomon: I remember saying that "aha." back to TimToady and actually not following along *at all*. :/ 12:35
colomon Here's what I'm picking up from this:
the concepts uppercase and titlecase are distinct entities in Unicode 12:36
masak I don't see why we call one 'uc' and another 'titlecase'.
colomon uc translates to all uppercase 12:37
ucfirst translates the first character to titlecase
masak I know we're all very into discontinuities for fun language design reasons, but... 'tc' would be more consistent with 'uc' and 'lc' and I don't see the argument for making the name distinct.
also, 'tc' is strangely consistent with 'tchrist' :P 12:38
moritz but, what I want to conver to upper (and not title) case?
*what if
colomon you use uc
12:44 JimmyZ joined
colomon I think I see what TimToady was getting at. srfi.schemers.org/srfi-13/mail-arch...00046.html contains an interesting old (non-Perl) discussion on the subject. 12:48
it seems like maybe what we really want is to have lc, uc, tc, and tcfirst? 12:49
masak \o/ 12:50
on the face of it, that sounds very nice.
so tcfirst would replace ucfirst and make sense under Unicode?
and then the rest is just retraining all the programmers, and we're done? :)
arnsholt It never ceases to amaze me how many bone-headed mistakes I make while writing tests 12:51
masak .oO( tcfirst is what happens when Tom Christiansen's reply ends up as the first reply on Stackoverflow and ownz everyone else... )
colomon well, the interesting question is: does tcfirst titlecase the first letter and then lowercase the rest? Or does it simply titlecase the first letter?
masak arnsholt: it's a very humbling experience, yes.
colomon: I... don't know. 12:52
colomon because $str.lc.tcfirst wouldn't work
masak why not? I haven't read the email thread yet.
maybe we want to list three-ish use cases and make sure our primitives cover them adequately. 12:53
colomon I haven't seen it in the e-mail thread yet, but that's what TimToady was talking about... you cannot necessary convert a character to lowercase and then properly titlecase it.
n: say "\x[1f3] \x[1f1] \x[1f2]" 12:56
p6eval niecza v19-12-gf36d743: OUTPUT«dz DZ Dz␤»
masak are you aware of any exam... is that an example?
colomon no
masak are you aware of any example?
colomon I'm not aware of an example, but I assume TimToady knows what he is talking about.
masak I feel I need concretitude. 12:57
colomon (That was an example of uppercase being different than titlecase.)
masak .oO( I'm Concrete Man! I explain jokes! Get it? )
12:57 cognominal_ joined
masak only funny in Polish, apparently... 12:57
12:57 cognominal left 13:03 atrodo joined
colomon is furiously researching... 13:04
tadzik :) 13:06
13:07 seldon joined
moritz notices that some routines that are documented are missing from doc.perl6.org 13:09
for example lc is there, but uc is missing 13:10
seldon In that particular case, that could be considered a feature. 13:11
moritz no no, uc hasn't been removed :-)
and split is also missing
13:12 awwaiid joined
colomon has been searching for 15 minutes and still doesn't have an example. But he trusts TimToady knows what he is talking about. 13:17
maybe the functions should be lc, uc, tc, and tcfirstlcrest? 13:18
err, probably better as tc-first-lc-rest
moritz .casefold($how)
and how can be 'Tl' for 'title-case first, lower-case everything' or so
probably a stupid idea 13:19
masak feels a little too strange.
colomon 's just searched his own code, and it looks like every time he's ever used ucfirst, tc would be more appropriate. 13:23
(ie I always use ucfirst on words, not on sentences)
moritz r: say Hash ~~ Cool 13:25
p6eval rakudo 501e8a: OUTPUT«True␤»
masak colomon: the thing that made me start talking about this was a similar case. I was doing ucfirst on single words. github.com/masak/crypt/commit/e478...5fd#L0R435 13:27
colomon: in my case I don't have multi-word rooms. if I did, I guess I would want each first letter of each word to be uc'd.
colomon yeah
hmmm... 13:28
rn: say "\x[1f3]is test".ucfirst
p6eval rakudo 501e8a, niecza v19-12-gf36d743: OUTPUT«DZis test␤»
colomon so in fact, neither rakudo nor niecza implement the perl 5 'ucfirst is really tcfirst' 13:29
masak is lost again
I should probably read the right source material to get this discussion.
colomon in (modern?) perl 5, ucfirst converts the first character of the string to titlecase 13:30
not uppercase as the name would seem to imply
JimmyZ rn: use Test; say is.Cool
p6eval rakudo 501e8a: OUTPUT«===SORRY!===␤CHECK FAILED:␤Calling 'is' will never work with no arguments (line 1)␤ Expected any of:␤ :(Mu $got, Mu $expected, $desc = { ... })␤»
..niecza v19-12-gf36d743: OUTPUT«Unhandled exception: No value for parameter 'got' in 'is'␤ at /home/p6eval/niecza/lib/Test.pm6 line 0 (is @ 1) ␤ at /tmp/f0qWJQb859 line 1 (mainline @ 4) ␤ at /home/p6eval/niecza/lib/CORE.setting line 3918 (ANON @ 3) ␤ at /home/p6eval/niecza/lib/CORE.s…
JimmyZ rn: say ord.Cool 13:31
p6eval rakudo 501e8a: OUTPUT«===SORRY!===␤CHECK FAILED:␤Calling 'ord' will never work with no arguments (line 1)␤ Expected: :(Cool $s)␤»
..niecza v19-12-gf36d743: OUTPUT«===SORRY!===␤␤Unsupported use of bare 'ord'; in Perl 6 please use .ord if you meant $_, or use an explicit invocant or argument at /tmp/zdTud40u3o line 1:␤------> say ord⏏.Cool␤␤Unhandled exception: Check failed␤␤ at /…
JimmyZ LTA ?
std: say ord.Cool 13:34
p6eval std fd2647b: OUTPUT«===SORRY!===␤Unsupported use of bare 'ord'; in Perl 6 please use .ord if you meant $_, or use an explicit invocant or argument at /tmp/y0aeIaRTxr line 1:␤------> say ord⏏.Cool␤Check failed␤FAILED 00:00 41m␤»
masak JimmyZ: slightly. feel free to submit rakudobug. 13:36
13:37 skids joined, tyatpi joined 13:38 tokuhiro_ joined 13:40 tokuhiro_ left
JimmyZ submitted 13:41
13:41 sergot left, sergot joined
masak JimmyZ++ 13:41
jnthn Rakudo does pretty well there...it detects the issue at compile time :)
STD hardcodes an error for it in the parser.
Rakudo does almost as well with a purely general mechanism. 13:42
13:42 Moukeddar joined, countley joined
jnthn (Which makes me wonder if we can do some more general improvement. :)) 13:43
13:43 Moukeddar left 13:44 bluescreen10 joined
dalek c: 878b8be | moritz++ | htmlify.pl:
[htmilfy] debug mode, pod pretty printer
 13:46
moritz gist.github.com/306024 13:53
(via twitter)
JimmyZ it's deleted 13:54
moritz sorry, cut the URL 13:55
gist.github.com/3060244
smash a long long time ago, in a yapc far far away, we register the perl6doc.org domain, currently it's redirecting to perl6.org/documentation but if anyone wants to use it for something please let me know
moritz smash: well, you could redirect it to doc.perl6.org 13:57
smash moritz: fair enough
moritz: done 13:58
moritz smash++
13:58 mucker joined
moritz smash: if I come up with a better use case, I'll tell you 13:58
smash moritz: sure 13:59
[Coke] Regarding Tcl conversation earlier - I'm pretty sure current versions of Tcl have multiple slots on their variables, ala perl, and once you've done the conversion, it's not really just "a string" at that point. 14:00
moritz [Coke]: right, I was more talking about the user-facing behavior 14:01
14:03 tokuhiro_ joined
[Coke] ah, yes, to the user, all scalars are the same time. 14:05
*type
dalek c: fe4e68d | moritz++ | htmlify.pl:
[htmlify] fix a pod dissection bug

previously some routines (like uc, split) were not showing up in the index, and no per-routine documentation was generated for them
[Coke] associative arrays are the only special type.
moritz just like you don't often see the dualvar nature of p5 scalars
ttfn, decommute&
14:10 Slacky joined 14:11 countley left
pmichaud good morning, #perl6 14:11
smash pmichaud: mornin' 14:12
masak pmichaud! \o/ 14:13
colomon \o 14:14
pmichaud ...why doesn't .spurt make sense on a filehandle, ooc?
pmichaud reads backscroll 14:16
14:16 countley joined 14:21 PacoAir joined 14:22 adu joined
pmichaud ":new" as a flag name bugs me a bit for some reasons; probably too close to ".new" 14:23
I might prefer :!overwrite
or :!replace
flussence :clobber
pmichaud or yes, :!clobber 14:24
...and perhaps there should be an equivalent flag to open
14:26 countley left
[Coke] :!smash! 14:27
14:28 GlitchMr42 left
masak :!clobber has the "flags shouldn't be True by default" design smell. 14:28
as do *all* the other proposed replacements. :)
timotimo :careful
masak :timid
pmichaud by that reasoning, spurt shouldn't clobber by default, then. It's the most dangerous.
masak pmichaud: that's why I had it spec'd the way it was before the change today. 14:29
g'ah, you can't please everyone! :P
pmichaud to me there's also a design smell of having a flagname that indicates a negative condition instead of a positive one. 14:30
hoelzro is there a way to evaluate a Perl5 regex in Perl6?
short of shelling out to Perl 5? =)
pmichaud hoelzro: not currently implemented in rakudo
hoelzro: but see the :Perl5 modifier in S05
14:30 GlitchMr joined
pmichaud (I can't say "not yet implemented" because that flag _was_ once implemented in an earlier version of Rakudo :) 14:31
masak :)
NCI
hoelzro pmichaud: ah, thank you!
pmichaud masak: what about :noclobber then? 14:32
it would also match the shell flag of the same name and purpose
14:32 PacoAir left
jnthn :createonly 14:32
pmichaud :createonly works for me too
masak feel free to change it.
pmichaud how snarky do I get to be in responding to RT #114012 (ucfirst)? 14:33
14:33 PacoAir joined
masak I guess the closeness between :new and .new was why moritz++ said "cute today". I saw it too, but it didn't bother me so much. 14:33
14:33 PacoAir left
masak pmichaud: you can apply any amount of snark, I probably deserve it one way or another :P 14:33
pmichaud masak: :-) 14:34
14:34 PacoAir joined
pmichaud if I do snark there, it's meant only as humor. :-P 14:34
masak sure, sure!
:P
masak is curious about what kind of snark makes pmichaud predeclare it before delivering it :) 14:35
pmichaud masak: you'll just have to wait and see... :-P
right now I'm spectesting the deprecated ucfirst and lcfirst
[Coke] pugs: say "this and that" ~~ /n.*t/:Perl5 14:36
p6eval pugs: OUTPUT«pugs: Named argument found where no matched parameter expected: (Perl5,Val (VBool True))␤»
pmichaud really likes the "is DEPRECATED" trait
14:36 thelazydeveloper joined
timotimo can you deprecate DEPRECATED? 14:37
pmichaud timotimo: of course! Someday I hope it won't be all-caps.
at that point DEPRECATED will be deprecated in favor of "deprecated"
timotimo :D
14:37 sergot left
timotimo role DEPRECATED is deprecated { ... } :) 14:37
14:37 sergot joined
seldon Five years later: role deprecated is obsolete { } 14:39
[Coke] keyword role is no longer hoopy;
colomon errr.... Rakudo has trait_mod:<is>(Routine:D $r, :$DEPRECATED!) but it doesn't actually do anything yet? 14:40
masak do anything? does it need to do anything? 14:41
pmichaud colomon: it doesn't do anything yet (more)
masak something is deprecated, that doesn't mean it has some behavior or other.
colomon masak: isn't it supposed to warn if you use it?
pmichaud I speculate we could have a dynamic variable that causes DEPRECATED-flagged routines to throw warnings or die if used.
[Coke] it should, eventually.
in java, you can optionally get/disable the deprecated warnings from the command line. 14:42
masak colomon: it could. I don't see how it must do that.
"deprecated" feels more like a community annotation to me.
pmichaud for now I just wanted to introduce the meme, and also because it makes it very nice to mark the DEPRECATED functions in the source
[Coke] this is mostly helpful in smart IDEs, though.
pmichaud I think tagging the routine itself as DEPRECATED is a lot nicer and more robust than having a # XXX: DEPRECATED comment.
it also means that if you want to find all of the DEPRECATED stuff, you could just change the trait to fail 14:43
or warn
masak ooh 14:44
seldon I think it would be useful to have a command line option for rakudo that causes it to warn when deprecated stuff is used, but I don't think it would be a good idea to warn about it without explicit request.
colomon that makes it sound like it would be a lot easier to implement a version for niecza... silent no-ops I can probably do.
pmichaud seldon: yes, thus "dynamic variable"
seldon: dynamic variables allow one to control deprecation warnings at a scope level. 14:45
14:45 cognominal__ joined
seldon Ah. 14:45
masak is this the "dynamical at parse time equals lexical at runtime" equivalence? 14:46
arnsholt Hmm. Something's weird with my structs
pmichaud my $*DEPRECATION_WARN = 1; ...; { my $*DEPRECATION_WARN = 0; ...; }
deprecation warnings are enabled except within the block
or something like that 14:47
dalek kudo/nom: 5ee1f1e | pmichaud++ | / (2 files):
Deprecate .ucfirst and .lcfirst, per the current synopses (RT #114012).
14:47 cognominal_ left
arnsholt rebuilds stuff with -g 14:48
pmichaud updated RT #114012 :-) 14:54
masak looks, curious 14:56
[Coke] # 07/05/2012 - rakudo++ (22775); niecza (89.98%); pugs (34.02%)
masak pmichaud: oh, that wasn't so bad... :) 14:57
[Coke] niecza is now below 90%. oddly, pugs is creeping back up slowly. must be removal of previously failing tests.
14:58 kaleem left
masak pmichaud: the way this happened was I needed ucfirst in this year's crypt, so I used it. but then I went "wait, wasn't this builtin removed from the spec recently?" and that spun off all the rest that happened on channel. 14:59
pmichaud masak: yes, I know -- TimToady++ also dinged me on using ucfirst in my slides at yapc::na
masak pmichaud: it's not that I want ucfirst to go away or be deprecated. I just want the spec to be sane, and the impls to follow the spec.
pmichaud masak: we're in full agreement.
I just figured this was a good point for a reminder (for others reading) that the spectests have a stronger say in what happens than do the synopses. 15:00
masak wishes TimToady was around so he could ding us using the appropriate frequency
gosh, I hope not :)
it's more of a dynamic interplay between syns, STD, and spectests. 15:01
pmichaud S01 says so. :-)
masak oh, ok.
hold on a minute :P
what do the spectests say about it? :P
pmichaud They agree with that. 15:02
masak how convenient.
pmichaud I agree fully about the dynamic interplay between syns, STD, and spectests. But ultimately spectests controls. 15:03
masak there's something going on there that I can't quite put my finger on. 15:05
you're right in a way.
but it's the same kind of bidirectional interplay that goes on between a design and an implementation in aglie. the design drives the implementation, but the implementation further informs the design. 15:06
pmichaud sure; the P6 implementations definitely affect the synopses and the tests as well.
dalek p: f14191e | (Arne Skjærholt)++ | src/6model/reprs/CStruct. (2 files):
Implement string members in CStruct repr'd classes.
 15:07
masak right; this kind of bidirectional relation exists between a lot of the components.
pmichaud I think the key notion is that it's the test suite that encodes our truest understanding of required Perl 6 semantics. 15:08
masak it feels similar to the bidirection/asymmetric relationship between a model and a view in MVC.
dalek volaj: 484fb91 | (Arne Skjærholt)++ | t/06-struct. (2 files):
Add tests for strings in structs.
masak pmichaud: yeah, basically.
pmichaud: the spec is secondary from that point of view. but information still flows both ways. 15:09
15:09 birdwindupbird left
sergot r: say 3, 6 ... * > 10; 15:11
p6eval rakudo 501e8a: OUTPUT«3 6 9 12␤»
[Coke] pmichaud: If you really feel that way about the spectests, you might want to look at the ones that rakudo isn't running.
I think pugs is running a lot of those that rakudo isn't, and they might be a little... stale.
[Coke] ponders adding a "who's running what" list of spetests to his daily run. 15:12
sergot Hmm.. What should I do if I won't "12"? :)
pmichaud sergot: ...^
r: say 3, 6 ...^ * > 10
p6eval rakudo 501e8a: OUTPUT«3 6 9␤»
sergot pmichaud++, I forgot 15:13
:)
thanks
[Coke] pmichaud: and I of course don't mean you specifically, because I'd rather see you hacking on your grant. ;)
How's that going, btw? ;)
pmichaud [Coke]: actually, pretty well. I did some work on it a couple of weeks ago.... and then we ran into some issues with lists again that need a bit of spec-hammering out before we can determine how they affect the design 15:14
but giving my talks at yapc::na finally gave me a comfortable outline for the synopsis
a report of tests that pugs is running but rakudo isn't could be very useful. 15:15
[Coke] pmichaud: I'll have it in my daily spec gist by monday.
pmichaud [Coke]: that would be.... awesome. 15:16
harmil $/.orig.substr($/.to) … is that the easiest way to get access to "what we're going to match against next" for purposes of producing backtracking errors? 15:17
pmichaud harmil: I don't quite understand the question. 15:18
arnsholt jnthn: Now that structs can have strings, I think the item on top of my wishlist is the annoying containerizing thing
Where did you say I should go looking for hints on how that works again? 15:19
harmil So, I have a rule that matches "x" and then some stuff. But failing matching some stuff, it matches "x" and then calls an error reporting routine. In the error reporting routine, I say, "this next bit is noise, fix it"
pmichaud: that next bit is, as best I can tell, easiest to capture as $/.orig.substr($/.to) but I was wondering if there was a shortcut to that that I'm missing 15:20
pmichaud harmil: $/.postmatch
harmil ahah, thanks!
pmichaud there's also a $/.prematch for everything prior to the match
15:20 birdwindupbird joined
masak weekend & 15:21
[Coke] suggests a format like this for the who's running what:
NPR /path/to/file
with spaces instead of NPR as appropriate.
pmichaud ...actually.... 15:22
I suppose I could run fudge with different options for rakudo, pugs, niecza, and then display the diffs :-)
harmil pmichaud: I see why I missed those. They're in the spec after a separator from from, to, etc., so I just didn't scan down far enough. 15:23
[Coke] are you looking for individual test granularity?
or just file?
not everyone does the "global fudge first" trick.
pmichaud [Coke]: well, file is definitely helpful, but individual test would help me to find tests that pugs is passing that rakudo skips 15:24
[Coke] (not that you couldn't as a standalone.)
pmichaud yes, I'm thinking standalone
[Coke] that assumes that if an implementation runs a test, it passes it.
pmichaud of course, I'd need to know which files pugs is running
if an implementation runs but fails a test, I do expect it to be fudged, yes.
[Coke] pmichaud: all three implementations use the same file to list that. 15:25
pmichaud: even rakudo doesn't do that.
pmichaud [Coke]: it doesn't? Then how do we get "all tests passing"?
[Coke] "rakudo", 22775, 23, 628, 1824, 25250, 24207
I've been failing those 23 tests for months.
you're not. I am.
pmichaud oh, can I get a list? 15:26
is it in the gist?
pmichaud looks
[Coke] one moment.
moritz pmichaud: re spurt on filehandle, becase you can simply .print a string to it
pmichaud moritz: so, .spurt could make sense on a filehandle, but would be redundant with .print ? 15:27
[Coke] it's not in the gist.
latest copies in feather.perl6.nl/~coke/
feather.perl6.nl/~coke/rakudo_summary.out
15:28 alester joined
moritz pmichaud: basically, yes 15:28
pmichaud: and if it also closes the handle (like the sub form does), it might be confusion
*confusing
[Coke] Failure summary at the bottom.
moritz afk again
pmichaud moritz: well, I wouldn't expect it to close the handle. We have a couple of other places in the IO API where methods are just aliases for other ones, iirc. 15:29
synonyms exist. :-)
[Coke]: so, looking at feather.perl6.nl/~coke/rakudo_summary.out, 15 of the failures are in S32-str/sprintf.rakudo ? 15:30
15:33 tokuhiro_ left
colomon pmichaud: only 51 tests, that's the version before you fudged it yesterday. 15:35
right now it has 100+ tests 15:36
pmichaud colomon: I'm just asking if I'm reading the results correctly.
colomon pmichaud: ah
15:36 thou joined
pmichaud I'm trying to figure out how Coke++ could be seeing the failures when our "make spectest" command wasn't. 15:37
15:37 mikemol joined
pmichaud a-ha. Rakudo fails the tests for %F, which weren't added until July 4th. 15:44
so those 15 fails are recent.
[Coke] pmichaud: yes.
well, those 15. but we've had about that many failing tests for months. 15:45
pmichaud [Coke]: when you get a chance, could you send the output of "make t/spec/S06-routine-modifiers/lvalue-subroutines.t" so I can see the errors you're getting.
[Coke] which tests they are come and go.
pmichaud [Coke]: oh, okay. Essentially you're saying that the spectests aren't always perfectly fudged, then?
I'm okay with that.
[Coke] pmichaud: running that by hand in my rakudo checkout dir, no failings. 15:46
pmichaud: well, many of those failures were "oh, we don't fail on our hardware platform, so don't skip those, even though they fail for you."
32 vs 64-bit. 15:47
.. but those tests no longer seem to be failing. 15:48
pmichaud okay, so pugs currently has 2007 fails in its run of the spectests. Yes, I agree the diff will be less useful then. 15:50
[Coke] those are from the *(#$ utf8 handling. 15:56
I can either 1) fudge those tests, or 2) re-enable the locale setting that enabled them to pass.
I am leaning towards 2 as the path of least resistance until we get someone hacking on pugs again. 15:57
pmichaud either works for me :)
kresike bye all
15:57 kresike left
dalek gs.hs: c268bfa | coke++ | / (3 files):
Revert "remove referencess to LC_ALL"

This reverts commit 6272950693a604b1443c28b08870c42a52247879.		 16:00
[Coke] crud. I think I missed today's run by about 20s.
pmichaud [Coke]: no problem.
[Coke]: I can wait until next week; I have other things to work on today anyway :) 16:01
[Coke] eh, just annoyed. ;)
dalek ecs: 70c1b24 | pmichaud++ | S32-setting-library/IO.pod:
[spurt]: s/':new'/':createonly'/ as suggested by jnthn++.
[Coke] so you would like test level granularity on who is running which tests. I lament AGAIN that TAP has no concept of test names.
pmichaud file and test number would be sufficient, although I recognize there would still be some mismatch. 16:02
if switching the LC_ALL flag reduces a significant number of fails in Pugs, then the diff approach becomes more feasible again too
[Coke] it was fully fudged at one point. without that, it's just "tests that are new since <X>" 16:03
pmichaud and since I'm really looking for tests that pugs passes that rakudo does not, that limits it down quite a bit also. I'm not too concerned about tests that rakudo passes and pugs fudges/fails
[Coke] pmichaud: :P 16:04
hater. :)
dalek ast: de9fa2b | pmichaud++ | S (2 files):
Unfudge now-passing file size tests.
[Coke] crud. spec tests runs now are sequential, but pugs goes first, so it's done already. I may redo the run for pugs today to include that commit. 16:07
harmil You know you work in the right place when you routinely find yourself referencing the initialism "REPL" in office conversations... 16:13
16:15 JimmyZ left 16:28 fridim_ joined 16:48 jlaire joined
sorear good * #perl6 16:49
phenny sorear: 11:12Z <colomon> tell sorear I haven't gotten gtk# or glib# to work since I installed the mac os x build of mono from the mono website. not even when I tried uninstalling it and installing from macports....
harmil ick 16:50
phenny: did you try the one from macports?
sjohnson sorear: hi 16:53
[Coke] harmil: phenny is a bot, telling sorear a message from colomon.
harmil oh, right, heh
[Coke] 1 todo: outdated semantics by Christmas -- pugs
harmil So, here's a fun debugging technique: rule term { [ <parentheticial> | <literal> | <variable> ] {debug "term {$/.keys}={$/.Str}"} } 16:54
will print "term literal=5" 16:55
arnsholt harmil: Have you tried Grammar::Debugger and Grammar::Tracer? 16:56
harmil arnsholt: not yet
I've been too busy debugging my grammar ;)
[Coke] ok, with that commit reverted, pugs is down to 453 failures, most of which are due to lack of fudging in the past few months.
arnsholt Do. They're pretty awesome for figuring out what goes wrong in grammars
[Coke] I'll clean that up again this weekend.
harmil I should
[Coke] I know pugs is running fewer tests, but it's sooo much faster than rakudo. ;) 16:57
sorear I do not get github.com/sorear/niecza/issues/133 16:59
17:00 birdwindupbird left
harmil I'm guessing that the concern is that mono dependency is icky? Dunno... 17:00
arnsholt Well, given that Niecza is written in C#, depending on Mono shouldn't be a surprise... 17:01
diakopter except that it builds with .Net too
harmil ah, so is the claim that you always need mono, and not just "generic C#"? 17:02
sorear just made an inquisitive reply 17:05
letssewhere that goes
harmil ha! I had my own tracing code and using Grammar::Tracer now makes my code throw an exception ;-)
17:10 fgomez joined
[Coke] +# 07/06/2012 - rakudo++ (22844); niecza (90.11%); pugs (38.95%) 17:12
so, guess the 9% of passes on pugs is worth being stuck on linux until we get au back.
phenny: au - come back to pugs, we miss you. ;)
phenny: msg au - come back to pugs, we miss you. ;)
phenny: tell au - come back to pugs, we miss you. ;) 17:13
phenny [Coke]: I'll pass that on when au is around.
[Coke] ETOOMANYBOTSYNTAXES
rjbs Coke's getting desperate
harmil [Coke]: I think that's just EBOTS
[Coke] rjbs: come hack on pugs, we miss you!
rjbs tempting :) 17:14
[Coke] hell, we have haskell, C#, and NQP implementations. I'm sure you can find something fun. ;) 17:15
rjbs Once the kid's in college. ;)
[Coke] ugh. my oldest only has 3 years of HS left. 17:16
17:17 xinming_ joined
[Coke] rjbs++ # p5p wrangling. 17:17
17:19 xinming left
rjbs One does what one can. 17:20
diakopter many times, one does not do what one can. 17:22
arnsholt But sometimes, one also does what one cannot
17:22 stephenlb joined
seldon What does it mean when rakudo is confused? 17:27
flussence r: o_0?
p6eval rakudo 5ee1f1: OUTPUT«===SORRY!===␤Confused␤at /tmp/NfywfP3d3H:1␤»
arnsholt Parse error, essentially
seldon But there's only a comment in line 1. 17:28
moritz sometimes the line number is not quite correctly 17:29
especially if rakudo is confused
seldon I see.
moritz maybe one of the following lines isn't propery terminated?
seldon Nah, it most likely has something to do with modules, which is what I'm trying to make sense of right now. Is it either class or module but not class in module? 17:31
moritz nesting classes in modules is fine
r: module A { class B { } }; say 'Look? Fine!'
p6eval rakudo 5ee1f1: OUTPUT«Look? Fine!␤»
17:31 kaare__ joined
moritz seldon: if you nopaste the code somewhere, maybe I can spot the error 17:31
17:32 kaare_ left
seldon Sure, just a moment. 17:32
dalek c: 0fe1236 | moritz++ | lib/Signature.pod:
[Signature] parameter traits and modifiers
 17:33
seldon moritz: codepad.org/cMI5ziMJ 17:35
The foo function works, but the FooType gives me trouble. 17:36
moritz Foo::FooType $f;
should be
my Foo::FooType $f;
seldon Ah. I feel very stupid now.
moritz I've made the same mistake quite a few times
once you start typing your variables, you fall back to C/C++ syntax automatically :-) 17:37
I even tried to declared sigilless variables that way
seldon Yes, language hopping is fraught with peril. I wonder what happens when I get back to my templates after coding perl6... 17:39
I can just see myself writing template<@types> class foo { ... }; 17:40
17:40 vmspb joined 17:51 topologist joined 18:01 sisar left
colomon seldon: what happens is you cry. or at least, that's my usual reaction to going back to C++... 18:02
seldon Nah, I like C++.
colomon seldon: I'm not a C++ hater -- I use it all the time. but still, I frequently find myself lamenting the fact I'm not programming in p6. 18:03
seldon Whenever you want to parse something, presumably. :P 18:04
colomon particularly if I'm doing anything much with arrays/vectors or what should be regular expressions...
yes, exactly.
arnsholt I frequently lament the fact that I'm not doing P6 when I'm doing P5 =)
seldon I use boost.spirit when I have to parse something in C++. Very C++y, and also blazing fast, although not as comfortable as perl6. 18:05
colomon seldon: unfortunately, boost isn't really an option for me. :( 18:06
seldon How you can write C++ without boost is beyond me.
colomon seldon: like I said, there are tears involved. 18:08
seldon There are regexes in the new standard, though, so you'll get that with one of the next compiler upgrades.
colomon seldon: doesn't work like that for me. I ship C++ source code, and I've got to support more or less every compiler from the last decade. 18:09
seldon Argh.
colomon I actually got a bug report a couple of years ago that I wasn't properly supporting VC++ 6 (from 1998). 18:10
seldon Well, at least that doesn't include VC6 anymore.
ARGH!
colomon yeah, I ignored that bug report.
:)
seldon You did the right thing.
arnsholt Discussions like this make me somewhat happy I'm in academia =) 18:13
Just releasing code is worth brownie points ^_^
18:18 sisar joined
seldon What is the going rate for brownie points these days? :P 18:19
18:25 kaare__ is now known as kaare_
seldon My module works! \o/ 18:25
seldon does a victory dance.
[Coke] \o/
18:26 xinming_ left
colomon \o/ 18:26
colomon wonders what seldon++'s module does.... 18:27
pmichaud produces dancing ascii art? \o/ \o_ _o_ !o!
seldon It's a brainfuck interpreter. I just made my little learning project into a module. 18:28
colomon brainfuck in p6?
pmichaud
.oO( still no new yapc::na videos on youtube :-/ )
I guess it was too much to hope for.
seldon Module: codepad.org/pr8hgOSB To be used like codepad.org/6rf2ozms 18:29
colomon seldon: now you need to add it to the p6 ecosystem... ;) 18:31
... and tests ...
seldon I suppose it is more useful than ACME::Meow. ;) 18:32
colomon seems like if nothing else it may be a handy test case for the different compilers.
seldon I'll learn about module testing next, then. 18:34
18:34 am0c left
seldon ufo didn't seem to work for me, by the way. Complained about missing method f for class Str. 18:34
harmil I have a "has $.x is rw = True" in my class, then I have a method that does a "say self.x" and I get back "Any" … am I doing it wrong?
seldon self.x(), I think 18:35
moritz r: class A { has $.x is rw = True; method f() { say self.x } }; A.new.f
p6eval rakudo 5ee1f1: OUTPUT«True␤»
moritz seldon: no, works without
harmil: do you happend to have another method named x?
harmil: otherwise... show the code. In the minimal example above it works 18:36
harmil no, but that might be part of it… there's some namespace collision I think
colomon forgot to listen carefully to Tom Steele once again...
colomon now knows that Brian Conway's Tom Steele is not the real he is looking for 18:37
pmichaud missing f for class Str -- any chance it's treating Str like IO ?
seldon Hold on, let me check that. 18:38
harmil moritz: the problem is, it's kind of clunky. I'm hacking on Grammar::Tracer to try to get it to not highlight in ANSIColor when I set a parameter to False. Otherwise less is not pleased
let me throw it up in a gist
seldon It's in line 163, near the end. when $p.f { ...
moritz harmil: there's a command line opttion for less that makes it pleased
seldon: then likely your rakudo is too old for the ufo you're using 18:39
seldon And $p comes from for dir($dir, :test(*)) -> $p {
That could be.
moritz in rakudo 2012.06, dir() returned strings
it now returns IO::Path objects
which have an .f method
seldon Is 2012.07 released yet? 18:40
moritz nope
pmichaud July 19ish
moritz harmil: less -R 18:41
harmil Thanks, that wasn't at all obvious ;)
pmichaud anyone have a command-line gist utility, ooc?
harmil I've been using less since the early 1990s and I had no idea....
pmichaud the one I was using (App::NoPaste) no longer works with gist.github.com (they changed the API)
moritz harmil: it might not have had that option in the eary 90ies 18:42
harmil: or maybe it had. No idea :-)
18:42 benabik joined 18:43 xinming joined
colomon pmichaud: if you find one, please share it, it's a great idea. 18:45
pmichaud I could try to get App::NoPaste::Gist to work again; but I suspect it requires OAuth or something like that nowadays. I couldn't find documentation for the API on github 18:46
I could switch to a different nopaste service, I guess.
seldon Is there an easy way to redirect $*IN to a string? 18:47
moritz seldon: my $*IN = (class A { method get { 'foo' } }).new # easiest case 18:48
or whatever method(s) you use for reading from $*IN
colomon seldon: you can have a grammar parse a string quite easily, if that's what you're trying to do. 18:49
seldon Nah, it's for the tests.
moritz in your case maybe 18:50
18:51 am0c joined
moritz class StringIO { has @.records; method read($|) { @!records.shift } }; 18:51
sisar pmichaud: sprunge.us/
moritz and then my $*IN.StringIO.new(records => [ ... ])
erm sorry, |$ in the signature
or $bytes or so
seldon Looks good. Thanks. 18:52
pmichaud sisar: looking
sisar pmichaud: oh, you want to paste to github. Sorry, i misread it as if you wanted a command line paste utility.
pmichaud if I can't find one to paste to github, I'll probably stick with App::Nopaste and just have it go somewhere other than gist 18:53
oh, found the API!
developer.github.com/v3/gists/ 18:54
okay, time to patch
harmil r: say /'(' ~ ')' 'b'/ ~~ '(b)' 18:55
p6eval rakudo 5ee1f1: OUTPUT«False␤»
harmil shouldn't that be True?
pmichaud smartmatch is backwards 18:56
harmil oh right
pmichaud r: say '(b)' ~~ /'(' ~ ')' 'b'/
p6eval rakudo 5ee1f1: OUTPUT«q[(b)]␤␤»
sorear colomon: ping
colomon sorear: pong
sorear colomon: with a clean install of Mono 2.11.2 from go-mono.com, LD_LIBRARY_PATH=/Library/Frameworks/Mono.framework/Versions/2.11.2/lib mono run/Niecza.exe examples/gtk-clock.pl DTRTs 18:57
bugzilla.xamarin.com/show_bug.cgi?id=6019 # relevant 18:58
harmil boy, for command-line usage, it would be really nice if regexes allowed for both 'string' and "string" as literals
colomon DTRT is does the right thing?
sorear yes
moritz harmil: they do
pmichaud harmil: they do.
harmil umm…
18:58 atrodo left
pmichaud r: say '(b)' ~~ /"(" ~ ")" "b"/ 18:58
p6eval rakudo 5ee1f1: OUTPUT«q[(b)]␤␤»
sorear harmil: I thik your shell is eating quotes. 18:59
harmil odd, my test didn't work. I must have done something wrong
pmichaud and double-quoted strings (are supposed to) interpolate like normal double-quoted strings (I think nyi in Rakudo)
sorear what was the command line?
colomon sorear++
harmil Ah, I had a rogue :
damned backstabbing colons!
sorear colomon: it works for you?
colomon I had to make it 2.10.9 instead of 2.11.2, but yes 19:00
harmil ok, so I was trying to come up with this example:
r: grammar A { rule TOP {^ <term> $}; rule term { <variable> | <function> }; rule variable { <ident> } ; rule function { <ident>"(" ~ ")" <params> }; rule params { <ident>* % "," } }; say A.parse("foo(bar)")
p6eval rakudo 5ee1f1: OUTPUT«#<failed match>␤»
colomon sorear: is stefanor you?
harmil basically, I'm trying to match a function signature looking thing, and it's consistently failing to even try. It always matches <variable> and gives up
pmichaud yes, because <term> doesn't backtrack 19:01
harmil I've used Grammar::Tracer and it just shows that it never goes into function
sorear colomon: yes
harmil shouldn't term try all alternations in parallel?
pmichaud the whitespace at the beginning of rule function prevents it 19:02
moritz (which is a known rakudo bug)
pmichaud well, as does the whitespace at the beginning ov variable, too
so ltm is effectively disabled (rakudo bug)
harmil moritz: oh thank you! I was about to have an aneurism if that was intended behavior ;-)
man, I've been beating on this one all day. Thank you 19:03
colomon sorear: hmmm. Is setting LD_LIBRARY_PATH in my shell a decent fix, or does it have issues I'm not seeing at the moment? It seems to be set to nothing right now...
pmichaud harmil: I'm wanting to fix that but need to figure out the migration path for existing code.
(as well as fix existing code.)
colomon sorear: hmm, xahlee.info/UnixResource_dir/_/ldpath.html 19:04
sorear colomon: setting DYLD_FALLBACK_LIBRARY_PATH would probably be safer
moritz usually one just adds a path to /etc/ld.so.conf
runs ldconfig to update the cache
and that's it
19:05 GlitchMr left
colomon moritz: /etc/ld.so.conf: No such file or directory 19:05
sorear colomon: as that page points out, any software which relies on LIBRARY_PATH is buggy. Which is why I filed that bug :) 19:06
harmil pmichaud: I think you can legitimately just break existing code. I know r* is supposed to be "usable alpha" but alpha software breaks existing code sometimes, and this is clearly a "change to match the spec"
sorear moritz: this is the Darwin dyld, not ld-linux.so.2
moritz sorear: :(
colomon sorear: btw, the reason I started very actively messing around with GTK# stuff again is that I'm hoping to add MP3 playback to my TuneReminder script. ;) 19:07
pmichaud afk for a moment, phone
sorear colomon: if you set LD_LIBRARY_PATH, mono's bundled libraries will effectively override system libraries within the shell, which could break lots of stuff 19:08
colomon: if you set DYLD_FALLBACK_LIBRARY_PATH, mono's bundled libraries will be ignored if there is a system library of the same name, which could break Mono, but probably won't break anything else
colomon okay, done, and it seems to work nicely. 19:12
sorear++
jnthn evenin' 19:13
colomon \o
sorear o/ jnthn
moritz \o jnthn
19:13 mucker left
harmil \o \o o/ o/ o/ \o \o jnthn (doing the wave) 19:14
jnthn
.oO( tsunamiest greeting ever )
 19:15
pmichaud back from phone 19:16
harmil: well, I'm wanting to think of rakudo as more than just 'alpha' status these days.
one of the things I've heard a fair bit of recently is "rakudo breaks my code too often to be usable". 19:17
moritz pmichaud: have you heared that from many different people, or fairly often from one person?
pmichaud more than one
colomon has to admit he has had that problem with rakudo this year...
pmichaud I'd say around five at least that I can remember. But more to the point, these are five highly visible people. 19:18
i.e., people who are also interested in teaching Perl 6 and building on ramps for it
harmil pmichaud: I understand, but this is a pretty major core feature that simply doesn't work right now. That's something that kind of needs to be fixed, and to, at this stage of Rakudo development, hold off because of backward compatibility is probably too much overhead to accept 19:19
I'd completely agree that breaking existing code should give us pause, but I don't think we're at a point where we can yet say that existing code must be preserved.
moritz pmichaud: thing is, I don't see what we could possibly do to help users in this case 19:20
pmichaud harmil: when do we reach that point, though?
moritz pmichaud: except prior notice
pmichaud moritz: yes, prior notice is one thing
and in this case, people can "fix" their code by adding <?> at the beginning of rules. That works both pre- and post- change. 19:21
I'm not totally against making some dramatic breakages. But I think we have to start giving people an idea of when the dramatic breakages will stop, and stick to that.
harmil pmichaud: I think that, once the standard library exists and has all of the basic features you'd expect from P5.001, for example, then we should set a 1.0b tag and tell people that they can rely on the interfaces that exist, barring major version bumpage.
pmichaud harmil: that's another way of telling people "don't use this until we set that tag" 19:22
but most of the reason our standard library is changing is because people are using it and saying "that's not quite right..."
harmil Not at all. I'm using it. I've got users relying on P6 code today, but I am very draconian about what Rakudo Star release I support
pmichaud I'm quite certain that the reason a large number of people are holding off is because they're waiting for a "it's stable" tag. 19:23
harmil If someone grabs .07 and it fails, I'll just shrug and tell them to follow the install docs
pmichaud: you are absolutely right, but I also don't think you want large-scale adoption yet. An alpha tag keeps early adopters in and the rest of the world correctly cautious 19:24
pmichaud I'm not asking for large-scale adoption yet. But we need larger adoption than we have now.
harmil I think Perl suffers less from being alpha and more from many, many waves of premature enthusiasm over the past 10 years
pmichaud there are many intermediate stages between "alpha" (which is effectively pioneers) and tags that encourage early adopters. 19:25
without going all the way to "widely adopted"
harmil When I mention "I'm using P6 at work" to someone, the first response is always either, "what's that" or "Perl6 is that back again? Didn't that fail like 10 times?"
masak it didn't fail so much as didn't succeed yet :) 19:26
harmil masak: I'm just the messenger. I know the score, but most people don't
masak nodnod
pmichaud keep in mind also that star doesn't have to closely track the compiler
masak I can totally see that you'd get those reactions, fwiw.
pmichaud anyway, "fix it regardless of what breaks" is noted. 19:27
afk for 15m
harmil If we've wandered into "how do we increase adoption," then I'd say we need more robust libraries and more satellite projects that can attract developers regardless of the language of implementation. 19:28
19:28 zby_home joined
masak agreed. 19:29
moritz well, but if we don't have stability, maintaining those will be a nightmare
harmil On the "more robust libraries" front, I'm willing to help. I'm already, slowly, tackling the IO::Parrot discussion we had before, and have no objection to being pushed in another direction after that.
masak well, we've been saying "we should bolster the module/application programmer part of things" since 2009-ish.
harmil masak: yes, but it wasn't practical, then 19:30
masak it was less practical than today, for sure.
harmil frankly, I tried to use p6 for about a dozen projects, and I failed every time because I'd hit major unimplemented chunks of the language
masak it gets easier all the time, much thanks to people who are already helping write infrastructural bits.
also, the ecosystem force-multiplies itself, like CPAN does. 19:31
sorear o/ masak
masak sorear: \o
harmil yep. Rakudo as it is today is about 90% of what I look for in a "production ready" language.
That last 10% is a real pain, though ;-)
masak please let us know about those 10%. 19:32
I was doing web development in 2008, when that ratio was reversed :P
sorear wonders what niecza looks like under harmil's 100% objective evaluation
masak .oO( get off my lawn! )
19:34 atrodo joined
[Coke] continues to hiccup, violently. 19:35
harmil sorear: to be perfectly honest, I've not used niecza except via the bot in this channel. I just don't have the time to use two p6 implementations, and so I arbitrarily stuck with the one that I used first (well, second, but Pugs isn't where I need it to be) 19:38
sisar [Coke]: Hiccups? If it started while you were eating something or because of eating something, may I suggest taking a spoon of sugar. It always helps me.
harmil masak: OK, I owe you two blog posts, then. I'll finish the Python setuptools/P6 integration one and then I'll collect my "last mile" thoughts on P6 19:39
masak I can heartily recommend Niecza. in some cases it's ahead of Rakudo (grammars). in others behind (MOP).
harmil: cool.
sisar ++harmil
harmil [Coke]: I find that hiccups are cured by a gunshot wound to the chest. However, you may find the side effects daunting.
seldon How is niecza performancewise? 19:40
harmil gets snarky in the face of health-related advice...
masak seldon: often faster at runtime. slower at startup.
this might be an overgeneralization in some cases... but I find it tends to hold up. 19:41
harmil Unable to parse _block3450, couldn't find final ')' … is that the correct error for '(' ~ ')'? Isn't it supposed to put the name of my rule in there?
masak that does indeed look a bit suboptimal. 19:42
sorear harmil: what happens if you put a :dba("...") in the rule? 19:44
harmil oh wow! that's a problem with Grammar::Tracer interaction! If I comment it out, then my error has my rule name in it....
masak that explains it to me. 19:45
Grammar::Tracer is essentially wrapping another thing around your rule. it's an anonymous routine.
so the strange non-name you're seeing is that anonymous routine's.
pmichaud back again 19:46
if after 8 years I'm still working on an "alpha" product... I need to do something else.
harmil I've run into that problem myself in trying to inspect exceptions… I'd love to have some way of asking, "what's the first non-anon sub/method/rule/whatever along this stack frame list?"
sorear pmichaud: we retired alpha in feb '10, remember? :D
pmichaud sorear: that's my recollection, yes. :) 19:47
harmil pmichaud: I don't think that there's any reasonable objective way to have put an alpha tag on Rakudo prior to 2011. I know that may not be what you wanted to hear, but IMHO you've been working on an alpha implementation for about 1.5 years. 19:48
pmichaud harmil: and the 6.5 years before that?
masak what's the letter before alpha? :P 19:49
harmil Call it whatever you like, but alpha has a pretty clear meaning: mostly feature complete and ready for the first external use. Mostly feature complete was a pipe dream from 2000 to 2010. It was an increasingly clear pipe dream, but it was a long pipe! 19:50
"pre-alpha" is a commonly used term. Before that it's just "development"
masak harmil: I think the point is that these version superstition things don't have "a pretty clear meaning".
it's more like a cloud of meanings around each of these things.
moritz has the feeling were' back to the discussions from '09
*we're
19:51 zby_home left
masak moritz: harmil wasn't around back then, you should let him experience some of the joy of it, too ;) 19:51
harmil masak: I've been in and out since the beginning
masak oh wait, harmil is ajs...
harmil correct
masak right.
[Coke] sisar: diabetic, but thanks.
sisar [Coke]: oh. 19:52
pmichaud moritz: (back to '09 discussions) that's kind of my point. We've gone through this before, and if we're no farther along...
harmil IRC not withstanding, I've been around the block, and yes, I recall similar conversations. I always stressed the term "pre-alpha" and thought I was being somewhat generous at that.
pmichaud normally if you're releasing software with the expectation that others will be using it, it's beyond "alpha" 19:53
harmil pmichaud: that's not true. We're phenomenally far along! I can't begin to stress what a dream it is to work in Rakudo Star 2012.06 compared to any other implementation of P6 I've ever touched!
pmichaud the "alpha" label refers to internal development and testing prior to any published releases
[Coke] pmichaud: just let us not fall into the trap parrot did.
pmichaud [Coke]: which trap, exactly? the one of publishing "1.0" before we're ready? 19:54
[Coke] "we can't change this" "but it isn't done yet!"
moritz pmichaud: well, maybe the discussions recur, but the software is much further along
pmichaud [Coke]: oh, no risk of that.
harmil pmichaud: yes and no… typically alpha testing in large projects has some external buy-in. An invitation-only external group.
pmichaud harmil: I hope we're far beyond "invitation only", too.
[Coke] pmichaud: but that's exactly the sort of thing I'm gleaning from this conversation.
hoelzro is tadzik still around? 19:55
19:55 crab2313 joined
hoelzro I have a question about MuEvent 19:55
pmichaud [Coke]: I'm not saying "don't change anything", I'm saying "what's our process for change?"
harmil moritz: absolutely! We'll be having the "what stage of release are we at" discussion right up until 7.0 comes out! ;-)
moritz pmichaud: writing htmlify.pl for p6doc was a very nice experience
pmichaud there's no way I'm going to go for the silly "supported" versus "development" dichotomy
[Coke] hokay. as long as that process isn't too painful, sign me up.
pmichaud we _have_ to be able to evolve, if only because the spec will require it. And P6 is all about having better control over evolution.
[Coke] Are there any SYN that are baked? 19:56
moritz pmichaud: in terms of features (I didn't hit a single missing rakudo feature), error reporting (with the same exception of some parse errors) and bugs (I didn't hit any rakudobug)
harmil speaking of the spec, I'm more interested in getting IT nailed down than the implementations. Do we have any clear idea on what we have to do to get _there_?
pmichaud my purpose here is not to say "we have to retain backwards compability no matter what" -- my purpose is to say "how do we help our users deal with the inevitable breakages?"
harmil pmichaud: that's a very sane question 19:57
pmichaud harmil: we have to have the implementations farther along. Don't make the mistake of putting the spec before the implementation.
moritz harmil: we can't nail the spec independently of implementations
masak hoelzro: please ask it.
pmichaud the specs and implementations must co-evolve.
harmil moritz: pmichaud: I'd agree witht hat
moritz harmil: that's waterfall model thinking, which hasn't been working for 40 years
pmichaud harmil, in fact, freezing (parts of) the spec is the "1.0b" tag you referred to earlier. 19:58
harmil but I'd also like to see some mile markers on it. I'd like to know that S05 is pretty much stable and know which bits of it I can really rely on.
moritz harmil: I've worked on such a classification
pmichaud harmil: the leading whitespace bug is one of those "wasn't really stable" things.
moritz harmil: but never got very far
pmichaud and the ? quantifier has flipped back and forth at least twice
harmil Hmm… if we had some way to annotate the spec (perhaps in a Web edition) with bug reports… that might help a lot
masak the "the spec still needs room to change" people will always win arguments as long as the compiler implementors outnumber the application developers (if not in absolute numbers, then in person-tuits).
[Coke] spec is already annoted with spec tests, btw. 19:59
masak when the community grows, the equation will change, and things will *need* to stabilize, whether they're ready or not.
[Coke] so you can see what is tested (more likely to be solid) and which implementations are not fudging those tests.
moritz harmil: gist.github.com/2346494
harmil [Coke]: yes, but there's no indication of who passes, is there?
sorear making promises not to change stuff is the mistake Perl 5 made
moritz harmil: you can always annotate the specs from the outside. That'w what I've been doing there
pmichaud what we can likely say is that there will be a spec frozen to a consensus of the implementations; and that spec will be almost immediately obsolete by new features and changes 20:00
sorear the whole point of perl 6 is to avoid that.
pmichaud and that the frozen spec will be a subset of what exists today.
[Coke] harmil: theoretically, if you're unfudged, you're passing.
harmil moritz: good stuff, but obviously very subject to bit-rot
moritz harmil: well, that's the case with any annotation
pmichaud "bit-rot" is the very definition of "not frozen" 20:01
hoelzro masak: it's about the licensing about MuEvent
I'd like to use it for a chat bot I'm writing
harmil moritz: not if it's generated on the fly form bug reports and test results....
moritz harmil: we can't test the spec. We can only test implementations of the spec
[Coke] pmichaud: do we need to warn users of the compiler, or just of star? 20:02
harmil hoelzro: sorry, what's about the licensing?
pmichaud [Coke]: I'm primarily interested in 'star'
hoelzro harmil: I'd like to use tadzik's MuEvent for my chat bot, and I was wondering about the licensing
pmichaud since it's our recommended release
masak hoelzro: I think you can readily assume a permissive license. tadzik won't clamp down on you. I'll make sure it gets a license. 20:03
hoelzro awesome, thanks! I just wanted to make sure I wasn't stepping on any toes
sorear harmil: it already is generated on the fly
moritz hoelzro: tadzik's other stuff is mostly MIT licensed
pmichaud ...but since I'm currently on the hook for this month's star release, I need to know how we'll start managing the breakages so that I can ... manage them. :-) 20:04
harmil sorear: from bug reports?
sorear harmil: no, from changes to the spec repository
harmil: bug reports can't be trusted
harmil: sorry, from changes to the test repository
harmil pmichaud: if anyone's asking me, I'd suggest that we start adding something to the end of "use v6"
20:05 birdwindupbird joined
harmil so, if you use v6 (or default) and have whitespace at the beginning of your rule, you get a warning in 2012.07. If you use v6.whatever you don't 20:05
pmichaud harmil: you mean in the sense of "if someone requests an older version then the compiler provides the older version's semantics?"
harmil That's my off-the-cuff answer 20:06
[Coke] that way lies insanity.
harmil [Coke]: why?
pmichaud [Coke]: (that way lies Perl 6, actually :-)
[Coke] I would only do that for things that change in incompatible ways.
20:06 SHODAN joined
harmil [Coke]: I thought that's what we were talking aout 20:06
[Coke] harmil: how many versions of perl6 does rakudo (e.g.) need to support simultaneously?
harmil *abouyt
bah
[Coke]: NO, I'm absolutely not saying that 20:07
[Coke] I thought we were talking about ways in which we could jettison old versions of the spec as soon as possible.
harmil [Coke]: (not being angry, just emphatic)
[Coke] ah, I was responding to pmichaud's response above "if someone..."
harmil [Coke]: we were talking about pmichaud's fix for whtiespace at start of ruels
pmichaud as soon as possible, and with minimal disruption to existing code
as soon as possible is easy by itself :) 20:08
[Coke] pmichaud: if we can support it both ways great. if there's a workaround, advertise in the next release, cutover the release after that.
pmichaud actually, I don't mind having disruption that is more than minimal. But I want disruption that is not beyond our users' expectations.
[Coke] pmichaud: if there isn't a workaround... same thing. just warning people if they upgrade past the next version, they'll need to change their code. 20:09
harmil My only trepidation is that with what I suggest, "use v6" becomes obsolete and you need to use a more recent version in order to have reasonable code not throw warnings… I might want a different pragma, but a pragma is definitely the way to go, IMHO
[Coke] pmichaud: (users' expectations). The only user I know of who has expectations like that is no longer a user.
hopefully you have more helpful data than I
pmichaud [Coke]: just to make certain I'm following accurately: warn one release prior, then change in the next? 20:10
(at least one release prior)
harmil FWIW, since I'm the only person I know of in the world who deploys code at $job in P6, my expectation is that the upgrade path from Rakudo Star release to subsequent release will be fraught with increasingly less pain over time. The magnitude of the initial pain is, as far as I'm concerned, currently undefined. 20:11
dalek ar: 121678e | moritz++ | Makefile:
HTTP::Easy is again maintained by supernovus++
 20:12
ar: c1c1244 | moritz++ | Makefile:
got back to using HEAD of several modules
harmil I think I would be bothered strongly if that pain took the form of a major re-write of my code, but if it took the form of some substantial logic re-jiggering, then I'd be less plussed. 20:13
pmichaud harmil: I'm just trying to execute a substantial drop in that pain in the very short term, or at least let people know (both users and developers) that such a drop needs to be on our shorter-term horizon.
harmil pmichaud: worthy
[Coke] pmichaud: (warn at least one in advance) - assuming that the whole point of this conversation is that warning them -on the release it happened on- is insufficient, yes. 20:14
pmichaud [Coke]: I think that the amount of warning required may be related to the magnitude of the change. That's one thing that Parrot's policy didn't really address, I think. 20:15
[Coke] sure, there may not be a one size fits all.
masak well, it'll always be a tradeoff. we know the spec needs to change, and sometimes the implementations with them. it's all about riding the curve of the "appropriate" mix of backwards-compat and fluidity.
[Coke] but at this point, I wouldn't worry about too many sizes. 20:16
moritz oh, and if we are to be serious about change management, then it should also apply to the modules shipped with R*
which is something we haven't really addressed yet at all
pmichaud moritz: yes
[Coke] moritz: ... eh. we don't have CPAN so everything is defacto core.
I don't think all the modules shipped with * are really core, do you?
moritz [Coke]: they aren't. That's the point of a distribution though (shipping non-core modules) 20:17
currently we only have two "core" modules in the p5 sense. Test and lib
[Coke] even if they are, have we solidified any of them? (or do they fall then to the lesser standard of just letting people know in the same release announcement.)
pmichaud at some point I'm hoping distributions will be more discriminating than what we've been in Rakudo Star thus far
but distributions are where the "how stable do things need to be?" decisions take place 20:18
sisar is reading www2.tcl.tk/3018 titled: "everything is a string". 20:19
Quite interesting.
cxreg a tiny vibrating string?
sisar one line which i really like is "Data typing is an illusion. Everything is a sequence of bytes. Call 'em ints, floats, symbols, strings, whatever. Tcl exposes both code and data to the user as sequences of bytes (called strings). This is Tcl's choice of abstraction." 20:20
cxreg: :D yes, superstings !
masak sisar: you can see much of the same mindset in Perl, especially Perl 5.
pmichaud I wonder to what degree that "choice of abstraction" precludes other abstractions, though. :) 20:21
masak sisar: in Perl 6 Str is a sequence of characters, not bytes. but much of the flexibility is still there.
sisar masak: *nod*
pmichaud many times the axiomatic choices made determine the possible world views that can result. 20:22
harmil: thank you for your suggestions on the deprecation topic; it has been very useful to me.
masak much of the early "wow this is really nice" experience I had with Perl 5 back in 2003-2004 was about everything being potentially a string.
pmichaud do we have anything appearing in the 2012.07 compiler release that really needs to be included in the 2012.07 star release? 20:23
phrased differently, is it problematic if 2012.07 star release uses the 2012.06 compiler?
moritz pmichaud: depends on your definition of "problematic" 20:24
pmichaud: you'd have to ship old versions of ufo, panda, File::Tools and p6doc
cxreg masak: all scalars reasonably stringify, but you have first class arrays and hashes too. you could theoretically do anything in a string with sufficient escaping, but lord knows i'd never want to.
moritz so the question becomes: if you ship the old versions of the compiler, panda, ufo and p6doc with star 2012.07, what benefits can it offer over 2012.06? 20:25
pmichaud moritz++ # excellent rephrase
20:26 crab2313 left
harmil pmichaud: your welcome. I'm trying to ride the line between distracting and thus counter productive and communicative enough to be helpful. 20:26
pmichaud how viable is it for us to tell people "Here's what we broke in 2012.07. If that's too much for you, stick with 2012.06 a while longer?"
harmil: it's a very difficult line, yes. :)
[Coke] pmichaud: you would need to ask the users if that's helpful. 20:27
but, if a user isn't going to upgrade to 2012.07 ... when will they ever upgrade? 20:28
pmichaud thinking a bit farther, is there a bit of a upgrade model change available here? (more)
[Coke] (I would just leave off the "don't upgrade" postscript.)
pmichaud i.e., we issue a release, and if someone says "hey, you broke this thing that I really need and can't upgrade" then we figure out how to go back and add backward compability so that someone can skip the broken upgrade and go to the one that works? 20:29
yes, I can see potential problems with that (starvation)
20:29 stepnem left
pmichaud but if we have a general notion of "if we break something really important in a release, we'll come up with an upgrade path shortly thereafter?" 20:29
[Coke] pmichaud: if it's broken, let's not release it. 20:30
pmichaud sounds fragile to me.... but evolution feels like it needs to be a negotiation and not just a "don't change until it's safe" process
dalek kudo/nom: 57eaaad | moritz++ | / (3 files):
rename lib.pm to lib.pm6

  @VienosNotes on twitter had a build problem where a "use lib" in one
of our perl 5-based build tools picked up the lib/lib.pm from Rakudo, and died.
[Coke] pmichaud: if it's /changed/, we can think about it. if we /broke/ something, our release process is wrong.
pmichaud I mean broke something in userspace code because of a change.
not that rakudo itself has an internally broken feature. 20:31
[Coke] ok, but if we did that, we cut the release unknowingly and couldn't announce it in the release. no?
ah, that's what you said.
so, "do we issue point releases to fix bugs?" sure.
pmichaud that's not exactly what I'm saying 20:32
harmil Hmm… how about an upgrade tool in every release?
pmichaud whenever we make a change, it's presumably to eliminate a bug (perhaps introduced by a spec change)
moritz harmil: what kind of tool are you thinking about?
pmichaud harmil: that presupposes we know everything that needs upgrading beforehand. I don't think we're that prescient.
harmil moritz: a modified P6 parser that warns on possible upgrade problems and the versions they affect 20:33
not a fixer, just a warning
20:33 vmspb left
harmil One nice thing about grammars is they're subclassable.... 20:33
20:33 stepnem joined
pmichaud harmil: imo, developing those sorts of things _really_ slows down momentum 20:34
because you spend a lot of time on the upgrade tool maintenance without actually knowing if they get used (or are really needed)
plus, I've yet to see a system like that that actually worked. :) 20:35
jnthn Well, this is the other trade-off. How much development time can we afford to invest in easing upgrade paths? What's the threshold?
harmil pmichaud: what if the upgrade tool was rakudo itself, but with command-line options? 20:36
jnthn I mean, in some cases it's simple: detect use of old syntax, warn or die with something helpful about the upgrade path.
pmichaud harmil: my note about maintenance and momentum still holds in that case :)
harmil --expected-version=2012.05 or the like
pmichaud if we can do --expected-version=2012.05, that gets back to the "use v6" + version information described earlier
jnthn In the case of the whitespace-at-start-of-rule changes, it's trickier. Sure, we *can* code-gen rules with an implicit <.ws> at the start and warn if it actually matches any whitespace. 20:37
But it's (a) not perfect, and (b) fiddlier.
harmil pmichaud: yes but making it an optional command-line thing removes my concern about having "use v6" become obsolete
pmichaud and (c) how long do we keep it?
jnthn pmichaud: That too.
pmichaud: We're still accepting the old protoregex syntax, for example.
pmichaud oh, I'm fine with eliminating that, fwiw :)
jnthn <...> was {*}
*vs
pmichaud I was keeping it because there might've been other languages using nqp-rx as a base that needed it. I'm fairly certain that's no longer the case :) 20:38
unless, of course, rakudo is using {*} still, in which case we need to get rid of those.
jnthn pmichaud: I'm worried about modules like, say, JSON::Tiny that may be using it. 20:39
(I dunno if it is.)
OK, it looks up to date in this case. :)
harmil Oh, I think we keep it forever. The argument to --expect-version should just be a tag that we, internally, map to an ordered list of all versions. Then any bit of code does something like, "upgrade-bump("2012.07", "whitespace at start of rule no longer kills longest token matching")"
that code can stay in forever because it only gets activated when you use the matching (or older) version on the command-line 20:40
sorear pmichaud: {*} is the new way
rakudo SHOULD be using {*}
pmichaud sorear: oh, I'm referring to a different {*} 20:41
[Coke] harmil: stay forever-- : that's code that needs maintaining, and therefore tuits, and we are scare on those. ripping things out asap is the way to go.
pmichaud sorear: there was a {*} token that appeared within regex syntax
jnthn pmichaud: oh...I was referring to the one sorear is
pmichaud jnthn: okay, that one too :)
harmil [Coke]: I don't understand why you would be eager to remove a warning like that if it is never emitted without a command-line option.
[Coke] harmil: because we have to write tests to keep it working. 20:42
and run those tests all the time.
harmil huh?
pmichaud and it could result in runtime overhead.
harmil what are you testing?
[Coke] harmil: that the feature/warning you wish to keep is not broken by some other change.
sorear pmichaud: fwiw, niecza is likely to soon get an extension to allow calling actions in the middle of rules.
harmil pmichaud: that's what macros are for, but I don't know if they're ready for prime time
20:42 skids left
harmil [Coke]: I think you misunderstood my intent 20:43
pmichaud sorear: ...will it be {*} perchance? ;-)
[Coke] harmil: entirely possible.
pmichaud (since that's what {*} originally meant in regexes)
harmil I have no interest in keeping an old feature, just warning people when they use a bug-fixed or updated version of a feature that there was an upgrade bump.
sorear pmichaud: I was thinking {*IDENT}
[Coke] , having gone through all this once before with parrot, is probably too sensitive, also. 20:44
pmichaud sorear: I'd be careful with the curlies there, though -- curlies really ought to imply more of a block.
[Coke] harmil: huh. yah, that's not why my brain saw. Even those warnings should be removed, though, no? (you're using a thing that changed 30 versions ago!)
pmichaud sorear: maybe <.ACT> and <.ACT: key> though 20:45
[Coke] at some point, the warnings should evaporate.
pmichaud although that's not quite right either.
harmil [Coke]: I think sometimes they will be replaced in the normal course of re-writing sections of code, but there's no reason to remove a warning in code that's static
pmichaud although <.ACT> works if we assume that it's a built-in method on cursors that invokes its corresponding action :)
[Coke] harmil: aha. this is where we get back to it. if we have to keep the warning there, we need a test to make sure it still warns.. 20:46
we wouldn't want to /accidentally/ remove the warning or garble it, neh?
pmichaud if it helps to shorten the discussion, I don't plan to do any sort of a compiler version switch anytime soon.
[Coke] same way that we're stuck warning people about perl5ism forever. ;)
pmichaud I know we'll have to have some mechanism eventually, but that's something I'm not ready to tackle today, and I have trouble seeing that as being a true blocker to progress because most other languages don't provide that facility (afaik) 20:47
[Coke] (not all of them, but there's a ton in STD.)
harmil do we? I don't necessarily agree. I think it's sufficient to add tests for the fix/new feature and perhaps run some/one of them in two modes (with/without the command-line flag). Regression tests just gain an extra step, but unique tests are not required.
[Coke] harmil: I disagree. code we mean not to break has to be tested. 20:48
harmil [Coke]: my point is that you're putting that emphasis in the wrong place
20:48 spider-mario left 20:49 spider-mario joined
harmil [Coke]: you should never have a version warning added to code "just because". It's going to be added because you did work, and that work needs to be tested. The warning itself is part of the work, and as such I have no problem with adding a test for that, but it's never in a vacuum. 20:50
[Coke] harmil: what's my wrong place, and what's your right place?
harmil: I'm not saying "just because".
harmil So, why is there "more testing" if you're just testing your new change?
[Coke] ok. we have a case where we add this warning, deliberately, with support aforethought. I'm saying the warning needs to be tested.
because you're testing the /feature/, and the /warning/, because you added the warning, not just the feature. 20:51
I suspect we're at least tangentially in agreement here.
harmil [Coke]: you are again mentioning adding a warning as if it's done in a vacuum. You are making a change. You are done making the change. You write tests for the change. All of this is the same as it always was. Now you add a warning in with your change that says, "hey I changed this at this version". Do you need to test the fact that you added that tag? Sure, if you like, but I don't see that as either required or extra work. It's part of testing your change. 20:52
pmichaud harmil: I'm in agreement with Coke here, fwiw. If you expect the compiler to produce a warning under certain conditions, you have to test that the compiler does indeed warn under those conditions. 20:53
sorear adding tests for a warning does not suddenly become effortless just because you are adding other tests at the same time
just like macro support doesn't suddenly make compiler features costless 20:54
harmil pmichaud: if you like. I think there's a point at which unit testing becomes so burdensome to run that no one ever runs it, but that's a discussion for another day. I also think there's a point at which unit tests become so burdensome that no one wants to do something new because it would mean adding too many tests (e.g. this dicsussion)
sorear: woah, wait… how is that the case? 20:55
pmichaud harmil: but the point at which unit tests become so burdensome is also the point at which you should ask "well, should I really be adding this new thing, then?" 20:56
If it's not important enough to test, then you're saying it's okay if it's not there.
harmil Your parse time is increased as a constant factor by having warnings in macros. Constant factors are not part of computing run time complexity....
pmichaud parse time is a part of our runtime, though.
In rakudo's case, it's often a significant part of our runtime. Parsing isn't "free". 20:57
sorear harmil: in the real world, constant factors *matter*
harmil sorear: in the real world, constant factors that matter are non-constant factors that are wearing a wig
pmichaud and if it's a function of the number of times a construct is used (like a regex), then it's not "constant"
harmil OK, let's back up a second. I'm very confused by this because I'm being told that apples grow on blue and that doesn't compute. 20:58
macro version-warning($version, $msg) { if $version.get-the-real-value-armwave >= $my-expected-version-command-line-otion { return-this-code-armwave { say {{{$msg}}} } } } } 21:01
how does that take time when we're parsing?
pmichaud I don't see what that is supposed to usefully produce. 21:02
21:04 atrodo left 21:07 kaare_ left
pmichaud returns to see if he can get App::Nopaste to work with gist.github.com again :-) 21:07
21:08 cognominal_ joined, cognominal_ left
sorear harmil: well, since the version command line option can change, you're requiring the parser to be recompiled every time you start rakudo 21:09
harmil: congratulations! You just gave Rakudo a 5-minute startup time.
21:10 cognominal joined
sorear if you don't beleive constant factors matter, I don't know what to say 21:10
21:10 cognominal__ left
sorear the difference between a compiler that compiles 20 lines per second and a clompiler that compiles 20,000 lines per second is a constant factor 21:10
masak r: say 20_000 / 20 21:11
p6eval rakudo 5ee1f1: OUTPUT«1000␤»
masak yes.
:)
sorear a nonconstant factor slower would be a compiler that takes N * N seconds to compile N lines
[Coke] sorear: no need to snark.
masak lol, I blogged! \o/ strangelyconsistent.org/blog/july-6...tions-look 21:12
21:12 fridim_ left
masak I again invite people to totally break the game in ways I haven't foreseen. 21:12
cognominal masak: parrot/nqp/rakudo sources are not mazes enough? :) 21:15
diakopter you are in a hierarchy of source files, all in slightly different DSLs 21:16
cognominal :)
masak cognominal: sir, are you seriously discouraging me from writing an adventure game in Perl 6? :P 21:17
21:19 bluescreen10 left
cognominal masak: As long you don't ask me do rewrite it in coffeescript, I don't mind so much. 21:19
masak then I promise not to do that. 21:20
cognominal I tripped on that yesterday :( www.mennovanslooten.nl/blog/post/62
21:21 spider-mario left
masak cognominal: yeah, scope in JavaScript is busted. :/ 21:22
"There's more than one way to do it. Your way is *wrong* [, JavaScript]."
cognominal TIMTOWTBI
colomon sorear: any notion on how to implement title-case in Niecza? There's a TitleCase method in C#, but it seems to be Microsoft's... idiosyncratic definition of what title-case means. 21:24
21:25 bluescreen10 joined
cognominal Javascript got in 10 days all the cruft perl got in 20 years. 21:25
But doing it in 10 days is more god like, almost like the biblical 7 days 21:26
harmil I'll point out that there's a difference between saying, "that's probably not practical because it would require re-compiling the parser with command-line switches as parameters" and, "congratulations! You just gave Rakudo a 5-minute startup time!" The latter sounds less productive and more argumentative to me. Perhaps I'm just reading it wrong. 21:31
sorear mmg 21:32
mmh
harmil en.wikipedia.org/wiki/MMH ? 21:34
sorear no, just a sound of consideration 21:36
masak I also thought it was a little too strawman-y.
sorear colomon: long-term best way would be to implement something in NieczaUCD.cs 21:37
harmil sorear: fair enough
I'm not certain, but I think there's a middle ground with respect to the compiler using macros. I think you could define an (albeit expensive) macro resolution pass at START time, but I'm not well enough versed in how macros are implemented in rakudo to know if that's practical. I'll admit that my naive "just make it a macro" approach was just that. 21:40
You would almost certainly NEVER want to do that in any program below some rather large level of complexity, but I think a compiler probably crosses that bar 21:41
"crosses … bar" … "mixed … metaphor"
Actually, now that I think about it, I think SBCL has something like that. 21:43
sjohnson eval: 3 21:45
buubot_backup sjohnson: 3
sorear harmil: I would not mind changed-feature notices as a courtesy 21:46
but I'd be very wary of a policy that _mandates_ changed-behavior notices, because some kinds of behavioral changes will require quite involved static analysis to detect 21:47
the other question is 'who gets to define the versions'
harmil Ah, I take it back. It seems that's a generic common lisp ism, not specific to SBCL
21:47 alester left
harmil sorear: I'm not advocating beuracracy (sp?). I think if we have the feature and someone thinks its worth using, they should use it and that would be a good thing. 21:48
sorear so then I think we're in broad agreement 21:49
harmil sorear: except now I want START macros ;-)
sorear sorry about the tension.
masak harmil: macros are already gone at START time. 21:53
harmil sorear: no tension. I'm in and out of impromptu meetings and debugging, here at work. I'm having a hard enough time re-capturing context, let alone maintaining tension ;-)
masak harmil: they have all been applied when parsing is complete.
harmil masak: but start-time macros aren't ;-)
masak harmil: URL?
harmil I'm bordering dangerously on proposing a 7.0 feature, not suggesting existing definitions cover any such thing. 21:55
Lisp has it, which makes it kind of attractive, but I understand it would be a massive change.
masak you still haven't explained what they are. 21:56
harmil What really happens in lisp is more complicated. Macros are really just a tool for modifying the s-expressions which make up your code. When you execute them is sort of up to you.
sorear harmil: I think 'start-time' means something different in Lisp than it does in Perl 6
masak I mean, I know you can put things in START phasers....
harmil I guess, to be more precise a "macro blah is START { … }" would not be evaluated away when seen, and instead remain as a sort of stub in the AST, and then at START time would be re-evaluated and replaced with its result.... 21:58
sorear START time is too late to modify the AST
harmil sorear: oh?
sorear harmil: in Perl 6, START phasers are run at the instant they are _first_ encountered in control flow 21:59
harmil ah, because code gen has been done. Yeah, Lisp doesn't really have the same concept of code gen
sorear START { foo } === state $run_foo; if (!$run_foo) { $run_foo++; foo }
harmil sorear: yes I know
sorear are you _certain_ you don't mean INIT or ENTER? 22:00
harmil I probably mean those as well, but the code gen problem still arrises.
Yeah, the overhead of keeping the AST around so that a second code-gen pass could be done would be obscene. I think I retract my desire for such a feature… though I'll still think about it. 22:01
The hard thing to get your head around about Lisp macros is that they operate on _the generated code_ not some data structure that will be turned into the generated code. There's tremendous power in that. 22:03
masak I'm not sure it's healthy to be wanting language features from other languages just for the sake of it. :) 22:05
show me what they enable instead, and we can talk about the means of getting the same results in Perl 6.
harmil masak: well, just for starters, the idea of a bit of code that can be optimized into zero instructions at an execution time that falls between parsing command-line options and executing the parser in a Perl 6-based compiler (including Perl 6 itself, of course). 22:07
masak you're still talking mostly features, not outcomes. 22:09
harmil masak: ur… I'm not sure that I want to re-hash the conversation that got us here. Can I just say "conditional warning messages based on command-line flags that consume zero execution time during the rest of program execution"? 22:11
sorear harmil: if you used if-statements instead of macros, it would be a net savings. 22:12
masak maybe I should just go back and read the backlog, then.
anyway. good night, #perl6. see you tomorrow. 22:13
harmil sorear: how would if statements be a net savings? They take time to execute, so the net cost is the execution time of a conditional test (and associated lookup of all pertinent state)
masak: later! 22:14
sorear harmil: they won't be executed very many times 22:15
sergot good night! o/ 22:17
harmil They won't? I'm pretty sure that's not knowable. If the if statement occurs in a test that happens as part of a rule (e.g. to test for whitespace at the start of a user-defined rule from the parser) then they might be executed thousands of times while parsing one program and that parse might happen many times at run-time in eval-type statements. The cost of expanding compiler complexity is always very high, no?
22:17 sergot left
flussence suggests doing something like metacpan.org/module/ifdef 22:17
22:18 birdwindupbird left
harmil flussence: that's not necessary if you have macros, but our problem is that rakudo is compiled before you get to it. 22:19
You can't do that trick on an already compiled program.
sorear harmil: every serious lisp implementation has a lower level of code than the levels macros work at 22:20
they just hide it from you.
harmil sorear: you're right, but Lisp accepts the burden of keeping s-expressions around at all times. Perl has not (yet?) made that committment. 22:21
22:21 tyatpi left
harmil So, the "lower level" you're talking about can always walk back up a level and re-build itself. 22:22
I have a friend who works on SBCL professionally. I've seen the damage this does to a mind ;-)
sorear that's sort of a direction I'm trying to go with niecza 22:24
anways, if $GLOBAL::warn_on_features_201206 takes around 100ns on niecza 22:25
harmil interesting… well, I'll be interested to see how it works out. Let me know if you feel brain damage setting in ;-)
sorear even "thousands of times" you're still talking under a millisecond
swapping out ASTs at compiler startup time is probably expensive enough to counter thousands of ifs
harmil sorear: I understand that it's a small cost, but small costs add up and if many of them can be removed at something that's almost but not quite "run time" then the savings is potentially disgustingly large. 22:26
sorear harmil: if you want disgustingly large, look at the costs of constructing AST nodes 22:27
harmil I'm reminded of a talk that Larry gave once at MIT. He spoke about Perl in general ways, but got specific about the limitations that the language had because startup time had to be sufficiently fast for shell scripts and Web servers to treat invoking the compiler as a relative noop
sorear: True, but I think that's a cost that we cannot avoid. There's no way to optimize those away, but I definitely feel the cost of adding lots of debugging to my grammars, and it would be nice if I could remove that cost when not debugging, not just make it "small" by putting if statements in there. 22:29
anyway, back to work 22:30
23:02 tyatpi joined 23:18 adu left 23:19 cognominal left, whiteknight joined 23:20 whiteknight is now known as Guest34089 23:21 cognominal joined 23:24 seldon left 23:37 fridim_ joined 23:50 skids joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!