On Tue, 29 May 2001 18:25:45 +0100 (BST), Dave Mitchell wrote:
>diffs:
>
>-"K&R" style for indenting control constructs
>+"K&R" style for indenting control constructs: ie the closing C<}> should
>+line up with the opening C etc.
On Wed, 30 May 2001 10:37:06 -0400, Dan Sugalski wrote:
>I realize
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, aren't they?
It's not really important.
UTF-8 is NOT limited to 16 bits (3 bytes). With
On Tue, 12 Jun 2001 18:12:35 -0400, Dan Sugalski wrote:
>'Kay, here's a question to ponder. Should the op dispatch loop handle
>argument decoding, or should that be left to the opcode functions?
Are you talking about lazy vs. normal evaluation?
Lisp knows basically two modes, normal evaluation
On Wed, 13 Jun 2001 12:00:21 +0100 (BST), Dave Mitchell wrote:
>I was thinking back to the earlier discusions on opcode dispatch,
>and the fact that some people thought that a big switch was as good as,
>or possibly faster than a dispatch table. Which led me to think...
I would think that a swit
On Wed, 13 Jun 2001 01:22:32 +0100, Simon Cozens wrote:
> Something that should be part of the core? I'll leave
>that for you to decide.
Most definitely NOT.
There is no reason to put fucntionality for free matching of Japanese
characters into the basic perl executable. There were already voice
On Wed, 13 Jun 2001 13:39:16 -0400, Dan Sugalski wrote:
>> > Something that should be part of the core? I'll leave
>> >that for you to decide.
>>
>>Most definitely NOT.
>
>Most definitely sort of.
>
>>There is no reason to put fucntionality for free matching of Japanese
>>characters into the basi
On Fri, 15 Jun 2001 06:52:32 -0400, Bryan C. Warnock wrote:
>On a side note (and this *will* sound stupid, but there is a reason I'm
>asking). Why is there no logical opposite to '.'; that is, a character
>which never matches another character? (Besides, of course, that it's
>utterly useless
On Tue, 19 Jun 2001 11:53:28 -0700, Hong Zhang wrote:
>> * Do a substr operation by character and glyph
>
>The byte based is more useful. I have utf-8, and I want to substr it
>to another utf-8. It is painful to convert it or linear search for
>charaacter
>position.
I tend to agree.
I currently
On Tue, 19 Jun 2001 14:51:43 -0500, Jarkko Hietaniemi wrote:
>But a locale is a collection of user preferences. How I want
>my dates to be formatted, how I want my strings to be sorted.
That's not right. If I do a text conversion from Windows to Mac, I would
want to source to use the CP-1522 lo
On Mon, 30 Jul 2001 22:32:54 -0400 (EDT), Sam Tregar wrote:
>On Mon, 30 Jul 2001, Dan Sugalski wrote:
>
>> When you actually use a module, the simple name (like IO) will be
>> internally expanded out to the three value thing. So if you have two
>> modules that each use a different version of the
On Tue, 31 Jul 2001 07:24:45 +0200, Bart Lateur wrote:
>For example, with simple file names, it's impossible to run a perl 5.005
>and a perl 5.6 both using XML::Parser, at the same time.
It's also impossible, on Win32, to use XML::Parser and (an XS version
of) HTML::Parser
On Mon, 6 Aug 2001 15:41:59 -0700 , Hong Zhang wrote:
>>Branches should work from
>> both constants and registers.
>
>Even so, the "branch #num" should have better performance, and
>it is part of any machine language. Since we already have jump
>instruction, do we really need the "branch %r", w
On Mon, 06 Aug 2001 21:55:07 -0400, Dan Sugalski wrote:
>>But I do not agree that calculated jumps should be done in such a hard
>>way.
>
>Nothing hard about it, really.
I was referring to Hong Zhang's proposal, not yours.
--
Bart.
On Sat, 25 Aug 2001 18:58:50 +0100, Simon Cozens wrote:
>I was using .pas and .pac. Gotta think about 8.3ness, unfortunately.
The "8" might not be that relevant nowadays, but the "3" still matters.
On Win32, file extensions get cut off after 3 characters. So a ".html"
file is actually the same a
On Mon, 03 Sep 2001 19:29:09 -0400, Ken Fox wrote:
>> *How* are they "fundamentally different"?
>
>Perl's "local" variables are dynamically scoped. This means that
>they are *globally visible* -- you never know where the actual
>variable you're using came from. If you set a "local" variable,
>all
On Mon, 03 Sep 2001 19:30:33 -0400, Dan Sugalski wrote:
>The less real question, "Should pads be hashes or arrays", can be answered
>by "whichever is ultimately cheaper". My bet is we'll probably keep the
>array structure with embedded names, and do a linear search for those rare
>times you're
On Sat, 08 Sep 2001 13:02:04 -0400, Dan Sugalski wrote:
>>Uri mentioned exp(x) = e^x, but I think if you are going to include
>>log2, log10, log, etc, you should also include ln.
>
>Added.
Er... aren't ln and log synonyms?
--
Bart.
On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote:
>Who the heck is going to override arctangent? (No, don't tell me, I don't
>want to know)
Perhaps you do. Think BigFloat. Or Complex.
--
Bart.
On Mon, 10 Sep 2001 18:48:01 -0400, Dan Sugalski wrote:
>At 12:35 AM 9/11/2001 +0200, Bart Lateur wrote:
>>On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote:
>>
>> >Who the heck is going to override arctangent? (No, don't tell me, I don't
>> &
[I'm behind on my mail :-)]
On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>We're trying to align to a power-of-two boundary, and mask is set to
>chop off the low bits, not the high ones. It should be something like:
>
>
>
>The calc:
>
> mem & mask + (~mask + 1)
>
On Thu, 13 Sep 2001 06:27:27 +0300 [ooh I'm far behind on these lists],
Jarkko Hietaniemi wrote:
>I always see this claim ("why would you use 64 bits unless you really
>need them big, they must be such a waste") being bandied around, without
>much hard numbers to support the claims.
>Unless you
On Sun, 23 Sep 2001 21:45:39 -0400, Dan Sugalski wrote:
>>We're talking bytecode. That will indeed be a case of "huge arrays of
>>tightly packed integers".
>
>For bytecode, it's not a big problem, certainly not one I'm worried about.
>Machines that want 64-bit ints have, likely speaking, more th
On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
>Nope. At the very least, a bytecode file needs to start with:
>
>8-byte word:endianness (magic value 0x123456789abcdef0)
>byte: word size
>byte[7]:empty
>word: major version
>word: minor version
>
>
On Thu, 20 Sep 2001 14:04:43 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
>> >For clarification: do you mean async I/O, or non-blocking I/O?
>>
>> Async. When the interpreter issues a read, for example, it won't assume the
>> read completes immediatel
On Mon, 24 Sep 2001 11:29:10 -0400, Dan Sugalski wrote:
>However...
>
>I was talking about a different instance of "bitmap". More like:
>
> newbm P3, (640, 480, 24, 8) # Make a 640X480, 24 bit image
> # with 8 bits of alpha
> drawline P3, (100, 100, 200, 200,
On Fri, 28 Sep 2001 22:53:35 +0200, Andreas Buggs Hauser wrote:
>On Friday 28 September 2001 19:55, Gibbs Tanton - tgibbs wrote:
>> Ooohh, that's bad. Cygwin works fine for me. What test is it failing on?
>> What version of perl?
>
>I reinstalled Cygwin with "Default Text File Type" set to Unix
On Tue, 23 Oct 2001 08:39:29 -0400, John Siracusa wrote:
>As one of the few rabid Mac users on this list, let me just say that I
>personally have no problem with classic Mac OS support being totally dropped
>from Parrot if it'll get stuff out the door sooner :) Classic Mac OS is
>(somewhat sadly
On Wed, 21 Nov 2001 13:46:09 -0500, Dan Sugalski wrote:
>Nah, using an I register as a host-machine-address for jumps doesn't argue
>for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
>that uses an int as an absolute address is wrong.
>
>I'm going to rewrite the docs and o
On Sun, 25 Nov 2001 13:14:22 +, Simon Cozens wrote:
>On Sun, Nov 25, 2001 at 02:32:34AM -0500, Angel Faus wrote:
>> use Text::Balanced 'extract_bracketed';
>
>Urgh. We need to work around this.
Can somebody fill me in exactly how this is supposed to behave?
I think that this may come close
On Sun, 25 Nov 2001 19:34:15 -0800, Brent Dax wrote:
>Perl 5's REs will always appear faster because Perl 5 has an
>intelligent, optimizing regex compiler. For example, take the following
>simple regex:
>
> /a+bc+/
>
>pregcomp will optimize that by searching for a 'b' and working outwards
On Tue, 09 Oct 2001 21:12:00 -0400, Dan Sugalski wrote:
>Does anyone handy have
>an 8-bit set that's not US ASCII as their default character set?
EBCDIC?
Not me.
--
Bart.
On Thu, 11 Oct 2001 09:59:56 -0400, Dan Sugalski wrote:
>At 06:10 PM 10/10/2001 -0700, Dave Storrs wrote:
>>Any interest in using something less painful than Make for this? I was
>>thinking of Cons, myself...built in Perl 5 (which we are already requiring
>>you to have), and much more friendly t
On Thu, 11 Oct 2001 22:23:06 -0400, Dan Sugalski wrote:
>>Are they going to be segmented somehow
>>so there's a "far jump" which takes us out of the current block?
>
>Nope. Jumps and jsrs take absolute addresses, so they can go anywhere.
>Branches are relative so fixing them up to bounce between
On Fri, 12 Oct 2001 18:18:27 +0200, Ritz Daniel wrote:
>within the vm address 0 should be address 0 of the bytecode, not the
>real cpu. but it would be nice to have a null pointerso what about the first
>instruction in bytecode is at vm address 1?
All you have to do is reserve the location
On Mon, 15 Oct 2001 22:12:58 -0400 (EDT), Dan Sugalski wrote:
>>doing:
>> save S0
>> restore S1
>>
>>(since there's no set S1,S0)
>>
>>binds the registers together, so a change to one is a change to
>>both...which doesn't happen on int registers.
>Right. Save on a string register pushes the
On Tue, 04 Dec 2001 15:57:56 -0500, Dan Sugalski wrote:
>Q: Don't you know that stack machines are the way to go in software?
>A: No, in fact, I don't.
>
>Q: But look at all the successful stack-based VMs!
>A: Like what? There's just the JVM.
>
>Q: What about all the others?
>A: *What* others? Th
On Wed, 05 Dec 2001 13:32:32 -0500, Dan Sugalski wrote:
>Right, but FORTH's not an interpreted language, generally speaking.
The old FORTH's in the 80's worked pretty much like the p-copde
interpreter.
Nowadays, FORTH compilers are really optimizing compilers. There are
excellent commercial off
On Thu, 06 Dec 2001 00:16:34 GMT, Tom Hughes wrote:
>So far I have added as is_digit() call to the character type layer
>to replace the existing isdigit() calls.
There seems to be an overlap with the /\d/ character class in regexes.
Can't you use the same test? Can't you use the definition of th
On Sun, 30 Dec 2001 16:11:35 -0800 (PST), Boris Tschirschwitz wrote:
>Yeah,
>
>int *num;
>
>is customary in C, but for some reason C++ people like to write
>
>int* num;
>
>I am sure I saw some rationale for that in gcc's C++ part, but I can't
>find it anymore. Apparently C programmers do not fall
On Sun, 06 Aug 2000 01:38:13 -0400, Dan Sugalski wrote:
>>Even in perl5 an XS module can do _anything at all_.
>
>It can't access data the lexer's already tossed out. That's where the
>current format format (so to speak) runs you into trouble.
Only if you insist on the identical syntax as it ha
On Tue, 08 Aug 2000 11:33:06 -0400, Dan Sugalski wrote:
>The problem perl will always run into is that our executable code counts as
>data to CPUs, and lives in the D cache, along with all the data we work on.
>Ripping through a few 100K strings'll kill any sort of benefits to keeping
>the opt
On Tue, 8 Aug 2000 20:58:46 -0400 (EDT), Dan Sugalski wrote:
>On Tue, 8 Aug 2000, Bart Lateur wrote:
>
>> Time for subroutine threading, isntead of op threading?
>
>Probably, depending on your definition of subroutine threading.
>
>> That would definitely make the &qu
On Wed, 9 Aug 2000 09:11:55 +0100 (BST), Nick Ing-Simmons wrote:
>> @foo = @bar * 12;
>
>I like it.
>It is pretty obvious what above should do:
>
>@foo = ();
>foreach my $elem (@bar)
> {
> push(@foo,$elem * 12);
> }
@foo = map { $_ * 12 } @bar;
I don't see the need for a new notat
On Wed, 09 Aug 2000 10:04:15 -0400, Dan Sugalski wrote:
>>5- Compact array storage: RFC still coming
>
>I hope this RFC will be "Arrays should be sparse when possible, and
>compact" and just about nothing else. :)
You mean, something like hashes?
Faster hashes, maybe, with a hash function opti
On Wed, 09 Aug 2000 12:03:40 -0400, Dan Sugalski wrote:
>> >I hope this RFC will be "Arrays should be sparse when possible, and
>> >compact" and just about nothing else. :)
>>
>>You mean, something like hashes?
>
>Nope.
>
>>Faster hashes, maybe, with a hash function optimized for numerical
>>inte
On Wed, 09 Aug 2000 09:41:22 -0400, Dan Sugalski wrote:
>> >> @foo = @bar * 12;
>> @foo = map { $_ * 12 } @bar;
>>I don't see the need for a new notation.
>
>Well, compactness for one. With a scalar on one side it's less odd (it was
>a bad example). When funkier, though:
>
> @foo =
On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote:
>> > @foo = @bar * @baz;
>Given that the default action of the multiply routine for an array in
>non-scalar context would be to die, allowing user-overrides of the
>functions would probably be a good idea... :)
[Is this still -internal
On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
>> I expect that we'll get more compile-time benefit from
>>
>> my HASH sub foo {
>> ...
>> }
>>
>> %bar = foo();
>
>Ah, the Return Value Optimization so loved in C++...
>
>For those who haven't seen it before, you can
On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote:
>Code you don't call won't eat up any cache space, nor crowd
>out some other code. And if you do call it, well, it ought to be in the cache.
Probably a stupid question... But can't you group the code for the most
often used constructs? So
On Tue, 05 Sep 2000 11:48:38 -0400, Dan Sugalski wrote:
>>- two-phase commit handler, rollback coordinator (the above two is
>> connected to this: very simple algorhythm!)
>
>Here's the killer. This is *not* simple. At all. Not even close.
>
>Doing this properly with data sources you comple
On Thu, 10 Aug 2000 05:03:38 +0200, Bart Lateur wrote:
[description of a mechanism for storing sparse arrays:]
>Imagine
>that it will be traversed based upon the groups of bits in the array
>index. Say, with 32 bit indices, subdivided into 4 bytes. You can start
>with the lower byt
On Wed, 06 Sep 2000 11:23:37 -0400, Dan Sugalski wrote:
>>Here's some high-level emulation of what it should do.
>>
>> eval {
>> my($_a, $_b, $c) = ($a, $b, $c);
>> ...
>> ($a, $b, $c) = ($_a, $_b, $_c);
>> }
>
>Nope. That doesn't ge
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
>Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
>anything else sees it. So any features implemented in the tokenizer have
>to get smarter about remembering what they did.
This sound pretty much like the same problem yo
On Tue, 5 Sep 2000 10:48:45 +0200, dLux wrote:
>/--- On Mon, Sep 04, 2000 at 07:18:56PM -0500, Greg Rollins wrote:
>| Will perl monitor the commit and rollback actions of transactions?
>\---
>
>What exactly you mean?
And did you have to quote 500+ lines of the RFC just to add this one
sentence?
On 25 Sep 2000 20:15:19 -, Perl6 RFC Librarian wrote:
>Erreur de syntaxe. Syntaxfehler. Errore di sintassi. suntaktik'o sphalm'a.
>
>Perl 6 needs some kind of internationalisation and therefore message
>catalogue support. Really needs, with great urgency.
Eh? Are you saying that Perl's error
On 28 Sep 2000 19:40:01 -, Perl6 RFC Librarian wrote:
>=head2 How iterators might work in perl 6
>
>In perl 6 the keys and values functions should no longer use the
>same iterator as the each function - each use of keys and values
>should use it's own private iterator instead.
Is that per Da
On 1 Oct 2000 06:40:08 -, Perl6 RFC Librarian wrote:
>Perl 5 split does five things that I think are just annoying, and
>which I suggest be removed:
I've got one more problem.
for my $i (0 .. 4) {
$_ = ':' x $i;
my @a = split /:/, "", -1;
my $coun
On Sun, 01 Oct 2000 11:18:58 +0200, Bart Lateur wrote:
> my @a = split /:/, "", -1;
Oops. that should be
my @a = split /:/, $_, -1;
--
Bart.
On Mon, 2 Oct 2000 09:40:33 -0500, Jarkko Hietaniemi wrote:
>
>For the record: I hate the current policy of defaulting to NVs for
>arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of
>2.000. Currently if I say
>
> $a = 2;
> $b = 3;
> $c = $a + $3;
s/\$3/\$b/
On Fri, 6 Oct 2000 23:26:44 -0500, Jonathan Scott Duff wrote:
> @foo = split;
> # BECOMES
> @foo = split; pop @foo until $foo[-1];
That doesn't fly. What if that last field is "0"?
> @foo = split ' ';
> # BECOMES
> @foo = split /\s+/; shift @foo;
What if th
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:
On Sat, 6 Jan 2001 00:45:11 +, Simon Cozens wrote:
>No, it's exactly what Perl 5 does.
>
>This is the Perl interpreter:
>while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
>PERL_ASYNC_CHECK();
>}
>
>The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
>do a
On Tue, 6 Feb 2001 17:53:17 -0200, Branden wrote:
>It appears you're blessing one reference and returning another... like
>
>sub new {
>my $key;
>my $a = \$key;
>my $b = \$key;
>bless $a;
>return $b;
>}
>
>I think the problem is not with the overloa
[CC'ed to language, because I think it's there that it belongs]
On Mon, 5 Feb 2001 15:35:18 -0200, Branden wrote:
>There are two possible things that could happen when you say:
>$a = $b;
>@a = @b; # or
>%a = %b;
>
>These two things are assignment and aliasing.
No way. Although I th
On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote:
>And then, if we have BigFloat, we need a way to specify rounding and
>precision. Otherwise 1/3 eats up all memory or provides limits ;o)
Er... may I suggest ratio's as a data format? It won't work for sqrt(2)
or PI, but it can easily store
On Tue, 24 Apr 2001 19:17:08 -0500, Jarkko Hietaniemi wrote:
>Wasn't Perl also taken, so why care...? I vaguely remember reading
>about another language called PERL...
It was "Pearl", AFAIK. That's why the "a" got missing. So I've been
told... ("Practical Extracting And Reporting Language"... y
On Wed, 25 Apr 2001 11:01:07 -0300, Branden wrote:
>If the idea is supporting arbitrary add-on operators, which I believe will
>be done seldom, for only some specific classes, wouldn't it be better to
>have a ``catch all'' entry for operators different than the built-in ones?
>
>Of course, add-
67 matches
Mail list logo
