Parrot 0.8.1 "Tio Richie" Released | parrot.org | 24 TT | 648 RT
Set by moderator on 10 December 2008.
Whiteknight make testj is the JIT core? 00:05
jonathan Think so, yes. 00:07
lathos JIT is meaningless now, with the MMD stuff, apart fromforNCI. 00:10
jonathan Yes and no. 00:11
MMD "only" affects PMCs.
But yes, we've made something that once coulda been JITTable with some effort (like, a 2D array lookup) into something that surely ain't. :-| 00:12
pmichaud why was mmd important, again? 00:13
lathos PMCs are rather omnipresent.
pmichaud (at the PMC level)
jonathan pmichaud: Well, we were doing it before.
We have been for a _long_ time.
pmichaud afaict, the PMC level mmd has always gotten in my way far more than it did anything useful. 00:14
even "before"
jonathan For things like add, etc, the idea is that it handles cases where you want to react differently depending on the type of the thing you're adding to yourself, etc.
pmichaud of course, Rakudo never gets to use that. 00:15
jonathan Before, we had two MMD systems.
The one for :multi(...) which did manhattan dispatch on PCC stuff.
And a separate one for opcodes.
Apparently, that was a problem.
pmichaud the opcode MMD hasn't ever been useful to me.
maybe it's better now
jonathan Maybe. 00:16
But for us it's a pain in the arse.
Because we already _do_ a multi dispatch.
pmichaud But I see a fundamental disconnect between pdd15_objects and mmd
jonathan And by the time we've done our Perl 6 dispatch, we know exactly what types we have.
pmichaud we have an object system, which basically takes us out of the PMC realm
so, HLLs either use that object system, which means the PMC-level mmd isn't at all useful 00:17
or they write custom PMCs, which means they aren't really using the object system
jonathan Oh, you can register Parrot subs with the opcdoe MMD.
*opcode
lathos To be fair I don't think we're doing much cross-language stuff and maybe it would turn out to be useful when we do.
pmichaud how does one register a Parrot sub with opcode MMD ? 00:18
lathos But it's slow as all hell.
jonathan pmichaud: Off hand, I don't remember. I'm sure I've seen a test doing this.
pmichaud I haven't seen anything like it.
anyway, the notion of "custom PMCs" doesn't seem to fit into any HLL that has some sort of object-based system at its core. 00:19
at least, not without re-implementing a Object PMC metamodel.
gotta go fetch the xmas tree... bbiaw 00:20
dalek r33872 | pmichaud++ | trunk: 00:22
: [pct]: :loadinit no longer does the "get_outer" hack to fetch its block.
: (More refactors coming on this part soon.)
diff: www.parrotvm.org/svn/parrot/revision?rev=33872
chromatic Now we have a single MMD system which does double-to-quadruple dispatch. 00:25
The solution, I suspect, is removing the MMDable vtable entries from vtables.
(it works for primitive registers because autoboxing works there) 00:26
As soon as we can say that all of those types of invokables use PCCs, we avoid the marshalling overhead. 00:27
jonathan chromatic: Calling to MMD rather than calling the vtable that then calls the MMD would be a tiny saving - it's the whole marshalling where the big cost lies.
chromatic As well, we make it possible that a reasonably smart JIT (or a really dumb tracing JIT) could *inline* and *optimize* those calls.
jonathan Getting rid of the marshalling - yes, this would be a big win. 00:28
lathos chromatic: Sounds a lot like optimizing by adding complexity rather than optimizing by reducing it.
jonathan But the amount of work we do now do *add to damm numbers together* is insane. 00:29
chromatic Which part, lathos?
jonathan *two
lathos Waiting for a magic JIT to sort it out.
chromatic I think you misunderstood. 00:30
Right now, there's no way a JIT could optimize this.
jonathan chromatic proposed something different to that
jonathan lets chromatic explain :-)
chromatic We call in and out of C far too many times for that to work.
If we pulled cmp out of the vtable and instead defined a Sub somehow (whether NCI or PIR or whatever), we could avoid a lot of marshalling overhead. 00:31
We could always do the cmp comparison with standard Parrot dispatch.
lathos Hrm.
chromatic A tracing JIT can inline that kind of dispatch.
We'd go a lot faster even without the JIT, but we have the possibility of going even faster.
lathos I thought the whole point of PMC vtables was that they wrapped up type-specific ways of doing stuff. 00:32
I think that, in as far as it goes, makes sense. When you have MMD on two PMCs, it goes it bit awry. 00:33
chromatic That's the problem. 00:34
We have vtables that do MMD, which suggests to me that we should skip the useless step.
(not in the least because it's also very expensive)
lathos Yep, see what you're saying now and agree.
chromatic Of course, I have this design for a highly-concurrent message-passing VM which does pervasive MMD, but that's a different story. 00:36
Also, did you see my Perl 5 patch? 00:37
lathos Yep, very neat. Did you see NCI.pm? 00:49
dev.simon-cozens.org/6pan/browser/trunk/NCI
chromatic That's tiny. That's a good sign. 00:52
lathos It's just exposing the two PIR functions to Perl basically, with a bit of sugar around them. 00:55
jonathan -> sleep 01:14
Tene So, anyone have any idea when I can expect to hear about reimbursements from PDS? 01:20
It's been... a while. 01:21
pmichaud Let's mutiny until PDS reimbursements are handled. :-P 01:53
Tene I think I'm RSI'd out for the day. 02:07
PDD23 updates wait until tomorrow.
02:23 gmansi joined 02:39 particle1 joined 03:06 leto joined 03:15 jimmy joined
jimmy null $P0 03:17
$S0 = typeof $PO # this does work, but i think $S0 should be NULL
sorry, this does not work
03:33 gmansi joined 03:36 TiMBuS joined
dalek r33873 | Whiteknight++ | calling_conventions: 03:47
: [calling_conventions] update to trunk r33872
diff: www.parrotvm.org/svn/parrot/revision?rev=33873
03:52 leto joined 04:02 elmex_ joined 04:25 contingencyplan joined 04:30 Alias joined 04:46 MariachiElf joined 04:57 apeiron joined 05:13 bacek joined 05:21 gmansi joined 05:38 leto joined 05:43 Andy joined 06:10 leto joined
dalek r33874 | pmichaud++ | trunk: 06:13
: [pge]: Add <?{{...}}> and <!{{...}}> code assertions (PIR).
diff: www.parrotvm.org/svn/parrot/revision?rev=33874
06:34 rhr joined 06:39 AndyA joined 06:57 TiMBuS joined 07:00 leto joined 07:21 Theory joined
dalek r33875 | fperrad++ | trunk: 07:50
: [Lua] update NEWS
diff: www.parrotvm.org/svn/parrot/revision?rev=33875
08:08 gmansi joined 08:32 iblechbot joined 08:38 Alias joined 08:51 allison joined 09:04 jimmy joined, gmansi joined 10:01 mberends joined, Hadi joined
dalek r33876 | tene++ | trunk: 10:02
: [pdd23]: Rewrite a few sections, update for sanity, add comments.
diff: www.parrotvm.org/svn/parrot/revision?rev=33876
10:02 Hadi left
cotto sanity++ 10:18
10:18 Hadi joined 10:19 Hadi left
cotto (which begs the question why I'm still up) 10:19
dalek r33877 | cotto++ | trunk: 10:36
: [imcc] be a little more defensive in NULL checks (CID #336)
diff: www.parrotvm.org/svn/parrot/revision?rev=33877
10:49 jimmy joined
dalek r33878 | fperrad++ | trunk: 10:59
: [dotnet]
: - update PIR syntax generation
: - fix some tests
: Failed 16/43 test programs. 80/263 subtests failed.
diff: www.parrotvm.org/svn/parrot/revision?rev=33878
r33879 | cotto++ | trunk: 11:34
: [io] free string after using it, rather than before (CID #343)
diff: www.parrotvm.org/svn/parrot/revision?rev=33879
jimmy cid? 11:35
purl cid is all MUA or Coverity ID
dalek r33880 | cotto++ | trunk: 11:36
: [ops] free string after using it, rather than before (CID #344, CID #345)
diff: www.parrotvm.org/svn/parrot/revision?rev=33880
11:39 alvar joined
cotto They're automatically generated reports of possible bugs. 11:39
11:52 leto joined 12:03 jan_ joined 12:05 jan joined 13:05 kj joined 13:20 slavorgn joined 13:33 leto joined 13:59 Theory joined 14:40 Whiteknight joined 14:47 Limbic_Region joined 14:52 Theory joined 15:12 jan joined
dalek r33881 | kjs++ | trunk: 15:26
: [pirc] update register usage in sub struct after doing register optimization.
diff: www.parrotvm.org/svn/parrot/revision?rev=33881
15:39 kid51 joined 15:45 apeiron joined
dalek r33882 | pmichaud++ | trunk: 15:48
: [rakudo]: Adjust grammar to use <?{{...}}> assertion syntax.
diff: www.parrotvm.org/svn/parrot/revision?rev=33882
15:57 tetragon joined
dalek r33883 | pmichaud++ | trunk: 16:00
: [docs] NEWS updates for December 2008 release.
diff: www.parrotvm.org/svn/parrot/revision?rev=33883
16:06 davidfetter joined 16:13 gmansi joined
dalek r33884 | kjs++ | trunk: 16:27
: [pirc] implement re-use of live_interval objects; no need to malloc() and free(), if they can be cached.
diff: www.parrotvm.org/svn/parrot/revision?rev=33884
r33885 | pmichaud++ | trunk:
: [rakudo]: spectest-progress.csv update: 240 files, 5005 passing, 0 failing 16:28
diff: www.parrotvm.org/svn/parrot/revision?rev=33885
r33886 | kjs++ | trunk: 16:30
: [pirc] don't need a separate varaible for iterator; re-use the old one. (saving 4 bytes of stack space)
diff: www.parrotvm.org/svn/parrot/revision?rev=33886
16:32 gmansi joined
dalek r33887 | kjs++ | trunk: 16:33
: [pirc] free memory of cached objects.
diff: www.parrotvm.org/svn/parrot/revision?rev=33887
r33888 | kjs++ | trunk: 16:37
: [pirc] remove unused codesize field from subroutine struct; endoffset - startoffset yields same value, if necessary.
diff: www.parrotvm.org/svn/parrot/revision?rev=33888
r33889 | jkeenan++ | trunk: 16:44
: Include report of better test coverage of Parrot::Test.
diff: www.parrotvm.org/svn/parrot/revision?rev=33889
r33890 | fperrad++ | trunk: 16:46
: [jako]
: - remove .namespace/.endnamespace
diff: www.parrotvm.org/svn/parrot/revision?rev=33890
r33891 | kjs++ | trunk: 16:51
: [pirc] don't generate leaving instructions in a sub if there's already a 'returncc' or 'end'. Update test as well. I think other branching instructions should be added to this check as well, or possibly a check on the opinfo->flags, which would be neater. TODO: check this out.
diff: www.parrotvm.org/svn/parrot/revision?rev=33891
r33892 | kjs++ | trunk: 16:59
: [pirc] layout++; (old comments)--
diff: www.parrotvm.org/svn/parrot/revision?rev=33892
r33893 | pmichaud++ | trunk: 17:07
: [rakudo]: Reorganize method ordering, other minor cleanups.
diff: www.parrotvm.org/svn/parrot/revision?rev=33893
r33894 | kjs++ | trunk: 17:11
: [pirc] prepare to do clean up some code related to symbol and pir_reg structures. + add a #define for documentation purposes.
diff: www.parrotvm.org/svn/parrot/revision?rev=33894
17:13 Andy joined 18:00 Hadi joined, Hadi left
dalek r33895 | pmichaud++ | trunk: 18:03
: [rakudo]: Clean up flattening a fair bit.
: This removes 15 seconds from "make spectest" on my machine,
: and eliminates the special-case 'isa' checks from !flatten.
diff: www.parrotvm.org/svn/parrot/revision?rev=33895
r33896 | pmichaud++ | trunk: 18:44
: [rakudo]: Optimize flattening a bit further.
: When splicing in a flattened element, we don't need to
: re-flatten the things we just spliced in.
diff: www.parrotvm.org/svn/parrot/revision?rev=33896
r33897 | moritz++ | trunk: 18:52
: [rakudo] add a few files to t/spectest.data, restore alphabetical order,
: and add reasons why we don't include other file(s) here
diff: www.parrotvm.org/svn/parrot/revision?rev=33897
19:04 peters joined
peters Hi folks =) 19:04
19:05 clunker3_ joined 19:09 bacek joined
peters is trying to implement a URI grammar (which doesn't need char ranges =) 19:12
nopaste?
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 i think 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)
moritz peters: I have a basic URL grammar here that works in Rakudo 19:13
Andy moritz: Thanks for the pointer
Anything interesting that we can do to churn up interest.
peters moritz: cool, but I'm in the mood for full RFC implementations ;) 19:14
moritz peters: even better ;-)
peters: make sure to blog about it (and tell us the URL) when you're done ;-)
nopaste "peters" at 83.183.129.106 pasted "Patrtitial implementation of URI (RFC 3986)" (117 lines) at nopaste.snit.ch/14941 19:15
peters but it doesn't work =(
I guess that it's because "longest token match" isn't implemented
pmichaud generally one can work around longest token match. 19:16
moritz peters: remeber that tokens never backtrack, you might need rules instead in some places
pmichaud (regexes) 19:17
moritz erm, yes
s/token/regex/ where appropriate
peters I see
pmichaud oh, we can also do code assertions in PIR now
so
peters tries s/token/regex/ 19:18
moritz pmichaud: i've changed S29-trig/trig.t to 'use Num :Trig' as it says in the spec, which rakudo fails...
pmichaud: should I fudge out that line? or regress on the test file?
pmichaud I prefer to fudge the line.
rakudo doesn't have a Num.pm yet, nor does it understand arguments to 'use' 19:19
peters: you need to flip the order of dec_octet 19:20
it'll match "2" (and stop) before it ever gets to "25 <[0..5]>"
yes, this is a place where ltm would solve that for you. :-)
peters thanks 19:21
pmichaud token ls32 { [ <h16> ':' <h16> ] | IPv4address }; 19:22
did you perhaps mean <IPv4address> ?
peters true =) 19:23
pmichaud if '2001:db8::7' ~~ /^<URI::IPv4address>$/ {
I'd expect that to be false, since IPv4addresses are separated by '.' 19:24
moritz peters: in general it's helpful to build and debug such grammars bit by bit, you never get them right at first try
pmichaud that's my experience, definitely. 19:25
nopaste "peters" at 83.183.129.106 pasted "URI (RFC 3986) matches IPv4 and IPv6, good start =)" (122 lines) at nopaste.snit.ch/14942 19:26
pmichaud peters: yes, please please please blog this somewhere. 19:29
this looks excellent -- and really shows off the power of p6 grammars.
peters I don't have a blog, perhaps you can blog it? 19:30
you desreve the credit ;) 19:31
peters s/desreve/deserve/ 19:32
pmichaud if you just send me a writeup, I'll post it.
peters would'nt the nopaste itself speak for the "powers" of p6 grammars and the state of the rakudo implemenation? 19:35
pmichaud sure -- there's a few things that you might want to finish up, though :-) 19:36
like
peters sucks at writing formal things in english
pmichaud token pct_encoded {
'%' HEXDIG HEXDIG
};
peters true =)
pmichaud it doesn't have to be formal -- it's better if it's not formal. Just "here's what I did in Perl 6/Rakudo", "here's why I did it", "here's what I think about it."
peters why is simple, we need a alot of RFC grammars if we are to compete (read enhance as in RFC compliance) with p5, we simple want to fix issues with invalid p5 URI.pm parsing ;) 19:40
pmichaud sounds good to me. :-)
peters and thanks to rakudo it's possible ;=)
pmichaud post it to perl6-users@perl.org, perhaps?
peters I want to try for a full URI (grammar proven; with tests) implementation first if thats ok 19:43
pmichaud sure 19:44
peters =)
jonathan pmichaud: Any preference for when I do Rakudo day next week? 19:47
Of course, I'm generally about a lot more now too, working on the grant/bytecode anno etc.
moritz found another rakudo bug today: sort() isn't stable
pmichaud jonathan: so far my week appears open, unless I'm forgetting some committment I've made. 19:48
jonathan: so it can be "pick your favorite day"
depending on what you're thinking of doing, it might be better to go "after tuesday" (release)
jonathan Is there anything you'd like my help on to make happen pre-release? 19:49
Or anything you'd like me to focus on post-release?
I haven't made any particular plans yet.
peters I think moritz should blog more about the powers about grammars, the ability to extend (inheritance), "override" rules and pass "action" objects is just amazing from a p5 perspective
pmichaud if you wanted to fix up WHENCE, that'd be cool. :-) 19:50
jonathan OK.
How's Associative etc going?
pmichaud blocked on fixing WHENCE :-)
jonathan Oh.
pmichaud I'll make a branch for it.
jonathan OK, great.
moritz peters: I will, some day :/
jonathan Just stick the branch in with the WHENCE realted failures and I can investigate. 19:51
pmichaud oh, I might be able to work around it, actually.
Anyway, I'll make the branch and get as far as I can and then you can look at things from there.
19:51 masak joined
peters moritz: cool =) 19:51
jonathan OK, works for me.
pmichaud it'd be great to get it in before release, but if it doesn't happen it's no biggie.
jonathan OK.
masak OH HAI
jonathan I'm away on Friday and then sketchy over the Christmas period from then.
pmichaud so if that's the case, maybe you'll want to rakudo day Monday. And it would be nice to say that has $a = ... is _really_ working.
jonathan Ooh, that's tomorrow. 19:52
OK, I can do that.
pmichaud I'll get the associative branch start in a couple of hours
jonathan Nothing is pressing from @other_job for tomorrow.
peters godkvļæ½ll (good evening) masak
moritz detects many more masak tickets in the Perl 6 RT queue
masak peters: tja.
jonathan Yeah, I was pondering a bug-fixing Rakudo day more than a features one...
pmichaud masak's tickets are getting more esoteric. eval() a method declaration inside of a class?!?!?!
masak moritz: that happens when I'm offline on a bus and bored. :)
pmichaud: see above :) 19:53
pmichaud: btw, that's a perfectly reasonable thing to do :P
jonathan pmichaud: It shouldn't segfault, but I think that might still be an error. Maybe.
pmichaud however, if they're getting more esoteric, that means that we're making it harder for him to find the "obvious" bugs, I think.
moritz masak: hehe, I was on a train ;-) see pugs r24361 for the result ;-)
masak pmichaud: aye. you are.
moritz: updating as we speak.
pmichaud speaking of which, I've almost fixed RT #58770 -- just need one more test.
(empty return gives back Nil) 19:54
jonathan brb - eating
masak ooh, lots of tests. moritz++
moritz masak: List.end needs to be exported as a sub, that should be an easy one for you 19:56
bacek good morning, people of past
masak moritz: i.e. `end @a`, yah?
moritz masak: aye 19:57
masak bacek: good morning, future fellow.
dalek r33898 | pmichaud++ | trunk:
: [rakudo]: Fix bare return value in item and list context (RT #58770)
diff: www.parrotvm.org/svn/parrot/revision?rev=33898
masak moritz: added to growing TODO list. the Chinese ordeal still isn't quite over. 19:58
moritz masak: maybe I'll take a look myself, it's been too long since I last did something in rakudo other than testing ;-) 19:59
pmichaud runs a spectest summary to see what moritz++'s tests do to the results.
masak moritz: feel free.
moritz should be plus ~60
bacek rakudo: class Foo { has $.foo }; class Bar is Foo {}; my $f = Foo.new(foo=>42); say $f; my $b = Bar.new(foo=>'epic fail'); say $b; 20:03
polyglotbot OUTPUT[Foo<0xb721dcb0>ā¤You passed an initialization parameter that does not have a matching attribute.ā¤current instr.: 'die' pc 13732 (src/builtins/control.pir:167)ā¤called from Sub 'parrot;Perl6Object;new' pc 568 (src/classes/Object.pir:360)ā¤called from Sub '_block11' pc 108 (EVAL_12:40)ā¤called
..from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 (src/...
bacek is Bar.new(foo=>'bar') should work? 20:04
or how I can initialise parent class?
moritz bacek: I think there needs to be a different syntax, in case the parend and the child have an attributed of the same name 20:05
Tene no, I'm pretty sure that inheritance should work like you said.
moritz maybe new('SUPER::bar' => ...)
bacek I can't find evidence in S06. 20:06
moritz bacek: S12 would be more interesting 20:07
bacek moritz: looking
rakudo: class Foo { has $.foo }; class Bar is Foo {}; my $f = Foo.new(foo=>42); say $f; my $b = Bar.new( Foo { foo=>42} ); say $b; 20:09
polyglotbot OUTPUT[Statement not terminated properly at line 1, near "( Foo { fo"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤called from Sub 'parrot;Perl6;Grammar;eat_terminator' pc 27602 (src/gen_grammar.pir:3377)ā¤called from Sub 'parrot;Perl6;Grammar;statementlist'
..pc 26258 (src/gen_grammar.pir:2844)ā¤called from...
bacek this should work. But it doesn't. Yet another TODO ticket :)
masak it used to work. 20:10
I remember jonathan blogging/talking about this.
bacek rakudo: class Foo { has $.foo }; class Bar is Foo {}; my $f = Foo.new(foo=>42); say $f; my $b = Bar.new( Foo{ foo=>42} ); say $b;
polyglotbot OUTPUT[Foo<0xb7205f8c>ā¤Bar<0xb7202364>ā¤]
bacek rakudo: class Foo { has $.foo }; class Bar is Foo {}; my $f = Foo.new(foo=>42); say $f; my $b = Bar.new( Foo{ foo=>42} ); say $b; say $b.foo;
polyglotbot OUTPUT[Foo<0xb71e8f6c>ā¤Bar<0xb71e4cb4>ā¤42ā¤]
bacek It works!
Tene That seems... less than ideal 20:11
masak Tene: indeed.
bacek Tene: it's from S12... Not perfect, anyway 20:12
nopaste "peters" at 83.183.129.106 pasted "complete but untested URI (RFC 3986) grammar" (147 lines) at nopaste.snit.ch/14943
masak peters++ 20:13
peters: now go test it! :)
peters I will =)
.. tomorrow ( in swedish time) 20:14
masak: I also have alomst complete 2616 (HTTP) grammar ;) 20:16
masak peters: sounds worthy.
peters: you might want to consider committing these to the Pugs repository somewhere.
moritz just what I wanted to suggest, only masak was faster ;-)
pmichaud Foo{foo=>42} is the correct syntax 20:17
5053 passing tests
masak pmichaud: it's sufficient syntax, but is it necessary?
peters but I can't test that until hex char ranges [(\\x00i..} is implemented
pmichaud if foo is private to Foo, yes. 20:18
masak peters: could you perhaps fake it in the meantime?
pmichaud I don't know if it's necessary for a public $.foo
peters != windows kb map
masak pmichaud: but it isn't in bacek's case.
peters masak: not sure how
masak peters: ok. me neither. 20:19
pmichaud we know that the Foo{...} implementation in rakudo has a couple of issues -- just discovered them last night.
masak peters: though working around not-yet-features usually works, once you get into the right frame of mind.
in Rakudo as well as in PGE.
pmichaud I might be able to refactor \\x to work
jonathan On the Foo{...} thingy. 20:22
peters that wold be very nice from my point of view
jonathan *The* most common bit of feedback I've got while talking about Perl 6 OO at workshops is that it'd be really nice if masak's second example worked and it did look up the hierarchy for an attr of that name.
pmichaud sounds like it needs a message to p6l
jonathan It came up in my OO talk at YAPC::EU when Larry was there. 20:23
masak peters: psst! submit TODO rakudo tickets for things that would be very nice from your point of view.
peters because I can't see a way too fake +<ctrl> - \\x00
pmichaud peters: [ <ctrl> & \\X00 ]
jonathan And IIRC Larry said, that it should do that. I said the synopsis didn't say it should and asked him to patch it.
masak jonathan: but now that power belongs to The Masses. 20:24
pmichaud any chance it just uses the accessor?
jonathan Which leaves the most likely option as, he just forgot/didn't get to it.
pmichaud: If it's a private there's not an accessor, though...
pmichaud ...private accessor?
jonathan ?
peters what about any char except unicode (<[\\x00..\\xff]>)
jonathan $!foo # storage location
pmichaud there's no private accessor?
(I need to review S12 for this.) 20:25
jonathan Oh, I think I've been there before. 20:26
It suspect it's sketchy
pmichaud it's okay if there's no private accessor -- I just thought I remembered one.
moritz self!foo is the private accessor
(I think)
pmichaud right, that's what I thought.
jonathan "If you declare with the . form, you also get the private ! form as a non-virtual name for the actual storage location"
Do $!foo and self!foo are different? :-S 20:27
And if $!foo goes via the private accessor, then presumably self!foo is non-virtual.
moritz jonathan: $!foo implies scalar context
jonathan: just like @!foo implies list context 20:28
jonathan Erm.
has @!foo; has $!foo; # so what does this mean?
moritz jonathan: conflict
purl somebody said conflict was really between naturalism and supernaturalism.
bacek ambiguity!
purl It's in the box.
jonathan looks in S12 for that
masak purl: there? 20:29
purl What?! Where?! When??! Why? Who?!
moritz has @!foo; for $!foo { # just one iteration }
jonathan And more curiously... "The attribute variables may be used within instance methods to refer directly to the attribute values. Outside the instance methods, the only access to attributes is through the accessors since an object has to be specified."
peters says g'night 20:30
bacek peters: g'night
masak peters: godnatt. 20:31
jonathan Ah, hmm.
dalek r33899 | moritz++ | trunk:
: [rakudo] export @list.end as a sub
diff: www.parrotvm.org/svn/parrot/revision?rev=33899
masak moritz++
dalek r33900 | moritz++ | trunk: 20:32
: [rakudo] add test for @list.end to spectest.data
diff: www.parrotvm.org/svn/parrot/revision?rev=33900
moritz JFDI also applies to the specs, it seems :)
pmichaud have to run an errand -- when I get back I'll work on the associateve branch
jonathan "If you declare with the . form, you also get the private ! form as a non-virtual name for the actual storage location" - and what if you declare it with the exclamation mark only... 20:33
Is it still non-virtual, etc.
masak sounds like another mail to p6l. 20:34
pmichaud it just felt to me as though new Dog( foo => ... ) could initialize via the accessors instead of the attributes directly.
jonathan pmichaud: If private accessors are non-virtual that won't fly. 20:35
pmichaud jonathan: right.
jonathan Not to get the "looks up the tree" semantics.
pmichaud afk for a bit
jonathan ok
dalek r33901 | pmichaud++ | assoc: 20:43
: [rakudo]: create a branch for associative array and WHENCE handling
diff: www.parrotvm.org/svn/parrot/revision?rev=33901
pmichaud oops. 20:49
in reviewing STD.pm, I misread the handling of postcircumfix on type names
it's not called out for special syntactic treatment. 20:50
(except in the case of postcircumfix:<[ ]> 20:52
jonathan Ah. 20:55
pmichaud so the arguments to Dog{ a=>b } are no longer a list of pairs. 20:56
wait
rephrase
the arguments to Dog{ :name<Fido> } are no longer a list of pairs, they're named arguments. 20:57
jonathan Ah.
That makes it...rather easy...to build the hash. ;-)
pmichaud indeed.
as a first cut, it's just the slurpy hash.
jonathan But how do we know to make a hash evaluate each time (e.g. its a closure that evalutes the hash)? 20:58
Static analysis maybe.
Hey, we discussed this the other day... :-)
pmichaud either postcircumfix always passes a closure, or we do static analysis.
jonathan prefers the second 20:59
pmichaud I'm still curious about the my $x = Dog; $x{ :name<Fido> } case
jonathan The synopsis seemed to disallow that case.
pmichaud yes.
jonathan S12 looks to me like it's making concessions to enable static analysis. I may be wrong, but it's how it looks to me.
pmichaud well, "only for literal named types" sounds very static. 21:00
it's not just making concessions -- it says it right there.
jonathan OK, but I mean it's limiting it to that.
pmichaud right. 21:01
doing that static analysis is going to be a little tricky at the moment, though :-(
maybe we cheat and put the rule we want in the grammar anyway. 21:02
jonathan :-)
pmichaud that might be simplest for the moment.
jonathan Yes.
It's one of the cases where being able to look back at what we last matched would be handy. 21:03
pmichaud actually, let's cheat the other way, and not worry about making it into a closure just yet. 21:04
which gives us what we have now.
(because what we have now doesn't assume closure semantics either.)
jonathan Right. 21:05
That'll "work" too.
We'll still build a closure that returns the slurpy hash anyway, I think, though...
So we get consistency.
pmichaud oh, that would be good. 21:06
jonathan (With building a closure-building-hash for attr init.)
Then later it's a smaller refactor.
pmichaud yes, then we just move the closure-building semantics into actions.pm at some point, and adjust postcircumfix:<{ }> on Protoobject accordingly.
GeJ Good morning everyone
jonathan *nod*
pmichaud wfm
jonathan Oh, I just realized... :-|
masak GeJ: top of the evening to you, sir. 21:07
jonathan Tomorrow is not so good for Rakudo day after all.
pmichaud jonathan: okay, no problem.
jonathan Since there's pm group in the evening.
And evening starts early in Slovakia. ;-) But also got some people going to that coming over for some of the afternoon before going there too.
pmichaud sounds like fun.
okay, Rakudo day later in the week. In the meantime I'll still get started on associative.
if I can get to a commit point, great; if not, then it's there for later. 21:08
jonathan I'll do it Tuesday - maybe we can still land the fixes to proto before release.
erm
to WHENCE I mean
pmichaud although I just put my fixes in and didn't get the same errors I had previously... so.... hrm.
GeJ masak: Early greetings to you too.
pmichaud (running tests)
aha. 21:09
I missed a step.
(forgot to update Makefile)
dalek r33902 | pmichaud++ | assoc: 21:19
: [rakudo]: Initial Associative implementation.
diff: www.parrotvm.org/svn/parrot/revision?rev=33902
21:34 allison joined
moritz how can I delete a (spam) ticket in track? 21:39
tt41 in this case
21:40 johbar joined
cotto it might require an admin 21:43
moritz then we should have more admins
jonathan Like, everyone who's active and has an account on RT now. 21:44
21:44 Theory joined
moritz for example 21:44
Khisanth o_O bugtracker spam? people are actually doing that now? 21:46
moritz Khisanth: people? bots, more likely
Khisanth well bots are probably being controlled by people
moritz more or less 21:49
purl thereabouts
21:54 leto joined 21:55 Limbic_Region joined 21:57 kid51 joined
dalek r33903 | pmichaud++ | trunk: 22:23
: [rakudo]: Eliminate use of %!properties attribute in favor of getprop/setprop.
diff: www.parrotvm.org/svn/parrot/revision?rev=33903
r33904 | pmichaud++ | assoc: 22:24
: [rakudo]: sync WHENCE handling from trunk.
diff: www.parrotvm.org/svn/parrot/revision?rev=33904
22:25 bacek joined 22:42 ffwonko joined 22:55 galf left 22:58 TiMBuS joined 23:24 gmansi joined
dalek r33905 | moritz++ | trunk: 23:24
: [rakudo] add tests for overridable <.ws> rules to spectest.data
diff: www.parrotvm.org/svn/parrot/revision?rev=33905
23:39 gmansi joined 23:44 bacek_ joined 23:57 leto joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!