Camelia, the Perl 6 bug

IRC log for #perl6, 2012-07-06

Perl 6 | Reference Documentation | Rakudo | Niecza | Specs

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 fgomez joined #perl6
00:11 dalek roast: e2fb70e | pmichaud++ | S32-str/sprintf.t:
00:11 dalek roast: [sprintf]  Correct tests for %g, fudge %F for Rakudo (NYI).
00:11 dalek roast: review: https://github.com/perl6/roast/commit/e2fb70eaae
00:16 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
00:16 pmichaud i.e.,   %5.2g  means output a number with two significant digits
00:16 colomon but why doesn't that also apply to %e
00:16 colomon ?
00:16 pmichaud %e is the number of digits following the decimal point, iirc.
00:16 colomon or %f, for that matter?
00:17 pmichaud because with %e, we always know there's one digit before the decimal point.
00:17 pmichaud I think %g came much later from %e and %f
00:17 pmichaud originally %f was designed to say "in this many characters, with this number of digits after the decimal point".  Thus it gets trailing zeroes.
00:18 pmichaud But there wasn't a way to say "this many significant digits" -- that's the slot that %g files
00:18 pmichaud *fills
00:18 colomon rn: say sprintf("%5.2g", 31415345)
00:18 p6eval niecza v19-9-g4b9c017: OUTPUT«3.14e+007␤»
00:18 p6eval ..rakudo 6ec88f: OUTPUT«3.1e+07␤»
00:19 colomon rn: say sprintf("%5.2g", 31415)
00:19 p6eval niecza v19-9-g4b9c017: OUTPUT«31415.00␤»
00:19 p6eval ..rakudo 6ec88f: OUTPUT«3.1e+04␤»
00:19 colomon rn: say sprintf("%5.2g", 3141)
00:19 p6eval niecza v19-9-g4b9c017: OUTPUT«3141.00␤»
00:19 p6eval ..rakudo 6ec88f: OUTPUT«3.1e+03␤»
00:19 colomon rn: say sprintf("%5.2g", 31)
00:19 p6eval rakudo 6ec88f: OUTPUT«   31␤»
00:19 p6eval ..niecza v19-9-g4b9c017: OUTPUT«31.00␤»
00:19 colomon rn: say sprintf("%5.2g", 310)
00:19 p6eval niecza v19-9-g4b9c017: OUTPUT«310.00␤»
00:19 p6eval ..rakudo 6ec88f: OUTPUT«3.1e+02␤»
00:19 colomon rn: say sprintf("%5.2g", 311)
00:19 p6eval niecza v19-9-g4b9c017: OUTPUT«311.00␤»
00:19 p6eval ..rakudo 6ec88f: OUTPUT«3.1e+02␤»
00:20 pmichaud the "precision" modifier means different things to different conversions.
00:20 colomon yeah
00:21 colomon does it always default to 6 if not present?
00:21 colomon rn: say sprintf("%g", 31415)
00:21 p6eval rakudo 6ec88f, niecza v19-9-g4b9c017: OUTPUT«31415␤»
00:21 colomon rn: say sprintf("%g", 314155)
00:21 pmichaud it depends on the conversion.
00:21 p6eval niecza v19-9-g4b9c017: OUTPUT«3e+005␤»
00:21 p6eval ..rakudo 6ec88f: OUTPUT«314155␤»
00:21 colomon rn: say sprintf("%g", 3141554)
00:21 p6eval rakudo 6ec88f: OUTPUT«3.14155e+06␤»
00:21 p6eval ..niecza v19-9-g4b9c017: OUTPUT«3e+006␤»
00:22 pmichaud for e, f, and g, it's 6, yes.
00:22 colomon great
00:22 pmichaud for d, i, o, u, x, and X, it's 1
00:22 pmichaud (at least according to C)
00:24 pmichaud I'm being called afk -- bbl
00:31 tokuhiro_ joined #perl6
00:39 dalek niecza: 7559ad4 | (Solomon Foster)++ | lib/Printf.cs:
00:39 dalek niecza: Get %g format closer to correct.
00:39 dalek niecza: review: https://github.com/sorear/niecza/commit/7559ad4e86
00:48 colomon pmichaud++
00:58 colomon nr: say 1.exp
00:58 p6eval rakudo 6ec88f: OUTPUT«2.71828182845905␤»
00:58 p6eval ..niecza v19-9-g4b9c017: OUTPUT«2.7182818284590451␤»
01:03 scott__ joined #perl6
01:04 dalek roast: 8bbf6aa | (Solomon Foster)++ | S32-str/sprintf.t:
01:04 dalek roast: Add tests for default precision in floating point formats.
01:04 dalek roast: review: https://github.com/perl6/roast/commit/8bbf6aae1e
01:05 dalek niecza: 9c29580 | (Solomon Foster)++ | lib/Printf.cs:
01:05 dalek niecza: Get correct default precision of 6 for the sprintf floating point formats.
01:05 dalek niecza: review: https://github.com/sorear/niecza/commit/9c29580c08
01:06 sisar the f in sprintf means 'formatted'? What does the 's' stand for ?
01:06 sisar 'special' ?
01:06 flussence hungarian notation
01:07 sisar flussence: really? or are you kidding? /me is bad at detecting sarcasm sometimes :-)
01:07 sisar s/sarcasm/puns
01:08 flussence I really don't know, but it sounds possible
01:08 colomon string
01:08 sisar oh, ok.
01:09 colomon it's like printf, but it prints to a string.  sprintf
01:10 sisar colomon: ah. hmm, printf doesn't print to a string ? What does it print "to" ?
01:10 colomon stdio
01:10 sisar oh
01:10 colomon fprintf prints to a file.  sprintf prints to a string.  it all makes a certain Unix-y sense
01:10 sisar colomon++
01:12 sisar aha, http://en.cppreference.com/w/c/io/fprintf explains it all.
01:14 sisar btw, perl6 documentation like ^ would be nice and easy to read. Just saying.
01:39 colomon does throws_like count as two tests?
01:44 colomon apparently yes
01:51 dalek roast: 1a4be3d | (Solomon Foster)++ | S32-num/rand.t:
01:51 dalek roast: Fudge for niecza.
01:51 dalek roast: review: https://github.com/perl6/roast/commit/1a4be3dab5
01:58 colomon rn: say "\t".perl
01:58 p6eval rakudo 6ec88f, niecza v19-10-g7559ad4: OUTPUT«"\t"␤»
01:58 colomon rn: say "\0".perl
01:58 p6eval rakudo 6ec88f: OUTPUT«"\x[0]"␤»
01:58 p6eval ..niecza v19-10-g7559ad4: OUTPUT«"\x[]"␤»
02:00 colomon rn: say "\0".perl.eval.perl
02:00 p6eval rakudo 6ec88f: OUTPUT«"\x[0]"␤»
02:00 p6eval ..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…
02:02 colomon rm: say sprintf("%c", 1101).perl
02:02 colomon rn: say sprintf("%c", 1101).perl
02:02 p6eval rakudo 6ec88f, niecza v19-11-g9c29580: OUTPUT«"э"␤»
02:02 colomon rn: say sprintf("%c", 1).perl
02:02 p6eval rakudo 6ec88f, niecza v19-11-g9c29580: OUTPUT«"\x[1]"␤»
02:02 colomon rn: say sprintf("%c", 2).perl
02:02 p6eval rakudo 6ec88f, niecza v19-11-g9c29580: OUTPUT«"\x[2]"␤»
02:04 colomon oh, I think I introduced that bug!
02:12 dalek roast: 235d9e1 | (Solomon Foster)++ | S32-str/sprintf.t:
02:12 dalek roast: Add simple %x test that would have prevented my last nieczabug.
02:12 dalek roast: review: https://github.com/perl6/roast/commit/235d9e14e6
02:12 dalek niecza: f36d743 | (Solomon Foster)++ | lib/Printf.cs:
02:12 dalek niecza: Don't delete the leading zero in a hex number if the hex number is just 0.
02:12 dalek niecza: review: https://github.com/sorear/niecza/commit/f36d743e9a
02:14 fgomez joined #perl6
02:16 FireFly joined #perl6
02:30 tokuhiro_ joined #perl6
03:01 cognominal_ joined #perl6
03:42 Khisanth joined #perl6
03:51 thou joined #perl6
04:30 am0c_ joined #perl6
04:34 cognominal__ joined #perl6
04:35 sudokode joined #perl6
04:36 cognominal__ joined #perl6
04:37 telex joined #perl6
04:45 telex joined #perl6
04:58 kaleem joined #perl6
05:04 telex joined #perl6
05:08 birdwindupbird joined #perl6
05:10 gardnan joined #perl6
05:14 gardnan are there any other perl6 implementations other than rakudo, pugs, or niecza?
05:20 sorear those are the most complete ones.
05:21 sorear there are others, like yapsi, perlito, mildew/smop
05:21 gardnan thanks
05:36 fhelmberger joined #perl6
05:43 moritz \o
05:43 kaare_ joined #perl6
05:44 sorear o/ moritz
05:45 sorear colomon: which libraries were you having trouble with?
05:49 GlitchMr joined #perl6
06:03 kaleem joined #perl6
06:06 sisar joined #perl6
06:08 _jaldhar joined #perl6
06:12 seldon joined #perl6
06:15 kaleem joined #perl6
06:22 dalek doc: b63269b | moritz++ | lib/Signature.pod:
06:22 dalek doc: [Signature] talk about where-blocks; add some sub-headings
06:22 dalek doc: review: https://github.com/perl6/doc/commit/b63269b1cb
06:32 sudokode joined #perl6
06:36 dalek doc: 7f16b18 | moritz++ | lib/Signature.pod:
06:36 dalek doc: [Signature] explain passing of positional and named arguments; parameter aliasing and renaming
06:36 dalek doc: review: https://github.com/perl6/doc/commit/7f16b184e9
06:41 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:â�¤------> [32msub should-fail([33mâ��[31m$x is rw) { }; should-fail 5[0mâ�¤â�¤Unhandled exception: Binding '$x' in 'should-fail', cannot bind read-only value to is rw parameterâ�¤  â€¦
06:41 p6eval ..rakudo 6ec88f:  ( no output )
06:41 moritz niecza++
06:49 dayangkun joined #perl6
06:54 Gesh joined #perl6
07:05 brrt joined #perl6
07:17 araujo joined #perl6
07:26 kresike joined #perl6
07:27 kresike good morning all you happy perl6 people
07:30 fridim_ joined #perl6
07:31 felher o/
07:32 kresike felher, o/
07:34 araujo joined #perl6
07:34 felher oh, nice. [&func] got into spec some days ago. awesome :)
07:35 felher and we have spurt now <3
07:41 moritz now somebody just need to implement and test it
07:44 sorear niecza already has spurt
07:44 arnsholt spurt?
07:44 moritz spew, spit, writeall... opposite of slurp :-)
07:44 sorear niecza has had spurt since back when I thought it was spelled spew
07:45 arnsholt Right
07:47 felher I like spurt. I sounds a bit like slurp. :)
07:50 moritz but I disagree with the current spec
07:51 moritz it says it fail()s if the file already exists
07:51 moritz which is totally inconsistent with open()
07:51 moritz and one can :append, but there's no way to overwrite the file
07:51 moritz sorear: does niecza do it the same way?
07:51 moritz I mean, as now specced?
07:53 sorear I didn't actually read the spec
07:53 moritz :-)
07:53 sorear I didn't make it quite that insane, anyway :D
07:56 jnthn morning o/
07:56 moritz \o jnthn
07:57 felher o/
07:59 sorear o/ jnthn
08:04 masak morning, World. (and Grammar and Actions, too.)
08:04 moritz \o masak
08:05 masak moritz: :overwrite should be easy to add.
08:05 masak moritz: in what way is fail()ing inconsistent with open? ooc.
08:06 moritz masak: open() simply overwrites existing files
08:06 moritz much like the system call
08:06 felher o/ masak
08:06 sorear o/ masak
08:08 masak moritz: oh, you'd prefer that to be the default? hm.
08:09 moritz masak: yes
08:09 masak I can see the case for that.
08:09 moritz masak: also because not overwriting requires non-atomic operations
08:09 moritz (existence check followed by open)
08:09 masak would you like to have an option, something like the opposite of :overwrite, to make it fail() if the file exists?
08:10 moritz I personally don't need such an option
08:10 masak ok.
08:10 moritz but I'd prefer it to what is specced now
08:10 masak :)
08:10 moritz :preserve maybe?
08:10 moritz or :createonly
08:11 masak :new :)
08:11 moritz :youthinkthisiscutetoday :-)
08:12 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.
08:12 masak it's not an old file, which is getting replaced. it's a new one, written now.
08:13 moritz masak: yes, :new is good
08:13 masak \o/
08:13 * masak changes the spec
08:17 dalek specs: 4137ad6 | masak++ | S32-setting-library/IO.pod:
08:17 dalek specs: [S32/IO] spurt now overwrites by default
08:17 dalek specs:
08:17 dalek specs: It fails on existing files only if you pass it the new `:new` option.
08:17 dalek specs: review: https://github.com/perl6/specs/commit/4137ad6cf7
08:21 masak agreed, the http://en.cppreference.com/w/c/io/fprintf documentation is seriously nice and clean.
08:25 dalek rakudo/nom: 737fb0f | moritz++ | src/core/IO.pm:
08:25 dalek rakudo/nom: [IO.open] make the $path optional
08:25 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/737fb0f563
08:25 dalek rakudo/nom: b1aa031 | moritz++ | src/core/IO.pm:
08:25 dalek rakudo/nom: [IO] implement sub form of spurt
08:25 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b1aa031fa4
08:26 moritz so, what should happen if .spurt on a file handle that has been opened for reading? fail()?
08:27 masak what happens if you do it with open()?
08:27 sorear .spurt doesn't make any sense on file handles
08:27 sorear only paths
08:28 moritz hm, right
08:28 moritz so IO::Path should have one
08:28 moritz but not IO
08:28 masak +1
08:28 moritz oh, and did I mention that I want to rename IO to IO::Handle?
08:28 sorear +\infty
08:29 moritz it means well have to change the $str.IO ~~ :e   pattern
08:29 moritz I'd like to change it to  $str.path.e
08:30 moritz oh, and I want to create long names too
08:30 moritz .exists in addition to .e
08:35 masak yes, please rename IO to IO::Handle.
08:35 * masak commutes
08:36 sergot joined #perl6
08:36 sergot morning o/
08:37 felher o/
08:37 Timbus <moritz> I'd like to change it to  $str.path.e
08:37 Timbus yessss
08:37 Timbus yes this is a good thing
08:39 moritz seems I'm The Big IO Changer these days
08:40 Timbus some have greatness piped into them
08:44 * moritz doesn't
08:51 baest joined #perl6
08:51 PZt joined #perl6
08:57 tadzik home! \o/
09:02 am0c_ joined #perl6
09:09 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
09:10 tadzik start naming them after animals
09:10 tadzik or star wars characters :)
09:11 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:12 sisar tadzik: :-) I would like that, but I'm not the only one who will read/use this code.
09:13 sisar so I need to come up with "meaningful" and "descriptive" names. :/
09:14 tadzik :)
09:16 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 baest_ joined #perl6
09:16 moritz well, if you happen to program in TCL... :-)
09:17 sorear sisar: std::pair
09:17 sisar moritz: sorry, what about TCL ? I'm not familiar with TCL syntax/stly of programming.
09:17 sorear sleep&
09:18 sisar sorear: wow, std::pair looks usable in my case !
09:18 sisar sorear: thanks ! and good nigth :-)
09:21 Timbus sisar, TCL is a string based language
09:21 Timbus you could almost call it truly homoiconic
09:21 Timbus but not really
09:22 sisar Timbus: oh. So how al numeric values are considered strings ? Then what happens to arithmetic ?
09:22 sisar all*
09:22 tadzik String Typing
09:23 tadzik I guess they're converted, like in Perl
09:23 moritz arithemtics convert to number and then back to string again
09:23 tadzik r: my $a = "5"; my $b = "7"; say $a + $b
09:23 p6eval rakudo b1aa03: OUTPUT«12␤»
09:24 sisar moritz++, tadzik++, Timbus++: thanks for explaining.
09:24 Timbus s'alright
09:27 kresike sisar, consider it a great opportunity for obfuscating your code :)
09:27 kresike sisar, that was for the var names from backlog
09:28 sisar kresike: yes it is an opputunity, provided that I myself don't get lost in the code  :-)
09:30 kresike by the time you get lost, you probably have to rewrite it anyway ...
09:51 dalek rakudo/nom: 501e8a2 | moritz++ | src/core/IO.pm:
09:51 dalek rakudo/nom: [IO] Add :new flag to &spurt
09:51 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/501e8a26ff
10:02 dalek specs/io-refactor: fb68e55 | moritz++ | S (2 files):
10:02 dalek specs/io-refactor: [IO] start IO refactoring with an overview over the new design
10:02 dalek specs/io-refactor:
10:02 dalek specs/io-refactor: The rest of S32::IO still reeks of over-engineering
10:02 dalek specs/io-refactor: review: https://github.com/perl6/specs/commit/fb68e5507b
10:02 dalek specs/io-refactor: 1aa555e | moritz++ | S32-setting-library/IO.pod:
10:02 dalek specs/io-refactor: bring some sanity to IO::Handle
10:02 dalek specs/io-refactor: review: https://github.com/perl6/specs/commit/1aa555e108
10:05 moritz IO refactoring TODO: describe IO::Path, IO::FileTests
10:05 moritz move everything into the correlection
10:06 moritz delete all the crap about IO::Readable, IO::Writable etc.
10:08 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?
10:09 moritz it might be
10:11 masak I think it is.
10:16 felher moritz: if you have a bit of spare time: https://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 felher If a nonzero imaginary part is the only way such a coercion can fail, the $.reason attribute should probably get removed :)
10:17 moritz other non-real classes might have their own reasons
10:17 moritz I think it looks good, at first glance
10:18 moritz will try to get more than a glance on it later (or over the weekend)
10:18 moritz felher++
10:20 felher moritz: okay. btw: I spectested it, and didn't introduce more failures. There were a bunch of old failures, though :)
10:21 felher +it
10:21 masak lunch &
10:22 felher i added the log to the gist
10:22 felher lunch &
10:25 Psyche^ joined #perl6
10:25 dalek specs/io-refactor: c2eea90 | moritz++ | S32-setting-library/IO.pod:
10:25 dalek specs/io-refactor: move &slurp and &spurt to functions; move file tests to IO::FileTests
10:25 dalek specs/io-refactor: review: https://github.com/perl6/specs/commit/c2eea90e22
10:47 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:49 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:53 hoelzro jnthn: so is it only for efficiency reasons?
10:54 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:56 hoelzro hmm
10:56 hoelzro could you give me a concrete example?
10:59 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".
11:00 spider-mario joined #perl6
11:02 hoelzro oh, I think I get it
11:02 hoelzro I think I just need more experience with more complex grammars
11:07 bbkr hoelzro: if you like p6 grammars but you still need to use p5 - there is http://search.cpan.org/~dconway/Regexp​-Grammars-1.016/lib/Regexp/Grammars.pm that offers a lot of syntax backported from Perl6
11:08 spider-mario_ joined #perl6
11:11 hoelzro bbkr: I've tried using Regexp::Grammars in the past; it's quite nice
11:11 hoelzro but I still have a lot to learn about grammars =)
11:12 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:27 arnsholt Oooh, the Rakduo build with --stagestats is pretty nice
11:29 arnsholt jnthn: *prod*?
11:33 DarthGandalf joined #perl6
11:34 jnthn arnsholt: ohhai
11:36 arnsholt After something of a hiatus, I'm trying to get back to Zavolaj hacking
11:37 arnsholt I'm looking at CStruct and thinking I can ditch the STRING array for embedded strings
11:38 arnsholt I think CArray did something similar that I killed after adding support for pointer-based objects
11:38 arnsholt Sound reasonable?
11:39 jnthn arnsholt: I guess we just create a new STRING * each time we're asked for the value?
11:41 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.
11:41 moritz r: say foo; say $*OUT.outs
11:41 p6eval rakudo 501e8a: OUTPUT«===SORRY!===␤CHECK FAILED:␤Undefined routine '&foo' called (line 1)␤»
11:41 moritz r: say 42; say $*OUT.outs
11:41 p6eval rakudo 501e8a: OUTPUT«42␤No such method 'outs' for invocant of type 'IO'␤  in block <anon> at /tmp/AROGWNqZkn:1␤␤»
11:42 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 #perl6
11:45 masak arnsholt++ # zavolaj hacking
11:47 jnthn arnsholt: OK, then it sounds reasonable.
11:53 pyrimidine joined #perl6
11:55 kaare_ joined #perl6
11:58 cognominal joined #perl6
12:08 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
12:09 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 masak rn: say ucfirst "aie!"
12:09 p6eval rakudo 501e8a, niecza v19-12-gf36d743: OUTPUT«Aie!␤»
12:09 * masak submits rakudobug
12:09 * masak submits nieczaissue
12:09 moritz I think I'll just unify them back into IO::Path, and have unsupported methods (like .open on a directory) fail
12:10 moritz masak: S32 is the newer one
12:10 masak yes.
12:10 masak that said, I think &titlecase is a poor substitute for &ucfirst, and I don't understand what's so useless about &ucfirst.
12:10 masak but the spec specs and I oblige.
12:10 moritz but I don't buy the "not useful under Unicode semantics" either
12:10 masak :)
12:10 moritz there are still many, many cases where even an ASCII-Only ucfirst can be useful
12:11 masak yes!
12:11 moritz even if it's just for compatibility with all the other "legacy" systems out there :-)
12:11 jnthn This feels like a pragmatism fail at first glance. :/
12:11 masak yes.
12:11 * moritz hopes we can change TimToady's mind
12:11 masak but I'm still submitting that rakudobug, because that's what the spec says right now.
12:12 moritz please also submit a specbug
12:12 masak ok.
12:12 masak submitting bugs, now that I can do ;)
12:12 dalek specs/io-refactor: 8082097 | moritz++ | S32-setting-library/IO.pod:
12:12 dalek specs/io-refactor: document IO::Path; move more stuff around
12:12 dalek specs/io-refactor: review: https://github.com/perl6/specs/commit/8082097aa4
12:12 moritz 1 files changed, 211 insertions(+), 309 deletions(-)
12:12 moritz looks like the right direction :-)
12:13 masak \o/
12:16 trist4n joined #perl6
12:21 masak rakudobug, nieczabug, and specbug submitted. all is well in the world.
12:21 moritz now fix 'em all :-)
12:23 masak I'd love to, but we have a strong TimToady dependency on the whole dependency tree of this issue.
12:23 masak he was the one deprecated ucfirst, he should have a say in defending that decision.
12:24 * masak has gotten in to the habit of deliberately dropping relative 'who' in sentences, and doesn't know why
12:25 masak rn: say titlecase "aie!"
12:25 p6eval rakudo 501e8a: OUTPUT«===SORRY!===␤CHECK FAILED:␤Undefined routine '&titlecase' called (line 1)␤»
12:25 p6eval ..niecza v19-12-gf36d743: OUTPUT«[31m===[0mSORRY![31m===[0mâ�¤â�¤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…
12:25 masak rn: say "aie!".titlecase
12:25 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…
12:25 p6eval ..rakudo 501e8a: OUTPUT«No such method 'titlecase' for invocant of type 'Str'␤  in block <anon> at /tmp/xeK3BTNWDI:1␤␤»
12:25 dalek specs/io-refactor: ce9cbc7 | moritz++ | S32-setting-library/IO.pod:
12:25 dalek specs/io-refactor: chdir, get, lines
12:25 dalek specs/io-refactor:
12:25 dalek specs/io-refactor: also remove more crazy stuff, and warn about the unreviewd stuff
12:25 dalek specs/io-refactor: review: https://github.com/perl6/specs/commit/ce9cbc72f5
12:25 masak mark one up for the argument "if we rescue ucfirst now and try to forget about titlecase, no ecosystem code will break" :)
12:26 cognominal joined #perl6
12:26 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:27 colomon TimToadynote that $s.lc.ucfirst is not capable of capitalizing correctly, since lc loses info needed to choose appropriate titlecase
12:27 colomon 17:41and lcfirst was always rather useless
12:27 colomon http://irclog.perlgeek.de/​perl6/2011-11-07#i_4673465
12:27 masak going the other way, hm, you'd have to extract the first word, titlecase it, and put it back.
12:27 masak colomon: thank you. colomon++
12:27 moritz masak: well, titlecase is more than just... what colomon pasted
12:27 masak ok, s titlecase has merit. but that doesn't mean ucfirst doesn't.
12:28 masak so*
12:28 moritz right
12:29 masak I agree lcfirst doesn't have much reason to exist.
12:29 masak nO-ONE wRITES lIKE tHIS.
12:29 masak um, hm. that would be untitlecase, I guess :P
12:31 moritz titleuncase :-)
12:32 * masak .oO( as a biologist, I read that as an enzyme that can splice titleunc ) :P
12:33 colomon the screen starting at http://irclog.perlgeek.de/​perl6/2011-11-07#i_4674253 seems to give the most useful explanation.
12:33 colomon crazily enough, the example implementation of titlecase depends on ucfirst.
12:33 masak ahahaha. *sob*
12:35 masak 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:
12:36 colomon 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'.
12:37 colomon uc translates to all uppercase
12:37 colomon ucfirst translates the first character to titlecase
12:37 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.
12:38 masak also, 'tc' is strangely consistent with 'tchrist' :P
12:38 moritz but, what I want to conver to upper (and not title) case?
12:38 moritz *what if
12:38 colomon you use uc
12:44 JimmyZ joined #perl6
12:48 colomon I think I see what TimToady was getting at.  http://srfi.schemers.org/srfi-​13/mail-archive/msg00046.html contains an interesting old (non-Perl) discussion on the subject.
12:49 colomon it seems like maybe what we really want is to have lc, uc, tc, and tcfirst?
12:50 masak \o/
12:50 masak on the face of it, that sounds very nice.
12:50 masak so tcfirst would replace ucfirst and make sense under Unicode?
12:50 masak and then the rest is just retraining all the programmers, and we're done? :)
12:51 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... )
12:51 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?
12:51 masak arnsholt: it's a very humbling experience, yes.
12:52 masak colomon: I... don't know.
12:52 colomon because $str.lc.tcfirst wouldn't work
12:52 masak why not? I haven't read the email thread yet.
12:53 masak 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.
12:56 colomon n: say "\x[1f3] \x[1f1] \x[1f2]"
12:56 p6eval niecza v19-12-gf36d743: OUTPUT«dz DZ Dz␤»
12:56 masak are you aware of any exam... is that an example?
12:56 colomon no
12:56 masak are you aware of any example?
12:56 colomon I'm not aware of an example, but I assume TimToady knows what he is talking about.
12:57 masak I feel I need concretitude.
12:57 colomon (That was an example of uppercase being different than titlecase.)
12:57 * masak .oO( I'm Concrete Man! I explain jokes! Get it? )
12:57 cognominal_ joined #perl6
12:57 masak only funny in Polish, apparently...
13:03 atrodo joined #perl6
13:04 * colomon is furiously researching...
13:06 tadzik :)
13:07 seldon joined #perl6
13:09 * moritz notices that some routines that are documented are missing from doc.perl6.org
13:10 moritz for example lc is there, but uc is missing
13:11 seldon In that particular case, that could be considered a feature.
13:11 moritz no no, uc hasn't been removed :-)
13:11 moritz and split is also missing
13:12 awwaiid joined #perl6
13:17 * 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:18 colomon maybe the functions should be lc, uc, tc, and tcfirstlcrest?
13:18 colomon err, probably better as tc-first-lc-rest
13:18 moritz .casefold($how)
13:18 moritz and how can be 'Tl' for 'title-case first, lower-case everything' or so
13:19 moritz probably a stupid idea
13:19 masak feels a little too strange.
13:23 * 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 colomon (ie I always use ucfirst on words, not on sentences)
13:25 moritz r: say Hash ~~ Cool
13:25 p6eval rakudo 501e8a: OUTPUT«True␤»
13:27 masak colomon: the thing that made me start talking about this was a similar case. I was doing ucfirst on single words. https://github.com/masak/crypt/commit/e478a​e2393329b113606eea037562ddce66e15fd#L0R435
13:27 masak 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.
13:27 colomon yeah
13:28 colomon hmmm...
13:28 colomon rn: say "\x[1f3]is test".ucfirst
13:28 p6eval rakudo 501e8a, niecza v19-12-gf36d743: OUTPUT«DZis test␤»
13:29 colomon so in fact, neither rakudo nor niecza implement the perl 5 'ucfirst is really tcfirst'
13:29 * masak is lost again
13:29 masak I should probably read the right source material to get this discussion.
13:29 colomon in (modern?) perl 5, ucfirst converts the first character of the string to titlecase
13:30 colomon not uppercase as the name would seem to imply
13:30 JimmyZ rn: use Test; say is.Cool
13:30 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 = { ... })␤»
13:30 p6eval ..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…
13:31 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)␤»
13:31 p6eval ..niecza v19-12-gf36d743: OUTPUT«[31m===[0mSORRY![3​1m===[0mâ�¤â�¤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:â�¤------> [32msay ord[33mâ��[31m.Cool[0mâ�¤â�¤Unhandled exception: Check failedâ�¤â�¤  at /…
13:31 JimmyZ LTA ?
13:34 JimmyZ std: say ord.Cool
13:34 p6eval std fd2647b: OUTPUT«[31m===[0mSORRY![31m===[0m�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:�------> [32msay ord[33m�[31m.Cool[0m�Check failed�FAILED 00:00 41m�»
13:36 masak JimmyZ: slightly. feel free to submit rakudobug.
13:36 skids joined #perl6
13:37 tyatpi joined #perl6
13:37 tokuhiro_ joined #perl6
13:41 * JimmyZ submitted
13:41 sergot left #perl6
13:41 sergot joined #perl6
13:41 masak JimmyZ++
13:41 jnthn Rakudo does pretty well there...it detects the issue at compile time :)
13:41 jnthn STD hardcodes an error for it in the parser.
13:42 jnthn Rakudo does almost as well with a purely general mechanism.
13:42 Moukeddar joined #perl6
13:42 countley joined #perl6
13:43 jnthn (Which makes me wonder if we can do some more general improvement. :))
13:43 Moukeddar left #perl6
13:44 bluescreen10 joined #perl6
13:46 dalek doc: 878b8be | moritz++ | htmlify.pl:
13:46 dalek doc: [htmilfy] debug mode, pod pretty printer
13:46 dalek doc: review: https://github.com/perl6/doc/commit/878b8bef75
13:53 moritz https://gist.github.com/306024
13:53 moritz (via twitter)
13:54 JimmyZ it's deleted
13:55 moritz sorry, cut the URL
13:55 moritz https://gist.github.com/3060244
13:55 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
13:57 moritz smash: well, you could redirect it to doc.perl6.org
13:57 smash moritz: fair enough
13:58 smash moritz: done
13:58 moritz smash++
13:58 mucker joined #perl6
13:58 moritz smash: if I come up with a better use case, I'll tell you
13:59 smash moritz: sure
14:00 [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:01 moritz [Coke]: right, I was more talking about the user-facing behavior
14:03 tokuhiro_ joined #perl6
14:05 [Coke] ah, yes, to the user, all scalars are the same time.
14:05 [Coke] *type
14:05 dalek doc: fe4e68d | moritz++ | htmlify.pl:
14:05 dalek doc: [htmlify] fix a pod dissection bug
14:05 dalek doc:
14:05 dalek doc: previously some routines (like uc, split) were not showing up in the index,
14:05 dalek doc: and no per-routine documentation was generated for them
14:05 dalek doc: review: https://github.com/perl6/doc/commit/fe4e68d428
14:06 [Coke] associative arrays are the only special type.
14:06 moritz just like you don't often see the dualvar nature of p5 scalars
14:06 moritz ttfn, decommute&
14:10 Slacky joined #perl6
14:11 pmichaud good morning, #perl6
14:12 smash pmichaud: mornin'
14:13 masak pmichaud! \o/
14:14 colomon \o
14:14 pmichaud ...why doesn't .spurt make sense on a filehandle, ooc?
14:16 * pmichaud reads backscroll
14:16 countley joined #perl6
14:21 PacoAir joined #perl6
14:21 adu joined #perl6
14:22 pmichaud ":new" as a flag name bugs me a bit for some reasons; probably too close to ".new"
14:23 pmichaud I might prefer :!overwrite
14:23 pmichaud or :!replace
14:23 flussence :clobber
14:24 pmichaud or yes,  :!clobber
14:24 pmichaud ...and perhaps there should be an equivalent flag to open
14:27 [Coke] :!smash!
14:28 masak :!clobber has the "flags shouldn't be True by default" design smell.
14:28 masak as do *all* the other proposed replacements. :)
14:28 timotimo :careful
14:28 masak :timid
14:28 pmichaud by that reasoning, spurt shouldn't clobber by default, then.  It's the most dangerous.
14:29 masak pmichaud: that's why I had it spec'd the way it was before the change today.
14:29 masak g'ah, you can't please everyone! :P
14:30 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?
14:30 hoelzro short of shelling out to Perl 5? =)
14:30 pmichaud hoelzro: not currently implemented in rakudo
14:30 pmichaud hoelzro: but see the :Perl5 modifier in S05
14:30 GlitchMr joined #perl6
14:31 pmichaud (I can't say "not yet implemented" because that flag _was_ once implemented in an earlier version of Rakudo :)
14:31 masak :)
14:31 masak NCI
14:31 hoelzro pmichaud: ah, thank you!
14:31 pmichaud masak: what about :noclobber then?
14:32 pmichaud it would also match the shell flag of the same name and purpose
14:32 jnthn :createonly
14:32 pmichaud :createonly works for me too
14:32 masak feel free to change it.
14:33 pmichaud how snarky do I get to be in responding to RT #114012 (ucfirst)?
14:33 PacoAir joined #perl6
14:33 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 masak pmichaud: you can apply any amount of snark, I probably deserve it one way or another :P
14:34 pmichaud masak: :-)
14:34 PacoAir joined #perl6
14:34 pmichaud if I do snark there, it's meant only as humor.  :-P
14:34 masak sure, sure!
14:34 masak :P
14:35 * 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
14:35 pmichaud right now I'm spectesting the deprecated ucfirst and lcfirst
14:36 [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))␤»
14:36 * pmichaud really likes the "is DEPRECATED" trait
14:36 thelazydeveloper joined #perl6
14:37 timotimo can you deprecate DEPRECATED?
14:37 pmichaud timotimo: of course!  Someday I hope it won't be all-caps.
14:37 pmichaud at that point DEPRECATED will be deprecated in favor of "deprecated"
14:37 timotimo :D
14:37 sergot left #perl6
14:37 timotimo role DEPRECATED is deprecated { ... } :)
14:37 sergot joined #perl6
14:39 seldon Five years later: role deprecated is obsolete { }
14:39 [Coke] keyword role is no longer hoopy;
14:40 colomon errr.... Rakudo has trait_mod:<is>(Routine:D $r, :$DEPRECATED!) but it doesn't actually do anything yet?
14:41 masak do anything? does it need to do anything?
14:41 pmichaud colomon: it doesn't do anything yet (more)
14:41 masak something is deprecated, that doesn't mean it has some behavior or other.
14:41 colomon masak: isn't it supposed to warn if you use it?
14:41 pmichaud I speculate we could have a dynamic variable that causes DEPRECATED-flagged routines to throw warnings or die if used.
14:41 [Coke] it should, eventually.
14:42 [Coke] 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.
14:42 masak "deprecated" feels more like a community annotation to me.
14:42 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
14:42 [Coke] this is mostly helpful in smart IDEs, though.
14:42 pmichaud I think tagging the routine itself as DEPRECATED is a lot nicer and more robust than having a # XXX: DEPRECATED comment.
14:43 pmichaud it also means that if you want to find all of the DEPRECATED stuff, you could just change the trait to fail
14:43 pmichaud or warn
14:44 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.
14:44 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.
14:44 pmichaud seldon: yes, thus "dynamic variable"
14:45 pmichaud seldon: dynamic variables allow one to control deprecation warnings at a scope level.
14:45 cognominal__ joined #perl6
14:45 seldon Ah.
14:46 masak is this the "dynamical at parse time equals lexical at runtime" equivalence?
14:46 arnsholt Hmm. Something's weird with my structs
14:46 pmichaud my $*DEPRECATION_WARN = 1;  ...;  {  my $*DEPRECATION_WARN = 0; ...; }
14:46 pmichaud deprecation warnings are enabled except within the block
14:47 pmichaud or something like that
14:47 dalek rakudo/nom: 5ee1f1e | pmichaud++ | / (2 files):
14:47 dalek rakudo/nom: Deprecate .ucfirst and .lcfirst, per the current synopses (RT #114012).
14:47 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5ee1f1e6dc
14:48 * arnsholt rebuilds stuff with -g
14:54 pmichaud updated RT #114012 :-)
14:56 * masak looks, curious
14:56 [Coke] # 07/05/2012 - rakudo++ (22775); niecza (89.98%); pugs (34.02%)
14:57 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:59 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
14:59 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.
14:59 pmichaud masak: we're in full agreement.
15:00 pmichaud 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
15:00 masak gosh, I hope not :)
15:01 masak it's more of a dynamic interplay between syns, STD, and spectests.
15:01 pmichaud S01 says so.  :-)
15:01 masak oh, ok.
15:01 masak hold on a minute :P
15:01 masak what do the spectests say about it? :P
15:02 pmichaud They agree with that.
15:02 masak how convenient.
15:03 pmichaud I agree fully about the dynamic interplay between syns, STD, and spectests.  But ultimately spectests controls.
15:05 masak there's something going on there that I can't quite put my finger on.
15:05 masak you're right in a way.
15:06 masak 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.
15:07 dalek nqp: f14191e | (Arne Skjærholt)++ | src/6model/reprs/CStruct. (2 files):
15:07 dalek nqp: Implement string members in CStruct repr'd classes.
15:07 dalek nqp: review: https://github.com/perl6/nqp/commit/f14191e7c4
15:07 masak right; this kind of bidirectional relation exists between a lot of the components.
15:08 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.
15:08 dalek zavolaj: 484fb91 | (Arne Skjærholt)++ | t/06-struct. (2 files):
15:08 dalek zavolaj: Add tests for strings in structs.
15:08 dalek zavolaj: review: https://github.com/jnthn/zavolaj/commit/484fb91a79
15:08 masak pmichaud: yeah, basically.
15:09 masak pmichaud: the spec is secondary from that point of view. but information still flows both ways.
15:11 sergot r: say 3, 6 ... * > 10;
15:11 p6eval rakudo 501e8a: OUTPUT«3 6 9 12␤»
15:11 [Coke] pmichaud: If you really feel that way about the spectests, you might want to look at the ones that rakudo isn't running.
15:11 [Coke] I think pugs is running a lot of those that rakudo isn't, and they might be a little... stale.
15:12 * [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"? :)
15:12 pmichaud sergot: ...^
15:12 pmichaud r: say 3, 6 ...^ * > 10
15:12 p6eval rakudo 501e8a: OUTPUT«3 6 9␤»
15:13 sergot pmichaud++, I forgot
15:13 sergot :)
15:13 sergot thanks
15:13 [Coke] pmichaud: and I of course don't mean you specifically, because I'd rather see you hacking on your grant. ;)
15:13 [Coke] How's that going, btw? ;)
15:14 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 pmichaud but giving my talks at yapc::na finally gave me a comfortable outline for the synopsis
15:15 pmichaud 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.
15:16 pmichaud [Coke]: that would be.... awesome.
15:17 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:18 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
15:19 arnsholt 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"
15:20 harmil 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
15:20 harmil ahah, thanks!
15:20 pmichaud there's also a $/.prematch for everything prior to the match
15:20 birdwindupbird joined #perl6
15:21 masak weekend &
15:21 * [Coke] suggests a format like this for the who's running what:
15:21 [Coke] NPR /path/to/file
15:21 [Coke] with spaces instead of NPR as appropriate.
15:22 pmichaud ...actually....
15:22 pmichaud I suppose I could run fudge with different options for rakudo, pugs, niecza, and then display the diffs :-)
15:23 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?
15:23 [Coke] or just file?
15:23 [Coke] not everyone does the "global fudge first" trick.
15:24 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.)
15:24 pmichaud yes, I'm thinking standalone
15:24 [Coke] that assumes that if an implementation runs a test, it passes it.
15:24 pmichaud of course, I'd need to know which files pugs is running
15:24 pmichaud if an implementation runs but fails a test, I do expect it to be fudged, yes.
15:24 [Coke] pmichaud: all three implementations use the same file to list that.
15:25 [Coke] pmichaud: even rakudo doesn't do that.
15:25 pmichaud [Coke]: it doesn't?  Then how do we get "all tests passing"?
15:25 [Coke] "rakudo",     22775,    23,   628,  1824, 25250, 24207
15:25 [Coke] I've been failing those 23 tests for months.
15:25 [Coke] you're not. I am.
15:26 pmichaud oh, can I get a list?
15:26 pmichaud is it in the gist?
15:26 * pmichaud looks
15:26 [Coke] one moment.
15:26 moritz pmichaud: re spurt on filehandle, becase you can simply .print a string to it
15:27 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.
15:27 [Coke] latest copies in http://feather.perl6.nl/~coke/
15:27 [Coke] http://feather.perl6.nl/~coke/rakudo_summary.out
15:28 alester joined #perl6
15:28 moritz pmichaud: basically, yes
15:28 moritz pmichaud: and if it also closes the handle (like the sub form does), it might be confusion
15:28 moritz *confusing
15:28 [Coke] Failure summary at the bottom.
15:28 * moritz afk again
15:29 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 pmichaud synonyms exist.  :-)
15:30 pmichaud [Coke]: so, looking at http://feather.perl6.nl/~coke/rakudo_summary.out, 15 of the failures are in S32-str/sprintf.rakudo ?
15:35 colomon pmichaud: only 51 tests, that's the version before you fudged it yesterday.
15:36 colomon right now it has 100+ tests
15:36 pmichaud colomon: I'm just asking if I'm reading the results correctly.
15:36 colomon pmichaud: ah
15:36 thou joined #perl6
15:37 pmichaud I'm trying to figure out how Coke++ could be seeing the failures when our "make spectest" command wasn't.
15:37 mikemol joined #perl6
15:44 pmichaud a-ha.  Rakudo fails the tests for %F, which weren't added until July 4th.
15:44 pmichaud so those 15 fails are recent.
15:44 [Coke] pmichaud: yes.
15:45 [Coke] 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.
15:45 [Coke] which tests they are come and go.
15:45 pmichaud [Coke]: oh, okay.  Essentially you're saying that the spectests aren't always perfectly fudged, then?
15:45 pmichaud I'm okay with that.
15:46 [Coke] pmichaud: running that by hand in my rakudo checkout dir, no failings.
15:46 [Coke] 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."
15:47 [Coke] 32 vs 64-bit.
15:48 [Coke] .. but those tests no longer seem to be failing.
15:50 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:56 [Coke] those are from the *(#$ utf8 handling.
15:56 [Coke] I can either 1) fudge those tests, or 2) re-enable the locale setting that enabled them to pass.
15:57 [Coke] 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 :)
15:57 kresike bye all
16:00 dalek Pugs.hs: c268bfa | coke++ | / (3 files):
16:00 dalek Pugs.hs: Revert "remove referencess to LC_ALL"
16:00 dalek Pugs.hs:
16:00 dalek Pugs.hs: This reverts commit 6272950693a604b1443c28b08870c42a52247879.
16:00 dalek Pugs.hs: review: https://github.com/perl6/Pugs.hs/commit/c268bfa3e4
16:00 [Coke] crud. I think I missed today's run by about 20s.
16:00 pmichaud [Coke]: no problem.
16:01 pmichaud [Coke]: I can wait until next week; I have other things to work on today anyway :)
16:01 [Coke] eh, just annoyed. ;)
16:01 dalek specs: 70c1b24 | pmichaud++ | S32-setting-library/IO.pod:
16:01 dalek specs: [spurt]:  s/':new'/':createonly'/  as suggested by jnthn++.
16:01 dalek specs: review: https://github.com/perl6/specs/commit/70c1b249af
16:01 [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.
16:02 pmichaud file and test number would be sufficient, although I recognize there would still be some mismatch.
16:02 pmichaud if switching the LC_ALL flag reduces a significant number of fails in Pugs, then the diff approach becomes more feasible again too
16:03 [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
16:04 [Coke] pmichaud: :P
16:04 [Coke] hater. :)
16:04 dalek roast: de9fa2b | pmichaud++ | S (2 files):
16:04 dalek roast: Unfudge now-passing file size tests.
16:04 dalek roast: review: https://github.com/perl6/roast/commit/de9fa2b5b9
16:07 [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:13 harmil You know you work in the right place when you routinely find yourself referencing the initialism "REPL" in office conversations...
16:28 fridim_ joined #perl6
16:48 jlaire joined #perl6
16:49 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....
16:50 harmil ick
16:50 harmil phenny: did you try the one from macports?
16:52 sjohnson sorear: hi
16:52 [Coke] harmil: phenny is a bot, telling sorear a message from colomon.
16:53 harmil oh, right, heh
16:53 [Coke] 1 todo: outdated semantics by Christmas -- pugs
16:54 harmil So, here's a fun debugging technique: rule term { [ <parentheticial> | <literal> | <variable> ] {debug "term {$/.keys}={$/.Str}"} }
16:54 harmil will print "term literal=5"
16:56 arnsholt harmil: Have you tried Grammar::Debugger and Grammar::Tracer?
16:56 harmil arnsholt: not yet
16:56 harmil I've been too busy debugging my grammar ;)
16:56 [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.
16:56 arnsholt Do. They're pretty awesome for figuring out what goes wrong in grammars
16:56 harmil I should
16:56 [Coke] I'll clean that up again this weekend.
16:57 [Coke] I know pugs is running fewer tests, but it's sooo much faster than rakudo. ;)
16:59 sorear I do not get https://github.com/sorear/niecza/issues/133
17:00 harmil I'm guessing that the concern is that mono dependency is icky? Dunno...
17:01 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
17:02 harmil ah, so is the claim that you always need mono, and not just "generic C#"?
17:05 sorear just made an inquisitive reply
17:05 sorear letssewhere that goes
17:05 harmil ha! I had my own tracing code and using Grammar::Tracer now makes my code throw an exception ;-)
17:10 fgomez joined #perl6
17:12 [Coke] +# 07/06/2012 - rakudo++ (22844); niecza (90.11%); pugs (38.95%)
17:12 [Coke] so, guess the 9% of passes on pugs is worth being stuck on linux until we get au back.
17:12 [Coke] phenny: au - come back to pugs, we miss you. ;)
17:12 [Coke] phenny: msg au - come back to pugs, we miss you. ;)
17:13 [Coke] phenny: tell au - come back to pugs, we miss you. ;)
17:13 phenny [Coke]: I'll pass that on when au is around.
17:13 [Coke] ETOOMANYBOTSYNTAXES
17:13 rjbs Coke's getting desperate
17:13 harmil [Coke]: I think that's just EBOTS
17:13 [Coke] rjbs: come hack on pugs, we miss you!
17:14 rjbs tempting :)
17:15 [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. ;)
17:16 [Coke] ugh. my oldest only has 3 years of HS left.
17:17 xinming_ joined #perl6
17:17 [Coke] rjbs++ # p5p wrangling.
17:20 rjbs One does what one can.
17:22 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 #perl6
17:27 seldon What does it mean when rakudo is confused?
17:27 flussence r: o_0?
17:27 p6eval rakudo 5ee1f1: OUTPUT«===SORRY!===␤Confused␤at /tmp/NfywfP3d3H:1␤»
17:27 arnsholt Parse error, essentially
17:28 seldon But there's only a comment in line 1.
17:29 moritz sometimes the line number is not quite correctly
17:29 moritz especially if rakudo is confused
17:29 seldon I see.
17:29 moritz maybe one of the following lines isn't propery terminated?
17:31 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
17:31 moritz r: module A { class B { } }; say 'Look? Fine!'
17:31 p6eval rakudo 5ee1f1: OUTPUT«Look? Fine!␤»
17:31 kaare__ joined #perl6
17:31 moritz seldon: if you nopaste the code somewhere, maybe I can spot the error
17:32 seldon Sure, just a moment.
17:33 dalek doc: 0fe1236 | moritz++ | lib/Signature.pod:
17:33 dalek doc: [Signature] parameter traits and modifiers
17:33 dalek doc: review: https://github.com/perl6/doc/commit/0fe1236535
17:35 seldon moritz: http://codepad.org/cMI5ziMJ
17:36 seldon The foo function works, but the FooType gives me trouble.
17:36 moritz Foo::FooType $f;
17:36 moritz should be
17:36 moritz my Foo::FooType $f;
17:36 seldon Ah. I feel very stupid now.
17:36 moritz I've made the same mistake quite a few times
17:37 moritz once you start typing your variables, you fall back to C/C++ syntax automatically :-)
17:37 moritz I even tried to declared sigilless variables that way
17:39 seldon Yes, language hopping is fraught with peril. I wonder what happens when I get back to my templates after coding perl6...
17:40 seldon I can just see myself writing template<@types> class foo { ... };
17:40 vmspb joined #perl6
17:51 topologist joined #perl6
18:02 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++.
18:03 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:04 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...
18:04 colomon yes, exactly.
18:04 arnsholt I frequently lament the fact that I'm not doing P6 when I'm doing P5 =)
18:05 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:06 colomon seldon: unfortunately, boost isn't really an option for me.  :(
18:06 seldon How you can write C++ without boost is beyond me.
18:08 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.
18:09 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.
18:10 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.
18:10 seldon ARGH!
18:10 colomon yeah, I ignored that bug report.
18:10 colomon :)
18:10 seldon You did the right thing.
18:13 arnsholt Discussions like this make me somewhat happy I'm in academia =)
18:13 arnsholt Just releasing code is worth brownie points ^_^
18:18 sisar joined #perl6
18:19 seldon What is the going rate for brownie points these days? :P
18:25 seldon My module works! \o/
18:25 * seldon does a victory dance.
18:25 [Coke] \o/
18:26 colomon \o/
18:27 * colomon wonders what seldon++'s module does....
18:27 pmichaud produces dancing ascii art?  \o/   \o_   _o_   !o!
18:28 seldon It's a brainfuck interpreter. I just made my little learning project into a module.
18:28 colomon brainfuck in p6?
18:28 pmichaud .oO( still no new yapc::na videos on youtube :-/ )
18:28 pmichaud I guess it was too much to hope for.
18:29 seldon Module: http://codepad.org/pr8hgOSB To be used like http://codepad.org/6rf2ozms
18:31 colomon seldon: now you need to add it to the p6 ecosystem... ;)
18:31 colomon ... and tests ...
18:32 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.
18:34 seldon I'll learn about module testing next, then.
18:34 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?
18:35 seldon self.x(), I think
18:35 moritz r: class A { has $.x is rw = True; method f() { say self.x } }; A.new.f
18:35 p6eval rakudo 5ee1f1: OUTPUT«True␤»
18:35 moritz seldon: no, works without
18:35 moritz harmil: do you happend to have another method named x?
18:36 moritz 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
18:36 * colomon forgot to listen carefully to Tom Steele once again...
18:37 * 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 ?
18:38 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
18:38 harmil let me throw it up in a gist
18:38 seldon It's in line 163, near the end. when $p.f { ...
18:38 moritz harmil: there's a command line opttion for less that makes it pleased
18:39 moritz 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 {
18:39 seldon That could be.
18:39 moritz in rakudo 2012.06, dir() returned strings
18:39 moritz it now returns IO::Path objects
18:39 moritz which have an .f method
18:40 seldon Is 2012.07 released yet?
18:40 moritz nope
18:40 pmichaud July 19ish
18:41 moritz harmil: less -R
18:41 harmil Thanks, that wasn't at all obvious ;)
18:41 pmichaud anyone have a command-line gist utility, ooc?
18:41 harmil I've been using less since the early 1990s and I had no idea....
18:41 pmichaud the one I was using (App::NoPaste) no longer works with gist.github.com  (they changed the API)
18:42 moritz harmil: it might not have had that option in the eary 90ies
18:42 moritz harmil: or maybe it had. No idea :-)
18:42 benabik joined #perl6
18:43 xinming joined #perl6
18:45 colomon pmichaud: if you find one, please share it, it's a great idea.
18:46 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 pmichaud I could switch to a different nopaste service, I guess.
18:47 seldon Is there an easy way to redirect $*IN to a string?
18:48 moritz seldon: my $*IN = (class A { method get { 'foo' } }).new # easiest case
18:48 moritz or whatever method(s) you use for reading from $*IN
18:49 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.
18:50 moritz in your case maybe
18:51 am0c joined #perl6
18:51 moritz class StringIO { has @.records; method read($|) { @!records.shift } };
18:51 sisar pmichaud: http://sprunge.us/
18:51 moritz and then  my $*IN.StringIO.new(records => [ ... ])
18:51 moritz erm sorry, |$ in the signature
18:51 moritz or $bytes or so
18:52 seldon Looks good. Thanks.
18:52 pmichaud sisar: looking
18:52 sisar pmichaud: oh, you want to paste to github. Sorry, i misread it as if you wanted a command line paste utility.
18:53 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 pmichaud oh, found the API!
18:54 pmichaud http://developer.github.com/v3/gists/
18:54 pmichaud okay, time to patch
18:55 harmil r: say /'(' ~ ')' 'b'/ ~~ '(b)'
18:55 p6eval rakudo 5ee1f1: OUTPUT«False␤»
18:55 harmil shouldn't that be True?
18:56 pmichaud smartmatch is backwards
18:56 harmil oh right
18:56 pmichaud r: say '(b)' ~~ /'(' ~ ')' 'b'/
18:56 p6eval rakudo 5ee1f1: OUTPUT«q[(b)]␤␤»
18:56 sorear colomon: ping
18:56 colomon sorear: pong
18:57 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:58 sorear https://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
18:58 colomon DTRT is does the right thing?
18:58 sorear yes
18:58 moritz harmil: they do
18:58 pmichaud harmil: they do.
18:58 harmil umm…
18:58 pmichaud r:  say '(b)' ~~ /"(" ~ ")" "b"/
18:58 p6eval rakudo 5ee1f1: OUTPUT«q[(b)]␤␤»
18:59 sorear harmil: I thik your shell is eating quotes.
18:59 harmil odd, my test didn't work. I must have done something wrong
18:59 pmichaud and double-quoted strings (are supposed to) interpolate like normal double-quoted strings (I think nyi in Rakudo)
18:59 sorear what was the command line?
18:59 colomon sorear++
18:59 harmil Ah, I had a rogue :
18:59 harmil damned backstabbing colons!
18:59 sorear colomon: it works for you?
19:00 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:
19:00 harmil 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)")
19:00 p6eval rakudo 5ee1f1: OUTPUT«#<failed match>␤»
19:00 colomon sorear: is stefanor you?
19:00 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
19:01 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
19:01 sorear colomon: yes
19:01 harmil shouldn't term try all alternations in parallel?
19:02 pmichaud the whitespace at the beginning of rule function prevents it
19:02 moritz (which is a known rakudo bug)
19:02 pmichaud well, as does the whitespace at the beginning ov variable, too
19:02 pmichaud so ltm is effectively disabled (rakudo bug)
19:02 harmil moritz: oh thank you! I was about to have an aneurism if that was intended behavior ;-)
19:03 harmil 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...
19:03 pmichaud harmil: I'm wanting to fix that but need to figure out the migration path for existing code.
19:03 pmichaud (as well as fix existing code.)
19:04 colomon sorear: hmm, http://xahlee.info/UnixResource_dir/_/ldpath.html
19:04 sorear colomon: setting DYLD_FALLBACK_LIBRARY_PATH would probably be safer
19:04 moritz usually one just adds a path to /etc/ld.so.conf
19:04 moritz runs ldconfig to update the cache
19:04 moritz and that's it
19:05 colomon moritz: /etc/ld.so.conf: No such file or directory
19:06 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"
19:06 sorear moritz: this is the Darwin dyld, not ld-linux.so.2
19:06 moritz sorear: :(
19:07 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
19:08 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 sorear 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
19:12 colomon okay, done, and it seems to work nicely.
19:12 colomon sorear++
19:13 jnthn evenin'
19:13 colomon \o
19:13 sorear o/ jnthn
19:13 moritz \o jnthn
19:14 harmil \o \o o/ o/ o/ \o \o jnthn  (doing the wave)
19:15 jnthn .oO( tsunamiest greeting ever )
19:16 pmichaud back from phone
19:16 pmichaud harmil: well, I'm wanting to think of rakudo as more than just 'alpha' status these days.
19:17 pmichaud 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?
19:17 pmichaud more than one
19:17 * colomon has to admit he has had that problem with rakudo this year...
19:18 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 pmichaud i.e., people who are also interested in teaching Perl 6 and building on ramps for it
19:19 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 harmil 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.
19:20 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?
19:20 moritz pmichaud: except prior notice
19:20 pmichaud moritz: yes, prior notice is one thing
19:21 pmichaud 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 pmichaud 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.
19:21 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.
19:22 pmichaud harmil: that's another way of telling people "don't use this until we set that tag"
19:22 pmichaud but most of the reason our standard library is changing is because people are using it and saying "that's not quite right..."
19:22 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
19:23 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
19:24 harmil 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.
19:24 harmil I think Perl suffers less from being alpha and more from many, many waves of premature enthusiasm over the past 10 years
19:25 pmichaud there are many intermediate stages between "alpha"  (which is effectively pioneers) and tags that encourage early adopters.
19:25 pmichaud without going all the way to "widely adopted"
19:25 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?"
19:26 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
19:26 masak nodnod
19:26 pmichaud keep in mind also that star doesn't have to closely track the compiler
19:26 masak I can totally see that you'd get those reactions, fwiw.
19:27 pmichaud anyway, "fix it regardless of what breaks"  is noted.
19:27 pmichaud afk for 15m
19:28 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 zby_home joined #perl6
19:29 masak agreed.
19:29 moritz well, but if we don't have stability, maintaining those will be a nightmare
19:29 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.
19:29 masak well, we've been saying "we should bolster the module/application programmer part of things" since 2009-ish.
19:30 harmil masak: yes, but it wasn't practical, then
19:30 masak it was less practical than today, for sure.
19:30 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
19:30 masak it gets easier all the time, much thanks to people who are already helping write infrastructural bits.
19:31 masak also, the ecosystem force-multiplies itself, like CPAN does.
19:31 sorear o/ masak
19:31 masak sorear: \o
19:31 harmil yep. Rakudo as it is today is about 90% of what I look  for in a "production ready" language.
19:31 harmil That last 10% is a real pain, though ;-)
19:32 masak please let us know about those 10%.
19:32 masak I was doing web development in 2008, when that ratio was reversed :P
19:32 * sorear wonders what niecza looks like under harmil's 100% objective evaluation
19:32 * masak .oO( get off my lawn! )
19:34 atrodo joined #perl6
19:35 * [Coke] continues to hiccup, violently.
19:38 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.
19:38 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).
19:39 masak harmil: cool.
19:39 sisar ++harmil
19:39 harmil [Coke]: I find that hiccups are cured by a gunshot wound to the chest. However, you may find the side effects daunting.
19:40 seldon How is niecza performancewise?
19:40 * harmil gets snarky in the face of health-related advice...
19:40 masak seldon: often faster at runtime. slower at startup.
19:41 masak 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?
19:42 masak that does indeed look a bit suboptimal.
19:44 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....
19:45 masak that explains it to me.
19:45 masak Grammar::Tracer is essentially wrapping another thing around your rule. it's an anonymous routine.
19:45 masak so the strange non-name you're seeing is that anonymous routine's.
19:46 pmichaud back again
19:46 pmichaud if after 8 years I'm still working on an "alpha" product... I need to do something else.
19:46 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?"
19:46 sorear pmichaud: we retired alpha in feb '10, remember? :D
19:47 pmichaud sorear: that's my recollection, yes.  :)
19:48 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?
19:49 masak what's the letter before alpha? :P
19:50 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 harmil "pre-alpha" is a commonly used term. Before that it's just "development"
19:50 masak harmil: I think the point is that these version superstition things don't have "a pretty clear meaning".
19:50 masak it's more like a cloud of meanings around each of these things.
19:50 * moritz has the feeling were' back to the discussions from '09
19:50 moritz *we're
19:51 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
19:51 masak oh wait, harmil is ajs...
19:51 harmil correct
19:51 masak right.
19:51 [Coke] sisar: diabetic, but thanks.
19:52 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...
19:52 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.
19:53 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!
19:53 pmichaud the "alpha" label refers to internal development and testing prior to any published releases
19:53 [Coke] pmichaud: just let us not fall into the trap parrot did.
19:54 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!"
19:54 moritz pmichaud: well, maybe the discussions recur, but the software is much further along
19:54 pmichaud [Coke]: oh, no risk of that.
19:54 harmil pmichaud: yes and no… typically alpha testing in large projects has some external buy-in. An invitation-only external group.
19:54 pmichaud harmil: I hope we're far beyond "invitation only", too.
19:54 [Coke] pmichaud: but that's exactly the sort of thing I'm gleaning from this conversation.
19:55 hoelzro is tadzik still around?
19:55 crab2313 joined #perl6
19:55 pmichaud [Coke]: I'm not saying "don't change anything", I'm saying "what's our process for change?"
19:55 hoelzro I have a question about MuEvent
19:55 harmil moritz: absolutely! We'll be having the "what stage of release are we at" discussion right up until 7.0  comes out! ;-)
19:55 moritz pmichaud: writing htmlify.pl for p6doc was a very nice experience
19:55 pmichaud there's no way I'm going to go for the silly "supported" versus "development" dichotomy
19:55 [Coke] hokay. as long as that process isn't too painful, sign me up.
19:55 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.
19:56 [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)
19:56 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_?
19:56 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?"
19:56 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.
19:57 moritz harmil: we can't nail the spec independently of implementations
19:57 masak hoelzro: please ask it.
19:57 pmichaud the specs and implementations must co-evolve.
19:57 harmil moritz: pmichaud: I'd agree witht hat
19:57 moritz harmil: that's waterfall model thinking, which hasn't been working for 40 years
19:58 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.
19:58 moritz harmil: I've worked on such a classification
19:58 pmichaud harmil: the leading whitespace bug is one of those "wasn't really stable" things.
19:58 moritz harmil: but never got very far
19:58 pmichaud and the ? quantifier has flipped back and forth at least twice
19:58 harmil Hmm… if we had some way to annotate the spec (perhaps in a Web edition) with bug reports… that might help a lot
19:58 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).
19:59 [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.
19:59 [Coke] so you can see what is tested (more likely to be solid) and which implementations are not fudging those tests.
19:59 moritz harmil: https://gist.github.com/2346494
19:59 harmil [Coke]: yes, but there's no indication of who passes, is there?
19:59 sorear making promises not to change stuff is the mistake Perl 5 made
19:59 moritz harmil: you can always annotate the specs from the outside. That'w what I've been doing there
20:00 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.
20:00 pmichaud and that the frozen spec will be a subset of what exists today.
20:00 [Coke] harmil: theoretically, if you're unfudged, you're passing.
20:00 harmil moritz: good stuff, but obviously very subject to bit-rot
20:00 moritz harmil: well, that's the case with any annotation
20:01 pmichaud "bit-rot" is the very definition of "not frozen"
20:01 hoelzro masak: it's about the licensing about MuEvent
20:01 harmil moritz: not if it's generated on the fly form bug reports and test results....
20:01 hoelzro I'd like to use it for a chat bot I'm writing
20:01 moritz harmil: we can't test the spec. We can only test implementations of the spec
20:02 [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?
20:02 pmichaud [Coke]: I'm primarily interested in 'star'
20:02 hoelzro harmil: I'd like to use tadzik's MuEvent for my chat bot, and I was wondering about the licensing
20:02 pmichaud since it's our recommended release
20:03 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
20:03 sorear harmil: it already is generated on the fly
20:03 moritz hoelzro: tadzik's other stuff is mostly MIT licensed
20:04 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?
20:04 sorear harmil: no, from changes to the spec repository
20:04 sorear harmil: bug reports can't be trusted
20:04 sorear harmil: sorry, from changes to the test repository
20:04 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 #perl6
20:05 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?"
20:06 harmil That's my off-the-cuff answer
20:06 [Coke] that way lies insanity.
20:06 harmil [Coke]: why?
20:06 pmichaud [Coke]: (that way lies Perl 6, actually :-)
20:06 [Coke] I would only do that for things that change in incompatible ways.
20:06 SHODAN joined #perl6
20:06 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?
20:06 harmil *abouyt
20:06 harmil bah
20:07 harmil [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.
20:07 harmil [Coke]: (not being angry, just emphatic)
20:07 [Coke] ah, I was responding to pmichaud's response above "if someone..."
20:07 harmil [Coke]: we were talking about pmichaud's fix for whtiespace at start of ruels
20:07 pmichaud as soon as possible, and with minimal disruption to existing code
20:08 pmichaud 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.
20:08 pmichaud actually, I don't mind having disruption that is more than minimal.  But I want disruption that is not beyond our users' expectations.
20:09 [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
20:09 [Coke] pmichaud: (users' expectations). The only user I know of who has expectations like that is no longer a user.
20:09 [Coke] hopefully you have more helpful data than I
20:10 pmichaud [Coke]: just to make certain I'm following accurately:  warn one release prior, then change in the next?
20:10 pmichaud (at least one release prior)
20:11 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:12 dalek star: 121678e | moritz++ | Makefile:
20:12 dalek star: HTTP::Easy is again maintained by supernovus++
20:12 dalek star: review: https://github.com/rakudo/star/commit/121678e349
20:12 dalek star: c1c1244 | moritz++ | Makefile:
20:12 dalek star: got back to using HEAD of several modules
20:12 dalek star: review: https://github.com/rakudo/star/commit/c1c12449b2
20:13 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.
20:13 harmil pmichaud: worthy
20:14 [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:15 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.
20:15 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.
20:16 [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*
20:16 moritz which is something we haven't really addressed yet at all
20:16 pmichaud moritz: yes
20:16 [Coke] moritz: ... eh. we don't have CPAN so everything is defacto core.
20:16 [Coke] I don't think all the modules shipped with * are really core, do you?
20:17 moritz [Coke]: they aren't. That's the point of a distribution though (shipping non-core modules)
20:17 moritz currently we only have two "core" modules in the p5 sense. Test and lib
20:17 [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.)
20:17 pmichaud at some point I'm hoping distributions will be more discriminating than what we've been in Rakudo Star thus far
20:18 pmichaud but distributions are where the "how stable do things need to be?"  decisions take place
20:19 * sisar is reading http://www2.tcl.tk/3018 titled: "everything is a string".
20:19 sisar Quite interesting.
20:19 cxreg a tiny vibrating string?
20:20 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 sisar cxreg: :D yes, superstings !
20:20 masak sisar: you can see much of the same mindset in Perl, especially Perl 5.
20:21 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.
20:21 sisar masak: *nod*
20:22 pmichaud many times the axiomatic choices made determine the possible world views that can result.
20:22 pmichaud harmil: thank you for your suggestions on the deprecation topic; it has been very useful to me.
20:22 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.
20:23 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 pmichaud phrased differently, is it problematic if 2012.07 star release uses the 2012.06 compiler?
20:24 moritz pmichaud: depends on your definition of "problematic"
20:24 moritz pmichaud: you'd have to ship old versions of ufo, panda, File::Tools and p6doc
20:24 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.
20:25 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 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?"
20:26 pmichaud harmil: it's a very difficult line, yes.  :)
20:27 [Coke] pmichaud: you would need to ask the users if that's helpful.
20:28 [Coke] 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)
20:28 [Coke] (I would just leave off the "don't upgrade" postscript.)
20:29 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 pmichaud yes, I can see potential problems with that (starvation)
20:29 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:30 [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
20:30 dalek rakudo/nom: 57eaaad | moritz++ | / (3 files):
20:30 dalek rakudo/nom: rename lib.pm to lib.pm6
20:30 dalek rakudo/nom:
20:30 dalek rakudo/nom: @VienosNotes on twitter had a build problem where a "use lib" in one
20:30 dalek rakudo/nom: of our perl 5-based build tools picked up the lib/lib.pm from Rakudo,
20:30 dalek rakudo/nom: and died.
20:30 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/57eaaada3a
20:30 [Coke] pmichaud: if it's /changed/, we can think about it. if we /broke/ something, our release process is wrong.
20:30 pmichaud I mean broke something in userspace code because of a change.
20:31 pmichaud 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?
20:31 [Coke] ah, that's what you said.
20:31 [Coke] so, "do we issue point releases to fix bugs?" sure.
20:32 pmichaud that's not exactly what I'm saying
20:32 harmil Hmm… how about an upgrade tool in every release?
20:32 pmichaud whenever we make a change, it's presumably to eliminate a bug (perhaps introduced by a spec change)
20:32 moritz harmil: what kind of tool are you thinking about?
20:32 pmichaud harmil: that presupposes we know everything that needs upgrading beforehand.  I don't think we're that prescient.
20:33 harmil moritz: a modified P6 parser that warns on possible upgrade problems and the versions they affect
20:33 harmil not a fixer, just a warning
20:33 harmil One nice thing about grammars is they're subclassable....
20:33 stepnem joined #perl6
20:34 pmichaud harmil: imo, developing those sorts of things _really_ slows down momentum
20:34 pmichaud because you spend a lot of time on the upgrade tool maintenance without actually knowing if they get used (or are really needed)
20:35 pmichaud 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?
20:36 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.
20:36 pmichaud harmil: my note about maintenance and momentum still holds in that case :)
20:36 harmil --expected-version=2012.05 or the like
20:36 pmichaud if we can do --expected-version=2012.05, that gets back to the "use v6" + version information described earlier
20:37 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 jnthn But it's (a) not perfect, and (b) fiddlier.
20:37 harmil pmichaud: yes but making it an optional command-line thing removes my concern about having "use v6" become obsolete
20:37 pmichaud and (c) how long do we keep it?
20:37 jnthn pmichaud: That too.
20:37 jnthn pmichaud: We're still accepting the old protoregex syntax, for example.
20:37 pmichaud oh, I'm fine with eliminating that, fwiw :)
20:37 jnthn <...> was {*}
20:37 jnthn *vs
20:38 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 pmichaud unless, of course, rakudo is using {*} still, in which case we need to get rid of those.
20:39 jnthn pmichaud: I'm worried about modules like, say, JSON::Tiny that may be using it.
20:39 jnthn (I dunno if it is.)
20:39 jnthn OK, it looks up to date in this case. :)
20:39 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")"
20:40 harmil 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
20:40 sorear rakudo SHOULD be using {*}
20:41 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.
20:41 pmichaud sorear: there was a {*} token that appeared within regex syntax
20:41 jnthn pmichaud: oh...I was referring to the one sorear is
20:41 pmichaud jnthn: okay, that one too :)
20:41 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.
20:42 [Coke] harmil: because we have to write tests to keep it working.
20:42 [Coke] and run those tests all the time.
20:42 harmil huh?
20:42 pmichaud and it could result in runtime overhead.
20:42 harmil what are you testing?
20:42 [Coke] harmil: that the feature/warning you wish to keep is not broken by some other change.
20:42 sorear pmichaud: fwiw, niecza is likely to soon get an extension to allow calling actions in the middle of rules.
20:42 harmil pmichaud: that's what macros are for, but I don't know if they're ready for prime time
20:43 harmil [Coke]: I think you misunderstood my intent
20:43 pmichaud sorear: ...will it be {*} perchance?  ;-)
20:43 [Coke] harmil: entirely possible.
20:43 pmichaud (since that's what {*} originally meant in regexes)
20:43 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.
20:43 sorear pmichaud: I was thinking {*IDENT}
20:44 * [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.
20:44 [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!)
20:45 pmichaud sorear: maybe <.ACT>  and <.ACT: key>   though
20:45 [Coke] at some point, the warnings should evaporate.
20:45 pmichaud although that's not quite right either.
20:45 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
20:45 pmichaud although <.ACT> works if we assume that it's a built-in method on cursors that invokes its corresponding action :)
20:46 [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 [Coke] we wouldn't want to /accidentally/ remove the warning or garble it, neh?
20:46 pmichaud if it helps to shorten the discussion, I don't plan to do any sort of a compiler version switch anytime soon.
20:46 [Coke] same way that we're stuck warning people about perl5ism forever. ;)
20:47 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.)
20:47 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.
20:48 [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:49 spider-mario joined #perl6
20:50 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?
20:50 [Coke] harmil: I'm not saying "just because".
20:50 harmil So, why is there "more testing" if you're just testing  your new change?
20:50 [Coke] ok. we have a case where we add this warning, deliberately, with support aforethought. I'm saying the warning needs to be tested.
20:51 [Coke] because you're testing the /feature/, and the /warning/, because you added the warning, not just the feature.
20:51 [Coke] I suspect we're at least tangentially in agreement here.
20:52 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:53 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
20:54 sorear 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)
20:55 harmil sorear: woah, wait… how is that the case?
20:56 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 pmichaud If it's not important enough to test, then you're saying it's okay if it's not there.
20:56 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....
20:56 pmichaud parse time is a part of our runtime, though.
20:57 pmichaud 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*
20:57 harmil sorear: in the real world, constant factors that matter are non-constant factors that are wearing a wig
20:57 pmichaud and if it's a function of the number of times a construct is used (like a regex), then it's not "constant"
20:58 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.
21:01 harmil 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 harmil how does that take time when we're parsing?
21:02 pmichaud I don't see what that is supposed to usefully produce.
21:07 * pmichaud returns to see if he can get App::Nopaste to work with gist.github.com again :-)
21:08 cognominal_ joined #perl6
21:09 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 sorear harmil: congratulations!  You just gave Rakudo a 5-minute startup time.
21:10 cognominal joined #perl6
21:10 sorear if you don't beleive constant factors matter, I don't know what to say
21:10 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:11 masak r: say 20_000 / 20
21:11 p6eval rakudo 5ee1f1: OUTPUT«1000␤»
21:11 masak yes.
21:11 masak :)
21:11 sorear a nonconstant factor slower would be a compiler that takes N * N seconds to compile N lines
21:11 [Coke] sorear: no need to snark.
21:12 masak lol, I blogged! \o/ http://strangelyconsistent.org/bl​og/july-6-room-descriptions-look
21:12 masak I again invite people to totally break the game in ways I haven't foreseen.
21:15 cognominal masak: parrot/nqp/rakudo sources are not mazes enough? :)
21:16 diakopter you are in a hierarchy of source files, all in slightly different DSLs
21:16 cognominal :)
21:17 masak cognominal: sir, are you seriously discouraging me from writing an adventure game in Perl 6? :P
21:19 cognominal masak: As long you don't ask me do rewrite it in coffeescript, I don't mind so much.
21:20 masak then I promise not to do that.
21:20 cognominal I tripped on that yesterday :(      http://www.mennovanslooten.nl/blog/post/62
21:22 masak cognominal: yeah, scope in JavaScript is busted. :/
21:22 masak "There's more than one way to do it. Your way is *wrong* [, JavaScript]."
21:22 cognominal TIMTOWTBI
21:24 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:25 bluescreen10 joined #perl6
21:25 cognominal Javascript got in 10 days all the cruft perl got in 20 years.
21:26 cognominal But doing it in 10 days is more god like, almost like the biblical 7 days
21:31 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:32 sorear mmg
21:32 sorear mmh
21:34 harmil http://en.wikipedia.org/wiki/MMH ?
21:36 sorear no, just a sound of consideration
21:36 masak I also thought it was a little too strawman-y.
21:36 sorear colomon: long-term best way would be to implement something in NieczaUCD.cs
21:37 harmil sorear: fair enough
21:40 harmil 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:41 harmil 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 harmil "crosses … bar" … "mixed … metaphor"
21:43 harmil Actually, now that I think about it, I think SBCL has something like that.
21:45 sjohnson eval: 3
21:45 buubot_backup sjohnson: 3
21:46 sorear harmil: I would not mind changed-feature notices as a courtesy
21:47 sorear 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 sorear the other question is 'who gets to define the versions'
21:47 harmil Ah, I take it back. It seems that's a generic common lisp ism, not specific to SBCL
21:48 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:49 sorear so then I think we're in broad agreement
21:49 harmil sorear: except now I want START macros ;-)
21:49 sorear sorry about the tension.
21:53 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 ;-)
21:53 masak harmil: they have all been applied when parsing is complete.
21:53 harmil masak: but start-time macros aren't ;-)
21:53 masak harmil: URL?
21:55 harmil I'm bordering dangerously on proposing a 7.0 feature, not suggesting existing definitions cover any such thing.
21:55 harmil Lisp has it, which makes it kind of attractive, but I understand it would be a massive change.
21:56 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.
21:56 sorear harmil: I think 'start-time' means something different in Lisp than it does in Perl 6
21:56 masak I mean, I know you can put things in START phasers....
21:58 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
21:58 harmil sorear: oh?
21:59 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
21:59 sorear START { foo } === state $run_foo; if (!$run_foo) { $run_foo++; foo }
21:59 harmil sorear: yes I know
22:00 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.
22:01 harmil 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:03 harmil 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:05 masak I'm not sure it's healthy to be wanting language features from other languages just for the sake of it. :)
22:05 masak show me what they enable instead, and we can talk about the means of getting the same results in Perl 6.
22:07 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:09 masak you're still talking mostly features, not outcomes.
22:11 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:12 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.
22:13 masak 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)
22:14 harmil masak: later!
22:15 sorear harmil: they won't be executed very many times
22:17 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 * flussence suggests doing something like https://metacpan.org/module/ifdef
22:19 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 harmil You can't do that trick on an already compiled program.
22:20 sorear harmil: every serious lisp implementation has a lower level of code than the levels macros work at
22:20 sorear they just hide it from you.
22:21 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:22 harmil So, the "lower level" you're talking about can always walk back up a level and re-build itself.
22:22 harmil I have a friend who works on SBCL professionally. I've seen the damage this does to a mind ;-)
22:24 sorear that's sort of a direction I'm trying to go with niecza
22:25 sorear 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 ;-)
22:25 sorear even "thousands of times" you're still talking under a millisecond
22:25 sorear swapping out ASTs at compiler startup time is probably expensive enough to counter thousands of ifs
22:26 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:27 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
22:29 harmil 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:30 harmil anyway, back to work
23:02 tyatpi joined #perl6
23:19 whiteknight joined #perl6
23:21 cognominal joined #perl6
23:37 fridim_ joined #perl6
23:50 skids joined #perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo | Niecza | Specs