> in regular expressions.
Just out of curiosity, and I'm not objecting to this RFC, has anyone
reading this mailing list actually intentionally used a vertical tab for
something related to its supposed purpose in the past ten years?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
avoiding printf constructs that make this too hard to do.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Ben Tilly <[EMAIL PROTECTED]> writes:
> I think that you actually can have trademarks on the same name in
> different areas as long as there is no possible confusion...
Correct, at least in the US.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
efficient since
that's most of what we do).
> And, if my being or not being a minority is something that would effect
> the value of my position, then you are even more dangerous than I had
> suspected.
Comments like this don't help the discussion any.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
your implication that people who don't
agree with you are saying that only European scripts matter. But please
don't escalate the argument as part of being offended.
I'll now stop replying to this thread. Sorry for sticking my nose in; it
really bugs me when this happens in i18n
that, or taking uuencode out of pack and putting it plus those
other things into a standard module.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
scenes), in a separate module that only
those programs that need to do UID fiddling need to load.
I guess the exception is getpwuid($<), which is probably done more than
any other operation on UIDs, but maybe just keep that single variable.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
mailing list and how to go about participating if the person
really wants to).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
do feel obligated to mention that the one free software project that
does use a private list for core development, namely CVS (at least at some
points in the past), I found highly annoying. But that was much more due
to the inability to read that list than the inability to post to it.
--
Rus
at I've heard, actually;
in fact, in some of them, you could do s/Alan Cox/Sarathy/ and get
basically the same rant, complete with the assurances that they consider
the actual tool of the Great Enemy to be a wonderful person.
I think this is par for the course in large, high-profile open source
software projects, regrettably.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ally good reason to learn Python.
> the TIL speedup over pure interpretation might win that back and
> more.
If that's true, that's a different ballgame of course.
If at all possible, Perl 6 should be *faster* than Perl 5. Perl is
already too slow IMO.
--
Russ Allb
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/>
f you follow
a standard text formatting style, it works reasonably well.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ople to talk about it will have absolutely no effect.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
urse (it's a large community), but the
FSF has a much clearer political goal. Perl doesn't really have as much
in the way of political goals.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
r earlier statement calling the positions of
the "GNU/Debian leaders" "fanatical." If you're attempting to be
persuasive, you may want to bear in mind that I'm pretty close to refusing
to read anything else you write on any topic, and it wouldn't sur
like upgrading libc, and this
particular upgrade, due to internal structural changes, is even more
complicated than that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
eing
arguably a subset of contract law, are to some degree based on common
rather than statutory law in the United States and in some other western
countries. That means that you can't necessarily figure out everything
you need to know about software licenses just by reading relevant law; the
hat this would require a
lot of work to do).
Sure, if people are aware of all of those issues and have decided that
their goals are more important to them than those drawbacks, more power to
them and they should be able to use whatever license they want.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
me at this policy?
<http://www.gnu.org/philosophy/license-list.html#PerlLicense>
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ings, and they
often don't line up with schedules very well.
I think you did quite a good job; I expect the issue to come back up again
when Larry's had a chance to look over the proposals and we'll have a few
more chances to clarify and talk it through.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ly annoying
distribution hassles like MIT used to have to do for Kerberos and which we
really don't want to get into.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ot the impression that this was one of the reasons why Larry never
bothered before with making the AL more lawyer-proof; since he intended it
to be used in conjuction with the GPL, it didn't need to be, since the GPL
was always there as a well-understood legal license if someone needed one
for s
aspect of the Perl language; I use that sort
of construct all over the place. We don't want to turn Perl into C, where
if you want to return anything non-trivial without allocation you have to
pass in somewhere to put it.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
So since when did perl6-language become perl-advocacy? Rephrased: Could
people please take the advocacy traffic elsewhere where it isn't noise?
Thanks.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
over-the-top whining that may have been intended to be funny and ended up
just being stupid and grating.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
nners in
> many case.
Without creating a function to extract the key, you can't sort in Perl at
all. sort { $a <=> $b } contains two functions to extract the keys.
Functions don't have to be complicated, you know.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
see a few YAPHs
with such properties, but I don't think we were guaranteeing that Perl 6
would be YAPH-compatible anyway.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>>> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:
> RA> Uri Guttman <[EMAIL PROTECTED]> writes:
> map { $_->[0] } sort { compare($a->[1], $b->[1]) } map { [$_, f($_)] } data
>
de. the supposed goal of this hypothetical builtin ST is to
> make it easier to use it. i say it is not worth the effort since you
> have to do almost as much work anyway.
Less mental effort is the important part, not how many characters have to
be typed. I don't want to be thinki
tched or subs inside the sort sub are called" then life
> becomes much easier.
I am strongly in favor of that approach. I see no reason to allow for
weird side effects in Perl 6. (Perl 5 would be a different matter, of
course.)
Not only is it simpler to deal with, it's simpler
so that Perl *can* usefully memoize, I can't think
of any realistic sort function where this would be a problem.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ute, is that such an
attribute will be fairly rarely used and that most of your gains will come
from managing to teach the compiler to figure out that information for
itself.
This will probably be harder in Perl than in C because C can afford to
take more time to do global optimization passes.
--
n* Yeah, that's the main thing that gets in the way
of optimizing C.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Doesn't have the right ring to it, unfortunately. It's not really
> immutable, it just has no side-effects.
gcc and the literature both use "pure"; I'd recommend that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ces and no side effects is "const" (a la C++). I think
"pure" was proposed for the somewhat relaxed version of that that allowed
memory references but not side effects.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
John Porter <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> It looks like I was misremembering; I remember a proposal for a "pure"
>> attribute in gcc, but it looks like the attribute used for functions
>> with no memory references and no side effec
't about what I
expected, so I didn't have much additional response, apart from saying
that that was rather more Perl 5 compatibility than I was expecting.
Interesting.
Oh, and I wholeheartedly approve of the approach to handling objects.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
get a copy of
> all these little gems from? :)
<ftp://ftp.cpan.org/CPAN/misc/lwall-quotes.txt.gz>
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
t so bad. People just kept
> their p4 binaries around for running those old scripts. No biggie.
There's quite a lot more Perl 5 code out there than there was Perl 4 code.
And it's rather annoying to still be maintaining a perl4 installation at
this point for the stragglers, althou
uper-long lines? Going to the shell syntax of:
PATH=/some/long:/bunch/of:/stuff
PATH="${PATH}:/more/stuff"
would really be a shame.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
C perspective if we're
turning objects into first-class entities rather than pointers; think
about a struct versus a pointer to a struct.
-> makes you remember that things are pointers.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> The switch from -> to . makes perfect sense from a C perspective if we're
>> turning objects into first-class entities rather than pointers; think
>> about a struct versus a p
David M Lloyd <[EMAIL PROTECTED]> writes:
> On 24 Apr 2001, Russ Allbery wrote:
>> It seems relatively unlikely in the course of normal Perl that you're
>> going to end up with very many references to objects.
> Well, right now in Perl, an object *is* a reference.
ters (in particular, something that
doesn't require explicit dereferencing), then using . to access object
members is entirely compatible with C.
I tried to make this point before, but I don't think people understood
what I was getting at.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
y here. (And Perl 5.6.0 has been in Debian
testing for a while, for that matter.)
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Simon Cozens <[EMAIL PROTECTED]> writes:
> Personally, I'd rather not deal with a toke.c that knows more of
> /usr/dict/words than I do.
use thesaurus;
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
In a typical group of system administrators, the features used in Perl
scripts grows by the union of the Perl knowledge of the people involved,
but the ability to maintain those scripts grows by the intersection.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Bryan C Warnock <[EMAIL PROTECTED]> writes:
> perl6-language-datetime - Originally chaired by Russ Allbery. Date &
> time handling. Freeze. Last post was 30 Sep.
[...]
> The ones marked as 'Freeze' have a chance to be reusued later on to
> convert the Apocal
file and will then automatically make those editors just Do The Right
Thing.
--
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/>
ython are really almost entirely just attempting to make
practical ideas already explored in other practical and experimental
languages.
Perl is far more practical than experimental.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
ther character sets for languages we don't need to use.
Am I missing something?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
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
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,
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
they're a lot
more unconventional.
You can still trace nearly everything that was proposed back to C, Lisp,
or Generic Object-Oriented Language, if not in inspiration than at least
in fundamental similarities.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
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
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
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/>
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/>
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
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
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/>
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
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/>
t; For what it's worth, I like it.
So do I, actually... it's sort of growing on me.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
raptor <[EMAIL PROTECTED]> writes:
> I was looking at Interbase SELECT syntax and saw these two handy
> shortcuts :
> = {= | < | > | <= | >= | !< | !> | <> | !=}
> !< and !>
How is !< different from >=?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
Sterin, Ilya <[EMAIL PROTECTED]> writes:
>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
>> How is !< different from >=?
> It's just more syntax just like foo != bar
> is the same as (foo > bar || foo < bar).
> It might prove convenient to expr
e (a bit of) a
> pain. That problem doesn't exist with "!<" and "!>".
Every other programming language I've ever seen uses >= and <=. I think
adding additional comparison operators not found in any other language and
identical to (and harder to type than!) exis
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
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
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/>
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/>
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'
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/>
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
>
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/>
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
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
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/>
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/>
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/>
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/>
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
instead to avoid potential problems.
--
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
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/>
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/>
ieve was the decision already
made), is safe.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
;ll agree with; I find the @{ $$hash{value} } syntax rather
bletcherous. But I think that's a separate problem and could well have a
separate solution.
Perhaps @->$$hash{value} as has been proposed before, and Perl 6 can deal
with the issue of the @- array in some other way.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
t it the order in which the members show up may be different (maybe
garbage collection happened behind the scenes, the hash was reorganized
due to an observation of how you were using it, etc.).
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
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
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
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
ave to guarantee a sorted traversal of the hash keys, your choices
of data structures are *far* more limited.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
John Porter <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> $args = 'first second third';
>> @args = split (' ', $args);
>> my $i = 0;
>> %args = map { $_ => ++$i } @args;
>> This is very Perlish to me; the
e it caused too much confusion.
> Or, if we're gonna not go along with the standard time_t, might as well
> make it 64.
32 bits is clearly insufficient; I would support that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
1 - 100 of 157 matches
Mail list logo
