% iblechbot has joined #parrot or maybe i'm just retarded, can't even get the windows binary to work properly... % Ademan has left Ademan!~dan@h-67-101-102-38.snfccasy.dynamic.covad.net * Tene working on placeholder vars. r27374 | fperrad++ | trunk: : [Lua] : - implement bytecode loader in a PMC diff: http://www.parrotvm.org/svn/parrot/revision?rev=27374 Hm. Looks like I've got a very basic version of placeholder vars working, but it doesn't do lexicographic ordering And I think there were a few other details of placeholder vars that I really should pay attention to. No additional spectests fail, and it looks like four more spectests compile. Tene++ purl: rt? rumour has it rt is just RT (http://bestpractical.com/rt) or (:rt3) or (: rt bugs) or Obra's trouble ticketing system or the first IBM RISC workstation (http://www.contrib.andrew.cmu.edu/~shadow/ibmrt.html) or the bombsquad or the Right Thing or very very capable and open-source or an application framework that bundles a ticketing system or obra's baby or SOOOO slow :-S or email mailto:perlbug-owner@perl.org for access Let's see if I can find tests of placeholder vars in the pugs repo... % Ademan has joined #parrot There are no explicit tests of placeholder vars in the pugs test suite. another TODO task for Auzon++ (unless somebody else does it in the mean time) I can't quite find any documentation on where I should be adding tests for this. where are they specced? S06 maybe t/spec/S06-signatures/placeholders.t ? So I should make a new test and commit it to pugs. aye or I can do it if you want me to Sure, that would be great. Oh, there's a $:named form. Apparently not used in the pugs test suite at all. That should be easy. Tene: the $:named is very new Tene: I added S06-signature/positional-placeholders.t % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se smartlinks are still missing :( am I right in assuming that a sub without a signature can have placeholders? No. Wait, I misread that. A sub with a signature *cannot* have placeholders. that would be sub foo () { ... } "Also, it is illegal to use placeholder variables in a block that already has a signature, because the autogenerated signature would conflict with that." but sub foo { ... } doesn'T have a signature, right? just: sub foo { ... $^a } Right. ok because the spec only mentions bare blocks Oh, rakudo doesn't have : allowed as a twigil. How new is that? 1 or 2 months Okay. does rakudo do any LTM? Not yet. Hm. Separate file for named and positional placeholders? Or just rename test to placeholders.t? separate files intentially So then a third file to test that they both work in the same sub? if that's supported, yes Okay. but the rakudo effort showed that test are useless as a start if they are too complicated so I like to keep the more complicated ones in separate files that are just completely skipped as a start Okay. r27375 | paultcochrane++ | trunk: : [lua] Keep c_parens coding standard test happy diff: http://www.parrotvm.org/svn/parrot/revision?rev=27375 Tene: may I charge you with the task of fudging the placeholder tests once your patch is accepted? moritz: they need to be fudged? Tene: I don't know ;-) Tene: since I have no idea what your patch can do, and what don't I'm in no position to assess that I kept them simple, so I hope it's not necessary No, not necessary. good My policy so far is to just commit as long as I can verify that it doesn't break anything. r27376 | tene++ | trunk: : Basic support for placeholder vars in rakudo. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27376 % iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-127.dynamic.mnet-online.de rakudo gets this wrong: multi sub t ($a) { say 'one positional' } multi sub t (:$a) { say 'one named' } t(1); purl: rakudobug? rakudobug is mailto:rakudobug@perl.org Jonathan will be delighted ;) % mj41_ has joined #parrot Well I've been delighted with his work lately, so it's a fair trade. ;-) % mj41 has left mj41!chatzilla@pc-jurosz.ro.vutbr.cz % mj41_ is now known as mj41 The problem with working at night is that I can't get immediate feedback on things like the :-whitespace thing. Oh, maybe that's discussed in the spec what :-whitespace thing? many of the tests have the following: $obj.meth:{here is a block}; STD.pm and rakudo's grammar both require whitespace after the : there. So it's a parse failure. hurm S06:613 Invocants may also be passed using the indirect object syntax, with a colon after them. The colon is just a special form of the comma, and has the same precedence: That's not the same. That's like: I don't think a comma needs a space after it meth $obj: {here is a block} you're right look for /legal forms above into a list operator by/ dunno what line that is in S06? S12 Sorry. I see space after the : in all of those examples. in S06:2425, is that the same construct? there's an exxample &substr.assuming:str($text):len(Inf); ah, but it's not a block in that case The rule in STD.pm is in methodop: | ':' That also doesn't have a , between :Str and :len in the example right above that, which I think isn't allowed. * moritz isn't competent enough to answer the question :( % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru Thanks for the help, moritz. :) % Zaba has joined #parrot % allison has left allison!~chatzilla@dsl-241-25-20.telkomadsl.co.za Okay, time for bed. % purl has left purl!purl@sentient.life % purl has joined #parrot % wknight8111 has joined #parrot % wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % mire has joined #parrot % iblechbot has joined #parrot % wknight8111 has joined #parrot % wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net % cosimo has left cosimo!~cosimo@pat-tdc.opera.com % ask has left ask!~ask@pat-tdc.opera.com % cosimo has joined #parrot % claes has joined #parrot % claes has left #parrot % ask has joined #parrot % wknight8111 has joined #parrot % jq- has joined #parrot % jq- has left jq-!~jquelin@merlin.mongueurs.net % tetragon has left tetragon!~seneca@216.126.67.44 % jan has joined #parrot % gryphon has joined #parrot % masak has joined #parrot % wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net how up-to-date is languages/perl6/docs/STATUS? it was last updated on 2008-04-17 % Psyche^ has joined #parrot has anything happened since in rakudo that was not entered? grammars were implemented, they aren't mentioned tehre I would change it, but (1) I'm not sure I'm the right person, (2) I'm not sure I have a commit bit you don't have a parrot commit bit ;) but you can skim over the last commit logs... no. if there is such a thing, I don't have it build a patch STATUS is probably out of date and send it rakudobug@perl.org moritz: that I can do lots has happened in rakudo since STATUS was last written pmichaud: I see a point in keeping it up to date sure, I agree good :) nobody will reject helpful documentation patches ;) * masak gets on with it % Patterner has left Patterner!~Psyche@e177238175.adsl.alicedsl.de % Psyche^ is now known as Patterner I updated STATUS a little while ago, but stuff has happened since then, it's certainly out of date. :-) I'll take a risk and start reading diffs from 2008-04-16 could just read the logs svn log -r '{2008-04-16}:head' % mire has left mire!~Frodo@252-172-222-85.adsl.verat.net pmichaud: sorry, meant logs that's what I'm doing doing is better than talking thanks, purl my pleasure masak and copying verbatim from the feature additions I find hard to go wrong doing that, I figure Yeah, though I tend to implement a given feature over several smaller patches, to get more karma^W^W^Wmake it easier to see what each change goes. s/goes/does/ (smaller patches)++ (more karma for jonathan)++ er, I guess the last is just jonathan++ :-) Jonathan: I see that. but still the new features seem to be on about the appropriate chunk level for STATUS karma jonathan jonathan has karma of 521 as long as it's not "junk level" ;-) Jonathan: logs say WHENCE is (partially) implemented masak: Partially, yeah. are others, like WHAT and HOW also implemented? Enough for the common use cases. STATUS doesn't say WHAT is implemented. There's implimentedish, but there's more to do there. that's what I'm asking ;) Does WHAT return the Right Thing? for many things we have "partial implementations" as in, object not a string? so it's hard to put everything into a "yes/no" box. I forget. WHAT returns a protoobject. (in the implementation) Ah, OK, good. I think that HOW also returns the class metaobject.... but I'm not sure of that. Then WHAT is done. HOW currently returns the Parrot class. right I've not made my mind up how right that is yet. :-) we should put a note in STATUS saying what "implemented" means I'll write WHAT, HOW, WHENCE then I do know we have to attach ^method's to the metaclass. there, mail sent pmichaud: have a couple of minutes to look at a ticket for me? in a couple of minutes, yes Okay, thanks. http://rt.perl.org/rt3/Public/Bug/Display.html?id=53804 I was about to look at that one -- I suspect the test is wrong but need to re-read the synopses to check purl: parrot logs? wish i knew, tene I saw the conversation in the scrollback :-) pmichaud++ # uses eyes for reading Tene: http://irclog.perlgeek.de/parrot/today % peepsalot has joined #parrot If that's the indirect object call thing - I'm not sure which is right, but even if you tweak it to have a space, I think it still gives a parse error. Jonathan: it's not inderect object call. Indirect method call syntax is spelled like: meth $obj: $arg1, $arg2; Ah, OK. karma more karma for jonathan? more karma for jonathan has karma of 1 (more karma for jonathan)++ this is for something like $foo.bar: args (karma karma karam karma karma baked beans karma karma and karma)++ Ah, OK, that syntax. STD.pm seems to require a space after the colon As mentioned in the ticket. however, S02 has for @x.grep:{ 0 <= $_ < all(@y) } {...} Hm. which may just be a typo in S02, also istr that at one time :{...} was a special syntax for passing subs. But I think that's since disappeared. s/subs/closures % davidfetter has left davidfetter!~chatzilla@start.fetter.org what's the rationale for forbidding :{} w/o a space in between, again? I'm not sure there is a rationale ;) I don't know that the required space is specifically for { } it may have been to prevent things like $foo.bar:a(1) masak: as written, STD.pm requires a space for *any* args. not just args which happen to be closures. ah anyway, I don't have an answer at the moment. My suggestion would be to add a space in the tests I'd suggest to wait for TimToady, because that affects quite many tests I also question whether .min and .max remain the same since we now have infix: and infix: so it's [min] @list? Yup. Reduction operator. well, that's one way to do it. just because we have [min] @list doesn't mean we can't have @list.min :-) Not sure if that means no min method for lists though... It *is* Perl. TMTOWTDI. ;-) but I think the minmax stuff in S29 predated the reduction operator *preceded does anyone else besides me think that rt#53808 belongs in the 'perl5' queue? % rdice has joined #parrot the elsif guy? I think he probably meant perl5, but he's going to get the same answer from either crowd, neh? No point in yelling at him about the wrong queue on top of that. oh, I wasn't going to remark on it -- I was just going to move it off of the perl6 queue I suppose I could silently mark it resolved, also *cough* spam queue *cough* as long as it's not in the parrot queue, I don't care. =-) * pmichaud moves it to the parrot queue, just to irk Coke. (just kidding :-) (irking coke)++ I think RT#39329 can be closed -- anyone disagree? I am so irked about my weight loss program, you can't hurt me. =-) pmichaud: is the issue leo mntioned resolved too? Coke: I'll double-check 3 tickets to go. looks like a few were missed in integer.pmc wonder if we need to be more thorough about testing such things. the problem with RT#39329 is that it's kinda of like trying to prove a negative there's not really a definitive way to know that everything has been converted, short of reviewing all of the .pmc code welp, for now, just comment that you found more cases in integer, and leave it for someone else to finish. I was going to go ahead and fix the cases I found :-) turns out that RT#53108 was the same problem as RT#39329 pmichaud++ % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk actually, there's some oddity in integer.pmc so I'll just comment on it and let someone else look at it. pmichaud-- ! ;) % ask has left ask!~ask@pat-tdc.opera.com RT #39132 should be pretty easy to close. (now) % iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-145.dynamic.mnet-online.de (followup on :{...}) :{...} is an adverbial closure so the tests have it correct. it gets parsed by (at least, I think colonpair handles it) that fits nicely. <-- this is an adverbial closure. I would note that you can write grep:{...} {...} because :{...} is adverbial, but grep: {...}, {...} requires the comma since it's just an argument er, actually, the first form probably doesn't work either...hmm... % Coke has left Coke!~coke@cpe-72-228-52-192.nycap.res.rr.com 'cause it won't parse the second {...} as args since it only can parse the adverb after deciding grep was out of args, i think @args.grep:{...} is fine though, since the list is on the left TimToady: So does @args.grep:{...} parse under STD.pm? {...}.grep:{...} # seems confusing % uniejo has left uniejo!~uniejo@langebro.adapt.dk I just removed every occurence of \w:{ in the test suite under spec/ moritz: ...? * purl quietly listens while the crickets chirp \w:{ ? pmichaud: like occurences of @list.grep:{...} oh pmichaud: s/(\w):{/\1: {/g I think that may be wrong, now, since TimToady reminded me about adverbial closures I looked over all occurences and they were all map:{block} and grep:{block} and the like so @list.grep:{...} is the same as @list.grep :{...} ? map is defined as our List of Capture multi method map ( @values: Code *&expression ) why should the expression be adverbial? the *& is what allows it but is it forced to be adverbial? no so, in @list.grep:{...} the :{...} is parsed by the subrule in then the whitespaces aren't wrong, at least ;-) otherwise grep: {...} wouldn't work well I was thinking adverbs in expect_term, but I see it's ambiguous... er, expect_term, right (I miswrote) but there is the difficulty of distinguishing from infix:{...} I'll have to think about that some, I guess.. anyway, rakudo parsefails because it doesn't have * on terms anywhere yet well, technically, the :{} is not on a term, but on the prior operator, which happens to be .grep mmm hmmm. it tends to skip the intermediate term in cases like 0..10:by(3) but we've got the same difficulty there, if someone writes 0..$max:by(3), as to whether the identifier eats the adverbial or whether we have to require a space there right. I think when we originally discussed it I was thinking that infix:() etc is specially recognized but I think we generalized to ident:() at some point without recognizing the difficulty so now we have "use Perl:<...>" for instance, and that's not because Perl is special cased like infix would be so maybe we will have to change grep:{...} to grep :{...} or grep: {...} hrmm... can rakudo grammars have attributes yet? particle: as in ... ? particle: gcc-4.2.0-3.aix5.3.ppc.rpm grammar Perl; has StrPos $.ws_from; paco++ particle: no, that doesn't quite work yet. % [1]JordanG has joined #parrot * particle just did a diff -u between STD.pm and grammar.pg i'm studying the output I'm not exactly sure how that would work, anyway -- at least not as PGE currently models grammars at some point we're going to have to support attributes, roles, classes, constants... protos of course % JordanG has left JordanG!~JordanG@witnet.wit.edu % [1]JordanG is now known as JordanG seems like huge changes to pge are required if I focus on the totality of everything we'll have to support "at some point", then I think we don't make much progress. no, PGE is just a fancy compiler. It doesn't have to understand all of that other stuff. okay, pmichaud. argggh stupid bot Stupid is as stupid does. no, PGE no, PGE? PGE? hmmm... PGE is just a fancy compiler. It doesn't have to understand all of that other stuff. er. right. no, PGE is the Parser Grammar Engine okay, pmichaud. anyway, as I said, PGE really don't have to worry about attributes, constants, classes, etc. the core of PGE simply compiles regex syntax it's Rakudo that will handle the other items ok. point. but I guess it will have to support some more modifiers eventually ;) the issue at the moment is that PGE conflates grammars with match objects in order to get inheritance working it does need to support hashes ...hashes? maybe ident:{...} can always parse as ident :{...}, since the run-time analog of ident: is actually ident:[$a, $b], not the curly form... I think conflating grammars with match objects is a necessity--that's what STD5 does right now. it also happily conflates match objects with cursors :) TimToady: oh. Okay, I'm glad to see I was on the right track there, then and all of the fates and peeks and such are now communicated through the unified "match state" cursor however, it does make me wonder about something like has StrPos $.ws_from; I thought PGE was still sub based no, PGE has been method-based for a very long time grammars have to be able to send additional info along through the match state argggh (I need to stop writing "no, ") though STD5 cheats and pulls that down into Cursor5 because I don't have cloning in p5 :) method-based pge was the only way I could get inheritance to work reliably but it's been that way since, oh, 2005 or 2006. cool, I've been mistaken for a goodly long time then! :) I blame my surgery. :) I blame a lack of documentation. :) % Eevee has left Eevee!~eevee@c-67-160-3-54.hsd1.wa.comcast.net TimToady: btw, we received the books back okay, many thanks. It is greatly appreciated. well, if only I were omniscient, the problem wouldn't arise... the problem with demigods is that they're only demiomniscient... * TimToady wonders what a hemidemisemigod would look like... 0.125`god I suspect pmichaud, and in actions.pm, I can't get a straight way to get at the length of a match which makes adressing #52276 difficult "length of a match"? you mean "number of children nodes"? $/.chars ? we don't use this word "length" any more :) arf, I keep using length I meant numbers of matches cognominal: +@($/) +$/ or $/.elems or ... (not +$/) right that would integerize the string (I keep making that mistake also :-) actually, it numifies the result object which might not be a string. :-) I keep making that mistake too. @() should work in a numeric context which reminds me, is there a convenient method for getting the text associated with a match object (even if a result object has been set)? istr we discussed .text at some point but it was never formalized/codified/officially adopted as long as we have .from and .to we can probably have something that returns the appropriate substr, and .text seems as good as anything I've been using .item in STD5, but that's because I have my head in the sand re result objects right, but .item returns the result object, yes? yes okay, just checking. i'm still here, pmichaud. does .list still return the positional captures, and .hash the named ones? yes excellent. I'm wanting to make that change to PGE. say +@($/); # gets me Null PMC access in type() since those are just the contextualizers @ and % in theory we have .slice too but I'll not insist on it (yet) TimToady: Thank you. :-) cognominal: in NQP or Rakudo? if in actions.pm, say requires the () oops I always forget it yes, I'm thinking of adding rudimentary listop parsing to nqp, since people always forget the parens. but that does complicate things a bit. it is just a question of warming up to a language. when I program in PIR, I put semicolon everywhere I don't quite understand why elements in a match is needed for [], though. I suspect the array composer isn't coded right if that's the case. what's this "Cannot put to non-PIO PMC" stuff about? Infinoid: seems to be a problem with the makefile generation. because it is the comma operator with 0 or 1 arguments so there is no comma visible well, with 0 arguments there's no comma operator. nor is one needed even with 1 argument there's no comma operator that's the problem in rakudo, [