On Mon, 9 Apr 2001, Peter Scott wrote:
> At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote:
> >
> >One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go
> >the multiflagged way, why not reflect `-e' to get the `-6' flag? At
> >the very least, I want a short flag!
>
> But by the
On Thu, 12 Apr 2001, Dave Storrs wrote:
> We could then just add a -7 flag. That's not necessarily bad;
> Perl 7 will probably face the same issue...it needs to be able to eat Perl
> [567] code without barfing, but it needs to know what it's getting. Also,
> the flag would be a good cho
It does. I ran a test here earlier today on the cost of mis-aligned data
access, and I figured the results would be of interest to folks in general.
A few caveats--this test was run on a lightly loaded Compaq TurboLaser with
6 700MHz EV6 processors and 16G of memory. There was no swapping, and
At 10:48 PM 4/12/2001 +0100, Simon Cozens wrote:
>On Thu, Apr 12, 2001 at 05:39:12PM -0400, Dan Sugalski wrote:
> > [We have FOO:BAR]
> > While this is reasonably true (and reasonably reasonable) it's not
> entirely
> > to the point. If we're going to provide a mechanism to define the
> syntax o
On Thu, Apr 12, 2001 at 06:02:16PM -0400, Dan Sugalski wrote:
> D'oh! I was thinking more along the lines of:
>
>START(FORTH) {
> $baz $foo $bar + =
>}
>
> where the entire parser was coopted. I wasn't considering the smaller (and
> probably more common) case where only a tiny piec
David Whipp writes:
: You may be right that there are no useful literals other than
: strings, integers, reals and lists. OTOH, if we are going to
: construct a meta-language which supports multiple syntaxes,
: then it is very likely that each application-specific language
: would have its own lit
At 02:14 PM 4/12/2001 -0700, Larry Wall wrote:
>David Whipp writes:
>: You may be right that there are no useful literals other than
>: strings, integers, reals and lists. OTOH, if we are going to
>: construct a meta-language which supports multiple syntaxes,
>: then it is very likely that each ap
On Thu, Apr 12, 2001 at 05:39:12PM -0400, Dan Sugalski wrote:
> [We have FOO:BAR]
> While this is reasonably true (and reasonably reasonable) it's not entirely
> to the point. If we're going to provide a mechanism to define the syntax of
> a mini-language (or a maxi one, I suppose, though there
Dan Sugalski writes:
: If we're going to provide a mechanism to define the syntax of
: a mini-language (or a maxi one, I suppose, though there are probably better
: ways to do it) then the details of colons and constants and what-have-yous
: are pretty close to irrelevant.
I expect that most o
Dan Sugalski wrote on 4/11/01 13.38:
>At 03:09 PM 4/11/2001
>-0400, John Siracusa wrote:
>>On 4/11/01 10:55 AM, Dan
>Sugalski wrote:
>> > It does fix the link issues,
>though. perl6.so won't ever
>have an
>> > unqualified function in
>it--they'll all have either a
>Perl_ or _Perl_
>> > prefix on
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The only difference between the aligned and unaligned runs is the
DS> pointer to the aligned data is on an 8-byte boundary, and the
DS> unaligned data is the aligned pointer plus 1.
i am assuming this is an alpha (which i got to kn
[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in
<[EMAIL PROTECTED]>:
> (No, I don't know why unaligned access to 8-bit data is faster, but there
> you go)
How *do* you unalign 8-bit data?!
MfG Kai
[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in
<[EMAIL PROTECTED]>:
> *) All private routines have #defines to give them a _Perl_ prefix
> *) All private data have #defines to give them a _PL_ prefix
IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved
for the st
At 12:15 AM 4/13/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 12.04.01 in
><[EMAIL PROTECTED]>:
>
> > (No, I don't know why unaligned access to 8-bit data is faster, but there
> > you go)
>
>How *do* you unalign 8-bit data?!
(Must... resist... straight... line...
At 12:16 AM 4/13/2001 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 11.04.01 in
><[EMAIL PROTECTED]>:
>
> > *) All private routines have #defines to give them a _Perl_ prefix
> > *) All private data have #defines to give them a _PL_ prefix
>
>IIRC, ISO C says you cannot
>IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved
>for the standard.
If you consider our prefix is "_Perl_" not just "_", we will be pretty safe.
There are just not many people follow the standard anyway :-)
Hong
16 matches
Mail list logo
