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.
wolverian mncharity, are you sure = doesn't have a special meaning in YAML? it's a mistake to think YAML is simple.. :) 09:56
mncharity wolverian: if yaml is speced that foo: = means foo=>"=", but foo: "=" means foo=>foo, ... well, if it's not an implementation bug, it's a spec bug. :) 13:12
pugs_svnbot r20163 | putter++ | [STD_red_run] new --dump5 and --dump6, much faster than --yaml. 13:14
diff: dev.pugscode.org/changeset/20163
lambdabot Title: Changeset 20163 - Pugs - Trac
wolverian mncharity, true enough :) 13:15
pugs_svnbot r20164 | putter++ | [elf_a] Added "is A", "has $.x", "self". Switched STD_red_run to --dump5 from --yaml. 13:23
r20164 | putter++ | [elf_b] Added IR node classes. They compile.
diff: dev.pugscode.org/changeset/20164
lambdabot Title: Changeset 20164 - Pugs - Trac
mncharity btw, at least part of the problem with slow yaml dumping is it does many .inspect() calls on the tree. with a big tree, even a small constant non-linear task slows you. ir_nodes.p6 goes from ~80 s -> 15 s when Match's inspect() is intercepted. -> 6 s using --dump5 instead. Of which ~ 5 is the parse itself. 13:32
time ./elf_b_create.pl is taking me 9 s now, despite the addition of a 34kb 1.1klog elf_b_src/ir_nodes.p6 :) 13:34
*kloc 13:35
mncharity STD_red_run on ruby 1.8 is rather slower. 2 min. perhaps needs to be performance optimized. 13:40
mncharity I'm not sure whether to switch STD_red_run to #!/usr/bin/env ruby1.9 or not. env ruby will work out of the box for more people. and elf_a should run fine with it, though slower. but anyone wanting to develop elf_b really needs 1.9 (ie 2m vs 10s). maybe just a README note. 13:45
pmurias mncharity: i have ruby 1.9 under ruby and ruby1.8 under ruby 1.8 13:47
mncharity me too
pmurias it might make sense to keep the generated files in a different directory 13:54
mncharity which ones? 13:56
pugs_svnbot r20165 | putter++ | STD_red/README: Added '--yaml and its 1.9 patch are no longer required. STD_red_run's #! should find ruby 1.9 for speed'.
diff: dev.pugscode.org/changeset/20165
pmurias ir_nodes.p6 13:57
lambdabot Title: Changeset 20165 - Pugs - Trac
pmurias argh, network is so slow today it takes ages to install cpan modules here :(
mncharity could be. my thought was ir_nodes.p6 is actually source, even though it's generated. but it does clutter up the svn diff. 13:59
pmurias ./elf_a -x -o ./elf_b elf_b_src/ir_nodes.p6 elf_b_src/main.p6 takes 27sec here 14:01
mncharity why a different directory? even though I'm not sure it should be in svn at all - a tradeoff ("it's source, you can web link it" vs "obscures what humans edited").
pmurias is web linking to generated code important? 14:03
mncharity re 27 s, :/ could you check how long STD_red_run itself takes to do ir_nodes.p6? cd misc/STD_red; time ./STD_red_run -q --dump5 ../winter_jig/elf_on_STD_red/elf_b_src/ir_nodes.p6 > /dev/null 14:04
pmurias kp6 only stored the compiled files as a hack because compiling was slow 14:05
16sec 14:06
mncharity pmurias: makes it easier to say "could someone familiar with Moose take a look at svn.pugscode.org/pugs/misc/winter_j...r_nodes.p6 and say what a non-bogus version would look like?" but it turns out it *hasn't* been added to svn (yet?). 14:07
lambdabot tinyurl.com/2vbl86
mncharity so i guess the only issue is which directory. why a different directory? :) 14:08
pmurias mncharity: you can nopaste it 14:09
it's not really source
mncharity re bogus, my fuzzy understanding is Moose defines its own new(). but I'm unclear on its characteristics, and thus on whether we want to generate our own new-like method.
pmurias mncharity: Moose genereates it's own new 14:11
mncharity re "it's not really source", :) "is!" <rendered in pouty voice>. I tend to think of it as source written with the help of a script. but I can argue the other way too. :) 14:12
re Moose, right. but I was unclear from a quick skim of the docs whether its arguments were passed by name. I kind of like insulating the IR name choices from the ast_handlers by going via a positional new. 14:13
stevan__ yes they are passed by name
it will take either a regular hash or a hash-ref 14:14
mncharity thanks stevan :)
stevan__ mncharity: no problem :)
the Moose Cookbook is the best way to get to know Moose actually
mncharity so the bummer is I've another commitment today. back ~10 hrs. 14:15
possible next steps for elf include 14:16
teaching elf_b to run STD_red_run, and load its output into a Match tree.
not sure what else. 14:17
?
stevan__: is ~1sec a plausible ballpark startup up cost for using Moose? the code generated by elf_a is slower to start - wondering if a 1 sec hit is normal, or a sign the emitted code is doing something silly. 14:19
re elf_b and Moose new, perhaps the current method new should be renamed new2, and convert its positional args to Moose new's hash args. 14:23
stevan__ mncharity: ~1 sec startup is possible, if you have a lot of classes 14:24
like a real lot of classes
also autobox has an overhead to it 14:25
mncharity: make sure you are on the latest Moose and MOP too,.. some serious speed improvements in the last few months
mncharity then again, there will soon be emitter code which depends on IR node field names. so its only putting off the inevitable for a moment. kiss. => the unnecessary ir_nodes.p6 new()'s should be ripped out.
stevan__ mncharity: gimme a link to the file and I will take a look
mncharity looking... 14:26
svn.pugscode.org/pugs/misc/winter_j..._red/elf_b 14:27
another issue is whether has() vars can somehow be accessed as lvalues. so $self->x = 3 rather than $self->x(3). but if not, can deal. 14:28
I need to scurry. back briefy in ~20 min.
pmurias: are you all set? any questions or whatever before I go? 14:29
stevan__ no, lvalues suck in p5 14:30
basically un-usable for all but the very simplest accessors
mncharity: also, if you dont call Moose::Object::new then Moose wont initialize any of your attributes 14:31
mncharity doh, re elf_b, that wasn't the ideal code to point you at. could someone run elf_a -x -e 'say 3' output? my impression is that used to be 0.5 sec, now > 1 s. not sure why. 14:33
bbiab
mncharity stevan__: thanks for eyeballing elf_b. we'll discard the new()s. 14:47
re 'say 3' slowdown, that may or may not be a Moose issue. so perhaps save your time for later, once it's clearer. 14:48
re lvalues, ah, ok. good to know. will deal.
anyone/anything else before I pumpkin? 14:50
mncharity have a good day all & 14:55
moritz_ re 18:41
lichtkind TimToady: im now thinkin about to put also some of your last oscon talks into Perl6::Doc and i need your explicit permission to do that :) 18:54
TimToady lichtkind: is fine by me, as long as you don't quote me out of context except where I want to be quoted out of context... :) 19:05
lichtkind TimToady: no just whole perl.com articles naming you as author in the doc and scribes section of the module but there you are already since you author of some design documents 19:06
lichtkind TimToady: chromatic told me that i have to ask the authors too 19:07
moritz_ pugs: say %*ENV ~~ Hash 19:30
exp_evalbot OUTPUT[␤]
moritz_ pugs: say %*ENV ~~ Object
exp_evalbot OUTPUT[1␤]
moritz_ pugs: say %*ENV ~~ Array
exp_evalbot OUTPUT[␤]
moritz_ pugs: my @a; say @a ~~ Array
exp_evalbot OUTPUT[1␤]
moritz_ why isn't %*ENV a Hash? pugs error?
moritz_ pugs: my @a = <a b c>; say ~@a 19:35
exp_evalbot OUTPUT[a b c␤]
moritz_ pugs: my @a = <a b c>; say "a: @a" 19:36
exp_evalbot OUTPUT[a: @a␤]
moritz_ pugs: my @a = <a b c>; say "a: @a[]"
exp_evalbot OUTPUT[a: a b c␤]
TimToady moritz_: yes, probably pugs bug 19:38
moritz_ pugs: say %*ENV.perl 19:45
exp_evalbot OUTPUT[\undef␤]
moritz_ pugs: my %a; say %a ~~ Hash 19:46
exp_evalbot OUTPUT[1␤]
moritz_ it's a safety issue. I think %*ENV is "unsafe", and therfore it's not populated in the evalbot
moritz_ is the error variable in Perl 6 still $! ? 19:56
pmurias stevan__: why do lvalues suck? 20:06
isn't it possible to use tied variables?
or does performance suffer badly? 20:09
stevan__ pmurias: any solution which requires tie() is usually a bad idea :) 20:10
performance suffers, and its just ugly and difficult 20:11
the code to make it work that is
pmurias: several people have talked about writing support for it
stevan__ it would be a MooseX:: extension of the attribute meta layer, which itself is pretty simple,.. but I suspect people start actually looking at what would be needed to support it 20:12
"it" being the lvalue-ness
and they probably decide that its not worth it for the little bit of sugar 20:13
pmurias stevan__: nothing horribly complex in implementation terms 20:16
stevan__ on the Moose side no
the tie() side, I think gets really messy
pmurias why? 20:17
stevan__ one second, there is a CPAN module that does it 20:18
it should help illustrate
not with Moose, but for regular args
pmurias coded a simple tied accesor after i asked the question ;) 20:19
stevan__ pmurias: Attribute::Property does it,.. however their code is not that messy 20:20
the issue is mostly that you have to take all the Moose code that handles; types, triggers, laziness, etc etc and that has to get put into a tied variable
diakopter Perl 6 - the Cloying edition 20:21
stevan__ since once you return something from the lvalue sub it is completely out of your control
it just reallyrubs me the wrong way
and seems all kinds of backwards
vel am i wrong or there is perl6.exe.manifest missing for win32 build? 20:22
pmurias seen S06:314?
stevan__ pmurias: coded one for Moose? or just a regular one?
pmurias a regular one 20:24
stevan__ pmurias: actually you probably could avoid having to acount for the Moose lazy feature, but things like trigger (which fires after something is set) and types would need to be passed to the tied scalar 20:28
its not impossible
but as I said, it just feels wrong to me,.. not the correct division of responibilities 20:29
you are certainly welcome to write it yourself, but IMO the overhead alone is not worth it 20:30
and I certainly wouldnt want to have to bend the core Moose code to do it
pmurias stevan__: how do i change the attribute metaclass to be used? 20:33
stevan__ has 'foo' => (metaclass => 'My::Custom::Metaclass', ... );
thats on a per-attribute basis
for classwide
use metaclass (attribute_metaclass => 'My::Custom::Metaclass'); # must be done before use Moose though 20:34
hmm... looks like weak ref would also be a little tricky
like I siad though,.. its kind of backwards,.. these are things the class should deal with and know about, not the actual slot-value 20:35
which is what tie() would do
stevan__ pmurias: you could also ask around on #moose, someone might have a half finished implementation 20:37
pmurias stevan__: not having a real need for it
pmurias i think most of the issues could be doged by delegeting to a real attribiute metaobject 20:38
stevan__ pmurias: I dont think you can actually dodge them, but yes, if you delegate to the attribute meta, you would only need to pass one thing to the tie() 20:40
but you would end up incurring a number of other method calls to get tot he things you need
Moose inlines the accessors for speed
so that would be out the window 20:41
again, not that it cant be done, just annoying and tricky
and incorrectly inverts the responsibilities
can you tell I am not a fan or lvalue or tie :) 20:42
moritz_ we blame TimToady ;-) 20:43
pmurias stevan__: i think the tied aproach is the default perl6 one
PerlJam stevan__: Did I just see you make a comment about inlining for "speed"? And you're using perl?!? ;)
moritz_ perl6 and tie? did I miss something? 20:44
stevan__ pmurias: uhm, I hope not 20:45
although if you fix tie
then maybe
pmurias moritz_: a tie in disguise 20:46
stevan__ PerlJam: we generate an optimized version of the accessors and if you ask for it the constructors,.. speeds things up quite a bit :) 20:46
moritz_ pmurias: how would you do that? MMD?
stevan__ PerlJam: if you want to write the Inline::ASM version for me I would happily accept the patch ;)
IIRC, the perl 6 tie is really that Proxy object 20:47
pmurias yes
stevan__ I think the p5 tie is much uglier 20:48
pmurias moritz_: S06:314
stevan__: it's really easy to code Proxy if you want it
in perl
5
stevan__ pmurias: with tie? 20:49
:)
pmurias: honestly I am not missing it
moritz_ pmurias: ah, 'is rw'
pasteling Someone at 81.168.228.98 pasted "Proxy in p5" (32 lines, 654B) at sial.org/pbot/30628 20:50
pmurias stevan__: yes 20:51
pmurias moritz_: i think formats are the only feature realy removed 20:51
PerlJam stevan__: I haven't enough Moose juice to write such a thing, but would that someone did, it could get rid of the stigma of slowness that perl has upon its OOPy bits.
stevan__ PerlJam: have you seen nothingmuch's MooseX::COmpile work? 20:52
its slow, but coming along
err.. its going slow
the actual code it generates is comparable to hand coded p5 20:53
PerlJam no, I've been ignoring MooseX:: lately.
stevan__ PerlJam: fine, be that way,.. I thought you cared,.. but *sniff* apparently not *sniff* 20:54
PerlJam not enough time in the day to play with all of the interesting things out there *and* get work done for $dayjob *and* spend time with family :) 20:58
pmurias stevan__: it would be a fun SoC
PerlJam once I figure out how to integrate "fun stuff" with $dayjob, that will be a great day. 20:59
pmurias stevan__: would accesors in c be much faster the perl ones? 21:13
stevan__ pmurias: to some degree yes, konobi has experimented with converting the type constraints to C 21:20
and I know jjore was working on some benchmarks with different C based accessors, some that actually implemented their own opcode
lichtkind TimToady: thanks
stevan__ pmurias: the accessors Moose inlines only inlines as much code is needed for the accessor, a C version couldnt be as dynamic, so it would have to be able to handle all cases 21:21
but the excution itself would be faster

Powered by Cro and the Raku® Programming Language.

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

Thank you!