% iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-244.dynamic.mnet-online.de r27535 | tene++ | trunk: : [rakudo] : * Add a basic isa_ok to Test.pm diff: http://www.parrotvm.org/svn/parrot/revision?rev=27535 % Zaba_ has joined #parrot % ruoso has left ruoso!~ruoso@a81-84-27-88.cpe.netcabo.pt % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru Static vs. Dynamic Languages, Adam Turoff, 14.5.2008, notes-on-haskell.blogspot.co - http://notes-on-haskell.blogspot.com/2008/05/static-vs-dynamic-languages.html mj41's url is at http://xrl.us/bkmso % cognominal has left cognominal!~cognomina@82.67.232.89 allison@perl.org | Concurrency Tasks: link: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks dalek's url is at http://xrl.us/bjqpy % donaldh has joined #parrot % iblechbot has joined #parrot % ruoso has joined #parrot % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se % jan has joined #parrot % mire_ has joined #parrot % tetragon has joined #parrot % cognominal has joined #parrot r27536 | jonathan++ | trunk: : [rakudo] Factor out a large chunk of method scope_declarator. Patch courtesy of moritz++. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27536 my first code contribution to rakudo ;-) :-) I have to blog about it! r27537 | jonathan++ | trunk: : [rakudo] Implement declaration and calling of private methods. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27537 jonathan: did you test that with t/spec/S12-methods/private_methods.t ? jonathan: it dies with "Could not invoke non-existent sub private", although there is no sub call at all (only method calls) or am I being too impatient? ;-) moritz: Hmm, I'd have expected that test to pass now... jonathan: it doesn't for me Oh! my method !private... I'd got my method private implemented, but not with the ! there. there's just 'my method private' in the test In http://svn.pugscode.org/pugs/t/spec/S12-methods/private_methods.t ? jonathan's url is at http://xrl.us/bkmxg I see a !private there. jonathan: my fault, I scrolled down to the second class OK. Removing the ! makes it work... curious though, that as the comment in the test file says, the ! is only mentioned in the roles section. jonathan: the difference is that 'my method !foo' can only be called as self!foo, whereas 'my method foo' also can be called as self.foo indeed moritz: But only inside the class? jonathan: as far as I understand, yes Otherwise it's not very private... :-) * moritz summons TimToady * jonathan fears TimToady may be sleeping at this time wait, I think the test case is flawed From S12 Private methods are declared using my: my method think (Brain $self: $thought) (Such methods are completely invisible to ordinary method calls, and are in fact called with a different syntax that uses ! in place of the . character. See below.) so the 'my method !foo' syntax is only applicable for roles? I'll clean up that test btw implementing $! in rakudo would be a great help for the tests so that one can write a lives_ok sub for Test.pm moritz: S12 isn't completely clear either way. I don't think it is, anyways. jonathan: ok, I'll write to p6l to ask for a clarification Thanks, that'd be great. allison@perl.org | Bylaws: link: http://www.perlfoundation.org/parrot/index.cgi?bylaws r27538 | fperrad++ | trunk: : [Lua] : - translates more opcodes diff: http://www.parrotvm.org/svn/parrot/revision?rev=27538 moritz: On $!, I was glancing over the specs for that. Last week. Pondering how to implement it. Will give it another read today. % iblechbot has left iblechbot!~iblechbot@161.18-dial.augustakom.net TapTinder is back ... http://tt.perl6.cz/ % cognominal has left cognominal!~cognomina@cac94-6-82-232-186-105.fbx.proxad.net jonathan: ok, I asked the list (and also lost myself in philosphy ;) % Tene has left Tene!~tene@castro.iodynamics.com moritz: Thanks. Hopefully @Larry replies with sane answers. :-) % allison has left allison!~chatzilla@dsl-241-62-167.telkomadsl.co.za % cognominal has joined #parrot % tetragon has left tetragon!~seneca@CPE0040d001f62f-CM000a736592a8.cpe.net.cable.rogers.com % masak has joined #parrot % iblechbot has joined #parrot % bacek has joined #parrot hi there bacek: hi what's up, jonathan. I have a stupid question about 'morph' :vtable method. It's probably not stupid. :-) Go ahead. I try to implement morphing from List to Per6Hash, but 'morph' just doesn't called on 'copy $P0, $P1'. I've added stub '.sub "morph" :vtable" into src/classes/Hash.pir with only 'say "morphing"'... any ideas what I doing wrong? r27539 | jonathan++ | trunk: : [rakudo] Add clone v-table method for protoobjects, which resolves the bug that showed up after we switched to using the copy opcode for :pasttype('copy'). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27539 http://pastebin.org/36351 bacek: I'd have expected what you're doing to work... $P0 is the PMC that you implemeted morph on, yes? jonathan: I hope so bacek: OK, looks to me like there's two issues at least. First, it appears that the morph v-table method doesn't support overriding. But deeper than that, looking at the copy opcode, we already call the destory vtable method before calling morph Meaning that the association with the class will have disappeared by morph-time. Which means we can't locate the morph method, even if we did support overriding it. So, hmm. :-S jonathan: its in set.ops? Yes. search for inline op copy is the goal to be able to create a Hash from a List? jonathan: yes. I'm rebuilding parrot with this 2 lines commented out pmichaud: Probably. List.pi defines 'infix:,' op and builds list from (a=>b, c=d..) pairs. ah. Converting that into a hash is the job of the 'hash' function. pmichaud: there is now 'hash' function at the moment. pmichaud: is it 'right way' to build Perl6Hash objects? % iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-170.dynamic.mnet-online.de actually, there shouldn't even be a Perl6Hash :-) I'm working on that at the moment. pmichaud: HLL? :-) Protoobjects, actually. Ah, OK. afaict, there's no need to create a separate Perl6Hash class -- just use Hash directly. * bacek is parrot-newbie pmichaud: Not unless you can someohow make that derrive from Any. pmichaud: It was a svn commit comment some time ago: "Use Hash directly". But later it was reverted to Perl6Hash jonathan: ah. good point. pmichaud: Yeah. That's why I've not used any PMCs directly now. Everything needs to be an Object and (expect from Junction) an Any. okay. There's a patch that proposes 'hash' -- just a sec. I've rebuilt parrot with lines 497-498 commented out. Doesn't help. we are *really* going to need a container type soon pmichaud: ok. Thanks. I think I may do that after finishing the protoobject re-implementation. (which, by the way, is looking really good) pmichaud: Scalar type? yes, but I don't think I'll call it 'Scalar' it'll really be for all variables Including arrays, hashes and so on? (if I'm understanding the types correctly) essentially $x, @a, %h, etc are just containers. @a and %h differ from $x in terms of the properties set on them and what they will accept BTW, where I can read more about protoobjects? (Google little bit stupid and offer replace it with 'photoobjects') (and, of course, they syntactically impose a different context) bacek: synopsis 12 pmichaud: 10x pmichaud: OK, but List, Hash and so on are already containers. there's a patch for a 'hash' function in RT#53016. (It still needs a bit of work.) jonathan: yes, but there's a difference between List and Array List is what we currently think of as ResizablePMCArray Array is a container that is allowed to reference List-like objects shouldn't a List (in Perl 6) be read-only? for example (2, 3, 4).push(5) should be forbidden yes Would my @a = (1,2,3) create an Array or a List? at the language level, Lists appear immutable. Underneath the hood there are various implementation strategies, as long as it appears that way. my @a is an Array that references a List (1, 2, 3) my $x = 3; my $x is a Scalar that references an Int (3) OK, so my @a = (1,2,3); @a.push(4); @a now references the list, and then another element 4? conceptually: @a.push(4) creates a new list that is ((1, 2, 3), 4) and stores that in @a OK, but when you iterate over @a, it's flattened? (in reality that's not what happens underneath, but that's how it appears conceptually) yet another stupid question: how 'hash' function will be called? bacek: it will depend on context ((1, 2, 3), 4) is already "flat" I think that the ((1, 2, 3), 4) behaviour isn't even visible in slice context as opposed to ([1, 2, 3], 4) which isn't "flat" :-) pmichaud: hmm... What about '%h = (a=>b, c=>d)'? bacek: because we're assigning to a hash type (%h), whatever implements assignment will coerce the list into a mapping er, Mapping (Mapping being the immutable form of a set of pairs with no duplicate keys) so Mapping <=> Hash is the same relation as List <=> Array? other way around other way around is not better Hash (mutable) is to Mapping (immutable) as Array (mutable) is to List (immutable) jonathan: @a.push(4) conceptually means " create a new List from @a that has a 4 tacked on the end, and make @a reference that new List " did I say something different? ;-) oh, you did I read one of them backwards. pmichaud: OK, but in the implementation we can optimize that some. jonathan: yes, exactly. But what I finally figured out yesterday is that "@a" is a container just like "$x" -- the difference being its properties this also means we move %properties out of the immutables and into variables (mutables) like they should be. :-) pmichaud: so what's the difference between a @a and a $s container? @a has properties on it that say "I hold a List object" a type constraint, ok pmichaud: I think the @ sigil just promises that whatever it holds does the Positional role. Yes, a type constraint. jonathan: yes, that's better. Grrr. I'm tempted to just not use the Capture PMC and write it directly in PIR. hmmm? Just looking at getting captures vaguely working. personally, I think we may have to make some modifications to the parrot calling conventions for that Only really want 'em for implementing .* and .+ method calls... either that or we'll need to layer a bunch of stuff in/out of perl 6 subs Yeah, I saw that thread. ...but why should Capture PMC versus PIR make a difference? However, what did occur to me too was that we need to think about postcircumfix:[] and postcircumfix{} more generally. pmichaud: Because the Capture PMC doesn't have the right semantics, I don't think. It is mutable, for one. well, at the implementation level all of the types can be "mutable". It's more how they're used Sure. I know that the Capture PMC doesn't yet have a scalar component -- I was going to add that. however, the Capture_PIR object does have a scalar component. that is another thing on my task list -- to convert the various tools over to the Capture PMC instead of Capture_PIR (hoping to get some speed improvements) (postcircumfix:[] versus postcircumfix:{}) PCT is adding a keyed_int PAST::Var scope OK. that was really the underlying reason I implemented the register coercions this week. so that I can easily (and smartly) coerce the X in $P0[X] to be an int. But more generally, what if people define their own postcircumfix:[] methods? I guess maybe we can just make set_pmc_keyed_int in Object just delegate to the multi-method, though... either that, or we specially recognize postcircumfix:[] and cause it to generate a :vtable('...') flag. I was kinda aiming for the latter. Oh, that would work nicely too. when it comes to generating custom operators, I think we'll do it with special cases Sure. Well, that's a little way off yet. that's why operator overloading is near the bottom of the roadmap :-) * bacek still don't understand how 'hash' function should be called... bacek: you mean in %h = ( a=>1, b=>2 ) ? pmichaud: exactly... Well, plus or minus 2%. bacek: well, the longer answer is that your question involves some Deep Magic that we haven't implemented yet pmichaud: yeek. but essentially it will be called "automatically" whenever %h (a Hash) recognizes that it's being assigned to. i.e., when the %h container gets an assignment, it will automatically call 'hash' on the value to convert it into a Mapping pmichaud: heh. Where is the source of Deep Magick so I can at least look at it? :) in the short term we'll have to tell Rakudo programmers to explicitly write %h = hash( a=>1, b=> 2); (source of Deep Magick ---> "we haven't implemented yet" ) pmichaud: But looks like it already implemented for lists. or if you just want to know how it works, the answer is Synopsis 2, but I didn't understand it myself yesterday. er, "until yesterday" (implemented for lists) -- actually, what we have now is that Rakudo just fakes lists tolerably well. but even there we can find holes :-) I really wish I had an easy answer today. My best guess is that we'll have an easy answer in a week or two. (or, at least, easier) alas, I have to do about an hour's worth of $otherjob this morning I'll keep the window open but may be slow to respond jonathan: do my musings on Scalar make any sort of sense? pmichaud: have a good day. It's 11pm here :) % mj41_ has joined #parrot bacek: have a good night, then. Sorry I didn't have any more straightforward answers yet. BTW, I have another stupid question about parrot/rakudo. (stupid questions -- no such thing) token fatarrow { \h* '=>' 'b'". Because "'a'" is not "ident" % mj41 has left mj41!chatzilla@pc-jurosz.ro.vutbr.cz % mj41_ is now known as mj41 right In STD.pm "ident" declared as "alpha*", so (as I think) pugs should rejects such statements as well. But it accept them. 'a' => 'b' is handled by infix:« => » not by (in fact, STD.pm didn't have infix:=> until this past Monday :-) pmichaud: Are you thinking, create a Scalar that we can use as the container, which in turn references the PMC representing the value? jonathan: yes. pmichaud: there is no 'infix:=> in grammar... token infix:sym« => » ( --> Item_assignment) line 3265 OK, but not do this for list and array? Because they already are containers? jonathan: no my precisely, my thoughts 1. create a Mutable PMC that does what we think of for "Scalar" It seems that we may just have to do this to get the correct semantics in a neat way. 2. "Scalar", "Mutable", "Hash" are subclasses of Mutable sorry can't type that would be tkil. 2. "Scalar", "Array", "Hash" are subclasses of Mutable % mire_ has left mire_!~Frodo@85.222.174.210 pmichaud: hmm... In STD.pm? Array and Hash differ from Scalar in terms of how they implement the opcode -- primarily they enforce a constructor on the value (either 'list' or 'hash') all of the mutables have a %properties attribute that limits how we can assign to them (e.g., type checking) variables then are instances of Scalar, Array, Hash, etc. values, on the other hand, tend to be the immutables values can be containers, yes, but they aren't variables bacek: yes, line 3265 in STD.pm I think actually having a distinct container type, is probably the only sane way we can expect to support things like tying, further down the road. so, a List is a container, yes, but @a (the variable) is not itself a List. It's an Array that references a list. or, think of it this way if it helps: my $x = [ 1, 2, 3 ]; my @a = (1, 2, 3); in both cases we have a List with elements 1, 2, and 3 in both cases we have a variable that references a List pmichaud: 10x... Got it... There is 800+ lines diff between my and current version of STD.pm... so $x and @a are both implemented as Mutable -- i.e., they reference a value of some sort both $x and @a can reference List objects if we do .WHAT on $x or @a, then we get back the protoobject for what they reference, not the protoobject of the variable itself Right. It just delegates everything to its value, aside from assign? pretty much. There may be a couple of other things that aren't delegated or have to be otherwise intercepted and it handles binding, probably or does binding replace the container? I'm thinking neither (haven't thought deeply about binding yet) moritz: I think binding would replace the container. to me, binding is just tying a symbol to a mutable Right, which means changing the entry in the lexpad to point to another mutable (container) so my @a; my $x := @a; means that $x and @a are the same mutable OK, I think I agree with the Mutable idea. tene: i'm still in scrollbackland, but i noticed you added isa_ok to Test.pm. you should also add it to the list of tests that fudge understands (inside fudge) if it's not already there well, that's the path I'm going to take for now and see how far I get. I'm guessing I can take some implementation cues from the delegate pmc particle: how long are we going to let the list of fudge-understandable-tests get? moritz: yes, please do blog about your rakudo patches! I'm thinking that fudge gives us a nice "spec" for what a Test.pm ought to implement. (isa_ok is already in fudge.) (just checked) pmichaud: Does it mean that someone have to add roto infix:«=>» is equiv(infix:<=>) { ... } into grammar-opr.pir? s/roto/proto/ bacek: yes. bacek: exactly. And write a sub for it. (adding the proto should get 'a' => 'b' to parse properly, though.) fudge currently has: my $IS = '\\b(?:is|ok|is_deeply|is_approx|isnt|like|unlike|eval_dies_ok|cmp_ok|isa_ok|use_ok|throws_ok|dies_ok|pass|flunk)(?:\\b|_)'; pmichaud: yes it is. (fudge $IS) that seems like a reasonable set of test methods. :-) * bacek got +2 to Deep Magick bacek++ * pmichaud remembers that he still has about an hour of $otherjob to go, but is having too much fun chatting on #parrot. % AndyA has left AndyA!~andy@c-68-33-170-161.hsd1.md.comcast.net pmichaud: 'undef $otherjob' bacek: heh. that may happen soon, yes. since I've had $otherjob for over 18 years. I suspect $otherjob.funds($parrot) (even though my role in $otherjob has changed frequently -- it's still the same employer for 18 years) Or rather $otherjob.funds(%pmichaud['parrot']) donaldh: You shoud use angle braces :) :) * donaldh is parrot-newbie too. * bacek Geofrey mode=on rt #53666 * bacek Geofrey mode=off * particle wishes more of the perl 6 talk would happen on #perl6 ...greater, more focused audience Much of this seems to be 'how to implement Perl 6 in Rakudo' No? well, maybe. rt#53666 looks good to me. It probably should have some POD documentation in front of the .sub, and we should check if there are any relevant spec tests. pmichaud: if you could, put tasks like converting Capture from PIR to PMC in rt, so somebody can pick it up we already have a Capture PMC that looks like a reasonable implementation I think it got converted/implemented as part of pdd17pmc pmichaud: ok. I'll add do it. it's just missing a scalar component, and some methods the trickier part of the conversion is switching PGE and PCT to using the Capture PMC instead of Capture_PIR. so, is it two tickets, or just one? pmichaud, I thougt @a = [1,2,3] was supposed to conceptuellement copy the list to make it an array under the wood, it may morph the list, but that's antoehr sotry At the moment, I'm trying to work out why subclassing a Capture in PIR doesn't seem to work out too well. Just another... hmm... question. Is anyone implemnting 'sort' for right now? Because I going to practice in PIR programming and implement trivial merge-sort. for 'List' bacek: I don't think 'sort' has been implemented. pmichaud: definetly not. jonathan: it often has to do with ProxyPMC versus native PMC bacek: afaik, nobody else is working on 'sort' at the moment pmichaud: excelent (from my egoistick POV :) % jhorwitz has joined #parrot pmichaud: Ho! Will 'Dark Magick' work if I'll replace 'infix:=' pirop=>'copy' with handcrafted assignement? don't rewrite sort. just use the sort method you'd inherit from the parrot PMCs. bacek: no. infix:= is pretty special. There's a fair amount of Dark Magick to be done there, even. e.g., getting infix:= to recognize when the rhs is to be parsed at item assignment or list assignment level DietCoke: Inherited methods works only on integers AFAIK. pmichaud: This magick is definitly dark... bacek: as an example, take a look at infix:sym< = > in STD.pm :-) pmichaud: infix_postfix_meta_operator? bacek: are you asking what that is? bacek: or is that related to infix:sym<=> somehow? % cjfields has joined #parrot pmichaud: related to infix:sym<=>. (infix_postfix_meta_operator) is what handles operators like += *= /= //= etc. token infix:sym<=> () { { self. eq '$' ?? make Item_assignment($/) } Looks pretty simple... Or I miss somthing... right. For infix:= , we check the sigil of the left hand operator, and use that to decide whether to parse the rhs as an Item_assignment or a List_assignment. s/left hand operator/left hand argument/ (still in scrollback but much closer to realtime) pmichaud: fudge list should be just reasonable Test.pm funcs, and isa_ok is reasonable (and already in there, TimToady++) particle: agreed. I'm just wanting to avoid a huge amount of test function proliferation in fudge (and by extension, in Test.pm) it does beg the question, however, if Test.pm should be renamed e.g., to SpecTest.pm donaldh: yes, this is implementation talk for rakudo, but rakudo isa perl6. if it's talk about changes required to *parrot* to implement rakudo, it belongs here (#parrot) having SpecTest.pm might avoid naming conflicts with other Test::* modules and make it clear that it's intended for testing specs. pmichaud: capture and pge/pct -- tickets are cheap. make two and relate them particle: I almost need a ticket just to remind me of all the tickets I need to create :-P % slightlyoff has left slightlyoff!~slightlyo@194.158.33.174 what about Spec::Test, or Test::Spec? is parsing namespace colons too much for a baby perl6 implementation to handle? it might be. % AndyA has joined #parrot I suspect a baby perl6 implementation might be able to fudge it, though. I'm not sure I want it to go into the Test:: hierarchy. maybe Perl6::Spec::Test is better? anyway, keep-it-simple is the order of the day for now. pmichaud, is there a reason for nqp not supporting infix:? cognominal: just haven't implemented it, I guess. feel free to add , , , you forgot the ultimate "looser" operator :) hmm? they have a loose precedecence oh. it's not so much "forgot" as following a principle of not adding things until I needed them. :-) nqp aims at conciseness and regularity instead of completeness and dwimminess % slightlyoff has joined #parrot less surprise is good too % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru well, it depends. Almost by definition we expect nqp programmers to be okay with a bit of rigidity -- nqp isn't intended to be a general-purpose programming language. (It might evolve to that someday, but at present it's not.) DietCoke: (late night gaming) -- yeah, that's starting to be an issue for me also. :-P * jonathan is having a hard time working out why subclassing Capture to use in Rakudo isn't working out. what's not working? see "doesn't work" pmichaud: You try to push things onto it, and get back a "push_pmc not implemented in class Undef" message. push from PIR? as in push capture, $P0 ? Yes. Tracing through it with the C debugger, I can see what where it should be getting an instance of the Capture PMC back, it's getting an Undef instead. (Inside class.pmc) oh, I think I know why. It's strange because inheriting form ResizablePMCArray to get List works just fine. And I can't see that much different. Other than the use of ATTR in Capture.pmc. Which I don't think should affect things... (checking.) oh, perhaps that's now resolved. There used to be cases where individual methods had to check for PMCProxy before dispatching other operations but perhaps that's being handled by the PARROT_CAPTURE(SELF) macro iirc, the issue is that SELF in an object of the inherited class refers to the ProxyPMC self and not the Capture self OK, but I don't understand why Capture has this issue, and other PMCs that we subclass don't. right Like Hash, ResizablePMCArray and so forth. oh probably because of the ATTR OK.