pmichaud: thanks for clarification. Christoph Otto | plumhead_renaming: link: http://www.perlfoundation.org/parrot/index.cgi?plumhead_renaming dalek's url is at http://xrl.us/d2gpk % clunker3_ is now known as clunker3 % TiMBuS|Away has joined #parrot % TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au % TiMBuS|Away is now known as TiMBuS rebooted in time to see myself go. damn windows games in WINE :( % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % cognominal has joined #parrot morning all morning, jonathan So, Rakudo day. Time-shifted a little, because I seem to have got some insomnia... % masak has joined #parrot % Ademan has left Ademan!~dan@h-67-101-41-50.snfccasy.dynamic.covad.net % Ademan has joined #parrot % bacek has joined #parrot r28708 | jonathan++ | trunk: : [core] Parse :lexid('foo'). diff: http://www.parrotvm.org/svn/parrot/revision?rev=28708 % iblechbot has joined #parrot % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se Oh IMCC The sight of your internals Will not bring world peace r28709 | fperrad++ | libs4php: : [php] to_number in PMC diff: http://www.parrotvm.org/svn/parrot/revision?rev=28709 jonathan, rewrite IMCC in Parser::Yapp? stupidbot, search Parser::Yapp stupidbot, find Memoize stupidbot, corelist search Parser::Yapp bacek: Found no module matching /Parser::Yapp/ hmm... not in corelist of cause... bacek: Would prefer to write something that does POST to PBC. Then parse PIR with PGE, and use the actions to produce POST. hey, It's different approach! Then you have to provide precompiled pbc for PGE Yeah, of course, that's the issue. Phew. Finally got :lexid to work. That should make pmichaud happy. r28710 | jonathan++ | trunk: : [core] Implement :lexid(...). diff: http://www.parrotvm.org/svn/parrot/revision?rev=28710 % skv has left skv!~skv@87.242.97.68 % skv has joined #parrot % ruoso has left ruoso!~ruoso@201009085227.user.veloxzone.com.br % iblechbot has left iblechbot!~iblechbot@ppp-62-216-197-207.dynamic.mnet-online.de % jan has joined #parrot Hi, I added MSWin32 machine to TapTinder - http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk mj41: Great, thanks! mj41: How hard would it be to also get reports like this, for make spectest_regression target in languages/perl6/ ? It is next on my TODO list :-) Oh, great. :-) mj41++ jonathan, how can I add the buiild on my macbook to taptinder? does that make you mj42? ;-) cognominal: I don't know - but mj41 is the person to ask. :-) ok moritz: no, 42 is too great number for me :-) okay, mj41. mj41: ;) mj41? I did a ack -i on parrot source and did not see taptinder http://taptinder.org cognominal: it is not easy to add next machine, but doable ho, that's a per branch thing? it is prepared for it but many parts are prototypes only % ruoso has joined #parrot mj41: after reading the wiki, it seems that you have an IRC bot for reporting mj41: would you care to send it here to report test failures? no IRC bot yet, probably you should fix my English oh no, I just didn't read the "future" in "long future feature list" ;) :-) % skv_ has joined #parrot % mj41_ has joined #parrot % nopaste has left nopaste!~opaste@202-154-105-237.people.net.au % skv has left skv!~skv@87.242.97.68 % skv_ is now known as skv % nopaste has joined #parrot % mj41 has left mj41!~chatzilla@pc-jurosz.ro.vutbr.cz % mj41_ is now known as mj41 half of my spectest_regression runs are failures due to some GC problems I've started using the tools/test_summary.pl script, which passes -G to parrot morning pmichaud pmichaud: isn't that the wrong approach? shouldn't we try to expose bugs rather than hiding them? % iblechbot has joined #parrot r28711 | pmichaud++ | trunk: : [rakudo]: : * Small update to postfix:, so that (1i)i comes up with the : correct result. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28711 is that tested somewhere? moritz: the -G bug has (or bugs have) been around literally for years. I don't have a good feel for when it/they might get fixed. :( so, for the most part it's interesting to note "oh, here's another place where it showed up", but rakudo doesn't seem to provide any useful information that is likely to lead to a fix. so it's really a parrot bug (or multiple so), nothing rakudo specific (for example rakudo specific PMCs)? the odds are very high that it's a parrot bug. what makes the CG bug(s) hard to fix? any change -- even turning on tracing -- causes the bug to disappear. masak: mostly that they aren't easy to reproduce with small code ouch http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs they're extremely sensitive to the order in which things occur in Parrot, so once you start doing things to locate the bug, you can't reproduce it. but they _can_ be reproduced in their exact circumstances, no? personally, I'm betting/hoping that whiteknight's new gc algorithm gets rid of the bug altogether they can be reproduced in the exact circumstances, yes. but that includes not being able to introspect the environment, I guess... pmichaud: re whiteknight, probably - but he'lll also introduce new ones :( at least not being able to introspect the environment in ways that seem useful thus far. Chromatic has done a lot of work on this (actually, many of us have) -- but I suspect it's just a simple algorithmic or pointer bug somewhere in Parrot's depths that is waiting for someone to stumble upon it. (introduce new ones) -- sure, there will be new ones, but at least we'll have some fresh eyes looking at them, and hopefully the code will be a bit better structured so that it'll be easier to track them down. (complex testing of (1i)i ) -- no, I don't think it's tested anywhere -- I just happened to notice it in scrollback a day or so ago and it's been in the back of my head to fix. :-) I can write a test for it perl6: say (1i)i; # testing OUTPUT[0+1i␤] polyglotbot hasn't updated either :-( % ank has left ank!~ank@ppp59-167-200-77.lns1.hba1.internode.on.net pmichaud: Currently working on using :instanceof so we can have Sub, Method, Block types etc. % Zaba has joined #parrot jonathan: excellent % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru Got two failing sanity tests after the switch...one of them turned out to be a Parrot bug, which I've fixed. The other looks like a Parrot issue too...pain to find... jonathan: partly tested in S02-builtin_data_types/anon_block.t (at least on the the perl6 level) jonathan: thanks for quick work on :lexid -- I'll give it a fuller test shortly pmichaud: Sure, hopefully it works for you. I'll add my (updated) test, at any rate. r28712 | pmichaud++ | trunk: : [core]: : * Add a test for :lexid/:outer implementation by jonathan++ . diff: http://www.parrotvm.org/svn/parrot/revision?rev=28712 the gc bugs can be tracked with the --gcdebug runcore, and in my experience, if you can occasionally get a GC bug on one platform without it, you can always get the gc bug elseewhere with it. there's a wiki page and two articles on ora by chromatic about this. jonathan: oops, looks like you've run into the same problem I had with my lexicals patch... nopaste coming This was a miracle for me, because tcl would often trip over some GC bug on my osx box, and no one could duplicate it on linux. * DietCoke hurls http://www.perlfoundation.org/parrot/index.cgi?fixing_gc_bugs :: Fixing GC Bugs (that has links to chromatic's bugs on the bottom.) % TiMBuS has left TiMBuS!~Hurf@123-243-167-27.static.tpgi.com.au s/bugs/articles/ warning: sloooooooooow. "pmichaud" at 76.183.97.54 pasted ":outer in .pbc still uses wrong sub" (55 lines) at http://nopaste.snit.ch/13404 wtf... let me see if I can verify that it is in fact the wrong sub.... That makes no sense, we look up the outer at compile time and store the outer sub PMC, then freeze the lot, or so I thought... yes, that's what I think as well but *something* isn't right. I didn't see a patch that updated how outer works, just one to parse lexid. r28713 | jonathan++ | trunk: : [core] Make multiple dispatch work when you have your own sub type. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28713 was that all in r28708? DietCoke: there were two commits for :lexid one for parse, one for implementation. That one you just mentioned was just parse. ah, 28710 was the impl. danke. % gryphon has joined #parrot "pmichaud" at 76.183.97.54 pasted ".pbc definitely grabs the wrong :outer" (55 lines) at http://nopaste.snit.ch/13405 gah, commented out code. bad jonathan, no donut. =-) DietCoke: Yeah, I have it removed locally, I spotted that just now in a debug trace. jonathan++ Sorry, been fighting against that in a codebase I have to maintain at work. =-) I want to re-do it a bit to make sure it throws an exception if :outer refers to a lexid that is in use by multiple subs % jay has joined #parrot but that's an easy change, once we get the .pbc working. DietCoke: it's gone r28714 | jonathan++ | trunk: : [core] Remove commnented out code accidentally left from earlier commit. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28714 pmichaud: Just fighting with the remaining test fail I have at the moment...give me a moment on that first. sure, no problem. I need a short break anyway, so bbiab ok I don't see anything obviously wrong with the patches. Thanks for sanity check. pmichaud: I've seen 0-ary referred to as "nullary". and there's a patch ready to go for turning that on for parrot; Just needed some feedback on how to deal with main. jonathan: RT#39844 has another core thing that might let patrick remove some hacks in perl6, if you can get it working. Chromatic and I got close but no ciagr. RT 39844d: [BUG] Parrot doesn't do args checking for a sub without params - open stupidbot, owner? (what's with the d after the ticket #?) DietCoke: that would be bacek purl, stupidbot owner is bacek OK, DietCoke. message bacek < stupidbot> RT 39844d: ... what's with the d? Message for bacek stored. RT 39844d: [BUG] Parrot doesn't do args checking for a sub without params - open message bacek You should also make stupidbot smart enough to know he's already done that in the last 5m. Message for bacek stored. % rdice has joined #parrot % jhorwitz has joined #parrot % tco has joined #parrot % magnachef has joined #parrot * DietCoke rethinks including Test::Harness 3 into parrot. % Andy has joined #parrot % magnachef has left magnachef!~dmagnus@bflo.corp.synacor.com % magnachef_away is now known as magnachef % jay has left #parrot pmichaud: ping - need PAST/PCT help! I can't find - in the DNS. jonathan: what's the problem? hmmm... the problem is that URI is not subclassible purl: forget the problem Tene: I forgot problem Tene: methods are not getting :outer generated I haven't got much more on it than that yet... * DietCoke sums up his pondering to RT and asks for comments. oh, arses ## FIXME: RT#47794 - Parrot currently doesn't allow both ## :method and :outer flags on a sub, so if we have :method ## we automatically skip :outer processing. RT 47794d: [BUG] objects - :method doesn't work with :outer() - open and ## FIXME: RT#47956 ## PIR doesn't compile properly if :outer points to a sub ## with :init/:load flags on it. RT 47956d: [BUG] :init :load cannot be target of :outer in compiled PIR - open "simple fix" not so simple. =-) class Foo { method bar { say &bar.WHAT; } }; Foo.new.bar Method sub foo { say 42 }; say &foo.WHAT; Sub ...progress... % NotFound has left NotFound!~julian@50.Red-213-96-228.staticIP.rima-tde.net Hmm. Well, :method and :outer together seem to work fine here for me. % NotFound has joined #parrot it's possible that the other lexical changes have fixed RT#47794 RT 47794d: [BUG] objects - :method doesn't work with :outer() - open (bots should not speak unless spoken to...) * Zaba is leaving so sicily for 2 weeks tomorrow to* pmichaud: Let me paste you my example here - if you think it's sane, we can maybe remove the workaround in PCT? nopaste? http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ rumour has it nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating or App::Nopaste or tools/dev/nopaste.pl % jonathan has left clunker3 % cjfields has joined #parrot how about my test case in the ticket? r28715 | jonathan++ | trunk: : [rakudo] Stub in Block, Ruotuine, Sub and Method PMCs and classes. Start using them for subs and methods (not for normal blocks yet - is a tad tickier). diff: http://www.parrotvm.org/svn/parrot/revision?rev=28715 pmichaud: OK, I'll try that. I still get "method not found". C:\Consulting\parrot\trunk>parrot testm2.pir abc xyz That's your test case. the first one (that doesn't work) or the second one (that does) ? is there anywhere I can read about history of parrot? The first one The first one is gone in the repository, on the mailing lists... is there something in particular we can answer? let me svn up and try it. (we're kind of looking forward to 1.0, rather than back historically) Oh, I have one local change...hmm :-) * DietCoke smacks jonathan. DietCoke, I am just curious, why it's been decided to write a virtual machine, and did it all start because of perl6.. can't run perl without a virtual machine of some sort. :-) DietCoke: It's not one that I *expected* to fix the bug. pmichaud, or rather, a virtual machine for another language but perl6, to write a perl6 interpreter on pmichaud: Putting in my other patch now, since it smoked... r28716 | jonathan++ | trunk: : [core] Fix another place where we tested for enum_class_Sub rather than any subclass of of Sub. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28716 One of the original goals was to provide a clean separation of the virtual machine for perl6 (as opposed to perl5, where it's bundled in) Zaba: a bit of forward thinking, I think -- virtual machines really ought to be more generic than language-specific. at some point we picked up "support other dynamica languages" as a goal, and perl6 picked up "support other implementations" "jonathan" at 85.216.151.226 pasted "pmichaud - this is the test that works here" (19 lines) at http://nopaste.snit.ch/13406 I see. essentially the choices at the time were either to (1) try to re-use the perl5 vm, or (2) build a new vm that supported dynamic languages, or (3) try to extend an existing vm to support dynamic languages. neither (1) nor (3) were very appetizing. i see now though 3 has some traction elsewhere. and clearly 1 is still in use. 3 has some traction elsewhere *now*, but I'm not sure that it did *then*. In fact, I think Parrot was an enabler for #3 to start happening. (but that's just speculative on my part) #3 is happening? pmichaud: Actually, the local change I had might realistically have made this work...checking... jonathan: something you committed in the past two hours caused it to work. pmichaud: Yeah, it was my last commit. the x.pir didn't run before I svn up'd, but it does now. that is fantastic if that's working now. I hadn't been trying to fix that specific issue, but I'm glad I have. I'll be testing all of the new :outer stuff in just a bit, I'll try that also and see what happens. OK, sure. I'll leave my workaround in place for the Method stuff for now. good idea. :-) well, there was always jacl. and ironpython has been around for some time. Once they get :outer's, it can go. honestly, I'm not sure the "here's why we're starting parrot" explanations were ever solidly documented; at least not to the skeptic's satisfaction. =-) OK, you wanted me to look at :lexid and PBC interaction... % slightlyoff has joined #parrot Do we have an op for composing a string from escaped characters? I'm thinking something that converts '\n' to a real newline. I saw compose(), doesn't seem to work for me % slightlyoff has left #parrot cjfields: I had to roll my own for PGE and Rakudo. one of the Data::* libraries might have something, though. DietCoke: maybe we should just answer that with "because it's fun" ;-) it is fun, but in some ways it's been a very frustrating sort of fun. :-| it's a lot more fun today than it was a few years ago :-) moritz: There's 2 tests "unexpectedly" suceeding now due to Sub type working. ;-) We have C functions, but don't know if they are accesible from bytecode. rakudo certainly looks more fun than partcl was, for example. =-) It's more fun than net2pbc was... but that's probably just jealousy. =-) if rakudo and pct are making parrot more fun, then I think the mozilla grant has been a success. :-) time for another! :-) Aye! * jonathan is looking forward to his extra Rakudo time during July. * pmichaud realizes he *really* needs to write his mozilla grant report today. OK, got the PBC with :lexid bug reproduced...now to try and work out what on earth is going on. well, I have trans() pretty much working... cjfields: Nice! :-) yes. I had that with the patch I did for :outer -- and was equally stumped as to why it didn't "just work". But I didn't investigate much farther, as I'm very unfamiliar with bytecode freezing. % Theory has joined #parrot cjfields: we have string_unescape_cstring, but I think there is no way to use it from bytecode. It doesn't have named args yet for :c :d :s, but :d and :s shouldn't be too hard to implement NotFound: okay, I can look into that are you looking for interpreting escapes for trans()? If so, why? * cjfields hates emoticons, when I mean ':c' trans() is supposed to handle /n, /b, and other escaped chars ...but won't Rakudo have already done that translation? but it 'just works' if you use double quotes yes I would not expect trans to change '\n' into a newline -- I'd want it to be a backslash + n I suppose if you want if I wanted a newline, I would have specified "\n" "/n" => 'A' Exactly S05 is a bit fuzzy re: that * cjfields meant "n" => 'A' % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 What's that 'trans' you talk about? transliteration i guess transliteration is "as much as you like", but you'll see in dictionaries, for instance: impinge, v.t.: To touch upon, to strike, to infringe (qv). Meh... NotFound: .trans() -- p6's version of the p5 tr///; Ah, yes. afk for a bit pmichaud: Found out why. Hating Parrot guts lots today. A bit important for us bioinformatics folks would like to have a way to reverse complement a DNA strand or translate DNA->protein babelfish cannot translate from en to en. Try translating through English. Interesting... purl's lack of directions is frustrating. jonathan: what now? =-) DietCoke: Turns out that we re-do the "what is the otuer sub" logic when loading the packfile. There's a big comment in there about why. Which I read as, "well, you can solve it properly if you want to go re-write a chunk of IMCC and who knows what else". Long story short, we're going to have to stash lexid away in the bytecode. I'd thougth we were going to avoid that. :-| I was hoping that wasn't the case. (storing lexid) where's the comment? well, the comment is pretty gold. I'm wondering it can be convenient to have an "escaped" encoding. That way escaping and unescaping can be treated like any other recoding. NotFound: but then the question becomes "whose version of escaping?" not everyone escapes the same way. Even perl 5 and perl 6 don't have the same escapes. pmichaud, what is different? also, at least in Rakudo's case, it's much easier to build/decode the escapes as the string is being parsed. pmichaud: the one used by the function string_unescape_cstring zaba: there are a _lot_ of differences. oh perl 5 uses \012 for octal notation, perl 6 uses \o012 (and doesn't allow \012) pmichaud: closure.pmc pmichaud: Maybe one day we can avoid this. For now, we'll just have to put up with it. pmichaud: See in thaw vtable method perl 6 allows things like \x[48,65,6c,6c,6f] instead of \x48\x65\x6c\x6c\x6f jonathan: looking oh that's nice pmichaud: but is not mandatory that every feature of parrot has to be perl6-centric, it isn't? ;) I'm not saying parrot has to be perl6-centric, I'm just saying that parrot's version of escaped strings would probably be useful only for Parrot. since other HLLs almost certainly also have different escape patterns. Yeah, I was wondering if that way can help simplify imcc and some other part of parrot. % peepsalot has joined #parrot oh, that's possible. but I don't know that there are many parts of parrot doing unescaping outside of string_unescape_cstring % jhorwitz has joined #parrot I definitely don't like the idea that we have to store the lexid's in the pbc's. But at this point I'll take whatever works. If I remember well there are some routines that convert a string to a c-string just to call that function, some improvement to that scheme will be good. how do you get at the lexids at runtime without storing them in bytecode? i don't understand how that would work normally you don't need the lexids at runtime :outer is a compile-time feature and since we know that the sub being used as :outer is in the same compilation unit, we should be able to store a reference to the outer sub as part of the bytecode unfortunately, parrot doesn't store compilation units as a single freeze/thaw -- instead it apparently does a series of separate freeze/thaws for each sub ok, storing the reference to outer sub is what i meant by lexid right, which means any cross-references between subs is lost yes, precisely. in parrot, a sub is a compilation unit ...and that's probably a mistake. Freezing them individually sure seems to be. well, i don't know about that, but it's definitely a long-ago design decision r28715 adds files but doesn't update MANIFEST. manifest must die OK, well, better than removing them and not updating MANIFEST true. :-) but we still get test failures. :-) Someone else can do it, or I'll do it once I've got this saving lexid mess sorted out. I'll take care of it. Thanks. r28717 | moritz++ | trunk: : [perl6] added tools/progress-graph.pl. Also added missing test file to This is a tad painful... : MANIFEST diff: http://www.parrotvm.org/svn/parrot/revision?rev=28717 * moritz forgot to make codingstd test before commiting will do now r28718 | pmichaud++ | trunk: : Update MANIFEST with files added in r28715. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28718 ugh! having separate classes for subs means we also have to have .pmcs for every type?!? moritz: can you add vertical lines to the graph, or some other delimiter to signify parrot releases? thats um, not going to work. parrot releases aren't in the source data for the graph. pmichaud: Yes, we need PMCs. (separate pmc types for subs isn't going to work) pmichaud: but the data is in the parrot repo particle: I think the graphs are being built from spectest-regression.csv, not from the repo. particle: I can take a look if GD::Graph supports that r28719 | moritz++ | trunk: : [perl6] codingstandards diff: http://www.parrotvm.org/svn/parrot/revision?rev=28719 jonathan: what happens when someone subclasses Sub, Block, Routine, etc. ? moritz: s/perl6/rakudo/ please particle: ok, will do pmichaud: Right now, they can't...does the spec allow for this? it doesn't *disallow* it OK so I suspect it's allowed if using :instanceof is going to require PMC types for everything, I think I might prefer to go with a wrapper Sub/Code/Method object of some sort. It's not possible right now to use a high level class / type. With :instanceof Or as a sub, in fact. And it didn't look too easy to change that. I could do it with a "Block" class that "has &!sub" and delegates invoke() to the &!sub % masak has left masak!~user@130.238.45.242 (and other methods as appropriate) does block, routine, sub, grammar, etc derive from closure? then it's just a matter of having appropriate initialization to generate the appropriate Block/Code/Method/whatever objects You could do something like that, but delegation ins't free, and calling in Parrot is costly enough already. oops, not grammar Block, Routine, Sub, etc. derive from Code, iirc. ah, code. how important is it to be able to distinguish Block/Routine/Sub/etc. at this point? i.e., what do we lose if we don't have that? pmichaud: distinctiion between return() and leave() for example Routine vs non-Routine is probably the most important distinction (return only works in Routines) rakudo's already handling that perhaps not perfectly in the case of leave(), but return does understand the Routine vs. non-Routine distinction. pmichaud: signature objects need to be stashed somewhere, and those are pre-requisite for MMD. jonathan: would it be possible to rebless parrot subs into HLL classes? as opposed to delegating? also you can .wrap a Routine (I can get .wrap to work also w/o having to distinguish the code types) Same problem - the PMC_Sub macro that gets at a sub's internals assumes it's a sub PMC. Or something with the same internal structure. ...but that can be fixed, yes? same as we've had to fix the macros for the other builtin types that get derived into HLL types? I think it can be fixed, but I'm not sure it's trivial. % Ademan has left Ademan!~dan@h-67-101-41-50.snfccasy.dynamic.covad.net or we could just have a single perl6code.pmc that is the base class for all code objects (and that understands HLL types) instead of separate perl6block.pmc, perl6method.pmc, etc. I don't see that working. I _really_ have a bad feeling about the proliferation of pmc types. like really really really bad As soon as you end up with a HLL type being expected to be a sub PMC, you hit the problem. ....because sub PMC operations don't go through vtables, or...? Right. Well, some do. Some don't. all should. shouldn't be poking at guts unless they're your own. particle: I investigated a bit, and found no way to annotate releases or some such. I looked at solving this, and it looked non-trivial. particle: if it's important for you, try digging into GD::Graph's docs, or switch to gnuplot or grace ;) I don't like extending the Perl6* <-> HLL* duality any farther than I absolutely have to. I agree we should do it eventually, and then we can have the PMCs now become HLL types, subclassable, the lot. In the meantime, what I've done doesn't break anything that did work, and does remove a roadblock. And I'm not expecting it to be hard to switch over to using HLL level stuff for this, once Parrot allows us to do that. "doesn't break anything that did work" isn't completely good. I'm worried about it becoming a dependency or expectation for new stuff. see, for example, the 'infix:,' stuff I had to rip out and fix. works is important, but we also want to try not to box ourselves into corners that are hard to extricate ourselves from. (imcc being another example.) because then we're continually saying "that's too hard to do the right way now... we'll just work around it and maybe we'll fix it later." % Zaba_ has joined #parrot I'm not immediately rejecting the work; I just didn't realize it was going to require a bunch of PMC classes to work, and I have to decide if I'm willing to accept that or not. :-) and that'll take a little time to think through. It wasn't my plan A - I wanted high level classes for the lot of them. I _really_ want high-level classes for the lot of them. I'm willing to consider a lot of other workarounds to let that happen, too. This approach has huge alarm bells going off in my head. in particular, I'd be willing to accept the delegation runtime cost in preference to enshrining this approach. :-| % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Ademan has joined #parrot Feel free to re-do it that way if you prefer it. I'm not completely sure it won't run into other Parrot issues too, though. :-| I'll mull it over a bit. I also think we're likely to end up with something for signature handling that maybe obliterate the need for this. i.e., I think we're going to have to layer our own signature handling on top of Parrot _anyway_, so doing this for the sake of signature handling doesn't quite fit for me. If you've got plans for signature handling, it'd be helpful if you told me about them like, soon. Before I dig into the MMD implementation. I don't have plans -- it's one of those things I hadn't thought about much yet. That's the *point* of this - so we can stick our own signature objects somewhere. most of my thoughts have been "oh, jonathan's working on it" :_) can signatures be properties on subs? we need to be able to introspect them anyway, I suspect. Hmm. If the properties get frozen into the bytecode, I guess that way could work. tcl has been storing them as attributes on a .Sub class (TclProc) even if they're not frozen in the bytecode -- we can generate :load :init to attach the properties We also need them for introspection. DietCoke: TclProc is a PMC? no. Oh? all the nasty bits are handled by .Sub (I agree that frozen in bytecode would be cleaner/faster, but there's an overall question about how properties get frozen and I think we'll need some real use cases before that gets decided.) I only did it this way because you couldn't have attributes on PMCs until recently. see languages/tcl/src/class/tclproc.pir (I'm storing my own string for 'args', not anything pure parrot there, but if it was a parrot representation, I could get the string I needed out of it. (btw, this is also the reason why multisub, mmd, captures, signatures, and currying are a ways down on the ROADMAP :-) okay, pmichaud. purl, forget (btw, this DietCoke: I forgot (btw, this DietCoke: And how do you bless subs into TclProc? As in, give them that type? moment. thanks line 251 of languages/tcl/runtime/builtin/proc.pir I had a sub, I assign it to a new tcl proc, and then set the attributes. er, not a sub, an Eval. in an ideal world, IMCC would say "oh, you don't want Eval, you want TclProc, here you are." % Zaba has joined #parrot Hmm but this worked. So you can subclass Sub and have it work somehow. That's...curious. welcome to my life as a partcl developer. :| I tried that with :instanceof and it didn't work out... :| this predates instanceof by several years. =-) part of the issue may be "when does the blessing occur" it can't occur immediately at compile time, because the class may not exist yet. but this isn't much different from things like :multi('MyHLLClass') or even :method in a namespace. :instanceof is designed to work when you eval code and the relevant class has already been created. right. I'm thinking it needs to work like :multi and/or :method, so that it patches things up once the relevant class is created. (years). I lied. 2007-02-25 % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru I agree that's more difficult. but i think it's ultimately what we'll have to do. (or come up with a somewhat different approach altogether) there have been many times lately when I doubt the intrinsic value of PMCs er, of PMC classes. perhaps Parrot's fundamental expectation is that every HLL will create a set of PMC types and that Class/Object types are the exception. But Perl 6 doesn't seem to be structured that way. Class/Object types aren't meant to be the exception. right, so having this PMC class type seems to get in the way a lot :-) Huh? What do you mean by "PMC class type"? things like Integer, String, Sub, Perl6Str, etc. for Perl 6 at least, we keep having to create a PMC type *and* a parallel Class type, and then somehow manage the vtable and method mappings between the two. that feels wrong. And I thought you were crazy when you started doing it. =-) I haven't figured out an alternative yet short of writing wrapper classes that delegate vtable methods the delegation should happen automagically. (yes, I think it's crazy. No, after doing lots of this stuff I haven't found any workable alternatives.) % kj has joined #parrot right, I'm not saying you have a choice. =-) For tcl, at least, i could use PMCs or objects; I went with PMCs because it lets me write some stuff in C for a (theoretical!) speed boost. I could probably get away just objects (that derive from the appropriate PMCs) just fine. I was hoping to keep the number of cases of this down to an absolute minimum -- i.e., where Parrot already provided a good built-in type (Integer, Float, Hash) or where performance issues _really_ seemed to dictact a C-based implementation (Perl6Str). in my case, parrot's types don't behave enough like tcl types, so I'd always need to override something. and even in the Perl6Str case, if I had a good way of writing Object methods in C then we wouldn't need Perl6Str at all. define good. You can implement METHOD's in PMCs now. yes, but Str is an Object, not a PMC so I have to have a Perl6Str PMC intermediary to have a place to attach the method. Ah, I see. (and actually it's a vtable override of get_number) but even here I could have a vtable override in PIR that calls the C named method.) You could write it in C and dispatch via NCI today. but that is less-than-good, ya. I tried that at one point and didn't have much success. I suspect the NCI signature I needed wasn't available. that's an easy fix I'll look at it again when I rewrite get_number and fix the radix issues. k. if you get stuck on it, please let us know, obviously. sure thing. actually, having an example of overriding get_number in a (non-PMC) class would be sufficient. i.e., subclass String and change its get_number vtable entry. (but have the work for get_number be written in C. A simple return 12345; would be enough to demonstrate that it works :-) % kj has left kj!~IceChat7@193.1.100.105 afk, lunch. before I go, though: jonathan -- if it seems I keep throwing up obstacles to the work you've put in today (i.e., :lexid, :instanceof) -- my apologies. Believe me, I'm frustrated about many of Parrot's limitations also. and you keep running into the tickets I've alredy submitted. :-) I am _very_ happy that :method and :outer work now pmichaud: Well, I fixed the :method :outer one, it seems. ;-) And lexid freezing, I am debugging right now...hope to have it done soon. oh, that will be fantastic will it still be smart enough to keep track of lexids only within a code unit, or do I need to worry about making sure lexids are unique within an entire interpreter? r28720 | fperrad++ | libs4php: : [php] more type functions :instanceof and sub stuff - I don't disagree with you on the end goal here, I just know I've got funding to work on MMD, know I need to be able to store away Perl 6 signature objects to have a chance of getting that right, and really wanted a way to do that. This seemed like a reasonable way. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28720 For the interim, at least. I think it will be within a code unit, from what I understand of the code. would sub properties be a reasonable approach, also? I hadn't thought of that, and yes, that would perhaps work. let's both think on it a bit. You've thought about mmd and signature issues far more than I have (in case it's not obvious, the roadmap is also a rough guideline as to how much thought I've put into the implementation details of each item, too :-) OK. Getting Method vs Sub vs Block right to me was a bonus, I was really after a place to stick the sig. I feel like a property is the right thing to do there, or an attribute on subs. (and as far as I'm concerned, it can be an attribute on Parrot Sub :-) (as opposed to something rakudo-specific ) Heh. Then we get into the world of trying to get some common type representation that's expressive enough to handle all that Perl 6 needs and other languages need, at Parrot level. it may be that we just need Parrot to give us a "first cut", then rakudo takes over and refines it more. It'd be nice, but I'm sure not smart enough to work that out without at least getting it done in Rakudo first. well, we'll keep working on it then. :-) Well, the hard part isn't (erm, apart from today's discussion ;-)) storing the sig somewhere, it's building and (even more so) using it. anyway, I have to go. bbiaw ok % AndyA has left AndyA!~andy@82.152.157.85 % AndyA has joined #parrot * DietCoke curses. Dates for yapc are set, and they conflict with the school year again. dates set already! sheesh, i'd better book a dorm room soon % Zaba_ has joined #parrot In Europe, we haven't had our YAPC yet this summer! :-P % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % _shane has left _shane!shane@hick.org r28721 | fperrad++ | libs4php: : [php] oops diff: http://www.parrotvm.org/svn/parrot/revision?rev=28721 "jonathan" at 85.216.151.226 pasted "pmichaud - fixed PBC issue, demo, patch coming after make test..." (30 lines) at http://nopaste.snit.ch/13407 particle: Where is the next YAPC::NA? jonathan: pittsburg i guess pittsburg is Soho-West, isn't? (PA) r28722 | fperrad++ | libs4php: : [php] rename decode_base64 to base64_decode diff: http://www.parrotvm.org/svn/parrot/revision?rev=28722 % _shane has joined #parrot % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net pittsburgh? OK pittsburgh is the host of yapc::na 2009 pittsburgh? * particle kicks purl * purl bites particle! literal pittsburg cotto_work: pittsburg =is= Soho-West, isn't? no, pittsburgh is the host of yapc::na 2009 okay, cotto_work. pittsburg is also hosting PPW in October of '08 okay, DietCoke. % Zaba has joined #parrot that bot is getting weirder and weirder jonathan++ # Haiku in the face of Cthulu -- er, IMCC's internals % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru IMCC FTAGN! iaaa! iaaa! wow. It's spreading. why is there no tpf news about pittsburgh for 09? rdice: shouldn't somebody blog about that? there was an article about PPW which referenced YAPC::NA'09 * davidfetter prepares a memo about the new cover sheets on the tpf repors reports* maybe i'll bother jmcadams about http://news.perlfoundation.org/ particle: GO GET HIM! * DietCoke grins at davidfetter. r28723 | jonathan++ | trunk: : [core] Make :lexid work in PBC as well as PIR. This changes the bytecode format, so you'll probably want a make clean or even make realclean after this. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28723 That, was one of the most non-fun patches I've done in a while... jonathan++ jonathan++ particle: You could also bother jeremy flumann, who is the conferences chair. aha, thanks jeremy@perlfoun... ? i'll look it up OK, I need to take a break for a while... pittsburg is also in California okay, TimToady. * jonathan goes to check a map of the US note the lack of h jonathan: Was that change why perl6.pbc was failing? or - the fix for that issue Oh! Dude, that confused me... avar: I wasn't aware perl6.pbc was failing - it wasn't using :lexid yet. (unless you svn up'd and didn't re-build, mind) pmichaud fixed a problem that caused perl6.pbc to fail where perl6.pir worked, it had to do with some namespace stuff that was different in PBC than PIR no this is 2-3 days ago, not related to your change Aha, OK. I just thought maybe lexid was related to namespaces .. It's dealing with a problem that I think pmichaud discovered around the time he was fixing that particular issue. Why do properties on PMCs smell a lot like magics on SVs? (Maybe the same reason Perl 6 doesn't have properties anymore as of about 5 years ago...) % Zaba_ has joined #parrot TimToady: Same crap, fancier nomenclature ? :) Sufficiently advanced properties are indistinguishable from magic. :/ S12: "A property is defined by a role like this: ..." i am fairly certain that parrot's PMC's properties and attributes came from dan's understanding of perl6's object model at the time. % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru yes, as of about 5 years ago :) Or are we talking about some other definition of properties? BTW, PMC properties are not what are used to do what that bit of S12 is talking about... S12 just uses that name to bridge the old notion of property to the new one of object attributes Right. The implementation of that bit of S12 in Rakudo really is just a role with an attribute. the basic problem is passive properties that must be interpreted by other code all "properties" in P6 are really methods and hence are innately active (at least potentially) the fundamental problem with passive data is that you must interpret it the same way everywhere you use it, so you end up with tons of macros and such to enforce consistency that could have been enforced by the OO system for less overall cost. % apeiron has left apeiron!~apeiron@c-71-230-65-194.hsd1.pa.comcast.net % apeiron has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru particle: I gave Jeremy a poke about this. beat me to it, thanks! % Theory has joined #parrot It turned out there were a few things I needed to say to him anyhow so I bundled it all together. % barney has joined #parrot n or sometimes y % Ivatar has joined #parrot % Theory has left Theory!~Theory@207.173.77.239 % Theory has joined #parrot bernhard.schmalhofer@gmx.de | plumhead_renaming: link: http://www.perlfoundation.org/parrot/index.cgi?plumhead_renaming dalek's url is at http://xrl.us/d2gpk r28724 | pmichaud++ | trunk: : [pct]: : * RT#44794 appears to have been resolved (jonathan++), so we : can now eliminate the :method :outer workaround. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28724 Error calling said() for rt: Ticket 44794 does not exist. er, RT#47794 oh well. RT 47794d: [BUG] objects - :method doesn't work with :outer() - open pmichaud: Nice! :-) Glad that's one ticket cleared up. me too. That should also make lexicals in classes work a little more sanely. It's hard to have methods nested in a class scope when :outer doesn't work :-| Well, we've :init :load bug too...if it still exists. Didn't check that one. yes, I'm wondering if that's been magically fixed also. Or if it's just another case of using enum_class_Sub that could be a similarly easy fix. now I'm going to see if I can get :lexid to work. Cool I'm sorta hacking out the PMCs you dislike, but...Euro 2008 semi-final. ;-) then we can fix $_. And then we can fix .method() no rush on the PMC hacking. I still dislike them and want to see them come out, but perhaps we both need a few days to re-think it. ack enum_class_Sub --parrot as long as I can virtually put up barbed wire fences and "danger danger!" signs around the current implementation I think we'll be okay :-) src\dynpmc\subproxy.pmc 15:#define enum_class_SubProxy -1 that's all and Euro 2008 semi-final *is* important. :-) pmichaud: Well, thing is, if I'm going to put signature stuff in, I'm going to need to do some stuff in the PMCs to make it happen. And if we're going to toss them in the end, I don't see much point putting more into them. My thought is: we just put it as a property on the Sub PMC, as you suggested. And we'll also stash, as a prop, the proto of the type of that sub too. I like that better for now, yes. But we do want something that works, too. I figure you'll solve it :-) Then override WHAT on a sub to grab the proto from the prop and return that. Sound workable? right yes OK it can be made to work, at any rate. oh, you probably won't want to see my next nopaste... Oh, I already checked earlier, that we can generate an :immediate with an :outer, get the outer sub with interpinfo and Do Stuff to it. "pmichaud" at 76.183.97.54 pasted ":lexid oops" (99 lines) at http://nopaste.snit.ch/13409 (yes, that's after svn up and make realclean) I'm trying a fresh checkout now. Oh, argh. And I think I know right now what that is. % Theory has left Theory!~Theory@207.173.77.239 same error with fresh checkout. Yeah Building something that in theory has a fix now... ...but Theory just left...? ;-) "jonathan" at 85.216.151.226 pasted "pmichaud - try this patch out" (23 lines) at http://nopaste.snit.ch/13410 :-P Theory went off to Practice... Ooh, game has started... jonathan: that seems to have fixed it. * NotFound puts his red t-shirt on who is in the semi-final? Spain :) and Nobody? nobody fucks with the Jesus. is that a Spanish name? Nobody important X-) Russia. Spain just scored. pmichaud: OK, running make test on it there erm here I'll ci if it passes. excellent. NotFound: Russia have played some good football this tournament! in Russia, the inquisition doesn't expect nobody!!! rebooting here (kernel upgrade and other package updates) jonathan: is not easy to reach semifinal without some good play ;) Anyway, I don't like football very much, I'm watching the match just to not be the only man in Spain that doesn't. * barney hopes for Russia in the final and does not understand check_isxxx.t r28725 | jonathan++ | trunk: : [core] Fix memory management bug in :lexid implementation. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28725 NotFound: Yes, I remember the football fever in Spain well, from when I lived there. :-) jonathan: add to that the time from last semifinal we played, and all is explained. % Theory has joined #parrot bernhard.schmalhofer@gmx.de | plumhead_renaming: link: http://www.perlfoundation.org/parrot/index.cgi?plumhead_renaming dalek's url is at http://xrl.us/d2gpk 2-0 2 thanks, purl no worries cotto_work 3_0 Awww...it's really all over for the Russians now. % iblechbot has left iblechbot!~iblechbot@89.17-dial.augustakom.net r28726 | fperrad++ | libs4php: : [php] add a PhpArray PMC diff: http://www.parrotvm.org/svn/parrot/revision?rev=28726 this worries me slightly cotto_work: which now? r28727 | bernhard++ | trunk: : svn merge -r 28566:28724 https://svn.perl.org/parrot/branches/libs4php/languages/plumhead diff: http://www.parrotvm.org/svn/parrot/revision?rev=28727 fperrad's change, but it looks like it's just stub code dalek's url is at http://xrl.us/goi5o it's fine r28728 | jkeenan++ | trunk: : Add some POD and comments explaining what ICU is. Some typographical reformatting. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28728 Can someone grab pmichaud's request in backscroll for a sample of a C-written method usable on an object in PIR and open a TODO ticket? cotto: The libs with implementations have tests which are passing for the PHC variant. nice barney, it'd be helpful if you could add a stub test for phparrays as t/pmc/array.t Spain wins! s/passing/mostly passing/ It's Germany vs. Spain on Sunday cotto: Will do tomorrow in that case I'll probably just do it tonight when I get home it's not a big deal either way * cotto_work grumbles about the slowness of the legal dep't k. Or put sanity tests for all PMCs in a single file. % barney has left barney!~bernhard@dslb-084-058-148-228.pools.arcor-ip.net r28729 | fperrad++ | libs4php: : [php] to_number() for PhpArray diff: http://www.parrotvm.org/svn/parrot/revision?rev=28729 % purl has left purl!purl@sentient.life % cognominal has left cognominal!~cognomina@82.67.232.89 % purl has joined #parrot % cognominal has joined #parrot did I send my perlcritic RFC to the list? (so I did. perl5 is sure getting a lot of new tickets. pmichaud: Having any joy with lexid? % gmansi has left gmansi!~gmansi@190.55.35.246 % silug has left silug!~steve@ppp-70-225-32-179.dsl.covlil.ameritech.net % magnachef is now known as magnachef_away % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 jonathan: had to take another break for a bit % gmansi has joined #parrot trying it now pmichaud: OK, sure. jonathan: got trans working with d: and s: say "bookkeeper".trans(:d, 'ok' => ''); # beeper say "bookkeeper".trans(:s, 'A..Za..z' => ''); # bokeper Haven't wrapped my head around how to implement complement yet... :d is presumably delete, :s? yup s = squash (repeats) complement would be any character not in the range. Nice work. cjfields++ yes, but how do we implement the complement of " <>&".trans( ( [' ', '<', '&' ]=> [' ', '<', '&'])) or " <>&".trans( ([' ', '<', '&'] => [' ', '<', '&' ])) ? * cjfields at a loss start at the first position. See any of the items in the list match the string at that point. If yes, it's in the set; if no, it's in the complemented set move to the next position repeat until no more positions one could potentially do some optimizations by keeping track of where each key occurs earliest morning everyone. instead of having to check every key at every position jonathan: it may take me a bit of time to do :lexid in PCT, since I have to basically generate unique lexids on every outer block OK, sure, no hurry. DietCoke, I'll try to add some brains to stupidbot pmichaud: nqp question: how do I get the match object after a result_object has been set on a match. scalar context always seens to return the result_object. the match object is just $/ $($/) is the result object, $/ is the match object or, if doing a submatch, then $ is the match object, and $($) is the result object that was set in $ re: trans() I'll see what I can come up with. I'm attaching the latest patch to rt#55492. RT 55492: [PATCH] partial implementation of transliteration - open I'm adding a few tests in to spec (BTW, S05-transliteration//trans.t should start passing, +22 tests not counting several more I need to add) excellent. jonathan: (re: RT#47956--the other flag issues) even if what you did today doesn't fix that one, allison has it fixed in the pdd25cx branch RT 47956: [BUG] :init :load cannot be target of :outer in compiled PIR - open pmichaud: Aha, good. % rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com Actually, I think the tests passed is 17 (tr/// isn't parsed yet, and there is an odd feed operator test which is also skipped). But I'll be adding in many more... excellent. we should be closing in on 1,000 passing tests then. cjfields: if you need help fudging the tests, please let me know thanks pmichaud, jonathan: are there any specific topics for which you want more tests in t/spec/ (apart from S03, which Auzon currently does)? S02, S03, S04, and S29 are the ones I'm most interested in at the moment. (in roughly any sequence.) Naturally, I have an interest in S12. :-) it may be a couple of weeks before we're ready for S06, S10, or S11 (beyond very basic tests, that is) I don't know that we'll be getting to S09 before the gsoc project finishes. :-) pmichaud++ thanks, I think I was getting confused with say()'s output, you and _dumper cleared things up for me tewk: yes, keep in mind that one a result object is set, then get_number and get_string are based on the result object however, one can use .text to get the original matched text (at least, I think .text works -- if not it needs to be added) * tewk really likes nqp, and is getting excited about perl6 I know its late, but I've just started writing production nqp/perl6 code. % teknomunk has joined #parrot S04-statements/no-implict-block.t should succeed (fudged), but when I add it to t/spectest_regression.data I get a usage message from fudge any idea what's wrong with it? (when I run spectest_regression I get that usage message) usually that means fudge can't find the file. % Andy is now known as AndyAway * moritz tries a third time jonathan: so far so good on :lexid -- got it added into POST and things compile okay nqp runs okay. Nice basic rakudo tests run -- now trying spectest_regression then I'll do it all again after converting immediate blocks to no longer be run as closures (which is where the real problems began before) gotta go GOTTA COME. % bacek_ has joined #parrot eww.. % Ivatar has left Ivatar!~graham@tu055.demon.co.uk % AndyA has left AndyA!~andy@82.152.157.85 % jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se % pjcj has left pjcj!~pjcj@84-73-177-217.dclient.hispeed.ch % nnunley has left nnunley!~nnunley@seatbelt.jerakeen.org % bgeron has left bgeron!bgeron@toad.stack.nl % polyglotbot has left polyglotbot!~evalbot@feather3.perl6.nl % wolverian has left wolverian!wolverian@feather.perl6.nl % jonathan has left jonathan!jonathan@feather.perl6.nl % PerlJam has left PerlJam!duff@193.200.132.135 % ilbot2 has left ilbot2!moritz@faui2k3.org % leo has left leo!lt@feather.perl6.nl % moritz has left moritz!moritz@ssh.faui2k3.org % pmichaud has left pmichaud!pmichaud@feather.perl6.nl % shorten has left shorten!~xrl@203.141.139.231.static.zoot.jp % Juerd has left Juerd!juerd@193.200.132.135 % dalek has left dalek!dalek@feather.perl6.nl % Maddingue has left Maddingue!~Maddingue@profane.mongueurs.net % paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net wow, what happened there netsplit hmmm... netsplit is at http://en.wikipedia.org/wiki/Netsplit % Ivatar has joined #parrot % AndyA has joined #parrot % jan has joined #parrot % pjcj has joined #parrot % paco has joined #parrot % pmichaud has joined #parrot % wolverian has joined #parrot % Maddingue has joined #parrot % polyglotbot has joined #parrot % dalek has joined #parrot % bgeron has joined #parrot % nnunley has joined #parrot % leo has joined #parrot % ilbot2 has joined #parrot % jonathan has joined #parrot % moritz has joined #parrot % PerlJam has joined #parrot % Juerd has joined #parrot % shorten has joined #parrot interesting.... pmichaud: let me know if rt#55492 is okay whenever you have the time (I'll check backlog). No hurry. RT 55492: [PATCH] partial implementation of transliteration - open % cjfields has left #parrot % tco has left tco!~ToddOlson@purrr.cit.cornell.edu % apeiron has left apeiron!~apeiron@c-71-230-65-194.hsd1.pa.comcast.net % bgeron_ has joined #parrot % d4l3k_ has joined #parrot % dalek has left dalek!dalek@feather.perl6.nl % Maddingue has left Maddingue!~Maddingue@profane.mongueurs.net % ilbot2 has left ilbot2!moritz@faui2k3.org % bgeron has left bgeron!bgeron@toad.stack.nl % ilbot2 has joined #parrot % d4l3k_ is now known as dalek to whomever maintains stupidbot, a url after the RT info would be nice % Maddingue has joined #parrot that would be bacek_ ;) cotto_work: btw if you look at the irc logs (see /topic), #\d{5} is turned into a link to the ticket % rdice has joined #parrot jonathan: well, something doesn't quite work with lexicals yet -- I'll have to do a fair bit of work to track it down, though. moritz, so they are. nqp passes all of its tests, but perl6 fails pretty spectacularly. thank for pointing that out % slavorg has left slavorg!~tomi@windmill.london.pm.org % slavorg has joined #parrot pmichaud: Is that when you removed the newclosure, or just with :lexid in general? removing the newclosure with just :lexid in general everything still works. OK (but I would somewhat expect that :-) you should commit with just :lexid r28731 | moritz++ | trunk: : [rakudo] one more test for spectest_regression diff: http://www.parrotvm.org/svn/parrot/revision?rev=28731 % Maddingue has left Maddingue!~Maddingue@profane.mongueurs.net % Maddingue has joined #parrot enough karma for today, good night ;-) (since it already works now.) anyway, I'll keep playing with it and see if I can track it down. rakudo has gotten so large it's a lot harder to track these things down, though. Because I've just hit upon something odd with lexicals too. Do you see issues when you have a case where you've got something like: { ...scome scope... sub foo { ...so this is nested... } } foo() Basically, when you call into a nested scope, when you've never called the outer one? night moritz g'night moritz do you mean is that the problem I'm seeing now, or do you mean do I think that's a problem to be addressed? it's not what I'm seeing now. After getting rid of newclosure I can't even get "say 'ok 1'" to work. (it won't compile -- there's a problem somewhere in gen_actions.pir) (related to the fact that there aren't newclosures.) Ah, you mean the actions from NQP don't even run to completion before hitting the problem? correct. I have a test case you might be interested in. "jonathan" at 85.216.151.226 pasted "pmichaud" (21 lines) at http://nopaste.snit.ch/13411 Run this somewhere it gets confused and expects a PAST::Val node to have a .pasttype (when running perl6) It fails. Then comment out the call to test(). yes, I'm aware that one can be an issue. OK. it fails because 'outer' was never called. OK, but it doesn't fail in test. so there's not really a context for test() to work from. oh...? checking. Add say "ok here" after test() % bgeron_ is now known as bgeron the problem is probably that outer thinks it already has a context because the call to test() will build one for it. Yeah. It "fakes" a call to the outer subs to build them. but that shouldn't happen with the code I'm doing at the moment. OK currently in PCT immediate blocks are called via newclosure It is decidedly an issue for the :immedidate with :outer. I want to switch those to be normal calls i.e., without calling newclosure % Ivatar has left Ivatar!~graham@tu055.demon.co.uk in the case of an immediate block, we're always invoking it from its outer sub, so there shouldn't be an issue. Right. % bacek_ has left bacek_!~bacek@122.110.79.7 (but obviously there is, since it's not working for some reason :-) src/sub.c from line 505 is what happens when you call newclosure I'm wondering if it's attaching the wrong :outer somehow. because it's acting like the lexical it's expecting isn't the one it's getting. and since the lexicals are fairly common (i.e., always '$/', '$past', and '$key'), a misplaced context would be difficult to spot. (it could also be that POST is generating incorrect lexid/outer pairs.) (i.e., that POST is getting the wrong lexids for each outer) That would certainly cause issues, if it is. ;-) yes, but the code to do it turned out to be fairly straightforward, so I'm thinking that's not likely it. *nod* At any rate, I'm not sure I want to go through gen_actions.pir and try to verify that each :outer is correct... It wouldn't exactly be surprising if it were a Parrot issue. % bacek_ has joined #parrot ugh. one nasty side effect of return exceptions is that they make the exception appear to be thrown from the return handler instead of the location of the original exception. :-( * pmichaud turns off "return" in NQP for now. The invoke vtable method in closure.pmc is the interesting one. % purl has left purl!purl@sentient.life % purl has joined #parrot yes, I looked at it over the weekend. looks like $args in build_call or whatever is being passed to build call % bacek_ has left bacek_!~bacek@pa58-109-178-54.pa.nsw.optusnet.com.au oh, perhaps store_lex isn't working. * pmichaud turns on some tracing. From reading the sub/closure code, I don't see anything that immediately looks like it would cause the issues you're seeing. % silug has joined #parrot pmichaud: OK, I really, really need to try and get some rest now. Good luck debugging. thanks for all of the improvements! Will write my report tomorrow...it ain't going to be a very exciting one. :-S Yeah, lots of under-the-hood work that was needed, but no shiny new features for people to play with. tis okay. we've already busted through 1000 passing spectests today Nice. :-) my current count is 1073, and that doesn't include a few things that are failing (that were previously passing) Does your :lexid change, without newclosure being removed, fix any? probably not Grrr. when newclosure is there, :outer doesn't really make a difference because it automatically takes the context of the caller, regardless of :outer says er, "regardless of what :outer says" Ah, OK. So we need both to make it work right. right, unless we want to be calling newclosure prior to every subroutine invocation (and checking to see if what we're calling is a Sub or a Closure to decide if we should be calling newclosure or not.) % particle has left particle!~particle@c-98-232-28-49.hsd1.wa.comcast.net OK. Hopefully you can work out a smaller test case. Maybe one of the other languages using NQP with a smaller actions file? % particle has joined #parrot oh, I think I found it. or at least a part of it. Oh? Just taking the garbage out...brb % Limbic_Region has joined #parrot if this is indeed the problem it could likely suck big time. ....but I think I can make a smaller test case. brb "pmichaud" at 76.183.97.54 pasted "more lexical badness :-( -- simple case" (70 lines) at http://nopaste.snit.ch/13413 % bacek_ has joined #parrot % peepsalot has left peepsalot!~peepsalot@bwext.kpimdp.com I can simplify the PIR quite a bit and then I'll submit a ticket. That looks like new invocations of a sub aren't getting a clean lexpad. oh, no it's not that... hmmm the closure is permanently tied to the original lexpad The inner one is holding...right. Which is probably what my :immediate bug boils down to as well. could be. It seems to make sense. here's a simpler case "pmichaud" at 76.183.97.54 pasted "more lexical badness :-( -- simpler case" (50 lines) at http://nopaste.snit.ch/13414 it removes all of the NQP cruft. should I file a ticket? I think I'll just file this as a ticket for the moment, so others can perhaps start looking at it. I need to get dinner and walk the dog. Yeah, do it. I'm too tired to look now Maybe Saturday. If someone doesn't beat me to it. Grrr. So many Parrot bugs. :-( % gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net % TiMBuS has joined #parrot OK, sleeep - night thanks, jonathan. great work today. even if nobody else recognizes/appreciates it, I sure do. % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % AndyA has left AndyA!~andy@82.152.157.85 % AndyA has joined #parrot % bacek_ has joined #parrot % ank has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % bacek_ has joined #parrot % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.or.comcast.net % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % bacek_ has joined #parrot % apeiron has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % Ademan has left Ademan!~dan@h-68-167-207-217.snfccasy.dynamic.covad.net % bacek_ has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % ank has left ank!~ank@ppp59-167-200-77.lns1.hba1.internode.on.net % ank has joined #parrot % Theory has joined #parrot % Ademan has joined #parrot % ank has left ank!~ank@ppp59-167-200-77.lns1.hba1.internode.on.net % bacek_ has joined #parrot % bacek__ has joined #parrot % bacek___ has joined #parrot home & % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % bacek__ has left bacek__!~bacek@mcas-151.usr.optusnet.com.au % Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net % ank has joined #parrot % bacek___ has left bacek___!~bacek@mcas-151.usr.optusnet.com.au % rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com % bacek_ has joined #parrot r28732 | coke++ | trunk: : RT#42293 : Remove tools/docs/pod_errors.pl; we have t/doc/pod.t which is more RT 42293: [TODO] t/doc/pod.t vs. tools/doc/pod_errors.pl - open : accurate, and is already run in "make test" diff: http://www.parrotvm.org/svn/parrot/revision?rev=28732 % Ademan has left Ademan!~dan@h-69-3-233-96.snfccasy.dynamic.covad.net % LordVorp has joined #parrot r28733 | jkeenan++ | autojit: : Creating autojit in https://svn.perl.org/parrot//branches diff: http://www.parrotvm.org/svn/parrot/revision?rev=28733 r28734 | jkeenan++ | autojit-28732: : Tagging trunk at r28732 so that the autojit can later be synched to it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28734 r28735 | jkeenan++ | autoicu: : Creating autoicu in https://svn.perl.org/parrot//branches diff: http://www.parrotvm.org/svn/parrot/revision?rev=28735 r28736 | jkeenan++ | autoicu-28734: : Tagging trunk at r28734 so that the autoicu can later be synched to it. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28736 % Ademan has joined #parrot % rblackwe has joined #parrot If I want to generate a warning, what's the parrot-approved way to do that? (I'm guessing fprintf(stderr) isn't right. =-) % magnachef has joined #parrot PIO_putps(interp, _PIO_STDERR(interp), s); meh. someone can update my patch if they like. =-) r28737 | pmichaud++ | trunk: : [rakudo]: : * Add sigil listop contextualizers. diff: http://www.parrotvm.org/svn/parrot/revision?rev=28737 % cjfields has joined #parrot % tetragon has joined #parrot does NQP have the concept of try/catch? no. we could potentially add it, however. % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net % Theory has joined #parrot % bacek__ has joined #parrot hola, pmichaud % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au (email sent to list) was just asking for that test. (which we can just write in PIR) % bacek__ has left bacek__!~bacek@mcas-151.usr.optusnet.com.au % bacek_ has joined #parrot % DietCoke is now known as Coke opbots, names % Coke is now known as DietCoke % DietCoke is now known as Coke opbots, names % Coke is now known as DietCoke Infinoid, danke. =-) no prob. think we need more opbots % Andy has joined #parrot % Theory has left Theory!~Theory@c-67-160-131-113.hsd1.wa.comcast.net % cjfields has left cjfields!~cjfields@adsl-76-227-79-69.dsl.chmpil.sbcglobal.net % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % bacek_ has joined #parrot % TonyC has left TonyC!~tony@202-154-105-237.people.net.au % nopaste has left nopaste!~opaste@202-154-105-237.people.net.au % TonyC has joined #parrot % tetragon has left tetragon!~seneca@76-10-148-120.dsl.teksavvy.com % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % nopaste has joined #parrot % nopaste has left nopaste!~opaste@202-154-105-237.people.net.au % bacek_ has joined #parrot % nopaste has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % cognominal has left #parrot % bacek_ has joined #parrot % magnachef has left magnachef!~dmagnus@cpe-74-78-109-88.buffalo.res.rr.com % Psyche^ has joined #parrot % Patterner has left Patterner!~Psyche@e177235223.adsl.alicedsl.de % Psyche^ is now known as Patterner % cognominal has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % bacek_ has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % Andy has left Andy!~Andy@64.81.227.163 % bacek_ has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au % bacek_ has joined #parrot % bacek_ has left bacek_!~bacek@mcas-151.usr.optusnet.com.au