% Zaba_ is now known as Zaba moin r27405 | fperrad++ | trunk: : [docs] : - docs/strings.pod removed since r27305 diff: http://www.parrotvm.org/svn/parrot/revision?rev=27405 r27406 | fperrad++ | trunk: : [docs] : - rename HQ9plus to hq9plus (new implementation since r26620) diff: http://www.parrotvm.org/svn/parrot/revision?rev=27406 % Ivatar has joined #parrot % jonathan has joined #parrot % desertmax has joined #parrot r27407 | allison++ | pdd25cx: : [pdd25cx] Throw an exception when attempting to remove an exception or event handler that doesn't exist. % tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com diff: http://www.parrotvm.org/svn/parrot/revision?rev=27407 % tetragon has joined #parrot % teknomunk has left teknomunk!~teknomunk@r74-195-239-111.stl1cmta01.stwrok.ok.dh.suddenlink.net r27408 | allison++ | pdd25cx: : [pdd25cx] Update the expected error message when attempting to delete an : exception handler when there is none. TODO rethrow test and a dynamic scope : test. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27408 % iblechbot has joined #parrot % masak has joined #parrot % ask_ has left ask_!~ask@pat-tdc.opera.com % desertmax has left desertmax!~markus@212-183-124-113.adsl.highway.telekom.at % desertmax has joined #parrot % mire_ has joined #parrot % desertmax has left desertmax!~markus@212-183-124-113.adsl.highway.telekom.at % kid51 has joined #parrot % Ivatar has left Ivatar!~graham@tu055.demon.co.uk r27409 | allison++ | pdd25cx: : [pdd25cx] Clean up stray tab added by unhelpful Vim config. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27409 r27410 | allison++ | pdd25cx: : [pdd25cx] TODO rethrow test. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27410 r27411 | allison++ | pdd25cx: : [pdd25cx] Change several more instances of 'throwcc' to 'throw'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27411 % ambs has joined #parrot % rdice has joined #parrot % mire__ has joined #parrot % mire_ has left mire_!~Frodo@85-172-222-85.adsl.verat.net % Ivatar has joined #parrot % mire_ has joined #parrot % mire__ has left mire__!~Frodo@207-168-222-85.adsl.verat.net r27412 | fperrad++ | trunk: : [Lua] : - translates first opcodes diff: http://www.parrotvm.org/svn/parrot/revision?rev=27412 r27413 | allison++ | pdd25cx: : [pdd25cx] Bringing the pdd25cx branch up-to-date with trunk r27411. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27413 % mire__ has joined #parrot % kid51 has left kid51!~jkeen@pool-68-237-5-210.ny325.east.verizon.net % kid51 has joined #parrot % mire_ has left mire_!~Frodo@133-172-222-85.adsl.verat.net % tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com % rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com % kid51 has left kid51!~jkeen@pool-71-247-56-231.nycmny.east.verizon.net % grim_fandango has joined #parrot Tene: (sorting) -- I had been thinking that for sorting we would use an insertion sort as placeholder variables are encountered as opposed to trying to call a sort algorithm % NotFound has joined #parrot Hello. * ambs waves NotFound: were you looking at the case of having NULL keys in hashes? pmichaud: I left the issue expecting chromatic decision. okay. Last night while scanning RT tickets I also found RT#43485: Null Key Strings Make Hashes Cry apparently chromatic encountered something similar :-) (about a year ago) % mire_ has joined #parrot I can't understand scheme But the issue is clearly than null keys are not valid, the code in hash.c assume they never are. okay. I was just pointing out the ticket in case it was useful to you or chromatic. :-) % mire__ has left mire__!~Frodo@251-170-222-85.adsl.verat.net (especially since chromatic is wanting to reduce the number of outstanding tickets for the may 20 release) I think the check for nullness is usefule, maybe a PARROT_ASSERT about that help catch bugs. oh, that might be good, yes. Talking about solving tickets, someone looked at 46629? seems reasonable to me. at least within the limits of the Complex implementation, which has some oddities At least is testable. r27414 | allison++ | pdd25cx: : [pdd25cx] Reverting two headerizer changes, suggested by chromatic. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27414 % mire__ has joined #parrot With the assertion in place, the test case in 53890 is catched. src/hash.c:342: failed assertion 'bucket->key' % mire_ has left mire_!~Frodo@3-168-222-85.adsl.verat.net Patch sended to RT#53890 pmichaud++ # nice Rakudo work Especially happy to see the fatarrow parsing bug fixed. yes, that was going to be an ongoing pain :-) fortunately it wasn't too difficult to correct :-) If one understands PGE, at least. ;-) I think I also have a way to fix the -> bug Other than a fail hack in the operator parser? yes Cool. I'm very happy to have you take care of the parser issues. Though I do want to try and understand PGE internals better at some point. unfortunately it means refactoring the OPP a bit...back to the form I had originally. :-( but it'll be more std.pm-like (since std.pm ended up using the form I had originally :-) Closing in on STD.pm is generally a good thing. I try to edge us further towards it now and then. I'm fairly sure I'll try to spend some dedicated time over the summer to getting ltm working That would be a big step forward. Larry mentioned he was parsing something like 2000 chars a second with his prototype in the last call. it may also be a substantial rewrite of pge. But fortunately the abstractions are such that I don't think it'll impact anything I'm hoping the Parrot implementation might manage more than that. ;-) oh, I'm sure it will. :-) OK, good. I'm even thinking of rewriting PGE in C it depends on how the ltm code is structured. It may be the only way to get the performance we need, and working in something higher level than PIR may well make development easier. heh I went with PIR because *it* made development easier. :-) "higher level" ;-) Yeah I can almost guarantee that a C implementation will be less accessible True. There's pros and cons either way. I'm pondering how best to spend my Rakudo time. While objects are very high in the list, I think there's plenty of other stuff that wants attention too. I don't have a good answer at the moment :-| I'm pondering dividing it half and half - half to incrementally get S12 in, but spend the rest on other bits: builtins, applying patches people send it (or giving feedback when they're not right), fixing other bugs, etc. that seems extremely reasonable. It's at least a good start. s/but/and/ I'd say go with that and feel free to change the mix as you go I stubbed in parsing a bunch of S12 stuff on Tuesday that I plan to fill out. got it parsing, but panicing with an "unimplemented" message...prefer to make it clear when stuff parses but shouldn't be expected to work. r27415 | allison++ | pdd25cx: : [pdd25cx] Updating exception names in merged code. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27415 So filling those out will likely by my next OO task, and then after that I plan to take on attributes in roles. I think I'll work on spectest a bit this morning r27416 | allison++ | pdd25cx: : [pdd25cx] Renabling generation of src/stacks.str. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27416 (spectest work)++ I'm mostly offline for the next 3-4 days with moving. (whoever fixed multiple pairs in sub calls)++ Will do my Rakudo day towards the end of next week, once I've got into the new appartment etc. that should work well with me OK, great. afaict I don't have anything coming up for the end of the week I've got a lot of talks to prepare for the end of the month. I'm envious. Wish I could get to do as many talks as you're getting to do :-) Are you planning to get return and other control exception-ish stuff in soon? for various values of "soon" (more) it would be better to get list assignment done first, as return will somewhat want that Talks - yes, I really enjoy sharing with people what's getting done on Perl 6. but return comes shortly thereafter. OK, makes sense. heh those are #1 and #2 :-) #3 and #4 are keeping me entertained. ;-) #5 is somewhat high as well -- just need to update the Digest::MD5 library a bit first is that "selected libraries written in Perl 6"? yes Digest::MD5? rumour has it Digest::MD5 is on CPAN the blocker is that PCT doesn't generate unique sub names (across multiple invocations) purl, sure it is OK, ambs. so, we'll md5 the source in order to produce a unique component of the name jonathan: if there's something I can do to help you (for example preparing very simple test cases) please let me know (test cases)++ moritz: I would *love* more OO tests. jonathan: what kind of OO tests? You don't even have to write some of them - there's plenty of starting points in the Pugs test and also the Moose ones. moritz: The most helpful thing to me at the moment is tests for the OO features that are already implemented in Rakudo. So as to be sure they don't accidentally get broken. jonathan: so mostly inheritance and role composition? So inheritance, attributes, role composition, the cases of handles that are done so far... methods ok WHENCE stuff, particularly in calls to new. (e.g. for initializing superclasses) I plan to work on private methods shortly. pmichaud: md5 - understand now, makes sense. % mire_ has joined #parrot jonathan: ok, that can get me started pmichaud: I think we also need to be able to have a way to emit a sub and choose what class is used. % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt % mire__ has left mire__!~Frodo@202-170-222-85.adsl.verat.net So we can differentiate method from regex etc I don't think Parrot supports that; I was pondering proposing a :class('Name') adverb for .sub ....differentiate method from regex? in what sense? They are different types in Perl 6. ohhhh yes, I agree we need a way to tell PIR what sort of Sub object to create. I think we might need that to get Submethod's right. Or at least, it's one way. well, we definitely want a compile-time mechanism to distinguish the various types of code objects Right, agree. We don't want to have to fix that up at runtime. I've mentioned it a couple of times before but haven't gotten any traction. (but also haven't pushed it hard because there are other fish to fry) I'll send my proposal in complete with an offer to impelement it. :-) that's more than I can do at this point (the "offer to implement it" part) although I'm rapidly getting to the point of understanding more about Parrot internals Hopefully it's not so hard. r27417 | allison++ | trunk: : [cage] Add svn:ignore property to generated file src/call_list.txt. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27417 % grim_fandango has left grim_fandango!~matt@bas2-kingston08-1177655568.dsl.bell.ca % desertmax has joined #parrot % wknight8111 has joined #parrot % wknight8111 has left #parrot % wknight has joined #parrot % wknight is now known as wknight8111 % radhios has joined #parrot % nopaste has left nopaste!~opaste@202-154-105-237.people.net.au % TonyC has left TonyC!~tony@202-154-105-237.people.net.au r27418 | pmichaud++ | pgeupdates: : Branch for PGE/S05 method updates diff: http://www.parrotvm.org/svn/parrot/revision?rev=27418 % davidfetter has joined #parrot % nopaste has joined #parrot % Senaka has joined #parrot seen infinoid infinoid was last seen on #parrot 19 hours and 58 minutes ago, saying: Cardinal Fang, fetch ... the comfy chair! :( % Senaka has left #parrot % Theory has joined #parrot % tetragon has joined #parrot r27419 | allison++ | pdd25cx: : [pdd25cx] Replace 'internal_exception' with 'exit_fatal'. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27419 allison@perl.org | Concurrency Tasks: link: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks dalek's url is at http://xrl.us/bjqpy % wknight8111 has left wknight8111!~chatzilla@pool-72-92-20-41.phlapa.east.verizon.net % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net % masak has left masak!~user@130.238.45.242 % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % cognominal has left cognominal!~cognomina@82.67.232.89 % rdice has joined #parrot % wknight8111 has joined #parrot % cognominal has joined #parrot % ambs has joined #parrot % janus has left janus!~janus@e182076081.adsl.alicedsl.de % wknight8111 has left wknight8111!~user@pool-72-92-20-41.phlapa.east.verizon.net % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt % peepsalot has joined #parrot % peepsalot has left peepsalot!~peeps@cpe-67-9-161-48.austin.res.rr.com % peepsalot has joined #parrot % guru has joined #parrot % ruoso has left ruoso!~ruoso@201009086089.user.veloxzone.com.br % Theory has joined #parrot % desertmax_ has joined #parrot pmichaud: the last thing I'm still considering is how to detect that a signature was given. Just scan the symtable every time we encounter a new placeholder var looking for vars that don't contain ^ as a twigil and throw an exception if we find one? % desertmax has left desertmax!~markus@62-47-174-122.adsl.highway.telekom.at % ruoso has joined #parrot well, scanning the symtable might not be enough % ambs has joined #parrot since other symbols are there easier might be to set a flag on the block to indicate that it has a signature since we put a signature on the block before we scan it Any suggestion on how I can do that? Are there arebitrary name/value keys I can throw at a past node? well, you can stick anything you want in the node's symtable :-) So adding a "ZOMGLWEHAVEASIGNATURELOL" entry to the symtable would be acceptable? it's within the spec. :-) whether it's "acceptable" is another question :-) % mire_ has left mire_!~Frodo@38-170-222-85.adsl.verat.net The two other things I'm going to have to track down, then, are what sort of error to create and how to create it, and whether I store placeholder vars as '$a' or '$^a' creating an error is just $/.panic("message") placeholder vars need to be '$^a', since $^a and $a are distinct variables (iirc) * Tene nods. pmichaud++ % mire_ has joined #parrot % pfig has left pfig!~pfig@208-78-102-38.slicehost.net % pfig has joined #parrot r27420 | pmichaud++ | pgeupdates: : [pge]: : Initial conversions to correspond to S05 updates: : 'get_scalar' => 'item' : 'get_array' => 'list' : 'get_hash' => 'hash' diff: http://www.parrotvm.org/svn/parrot/revision?rev=27420 % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net Hm. sub foo { say "make and return a sub to say: $^a"; my $x = sub { say $^a }; return $x } % ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt pct still needs a little work on closures, I think. placeholders are always local to the sub they're used in, I guess. correct. no, it's not! I would write that as sub foo { my $a := $^a; say "...."; ... } and then the inner sub would use $a Right. Just making sure I don't have to scan around in outer blocks checking. % Theory has joined #parrot r27421 | pmichaud++ | pgeupdates: : [pge]: : * More updates. : * Have PGE::Match use Capture_PIR as a base class (DRY). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27421 % IllvilJa has joined #parrot afk # library gcc -Llibrary Ack. I'm duplicating a lot of code. % Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net Hm. String comparisons in NQP. % tg has left tg!tg@digit.drk.hu NQP doesn't have 'lt' and 'gt'. Trying to call rakudo's infix:lt and infix:gt is awkward. We can add lt and gt since we now have a need for them :-) r27422 | pmichaud++ | trunk: : [core]: Deprecate Super PMC (RT#53968) diff: http://www.parrotvm.org/svn/parrot/revision?rev=27422 I guess we need 'le' and 'ge' also, then. although we could just implement <=> and leg and be done with it :-) Added, r27423 r27423 | pmichaud++ | trunk: : [nqp]: : * Add lt, le, gt, ge infix operators. diff: http://www.parrotvm.org/svn/parrot/revision?rev=27423 pmichaud++ % guru has left guru!~guru@dsl-67-204-16-108.acanac.net % wknight8111 has joined #parrot % teknomunk has joined #parrot % desertmax_ has left desertmax_!~markus@212-183-123-66.adsl.highway.telekom.at % rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com % iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-113.dynamic.mnet-online.de % wknight8111_ has joined #parrot % wknight8111_ has left wknight8111_!~Whiteknig@pool-72-92-20-41.phlapa.east.verizon.net % rdice has joined #parrot % Ivatar has left Ivatar!~graham@tu055.demon.co.uk % wknight8111 has left #parrot r27424 | pmichaud++ | trunk: : [nqp]: : * Oops! Forgot a piece of the lt, le, gt, ge operators! (pmichaud--) diff: http://www.parrotvm.org/svn/parrot/revision?rev=27424 % TonyC has joined #parrot % radhios has left radhios!~roberto@190.19.126.84 % radhios has joined #parrot % askie has left askie!~askie@81.171.100.207 * rafl wonders if http://files.perldition.org/rakudo_list_undef_perl.diff looks sane % askie has joined #parrot should probably use an interator to loop over elements of the List also, should it be (a, b, c) or [a, b, c] ? *iterator not sure about the iterator. all of the other methods in List.pir are implemented like that. no idea about () vs []. let me see.. (a, b, c) and is tested however [a, b, c] also works, as it seems. what's the difference? no, my question is what should .perl return okay, pmichaud. should it use (...) or [...] ? purl, forget my question pmichaud, I didn't have anything matching my question is there a semantic difference? is there a difference in (1, 2, (3, 4), 5, 6) ? versus [1, 2, [3, 4], 5, 6] ah, ok. then i guess it should be [] I still need to get list context straight in my head well, what does pugs output? that might also be a good indication i thought pugs doesn't build these days. I think pugs still works on #perl6 pugs came back with square brackets for pugs: my @a = <1 2 3>; say @a.perl; but with parens for say <1 2 3>.perl; which means that we need to get the List vs. Array distinction correct. I need a crash course on list context, mutable values, and immutable values what should [[1, 2]].elems return? I would think 1. pmichaud: the question of what .perl should return is what would eval to return the same structure. Tene: I understand that in the abstract -- I don't completely understand list structures in Perl 6 yet I remember a big issue in pugs (that was never resolved, happened after pugsdeath) about my @a = [1, 2, 3]; Pugs does something about that wrong. Should @a after that have .elems=1 or .elems=3? exactly. that's where I get all fuzzy at the moment. see, rhs of assigning to @a is in list context, and that's a single item, so @a.elems=1, as I recall because you'd say @a = 1, 2, 3; Which is the same as @a = (1, 2, 3); ()s are nullops in lists. .elems == 1 is what I would expect (1, 2, (3, 4, 5), 6) is the same as without the parens. so, @a = 1 is the same as @a := [1] because my @a = [1, 2], 3; should result with @a.elems == 2 Right. I remember confusion about whether pugs had it right or not. well, I'll read up on list context some more and then we can ask on p6l or somewhere appropriate If we're all confused about this, is this a sign that this design might be a common source of errors? I think it may simply be that it's not explained well enough Okay. I'm pretty sure TimToady has it straight. Now to go implement an insertion sort in NQP. I haven't done these by hand in ages. we may need 'splice' for that although it can certainly be done w/o splice splice might be nice, but we can get away without it for now, I think. $i := +@($whatever); while ($i > 1 && ...key comparison...) { $whatever[$i] := $whatever[$i-1]; } Of course, rakudo needs splice, and if rakudo has it, we can use it in actions.pm. $whatever[$i] := ...thing to be inserted...; I guess that should be $i > 0 above and we need a $i-- The list is going to contain only items inserted by us, so we know it's sorted coming in, so it's an insertion sort into a sorted list. exactly. so just start at the end of the list and move elements from i-1 to i until you find the spot where the new one should go My plan was just to make a new PAST::Stmts, and push things into it in order, then replace $?BLOCK[0] with it. That works too. insertion seems a bit easier to me * Tene nods. I'll commit in a bit. that will be quite impressive ? (having working placeholder vars) Only because the rest of you have done all the hard work for me. :) my first draft already committed was ~6 lines, iirc. r27425 | pmichaud++ | trunk: : [rakudo]: : * (Test.pm) refactor 'proclaim' to mark TODO tests in output as : not ok 123 # TODO reason - test description : instead of : not ok - test descriptionTODO reason diff: http://www.parrotvm.org/svn/parrot/revision?rev=27425 r27426 | chromatic++ | trunk: : [config] Made rpms target in root Makefile use rpmbuild to build RPM (Gerd : Pokorra, RT #53552). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27426 r27427 | chromatic++ | trunk: : [install] Allowed installation of runtime/ directory during make reallyinstall : (Gerd Pokorra, RT #53738). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27427 % particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net r27428 | chromatic++ | trunk: : [OO] Added class name to attribute re-adding exception (NotFound, RT #53850). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27428 % particle has joined #parrot pmichaud: $block[+$i] := $var; is resulting in: <4> => PMC 'PAST::Var' { => "$^a" => "parameter" } Any ideas? * purl burps * Patterner pets purl * purl purrrrrs looking Looks like prefix:+ generates a 'Float' pmc. yes, it does. * purl stays quiet this is kinda ugly, but you might try @($block)[+$i] * Tene tries. did you try $block[$i] ? Yes, that's what I tried first. the + prefix shouldn't be necessary, since $i is already numeric Method 'viviself' not found for invocant of class 'PAST::Op' Method 'viviself' not found for invocant of class 'PAST::Op' that's with $block[$i] ? No, that's with @($block)[+$i] Doesn't compile. okay. Let me check what's generated without the prefix:+ r27429 | chromatic++ | trunk: : [t] Fixed typos in t/op/sysinfo.t (Brad Gilbert, RT #53924). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27429 % NotFound has left NotFound!~julian@50.Red-213-96-228.staticIP.rima-tde.net just find_lex, find_lex, set $PX[$PX], $PX And $i is an Integer pmc. hmmmm oh. * pmichaud checks. so, set $PX[$PX], $PX is calling set_pmc_keyed even when [$PX] is an Integer Looks like. looks like is tne only usage, yes. I thought I had checked that it wouldn't do that. hrm. purl, forget looks like pmichaud: I forgot looks like just a sec, writing a test ....very interesting. "pmichaud" at 76.183.97.54 pasted "get_pmc_keyed_int doesn't match set_pmc_keyed_int" (32 lines) at http://nopaste.snit.ch/12929 r27430 | chromatic++ | trunk: : [pbc_merge] Added DOES_NOT_RETURN annotation to header of help() function to : fix MSVC build (Andrew Whitworth, RT #53934). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27430 I'll make another clearer example. r27431 | chromatic++ | trunk: : [PMC] Added a custom mark() vtable entry for OrderedHash, as it can have GCable : keys in its hash that are null (RT #53890). diff: http://www.parrotvm.org/svn/parrot/revision?rev=27431 okay. $P1[$P2] always invokes get_pmc_keyed and never get_pmc_keyed_int that's a bit of a problem for aggregates that have both hash keys and int keys It's times like these that make me wonder whether PHP got it right all along. That's very disorienting. heresy well, I could just do everything as string keys That seems less than ideal. yes, because it complicates 'push' and 'pop' a fair bit I'm a bit surprised that @(block)[$i] didn't work maybe (@($block))[$i] ? Sure, I'll try that. unfortunately I have to go attend to some family stuff now. But I'll think about it some more. it also may be that the work I'm doing in the pgeupdate branch may clean it up and/or fix it Nope, same viviself not found failure on compile.