pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
mncharity had a < 2 sec startup. eh. are there other potential payoffs from mx::c? 00:01
hmm, I said eh, but once we start regularly running the test suite, that 2 sec may start to be a bottleneck, given STD_red parse caching. 00:03
bbl & 00:04
pugs_svnbot r20222 | lwall++ | [STD] was missing private method call using ! 00:43
diff: dev.pugscode.org/changeset/20222
lambdabot Title: Changeset 20222 - Pugs - Trac
meppl good night 01:44
mncharity g'night meppl :) 01:55
pugs_svnbot r20223 | putter++ | [elf_c] Forked a stable copy of STD_red (r20220). elf_c is now slushy.
diff: dev.pugscode.org/changeset/20223
lambdabot Title: Changeset 20223 - Pugs - Trac
Auzon What do you mean by slushy?
mncharity slushy is in between active and frozen. /me looks for good definition... 01:56
Auzon so maintained? 01:57
mncharity bbiam 01:58
mncharity back, 02:01
re maintained, yes. depends what you mean. with it's own copy of STD_red, it's only external dependencies are on perl and ruby. biggest risk there is ruby 1.9 over future releases. so relatively bitrot resistant. however, 02:03
s/ruby 1.9/ruby 1.9 drift/ 02:04
as it freezes, it is increasingly considered feature complete. bug complete too. the later both to focus development on HEAD, and so that people can depend on behavior not changing. 02:05
old elfs can be thought of as old svn revs, but more convenient because you can keep running them, and they've been tweaked to avoid rotting. 02:06
answered? 02:07
Auzon Very well, thanks :)
Auzon Have you done any benchmarking to see how much slower things get when adding another elf? If I remember correctly, that was a large problem with KP6. 02:08
mncharity not really. mainly just watching the self-compile time. 02:10
Auzon aren't you compiling each new version with the immediately previous version? 02:11
mncharity elf_b, the first bootstrapped elf, was significantly slower than elf_a. 10 sec vs 2? sec. and slower to start (2 sec vs noise). since then its been stable.
mncharity re compiling, no. generally, things start off with a version being compilable by itself and its predecessor. but elf_c for 02:12
instance became solely self-compiling. it could no longer be compiled by elf_b.
basically the tradeoff is between the additional hassle of being only self-compiling, vs the hassle of updating the predecessor sufficiently to keep compiling the new version. 02:13
Auzon oh, I see. So elf_c rolled in more changes than I expected 02:14
I just expected you to implement elf_{n} in elf_{n-1}, and anything past that point would go to elf_{n+1} 02:15
Auzon I must be going. It was nice to talk :) 02:17
mncharity one could, and end up with a chain. but it's not clear that buys you very much. if the environment breaks something, or a latent bug gets introduced but not noticed, you're not much better off if you have a chain than when you have a series of "releases". atleast while
mncharity the executable form is still so easily directly edited. 02:17
Auzon Makes sense :)
SamB what is this -- the demoscene?
mncharity re talk, indeed :)
SamB editing executables directly!
mncharity its just p5, and "looks almost like hand written" as well. 02:18
SamB oh
sorry, you kept using the word "elf"
that confused me ;-)
Auzon elf is the name of the interpreter/compiler/thing 02:19
mncharity ooohhhhh. drat. didn't think of that. bzzzt. unfortunate name collission
SamB hahahaha
Auzon At least you didn't pick gnome :P
mncharity think green hat, pointy ears, working with Santa
lol
SamB gnome would have been less confusing though
mncharity LOL :) # re gnome
SamB since GNOME has little to do with compilers
mncharity ah well. elf is all about making itself obsolete by allowing people to write _real_ p6 compilers. 02:20
mncharity name just has to survive some months. 02:21
mncharity anyone know state-of-the-art on p5 multiple dispatch? a quick microbench sugggests a simple method-call plus dispatch to sub in hash indexed by ref of first (well, second) argument wouldn't be significantly more expensive than a double method call. 02:23
mncharity (the double method call being what you pay in a single dispatch workaround "visitor" kludge) 02:27
hi stevan_ :)
stevan_ heya mncharity 02:28
mncharity and since we have control over the compiler, we can punt the arity check. go directy to method_foo_called_with_one_extra_dispatching_argument
stevan_: Moose have anything multiple-dispatchy I can use? :) 02:29
getting rather tired of fighting single dispatch, and watching it distort and complicate things. 02:30
as long as the cost is only ~3x or 4x that of a method call 02:31
mncharity oh, objective is multimethods rather than multisubs. 02:31
stevan_ nope, Moose doesnt even ry to go there 02:32
even LISP cant do it fast :P
mncharity so have time for the original method call, the final sub call, a couple of refs and other ops. maybe squeze in another sub call.
lol
stevan_ there is Data::Bind
mncharity different definition of fast though :P 02:33
hmm, Data::Bind...
Since having control of the compiler let's one play games one can't with a pure p5 module... hmm, maybe scavange Moose reflection stuff, so can easily say collect the set of named-for-easy-spotting multimethod subs from the inheritance tree, with the type constraints encoded in name perhaps, and then assemble the actual dispatchers from those. 02:36
re Data::Bind, interesting, but no. let's see.. 02:40
mncharity re LISP fast, but one of several advantages of perl of CL is never hearing "yes X would be nicely expressive and save you work, but we don't know how to compile it efficiently so you can't have it". :) 02:42
s/of/over/
sort of like haskell in that respect
re Moose and MMD, just having double dispatch, invocant and the first argument after that, would allow people to get away from single-dispatch visitor workarounds. hmm, as long as the inheritance tree is flatish. 02:45
though dameon(sp?) had a "use a regex to do type recognition" hack for some mmd module. wonder what that costs... 02:46
stevan_ mncharity: nothingmuch is working on something to do basic type based dispatching
mncharity ah, released?
stevan_ so loc(DateTime $x) will dispatch to loc_datetime($x)
mncharity oh, hmm. 02:47
stevan_ no, he is currently fighting the eurorail customer service nightmare I think
mncharity eep
stevan_ next week I think
cause we need it for $work stuff
it will be intentionally simplistic though
mncharity I'm thinking more multi method m(Int $i){3} aka multi method m ($self : $i ;;) {3} which could be compiled to sub m { my $self=shift; if(ref($_[0]) eq 'Int'){3} else {die} }. well, "could be", wouldn't want to. 02:49
multi method m (Int $n;; $none, $of, $this, $affects, $dispatch) { $hash_from_somewhere{ref($_[1]}->(@_) } 02:50
multi method m (Int $n;; $none, $of, $this, $affects, $dispatch) { goto $hash_from_somewhere{ref($_[1]}; } 02:51
err, ok, that was a bizarre mix of p6 and p5
multi method m (Int $n;; $none, $of, $this, $affects, $dispatch) {...} compiled to sub m { goto $hash_from_somewhere{ref($_[1]}; }
class X { multi method m (Int $n;; $whatever) { 3 } multi method m (Num $n){4} }; X.new.m(3); -> {package X; sub m { goto $my_hash{ref($_[1]}; }} 02:53
minor matter of collecting the info, and code generating(?) that sub. 02:54
:/ 02:55
mncharity but performance should be < 2 method calls. 02:55
or ~= 2 method calls anyway.
stevan_: any nice Moose infrastructure to ask "gimme a list of all the method names available for class X, directly or through inheritance"? 03:00
stevan_ Class->meta->compute_all_applicable_methods 03:01
returns an array of hashes with CODE ref, class name (i think) and method name
Class::MOP::Class has the docs
mncharity woot :)
many thanks 03:02
mncharity search.cpan.org/~stevan/Class-MOP-0...P/Class.pm 03:10
lambdabot Title: Class::MOP::Class - Class Meta Object - search.cpan.org, tinyurl.com/587e4q 03:11
pugs_svnbot r20224 | putter++ | [STD_red] "multi method ..." now parses. And <paramater>'s Match now includes quantchar.
r20224 | putter++ | [elf_d] That info is available in the IR.
diff: dev.pugscode.org/changeset/20224
lambdabot Title: Changeset 20224 - Pugs - Trac
mncharity thanks for the help stevan_. 04:47
good night all &
pugs_svnbot r20225 | putter++ | [elf_d] A crude start at multi methods. Dispatches on two parameters: the invocant, and the bare non-inherited typename of the first other parameter.
r20225 | putter++ | 'class A {multi method f(SCALAR $x){say "hi"~$x}; multi method f(ARRAY $a){say "ay"};}; my $a = A.new; $a.f(3); $a.f([]);' works. Likely little else.
diff: dev.pugscode.org/changeset/20225
lambdabot Title: Changeset 20225 - Pugs - Trac
spinclad mncharity: re 'bare non-inherited typename of the first other parameter': that sounds good, especially if you treat the hash as a cache as you meet new types and ask them various 'does' questions 05:37
pugs_svnbot r20226 | cosimo++ | [t/spec] var/type.t moved to S02 spec test. Hackaton! 11:01
diff: dev.pugscode.org/changeset/20226
lambdabot Title: Changeset 20226 - Pugs - Trac
pugs_svnbot r20227 | cosimo++ | [t/spec] Fudgified var type test 12:34
diff: dev.pugscode.org/changeset/20227
lambdabot Title: Changeset 20227 - Pugs - Trac
pugs_svnbot r20228 | cosimo++ | [t/spec] Moved var/autoref.t to spec S02/ 12:39
diff: dev.pugscode.org/changeset/20228
lambdabot Title: Changeset 20228 - Pugs - Trac
pugs_svnbot r20229 | cosimo++ | [t/spec] Fixed pod markup 12:45
diff: dev.pugscode.org/changeset/20229
lambdabot Title: Changeset 20229 - Pugs - Trac
pugs_svnbot r20230 | cosimo++ | [t/spec] autovivification test script moved to spec/S09 12:47
diff: dev.pugscode.org/changeset/20230
lambdabot Title: Changeset 20230 - Pugs - Trac
pugs_svnbot r20231 | cosimo++ | Now 'my Type $foo' is actually implemented 13:07
diff: dev.pugscode.org/changeset/20231
lambdabot Title: Changeset 20231 - Pugs - Trac
pugs_svnbot r20232 | cosimo++ | [t/spec] Added correct fudge directives according to current rakudo implementation status 13:25
diff: dev.pugscode.org/changeset/20232
lambdabot Title: Changeset 20232 - Pugs - Trac
pugs_svnbot r20233 | cosimo++ | [t] Fudgified test 13:32
r20234 | cosimo++ | [t/spec] Refactored control_flow/try.t tests under S04
diff: dev.pugscode.org/changeset/20234
lambdabot Title: Changeset 20234 - Pugs - Trac
pugs_svnbot r20235 | cosimo++ | [t/spec] Fudgified try.t spec test 13:35
diff: dev.pugscode.org/changeset/20235
lambdabot Title: Changeset 20235 - Pugs - Trac
pugs_svnbot r20236 | cosimo++ | [t/spec] Refactored some literal/unicode tests under S02/S29 15:02
diff: dev.pugscode.org/changeset/20236
lambdabot Title: Changeset 20236 - Pugs - Trac
pugs_svnbot r20237 | cosimo++ | [t/spec] Moved string tests under S29-str 15:14
diff: dev.pugscode.org/changeset/20237
lambdabot Title: Changeset 20237 - Pugs - Trac
pugs_svnbot r20238 | cosimo++ | [t/spec] Infinity tests moved to S02-builtin-types 15:20
diff: dev.pugscode.org/changeset/20238
lambdabot Title: Changeset 20238 - Pugs - Trac
pugs_svnbot r20239 | cosimo++ | [t/spec] Moved not/true tests under operators. Not sure about this. Should it be 'S03-precedence' ? 15:23
diff: dev.pugscode.org/changeset/20239
lambdabot Title: Changeset 20239 - Pugs - Trac

Powered by Cro and the Raku® Programming Language.

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

Thank you!