|
Parrot 6.5.0 "Black-winged Lovebird" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 9 July 2014. |
|||
|
01:30
FROGGS_ joined
02:34
kid51_ joined
02:36
kid51__ joined
05:45
davidfetter joined
06:16
bighugedog joined
08:16
basiliscos joined
09:47
Psyche^ joined
10:19
Tene joined
11:02
kid51 joined
11:50
bighugedog joined
16:11
rurban1 joined
16:42
Chirag joined
|
|||
| Coke | looks like one more parrot test is aborting, have a few failures that need to be ticketed & fudged. | 17:07 | |
| er, rakudo-parrot | |||
| Chirag | rurban: If I am understanding the problem correctly, maybe we can check the type for the incoming "PMC *signature" at the beginning of the call itself and then maybe create type-specific "*call_object"s ?? | 17:19 | |
| rurban | which call? | 17:29 | |
| the call_obj is always a CallContext PMC | |||
| which holds various sig arrays (args and arg flags) | |||
| Chirag | yes it is always a PMC.. so to overcome boxing of signatures, we will detect the type carried by PMC *signature, right? | 17:35 | |
| and I mean do we try to stop using call_object altogether? and instead come up with independent logic for each type? | 17:37 | ||
| rurban | hmm, I'm not sure | 17:56 | |
| A union type as with Pcc_cell sounds good | 17:58 | ||
| Hmm, we already do that: ATTR struct Pcc_cell *positionals | 18:00 | ||
| Chirag | hmm.. so the methods that send PMC *call_object might need a change in definition to send a union-type? or we expand them in our call itself? | 18:02 | |
| rurban | we cannot touch the CallContext itself, we want to improve the sigs | 18:03 | |
| Chirag | ok.. so some sort of a patch-work, I guess | 18:05 | |
| rurban | mostly like inlining access to CallContext attrs | 18:15 | |
| getting rid of the autoboxing would be nice, yes | 18:16 | ||
| the call context already was prepared to hold arbitrary type (PSNI) args, which was thrown away to support a PMC array to hold it | 18:17 | ||
| until the 1.6 release or so | |||
| wknight8111.blogspot.com/2009/10/op...arrot.html | 18:18 | ||
| Chirag | I can look at that commit and try to get it back.. | ||
| rurban | it's not just a simple commit. It was whole refactoring. look for bacek and Context | 18:19 | |
| I'm looking now at the kill_pccinvoke branch | 18:20 | ||
| 863cfa471593f0342b45f1d973e9bfc49291c9b1 | 18:21 | ||
| e.g. e5dead2ed00fdcfc383ad82fe92c74636f8f2a45 changed the sig array to a PMC | 18:25 | ||
| tig src/inter_call.c is nice to use | |||
| Chirag | just finished going through the code... I guess all this work is now non-existent.. | 19:06 | |
| rurban1 | yep | 19:11 | |
| Chirag | the challenge/task will be to merge this into our current version | 19:13 | |
| Coke | what's the "unstable" note regarding for rakudo/parrot? | 19:50 | |
| ah, sounds like folks are on it. nevermind. | 19:51 | ||
| rurban1 | unstable? last month all the parrot spectest ran okay, this month not. it's getting closer though | ||
| rurban | updated wiki.enlightenedperl.org/gsoc2014/i...signatures a bit with the done work | 20:33 | |
| Coke | ah. that's mostly due to fudging issues in the suite now that we're trying to maintain 3 backends that all have varying states of todos. ideally, you should only have a particular failure for a day or so until someone can fudge the test properly for that backend. (but if you have something fudged on all, then unfudge it because it works in one place, but it fails on the other two, that will fail until someone fudges it just for the failing backend). | 20:34 | |
| it's kind of a | |||
| whoops. It's kind of annoying, but all we have to do to fix it is finish rakudo. :) | 20:35 | ||
| rurban | documented now all of the current ideas in the wiki | 20:45 | |
|
22:13
kid51 joined
23:00
basiliscos joined
23:58
khisanth__ joined
|
|||