On Tue, 11 Nov 2003, Michael Carman wrote:
> old format 2192 kB
> new format (default)326 kB
> new format w/ -option=pod,data 391 kB
> new format w/ -option=unified 340 kB
> new format w/ -option=pod,data,unifi
When I compile with Electric Fence (linux Athlon XP)
I get a floating point exception on startup.
The stack trace:
#0 0x0811f2e2 in add_pmc_ext (interpreter=0x400a3cc0, pmc=0x405a7018) at
src/headers.c:185
185 PObj_is_PMC_EXT_SET(pmc);
(gdb) back
#0 0x0811f2e2 in add_pmc_ext (interprete
I agree with Leo.
What good are param counts for the different return types anyway?
How can you tell the difference between a function returning
(int, int, string, PMC, string, float, string, PMC)
and a function returning
(string, int, int, PMC, string, float, PMC, string)?
Both will have the s
Mark A. Biggar wrote:
0x (Unicode as code-points up to 0x10FFF), as either two 16 bit
Oops that should be 0x10^^^
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Nicholas Clark wrote:
On Wed, Nov 12, 2003 at 01:57:14PM -0500, Dan Sugalski wrote:
You're going to run into problems no matter what you do, and as
transcoding could happen with each comparison arguably you need to make a
local copy of the string for each comparison, as otherwise you run the
ris
On Wed, Nov 12, 2003 at 11:35:41PM +0200, Peter Gibbs wrote:
> I would prefer this to be done via an iterator, as it would also solve
> the skip_backward problems with DBCS encoding. Something like:
> For the hash_utf8 benchmark with the current code I get numbers like:
> 3.758691
> 5.535916
Leopold Toetsch wrote:
> To improve this (and some other operations like this) further, it
would
> be nice, if we could combine encoding->decode and
encoding->skip_forward
> to another function:
>
>INTVAL code = s->encoding->decode_skip_forward_1( &sptr );
I would prefer this to be done via a
On Wed, Nov 12, 2003 at 01:57:14PM -0500, Dan Sugalski wrote:
> You're going to run into problems no matter what you do, and as
> transcoding could happen with each comparison arguably you need to make a
> local copy of the string for each comparison, as otherwise you run the
> risk of significant
On Wed, 12 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> > On Wed, 12 Nov 2003, Steve Fink wrote:
> >>... ($x eq $y) ... couldn't this be
> >>done as another string vtable entry instead of being specific to
> >>hash_compare?
> >>
> >
> > Yeah, that'd be a better way to do it. Add a st
On Wed, 12 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> [ I,N,S counts ]
>
> > 6) Note that non-PMC counts only need to be filled in if we're marked
> > "prototyped"
>
> Again, this is IMHO unneeded or at least suboptimal. The caller has 3
> more instructions. And
On Wed, 12 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > The reason to have them is compile-time uncertainty about call and return
> > types. Since we can't safely know with certainty what the definition of a
> > sub or method is, we need to pass into the sub/met
Dan Sugalski wrote:
On Wed, 12 Nov 2003, Steve Fink wrote:
... ($x eq $y) ... couldn't this be
done as another string vtable entry instead of being specific to
hash_compare?
Yeah, that'd be a better way to do it. Add a string_equal function to
string.c and do the magic there instead.
Good point. I
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ I,N,S counts ]
> 6) Note that non-PMC counts only need to be filled in if we're marked
> "prototyped"
Again, this is IMHO unneeded or at least suboptimal. The caller has 3
more instructions. And what should the assembler generate for the
callee?
if I
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The reason to have them is compile-time uncertainty about call and return
> types. Since we can't safely know with certainty what the definition of a
> sub or method is, we need to pass into the sub/method a notation of what
> parameters its getting. Other
On Wed, 12 Nov 2003, Steve Fink wrote:
> On Nov-12, Leopold Toetsch wrote:
> > I've committed a change that speeds up hash_compare considerably[1],
> > when comparing hashes with mixed e.g. ascii and utf8 encodings.
>
> I read the patch, and thought that we'll also have a lot of ($x eq $y)
> and (
On Nov-12, Leopold Toetsch wrote:
> I've committed a change that speeds up hash_compare considerably[1],
> when comparing hashes with mixed e.g. ascii and utf8 encodings.
I read the patch, and thought that we'll also have a lot of ($x eq $y)
and ($x ne $y) statements that this won't accelerate --
'Kay, here's the proposed changes:
1) Return conventions die. Chopped entirely out of the list
2) The hash for the sub/method name goes, though we may later regret that.
3) The return type info that was in I3 is gone. It's really "calling
context" and I think we may need a better way for things in
On Mon, 10 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> > Anyway, time to unify. The question, then, is what gets kept and what gets
> > tossed. The return spec says we pass in the number of P, I, S, and N
> > params we're returning, which is fine,
>
> I don't think we need these cou
I've committed a change that speeds up hash_compare considerably[1],
when comparing hashes with mixed e.g. ascii and utf8 encodings.
To improve this (and some other operations like this) further, it would
be nice, if we could combine encoding->decode and encoding->skip_forward
to another functi
On Tue, Nov 11, 2003 at 10:53:58AM -0500, Dan Sugalski wrote:
>
> On Tue, 11 Nov 2003, Thies C. Arntzen wrote:
>
> > still working onm this php-compiler;-)
> > thanx for all the replies on my last issue..
> >
> > next question: calling conventions.
> > in the calling_convertion.po
20 matches
Mail list logo
