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
Dan Sugalski wrote:
>
> At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
> >Dan Sugalski wrote:
> > >
> > > It's also possible we'll do the parser mainly in C with perl hooks, but
> > > that's not the direction I've been pointed in.
> >
> >Write it entirely in perl, but have native C implementations
> "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
At 03:35 PM 11/22/00 +, raptor wrote:
>hi,
>
>I don't know very much about internals or about how the parser works in
>reality but something like this can be helpfull I think !! What I have in
>mind ? Micro-perl-parser may be this is external interface (written in
>perl).
>
>
>rule:do {
>/
At 12:11 PM 11/22/00 -0800, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> > You're not wrong, but I don't think this is a huge problem. Lots of systems
> > do it like this at the moment--GCC comes to mind as a first one, but there
> > are lots of others. Granted it does mean that we'll need to ship
At 08:51 PM 11/21/00 -0500, Sam Tregar wrote:
>On Wed, 22 Nov 2000, Nicholas Clark wrote:
>
> > Are we hoping that we can mmap() most scripts, so read isn't hugely a
> > problem? And slrp the rest in one? [doesn't feel good]
> > Are we going to have "lazy scalars" which collude with the rege
At 09:06 AM 11/22/00 +, David Grove wrote:
>Anyway, I'm trying to fit the definitions Dan offered yesterday with what
>has been said so far. Not everything seems to fit. One obvious question is
>that "the functions that are presented to the world" refers to functions
>like SvPV() (C language)
Dan Sugalski wrote:
>
> You're not wrong, but I don't think this is a huge problem. Lots of systems
> do it like this at the moment--GCC comes to mind as a first one, but there
> are lots of others. Granted it does mean that we'll need to ship a
> bytecode-compiled version of the parser as part o
Bart Lateur wrote:
>
> On Tue, 21 Nov 2000 17:24:49 +, Simon Cozens wrote:
>
> >I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles,
> >Techniques and Tools".
>
> AKA "The Dragon Book". You're not the only one to mention this book on
> this list.
>
> IMO, this book is rea
On Wed, Nov 22, 2000 at 08:51:08PM +0100, Bart Lateur wrote:
> On Wed, 22 Nov 2000 14:15:57 -0500, Dan Sugalski wrote:
>
> >>We bootstrap on perl5 to get a bytecode stream, and then that bytecode
> >>stream had better stay supported.
> >
> >Yup. It's one way to ensure backwards compatibility... :
On Wed, 22 Nov 2000 14:15:57 -0500, Dan Sugalski wrote:
>>We bootstrap on perl5 to get a bytecode stream, and then that bytecode
>>stream had better stay supported.
>
>Yup. It's one way to ensure backwards compatibility... :)
I assume a byte is still 8 bits? So you have a max of 256 different (1
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 07:36 AM 11/21/00 -0500, David Grove wrote:
>> However, one thing is seriously lacking in this theory... if the parser is
>> perl, how does the perl parse? (Sort of a woodchuck chucking wood type of
>> thing.) Somehow, the external par
At 01:50 PM 11/22/00 -0500, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> At 07:36 AM 11/21/00 -0500, David Grove wrote:
> >> However, one thing is seriously lacking in this theory... if the parser is
> >> perl, how does the perl parse? (Sort of a woodchuck c
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
"Rocco Caputo" <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Nov 2000 12:45:50 +0100, Bart Lateur wrote:
> >
> >AKA "The Dragon Book". You're not the only one to mention this book on
> >this list.
> >
> >IMO, this book is really thick to crawl through, and in the end, it's
> >all just theory, y
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
hi,
I don't know very much about internals or about how the parser works in
reality but something like this can be helpfull I think !! What I have in
mind ? Micro-perl-parser may be this is external interface (written in
perl).
rule:do {
/do/ and "{" call(token) and "}" and action
}
rule:t
On Wed, Nov 22, 2000 at 12:45:50PM +0100, Bart Lateur wrote:
> Heh. In short: are there
> any more *practical* "how do I build my own compiler" books, that people
> can wholeheartedly recommend?
"Modern Compiler Design in C" (or "... in ML" if you so desire) by Appel.
Bit weird in places - excel
On Tue, 21 Nov 2000 17:24:49 +, Simon Cozens wrote:
>I really *would* recommend Aho, Sethi, Ullman, "Compilers: Principles,
>Techniques and Tools".
AKA "The Dragon Book". You're not the only one to mention this book on
this list.
IMO, this book is really thick to crawl through, and in the e
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:45 PM 11/21/00 +, Tom Hughes wrote:
>
> >Given that it isn't a valid C identifier, yes... Unless you're
> >using VAXC or DECC of course, which was your point I assume ;-)
>
> Odd. The Dec C docs don't men
30 matches
Mail list logo
