pdcawley <[EMAIL PROTECTED]> writes:
> Bugger, I used L and pod2text broke it.
> http:[EMAIL PROTECTED]/msg10797.html
perlpodspec sez you can't use L<...|...> with a URL, and I'm guessing that
I just didn't look at that case when writing the parsing code in po
ieve was the decision already
made), is safe.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ning; unfortunately, one can't solve portability routines by
expressing one's opinion that the decisions various platforms made were
stupid. :)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
It's one of the few headers that
I've *never* seen wrapped in ifdef even in code meant to compile on
extremely strange systems.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Brent Dax <[EMAIL PROTECTED]> writes:
> Russ Allbery:
> # POSIX reserves all types ending in _t. I'm not sure that extends to
> # struct tags, but it may still be better to use _s or something else
> # instead to avoid potential problems.
> My understanding is that i
instead to avoid potential problems.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Bryan C Warnock <[EMAIL PROTECTED]> writes:
> On Monday 21 January 2002 16:43, Russ Allbery wrote:
>> Changing the capitalization of C does not change the word.
> Er, most of the time.
No, pretty much all of the time. There are differences between proper
nouns and commo
quot;half width letter" and "full width letter".
You'll find that the Unicode compatibility equivalence does nothing as
ill-conceived as unifying e and e', for very good reason because that
would be a horrible mistake.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Used for unused parameters to silence gcc warnings. */
#define UNUSED __attribute__((__unused__))
and then writing things like:
int
foo(int bar UNUSED)
actually serves to add additional documentation as well as shutting up
warnings.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ed, as I believe gcc 3.0 no longer warns on
system headers, so -Wredundant-decls possibly could get pulled back in.
-Wundef is a style thing.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ke a good idea.
IIRC, all types ending in _t are reserved by POSIX and may be used without
warning in later versions of the standard. (This comes up not
infrequently in some of the groups I read, but I unfortunately don't have
a copy of POSIX to check for myself and be sure.)
--
Russ Allbery
re this technique can
be used, and it's worth watching out for.
(In the case above, I'd probably instead define a sleep function on WIN32
that calls Sleep so that the platform differences are in a separate file,
but there are other examples of things like this that are better suited to
ition on the 5.6.1 alpha the other night... :) and
> it'll let us skip some of the more awkward bits of make.
I can certainly see the features of that approach. It just seems like
quite a lot of work.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Russ Allbery <[EMAIL PROTECTED]> writes:
> I'm not sure what there is to expand on. I've looked at 2.50, and it
> definitely doesn't look like an unmitigated evil hack to me. It looks
> like a collection of tests for various standard things that packages need
>
Robert Spier <[EMAIL PROTECTED]> writes:
> On Tue, 2001-10-23 at 20:52, Russ Allbery wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>> Once we build miniparrot, then *everything* can be done in
>>> perl. Having hacked auto* stuff, I think that'
e because they never need to look inside)
I've looked inside a lot, and I definitely do not agree. But maybe you've
not seen autoconf 2.50 and later?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
a lot to be said for not re-inventing the wheel. Taking a good
look at the facilities for dynamic loading provided by libtool before
rolling our own again may also be a good idea; it's designed to support
dynamically loadable modules.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
gt; no extra checking be performed.
Something akin to gcc's --enable-checking strikes me as a really good
idea.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
mory.o bytecode.o string.o strnative.o test_main.o
Definitely bugs in Configure there; cc has to be used as the linker or -lc
isn't added (and possibly some of the other crt.o files too), and
libraries have to be after all the object files.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes:
> * CVS Info
> * $RCSfile: $
> * $Revision: $
> * $Date: $
If you're going to include all that, why not just use $Id$, which contains
all of that information?
--
Russ Allbery ([EMAIL
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 01:05 PM 6/11/2001 -0700, Russ Allbery wrote:
>> Dan Sugalski <[EMAIL PROTECTED]> writes:
>>> Should perl's regexes and other character comparison bits have an
>>> option to consider different character
racter and get rid of most of the compatibility characters for you.
NFKC will go further and do stuff like getting rid of superscripts and the
like.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
capitalization indicates a proper noun). If there is some similar
distinction of meaning for numbers in some language, I suppose that
Unicode may add such a thing; to date, there doesn't appear to be any
concept of uppercase or lowercase for anything but letters.
--
Russ Allbery
e were lossless where possible.
The other advantage of looking at glibc's approach is that they get tons
of bug reports about obscure things and conventions for using particular
characters that aren't obvious from the specifications.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
David L Nicol <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> a caseless character wouldn't show up in either IsLower or IsUpper.
> maybe an IsCaseless is warrented -- or Is[Upper|Lower] could return
> UNKNOWN instead of TRUE|FALSE, if the extended boolean attr
Larry Wall <[EMAIL PROTECTED]> writes:
> Russ Allbery writes:
>> Particularly since extending UTF-8 to more than 31 bits requires
>> breaking some of the guarantees that UTF-8 makes, unless I'm missing
>> how you're encoding the first byte so as not to give
Russ Allbery <[EMAIL PROTECTED]> writes:
> That's probably unnecessary; I really don't expect them to ever use all
> 31 bytes that the IETF-standardized version of UTF-8 supports.
31 bits, rather. *sigh*
But given that, modulo some debate over CJKV, we're getting
worst of both worlds, and I
don't expect it to be used much now that they've buried the idea of
keeping Unicode to 16 bits.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ot a complete solution.
It seems to me that you haven't bothered to go look at what Unicode is
actually doing.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, Jun 05, 2001 at 03:27:03PM -0700, Russ Allbery wrote:
>> Caseless characters should be guaranteed unchanged by conversion to
>> upper or lower case, IMO.
> I think Bryan's asking more about \p{IsUpper} tha
ou leave
things fully decomposed, and in the other two you recompose characters as
much as possible.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 12:40 PM 6/5/2001 -0700, Russ Allbery wrote:
>> (As an aside, UTF-8 also is not an X-byte encoding; UTF-8 is a variable
>> byte encoding, with each character taking up anywhere from one to six
>> bytes in the encoded
Bart Lateur <[EMAIL PROTECTED]> writes:
> On 05 Jun 2001 11:07:11 -0700, Russ Allbery wrote:
>> Particularly since part of his contention is that 16 bits isn't enough,
>> and I think all the widely used national character sets are no more
>> than 16 bits,
xts; I'm guessing that none of the other
national character sets have ever bothered assigning code points to them
either.
Particularly since part of his contention is that 16 bits isn't enough,
and I think all the widely used national character sets are no more than
16 bits, aren
ther character sets for languages we don't need to use.
Am I missing something?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
lains
about things that are perfectly valid ANSI C and the best way of writing
some constructs. I don't believe that the list in the gcc info page of
what this turns on is actually comprehensive.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
file and will then automatically make those editors just Do The Right
Thing.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
f you follow
a standard text formatting style, it works reasonably well.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ould think of cases where you might
want to do in-place modifications without changing the allocation, but
that sounds a lot iffier.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
rogram would just fetch function pointers from us somehow, and
> do the call in.
Can't. ISO C requires that all variadic functions take at least one named
parameter. The best you can do is something like (void *, ...).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>>>>>> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
> RA> This will be completely impossible to implement in some installation
> RA> environments, such as AFS or read-only remote NFS mounts. I
avoiding printf constructs that make this too hard to do.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 04:36 PM 9/25/00 -0700, Russ Allbery wrote:
>> Yes. Most major free software packages already do this.
> Yeah, but from what I've seen none of them do it at all well. (Granted
> this is coming from someone barely functio
; I think there definitely should be
mechanisms available to do this if so wished.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
plement in some installation
environments, such as AFS or read-only remote NFS mounts. I really don't
like software that tries to play dynamic compilation tricks; please just
compile at installation time and then leave it alone.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
whole lot), and that's in a simple
> filtering email Local Delivery Agent. perl-based filtering programs
> don't blow procmail away because procmail weighs in at a teensy fraction
> of perl's pork, so there's a radical difference in sustainable email
> traffic levels.
Yup.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ye, wei <[EMAIL PROTECTED]> writes:
> Yes, I agree with you that Perl kernel is too big to embed into other
> program.
You do? I don't. INN has been embedding Perl for years, quite
successfully.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
#x27;t save much at all in the way of code size, but it
*would* mean that Perl would link against one fewer library on some
platforms, which is frequently a plus in load time.
Don't have time at the moment to write an RFC, so if someone else wants
to, be my guest
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ibc to this standard from 2.2 and up.
Perl *should* have a *much* easier task than glibc, given that our
interface is positively tiny compared to the entire C library.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Dan Sugalski <[EMAIL PROTECTED]> writes:
> On 29 Aug 2000, Russ Allbery wrote:
>> I'd love to see Perl aggressively take advantage of new capabilities in
>> dynamic loaders, though. Among other things, I'll point out that
>> symbol versioning is the w
fficult to implement stable API
for modules and the XS-equivalent.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ed library by itself except that it just
makes things infinitely more convenient).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
s true that increasing
the size of an executable will make it start slower or consume more
memory, and I expect that to become less true over time. And loading
dynamic libraries is actually fairly slow; static code loads faster
because it doesn't have to do the relocations and the addition
DP_PROTO)) {
warn "$0 (socket): $!\n"; close S; return undef;
}
should be done away with for good.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Tim Jenness <[EMAIL PROTECTED]> writes:
> On 14 Aug 2000, Russ Allbery wrote:
>> Day resolution is insufficient for most purposes in all the Perl
>> scripts I've worked on. I practically never need sub-second precision;
>> I almost always need precision be
ugh a different interface to
return something like TAI64NA or something, that would make sense to me.
What doesn't make sense to me is a change of epoch; I just don't see what
would be gained.
I must be very confused. I don't understand what we gain from MJD dates
at all, and
ething that works?
Is Perl currently using different epochs on different platforms? If so, I
can definitely see the wisdom in doing something about *that* and
off-loading the system-local time processing into modules (although I can
also see the wisdom in leaving well enough alone). But why n
represent times before 1970
just fine. The range problem is easily solved by making it a 64-bit
value, something that apparently we'd need to do with an MJD-based time
anyway. And everyone already knows how it works and often relies on the
base being consistent with their other applicatio
d narrow-minded
implementation that considers gcc the "best" compiler and mostly ignores
all the better ones out there for certain platforms. It will also help to
encourage *gcc* to become a better C compiler, rather than a better
compiler for some odd language that isn't quit
x27;s. It has a nice license; that's irrelevant
to porting Perl.
In short, while some of the ideas in this RFC have merit, I am absolutely
100% opposed to the grand implications and its tone and would consider
this approach to be disasterous for Perl.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ad seems to
be a technique that's growing in popularity among the commercial LISP
systems).
Please also note that he's criticizing the emacs GC about as much as he's
criticizing the Perl GC.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
hat, anything that a program wants to modify during
its normal course of operation and isn't a dotfile in the user's home
directory is inherently Evil and not to be tolerated if at all possible.
Bear in mind that site-wide Perl installations are going to be exported
read-only.
--
62 matches
Mail list logo
