Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 23 December 2008.
tewk Coke: I'm cleaning up the class registry an your t/pmc/key.t TclProc test is coming back to haunt me. 00:01
Coke good luck with that. =-)
tewk This time it has to do with all the Namespaces,
Coke glad I got that test in. one less thing that is likely to bork tcl. =-) 00:02
compiling src/ops/core_ops_cgp.c is WICKED slow on this ole *bsd box.
tewk Why the '_Tcl' namespace and then 'tcl' namespace. 00:03
I just spent hours trying to figure out why TclProc lookup wouldn't work. 00:04
00:09 uniejo joined 00:10 AndyA joined
Infinoid 600 functions marked with headerizer asserts, 1200 more to go 00:10
Infinoid finds a place where string_make_direct() is called with a NULL charset
Coke tewk: 'tcl' is the parrot namespace that corresponds to the top level user-visible tcl namespace. 00:23
'_tcl' is the one that corresponds to the top level of a ``private'' namespace for compiler/interpreter builtins that aren't user-visible. 00:24
tewk what is _Tcl a typeo ?
Coke no. HLLs are case insensitive.
tewk that makes sense now,
Coke or, rather, if I do .HLL '_Tcl', that corresponds to an hll namespace of '_tcl' 00:25
tewk right
Coke tries to build parrot on 3 different machines. 00:27
nopaste "tewk" at 209.193.100.96 pasted "'TclProc' test change" (15 lines) at nopaste.snit.ch/15107
tewk Coke: does that look reasonable, thats how things will work after the class registry fix. 00:29
Coke I'm instantiating a namespace? 00:31
what if I try to instantiate a namespace that isn't actually a class?
tewk TclProc is a class no? 00:33
Coke (in general, I don't particularly care about the syntax, btw.
tewk ok
Coke Yes; what would happen if I did 'TclProcFoo' in that example, where i hadn't done a newclass?
tewk no your getting the TclProc from the namespace it was created in. 00:34
yeah you would get a namespace,
Coke I assume that's so parrot and the various HLLs will be able to have their own similarly named classes this way
?
tewk yes,
get_class is probably the better method, but that doesn't quite work yet. 00:35
Coke k. I'll probably wrap it up in a .macro anyway. (my defense against deprecation)
nopaste "tewk" at 209.193.99.80 pasted "'TclProc' test change attempt 2" (14 lines) at nopaste.snit.ch/15108 00:37
tewk Sorry it will look like this.
Coke wonders how much he'll fubar his *bsd sytem if he runs the system 'cpan'.
tewk: that looks slightly saner. 00:38
hurm. I wonder if it would be useful to make a tcltest option that caused it to generate TAP instead of the normal output. 00:39
(then I could use smolder.)
dalek r34528 | pmichaud++ | branches/rvar/languages/perl6/src (2 files): 00:47
: [rakudo]: Add 'readonly' property to parameters.
review: www.parrotvm.org/svn/parrot/revision?rev=34528
Coke removing experimental ops doesn't require updates to PBC_COMPAT, neh? 00:52
00:52 uniejo left
Coke is trac.parrot.org non responsive for anyone else? 00:58
Tene yes 01:00
dalek r34529 | coke++ | trunk (2 files): 01:01
: Remove the experimental 'slice' ops.
: (don't think we need to touch PBC_COMPAT for experimental ops.)
review: www.parrotvm.org/svn/parrot/revision?rev=34529
Coke I'll email the OSU admins. 01:02
pmichaud ...so trac.parrot.org is finally slower than rt? ;-)
Coke wow. it's almost taking as long to run cpan> i/TAP::Archive::harness/ on this bsd box as it did to build parrot. 01:06
Coke wonders if osu has something like log.perl.org 01:07
01:14 pedr joined 01:16 pedr left
dalek r34530 | coke++ | trunk/tools/dev: 01:16
: note what generates this generated file.
review: www.parrotvm.org/svn/parrot/revision?rev=34530
r34531 | coke++ | trunk (2 files): 01:18
: Avoid deprecated open modes (This allows the build to complete if they are removed.)
review: www.parrotvm.org/svn/parrot/revision?rev=34531
r34532 | pmichaud++ | branches/rvar/languages/perl6/src (3 files): 01:20
: [rakudo]: Add is rw, is copy traits to parameters.
review: www.parrotvm.org/svn/parrot/revision?rev=34532
01:26 pedr1 joined, pedr1 left 01:29 pedr2 joined, pedr2 left 01:32 leto joined
dalek r34533 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 01:33
: [rakudo]: Fix case where params have no explicit traits.
review: www.parrotvm.org/svn/parrot/revision?rev=34533
01:41 leto joined
Coke hurm. $P1 = open 'foo', 'a' doesn't seem to work. 01:42
is it intended that it has to be 'wa' ? 01:47
dalek r34534 | coke++ | trunk/t (10 files): 01:53
: Remove all deprecated open types from 'make test'
review: www.parrotvm.org/svn/parrot/revision?rev=34534
r34535 | coke++ | trunk (2 files): 02:01
: Remove [DEPRECATED] open file modes.
review: www.parrotvm.org/svn/parrot/revision?rev=34535
Coke msg allison Sent a mail to list about open mode 'a' vs. open mode 'wa'. 02:12
purl Message for allison stored.
dalek r34536 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 02:29
: [rakudo]: (simple) multisubs work again
review: www.parrotvm.org/svn/parrot/revision?rev=34536
02:31 tetragon joined
dalek r34537 | pmichaud++ | branches/rvar/languages/perl6 (3 files): 02:47
: [rakudo]: Complain about declaring a lexical twice in same scope.
: * Fix some double-declarations in 00-parrot tests.
review: www.parrotvm.org/svn/parrot/revision?rev=34537
03:09 zostay joined
dalek r34538 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 03:10
: [rakudo]: Restore type bindings (::T) in signatures.
review: www.parrotvm.org/svn/parrot/revision?rev=34538
GeJ nopaste ? 03:12
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
03:14 zostay_ joined
nopaste "GeJ" at 202.22.229.231 pasted "[open modes] Diff applied to "compilers/tge/tgc.pir" to fix build." (21 lines) at nopaste.snit.ch/15109 03:16
GeJ Coke: could you have a look at it if you have a few minutes? 03:17
Coke gej;looks good. you have a commit bit? 03:36
(oddly, my build doesn't break without that.) 03:37
dalek r34539 | coke++ | trunk/compilers/tge: 03:39
: Update mode usage for TGE.
: Courtesy GeJ++
review: www.parrotvm.org/svn/parrot/revision?rev=34539
GeJ Coke: nope. no commit bit.
thank you
Coke thank you. 03:40
I note that "examples_tests" is also borked if you're bored. =-)
(fixing that one now.)
GeJ Well, lucky you, I'm bored :)
03:40 kid51 joined
Coke oooh, really? danke. 03:41
Coke backs away from the examples/ directory.
kid51 trac.parrot.org/parrot/ is back on line.
GeJ hum, can't find . -name "*examples_tests*" though... 03:42
Coke it's a make target, sorry.
GeJ Ah ok... I'm on it.
Coke GeJ++
kid51 Coke: I don't see anything wrong with 'make examples_tests'. Are you talking about something other than top-level dir in trunk? 03:47
Coke kid51: yes, that's what I mean.
kid51 I just ran both 'prove t/examples/*.t' and 'make examples_tests". Setting aside TODOed tests, all tests passed. 03:48
nopaste "kid51" at 68.237.2.168 pasted "make examples_tests" (31 lines) at nopaste.snit.ch/15110 03:49
Coke kid51: what revision?
purl revision is 0, unless it's an svn co, then it's whatever svn reports
kid51 34497
Coke I'm sure it worked fine back then. =-) 03:50
03:50 rurban_ joined
Coke r34535 - Remove [DEPRECATED] open file modes. 03:51
dalek r34540 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 03:54
: [rakudo]: Restore placeholder vars.
review: www.parrotvm.org/svn/parrot/revision?rev=34540
Coke I wonder if there's a "fulltest" analog with just the one core. 03:56
dalek r34541 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 03:59
: [rakudo]: Restore .arity on signatured blocks.
review: www.parrotvm.org/svn/parrot/revision?rev=34541
kid51 Okay, I see the failures you were talking about.
nopaste "kid51" at 68.237.2.168 pasted "make examples_tests at r34539" (271 lines) at nopaste.snit.ch/15111 04:01
Coke ayup.
04:01 elmex_ joined
Coke should be a simple fix; GeJ is working on it now. 04:01
GeJ almost done
kid51 It's almost my bedtime, so I'm glad it's daytime for Gej to work on it ;-) 04:02
Coke =-)
kid51 Coke: Earlier today I posted about the non-working links here: www.parrot.org/docs/ 04:05
Do you know what the plan is to get them working?
Coke there's a ticket about that, neh?
kid51 checks
Coke ah. the original ticket was probably re: parrotcode.
(plan) ISTR particle is working on it.
basically: have a trunk/release version of the docs, and try to create them with "make html". 04:06
kid51 Woah: Trac problem: 04:07
Trac detected an internal error:
OperationalError: database is locked
There was an internal error in Trac. It is recommended that you inform your local Trac administrator and give him all the information he needs to reproduce the issue.
(Cleared up) 04:08
Coke Wow. it is more challenging to cpan install a module on this box than it was to build parrot. 04:10
(swap on this old machine hurts) 04:11
kid51 'make coretest' passes at r34539. 04:14
nopaste "GeJ" at 202.22.229.231 pasted "[open modes] fix `make examples_tests'" (101 lines) at nopaste.snit.ch/15112
GeJ I should note that I SKIP some GMP-related tests... 04:15
Coke if some committer would like to apply that, looks good here.
(I'm in the middle of something in my normal checkout dir0 04:16
GeJ so I may have missed some.
Coke gej;if no one gets to that, plz. open a ticket. I'm not sure I'll remember once I finish this task. 04:17
(or that I'll finish this task tonight)
GeJ Will do. Thanks. 04:18
dalek r34542 | jkeenan++ | trunk (6 files): 04:21
: Fix PIR used in 'make examples_tests' to reflect discontinuation of certain open modes. Patch courtesy of Geraud Continsouzas.
review: www.parrotvm.org/svn/parrot/revision?rev=34542
kid51 'make examples_tests' now PASS 04:22
GeJ Thanks kid51
kid51 Thank *you* -- that was fast work for that number of files.
kid51 must sleep 04:23
purl $kid51->sleep(8 * 3600);
Coke kid51++ GeJ++ 04:26
GeJ Coke: if there's anything else I can do. I still have some CPU cycles available.
Coke ack --parrot 'open.*[<>]' ? 04:27
(see if we missed any?)
dalek r34543 | coke++ | branches: 04:28
: Branch to remove store_global & find_global opcodes
review: www.parrotvm.org/svn/parrot/revision?rev=34543
r34544 | coke++ | branches/global_cleanup (4 files): 04:30
: Remove the opcodes themselves.
review: www.parrotvm.org/svn/parrot/revision?rev=34544
GeJ yup... found some. On it. 04:32
do the new modes also apply to PASM files? 04:36
Coke yup. 04:38
it's the opcode, so it's same on both. 04:39
Coke stares balefully at the ncurses library.
GeJ What are the new modes for '<>' and '+<' ? 04:41
Coke I'm assuming <> == rw
I think +< also means rw. 04:42
+> would mean something else, though.
guessing this based on the code removed in r34535 04:43
GeJ I got a hit in book/ch05_pasm.pod
it describes '+<' as read-write and '<>' as append.
Coke >> was append. 04:45
so replace <> with 'wa'
(fixing the typo)
and +< with 'rw'
GeJ noted. thanks 04:46
Hum, pdd22_io.pod defines : C<open> opcode: 'r' for read, 'w' for write, 'a' for append, and 'p' for pipe. (l 125-126) 04:53
Coke yup. but 'a' by itself is (currently) not enoughy. 04:54
I sent an email to the list noting that.
(when trac was down)
GeJ oh yes, I remember you mentioning that earlier.
GeJ should subscribe to The list.
dalek r34545 | coke++ | branches/global_cleanup/runtime/parrot/library (19 files): 04:56
: Fixup (just compiles, not tested) any _global variants needed to complete 'make'
review: www.parrotvm.org/svn/parrot/revision?rev=34545
GeJ rebuilding parrot with patches, restarting tests. 05:00
there's one file in pipp I'm not 100% sure about. And I probably b0rked the quine example. 05:01
Coke I hate that quine. :| 05:02
bah. I've borked test/builder/tester in the branch. 05:03
picked the wrong _global variant as a replacement somewhere. :|
dalek r34546 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 05:05
: [rakudo]: Clean up package variable vivification.
review: www.parrotvm.org/svn/parrot/revision?rev=34546
r34547 | pmichaud++ | branches/rvar/languages/perl6/src/classes:
: [rakudo]: Autovivify @!params in Signature.
review: www.parrotvm.org/svn/parrot/revision?rev=34547
Coke gives up on global_cleanup for the evening. 05:08
making t/library/test_builder_tester.t pass in the branch will probably be most illuminating. 05:09
nopaste "GeJ" at 202.22.229.231 pasted "[open modes] Yet another batch of conversions. Coke++ for the assignment." (377 lines) at nopaste.snit.ch/15113 05:23
Coke GeJ: I'm heading abed. If no one grabs it, could you open a ticket? Thanks. 05:26
zzzzzzzzz
GeJ++
GeJ Will do. Thanks 05:28
Good night Coke. 05:29
05:46 Andy joined
TiMBuS dumb question: is there a way to redefine a sub block in parrot? 05:49
ive changed undefined functions to throw an error when executed instead of spitting out a 'null pmc' error, but i'd like to be able to change the sub definition if the function is later implemented before it is ran 05:50
dalek r34548 | pmichaud++ | branches/rvar/compilers/pct/src/PAST: 05:51
: [pct]: Make PAST::Block.symbol smart about adding attributes to existing entry.
review: www.parrotvm.org/svn/parrot/revision?rev=34548
r34549 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 05:56
: [rakudo]: Fix up symbol table handling a bit.
review: www.parrotvm.org/svn/parrot/revision?rev=34549
r34550 | petdance++ | trunk/src: 06:17
: removed unused var; did some consting
review: www.parrotvm.org/svn/parrot/revision?rev=34550
r34551 | petdance++ | trunk/lib/Parrot/Pmc2c (2 files): 06:23
: removed unused include
review: www.parrotvm.org/svn/parrot/revision?rev=34551
r34552 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 06:32
: [rakudo]: Restore &-sigil vars.
review: www.parrotvm.org/svn/parrot/revision?rev=34552
r34553 | petdance++ | trunk/lib/Parrot/Pmc2c (3 files): 06:34
: pruned unused imports
review: www.parrotvm.org/svn/parrot/revision?rev=34553
r34554 | petdance++ | trunk/lib/Parrot/Pmc2c: 06:36
: pruned unused imports
review: www.parrotvm.org/svn/parrot/revision?rev=34554
r34555 | petdance++ | trunk/lib/Parrot/Pmc2c (5 files): 06:38
: renamed gen_ret() to return_statement()
review: www.parrotvm.org/svn/parrot/revision?rev=34555
06:45 Theory joined 06:46 tuxdna joined 06:47 Zaba_ joined
dalek r34556 | pmichaud++ | branches/rvar/languages/perl6/src/classes (2 files): 06:53
: [rakudo]: Add Hash() coercion and hash parameters.
review: www.parrotvm.org/svn/parrot/revision?rev=34556
r34557 | pmichaud++ | branches/rvar/languages/perl6/src/parser (2 files):
: [rakudo]: Do something reasonable with the 'returns' trait.
review: www.parrotvm.org/svn/parrot/revision?rev=34557
r34558 | petdance++ | trunk/lib/Parrot/Pmc2c: 06:55
: removed unused include
review: www.parrotvm.org/svn/parrot/revision?rev=34558
r34559 | chromatic++ | trunk/src (4 files): 08:02
: [src] Tidied some source code; no functional changes.
review: www.parrotvm.org/svn/parrot/revision?rev=34559
r34560 | chromatic++ | trunk (24 files): 08:07
: [src] Converted several old file modes to new form (patch by Geraud
: CONTINSOUZAS).
review: www.parrotvm.org/svn/parrot/revision?rev=34560
tewk chromatic: mmd canidate types_names are converted to type_ids at invocation right. 08:09
08:10 iblechbot joined
GeJ chromatic: thanks 08:13
chromatic tewk, yes, for MMD cache keys and such. 08:17
GeJ, I believe we should be thanking *you*.
GeJ Not really like it was a critical patch. I just helped Coke with the dirty repetitive work so he could do something that really matters. 08:29
But if any other tasks like these would come up (and if time permits) I'd be happy to help. 08:30
chromatic trac.parrot.org/parrot/wiki/Conver...tsToParrot is always good. 08:31
GeJ Oh, do you happen to know if some tools are publicly available to convert PseudoPod to PDF? I tried pod2pdf, but some data gets lost in the process.
chromatic We use Pod::PseudoPod::Latex at Onyx Neon, then a LaTeX to PDF converter with a custom stylesheet. 08:32
GeJ I'm going to try that. thanks for the tip. 08:35
lathos 'Ken Lunde has just notified me of the release of the Second Edition of _CJK Information Processing_. ' 08:52
09:12 kj joined
TiMBuS arg. I tried to subclass ResizablePMCArray, but now I get told it 'doesnt array' when I use :flat 09:24
how to I let it array?
09:33 skv joined 09:36 tomyan joined
dalek r34561 | kjs++ | trunk/compilers/pirc/new (5 files): 09:38
: [pirc] for now, stick to current :multi syntax; not sure whether :invocant will be 1.0 feature.
: + Count the number of :multi types during parsing.
review: www.parrotvm.org/svn/parrot/revision?rev=34561
09:53 alvar joined
dalek r34562 | kjs++ | trunk/compilers/pirc/new (6 files): 10:24
: [pirc] decouple bcgen module from rest of PIRC. Define some new structs for multi_types. Add some helper functions.
review: www.parrotvm.org/svn/parrot/revision?rev=34562
10:32 masak joined 10:33 tuxdna joined
dalek r34563 | kjs++ | trunk/compilers/pirc/new (3 files): 10:33
: [pirc] create a signature pmc for :multi(), without any types.
: + add the trick stolen from imcc, that numtypes=1 means :multi(), n=2 means :multi(Type1), n=3 means :multi(Type1,Type2), etc. n is always 1 higher than actual type. If n=1, "__VOID" signature is generated.
review: www.parrotvm.org/svn/parrot/revision?rev=34563
r34564 | kjs++ | trunk/compilers/pirc/new: 10:46
: [pirc] implement parts of generate_multi_signature().
review: www.parrotvm.org/svn/parrot/revision?rev=34564
TiMBuS i had to make the pmclass have a 'provides array' in the declaration 10:50
dalek r34565 | kjs++ | trunk/compilers/pirc/new (6 files): 11:12
: [pirc] create an array of :multi types, and convert the PIRC AST expression nodes into multi_type nodes. This is to keep bcgen module apart from PIRC, otherwise we could have used expression nodes, which are PIRC AST specific.
review: www.parrotvm.org/svn/parrot/revision?rev=34565
r34566 | kjs++ | trunk/compilers/pirc/new (2 files): 11:17
: [pirc] fix a bug, and add a few comments.
review: www.parrotvm.org/svn/parrot/revision?rev=34566
11:50 rurban_ joined, ruoso joined
Tene seems like my RSI rest is mostly over. starting work on HLL stuff tomorrow. 12:01
12:39 ask_ joined
dalek r34567 | rurban++ | branches/pdd30install_stage3/t/tools: 12:52
: Trac #97: Current tests do not test the installables, esp.
: if the prefix is correctly set from the build_dir to the
: configured prefix, i.e. if config.fpmc is linked, in contrary
: to the build-time config_lib.pasm
: t/tools/parrot_config.t checks parrot_config prefix against
: installable_parrot_config prefix.
review: www.parrotvm.org/svn/parrot/revision?rev=34567
Coke I'm going to get this *bsd box working and then realize how horribly outdated it is and probably not worth smoking. =-) 13:01
dalek r34568 | kjs++ | trunk/compilers/pirc/new (7 files): 13:18
: [pirc] work on lexical registering.
review: www.parrotvm.org/svn/parrot/revision?rev=34568
13:20 apeiron joined
dalek r34569 | kjs++ | trunk/compilers/pirc/new (5 files): 13:27
: [pirc] prefix sub_flags with "PIRC", to prevent collisions with libparrot.
review: www.parrotvm.org/svn/parrot/revision?rev=34569
13:30 masak joined 13:31 Theory joined
dalek r34570 | rurban++ | branches/pdd30install_stage3/tools/build: 13:35
: [cage] RT#56998 cygdll_versioning moved the dll to build_dir,
: so this check is not needed anymore.
: RT#57548 CONDITIONED_LINE_enh added a platform check so the
: cygchkdll config entry is also not needed anymore.
review: www.parrotvm.org/svn/parrot/revision?rev=34570
Coke msg timbus (redefine sub block) - if the sub is in a namespace, you can just get the namespace and shove a newly defined sub into it. 13:36
purl Message for timbus stored.
Coke ... it's sad that I can tell when this box is waiting for me to hit enter because the hard drive noise drops below audible. :| 13:37
karma orkut? 13:42
purl orkut has karma of -8
Coke orkut--
dalek r34571 | kjs++ | trunk/compilers/pirc/new (4 files):
: [pirc] bits of find_outer_sub().
review: www.parrotvm.org/svn/parrot/revision?rev=34571
r34572 | rurban++ | trunk/t/tools: 13:44
: [cage] prefer $PConfig{perl} over perl
review: www.parrotvm.org/svn/parrot/revision?rev=34572
13:54 Andy joined 13:56 apeiron joined
dalek r34573 | kjs++ | trunk/compilers/pirc/new (2 files): 13:58
: [pirc] bits for namespace stuff in PMC_sub.
review: www.parrotvm.org/svn/parrot/revision?rev=34573
14:05 apeiron_ joined
dalek r34574 | kjs++ | trunk/compilers/pirc/new (4 files): 14:28
: [pirc] remove lex_name field from target; no longer used. + some documentation updates.
review: www.parrotvm.org/svn/parrot/revision?rev=34574
14:35 jimmy joined 14:52 workbench joined
dalek r34575 | rurban++ | branches/pdd30install_stage3 (5 files): 14:54
: [test] add parrot_utils tests #101
: trac.parrot.org/parrot/ticket/101
review: www.parrotvm.org/svn/parrot/revision?rev=34575
14:57 AndyA joined
dalek r34576 | kjs++ | trunk/compilers/pirc/new (2 files): 15:05
: [pirc] first draft of optimization suggested by chromatic++. box_p_ic becomes set_p_pc.
review: www.parrotvm.org/svn/parrot/revision?rev=34576
15:06 workbench joined 15:13 jsut|work joined
dalek r34577 | kjs++ | trunk/compilers/pirc/new: 15:15
: [pirc] optimize box_p_sc and box_p_nc also as set_p_pc. + refactor.
review: www.parrotvm.org/svn/parrot/revision?rev=34577
15:23 gryphon joined
dalek r34578 | rurban++ | branches/pdd30install_stage3: 15:35
: [install] add missing files which need to installed, languages not yet
review: www.parrotvm.org/svn/parrot/revision?rev=34578
r34579 | pmichaud++ | trunk/languages/perl6/docs: 15:41
: [rakudo]: spectest-progress.csv update: 264 files, 5802 passing, 141 failing
: Failure summary:
: S16-filehandles/io.rakudo aborted 57 test(s)
: S16-filehandles/io_in_for_loops.rakudo aborted 49 test(s)
: S16-filehandles/io_in_while_loops.t aborted 13 test(s)
: S16-io/basic-open.t aborted 9 test(s)
: S16-unfiled/slurp.rakudo aborted 9 test(s)
: integration/say-crash.t aborted 4 test(s)
review: www.parrotvm.org/svn/parrot/revision?rev=34579
masak some IO failures there. 15:42
15:43 Andy joined
jonathan wonders where they came from. 15:45
pmichaud I suspect the filemode changes to FileHandle
jonathan ah, should be easy to fix then
pmichaud: How's paramters going? I glanced over what you've been checking in earlier and it looks good. 15:46
pmichaud it's going well thus far
still a ways to go
jonathan Lot of regressions to fix up?
pmichaud but we now handle sub foo(@a) { ... } and sub foo(%h) { ... } 15:47
well, I've ripped out huge portions of actions.pm that haven't gone back in yet
jonathan We didn't before?
pmichaud no, we didn't before.
before it was treating all parameters as Perl6Scalar
so, for example, sub foo(%h?) { ... } would result in %h being an undef instead of an empty Hash 15:48
jonathan Ah.
OK.
pmichaud and
sub foo(@a) { ... }; foo(1); would leave @a as an Int instead of an Array containing an int
anyway, the typechecking and binding code is no longer in actions.pm 15:49
it's now in a separate function that does the typechecking and binding based on the $!signature object 15:50
jonathan Right, as we agreed a while back. :-)
jonathan is happy to see this implemented.
pmichaud right now I'm trying to figure out if STD.pm chooses to parse @( ... ) as a variable or a circumfix: (and why there are two choices) 15:51
15:51 hercynium joined 15:56 tetragon joined
pmichaud looks like it uses circumfix:sigil . I have no clue why. 15:57
15:57 barney joined
dalek r34580 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 15:58
: [rakudo]: Make <sigil>(...) parse as circumfix again.
review: www.parrotvm.org/svn/parrot/revision?rev=34580
16:00 elmex_ joined
Coke does parrot support a namespace path? 16:14
(like @INC for namespaces)
dalek r34581 | bernhard++ | trunk (5 files): 16:16
: RT #61800: [PATCH] implement array_fill() within pipp.
: Courtesy of Daniel Keane.
review: www.parrotvm.org/svn/parrot/revision?rev=34581
Coke Actually, I suppose I can easily do that on my own, since I have a hook on every command invocation. Ne'ermind.
dalek r34582 | bernhard++ | trunk (7 files): 16:24
: RT #61786: [PATCH] docs/book typo corrections
: Courtesy of Ovid.
review: www.parrotvm.org/svn/parrot/revision?rev=34582
Coke looks like we misspell precidence a bit, too, if someone wants to grab that. 16:27
16:29 Zaba joined
dalek r34583 | bernhard++ | trunk (4 files): 16:29
: RT #61812: [PATCH] Fixed typos in docs -- removed duplicate example code
: Courtesy of Saleem Ansari.
review: www.parrotvm.org/svn/parrot/revision?rev=34583
16:31 jhorwitz joined
dalek r34584 | bernhard++ | trunk: 16:42
: [docs] order entries in CREDITS
review: www.parrotvm.org/svn/parrot/revision?rev=34584
rurban I cannot change the tiackt status of my trac tickets. Who's admin? 17:10
dalek r34585 | pmichaud++ | branches/rvar/languages/perl6/src/classes:
: [rakudo]: Protoobjects are already scalars.
review: www.parrotvm.org/svn/parrot/revision?rev=34585
r34586 | bernhard++ | trunk/languages/pipp/src/common: 17:15
: [Pipp] The Perl-like file modes have been removed from Parrot.
review: www.parrotvm.org/svn/parrot/revision?rev=34586
17:18 tomyan joined 17:29 mberends joined
rurban The cygwin distro is now out (0.8.2) 17:30
I'll report any cygwin feedbacks here. 17:31
17:40 Zaba joined, ask_ joined 17:41 leto joined 17:47 davidfetter joined 17:48 Zaba_ joined
dalek r34587 | rurban++ | branches/pdd30install_stage3/ports/cygwin (7 files): 17:52
: [ports] parrot-0.8.2-1 release
review: www.parrotvm.org/svn/parrot/revision?rev=34587
18:26 allison joined 18:49 register joined 18:55 dngor joined 19:10 ffwonko joined 19:26 chromatic joined
dalek r34588 | bernhard++ | trunk (3 files): 19:28
: [codingstd] remove a trailing space.
review: www.parrotvm.org/svn/parrot/revision?rev=34588
r34589 | jkeenan++ | branches/pdd30install_stage3 (2 files):
: Update MANIFEST and MANIFEST.SKIP.
review: www.parrotvm.org/svn/parrot/revision?rev=34589
allison chromatic: (reviewing gc branch commits) quick question about r34113, was that a merge from trunk? 19:35
chromatic Checking. 19:36
Oh, I'm sure it was.
I tried to check out the branch with SVK and it played helpful.
jhorwitz allison++ # i see pdd22io_part3 branch is coming along nicely :) 19:37
allison chromatic: cool, I'll update the merge history
jhorwitz: just about ready to merge in, fixing a few failing tests 19:38
jhorwitz: well, all existing tests pass, I just added some new ones for the StringHandle PMC
jhorwitz allison: can i subclass using a parrot class or do i have to write a new PMC? 19:39
chromatic That was my question too. 19:40
allison jhorwitz: you can subclass using a Parrot Class, and if you do you can use all the internal I/O functions. The one catch is that a subclass has to have the same basic struct members as FileHandle
jhorwitz as attributes?
allison ah, you mean a PIR class, rather than a C class 19:41
jhorwitz yeah
allison the only way to do that at the moment is by delegation
largely because Parrot's mechanism for subclassing across the C->PIR barrier isn't complete
jhorwitz nods 19:42
allison I created StringHandle as a demonstration that any PMC with the right methods can polymorphically substitute for a FileHandle 19:43
jhorwitz so it would seem that for me it would be easiest to write a new PMC using StringHandle as a template. 19:44
allison the things that won't work are the 'tell', 'seek', and 'peek' functions, which currently work with types that aren't supported in PIR
jhorwitz all i need is open, read and write (or their equivalents). :) 19:46
allison (though, I notice the opcodes handle these by casting the long as an int or two ints
jhorwitz: and, yes, using StringHandle as a template will work fine
jhorwitz excellent
jhorwitz loves it when a plan comes together.... 19:47
allison are you using internal I/O functions at all?
jhorwitz PIO functions?
allison aye, or the Parrot_io_* functions 19:48
(I'm guessing not)
jhorwitz nope
allison then StringHandle is definitely the way to go
(it doesn't use them either) 19:49
jhorwitz any IO that i do is abstracted by apache
keeps me out of trouble. :)
allison and StringHandle, btw, is safe to subclass from PIR 19:50
jhorwitz cool 19:51
19:53 rurban_ joined 19:57 tomyan joined
Coke is it possible to use the trick to get your pir subclasses proxy attribute to override the invoke vtable? 20:02
I want to have my TclProc (a pir class that subclasses Sub) have some setup/teardown on invoke. 20:03
$P0 = getattribute self, ['Sub'], 'proxy'
$P0()
(the overriden vtable is getting invoked, I just can't seem to use that trick to get at the original invoke vtable.) 20:05
(the $P0 there is NULL) 20:07
chromatic Hm, the new IO file modes are undocumented except for the book -- nothing in the PDD, the ops, nor the Parrot_io_* function docs, as far as I can see.
Coke they're in the PDD.
pdd22, search for "append" 20:08
(which has duplicated docs which say "same as open opcode", and yah, I don't think their documented at the opcode. 20:09
ah, in fact, the opcode file lies and says 'perl style'
chromatic Hence my comment.
Coke my fault, I suppose; I didn't update the docs when I ripped out the old syntax.
chromatic I'm running Rakudo tests now, having updated the code there to fix things. Hopefully. 20:10
Coke chromatic: fixed. 20:13
dalek r34590 | coke++ | trunk/src/ops: 20:14
: reference mode types at the opcode docs, where the PDD points us to.
review: www.parrotvm.org/svn/parrot/revision?rev=34590
Coke (oh good, I had already switched back to trunk earlier today. )
my note can probably be cleaned up a bit. 20:15
The way the code is written now, you must specify one of 'r' or 'w'
nopaste "Coke" at 72.228.52.192 pasted "without an arg, this errors out on # of params. With args, the typeof gives the type of the first argument. (where'd self go?)" (25 lines) at nopaste.snit.ch/15115 20:24
Coke I would expect that to print "IN UR VTABLE\\nTclProc" 20:25
tewk I have a class registry patch ready for review. 20:28
allison tewk: excellent
tewk t/library/p6object.t, fails several tests that need to be modified, I just dont' know how to fix them.
chromatic t/spec/S05-substitution/subst.rakudo TODO passed: 22, 25, 35, 38 20:29
dalek r34591 | chromatic++ | trunk/languages/perl6/src/builtins:
: [Rakudo] Fixed IO open modes; all spectests pass again.
review: www.parrotvm.org/svn/parrot/revision?rev=34591
masak chromatic++ 20:32
20:35 dngor joined 20:40 PacoLinux joined
nopaste "tewk" at 209.193.99.80 pasted "class_registry.diff" (2857 lines) at nopaste.snit.ch/15116 20:41
pmichaud I'd be surprised if p6object.t fails tests. That might indicate that the class registry patch isn't as transparent as it needs to be. 20:49
Coke allison: ping 20:52
for open modes, is it intentional that you have to specify "write append", not just "append" ?
allison Coke: yes 20:53
well, wait...
Coke if you use an open mode of just 'a', it fails.
(because 'a' doesn't imply WRITE)
(and you have to specify either read or write, at least on unix.) 20:54
allison Coke: yes, that's how it works
Coke ok.
allison Coke: why?
Coke because i would expect 'a' to imply 'w'
(because 'ra' doesn't make any sense to me.)
chromatic +>
allison the way the internal flags work is you specify "WRITE" and either TRUNCATE or APPEND 20:56
Coke there is no declared way to specify truncate.
chromatic w
allison so, made truncate the default
and then set APPEND if 'a' is also found
(that is, unset TRUNCATE and set APPEND)
Coke right. 20:57
<shrug> I don't particularly care, I just wanted to make sure it was intentional.
I am going to have to map tcl's modes to parrots anyway.
allison the PDD is non-specific
at this point, it can really go either way
it's early enough that changing 'a' to imply 'w' isn't going to mess anyone up 20:58
Coke again, I don't care. I just wanted to make sure it was intentional.
allison so, how strong is your first reaction that 'a' should imply 'w'
Coke it surprised me.
allison yes, but the first reactions of the first users are important
so, want to capture it 20:59
Coke if I didn't have access to the source code, I would have very confused.
tewk pmichaud: I don't put classes in the registry anymore. its just bound to raise its nasty head later.
pmichaud tewk: then we need to go through a deprecation cycle for it.
allison Coke: ok, I'll change that right after I merge in the stringhandles branch
tewk hasn't the old oo system been deprecated for months 21:00
pmichaud (filehandle modes) my first reaction is that they look like stdio modes, so I'd expect them to work as such.
Coke I thought we already replaced the old OO system. =-)
pmichaud tewk: afaik the class registry has not been deprecated.
21:00 workbench joined
allison the class registry is still used to create unique ids 21:01
Coke running one spec test via tclsh8.5 takes 0.055s; via partcl, it takes 5m.
allison and unique ids are still necessary
Coke 5*60/0.055
purl 5454.54545454545
allison and, the new OO system still enters all PIR classes in the registry
tewk allison: creating unique ids hasn't changed, you just can't assume a flat namespace 21:02
allison tewk: right, isn't that what your patch is fixing?
eliminating the flat namespace?
tewk yes but there is code where people assume a flat namespace, and I'm not providing backwards compat for that.
allison mmmm... diff -u is not producing a terribly comprehensible result on this one 21:03
Tene someone want to remind me how to create a branch with svn?
allison Tene: svn copy
purl svn copy is, like, a good idea
Coke svn cp svn.perl.org/parrot/trunk svn.perl.org/parrot/branches/new_branch 21:04
Tene thanks
tewk if you create class foo in namespace A and then in switch to namespace B and do $I0 isa Foo_obj "Foo" 21:05
because it can't find "Foo" in namespace B
$I0 isa Foo_obj Foo_class is the right way to do that of course. 21:06
Tene isa_*_s should probably look in the same place that new_*_s does
tewk Continuing to support a flat namespace is dangerous, as an example, I could introduce my own version of P6object early in the load process and break everything that uses PCT 21:08
Coke Anyone have any ideas on overriding the invoke vtable? (need it to support tcl's [trace])
GeJ Good morning everyone 21:09
pmichaud tewk: actually, that *wouldn't* break PCT because PCT tries never to use the flat namespace in the first place.
that's kinda the point.
(if PCT is using the flat namespace for anything other than Parrot builtin PMCs, it's a bug in PCT.) 21:10
HLLCompiler being the potentially notable exception, as it needs an overhaul
tewk pmichaud: ok. bad example
good news: perl6 only has a couple of failures with the new patch
good news: perl6 only has a couple of failures with the resgistry hack. 21:11
good news: perl6 only has a couple of failures with the class registry fix.
pmichaud I would expect Rakudo to have a couple of failures, yes -- there's still some code that uses new_p_sc
but that's partially why I think we need to keep the registry around a while, to give people a chance to adapt 21:12
nopaste "tewk" at 209.193.99.80 pasted "rakudo.class_registry_fix.results" (9 lines) at nopaste.snit.ch/15117
pmichaud tewk: that's _all_ that fail? 21:13
if so, I'm totally and utterly shocked. :-)
tewk pmichaud: yep, which supports your statement that PCT is doing the right thing.
I think it is further evidence that the change won't be as painfull as maybe we expected. 21:14
pmichaud Rakudo and PCT have the advantage that I've been designing away from the class registry for nearly a year. 21:15
I suspect other languages don't have that luxury.
tewk new_p_sc continues to work if you use it in the same namespace where you declared the class.
Who doesn'
t use PCT? tcl, ...
pmichaud same namespace == same hll namespace?
Tene oh, I should probably wait until after class registry fixes go in 21:16
pmichaud it's not just the compiler, it's also the builtins
PCT just takes care of the compiler part.
Tene tewk: you going to commit class registry stuff today?
pmichaud and if "continues to work if you use it in the same namespace" really means "same hll namespace", then things may break horribly when we start using .hll 21:17
Tene pmichaud: no, same .namespace
tewk no it means the same namespace
pmichaud so, new 'Integer' would fail if I don't have an Integer class in my current namespace?
pmichaud is confused.
tewk Integer is a core PMC, so it will work 21:18
pmichaud "core PMC" means "any PMC"?
how about dynamically loaded PMCs?
Tene I thought that _sc meant [parrot;*] 21:19
pmichaud that wasn't what I proposed, no. 21:20
tewk Tene: no _sc means string constant.
I think all PMC still go into the registry
Tene tewk: s/_sc/the _sc variants of the class registry ops/, but i'm wrong anyway
tewk the _sc variants go into the current namespace. 21:21
We don't support dynpmcs in namespaces yet do we? 21:23
pmichaud every PMC type has a corresponding namespace, yes. 21:24
I don't know if there's a way to have a PMC type in anything other than parrot;
Coke switches to the list for his invoke() question. 21:32
tewk: tcl doesn't use PCT; neither does pheme, IIRC. 21:33
tewk Coke: I'm trying to fix Tcl 21:34
Coke would you like commit bits for partcl?
tewk tewk: no, not yet. 21:35
Coke talking to yourself is not a good sign.
tewk I'm not going to check in the registry fix yet I'm just trying to gauge how bid a disruption it is.
Coke: got: 'Class '[ 'TclExpr' ; 'PAST' ; 'Grammar' ]' not found 21:36
where does this lookup occur?
pmichaud suspects it's a tge-generated item.
Coke very likely.
tewk pmichaud++ sounds right
dalek r34592 | tewk++ | branches: 21:38
: Gut the class registry :)
review: www.parrotvm.org/svn/parrot/revision?rev=34592
tewk no worries I just created a branch :)
Tene Coke: pheme will use PCT soonish. 21:52
tewk pheme passes all its tests
Tene tewk: when do you plan to commit? 21:56
tewk Tene: when/if people think it is a good idea. 21:58
Coke Tene: I thought pheme was meant not to use pct.
ISTR chromatic explaining it as a canary in the coal mine for tcl.
Tene Coke: chromatic said that it's meant to be a simple demonstration of the right way to do things, and so should ddefinitely use PCT 21:59
Coke must have been a happy coincidence.
I would happily accept a patch to let tcl use PCT. =-) 22:00
chromatic Canary in the coal mine for TGE. 22:01
(but it would be easier to add features to Pheme if it used PCT)
dalek r34593 | chromatic++ | trunk/src/ops: 22:02
: [ops] Removed trailing whitespace.
review: www.parrotvm.org/svn/parrot/revision?rev=34593
22:03 Whiteknight joined
Coke wozzat me? sorry 22:03
chromatic Was that me complaining that someone checked in accurate, concise, and timely documentation? No way! 22:06
Coke sorry about the whitespace, still. 22:07
chromatic Check in more documentation and I will happy fix any apostrophe or whitespace fixes if they exist. 22:08
Coke I cannot think of a comment that doesn't invoke tcl and snark. 22:09
pmichaud including that one. :-P 22:12
Coke exactly! 22:15
purl somebody said exactly! was it not awesome?
Coke aside from --optimize, how I can make parrot go faster? 22:23
(3*60+46)/0.055
purl 4109.09090909091
pmichaud perhaps a better GC? 22:24
pmichaud ducks.
Coke I should definitely run future spec test runs against an optimized parrot, though. 22:25
5/(3+46/60)
purl 1.32743362831858
Coke (3+46/60)/5
purl 0.753333333333333
Tene pmichaud: don't we already think that that the class registry fix is a good idea?
pmichaud I think the class registry fix is important. But tewk's details differ slightly from what I was imagining, and we can't cause existing code relying on the registry to break without going through a deprecation cycle first. 22:26
s/important/critical/
(well, we can skip the deprecation cycle, but only by breaking a long-standing policy. I'm not sure it's critical enough to warrant that.) 22:27
tewk I've got an idea about quickly adding backwards compat.
I'll give it a try
Coke note that we are running out of deprecation cycles for 1.0 22:28
pmichaud if fixing the registry involves modifying existing tests or language implementations, then by definition we need a deprecation cycle.
Coke (presuming we're sticking with our target date.)
Tene and we don't currently need this for HLL stuff, right?
pmichaud I think we can move forward on HLL stuff w/o the registry fix, but as you observed it might be good to get the registry fix in place first. 22:29
I don't see one as blocking on the other, no.
Tene I mostly wanted to avoid conflicts, but if it's not going in soon, I should be fine. 22:30
pmichaud I don't think there should be (m)any conflicts.
Tene Can we at least get a deprecation note in DEPRECATED, though?
pmichaud I'd like to know what exactly we're deprecating, first.
Coke getting the note in only matters on release boundaries.
pmichaud again, what tewk described is different from what I proposed, so I'd like to understand that better first. 22:31
Tene Coke: yes, and I'd like to make sure this can be fixed after the next release. 22:32
pmichaud: okay.
pmichaud if fixing the class registry requires a deprecation, then almost by definition we missed the Jan 2009 target for it. :-| 22:33
Tene Ah. 22:34
pmichaud (although we can certainly have it fixed on the day-after-Jan-2009-release :-)
Tene food with the girl &
dalek r34594 | pmichaud++ | branches/rvar/languages/perl6/src (6 files): 22:35
: [rakudo]: Fix a brain-o; we can't have Scalar(), Array(), Hash() subs
: because those are actually types. So work around it for now.
review: www.parrotvm.org/svn/parrot/revision?rev=34594
jonathan is back
Coke jonathan! 22:36
purl i guess jonathan is mailto:jnthn@jnthn.net or trying to put together a grant application.
jonathan Coke!
Coke How much would I have to pay you to work on tcl for a day? =-)
jonathan Seriously?
purl Totally!
jonathan I don't exactly know the codebase... ;-)
Coke come up to speed on your own time! =-)
jonathan Is it using PCT, or written in PIR, or hybrid (like PGE parser, PIR rest...)? 22:37
Coke PGE/TGE
lots of runtime invocations of stuff written in PIR.
jonathan Ah, it's sorta interpreted-ish as much as it is compiled? 22:38
pmichaud Coke: we might get a bigger win if we could get Jonathan to instrument Parrot with some profiling stuff :-)
Coke of more general use would be a ....
what pmichaud said.
jonathan Ah. So what you really want is performance stuff?
Coke If we had sub level profile information (PIR & C), that would be awesome.
then I can properly blame patrick! =-)
jonathan At least, performance analysis...
pmichaud Coke's goal is to make Tcl less annoyingly slow.
s/annoyingly/agonizingly/ 22:39
Coke with an optimized bird, one spec test for tcl is currently 4100 times slower than tclsh8.5.x
chromatic Even just knowing where the hotspots in PGE and PCT are would help.
jonathan Given the recent OMFG 2000 TIMES SLOWER THAN LUA post on the list, I'm struggling to have much faith in Parrot performance right now.
Coke (5400 with a regular build.)
I feel his pain.
chromatic We have to fix calling conventions to NOT COPY DATA AROUND MULTIPLE TIMES WHEN WE COULD JUST POKE IN REGISTERS WHICH IS THE POINT OF REGISTERS NOT STACKS to get some of that back. 22:40
jonathan First step would be to revert the MMD changes on ops. *sigh*
Bluntly, I think that change was a mistake.
chromatic MMD doesn't hurt as much as you think.
jonathan But IANTA.
Coke profiling. need profiling. =-)
jonathan chromatic: No, it didn't hurt before.
chromatic It only hurts now because argument passing is slow. 22:41
jonathan Like, when it was a lookup in a 2D array which gave us a function pointer (OK, a couple of indirections...)
No, a candidate sort or even hitting an MMD cache is *way* more expensive than a 2D array lookup.
chromatic I made a quick patch to run MMD from ops through the cache lookup, and it was only a few percent faster.
jonathan That's because even MMD *with* a cache hit now is more costly than what we used to do.
chromatic It was not worth abstracting out. I was surprised.
It's not the MMD that's the problem. It's Parrot_pcc_invoke_from_sig_object(). 22:42
jonathan That doesn't surprise me that much. The marshalling is costly, however.
Yes.
chromatic There's at least one spot to optimize in MMD caching, and that's the string creation for cache keys.
I haven't thought of a simple solution there though. It'd be very nice to make keys usable with const_string(). 22:43
jonathan chromatic: I only used Parrot STRING*s because of what happened with a cstring cache...
(I forgot about NULL termination ;-))
chromatic Exactly.
jonathan If we didn't piggy-back of hash or tried to do something smart we could do better.
s/of/off/
chromatic I hate to multiply entities, but a trie wouldn't hurt there at all.
jonathan But I was going more for first cut than optimal. 22:44
that'd be wroth looking at.
chromatic Yeah, that's still only at most a 10% improvement though.
jonathan But as you said, efforts on marshalling less and stuff would be a big win.
chromatic Right now we pay a huge cost in argument processing because we *may* have named parameters.
jonathan What worries me plenty is that other VMs can JIT calling.
For simple calls.
chromatic Agreed.
jonathan leo got some amazing performance when he made us able to do that. 22:45
But we've lost it.
(We've gained a lot of correctness and cleaner code, mind...)
pmichaud keep in mind that PGE always has to assume there are named parameters.
chromatic We need to start by unifying all calling through sig objects, and then pull more information into sig objects so we don't create some 4 - 7 PMCs for each invocation.
pmichaud if there's a way to optimize that, I'm in favor of it. 22:46
chromatic At compile time, we know if we have named parameters or named arguments. 22:47
We can make a fast path there.
jonathan We know on the caller side.
chromatic We know on the callee side too.
Not for any given pair, but for each element of the pair.
jonathan We don't know the callee at compile time. ;-)
pmichaud I'll rephrase
jonathan Yes, we're saying the same thing. :-)
pmichaud PGE always has to assume there are slurpy named params 22:48
so a hash gets built for every regex invocation even when it might not be needed.
jonathan wonders how many places modify the thingy that collects the slurpy parameters. 22:49
pmichaud a few, but I know where they are.
chromatic .sub "name" :method
.param pmc adverbs :unique_reg :slurpy :named
jonathan If we know there are no named being passed, and we expect a slurpy, and we can promise non-modification, then we can just have one global read-only Hash. 22:50
pmichaud correct.
I was even thinking of a COW hash :-)
jonathan .param pmc adverbs :slurpy :named :ro
We can't easily do that I fear.
pmichaud right. :-)
chromatic No, it's named adverbs'
pmichaud but there's another approach
chromatic not 'ro'
pmichaud (more) 22:51
Coke kicks off an --optimized run of partcl's spec tests.
pmichaud it would be nice if there was a way to say "ignore any extra arguments the caller happens to send" without having to create slurpies for them
in fact, this is a problem in general
right now we can't throw exceptions when a caller sends arguments to a sub taking zero params 22:52
jonathan Erm? 22:53
purl Erm is it bat shit crazy? It's just unprovable right?
pmichaud iwbni we could have a way to differentiate subs that ignore extra arguments from those that expect a specific set of extra arguments
s:2nd/extra//
jonathan pmichaud: Ah, you mean, this can take any params, but we ignore them and don't bind them anywhere?
pmichaud yes.
"if there are extra params, it's okay, just ignore them"
jonathan That sounds like a quite specific and odd thing.
pmichaud actually, it'd be very common 22:54
jonathan In PGE?
pmichaud yes.
PGE regexes are technically methods
jonathan If it'd get a PGE win, it's probably an optimization worth considering.
pmichaud PGE regexes are technically Perl 6 methods
and Perl 6 methods always have an assumed *%_ param
chromatic At compile time in PIR we know that we have named parameters; we could convert those to hash lookups.
pmichaud (i.e., a slurpy hash)
chromatic At least the first assignments.
pmichaud so therefore when PGE generates its regexes, it always has to put that slurpy param at the end, even though it's not going to use anything it gets there. 22:55
because calling a regex with extra named arguments shouldn't throw an exception.
the same is true for any method in Perl 6
so, PGE ends up creating these slurpy hashes on every regex invocation 22:56
jonathan *nod*
pmichaud better would be
PGE generates specific named parameters for the ones it's interested in, and ignores the rest 22:57
jonathan In Perl 6 it's harder to staticly know when ignoring the extra nameds is possible, but we likely can. And for PGE, I guess it's much easier.
pmichaud for PGE it's pretty easy. 22:58
we don't expect PGE to be dealing with CALLER::<%_>
(at least, I don't.)
22:59 TiMBuS joined
pmichaud but this is also part of the reason I'm in favor of a :capture PMC type 22:59
i.e., make it easy for me to unpack the arguments in whatever way I want.
s/PMC type/param type/ 23:00
note that :capture doesn't have to imply creating a hash and array -- it just means that when I do 23:01
.param pmc args :capture
then args[0] gives me the first positional argument and args['name'] gives me the named argument
GeJ From the i-have-some-free-time-to-do-the-gruntwork dept., could someone point me to a Perl-to-PIR converted test so I can work on some others? 23:02
pmichaud 'args' itself can be something that is very smart about locating the corresponding argument
i.e., $I0 = args[0] doesn't have to involve going through a PMC if the sub was invoked with an integer register as the first argument. 23:03
chromatic GeJ, rt.perl.org/rt3/Ticket/Display.html?id=60682 23:04
jonathan pmichaud: Laziness good. :-)
chromatic All this makes me want to have a smarter register allocator and SSA-based optimizations of PCT before generating PBC. Or I could eat pie and play video games with my family.
pmichaud mmmmm pie 23:05
but it could also mean that I could avoid doing :flat and :named :flat if I just wanted to pass all of the arguments on to another sub (e.g., in a delegation or tailcall)
GeJ chromatic: Ah, thanks. I'll try to warm up with some easy ones first and hopefully will go ballistics later this afternoon. 23:06
chromatic Problem is, we're not thinking of the advantages of registers, nor laziness.
pmichaud we aren't?
chromatic GeJ, I look forward to applying patches.
Currently we aren't.
pmichaud which "we" are we referring to? ;-)
chromatic "We" as in "the current code".
pmichaud correct, the current code does not do this. 23:07
I was hoping that the calling conventions branch might head in this direction, but I'm doubtful now.
chromatic I talked to allison about this yesterday, and she convinced me that unifying multiple disparate invocation styles into one is an advantage to making them fast and saner later. 23:08
pmichaud if you're convinced, then I feel much better.
chromatic It's much easier to optimize decent code than accreted, half-working experiments. 23:09
jonathan While that's true, releasing a 1.0 with a Lua compiler that is 2000 times slower than the standard engine isn't going to fly too well. 23:10
And I don't think it's slow because the Lua on Parrot compiler is bad, though there's doubtless room for optimization there too. 23:11
chromatic I agree, but I don't want to fall into the trap of thinking that we should delay 1.0 for this feature or that feature.
We could release a new version of Parrot every day if we wanted. 23:12
jonathan Sure, we're not saying 1.0 is production, but "a stable platform for building compilers" implies we want to attract compiler writers.
We all know that. It's a perception game. And of course, performance isn't a feature.
pmichaud jonathan: I'm cheerful -- the roadmap says that GC, contexts, and calling conventions will all be refactored in the Jan 2009 release. 1/2 :-)
jonathan pmichaud: And if it happens by then I'll be overjoyed. :-) 23:13
chromatic Our advantage isn't "Faster than LuaJIT"; it's "Interoperable with other languages, unencumbered and free, and the world's best compiler toolkit."
jonathan chromatic: I didn't say we had to be faster. I said we had to be under three orders of magnitude slower. :-)
chromatic Make PGE use fewer PMCs and we can probably double its speed. 23:14
jonathan Slower doesn't bother me. *This* much slower does.
chromatic The trick is knowing which PMCs we don't need and where.
pmichaud give me a way to ignore extra named params and I can likely save one pmc per regex invocation :-)
jonathan :capture :-) 23:15
It's just a...simple matter of implementation...
pmichaud (more than that, because we won't be converting named arguments into PMCs)
chromatic Write me a simple test case, and I'll see what I can do. 23:16
pmichaud (writing.)
chromatic Thanks. 23:17
nopaste "pmichaud" at 72.181.176.220 pasted "ignore extra named arguments test for chromatic" (12 lines) at nopaste.snit.ch/15119 23:18
"pmichaud" at 72.181.176.220 pasted "ignore extra named arguments test for chromatic (with current execution)" (12 lines) at nopaste.snit.ch/15120
pmichaud arggggh
nopaste "pmichaud" at 72.181.176.220 pasted "ignore extra named arguments test for chromatic (with current execution) FOR REAL THIS TIME" (17 lines) at nopaste.snit.ch/15121
pmichaud ideally I'd think something like 23:19
.param pmc args :slurpy :named :ignore 23:20
.param pmc args :slurpy :ignore
chromatic_away the :ignore flag
?
pmichaud basically it means "accept extra arguments for purposes of calling this sub, but don't bother creating the slurpy pmc" 23:21
(pick a more suitable flag or name besides :ignore)
or if not a flag, then a directive.
a flag is nice because we could also then do 23:22
($P0, $P1, $P2 :slurpy :ignore) = 'foo'()
23:22 ruoso joined
pmichaud which allows 'foo' to return extra (named) arguments that are also ignored. 23:22
right now they're ignored by default, because chip rightly disliked the idea that we would have to always do 23:23
($P0, $P1 :slurpy) = 'foo'()
when we only wanted the first return value back from foo
_another_ possibility would be to turn the whole thing around. 23:25
right now we throw exceptions when the number of (named) arguments doesn't match the params
_except_ when a sub doesn't declare params, in which case they're ignored 23:26
if we could have a flag or directive that tells the sub whether or not to do parameter arity checking, that'd be another way to approach it.
i.e., I'm thinking we should perhaps try to solve RT #39844 while we're at this. 23:29
pmichaud shuts up now. 23:30
23:30 Limbic_Region joined
jonathan gets some rest now 23:31
Taking family to Vienna tomorrow, so don't know that I'll be around much.
It'll be January before I really dig back into stuff properly. 23:32
pmichaud jonathan: okay.
jonathan: can you give me a quick overview of how subset types work?
(I haven't looked at the code yet.)
jonathan pmichaud: From what angle?
pmichaud I'll ask slighly differently.
jonathan But basically, all you need to know from a type-checking angle is to tall .ACCEPTS - just smart-matching.
*call
pmichaud what's the difference between "type" and "constraints" in Signature?
jonathan Ah. That matters. :-) 23:33
If you have a simple type, either a single role or a single class name, then it goes in type
If you have either multiple type names or one type name that refers to a subset type, it goes in constraints. 23:34
Examples
purl hmmm... Examples is shorl.com/bynygruhofrebru
jonathan sub foo(Int $a) { ... } # type is Int, constraints is empty
pmichaud then iiuc, 'type' is an optimization for mmd on simple types, while everything else goes in constraints?
jonathan sub foo(R1 R2 $a) { ... } # R1 and R2 go in constraints 23:35
It's deeper than optimization.
Note that
purl somebody said Note that was a really bad picture of me, but it was the only thing I could find at this hour.
jonathan sub foo(Int where { $_ > 0 }) { ... } # type Int, plus one constraint 23:36
oh
I meant sub foo(Int $a where { $_ > 0 })
And was calling to follow it with
sub foo(Int where { $_ > 0 } $a)
Which mean the smae thing.
Basically if there's at most one type that is a class or a role, it goes in type. 23:37
If there is more than one class/role it's more complex and they go in constraints.
pmichaud what would happen if that example ended up with Int and where in constraints ?
(and type empty)
23:37 apeiron joined
jonathan Type should never be empty, but rather Any, otherwise auto-threading won't work. But the direct answer to what you asked, is that MMD would not consider the Int type when doing type narrowness analysis. 23:38
And thus if you wrote a sub foo(Num $a) { ... }
pmichaud is the dispatcher currently smart enough to handle the case when a parameter isn't a subclass of Any?
jonathan And you'd not put Int in the type slot 23:39
Then the Num would come out more narrow.
pmichaud sorry, argument isn't a subclass of Any
23:39 jq joined
jonathan Multi-dispatch will currently say no applicable candidates, I believe. 23:39
perl6: multi foo(Int $x) { say 42 }; foo(1); foo(1 | 2); 23:40
pmichaud that might have some implications for language interop
polyglotbot OUTPUT[42ā¤No applicable candidates found to dispatch to for 'foo'ā¤current instr.: '_block14' pc 100 (EVAL_13:46)ā¤called from Sub '!UNIT_START' pc 16073 (src/builtins/guts.pir:327)ā¤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 (src/PCT/HLLCompiler.pir:508)ā¤called from Sub
..'parrot;PCT;HLLCompiler;evalfiles' pc 1217 (src/PCT/HLLCompiler.pir:...
jonathan We'll worry about that when we have .HLL and some languages to interporate with.
pmichaud I already have languages to interoperate with: PGE
23:41 cognominal_ joined
jonathan Then we'll have to make Any do something special when the call comes from a different HLL. 23:41
Or handle it in signature binding.
pmichaud right.
again, I was just curious. 23:42
jonathan I don't fancy hanlding it until we have .HLL in place unless we really have to.
When we have that, it's a dynop that cheaply checks if the caller is from a different HLL.
pmichaud I give about a 40% estimate that Perl 6 ends up re-thinking Junction handling before we're done. :-)
(note "Perl 6" not "Rakudo" :-) 23:43
jonathan I like the way it works from a typing point of view.
But I agree it makes language inter-op a tad interesting.
Limbic_Region pmichaud: the synopses officially live in pugs repo now right?
pmichaud L_R: that's correct.
L_R: we still haven't done the magic to make all of the related websites point to the right place.
(and I'm not necessarily the person with that magic.) 23:44
jonathan pmichaud: If you're actually going to enforce the Any type - which I don't think we are right now - we might get some interesting things showing up.
Limbic_Region my question has more to do with the draft synopses that only lived there
for instance - S17
jonathan (As in, during sig binding.)
pmichaud jonathan: actually, I was wondering what happens if I don't enforce it.
if not enforcing it is what we do now, great.
jonathan pmichaud: If it's easy for you to try and see the fallout, please try it.
If you don't, I will have to in a couple of weeks anyway. 23:45
pmichaud it will be easy to do after the refactor.
I'm _very_ pleased with the way this refactor is shaping up.
jonathan (Because we need to for junctions.)
Limbic_Region pmichaud: svn.pugscode.org/pugs/docs/Perl6/Sp...rrency.pod # there is no mention of coroutines anywhere else so I am wondering if these draft synopses should be moved?
shorten Limbic_Region's url is at xrl.us/beay9z
pmichaud so far actions.pm is about 1500 lines shorter.
jonathan I didn't look at everything, but I did look at actions.pm after your changes and liked what I saw.
...wow...
pmichaud (there's a lot of code left to be restored, but it's a lot shorter)
jonathan How many less comments do we now have? ;-) 23:46
I think one of us has a tendancy to write more of those than the other. :-)
pmichaud some of that too. But I'm trying to emulate your commenting style as much as I can.
jonathan I'm not sure how helpful my comments are to others.
pmichaud I can answer that: they're very helpful.
to me, at least.
jonathan OK, good. That's two of us. :-)
pmichaud which is why I'm trying to do the same (with lesser success)
jonathan Do you write code then comments? 23:47
Or write comments and then code?
pmichaud code then comments
jonathan Ah.
pmichaud I think in code.
jonathan That's probably where we differ. :-)
pmichaud to me, code is a more natural medium of expression than prose.
jonathan I can appreciate that.
pmichaud L-R: moving synopsis discussion over to #perl6 23:48
jonathan I'm also the kind to write the opening and closing braces of a block and then to fill in the middle. :-)
Each to their own.
jonathan certainly wouldn't claim to be normal.
pmichaud clearly each of our styles works for us individually, and is workable as a team :-) 23:49
jonathan Aye. Which is fine. :-)
How much % of the spectests does the refactor branch currently regress? 23:50
Like, is it mostly there, or a long way off?
pmichaud it's a way off, but that's because I'm still working on simple things like list assignment. 23:53
jonathan Ah, OK.
pmichaud Like, I found a brain-o an hour or so ago and had to re-regress a bit.
a lot more passes than I would've expected at this point.
mostly I'm catching little things here and there.
jonathan I guess you're reviwing/fixing a lot of stuff I've shoved in over the last year too. :-) 23:54
It's a _big_ refactor.
I expect it'll stand us in a good place for the next bunch of stuff. 23:55

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!