Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
> >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 tha
Dave Storrs <[EMAIL PROTECTED]> writes:
>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
David Mitchell wrote:
>
> Roland Giersig <[EMAIL PROTECTED]> wrote:
>
> > Maybe:
> >
> > "Perl6 should excell at manipulating *formatted* text."
>
> Quite possibly, although as a previous poster has pointed out,
> formatted text != XML.
Yes, but both share a common underlying structure: they a
Roland Giersig <[EMAIL PROTECTED]> wrote:
> Maybe:
>
> "Perl6 should excell at manipulating *formatted* text."
Quite possibly, although as a previous poster has pointed out,
fotmatted text != XML.
ie in the sense that HTML, RTF, TeX etc, have a natural sense of containing
a single piece of te
Bart Lateur wrote:
>
> On Fri, 24 Nov 2000 08:54:43 +0100, Roland Giersig wrote:
>
> >Maybe the title should be :
> >
> >"Perl should use XML as its basic data type instead of linear strings"
>
> Horrible.
>
> I kinda liked your original proposal. But you should NOT focus on XML.
> That leaves
On Fri, 24 Nov 2000 08:54:43 +0100, Roland Giersig wrote:
>Maybe the title should be :
>
>"Perl should use XML as its basic data type instead of linear strings"
Horrible.
I kinda liked your original proposal. But you should NOT focus on XML.
That leaves out too many other possible data sources:
Nicholas Clark wrote:
>
> 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
It could be argued that the way to implement "enhanced" strings, eg
strings with embedded attributes (html, rtf,) is for someone
to write a specific SV class to deal with that kind of string.
As has been pointed out, a difficulty with this is that standard
regexes must be able to operate on th
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
At 05:04 PM 11/21/00 +, Nicholas Clark wrote:
>(I'm not sure if I've missed all the fun here before I subscribed, but
>I can't anything on the RFC list that mentions the following)
>
>perl5 has a tangle of SvPV macros to allow C code to get a pointer
>to the scalar. (or the "private", with or
On Tue, Nov 21, 2000 at 05:04:32PM +, Nicholas Clark wrote:
> (I'm not sure if I've missed all the fun here before I subscribed, but
> I can't anything on the RFC list that mentions the following)
>
> perl5 has a tangle of SvPV macros to allow C code to get a pointer
> to the scalar. (or the
24 matches
Mail list logo
