Camelia, the Perl 6 bug

IRC log for #parrot, 2008-09-11

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:09 AndyA joined #parrot
00:21 bacek joined #parrot
00:21 bacek morning everyone
00:28 cotto_work morning, bacek
00:33 szbalint kid51: I had the same experience, installing Moose on my laptop and noticing it depended on half CPAN ;-)
00:34 szbalint (for smartlinks)
00:35 bacek I have a question about https://rt.perl.org/rt3/Ti​cket/Display.html?id=56468
00:36 bacek E.g. in bigint.pmc I found many lines similar to "bigint_sub_bigint_int(INTERP, SELF, PMC_int_val(value), dest);" (this is from "substract")
00:36 bacek Should we replace PMC_int_val with VTABLE_get_intereg(value) in this case?
00:39 dalek r30979 | jkeenan++ | trunk:
00:39 dalek : Applying patch submitted by Balint Szilakszi in RT 46783, deleting comments calling for use of tempfiles where they would be superfluous.  szbalint++.
00:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30979
00:39 kid51 szbalint:  Welcome to the ranks of Parrot contributors and cage-cleaners!
00:41 szbalint thanks :)
00:43 bacek And all keyed functions (e.g. get_integer_keyed_int) uses PMC_int_val(key)...
00:49 cotto_work szbalint++
01:00 * Whiteknight applauds pmichaud
01:03 cotto_work ?
01:04 Whiteknight he posted his final grant report
01:13 rurban_ joined #parrot
01:16 Whiteknight I'm subscribed to a few aggregators, and I got 6 copies of the report in my reader
01:27 cotto_work It's fairly generous to call xlibtest an application, awesome as it is.
01:31 Whiteknight I haven't even seen it yet. What is it, an NCI test app?
01:32 cotto_work examples/nci/xlibtest.pir
01:32 cotto_work it lets you draw in a window with a mouse in pure pir
01:32 cotto_work there's also an nqp and a perl6 version
01:33 Whiteknight is it in trunk?
01:34 cotto_work yup
01:35 cotto_work read the inline POD before running
01:35 bacek joined #parrot
01:36 Whiteknight how do I make xlib.pbc? is there a make target for it?
01:36 * Whiteknight demands documentation
01:37 cotto_work perldoc xlibtest.pir
01:37 cotto_work ../../parrot -o Xlib.pbc Xlib.pir
01:37 cotto_work ;)
01:37 Whiteknight you think you're so freaking smart! :)
01:38 Whiteknight i have to remake, don't have the right NCI signatures
01:42 cotto_work home &
01:45 particle joined #parrot
02:08 kid51 joined #parrot
02:10 AndyA joined #parrot
02:26 AndyA joined #parrot
02:31 cotto_home and home
02:44 bacek joined #parrot
02:55 gmansi joined #parrot
02:57 cotto_home Does anyone here running windows and have both msvc and gcc working?  I'd like a patch tested.
03:07 nopaste "cotto_home" at 96.26.202.243 pasted "file.pmc patch to use strerror_(rs) where available" (211 lines) at http://nopaste.snit.ch/14016
03:14 cotto_home It doesn't quite dtrt, but it's close enough that testing it will yield useful results.
03:15 cotto_home to test, apply, build and prove t/pmc/file.t
03:53 particle joined #parrot
03:56 ab5tract joined #parrot
04:02 grim_fandango joined #parrot
04:14 cotto_home particle: ping
04:19 cotto_home particle, when you have a minute I'd appreciate a review of the patch for http://rt.perl.org/rt3/Tic​ket/Display.html?id=52778
04:20 cotto_home It's a nearly trivial patch, but it changes the behavior of resizable*arrays, so I'd like to make sure it's OK to commit.
04:36 ab5tract i ran 'perl Configure.pl --prefix=~/lang'
04:37 ab5tract and it installed to ~/parrot-0.7.0/~
04:37 ab5tract the second tilde being an actual directory named '~'
04:38 ab5tract actually it did ~/parrot-0.7.0/~/lang
04:38 ab5tract so it kind of got it right i guess
04:53 Hinrik hm, http://rakudo.de/
04:53 Hinrik ^--- how big is the entire test suite?
04:54 Hinrik and how much of Perl 6 does it cover?
04:54 Zaba joined #parrot
04:57 cotto_home Hinrik, try asking on #perl6 on Freenode
04:57 Hinrik ok
05:00 ab5tract !bugs
05:01 GeJ Hinrik: there was a post from pmichaud IIRC, that discussed the subject of the test suite. Summary is not everything is covered yet so even the current number isn't going to tell that much about the final number.
05:01 GeJ For comparison, I think moritz wrote a post recently where he said that Pugs had 16k tests passing.
05:01 Hinrik hm, ok
05:02 GeJ that's for moritz: http://perlgeek.de/blog-en​/perl-5-to-6/22-state.html
05:04 GeJ and that's for pmichaud: http://use.perl.org/~pmichaud/journal/36834
05:16 ab5tract SMOP sounds awesome!
05:17 ab5tract what is bug repo link for parrot?
05:17 ab5tract and where can i learn more about smop
05:20 diakopter ab5tract: http://www.perlfoundation.org/perl6/index.cgi?smop
05:20 ab5tract diakopter: thank you.
05:25 diakopter wow; that smop wiki has expanded greatly since I last looked at it
05:28 ab5tract it sounds crazy
05:28 ab5tract but i guess they are right. perl 6 is just a smop.
05:30 ab5tract the object responder interface... that's clean c
05:30 ab5tract "just a macro to a callback", yeah you know nothin serious
05:33 ab5tract will it connect with parrot?
05:34 diakopter "mutual embedding as p2p" - I can see it now...
05:35 diakopter ab5tract: I dunno.  ruoso or pmurias on #perl6 on freenode
05:50 AndyA joined #parrot
06:19 uniejo joined #parrot
06:40 Zaba joined #parrot
07:13 barney joined #parrot
07:17 iblechbot joined #parrot
07:27 ab5tract joined #parrot
07:39 Debolaz joined #parrot
07:53 mberends joined #parrot
08:13 slavorg joined #parrot
08:59 cosimo joined #parrot
09:14 rurban_ joined #parrot
09:37 kj joined #parrot
10:10 xiaoyafeng joined #parrot
10:22 jonathan hi all
10:23 kj hi jonathan
10:29 * jonathan svn up's
10:51 jonathan moritz: ping
11:03 jonathan moritz: I don't know if I was supposed to set any environment variables to really do parallel testing, but I just did a make spectest_regression with the parallel testing patch applied on Windows and it worked fine.
11:04 jonathan oh, damm
11:04 jonathan I didn't make makefile
11:04 * jonathan tries again after that
11:09 bacek joined #parrot
11:12 jonathan moritz: Works after I actually tested it too. ;)
11:18 bacek joined #parrot
11:19 bacek g'localtime
11:19 bacek hi purl ;)
11:20 bacek purl?
11:20 purl yes, bacek?
11:20 bacek hi purl
11:20 bacek hmm... what happened to her?
11:21 uniejo joined #parrot
11:21 clunker3 joined #parrot
11:48 Ademan joined #parrot
11:55 moritz re
11:55 moritz jonathan: ok, then I'll apply the patch when I'm back home
11:56 jonathan moritz: OK, nice. :-)
12:02 dalek r30980 | jonathan++ | trunk:
12:02 dalek : [rakudo] Add argumentless ... stubby exception generator.
12:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30980
12:03 * jonathan stares at patch in RT#58150
12:24 dalek r30981 | jonathan++ | trunk:
12:24 dalek : [core] When slurping an empty file, we should hand back the empty string rather than a NULL, which would suggest an error. Patch courtesy of Ron Schmidt.
12:24 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30981
12:30 bacek joined #parrot
12:38 dalek r30982 | jonathan++ | trunk:
12:38 dalek : [rakudo] Make split method a little more liberal about the multi parameters it takes, so $*IN.slurp.split(...) will work.
12:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30982
12:59 kj joined #parrot
13:04 Zaba joined #parrot
13:07 pmichaud split belongs in any-str .
13:08 jonathan I did wonder that.
13:08 pmichaud and the first param should be _
13:08 jonathan If it's going in any-str, then yes.
13:08 jonathan Is there a list of what belongs in Any somewhere, or is it just an instinctive feeling? :-)
13:09 pmichaud there's not a list, but in general any time that we expect a function to "coerce" its invocant into the appropriate type, it belongs in Any
13:09 jonathan OK.
13:09 pmichaud thus .abs goes in Any, because it will always treat its invocant as a numeric value
13:09 pmichaud and split goes in Any, since it treats its invocant as a string value
13:10 jonathan *nod*
13:10 jonathan Will move it.
13:11 tewk pmichaud: I didn't create Squaak
13:11 pmichaud tewk: yes, I just got a message from kjs as well
13:11 pmichaud those "k"s got me confused.  I'm fixing it now and will re-submit.
13:11 pmichaud (and I was tired and distracted when I wrote the report)
13:18 dalek r30983 | jonathan++ | trunk:
13:18 dalek : [rakudo] $(), @() and %() now mean the same as $($/), @($/) and %($/), as per S05.
13:18 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30983
13:24 pmichaud okay, fixed the reports online.  I'm sending an updated version to mozilla now.
13:24 jonathan pmichaud++ # good report
13:24 jonathan Makes me realize how far we've come.
13:26 pmichaud done.
13:29 pmichaud jonathan:   I think I would much prefer for ... to be    term:<...>  instead of a special token in the grammar
13:30 pmichaud and then a builtin-sub rather than part of the AST
13:30 jonathan pmichaud: We can't write term:<...> yet, though?
13:30 jonathan Thus why we have named_0ary?
13:30 pmichaud do it the same as the other 0-ary terms.
13:30 jonathan OK, though it's not actually 0-ary. :-)
13:31 pmichaud it's not?
13:31 jonathan No
13:31 jonathan It can take args.
13:31 jonathan STD.pm has it
13:31 jonathan token term:sym<...> ( --> List_prefix) { <sym> <args>? }
13:31 pmichaud okay, it's 0-ary for now, then.  :-)
13:31 jonathan But <args> is a special arguments rule that only a few things use, so I didn't pull that in yet.
13:31 jonathan OK, I can move it there.
13:32 pmichaud at any rate, I'd prefer it not to be handled specially in the AST
13:34 jonathan Well, if it's going to be parsed as in STD.pm, we'd only end up emitting a call to term:... rather than a call to fail...
13:34 pmichaud yes
13:34 jonathan (Well, with the exception of checking if there's any args)
13:35 pmichaud but when we're STD.pm-like it'll probably be a special method in the action grammar anyway (instead of being part of an existing method)
13:35 jonathan Yes.
13:35 masak joined #parrot
13:35 jonathan But then it will be handled in the AST? So doing it like that now is closer to what we'll eventually want?
13:35 pmichaud I'd prefer it not to be an if-then statement that we have to rip out.
13:36 pmichaud and it's still better for it to be treated as a call to a sub named 'term:...' than a special failure node.
13:37 jonathan True, that'll allow overriding.
13:37 pmichaud and it'll be easier to handle things like 'use fatal'
13:37 jonathan *nod*
13:37 jonathan Yes, I'm sold on it now. :-)
13:39 jonathan Ah, hmm. It looks like the named_0arys actually call just the name, not term:name
13:39 pmichaud yes.
13:39 jonathan so just .sub '...' for now?
13:39 pmichaud sure.
13:40 pmichaud that's probably so that we can get things like &rand and the like
13:42 jonathan Yes, I expect so.
13:44 jonathan ouch
13:44 jonathan token named_0ary { [pi|rand|undef|nothing|time|'...'] >>
13:44 jonathan }
13:44 davidfetter joined #parrot
13:44 jonathan Now I get parse fails.
13:44 jonathan sub foo { ... }
13:44 jonathan Missing '}' at line 1, near "... }\n"
13:44 jonathan :-S
13:44 jonathan That's what I was getting with ??? and !!!
13:53 pmichaud looking
13:54 jonathan Thanks.
13:55 pmichaud it really shouldn't make a difference (more)
13:55 pmichaud you had '...' as a specially parsed term in token term, but <named_0ary> is also called from there
13:56 jonathan Right.
13:56 pmichaud so if it works in one place, it should work in the other.
13:56 jonathan Agree.
13:56 jonathan Grammar engine bug, maybe?
13:56 pmichaud no, it's the >>
13:56 pmichaud there's no word boundary after the '...'
13:56 gryphon joined #parrot
13:56 jonathan ah.
13:57 pmichaud so, perhaps   [pi|rand|undef|nothing|time] >> | '...' | '!!!' | '???'
13:58 pmichaud (!!! and ??? still might not work, but we might as well stub them in for now.)
13:58 jonathan Will try it
13:58 jonathan Just trying to work out what is wrong the !OUTER at the moment
13:59 jonathan if "foo" ~~ /o/ { say $/ } # doesn't work - $/ access gives NULL PMC access
13:59 jonathan And removing exception handler in !OUTER gives "No such outer depth"
14:04 jonathan Ah. I fear it's confusion of static chain and dynamic chain.
14:05 pmichaud in this case they're essentially equivalent, though.
14:05 jonathan Yes, but I fear it may be trying to look for !OUTER's outer.
14:06 pmichaud possible, but I doubt it.
14:06 pmichaud I'll svn up, rebuild, and look a bit also
14:07 jonathan In parrotinterpreter.pmc, the usage $P0['lexpad', depth] is not one of the things that's documented as meant to work, either. :-(
14:08 pmichaud it's documented in pdd20, though.
14:08 pmichaud (line 342)
14:08 jonathan "outer"                   ... return outer sub of this closure
14:08 jonathan "<item>"; level           ... same for caller <level>
14:08 jonathan "outer"; "<item>"         ... same for outer level 1
14:08 jonathan "outer"; "<item>"; level  ... same for outer <level>
14:09 jonathan So it is.
14:09 purl no it isn't
14:10 * jonathan stares at the rather opaque implementation
14:10 pmichaud staring at it gives transparency?  ;-)
14:10 jonathan If only...
14:11 * jonathan is glad purl doesn't have a comment along the "speaker's so loud" one at this point
14:13 jonathan The fact it gives the "no such outer depth" message suggests that it is ending up in the code path that chases down the outer chain.
14:13 jonathan Otherwise it would say, "no such caller depth"
14:14 pmichaud well, chasing down the outer chain is correct, yes?
14:14 jonathan Wait a moment...this is 'lexpad', depth you're using
14:14 jonathan not 'outer', depth
14:14 * jonathan was looking at the wrong thing
14:14 jonathan s = CONST_STRING(interp, "lexpad");
14:14 jonathan if (string_equal(interp, item, s) == 0)
14:14 jonathan return ctx->lex_pad;
14:15 jonathan That's all of the code that relates directly to saying "lexpad"
14:15 jonathan BUT there is code that specially handles the case when there is more than one key supplied!
14:18 jonathan I still can't see the code-path that would get us to walking the static chain though. (The problem being that !OUTER doesn't have an outer...)
14:18 pmichaud I grant that lexicals are still broken in Parrot.  :-)
14:19 pmichaud here's another interesting case:
14:20 pmichaud > $_ = 'hello';  { say $_; }
14:20 pmichaud >
14:20 jonathan Yes
14:20 jonathan I did almsot exactly the same
14:20 jonathan Again, it's !OUTER
14:22 pmichaud the !OUTER function is using 'outer', not 'lexpad'
14:25 dalek r30984 | kjs++ | trunk:
14:25 dalek : [NEWS] updated NEWS for next release, adding PIRC news.
14:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30984
14:33 jonathan pmichaud: Ah, yes, you're right
14:33 jonathan Sorry, had phone call
14:34 jonathan pmichaud: I really don't like that for every immediate block we enter we then have to do three Parrot sub calls for this.
14:34 jonathan We could get the required functionality out of a few-line dyn-op.
14:36 jonathan But ParrotInterpreter PMC does: if (outer) {
14:36 jonathan (Which is true if we mention 'outer', it appears)
14:36 jonathan And if that's true, goes and looks for !OUTER's outer, etc.
14:38 dalek r30985 | moritz++ | trunk:
14:38 dalek : Enable parallel testing in rakudo.
14:38 dalek : Patch courtesy by Michael Schwern and Ron Schmidt
14:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30985
14:41 dalek r30986 | moritz++ | trunk:
14:41 dalek : [NEWS] first stab at Rakudo news
14:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30986
14:41 jonathan pmichaud: May have a fix.
14:42 moritz pmichaud: the NEWS entry for rakudo is probably not complete, so extend/edit it before the release
14:42 jonathan pmichaud: Need to spectest_regression it.
14:46 jonathan pmichaud: I think we should be using lexpad.
14:47 jonathan Not outer.
14:47 jonathan Doing so gives me two test failures, however.
14:48 jonathan (But fixes the "if "foo" ~~ /o/ { say $/ }" bug, and"$_ = "hello"; if 1 { say $_ }" too).
14:48 moritz jonathan: what kind of failures?
14:48 jonathan t\spec\S04-statements\given.rakudo
14:48 jonathan t\spec\S06-signature\named-placeholders.t
14:49 moritz making that work means *much* easier real-world code
14:50 jonathan moritz: I know.
14:50 jonathan I'd rather fix it without causing regressions, though.
14:50 jonathan Investigating them now.
14:52 masak I, for one, like where this is going. hope everything works out.
14:52 jonathan OK, the given is actually now failing in a todo test.
14:52 jonathan And it's failing when it wasn't before because it now executes some code it should!
14:52 moritz that's OK
14:52 jonathan Basically it did
14:52 jonathan (does)
14:52 jonathan my $x;
14:52 jonathan given 41 {
14:52 jonathan when ({ $_ == 49 }) { diag "this really shouldn't happen"; $x = 49 }
14:52 jonathan when ({ $_ == 41 }) { $x++ }
14:52 jonathan }
14:53 jonathan Before, $_ wasn't being taken into the block inside the when test, so we never tried to do $x++
14:53 masak yes, of course. :)
14:53 masak tests++
14:53 jonathan Now we do and get the "increment not implemented in undef"
14:53 jonathan Which causes the test to bomb out.
14:54 moritz jonathan: changing that to 'my $x = 0' should solve the problem
14:54 jonathan Yes. Is that an OK thing to do?
14:54 jonathan We actually pass the test...
14:54 moritz jonathan: since it's not autoincrementation that we test... yes
14:54 jonathan OK.
14:54 jonathan I can un-todo the test as well, otherwise we'll get another unexpected success.
14:54 NotFound I think that if the test was passing erroneously, the test must be fixed.
14:54 moritz jonathan: I added a test like that in the proper place, and now I simplify such thing whenever I see them
14:55 jonathan OK, so that's a WIN.
14:56 NotFound I mean, make it fail before the change.
14:56 jonathan NotFound: It wasn't that it was passing. It was just not failing badly enough before the change.
14:56 NotFound Ah, well.
14:56 jonathan OK, t\spec\S06-signature\named-placeholders.t...
14:56 jonathan This could be nastier.
14:57 jonathan oh, wtf, just ran it outside of the harness and it passes
14:57 * jonathan tries spectest_regression again
14:58 * jonathan suspects that if we fixes this !OUTER thing there may be a couple of RT tickets that can get closed
14:59 masak aye,
14:59 masak lots of november code will become much more succinct :)
14:59 jonathan Yay.
15:00 NotFound So given/when will be working now?
15:00 jonathan No
15:00 jonathan That to work fully needs the control exception stuff
15:01 NotFound I just want to use it instead of a chain of if in xlibtest.p6
15:01 jonathan I think it's waiting on PCT refactors, which I'm not 100% comfortable doing.
15:02 NotFound I'll wait, then.
15:03 jonathan Hmm. I've got a test that runs fine with perl t/harness, fine when run with perl6.pbc, but fails when run as part of spectest_regression.
15:04 jonathan That would seem to suggest a test harness issue rather than a Rakudo issue.
15:04 NotFound Differents flags passed to parrot, maybe?
15:05 masak NotFound: you can already use it if you refactor it out into a sub, and end each when { ... } with a return :)
15:06 NotFound masak: if I use a sub for each value, I'll like better to use a hash of subs.
15:06 masak NotFound: nono, just refactor the given into its own sub.
15:07 masak so that you can use return as .leave
15:07 dalek r30987 | jonathan++ | trunk:
15:07 dalek : [rakudo] Fix !OUTER, so things like if 'foo' ~~ /o/ { say $/ } will now work. Since !OUTER no longer seems to produce exceptions after this fix, we'll try not wrapping it in an exception handler any more and see what comes of that - none of spectest_regression depends on it.
15:07 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30987
15:08 masak jonathan++ # best present ever!
15:08 NotFound masak: I think I understand, but that goes against the idea of showing an example of clean and simple code.
15:08 jonathan masak: Report any issues you see as an upshot of this.
15:08 masak jonathan: sure thing.
15:08 masak NotFound: ah, didn't know that was a goal. nvm.
15:09 * masak has been working too long from the gotta-make-this-work-somehow angle
15:09 NotFound masak: well, is my goal for program in examples, at least.
15:09 jonathan masak: Also interested to know if there's the odd failure under spectest_regression but not at the command line for you.
15:10 moritz jonathan: don't forget to commit your test changes in the pugs repo
15:10 masak jonathan: 'll have to get back to you on that. :)
15:10 jonathan moritz: Yes, I have commits hanging to svn.perl.org...committing that one now...
15:11 moritz my last two commits did hang on the client, or otherwise reported failure
15:16 jonathan Updates to tests commited.
15:17 moritz thanks
15:17 NotFound If I try rurban suggestion of load_bytecode 'Xlib' instead of 'Xlib.pbc' and have the pbc already compiled if fails: error:imcc:syntax error, unexpected $end ('?') .... Xlib.pbc
15:18 NotFound Looks like is tring to compile the pbc file.
15:27 NotFound I see: the logic is extremely simple in Parrot_load_bytecode, if it has no pbc extension, is source.
15:30 pmichaud sorry for disappearing -- having to book a flight for my dad (and flights are cancelling quickly due to weather)
15:31 pmichaud bbiab
15:31 jonathan masak: Are there any particular tickets that are really blocking you at the moment, or at least being exceptionally annoying for November?
15:32 moritz I think the for/recursion scoping bug
15:32 NotFound We're still in September ;)
15:32 jonathan Yeah, but Rakudo loses me for most of October! :-P
15:33 jonathan So November is virtually close for me. ;-)
15:33 NotFound Strange internet world.
15:33 jonathan moritz: #58392: Recursion and for loops interact badly in Rakudo ?
15:35 masak jonathan: aye, that one
15:35 masak it's blocking the branch that replaces a cruddy HTML::Template (using regexes) with a cool one (using grammars)
15:36 masak and it keeps popping up when we want to do cool things, such as recurse correctly
15:36 masak I'd say that regardless of november, it's the most 'outstanding' bug in Rakudo right now
15:37 jonathan youch!
15:37 jonathan wtf...
15:37 masak kthxbai.
15:37 purl kthxbai is http://www.flickr.com/photos/goopymar​t/291244864/in/set-72157594362502502/
15:37 pmichaud jonathan: the reason for the exception handler was in case someone requested looking at a depth greater than the current caller/outer stack
15:38 masak purl: forget kthxbai
15:38 purl masak: I forgot kthxbai
15:38 jonathan pmichaud: OK, but since it's an internals function and nothing seems to be doing it...
15:38 jonathan An exception feels nice to me than it mysteriously not working.
15:38 pmichaud well, it's internals *now*, but we do need to eventually support OUTER:: and CALLER:: :-)
15:38 pmichaud yes, we can leave the handler out for now
15:38 NotFound Will be better call int 'chain'. We can't talk about stacks while telling people that we are stackless ;)
15:38 NotFound s/int/it
15:39 jonathan pmichaud: OK. I think it'll make it easier to spot problems for now, and we can easily enough add it back in later. :)
15:39 pmichaud I have no good ideas about 58392 and why it's not working.
15:39 pmichaud I've thought about it some but nothing makes sense to me
15:39 jonathan It looks...so odd.
15:39 pmichaud I'm guessing we may have some reference or lexical issues somewhere.
15:39 jonathan My first guess is that it's to do with lexical attachments or something.
15:40 pmichaud I haven't convinced myself that the current lexical environment supports recursion yet anyway
15:40 pmichaud I don't know that we have any tests for recursion, so it may be that some of the "fixes" we put in place over the summer actually broke recursion.
15:41 jonathan That would suck.
15:41 pmichaud lexicals in Parrot suck in general.
15:41 jonathan http://www.flickr.com/photos/goopymar​t/536757876/in/set-72157594362502502/ - but US government said teh internets is not a truck?!
15:41 jonathan pmichaud: True.
15:41 NotFound Did you mean rakudo tests, parrot tests, or both?
15:42 pmichaud I know that the last time I dealt with lexicals in parrot it ate up about 10 hours of my life trying to figure out what wasn't working, so I haven't been eager to check it
15:42 NotFound I can take a look at the parrot part.
15:42 jonathan I can't even remember the outcome of the whole thing.
15:42 pmichaud NotFound: I was referring primarily to rakudo tests, but I don't know that there are any parrot tests either
15:42 pmichaud jonathan: the outcome was that I needed to re-draft a lexicals design, but then oscon and vacations and yapc::eu hit
15:43 pmichaud Ultimately I still think we need to get rid of the Closure PMC
15:43 jonathan Aha, OK. So the re-draft is still pending...
15:43 pmichaud correct.  #58392 might prompt me to get to work on the re-draft
15:44 pmichaud I needed to get the mozilla foundation report finished first, though.
15:44 jonathan *nod*
15:45 NotFound pmichaud: I liked to see the xlib work mentioned in your report :)
15:45 pmichaud NotFound: yes, it was a readily-available example of where rakudo was being used for more than just running tests :-)
15:46 pmichaud jonathan++  # fixing !OUTER to work
15:53 pmichaud moritz:  (rakudo NEWS)   since I'm the one doing the Parrot release this month, I'll make sure NEWS gets updated :-)
15:54 moritz pmichaud: ooh, I didn't know that ;)
15:58 Theory joined #parrot
16:12 dalek r30988 | moritz++ | trunk:
16:12 dalek : [rakudo] tools/autounfudge.pl: skip a few more files by default
16:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30988
16:14 iblechbot joined #parrot
16:18 jonathan Hmmm. It's more complicated than just lexicals, I fear.
16:19 jonathan oh, no it's not
16:19 * jonathan has short-ish PIR example
16:20 moritz jonathan: chromatic offered to fix it if there was a (pure?) PIR example
16:21 jonathan moritz: Just attached it to the ticket.
16:21 jonathan Doesn't depend on Rakudo at all.
16:21 masak oh, that's good news
16:24 paco NotFound: now, I have the (64b) powah ... :   file parrot
16:24 paco parrot: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped
16:24 jonathan masak: It's reasonably short too.
16:24 masak yay!
16:25 masak swimming &
16:25 particle paco++
16:27 jonathan And it's certainly lexical related. Adding a call to newclosure gives the right output.
16:30 paco now I have to prepare a patch to hints, becouse I had to make some hand tuning to the makefile ..
16:30 particle paco: which distro, btw?
16:31 paco particle: is a debian one - Linux s390 2.6.18-6-s390x #1 SMP Tue Aug 19 04:50:55 UTC 2008 s390x GNU/Linux
16:31 particle i see, thanks
16:39 pmichaud jonathan: seeing r22207 (pugs repo) about autoincrementing Undef reminds me of something -- any way that we can get Scalar (Perl6Scalar) to default to initializing to something other than Undef ?
16:39 pmichaud like, Failure ?
16:40 pmichaud even better... could we avoid actually initializing the Scalar until it's needed?  Right now we create a separate Undef object every time a Scalar is created
16:41 pmichaud (actually, I guess most of this stuff is in Mutable)
16:42 jonathan pmichaud: It's all in Mutable, and yes, we literally do, if no initialization value is in, pass in Undef.
16:42 jonathan We can instantiate whatever we like in there by default.
16:42 pmichaud I'd like it to be PMCNULL until needed
16:42 particle Undef isn't a singleton?
16:42 jonathan Doing it lazily would mean checking if we have a value every time we do something.
16:43 jonathan particle: If it is, then I expect pmc_new on it returns the same thing every time. :-)
16:43 jan joined #parrot
16:43 pmichaud yes, but that won't be the case for Failure objects -- those aren't singletons.
16:43 jonathan Yes.
16:43 jonathan True.
16:43 particle right
16:43 jonathan Are you thinking that for different operations we will want to auto-vivify to different things?
16:44 jonathan So we call increment, and there's nothing in the container, so we create an Int in there?
16:44 moritz or ~=, and create a Str
16:44 pmichaud no, it should throw exceptions
16:44 pmichaud same as any other use of an undefined value.
16:44 jonathan my $x; $x++; # should throw an exception?
16:45 pmichaud I haven't heard that officially, but yes, I think that should be what happens
16:45 particle hrmm
16:45 jonathan Is it a warning to do that in Perl 5?
16:45 pmichaud not presently.
16:45 particle no
16:45 particle undef++ in perl 5 is 1
16:46 jonathan OK.
16:46 pmichaud whether it is an exception or not, we need a way to define such operations on "undef" values
16:46 moritz it's very useful for counting stuff in a hash
16:46 jonathan Aye.
16:46 moritz $lines{$key}++
16:46 pmichaud which means we can't be using Undef
16:46 pmichaud (the Parrot type)
16:46 particle rakudo: my String $x = ''; say ++$x;
16:46 polyglotbot OUTPUT[Method 'ACCEPTS' not found for invocant of class 'String'␤current instr.: '!DOTYPECHECK' pc 12992 (src/gen_builtins.pir:8185)␤called from Sub 'parrot;Perl6Object;infix:=' pc 60 (src/gen_builtins.pir:52)␤called from Sub '_block11' pc 80 (EVAL_11:38)␤called from Sub
16:46 polyglotbot ..'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)␤called ...
16:46 jonathan Yes, that isn't going to fly.
16:46 pmichaud Str, not String
16:46 jonathan particle: Str :-)
16:46 particle oops
16:46 particle rakudo: my Str $x = ''; say ++$x;
16:46 polyglotbot OUTPUT[␤]
16:47 particle rakudo: my Int $x = 0; say ++$x;
16:47 polyglotbot OUTPUT[1␤]
16:47 pmichaud rakudo: my Str $x = 'a'; say ++$x;
16:47 polyglotbot OUTPUT[b␤]
16:47 jonathan rakudo: my Int $x; say ++$x;
16:47 polyglotbot OUTPUT[Int␤]
16:47 particle heh
16:47 jonathan Ah, of course.
16:47 pmichaud I will likely get the protos to throw exceptions if used as values also
16:47 jonathan We have an Undef, which is the proto-object. :-)
16:47 jonathan Yes.
16:48 pmichaud sure, that works for my Int $x, but I'm looking at the case of    my $x;
16:48 pmichaud I suppose that $x could be initialized to the Object proto
16:48 particle is that my Object $x by default?
16:48 particle right
16:48 moritz in the case of signatures it's Any
16:48 pmichaud and that wouldn't involve creating Undefs
16:48 moritz in the case of 'my' it's Object
16:49 jonathan But just sticking the Object proto in there. Which is a singleton.
16:49 jonathan Would work.
16:49 particle moritz: sounds like a few reasonable tests
16:49 pmichaud and we can define prefix:<++> and other operations on Object proto to do what we want
16:49 particle indeed
16:49 pmichaud okay, I'll live with Undef in the Scalar code for now.
16:50 moritz particle: go right ahead ;)
16:50 jonathan pmichaud: We can easily change it to have the Object proto instead of undef.
16:51 pmichaud okay, that's fine also (assuming the PMC stays rakudo-specific)
16:51 jonathan Mutable is all in the Rakudo source tree at the moment
16:51 jonathan If it escapes, we can always generalize and subclass it.
16:51 pmichaud well, we were thinking it might graduate to core at one point
16:51 pmichaud right
16:51 particle why wait?
16:51 jonathan Wait for?
16:51 jonathan Making it core?
16:51 particle yep
16:51 pmichaud nobody else is using it yet, or has expressed a need for it
16:52 jonathan What Pm said.
16:52 jonathan No point adding stuff to core unless it's really being used by more than one langauge, or going to be.
16:52 jonathan Otherwise it's deprecation cycle stuff to remove it again.
16:53 jonathan pmichaud: This lexicals bug. It's...not fun. :-(
16:53 pmichaud jonathan: as I've been saying, lexicals are really broken in parrot
16:53 jonathan pmichaud: From what I can see, because we write on the sub->outer_ctx, it seems we affect all invocations of the sub
16:53 pmichaud should I retarget my focus for the next few days on that?  I've been working on getting the arrayref and hashref semantics correct, so that [ [1,2], [3,4] ]   will work properly.
16:54 jonathan And stuff isn't undone on return.
16:54 jonathan Well, it's frustrating to work on, but it's kinda important too.
16:55 pmichaud yes, I've seen that it's a big blocker for masak and November
16:55 jonathan Right. The !OUTER seemed to be one big annoyance, which is fixed now. And I gather this is the other.
16:55 jonathan I don't see any easy fix.
16:56 teknomunk joined #parrot
16:57 Andy joined #parrot
16:57 pmichaud I'll review the relevant threads this afternoon
16:58 pmichaud and see if I can come up with some ideas for fixing lexical handling
16:58 pmichaud but yes, Parrot's confusion between outer, caller, and newclosure is a big part of the problem.
16:59 jonathan I worry that we do stuff to a sub when we should really be touching the contexts too.
16:59 pmichaud I much prefer S04's notion of "cloning" contexts instead of newclosure
17:00 pmichaud and it very much bugs me that newclosure always produces a Closure PMC.  I think Closure PMCs are fundamentally wrong
17:00 jonathan As I mentioned earlier, adding a newclosure worked just great at fixing the problem here.
17:00 pmichaud yes, but putting a newclosure on every invocation has already shown to lead to problems
17:00 jonathan Yes.
17:00 jonathan Fixes this, breaks other things.
17:01 jonathan Just doing a clone doesn't help in this case.
17:01 pmichaud and putting a newclosure on every reference also seems to have difficulty
17:01 pmichaud well, "clone" has a slightly different meaning here than "strictly copy the Sub"
17:01 jonathan Yes.
17:01 jonathan Anyway, the short PIR example is attached to the ticket.
17:01 pmichaud okay, that should help.  Thanks.
17:02 jonathan (58392, just to be clear)
17:02 pmichaud yes, it hasn't hit my inbox yet.
17:02 jonathan http://rt.perl.org/rt3/Tic​ket/Display.html?id=58392 :-)
17:02 * jonathan finds a ticket he can probably close thanks to OUTER fix
17:02 jonathan As in, another one
17:03 pmichaud yes, your PIR example is the classic case where a newclosure is needed.
17:04 pmichaud (from the Parrot perspective, not from the "this is the way it ought to work" perspective)
17:04 jonathan moritz: t\spec\S05-match\blocks....Could not find non-existent sub plan - any clues?
17:06 jonathan moritz: Oh, was something else - don't worry
17:07 * moritz doesn't worry
17:08 jonathan pmichaud/moritz: In that test file:
17:08 jonathan if 1 { ok 'a' ~~ /./, 'Can match in an if block'; is ~$/, 'a', '... and can use the match var';
17:08 jonathan }
17:08 jonathan #?rakudo todo 'Proper contextual scoping for $/'
17:08 jonathan is ~$/, 'a', '... even outside the block';
17:08 moritz I'm not sure that one is correct
17:08 jonathan I think that maybe this is not what contextual scoping actually menas.
17:08 jonathan Not, looks dubious to me.
17:09 moritz I should clean that up
17:09 moritz to ok !$/.defined, '$/ is undef in the outer scope'
17:11 moritz done
17:12 jonathan Unfortunately, the while test exposes another, different bug.
17:13 jonathan But the if one can be un-todo'd.
17:13 jonathan while $str ~~ /b/ {
17:13 jonathan $count++;
17:13 jonathan $str = '';
17:13 jonathan $match = "$/";
17:13 jonathan }
17:13 pmichaud what's the bug in the while block?
17:14 jonathan In there, it seems that "$str = ''" ends up affecting what $/ references
17:14 jonathan And then you get: Cannot take substr outside string
17:14 pmichaud oh, yes.
17:14 jonathan (current instr.: 'parrot;PGE::Match;text')
17:14 rurban_ joined #parrot
17:14 pmichaud currently PGE Match objects reference the target string
17:14 pmichaud as opposed to cloning it
17:15 pmichaud that will be fixed when PGE gets Cursor objects
17:15 sjansen joined #parrot
17:15 jonathan OK
17:16 jonathan Can make the test pass by swapping the order of the two lines around! ;-)
17:16 jonathan Or is that too naughty? :-)
17:17 pmichaud that sounds like it should be a separate test
17:17 jonathan ok
17:17 jonathan Will swap them
17:17 pmichaud although perhaps we're being too naughty all-around there anyway -- perhaps it really should be 'last'  :-)
17:19 moritz is it the "can't return a match object" bug the we're hitting here?
17:24 jonathan moritz: No, it's that if you do a match on a string, then change the string, the bits of the match then try and index into the changed string.
17:25 moritz ah, 'is rw' by default. Call it a feature ;)
17:25 moritz erm, :rw I mean
17:25 jonathan :-)
17:26 jonathan Methods outside class declarations - only allowed if they're anonymous. :-)
17:26 jonathan (with reference to 58138)
17:27 moritz should I try to to add some form of quote parsing (like q/.../) that's easy to do with our current setup?
17:31 dalek r30989 | jonathan++ | trunk:
17:31 dalek : [rakudo] Re-work implementation of ... a bit.
17:31 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30989
17:31 pmichaud I'm fine with q, qq, qw, qqw
17:31 pmichaud I wouldn't get much more fancy than that :-)
17:31 moritz ok, I'll add those
17:32 pmichaud qqw would be very useful, as we don't have a good way of testing that at the moment.
17:32 pmichaud I need to see what's blocking the handling of «
17:32 pmichaud that *should* work.
17:33 moritz is qqw :qq :w or :qq :ww?
17:33 pmichaud check the spec?  ;-)
17:33 moritz I will
17:34 pmichaud oh, looks like there's not a qqw
17:34 pmichaud it's qww
17:35 pmichaud oh, I'm wrong again.
17:35 moritz the short forms are allowed
17:35 pmichaud qww, qqww, qqw, and qqww
17:36 pmichaud anyway, we don't need all of those -- just pick the more useful ones
17:36 moritz I'll go for qq qw q now, check that they are properly tested, then return to the others
17:36 * jonathan wonders how on earth to remember all of the q's and w's!
17:37 pmichaud the only other one I'd be interested in is the synonym for   « »
17:37 moritz jonathan: it's quite easy, once you've got the nack
17:37 moritz *knack
17:37 pmichaud note that the grammar can be clever enough to recognize that   qw, q:w, and q :w   are all identical
17:38 davidfetter joined #parrot
17:39 cognominal http://www.lefigaro.fr/economie/2008/09/10/0​4001-20080910ARTFIG00295-climat-des-affaires​-la-france-se-classe-au-erang-mondial-.php
17:39 cognominal trop fort le FMI et le Figaro
17:39 jonathan cognominal: l'incorrect channel?
17:39 moritz pmichaud: I don't think it makes sense to implement that yet, unless we implement pairs on quotes in general
17:39 cognominal oopd
17:40 pmichaud moritz, okay, if you wish.
17:42 moritz ouch, rakudo can't parse some unicode stuff in comments
17:42 pmichaud moritz:  can you paste an example?   It should be able to handle it.  :-|
17:43 jonathan pmichaud: The "use of uninitialized variables" really makes the spectest_regression output a load longer... :-S
17:43 jonathan Is this a temporary thing?
17:43 jonathan (It appearing in the test output, not the feature)
17:44 pmichaud it's temporary until the tests are fixed to not use uninitialized variables :-)
17:44 jonathan Cool.
17:44 jonathan I guess there will be tests to test the warning too. :-)
17:44 pmichaud meaning, when the tests no longer use uninitialized variables, then you won't see the warnings any more :-)
17:45 pmichaud it's permanent in the sense that using uninitialized variables will always issue a warning or exception of some sort :-)
17:45 moritz pmichaud: I just commited t/spec/S02-literals/quoting.t - the parser complains about line 68, even though fudge comment that out
17:46 jonathan OK, so it's the tests that need fixing. Thanks for the clarification.
17:46 moritz but the tests can only be fixed sanely if .defined really works
17:46 moritz last I looked that was a bit of a blocker
17:46 pmichaud I did add .defined to Object already -- are there others?
17:47 dalek r30990 | jonathan++ | trunk:
17:47 dalek : [rakudo] Methods written outside of a class, grammar or role should not be allowed unless they are anonymous.
17:47 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30990
17:49 jonathan From S04:     for =<> {...}
17:49 jonathan which is short for
17:49 jonathan for =$*ARGS {...}
17:49 * jonathan wonders how on earth to implement that
17:49 pmichaud it's a token
17:50 jonathan Oh, phew. :-)
17:50 pmichaud =<> is a token in its own right, I think.
17:50 moritz that's where LTM really helps ;)
17:50 jonathan OK, that's the only sane way I could see it happening.
17:50 jonathan I'm glad you agree. :-)
17:50 jonathan In that case, it's really easy.
17:50 pmichaud that's the way we discussed it in the design meeting a couple of years ago when that came up :-)
17:50 jonathan ...if I can work out what precedence it should have...
17:51 pmichaud it's a term.
17:51 jonathan Or is it just a term?
17:51 pmichaud it's not in STD.pm yet, though.
17:51 jonathan OK, should I send a note about that to somewhere?
17:52 moritz just tell TimToady in #perl6
17:52 pmichaud I think TimToady will likely catch it at some point.  :-)
17:52 dalek r30991 | moritz++ | trunk:
17:52 dalek : [rakudo] implement qq qw and q quoting forms
17:52 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30991
17:53 pmichaud moritz: fwiw, right now it would be quicker (perhaps much quicker) to factor out the initial q
17:54 moritz pmichaud: not sooo likely, because =<> probably already parses, only differnt
17:55 jonathan hang on - $*ARGS, isn't it @*ARGS?
17:56 pmichaud moritz:  I bet =<> is parsing due to   prefix:=  followed by <>  quoter
17:56 moritz yes, that's what I meant
17:57 NotFound There is a test in lexicals.t labeled 'find_lex: (Perl6 OUTER::)' that is todo'ed. This is related to the problems you where commenting?
17:57 pmichaud we did discuss that perhaps <> quoter should evaluate to @*ARGS when used in this manner, but we later decided it was better to not try such dwimmery and just use a special term for it
17:57 pmichaud i.e., = followed by <> was just a little "too clever"
17:59 moritz pmichaud: re speed difference, it only makes a difference for parsing quote constructs, right?
17:59 jonathan pmichaud: Argh - it actually parses it as =<>!
17:59 jonathan As in = <>
17:59 jonathan (prefix:= called on empty list)
18:00 pmichaud right
18:00 pmichaud you mean rakudo or STD.pm?
18:00 jonathan Rakudo.
18:00 pmichaud it's the same issue that we don't have a good way of mixing prefix operators and terms
18:00 pmichaud i.e., LTM
18:00 jonathan Same bug we have as with ??? and !!! and ->
18:01 pmichaud it's possible that I could get term:<!!!>, term:<???>, and term:« =<> »   to parse, though.
18:01 pmichaud parsing -> is tricky because more than just the token has to be parsed.
18:02 pmichaud moritz:  the speed difference will be there for every time we're matching a term -- i.e., a place that a quote might be (as opposed to where a quote is)
18:02 jonathan Is there not a way we can give the precedence parser a list of things and say, "if you see this sequence of characters, back off and hand back to term"?
18:02 pmichaud sure, there's a way to do it
18:02 pmichaud it does that now
18:02 moritz pmichaud: I can refactor it, no problem
18:02 pmichaud oh, wait, "hand back to term" -- not exactly
18:03 pmichaud let me explain a bit further
18:05 pmichaud (phone again, sorry)
18:06 moritz rakudo: my $x; say $x.defined
18:06 polyglotbot OUTPUT[set_attr_str() not implemented in class 'Undef'␤current instr.: 'parrot;Failure;!exception' pc 8693 (src/gen_builtins.pir:5554)␤called from Sub 'parrot;Failure;defined' pc 8747 (src/gen_builtins.pir:5572)␤called from Sub '_block11' pc 27 (EVAL_13:17)␤called from Sub
18:06 polyglotbot ..'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)␤calle...
18:07 moritz pmichaud: (when you're back from phone) that's one of the things that block me from using .defined everywhere in the test suite
18:07 moritz and it's no fun to figure out where I can actually use it, and where not
18:09 jonathan I'd expect putting the Object proto instead of Undef woudl help with that.
18:11 moritz isn't there a way to make *everything* accessible from rakudo an Object?
18:11 moritz even foreign data structures that are imported via NCI
18:12 dalek r30992 | rurban++ | cygwin070patches:
18:12 dalek : more make cleanup
18:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30992
18:13 pmichaud moritz: short answer, no.
18:13 pmichaud yes, when we get "my $a" to initialize to something other than Undef, then ".defined" should work
18:14 pmichaud the other somewhat messier approach would be to add a .defined method to Undef, similar to the way we augment methods in Integer, String, ResizablePMCArray, etc.
18:15 jonathan pmichaud: After using the Object proto instead:
18:15 jonathan my $x; say $x.defined;
18:15 jonathan 0
18:15 jonathan (Instead of undef)
18:15 jonathan However, Test.pm fails to compile now.
18:15 jonathan ..\..\parrot.exe  perl6.pbc --target=pir --output=Test.pir Test.pm
18:15 jonathan get_number() not implemented in class 'Object'
18:16 pmichaud I'm guessing an uninitialized value
18:17 jonathan Why would it fail in the compilation, though?
18:17 jonathan Adding the get_number v-table method, I then get even stranger things: "Could not find non-existent sub diag"
18:18 pmichaud where did you put get_number()?
18:18 pmichaud diff output, please?
18:18 jonathan .namespace ['Perl6Object']
18:19 jonathan Maybe should abeen ont he proto...
18:19 jonathan nopaste?
18:19 clunker3 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/
18:19 purl somebody said nopaste was at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/
18:19 pmichaud I think adding get_number to Perl6Object might be evil -- it might affect Num, Int, Str, etc.
18:19 nopaste "jonathan" at 85.216.151.226 pasted "pmichaud - diff" (80 lines) at http://nopaste.snit.ch/14020
18:19 pmichaud at any rate, using get_number on a proto should produce a warning anyway (like Failure), so that's not really a solution
18:19 pmichaud we need to avoid whatever is calling get_number in the first place
18:20 jonathan pmichaud: Agree, I did it more out of curiosity if it got us through the compile rather than as a fix.
18:20 jonathan oh, that diff is full of =<> stuff too
18:22 pmichaud okay, I have four tasks open now.  :-|   which one would you like me to focus on:  getting terms to parse or fixing .defined or ...?
18:22 pmichaud :-)
18:23 moritz some of the uninitialized warnings are triggered by TODO tests
18:23 jonathan All in parallel? :-)
18:23 jonathan I can investigate this one a bit more.
18:23 moritz lambdas would be quite nice
18:23 jonathan I'll leave you with the parsing.
18:23 jonathan The parser scares me.
18:23 moritz should I skip the TODO tests that cause warnings?
18:25 jonathan Hmm. Interesting. --target=past spits out this error at the end, after all of the output. :-S
18:25 hercynium joined #parrot
18:25 rurban svn: Commit failed (details follow): svn: MERGE of '/parrot/branches/cygwin070patches': 200 OK (https://svn.perl.org)
18:25 dalek r30993 | moritz++ | trunk:
18:25 dalek : [rakudo] refactored qq, qw, q parsing to be more efficient
18:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30993
18:26 jonathan Ah. It's in the END block.
18:26 rurban Is my branch already merged?
18:26 pmichaud I'm guessing 'main' is being a little over agressive.
18:26 jonathan rurban: No, svn is a tad messed up today. Your patch most likely has been commited.
18:26 purl okay, jonathan.
18:26 jonathan purl, rurban:, No, svn
18:26 purl jonathan: sorry...
18:27 rurban 200 OK doesn't look an error to me neither
18:27 jonathan Oh no, what has she saved that one under.
18:27 jonathan rurban: if you svn up, should find it was checked in
18:27 moritz yes, the svn server seems to be a bit b0rked
18:27 jonathan Taht's what I've been doing.
18:27 rurban everything ok.
18:28 pmichaud jonathan: ah, this points out a bigger bug -- @?END_BLOCKS only gets filled in when compiling perl6 source
18:28 jonathan pmichaud: Thing is, the variables are not set in a BEGIN block, but are tested in an END block.
18:28 jonathan pmichaud: Yes, but this is when we are compiling Test.pm that we get this error.
18:28 pmichaud right.  exactly.
18:28 jonathan if ($testing_started and $num_of_tests_planned != $num_of_tests_run) {  ##Wrong quantity of tests
18:28 jonathan Here, I think.
18:28 jonathan We do things like
18:28 jonathan our $num_of_tests_run = 0;
18:28 jonathan our $num_of_tests_failed = 0;
18:28 jonathan But not in a BEGIN block.
18:29 pmichaud I think you're missing my point
18:29 jonathan Probably. :-)
18:29 pmichaud right now, things get added to @?END_BLOCKS during the action methods
18:29 jonathan Yes.
18:29 pmichaud that's wrong in two ways
18:29 pmichaud (1)  we might not be compiling to immediate execution
18:29 pmichaud (2)  the PIR that we generate doesn't cause the END block to be added to @?END_BLOCKS when it's run
18:30 jonathan Ah.
18:30 pmichaud it needs to be part of a loadinit
18:30 * jonathan wonders how Test.pm was working anway
18:30 pmichaud I'm guessing the END block isn't being run
18:30 jonathan Or maybe this bit int he END block never did get run.
18:30 jonathan We'd not have noticed - ti's just diagnostics.
18:30 pmichaud and thus the "diag" message :-)
18:31 jonathan :-)
18:31 jonathan All makes sense now.
18:31 jonathan OK, that explains what's wrong.
18:31 pmichaud so, first question -- do we need that END block?
18:32 jonathan Well, maybe not *need* because we've been doing fine without it for a while. But the diagnostics would probably be good to have.
18:32 pmichaud yes, but should we be getting those diagnostics just because someone decided to do    "use Test;"   ?
18:32 pmichaud i.e., it's giving us the diagnostics whenever we run a test script directly
18:32 pmichaud (as opposed to doing it with something like 'prove' or from an external harness)
18:33 jonathan That, I can't answer
18:33 pmichaud also bear in mind that it's likely that the test functions will become builtins :-)
18:33 pmichaud I suggest the following:
18:33 pmichaud (1) remove END from Test.pm
18:33 pmichaud (2) see if things work with the Undef-->Object switch, and if that solves Moritz's .defined issue, if so, commit
18:34 pmichaud (3) file a ticket that we're not handling END blocks properly :-)
18:34 pmichaud end
18:35 pmichaud alternate to (3) is to just fix the END block handling :-)
18:35 jonathan Done 1
18:35 particle invalid code after 'end'
18:35 jonathan Runing tests to determine 2
18:35 pmichaud I need lunch.
18:35 jonathan This does have the slight issue that
18:35 jonathan my $x; say $x.WHAT; # Object
18:35 jonathan :-)
18:35 pmichaud ...before it was doing, what?
18:35 jonathan Undef
18:36 pmichaud Undef is clearly wrong.
18:36 jonathan Or more likely, Failure
18:36 jonathan I think Failure.
18:36 pmichaud oh, it might have been mapped to Failure.
18:36 jonathan Yes.
18:36 jonathan It was Undef PMC, but that was mapped to Failure.
18:36 jonathan Talking of food...it's time I cooked some too.
18:36 pmichaud anyway, TimToady has speculated on #perl6 that perhaps things default to the Object proto, so while we don't have a spec yet, that's good enough for me.
18:37 * jonathan creates a LolCat proto and defaults to that, hoping it might make it into the spec
18:37 pmichaud oh, that reminds me
18:37 moritz not that in 'sub foo ($x?)' $x can't default to Object proto, rather Any (IMHO)
18:38 jonathan moritz: Hmm, good point.
18:38 pmichaud that's okay, parameter handling is going to be totally different anyway
18:38 pmichaud we never have an uninitialized param
18:38 pmichaud at least, not in the sense that we do for variable declarations
18:39 pmichaud but parameter initializing code is different from variable declaration code, so it shouldn't be a big issue
18:39 pmichaud (Object vs. Any)
18:39 jonathan Damm. The change makes us fail some tests.
18:39 jonathan Failed 9/159 test scripts. 35/4859 subtests failed.
18:39 jonathan :-(
18:39 pmichaud probably having to do with definedness and/or object truth
18:40 pmichaud or possibly being able to increment or otherwise use uninitialized values
18:40 pmichaud anyway, lunch is a requirement now.
18:40 pmichaud bbiaw
18:42 particle has the code for november been published?
18:42 pmichaud it's in a git repo, I think.
18:42 jonathan is($one, undef, 'two blocks ({} {}) no semicolon after either,.. first block does not execute');
18:42 jonathan That is one that now fails, for example.
18:42 pmichaud sure, because Object != Failure :-)
18:42 moritz jonathan: because it stringifies different
18:42 moritz ly
18:43 moritz particle: http://github.com/viklund/november/
18:43 particle thanks
18:43 jonathan pmichaud: Aye. But not quite sure what the fix for this is. :-) But anyway, lunch...and for me dinner.
18:44 pmichaud the test itself is wrong
18:44 jonathan OK, and it should be?
18:44 pmichaud we can't use 'is' to check for undef anymore (at least not as currently defined)
18:44 particle nok($one, '...')
18:44 pmichaud it should be   ok !$one.defined
18:45 particle er, right
18:45 pmichaud ....which is why moritz++ wants .defined to work (currently it doesn't -- it gives an error when we attempt to invoke the 'defined' method on an Undef PMC)
18:45 pmichaud so, fixing the code and the test should cause everything to work :-)
18:45 pmichaud it's okay with me to use a stopgap of adding a 'defined' method to the Undef PMC
18:46 rurban pdd30_install idea: parrot install.pbc mylib --build --test --installable --test-installable --install
18:46 jonathan Meh, if that's all it will take to get this fixed up, I'll fix the testes now.
18:46 rurban --build --test --installable --test-installable --install being optional
18:46 jonathan *tests
18:46 jonathan !!
18:46 pmichaud maybe dinner would be better first.  :-)
18:46 rurban this should be used for parrot languages and libraries (on CPAN6)
18:47 jonathan Yes.
18:47 * jonathan goes for dinner
18:50 moritz jonathan: with your fix, will $stuff ~~ undef work?
18:50 pmichaud we should be able to make it work, yes.
18:50 pmichaud that's really just a matter of defining Failure.ACCEPTS, I think.
18:51 moritz then I offer that I'll fixe the broken tests that jonathan's fix reveals
18:51 pmichaud we should be able to make that work even before jonathan's fix
18:51 pmichaud except that he and I apparently both need to eat.
18:51 pmichaud so, food first.
18:51 pmichaud (really gone this time.)
19:09 japhb joined #parrot
19:14 Hinrik joined #parrot
19:19 rurban cpan6?
19:19 purl it has been said that cpan6 is more like a METAPAN
19:19 rurban I envision either "cpan6 mylib --download --build --test --installable --test-installable --install"
19:20 rurban or cd mylib && parrot Makefile.pir
19:20 rurban Makefile.pir does load_bytecode 'Parrot/Install'
19:21 rurban and generates the Makefile
19:30 japhb joined #parrot
19:36 dalek r30994 | moritz++ | trunk:
19:36 dalek : [rakudo] allow $stuff ~~ undef
19:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30994
19:37 Hinrik joined #parrot
19:41 moritz pmichaud: t/spec/S04-statements/return.t exhibits some failures after being re-written as ok(!defined(subcall()), ...)
19:41 moritz pmichaud: should I fudge them and open a ticket?
19:42 hercynium joined #parrot
19:44 dalek r30995 | rurban++ | cygwin070patches:
19:44 dalek : [pdd30] added long-term goals and competing layout variants
19:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30995
19:49 * jonathan returns from The Dinnber
19:49 jonathan *dinner
19:50 jonathan moritz: Will do spectest_regression again with your latest changes to it and Rakudo plus my Object change and see how it goes.
19:51 moritz jonathan: ok. 3 failed tests in return.t are to be expected (if not even better)
19:52 hercynium joined #parrot
19:55 dalek r30996 | rurban++ | cygwin070patches:
19:55 dalek : root/Makefile: languages need install_config.fmpc, no circular all-installable deps
19:55 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30996
19:58 jonathan Yes, the ones in return.t are new.
19:58 jonathan (As in, weren't there before your changes)
19:58 jonathan I've also got a new failure in t\spec\S03-operators\binding-scalars.raku    1   256    28    2  28
19:59 moritz try to run that one again please
19:59 moritz I don't get it in trunk
19:59 moritz and I've seen some temporary failures now and then during the last few days
20:00 jonathan not ok 27 - bound keyword# TODO List binding
20:00 jonathan get_number() not implemented in class 'Object'
20:02 Hinrik joined #parrot
20:02 jonathan equality.t fails on
20:02 jonathan ok($foo == 0,      "Undef == 0");
20:03 jonathan We deleted the END code that did similar.
20:03 jonathan But we shouldn't just do that here I suspect.
20:04 moritz aye
20:05 dalek r30997 | rurban++ | cygwin070patches:
20:05 dalek : root/Makefile: 58354-installable_parrot_config.patch
20:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30997
20:05 rurban svn is always locking up today
20:05 moritz a Any, Any multi for == that numifies?
20:06 jonathan We have that
20:06 jonathan The problem is that Object refuses to numify.
20:06 jonathan The error about get_number() occurs because an Object will not numify.
20:07 rurban and stringifiy it and numify the strings?
20:07 particle should Object numify? i think not.
20:07 particle eval_dies_ok(+$foo, "Object does not numify");
20:07 jonathan particle: If we're going to stick it in scalars by default instead of Failure (Parrot Undef), however...
20:08 jonathan Doesn't feel especially Perl-ish.
20:08 particle can you attach a trait that allows it to numify when stuck in a scalar?
20:08 jonathan Well, we could stick these in the proto rather than for Object itself perhaps.
20:09 jonathan The other intresting one will be: my $foo; say $foo; # Object
20:09 jonathan Bit surprising.
20:10 jonathan Maybe if there's a Failure role that gets mixed in, it'd work.
20:10 particle Object but Failure :)
20:10 jonathan Right.
20:11 jonathan So we do that and just stick it somewhere that can be retrieved each time we want to use it in a Scalar.
20:11 dalek r30998 | rurban++ | cygwin070patches:
20:11 dalek : [jvm] fix codetest, rm Makefile
20:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30998
20:11 particle yep
20:11 jonathan OK, will get pm's opinion, when he's done with nomming lunch. :-)
20:17 dalek r30999 | rblasch++ | trunk:
20:17 dalek : [config] Report MSVC version during Configure.
20:17 dalek : The MSVC version is important when looking for issues, but people sometimes
20:17 dalek : forget to add this to tickets, but post Configure's output.
20:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=30999
20:17 pmichaud back
20:18 dalek Ronald Blaschke | Platforms:
20:18 dalek link: http://www.perlfoundation.or​g/parrot/index.cgi?platforms
20:19 jonathan pmichaud: w/b - you can haz backscroll
20:20 pmichaud my $foo;  if +$foo == 0 { ... }      # should be a "use of uninitialized value" warning/error
20:20 jonathan OK, but the test should suceed also, if it's a warning?
20:20 dalek r31000 | rurban++ | cygwin070patches:
20:20 dalek : [pdd30] quote =>
20:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31000
20:20 moritz jonathan: yes
20:21 pmichaud well, if "use fatal" is in effect it'll die.  but yes, in absence of fatality it would numify to 0, the same way that Failure does
20:21 pmichaud I almost want to create a Perl6Undef role that incorporates these behaviors
20:21 pmichaud then all protoobjects would perform that role, as well as Failure instances
20:22 pmichaud in parrot, do vtable methods in roles compose properly?
20:22 jonathan Not completely sure - I'd think they do.
20:22 pmichaud okay
20:22 jonathan They can probably be made to without much trouble if not.
20:23 pmichaud if nothing else I could do it with class composition
20:23 jonathan Sure, but it's nicer as a role.
20:23 pmichaud roles can haz attributes?
20:23 jonathan Yes.
20:24 jonathan But to be composed properly you need to use the Rakudo stuff to do it.
20:24 pmichaud oh, P6object should probably learn to handle roles
20:24 jonathan Parrot doesn't handle that. Perl 6's needs are a little interesting.
20:24 jonathan Probably.
20:24 purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
20:24 jonathan Perl 6's role composition for attributes actually ties into the Perl 6 type system a bit too.
20:25 pmichaud well, I'm thinking it'll be strictly internal, not anything exposed
20:25 Whiteknight joined #parrot
20:25 jonathan Sure.
20:25 pmichaud (except for the methods that get composed in)
20:25 jonathan Maybe better to wait until we're a bit more complete with roles before working it into P6Object, though?
20:25 pmichaud maybe
20:25 jonathan Things are almost certainly going to change a lot when I do parametric roles.
20:25 pmichaud otoh, protoobjects in P6Object might be a bit better off as roles
20:26 pmichaud instead of the P6protoobject being a class as it is now
20:26 jonathan A Perl 6 role object is going to become something like a multi-sub.
20:26 jonathan Which itself contains a bunch of Parrot-level roles.
20:27 jonathan However, that blocks on me finishing Perl 6 multiple dispatch first. :-)
20:27 * jonathan has a whole stack of trickyish stuff to worry about.
20:28 pmichaud I wonder if protoobjects should really be done with mixins
20:28 jonathan Very possibly.
20:28 pmichaud I guess that's kinda what P6object is doing now
20:28 jonathan Yeah.
20:28 jonathan It pretty much is. :-)
20:28 pmichaud except it's mixing in a class instead of a role.
20:28 jonathan Create an anonymous subclass that inherits from the protoobject class.
20:29 pmichaud that's what it does now
20:29 jonathan It's about the same thing as a does
20:29 jonathan Or a but
20:29 pmichaud yeah
20:29 jonathan So yes, you could do those quite easily as roles.
20:30 jonathan (It'd actually once composed perform a tiny bit better too, I expect...)
20:30 jonathan OK, so for undefined values, we're going to go with a Perl6Undef role?
20:31 pmichaud I need to think about it a little bit more
20:31 jonathan OK
20:31 pmichaud I'm pretty certain that P6object will somehow override get_number, etc., in protoobjects
20:31 jonathan I really shoudln't commit my patch to switch us to Object instead of Undef. It breaks far too much.
20:31 pmichaud it's an easy enough patch -- just hold it, or submit it to RT so several of us can play with it
20:31 contingencyplan joined #parrot
20:31 jonathan Heh, it's a couple of lines. :-)
20:32 pmichaud we could even work on it in a branch, although I think it's not (yet?) significant enough to warrant a branch
20:32 pmichaud moritz was asking that we get   $foo ~~ undef to work -- that we should be able to do immediately
20:32 jonathan I already have one nasty out-dated branch. :-|
20:32 jonathan I think he checked it in already himself, while we were eating. :-)
20:32 moritz pmichaud: I already tried
20:32 moritz pmichaud: and comitted, because I thought it worked
20:33 moritz > say undef ~~ undef
20:33 moritz 0
20:33 Tene jonathan: want me to update the lazy branch for you?
20:33 pmichaud oh, I didn't see the dalek message for it
20:33 jonathan Tene: That would be great.
20:33 moritz obviouusly I failed
20:33 * jonathan is fail at branch management.
20:33 Tene I should be able to do that today.
20:33 jonathan Thanks!
20:33 jonathan Don't expect much to pass in that.
20:33 jonathan Before or after merging.
20:34 pmichaud oh, there's the dalek message... just a sec
20:35 jonathan pmichaud: One other issue is that proto-objects need to override .item to just return themselves. And not pass up to the .item of the class itself. Which if it's a list causes oddness. :-)
20:35 jonathan I'm going to do that now.
20:35 pmichaud for Failure.ACCEPTS, I think I'd recommend   $I0 = defined other    instead of   $I0 = other.defined()
20:36 pmichaud also, the logic seems backwards to me
20:36 pmichaud the test should return false if other is defined, true otherwise
20:37 pmichaud jonathan: I'm still having to re-think .item a bit as part of arrayref and hashref
20:37 * moritz must have been sleeping
20:37 pmichaud however, you're correct that .item on protos should return itself.  That can be added the same way we did .WHICH, I suspect.
20:37 Hinrik joined #parrot
20:38 pmichaud (or .WHERE.  I forget.  Too many interrogative pronouns.)
20:38 moritz pmichaud: I've got a fix now... testing locally...
20:39 jonathan pmichaud: Yes, will do.
20:39 Hinrik joined #parrot
20:39 jonathan It'll let me close an RT ticket. :-)
20:39 pmichaud jonathan is getting all of the fun of closing rt tickets today :-|
20:39 nopaste "jonathan" at 85.216.151.226 pasted "Switching to Object proto from undef" (13 lines) at http://nopaste.snit.ch/14024
20:39 moritz pmichaud: you didn't close the Hash.kv ticket, although you said you'd do
20:40 pmichaud I found it it's still broken
20:40 dalek r31001 | rblasch++ | trunk:
20:40 dalek : [config] Adjusted tests to config/auto/msvc changes.
20:40 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31001
20:40 pmichaud s/it/out/
20:40 jonathan pmichaud: There is the patch. But it's going to change notably if we're doing the mixin thing anyway.
20:40 pmichaud rakudo: my %a = { b => [1,2] };  say %a.kv.perl;
20:40 polyglotbot OUTPUT[["b", 1, 2]␤]
20:40 jonathan I can re-create it in the same 2 minutes it took the first time if we do want it.
20:40 pmichaud it'll change?
20:41 jonathan Well, we'll need to stick the object with the role mixed in
20:41 pmichaud that would be Object -- the role would already be mixed in
20:41 jonathan Unless you were thining that ProtoObject would just carry the "warn and numify to 0" stuff?
20:41 jonathan Aha.
20:41 Hinrik joined #parrot
20:41 pmichaud yes, Protoobject will have it.
20:41 jonathan OK, so it'd not change.
20:41 jonathan OK.
20:41 pmichaud all protoobjects should not be used as values
20:41 jonathan *nod*
20:41 pmichaud (because they're all undefined)
20:42 pmichaud of course, we'll have a way for a class to override that behavior for its proto, but that's the default
20:42 dalek r31002 | moritz++ | trunk:
20:42 dalek : [rakudo] fixed Failure.ACCEPTS, pmichaud++
20:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31002
20:43 pmichaud that's why I was saying earlier that I may put warnings directly into P6protoobject
20:43 pmichaud so that we get it for all protos, not just Rakudo ones
20:43 jonathan Aha, OK.
20:43 pmichaud .oO( if Failure.ACCEPTS(pmichaud++), then does that mean I'm undefined?)
20:44 moritz pmichaud: you're meta-defined
20:44 jonathan .item and .list on a proto are obvious enough - .hash? Exception?
20:44 pmichaud I'd leave .hash to its default
20:44 pmichaud (which is generally to try to build a hash from .list)
20:45 jonathan my %x = Hash.new.WHAT; # is ok?
20:46 pmichaud that one confuses me.
20:46 jonathan Me too
20:46 pmichaud you're assigning a protoobject to %x ?
20:46 pmichaud and isn't that the same as    my %x = Hash ?
20:46 jonathan Yes.
20:46 pmichaud that's likely an error
20:46 pmichaud but that's a type mismatch, unrelated to the proto
20:47 pmichaud oh, it's not a type mismatch
20:47 jonathan OK, but thing is that assigning to %x will call .hash on Hash
20:47 pmichaud effectively it's the same as   my %x = list(Hash);
20:47 jonathan Which for a Hash returns...itself.
20:47 jonathan Unless you have a type which defines .hash differently, though?
20:47 pmichaud my %x = Hash   does not call .hash on Hash directly
20:48 pmichaud it calls .hash on list(Hash)
20:48 jonathan OK
20:48 pmichaud because my %x = ... is a list assignment
20:48 jonathan Aha.
20:48 jonathan OK
20:48 jonathan So we just don't bother writing hash method for protos and we should be OK?
20:48 pmichaud I think so.
20:48 pmichaud if I'm wrong, we'll find out :-)
20:48 jonathan Well, it doesn't error.
20:48 jonathan my %x = Hash; # runs fine in Rakudo today
20:49 pmichaud that's because we don't really implement a good list assignment yet :-)
20:49 jonathan OK.
20:50 pmichaud rakudo:  my %x = Hash; say %x.WHAT;
20:50 polyglotbot OUTPUT[Hash␤]
20:50 jonathan It calls infix:= on Perl6Hash, which in turn calls .hash on Hash.
20:50 jonathan Which reads
20:50 pmichaud oh, because we've overloaded infix:=
20:50 jonathan .sub 'hash' :method .return (self)
20:50 jonathan .end
20:50 jonathan Right.
20:51 jonathan So we never end up making a list, and thus we never see an error.
20:51 pmichaud I think that's an incorrect implementation that works for now.
20:51 jonathan Ah.
20:51 moritz there's no hash context
20:51 dalek r31003 | rblasch++ | trunk:
20:51 dalek : [config] Quote $icuheaders in t/steps/auto_icu-01.t.
20:51 dalek : For example, the path may contain backslashes on Windows, messing up the
20:51 dalek : regex.
20:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31003
20:52 pmichaud at some point in the future we may want to implement a Perl6Hash PMC that acts more like a list of Pairs
20:52 jonathan OK.
20:52 pmichaud with some very good key-indexing
20:52 jonathan So for now I should just ignore the problem? :-)
20:52 pmichaud sure, or file an RT marker for it :-)
20:52 pmichaud up to you.
20:52 jonathan I don't see why we can't die early.
20:52 jonathan Trying to form a Hash when you only have one element can never work.
20:52 pmichaud well, that's what will happen.
20:53 jonathan As I understand it anyway.
20:53 jonathan OK.
20:53 pmichaud it'll be the same as if we had done
20:53 pmichaud rakudo:  my %a = 1;
20:53 polyglotbot OUTPUT[Odd number of elements found where hash expected␤current instr.: 'parrot;List;hash' pc 2872 (src/gen_builtins.pir:2010)␤called from Sub 'parrot;Perl6Hash;infix:=' pc 4689 (src/gen_builtins.pir:3222)␤called from Sub '_block11' pc 25 (EVAL_11:15)␤called from Sub 'parrot;PCT::HLLCompiler;eval'
20:53 polyglotbot ..pc 806 (src/PCT/HLLCompiler.pir:481)␤called from...
20:53 jonathan Right.
20:53 jonathan That's what I'd expect from my %a = Hash;
20:54 pmichaud we could fix infix:= so that it first coerces to list context before building the hash
20:54 pmichaud that would make  my %a = Hash;   fail properly
20:55 jonathan That'd work for me.
20:55 pmichaud but since I'm expecting we'll be revamping contexts yet again in the near future, I'd say let's not worry about it too much
20:55 jonathan Yes.
20:56 jonathan We need to solve the "can't assign match objects" problem at some point too.
20:56 pmichaud when does that occur?
20:56 pmichaud (I've lost track)
20:57 moritz for example when returning a match object from PIR from Str.subst
20:57 moritz or the to-be-written Str.comb
20:57 moritz no, Str.match (not subst)
20:58 Tene Okay, either tomorrow night or saturday during the day I'm going to get some caffeine and crank through the exception issues.
20:58 jonathan Yes, from .match
20:58 Tene At the very least do pmichaud's throw API refactor.
20:58 jonathan But just try
20:58 Tene I'll see if I can eliminate the "disabled exception handlers" issue also
20:59 pmichaud Tene:  I was wondering if I assign a zero to the exception handler if that would re-enable it.
20:59 jonathan rakudo: "foo123" ~~ /o(\d+)/; my $x = $/; say $x; say $x[0];
20:59 polyglotbot OUTPUT[o123␤get_pmc_keyed() not implemented in class 'String'␤current instr.: '_block11' pc 82 (EVAL_13:32)␤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)␤called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1078 (src/PCT/HLLCompiler.pir:610)␤called from Sub
20:59 polyglotbot ..'parrot;PCT::HLLCompiler;command_line' pc 1257 (s...
20:59 Tene pmichaud: yes.  can you get the EH in pir, though?
20:59 pmichaud Tene:  sure
20:59 pmichaud if I build it and register it instead of using push_eh LABEL
21:00 pmichaud $P0 = new 'ExceptionHandler'
21:00 pmichaud set_addr  $P0, label
21:00 pmichaud push_eh $P0
21:00 pmichaud ...and then later
21:00 pmichaud $P0 = 0
21:00 pmichaud to reset the handler to being active
21:00 Tene Want me to confirm that that works?
21:01 pmichaud sure, I was going to write a reply to the rt ticket with a demo (if it worked), but I've been too busy answering questions for little or no karma points :-)
21:01 Tene pmichaud++ # bugging me to do stuff
21:01 jonathan pmichaud++ # answering questions for little or no karma points
21:01 pmichaud ....but in thinking about gather/take altogether, I've been wondering if resumable exceptions is really the way to go.  Coroutines might be better
21:01 Tene I thought about that too
21:01 dalek r31004 | jonathan++ | trunk:
21:01 dalek : [rakudo] Fix assigning a proto-object.
21:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31004
21:01 pmichaud but I'm not sure how to .yield from a different sub
21:02 jonathan A friend was asking me the other day about iterators in Perl 6, so I mentioned gather/take as being a way to implement such things.
21:02 pmichaud for a lot of the builtins we could probably handle iterators using .yield
21:02 jonathan And he then asked if you could have an array with that iterator in it, and then shift from it in different threads, so it's like a task queue. :-)
21:03 jonathan I was like, "hmm...well I'd hope so", then thought about the fun of making that actually work. :-S
21:03 pmichaud but I've been thinking that we might be able to do .yield in the return_pir section of blocks
21:03 Tene pmichaud: it runs, but segfaults at the end
21:03 pmichaud so, we throw an exception, but instead of doing .return(foo)   we do .yield and then re-enable the exception handler
21:04 nopaste "tene" at 67.137.148.179 pasted "exception handler re-enable test for pmichaud" (34 lines) at http://nopaste.snit.ch/14025
21:04 pmichaud I was going to re-enable the handler inside of the handler itself
21:04 pmichaud i.e., just before returning to the continuation
21:05 pmichaud anyway, we still need resumable exceptions for "warn" semantics, but I'm thinking gather/take based on .yield might be a bit better
21:05 pmichaud I think there is a problem there though that I doubt that Coroutines can contain :outer
21:06 pmichaud (thus my earlier comments that I think we need to eliminate the Closure PMC)
21:06 jonathan Gah, so I'm trying to get the RT queue for Rakudo down to 150 and then moritz goes and files another bug when I get down to 151!
21:06 jonathan :-P
21:06 pmichaud moritz++  # make jonathan *work* for his accomplishments :-)
21:06 moritz lol
21:07 pmichaud when I last worked on the RT queue, it was down to about 70.  I don't know what happened over the summer -- someone messed up my queue :-)
21:07 cotto_work the only bad thing that can happen to the number of tickets is for it to stay the same
21:07 jonathan moritz: Hmm. On the latest one you filed...
21:07 jonathan sub bar { return }; say defined(bar());
21:07 moritz pmichaud: I think it was obra, masak and me ;)
21:08 japhb joined #parrot
21:08 jonathan Gives 1
21:08 jonathan oh, wait, that's the problem
21:08 jonathan duh!
21:08 moritz yes
21:08 jonathan sub bar { return }; say bar().WHAT # list
21:08 jonathan Heh.
21:09 pmichaud isn't that correct?
21:09 jonathan Perhaps.
21:09 jonathan But an empty list is defined, right?
21:09 pmichaud yes, it is.
21:10 jonathan So defined(bar()) is thus 1?
21:10 pmichaud I'm thinkin gyes.
21:10 jonathan Which would make sense given the sub was successful.
21:10 pmichaud say bar();     evaluates the result of bar() in list context
21:10 pmichaud i.e., bar() returns an empty capture, which becomes an empty list when taken in list context
21:10 pmichaud which is defined
21:10 jonathan of coruse, if bar() { say 42 } # prints nothing
21:11 jonathan But truth is differnet from definedness.
21:11 pmichaud right, becaue an empty list evaluates to false
21:11 jonathan If you explicitly return undef, then of course: sub bar { return undef }; say defined(bar()) # 0
21:11 jonathan OK, so the ticket is wrong?
21:11 jonathan http://rt.perl.org/rt3/Tic​ket/Display.html?id=58770
21:11 * moritz is quite sure he saw that in the specs, but can't find it now
21:12 pmichaud there is the possibility that   defined(bar())  should be evaluating bar() in item context
21:12 pmichaud and that the empty capture in item context should return Failure
21:12 pmichaud or Object
21:12 pmichaud and therefore should be false
21:12 * jonathan wonders if the spec says that anywhere
21:12 pmichaud I suspect that's the case
21:13 pmichaud I don't think it's in the spec yet, I think that's just from TimToady musings
21:13 jonathan OK
21:13 jonathan Maybe wait until he muses it into the spec... :-)
21:13 pmichaud I think the ticket is valid.
21:13 jonathan OK
21:25 japhb joined #parrot
21:28 * jonathan notices a bug in Object.pmc and wonders how we survived so long with it
21:30 jonathan Or...hmm.
21:34 Khisanth it inherits from cockroach? :)
21:35 jonathan :P
21:36 cotto_work DietCoke, ping
21:37 jonathan Looks almost like things were re-written to work differently, and a chunk of code that did things the original way were left hanging around, and didn't actually do anything by accident.
21:48 pmichaud bring out yer dead (code)!   bring out yer dead (code)!
21:53 cotto_work you almost made me lose my drink
21:53 pmichaud "twas a woman that drove me to drink, and I never got to thank her for it."
21:59 davidfetter joined #parrot
22:00 Tene Hmm.  I need to show this little PIr segfault example to chromatic.
22:00 Tene Anyone want to post it to a ticket for me?
22:01 moritz he'll be delighted ;)
22:01 cotto_work 'segfault'()
22:01 Tene moritz can do it!
22:01 Tene http://nopaste.snit.ch/14025
22:02 * moritz knows next to nothing about PIR
22:02 Tene moritz: you know how to post tickets and cc chromatic, though.
22:02 PerlJam Tene: sounds like you need to learn  :)
22:02 particle i suspect he's email-inoperable atm
22:03 moritz ok, I can do it
22:03 Tene Kinda.  Email-inconvenient.  I'm trying to concentrate on $job.
22:03 Tene And historically, I forget about these tasks pretty quickly.
22:03 PerlJam Tene: yeah, me too.
22:05 moritz bug report sent
22:05 PerlJam too bad you can't just DCC it to a bot and have the bot proxypost it for you
22:05 Tene Hmm.  I could write a shell script to do it, actually...
22:06 Tene I should do that.  That's a great idea.
22:06 Tene PerlJam++
22:06 moritz I already thought about an IRC bot that pastes evalbot's output into a stub ticket
22:06 Tene It would be pretty simple to make polyglotpot do that.
22:06 Tene It can already nopaste.
22:07 Tene perl6.pir: say "lol hi"
22:07 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 pir" (39 lines) at http://nopaste.snit.ch/14026
22:07 moritz Tene: RT #58772 it is
22:08 Tene perl6.paste: say "spamming the nopaste"
22:08 nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 paste" (1 line) at http://nopaste.snit.ch/14027
22:09 moritz that nopaste feature would be quite useful for evalbot+STD.pm, because the parse tree never fits into IRC
22:11 Tene It uses tools/dev/nopaste.pl in the parrot tree
22:11 cotto_work that's a very long backtrace
22:11 Tene You could jam in support for STD.pm into polyglotbot.
22:12 dalek r31005 | jonathan++ | trunk:
22:12 dalek : [rakudo] Fix to new in Perl6Object so we don't blow away PMC instances for PMCs we are inheriting from.
22:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31005
22:12 moritz Tene: the problem with STD.pm is more the environment, not the code to run it
22:13 Tene ah
22:14 moritz but I could integrate nopaste.pl into p6eval
22:24 cotto_work ctx == ctx->caller_ctx == ctx->caller_ctx->caller_ctx ...
22:29 jonathan Reccursion?
22:30 cotto_work yes, in mark_context.  I suspect that chromatic will have to figure out why, though.
22:31 cotto_work I'm looking at that bug Tene nopasted earlier.
22:31 jonathan Well, it comes up naturally if the program is _meant_ to recurse.
22:31 jonathan Ah.
22:32 cotto_work It shouldn't be infinitely recursive, though. ;)
22:34 jonathan No.
22:34 jonathan Which was the nopaste you were looking at?
22:34 cotto_work http://nopaste.snit.ch/14025
22:34 * jonathan can't find it amongst the many in the backscroll
22:36 cotto_work Unfortunately it's more fun to try chasing that down that work on what I'm supposed to be working on.
22:37 pmichaud ...that doesn't sound unfortunate to me :-)
22:38 dalek r31006 | jonathan++ | trunk:
22:38 dalek : [rakudo] Clear namespace after we leave one, so later rules don't get attached to earlier grammars.
22:38 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=31006
22:39 jonathan Woo! Down to 150 tickets!
22:39 pmichaud jonathan: I think that the namespaces should be an array
22:39 jonathan Sure, when we do nested stuff.
22:39 Whiteknight what's down to 150 tickets?
22:39 pmichaud and we should "pop" to the outer namespace
22:39 jonathan Yup.
22:39 pmichaud okay.
22:39 jonathan But I think many other things get in the way of nested classes/grammars etc yet.
22:40 jonathan Whoever of us gets lucky enough to the package/symbol to match with what STD.pm is doing can have that fun when they reach it. :-)
22:40 cotto_work Whiteknight, looks like perl6 new+open+stalled
22:40 * jonathan is going on holiday soon ;-)
22:40 jonathan Whiteknight: what cotto_work said - the Rakudo queue
22:41 pmichaud moritz: (unicode in comments) -- what comments are causing rakudo to not parse?
22:41 pmichaud oh, nm, I think I found it
22:42 jonathan pmichaud: I have one uncommited chunk of code left from today, for =<>
22:42 jonathan But it doesn't actually work because of the parser issues.
22:42 jonathan Want me to check it in anyway?
22:42 pmichaud oh yes, I was going to explain that earlier but got caught on the phone
22:42 pmichaud in theory, using term:=<>   should work even in the present parser
22:43 pmichaud the reason why term:->  can't work yet for pointy blocks is that we have to parse more than just the pointy block
22:43 pmichaud sorry, more than just the pointy
22:43 pmichaud (we have to grab the block as well)
22:44 pmichaud ideally I'd be able to write    term:« !!! » is parsed(&foo) { ... }   and then let a 'foo' rule or token do the actual parsing
22:45 pmichaud unfortunately, the operator precedence parser eats the !!! prior to calling the parsing rule (because that's what audrey and TimToady told me to change it to a couple of years ago)
22:45 pmichaud for the term tokens that simply need to eat the symbol itself, such as !!!, ???, and =<>, we might be able to get those to work
22:46 pmichaud for the pointy block to parse as a term, I have to go back and undo the change that causes the token to be eaten prior to calling the "is parsed" rule
22:46 pmichaud unfortunately, that breaks everything that currently uses is parsed on non-empty term: , which include quite a few things in PGE itself
22:47 pmichaud so, it's a bit of a refactor to fix.  It's one I have to fix, and that is scheduled to occur in the first couple of weeks of my next grant (which should start this weekend)
22:47 pmichaud but it's non-trivial.
22:48 pmichaud once I have the fix that doesn't eat the token as part of the parsing, then the pointy block term becomes    token term:« -> » is parsed(&pblock) { ... }     and everything should "just work"
22:48 pmichaud and the others become    token term:<!!!> { ... }
22:48 pmichaud and all of that can occur before we have the "official" LTM algorithms in place
22:48 pmichaud anyway, I have to run now -- back tomorrow.
22:48 jonathan Question on workaround for now. Since when we called something with is parsed, we know what we're calling and thus in turn know what we parsed beforehand...
22:49 pmichaud we don't know what was parsed beforehand, in the case of pblock
22:49 pmichaud because pblock expects to find a '->'
22:49 jonathan ...can we not just call something for pointy block that says "OK, I know you swallowed a ->, and now match..."
22:49 pmichaud we could workaround it that way, yes, but I prefer not to.
22:49 jonathan Oh, sure, but we can have a copy of the rule, pblock_hack, that doesn't look to parse the -> because it was already parsed.
22:50 mberends joined #parrot
22:50 pmichaud I'd rather fix the term: rule, which has to happen anyway.
22:50 pmichaud I have to run to kid soccer practice now
22:50 pmichaud bbl
22:50 jonathan OK, I will sleep soon too
22:50 jonathan So, tomorrow. cu :-)
22:53 cotto_work hmmm.  The fix might be trivial.  It'll be interesting to see if chromatic comes up with the same thing.
22:54 bacek joined #parrot
22:55 * jonathan waves at bacek
22:55 jonathan Think I fixed a couple of tickets you filed today. :-)
23:01 s1n pmichaud: when you get back, i've gotta grill you about something
23:09 tetragon joined #parrot
23:10 kid51 joined #parrot
23:14 cotto_work my "fix" still seems to DTWT
23:27 wknight8111 joined #parrot
23:30 cjfields joined #parrot
23:31 cjfields jonathan++ # for RT 58678 fix
23:32 wknight8111 If I absolutely have to buy a book, a good technical one, does anybody have any recommendations?
23:32 wknight8111 I am to books what my Fiancee is to shoes
23:33 particle i hope you have "the pragmatic programmer"
23:33 particle if not, you must
23:33 Hinrik you have the Camel book, I presume
23:34 * particle no longer has the camel :(
23:34 particle it's been stolen/lost/"permanently loaned"
23:34 * PerlJam hasn't had a Camel since they were pink
23:34 particle but i have safari via acm
23:35 particle of course, they have 3rd edition of camel, not 5th
23:35 Limbic_Region joined #parrot
23:35 wknight8111 I've practically got the whole O'Reilly catalog :)
23:35 wknight8111 I don't have the pragmatic programmer, no
23:35 * wknight8111 toodles off to amazon
23:35 particle get it. NOW.
23:35 cjfields Anyone have an idea where to place grammar tests for Rakudo?  Couldn't find anything in t/spec.
23:36 wknight8111 65 new and used from 18.99$!
23:36 particle t/spec/S05-grammar/foo.t
23:36 cotto_work buying books is much easier than reading them
23:36 particle code complete is a good book, too
23:37 particle steve mcconnell, microsoft press
23:37 particle some number of c's, n's, and l's
23:38 wknight8111 I've got Code Complete
23:38 * wknight8111 is very proud of his library
23:38 Ademan joined #parrot
23:38 particle have the set from knuth?
23:39 wknight8111 in hardcover
23:39 * jonathan used to buy lots of books, then realized he hardly ever read them, so kinda stopped
23:39 Debolaz joined #parrot
23:39 wknight8111 I reference them all the time
23:39 particle i stopped buying perl books after i met the authors. bums, all of them.
23:39 wknight8111 probably more then I should
23:40 cotto_work I was quite surprised to find out that Allison edited Programming PHP
23:40 wknight8111 She's an editor at O'Reilly, isn't she?
23:40 wknight8111 She probably doesn't make any money if she's snobby or picky
23:42 wknight8111 I would like to get a good book about VMs or programming languages or compilers, something in that area
23:42 wknight8111 but there are so few of them available
23:42 cjfields thx particle.  BTW, agree about 'Code Complete'.
23:44 Hinrik they should update Perl 6 & Parror Essentials
23:44 particle i still reference "numerical recipies in fortran 77" more than i'd like :)
23:44 Hinrik that's a good book
23:44 particle wish i had the c version
23:44 particle hinrik: the source for the book is in the pugs and parrot repos
23:44 particle p6pe, that is
23:45 particle so feel free to update it :)
23:45 Hinrik oh, awesome
23:45 Debolaz Good books in general seems to be few and far between these days. Maybe I'm just being nostalgic though..
23:45 particle mjd's HOP is a fun book
23:45 Hinrik particle: I might actually take you up on that
23:45 Hinrik as soon as I figure out what's missing
23:45 cotto_work HOP++
23:45 particle hinrik: please do! we need the updates
23:46 Debolaz particle: It's probably the only perl related book I actually like.
23:47 * cjfields likes HOP as well
23:47 Hinrik I liked Mastering Algorithms with Perl
23:47 Hinrik http://blog.nix.is/perl-book-mini-reviews
23:49 kid51 cotto_work:  Do you have any update on http://rt.perl.org/rt3/Tic​ket/Display.html?id=43715 ?  Thanks.
23:49 cotto_work kid51, nope
23:50 particle ok, so what do i do first: parrot i18n? finish mod_parrot configure engine? perl 6 cmdline syntax?
23:50 Hinrik the first thing sounds most important
23:51 cjfields msg moritz I would like to add some spec tests for RT #58678, but this is blocking on further clarification on spec per RT#58676.  I'll check backlog for your response.
23:51 purl Message for moritz stored.
23:51 cjfields left #parrot
23:55 Debolaz "Structure & Interpretation of Computer Programs" is another book I like.
23:55 Debolaz Even though I don't like lisp. :-)
23:56 particle yes, and that's available free online from mit
23:56 Debolaz And in video format.

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced