Will Coleda schrieb:
On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
This module is written in Perl 5 and is called in a program written in
Perl 5. In the work I've done in this project, I've taken the approach
to return values which I think is more Perlish,
On Wednesday 16 July 2008 19:54:57 James Keenan via RT wrote:
> This module is written in Perl 5 and is called in a program written in
> Perl 5. In the work I've done in this project, I've taken the approach
> to return values which I think is more Perlish, namely, if a subroutine
> completes and
On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> This module is written in Perl 5 and is called in a program written in
> Perl 5. In the work I've done in this project, I've taken the approach
> to return values which I think is more Perlish, namely, if a subrouti
This module is written in Perl 5 and is called in a program written in
Perl 5. In the work I've done in this project, I've taken the approach
to return values which I think is more Perlish, namely, if a subroutine
completes and does what you wanted it to, it should return a true value.
A bare ret
On Wed Jul 16 19:25:46 2008, coke wrote:
>
> Attached is a patch which passes all tests by removing the tests for
> the explicit true value of these methods.
>
Coke: I don't think we should accept this patch, for the simple reason
that I think the changes made to lib/Parrot/Op
plicit return value that was originally present. (e.g. in
>> sort_ops in Parrot/Ops2pm/Utils.pm).
>
> IIRC, in the spring of 2007 my fellow Cage Cleaner went down this
> precise road, possibly with this very module. I.e., he added bare
> returns to subs that had quite well-define
On Wed Jul 16 18:53:05 2008, [EMAIL PROTECTED] wrote:
>
> So if you really think lib/Parrot/Ops2c/Utils.pm could be better
> designed while achieving the same functionality, have a go at it!
But in the short run I would recommend simply reverting to the last
prior version of the m
d, possibly with this very module. I.e., he added bare
returns to subs that had quite well-defined final statements. And he
got the same kind of test failures as we have here.
But when I refactored tools/build/ops2c.pl into
lib/Parrot/Ops2c/Utils.pm earlier that year, it was for the purpose of
refactor
768 Tests: 38 Failed: 3)
> Failed tests: 16-17, 36
> Non-zero exit status: 3
> t/tools/ops2pmutils/10-print_module(Wstat: 1024 Tests: 42 Failed: 4)
> Failed tests: 16-17, 34-35
> Non-zero exit status: 4
> t/tools/ops2pmutils/11-print_h (Wstat: 512 Tests: 23
Failed tests: 16-17, 34-35
Non-zero exit status: 4
t/tools/ops2pmutils/11-print_h (Wstat: 512 Tests: 23 Failed: 2)
Failed tests: 16-17
Non-zero exit status: 2
Files=38, Tests=1009, 24 wallclock secs ( 0.16 usr 0.05 sys + 12.72 cusr 0.77
csys = 13.70 CPU)
Result: FAIL
Fail
On Sat Jun 21 07:33:57 2008, [EMAIL PROTECTED] wrote:
> Mark: Do you have any objection to closing this RT?
No objection here, my needs regarding g++ builds have been satisfied.
Thanks!
Mark
Resolved per discussion with Infinoid.
Mark: Do you have any objection to closing this RT?
Thanks.
kid51
On Sun Apr 06 13:13:20 2008, infinoid wrote:
>
> * Honestly, I'm not really sure print_c_source_top and
> print_c_source_bottom need to be public methods any more. In fact, they
> could be merged into print_c_source_file entirely.
True, but ...
> But separating the
> filehandling from the pri
As per discussion on #parrot, the remaining TODO questions posed no
obstacle to merging the branch back into trunk. So I did so in r26830.
On Windows, make, make perl6, and make test all function in ops2c branch
with no more than the customary grumbling.
--
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
On Sun Apr 06 07:39:09 2008, [EMAIL PROTECTED] wrote:
> Following discussion on #parrot with Infinoid, I created the 'ops2c'
> branch in our SVN repository to handle refactoring of this area of the
> build system. You can follow developments there with:
>
> svn co ht
ub
> declaration, and another declaration at the end of the file with an
> initializer block.
>
> It seems appropriate to change the order of things output by ops2c, to
> avoid the redundant declaration. So I did so. Patch attached.
+1 here
-- c
Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system. You can follow developments there with:
svn co https://svn.perl.org/parrot/branches/ops2c
In that branch, I have applied Infino
Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system. You can follow developments there with:
svn co https://svn.perl.org/parrot/branches/ops2c
In that branch, I have applied Infino
Additional testing note. If you try out this patch, you will need to
remove src/ops/*.c before doing a "make". Otherwise ops2c won't be
re-run, and you won't actually be testing the patch.
Extra points for anyone who tests it on something other than gcc. :)
Mark
reports an error about "static op_lib_t core_op_lib" being
declared twice, and rightly so, because it is. There's an initial stub
declaration, and another declaration at the end of the file with an
initializer block.
It seems appropriate to change the order of things output by ops2c,
I'm trying to write some documentation for the ops2c system at the
moment and have a question.
In Parrot::OpsFile::read_ops() a Parrot::Op's type is set to 'inline'
or 'function', yet in Parrot::Op type is expected to be 'auto' or
'manual'.
Au
This patch removes a lot of code duplication:
- core_ops_cg.c is built by ops2c.pl now, making ops2cgc.pl obsolete
- core_ops_prederef.c doesn't have an op_info_table anymore, it was just
a duplication of core_ops.c
- this saves ~300K in sources and makes the interpreter smaller by ~10%
- all core
24 matches
Mail list logo
