00:00 zostay left 00:02 zostay joined 00:19 kanru joined 00:22 jfredett joined 00:23 Limbic_Region joined 00:26 elmex left 00:30 _Chillance_ left 00:34 ting left 00:50 bacek joined 00:53 lunatic joined 00:57 apeiron joined 01:05 apeiron_ left 01:06 Lorn joined 01:32 Alias_ joined 01:40 Lorn left 02:11 lunatic left 02:13 Alias__ joined 02:14 bacek left 02:16 bacek joined 02:30 Alias_ left 02:33 sri_work left
ruoso realises that he's working too much when he unconsciously types __HELP__ when he was trying to type __END__ 02:52
ruoso sleep & 03:02
03:02 bacek left, bacek joined 03:06 BinGOs left 03:20 Limbic_Region left 03:22 spinclad joined 03:24 BinGOs joined 03:33 xuser left, xuser joined 04:13 alanhaggai joined, Alias_ joined, Alias_ left 04:28 alanhaggai_ joined 04:33 alanhaggai left, alanhaggai_ is now known as alanhaggai 04:34 bacek left, bacek joined 05:20 Psyche^ joined 05:31 dr_df0 joined 05:37 Patterner left, Psyche^ is now known as Patterner, dr_df0 left 06:01 zamolxes left
TimToady @tell pmurias yes, void context is a special kind of scalar context, and map/for both eagerly return a list object in scalar context (lazily in list context), and either can be used only for its side effects; they are isomorphic. see S04:279 06:10
lambdabot Consider it noted.
TimToady @tell pmurias a useless-use-of warning results if you use a non-side-effective operation within either map or for in void context, but the map/for don't themselves care 06:13
lambdabot Consider it noted.
TimToady @tell pmurias and of course, the array object need not actually be constructed if it is known that void context will throw it away; in fact, it may well be the void context optimizer that emits the warnings about useless-use as it propagates void context inward 06:21
lambdabot Consider it noted.
06:22 Ehtyar joined
TimToady ruoso: see above 06:26
06:33 ashizawa joined 06:45 BinGOs left 06:57 alanhaggai left 07:02 BinGOs joined 07:12 iblechbot joined, drbean left
moritz_ good morning 07:20
does anybody know how I can submit a link to the perl section of reddit?
07:21 cosimo joined 07:22 pmurias joined 07:23 pmurias left 07:43 barney joined
pugs_svn r22080 | lwall++ | [STD] fix enum parsing (again) 07:49
r22080 | lwall++ | [Cursor] minor speedups
07:54 penk joined 07:55 alanhaggai_ joined 07:56 alanhaggai_ is now known as alanhaggai 08:23 elmex joined
Ehtyar anyone know where to find a current pugs build for windows? 08:26
08:36 mtve left, mtve joined 08:40 viklund joined 08:50 jferrero joined
pugs_svn r22081 | moritz++ | [t] fixed use of do as a function in statements/redo.t 08:51
Ehtyar why do i get revision 16464 from svn and i'm seeing revision 22081 here? 08:54
moritz_ svn up -r 16464
but if you have a new ghc installed, the latest version *should* work 08:55
pugs_svn r22082 | moritz++ | [t] moved last.t and redo.t to spec/
Ehtyar on win32? 08:56
moritz_ I think so, yes
(but haven't tested)
Ehtyar so how can i checkout 22082? 08:58
up gives me no such revision
:S
moritz_ what does 'svn up' update to?
Ehtyar 16464
moritz_ which repository are you using? 08:59
(svn info; search for Repository Root)
Ehtyar svn.openfoundry.org/pugs/
lambdabot Title: Revision 16464: /
moritz_ use svn.pugscode.org/pugs instead
lambdabot Title: Revision 22082: /
moritz_ the one you use is outdated
Ehtyar ah ty 09:00
pugs_svn r22083 | moritz++ | [t] merged statements/grepa-and-sort-in-for.t into spec/S04-statements/for.t
09:02 Myoma left
Ehtyar ok, checking out latest, ty moritz 09:03
09:03 Myoma joined
pugs_svn r22084 | moritz++ | [t/spec] initialize a variable to make rakudo happy 09:03
09:05 zamolxes joined 09:06 Alias__ left
pugs_svn r22085 | moritz++ | [t] simplified blocks/recurse.t a bit, used is() instead of ok() 09:14
r22086 | moritz++ | [t] moved blocks/recurse.t to spec/ 09:19
09:22 preflex left
pugs_svn r22087 | moritz++ | [t/spec] recurse.t: use numeric comparison where appropriate, fudged for 09:23
r22087 | moritz++ | rakudo
09:23 kjeldahl joined 09:26 bacek left
pugs_svn r22088 | moritz++ | [t] moved blocks/pointy.t to spec/ 09:26
09:36 iblechbot left 09:50 preflex joined 09:52 barney left 09:58 drbean joined 10:12 drbean left 10:28 meppl joined 10:37 kowey joined 10:40 ruoso left 10:48 itz joined 10:55 sri_work joined, araujo left 11:10 charsbar_ left 11:14 charsbar joined 11:18 tessier__ left, tessier__ joined 11:35 BinGOs left 11:36 BinGOs joined 11:39 Lichtkind joined, BinGOs left, BinGOs joined 11:42 BinGOs left 12:06 BinGOs joined 12:07 alanhaggai_ joined 12:09 BinGOs left, BinGOs joined 12:11 BinGOs left, ashizawa left 12:19 BinGOs joined 12:22 alanhaggai left 12:25 hcchien left 12:28 alanhaggai_ is now known as alanhaggai 13:05 guest56801 joined 13:11 guest56801 left 13:42 charsbar left 13:54 charsbar joined 14:08 araujo joined, araujo_ joined 14:09 araujo_ left, araujo left 14:10 jiing joined, araujo joined, araujo left 14:12 araujo joined, araujo left 14:13 araujo joined 14:15 alc joined 14:16 wknight8111 joined 14:28 penk left 14:31 jferrero left 14:43 masak joined 14:46 iblechbot joined 14:51 hcchien joined 14:58 kowey left 15:09 awwaiid joined 15:18 wknight8111 left 15:36 zamolxes left 15:46 pmurias joined 15:56 iblechbot left, kanru left, wknight8111 joined 16:06 masak left 16:08 cosimo left, alc left 16:11 fronty__ joined, fronty__ is now known as Front_slash, Front_slash left 16:12 Front_slash joined 16:17 iblechbot joined 16:23 Bensawsome joined 16:26 rindolf joined 16:30 wknight8111 left 16:39 alanhaggai left 16:55 Bensawsome left 16:59 Front_slash left 17:06 [particle]1 joined 17:08 rindolf left 17:11 Chillance joined 17:13 alanhaggai joined 17:14 IRSeekBot joined 17:18 rindolf joined 17:25 [particle] left 17:41 rindolf left 17:42 simcop2387 left, simcop2387 joined
rakudo_svn r30688 | moritz++ | [rakudo] add recursion tests to spectest_regression.data 17:45
17:49 rindolf joined 17:56 rindolf left 18:00 rindolf joined 18:07 jan_ left 18:10 kjeldahl left, jan_ joined 18:13 jhorwitz joined 18:40 araujo left 19:07 ruoso joined 19:17 araujo joined 19:20 rindolf left 19:27 rindolf joined 19:38 larsen_ joined 19:47 araujo left 19:49 ruoso left 19:50 ruoso joined 20:05 dduncan joined, araujo joined 20:28 lisppaste3 left, lisppaste3 joined
pmurias ruoso: hi, turned out Array.map is enough ;) 20:46
lambdabot pmurias: You have 3 new messages. '/msg lambdabot @messages' to read them.
ruoso pmurias, yeah... I saw it...
it's weird to think that Array.Void() will eagerly evaluate a lazy array...
pmurias it will only extract it's side effects 20:48
20:49 jferrero joined
pmurias i'm convinced more and more that we should take the context is part of the method call route 20:50
ruoso hmm 20:52
I still can only think on contextual information as optimization...
moritz_ want() 20:53
ruoso want() is something that cannot always be answered, iirc
20:53 Auzon left 20:54 justatheory joined
moritz_ well, sometimes you have to fake answer 20:55
ruoso that's why I'd rather use lazy contextualization...
by calling methods on the returned value
(that's how "sub foo is rw" is implemented in SMOP, btw) 20:56
moritz_ that's the recommended approach, but not the only allowed
ruoso sure... that's why I think on "context on the stack frame" as optimization...
and that we could stick to method calls on the returned values for now...
pmurias shower& 20:57
ruoso because instead of doing if (want() ~~ Scalar), I can return an object that knows how to perform in the different contexts... 20:58
pmurias like Contextual::Return?
ruoso yeah 20:59
I think that should improve the overall lazyness of the code...
which IMHO, is a good thing... 21:00
21:00 apeiron_ joined
ruoso I could even think about dropping "want" entirely.... ;) 21:00
geez... have to run 21:01
ruoso home &
ruoso will backlog... as usual...
21:01 ruoso left 21:02 jhorwitz left 21:08 apeiron left 21:13 pmurias left 21:22 araujo_ joined 21:23 araujo left, araujo_ left, larsen_ left 21:26 araujo joined 21:30 araujo left, araujo joined 21:44 iblechbot left
pugs_svn r22089 | lwall++ | [STD] Add Bool::True and Bool::False as valid typenames 22:08
22:13 araujo left 22:29 rindolf left 22:32 araujo joined 22:46 ggoebel joined 22:50 jferrero left 22:55 wknight8111 joined 23:00 wknight8111 left 23:01 krunen left 23:02 krunen joined 23:09 Gothmog_ left 23:13 Gothmog_ joined 23:18 ruoso joined 23:19 wknight8111 joined
ruoso back 23:20
pugs_svn r22090 | lwall++ | [t] clean up various calls to try, system, etc 23:21
ruoso btw... if for returns the elements returned by each iteration... what is the difference from map? 23:31
pugs: my @a = for (1,2,3) { $_ * 2 }; say @a 23:32
p6eval pugs: OUTPUT[*** ␤ Unexpected "@a"␤ expecting "=", context, ":" or "("␤ postfix op␤ at /tmp/L16H25MEQV line 1, column 4␤]
ruoso perl6: my @a = for (1,2,3) { $_ * 2 }; say @a 23:33
p6eval rakudo 30693: OUTPUT[Statement not terminated properly at line 1, near "{ $_ * 2 }"␤␤current instr.: 'parrot;PGE::Util;die' pc 119 (runtime/parrot/library/PGE/Util.pir:82)␤]
..elf 22090: OUTPUT[Parse error in: /tmp/f7iVqGrfPJ␤panic at line 1 column 20 (pos 20): Statement not terminated properly␤WHERE: my @a = for (1,2,3) { $_ * 2 }; say @a␤WHERE: /\<-- HERE␤ STD_red/prelude.rb:99:in `panic'␤ STD_red/std.rb:355:in `eat_terminator'␤
..STD_red/std.rb:26...
..pugs: OUTPUT[*** ␤ Unexpected "@a"␤ expecting "=", context, ":" or "("␤ postfix op␤ at /tmp/1HLusRMsnQ line 1, column 4␤]
ruoso nobody seems to like the idea of "for" returning a list...
ruoso implementing "Void method for ($code)" in Array in the meanwhile 23:37
pugs_svn r22091 | ruoso++ | [smop] implementing the test for the "for" operator 23:40
23:45 xinming left
TimToady perl6: my @a = do { for 1..3 { $_ * 2 }}; say @a 23:47
p6eval pugs: OUTPUT[␤]
..elf 22091: OUTPUT[Useless use of multiplication (*) in void context at (eval 119) line 4.␤␤]
..rakudo 30693: OUTPUT[-1␤]
wknight8111 ...neither of those answers look right 23:48
TimToady well, at least that parses :)
you can't just use a statement where a term is expected
ruoso TimToady, but is there really a use to my @a = for?
I mean...
isn't that the use of "map"? 23:49
TimToady map is just another way to write the same thing
you'll note the args come in a different order
23:49 meppl left
TimToady map is even more redundant with list comprehensions 23:49
23:50 meppl joined
ruoso I know that it will benefit from optimizations depending on the context... 23:50
but it's a shame that it needs to be optimized... IMHO... 23:51
23:52 Chillance left
TimToady I'd much rather keep the semantics of statement for and modifier fo the same 23:52
*for
and modifier for is essential for list comprehension syntax
which has to return its values
ruoso and turn the "modifier for" into a map, actually 23:53
23:53 justatheory left
TimToady they're all maps, really 23:53
ruoso but a for that doesn't return is simpler than a map 23:54
I'm arguing that we should keep at least one option that simply doesn't return any value
TimToady I know you're arguing that, and I'm ignoring you. :) 23:55
ruoso he
:P
23:56 elmex left
TimToady void context propagation has to happen anyway--I don't really consider it an optimizaiton 23:56
*tion
23:57 Lichtkind left
ruoso alright... so for is just a synonym for map... and both are evaluated lazily... 23:59
TimToady in list context...
ruoso void context causes eager evaluation...