Hi,
It could be useful to have a way to know the exact memory footprint of any
PMC.
For instance, suppose that each PMC must override/implement a method
get_allocated_size(), it could be used to
optimize programs that takes too much memory, or to debug/optimize PMC
implementation.
That method cou
Hi,
Is there a way to specify a minimum allocation size for PMCs like strings or
arrays ?
Something like in perl : %h = 1000 ?
It could boost execution times when you have a good idea of the space you
need.
For example, I'd like to do:
#ensure that the array has enough allocated storage for 100
On Oct 17, 2006, at 4:25 PM, Jerry Gay via RT wrote:
On Tue Oct 17 07:33:02 2006, [EMAIL PROTECTED] wrote:
Well, the verdict defnitely seems to be that trailing space and tab
characters are annoyances that should go away :-) This patch adds a
new test (in place of the curly-space test I poste
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> > I view lines as a valuable resource. I like to fit whole functions on
> > the screen when possible so I'm more of a fan of
If you are out of lines:
$ perl -e'++$lines for 1..1000'
helps for some time, then pleae restart.
> > if (foo) b
Please, let's go with whatever's written in the PDD.
Coding standards discussions = much heat, little light.
I'm sorry I responded to anything in this thread in the first place.
Please.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Am Dienstag, 17. Oktober 2006 23:19 schrieb Kevin Tew:
> if ( foo )
> bar();
> else
> bat();
> if ( foo )
no spaces in the parens. No example in pdd07 is looking like this. There where
some ident rules in that pdd some time ago regarding that.
Above vs.:
if (foo) {
bar();
}
else {
Kevin Tew wrote:
> 1) *s should go right next to the type in function declarations and
> definitions
>
> /* incorrect */
> do_thaw(Parrot_Interp interpreter, PMC * pmc, visit_info *info)
> /* correct */
> do_thaw(Parrot_Interp interpreter, PMC* pmc, visit_info* info)
Disagree. Consider:
char* fo
Am Dienstag, 17. Oktober 2006 22:33 schrieb Kevin Tew:
> While exploring Parrot internals I started cleaning up some code.
> I'll post patches to the list, but here are some things that are not
> defined by the coding standards, but of which I'm a fan.
> So the question is are they acceptable in th
Kevin Tew wrote:
Jerry thanks for finding the reference in pdd07.
Note I'm not trying to start a preference war here, I would just like
Chip to rule on some things that are not in the coding spec yet.
Thanks,
Kevin
Prvious mail should have read:
if ( foo )
bar();
else
bat();
I cant find
I cant find it in the spec pdd07 but I though Chip said no curlies on
single statements bodies of ifs
if ( foo )
bar();
else
bat();
I view lines as a valuable resource. I like to fit whole functions on
the screen when possible so I'm more of a fan of
if (foo) bar();
else bat();
Cu
On Tuesday 17 October 2006 14:01, Andy Lester wrote:
> On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
> >if (!info->thaw_result) info->thaw_result = pmc;
> >else *info->thaw_ptr = pmc;
>
> No, definitely not.
>
> if ( foo ) {
> bar();
> }
> else {
>
On 10/17/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
>if (!info->thaw_result) info->thaw_result = pmc;
>else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
if
On Oct 17, 2006, at 3:33 PM, Kevin Tew wrote:
if (!info->thaw_result) info->thaw_result = pmc;
else *info->thaw_ptr = pmc;
No, definitely not.
if ( foo ) {
bar();
}
else {
bat();
}
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:
On 10/17/06, Kevin Tew <[EMAIL PROTECTED]> wrote:
1) *s should go right next to the type in function declarations and
definitions
I disagree; they should go right next to the name being declared,
since C declarations are designed to reflect the way the declared item
is later used: PMC *pmc, vi
While exploring Parrot internals I started cleaning up some code.
I'll post patches to the list, but here are some things that are not
defined by the coding standards, but of which I'm a fan.
So the question is are they acceptable in the parrot code base.
1) *s should go right next to the type
On Tue Oct 17 07:33:02 2006, [EMAIL PROTECTED] wrote:
> Well, the verdict defnitely seems to be that trailing space and tab
> characters are annoyances that should go away :-) This patch adds a
> new test (in place of the curly-space test I posted earlier) which
> searches for superfluous trailing
looks like a valid problem, and a valid solution... commit away!
~jerry
On 10/17/06, Kevin Tew <[EMAIL PROTECTED]> wrote:
Used Cwd::abs_path like FindBin in perl 5.8.6 does.
defaults.pm |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: config/init/defaults.pm
=
Used Cwd::abs_path like FindBin in perl 5.8.6 does.
defaults.pm |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: config/init/defaults.pm
===
--- config/init/defaults.pm (revision 14936)
+++ config/init/defaults
Am Dienstag, 17. Oktober 2006 10:47 schrieb François PERRAD:
> Now, Lua doesn't depend of the deprecated Coroutine PMC.
Coroutine PMC isn't deprecated, it's limited in its functionality.
leo
# New Ticket Created by Kevin Tew
# Please include the string: [perl #40559]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40559 >
defaults.pm |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Fixes this probl
Well, the verdict defnitely seems to be that trailing space and tab
characters are annoyances that should go away :-) This patch adds a
new test (in place of the curly-space test I posted earlier) which
searches for superfluous trailing spaces in source files.
Comments definitely welcome!
Regar
At 13:48 14/10/2006 -0400, Bob Rogers wrote:
So while we could redesign Coroutine.pmc now, I don't think we are
ready to reimplement it. In the mean time, having an alternative
implementation allows those who want a full implementation (hi,
Fran,Ag(Bois!) to get on with it.
I've removed th
22 matches
Mail list logo
