Dan Sugalski <[EMAIL PROTECTED]> writes:
> More often vice versa. INN embeds perl, for example, and uses it for
> spam detection. When it builds scalars for perl to use, it uses the copy
> of the article already in memory to avoid copies. (Given the volume of
> news and the size of some news arti
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> Have I misunderstood you if I suggest that "two or more" is actually a
NC> continuous range of representation from
NC> 1 (contiguous linear) string data with 0 or more attribute attached to each
NC> character where the string's text
On Wed, Nov 22, 2000 at 01:24:50PM -0500, Chaim Frenkel wrote:
> I'd offer the possiblity that there are two (or perhaps more)
> different problems here. One is the current bunch of bytes (string,
> executable to be twiddled) Another which the attribute on strings
> seems to be structured data.
>
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> 2) An attached table of attributes and ranges to which they apply?
>> Uses less memory for sparse attributes, but means that it's hard work
>> every time we have to interrogate or shuffle characters as we need to
>> check all the rang
On Wed, Nov 22, 2000 at 12:29:55PM -0500, Dan Sugalski wrote:
> At 09:17 AM 11/22/00 -0800, Dave Storrs wrote:
>
>
> >On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
> >
> > > Yet another bummer of the current SVs is that they poorly fit into
> > > 'foreign memory' situations where the buffer is m
Nicholas Clark <[EMAIL PROTECTED]> writes:
> How does the regexp replacement engine cope with this? By implementing
> all replacements as substr() type ops?
> [or behaving as if it implements... whilst cheating and doing it direct for
> scalars it understands?]
>
> Or don't we need to work this
At 09:17 AM 11/22/00 -0800, Dave Storrs wrote:
>On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
>
> > Yet another bummer of the current SVs is that they poorly fit into
> > 'foreign memory' situations where the buffer is managed by something
> > else than Perl. "No, thank you, Perl, keep your gre
At 05:07 PM 11/22/00 +, Nicholas Clark wrote:
>On Wed, Nov 22, 2000 at 11:02:16AM -0600, Jarkko Hietaniemi wrote:
> Dan:
> > > This strikes me as an excellent candidate for a custom scalar type. I
> like
> > > the idea, and it could be really useful in some circumstances, but
> I'd not
> >
On Tue, 21 Nov 2000, Jarkko Hietaniemi wrote:
> Yet another bummer of the current SVs is that they poorly fit into
> 'foreign memory' situations where the buffer is managed by something
> else than Perl. "No, thank you, Perl, keep your greedy fingers off
> this chunk. No, you may not play wit
On Wed, Nov 22, 2000 at 11:02:16AM -0600, Jarkko Hietaniemi wrote:
Dan:
> > This strikes me as an excellent candidate for a custom scalar type. I like
> > the idea, and it could be really useful in some circumstances, but I'd not
> > want to burden the default scalar with the code for this.
>
> >I believe this alternative has been discussed once in a while. Which
> >ranges an operation affects is a log(N) operation on the character
> >position (binary search), and the ranges can also be kept sorted among
> >themselves on (primary key start position, secondary key end
> >position), so
At 10:45 AM 11/22/00 -0600, Jarkko Hietaniemi wrote:
> > 2) An attached table of attributes and ranges to which they apply?
> >Uses less memory for sparse attributes, but means that it's hard work
> >every time we have to interrogate or shuffle characters as we need to
> >check all the
> 2) An attached table of attributes and ranges to which they apply?
>Uses less memory for sparse attributes, but means that it's hard work
>every time we have to interrogate or shuffle characters as we need to
>check all the ranges each time to see if the characters we are
>manipu
On Wed, Nov 22, 2000 at 02:57:09PM +0100, Roland Giersig wrote:
> I posted a RFC for something like that a while ago but got no reaction
> from the crowd. It is not an internal optimisation like the one
I don't think that there's a crowd here.
> Take this HTML for example:
>
> Text with a
Nicholas Clark wrote:
> IIRC Ilya mailed p5p bemoaning the fact that perl's SVs use a continuous
> buffer. A split-buffer representation (where a hole is allowed in the
> middle of the buffer data) permits much faster replacement type operations,
> as there is less copying, and you can move the h
15 matches
Mail list logo
