Dan Sugalski wrote:
> If you want efficiency, n-dimensional arrays really need to be a concrete
> data type all of their own. That way one big block of memory can be
> allocated and, if it's a typed array, properly sized.
I wholeheartedly agree ;)
>
> That doesn't mean that n-dimensional array
> I'm still in favor of moving the socket functions into Socket if for no
> other reason than it may help beat into people's heads that code like:
>
> eval 'require "sys/socket.ph"';
> eval 'sub SOCK_DGRAM {-f "/vmunix" ? 2 : 1;}' if $@;
>
> and
>
> $csock = pack('S n a4 x8', 2, 0,
Stephen P Potter <[EMAIL PROTECTED]> writes:
> At this point, should I go ahead and abandon the Math/Trig and/or
> Sockets ones?
I'm still in favor of moving the socket functions into Socket if for no
other reason than it may help beat into people's heads that code like:
eval 'require "sys/
> "SF" == Steve Fink <[EMAIL PROTECTED]> writes:
SF> Or what about a variable attribute:
SF> my $x : transactional
SF> and making the effect completely lexical? Why would other scopes need to
SF> see such variables?
You haven't handled the multiple variable variety. You will need to
able t
At 08:18 AM 8/29/00 +1200, Christian Soeller wrote:
>Dan Sugalski wrote:
> > That doesn't mean that n-dimensional arrays won't be just sugar over the
> > standard list-o-list structure to start, but they won't have to stay
> that way.
>
>That seems to be a possible route. Get multi-dim syntax for
>>BTW, I have access to Rational Software's Quantify (and PureCoverage and
>>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests.
>
>If you want to get "in the mood" it would be good to fire it up on
>(say) perl5.6.0 and see where the hot-spots are.
Planning on it as part of
Lightning flashed, thunder crashed and Nick Ing-Simmons <[EMAIL PROTECTED]>
whispered:
| I think this is inappropriate for sin/cos/tan et. al. and possibly even
| sockets (although Win32 sockets are weird enough that it would be worthwhile)
|
| But for getpw* or shm/queue/msg or other may-not-b
Tom Christiansen <[EMAIL PROTECTED]> writes:
>
>Explain why things like #ifdef HAS_SETLOCALE are not sufficient for
>this stated purpose.
Because the source has to have something like:
#ifdef HAS_SETLOCALE
...
setlocale(...)
...
#else
#endif
That does not help someone who has Locale
Steve Fink wrote:
>
> "cond" for conditional?
I was thinking along that line, too. But coopting "conditional" in any way
is probably an ungood idea.
Probly "trans" is good; it has multiple useful mnemonic values: transactional,
transfer, transparent...
--
John Porter
We're building
Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> But if perl6 bytecode does not need to be modified to be used
I'd assume that.
-- Johan
>Move the mathematic functions (C, C, C) from the core
>binary into a loadable module. Remove the trigonomic (C, C,
>C) functions from the binary, they can already be loaded from the
>Math::Trig.pm module.
>=head1 DESCRIPTION
>It is desirable to make the perl core binary be easy to maintain a
At 12:19 PM 8/28/00 -0500, Jarkko Hietaniemi wrote:
> > Or what about a variable attribute:
> >
> > my $x : transactional
> >
> > and making the effect completely lexical? Why would other scopes need to
> > see such variables?
>
>Hear, hear! We do not want zillion and a half new keywords now that
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Remove mathematic and trigonomic functions from core binary
=head1 VERSION
Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
Date: Aug 24 2000
Last Modified: Aug 28 2000
Version: 2
Mailing List: [
> Or what about a variable attribute:
>
> my $x : transactional
>
> and making the effect completely lexical? Why would other scopes need to
> see such variables?
Hear, hear! We do not want zillion and a half new keywords now that
we have attributes.
--
$jhi++; # http://www.iki.fi/jhi/
dLux wrote:
>
> /--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote:
> | > Still not good. "trans" is too overloaded word. "transaction"?
> | > "transactional"? (a bit too long...) "atomic"?
> |
> | "acid"?
> \---
>
> "transactional" and "transaction" are quite long, I don't like th
Nathan Torkington wrote:
>
> David L. Nicol writes:
> > Any subroutine declaration, for instance
> >
> > sub Cmp:infix($$){
> > return uc($_[0]) cmp uc($_[1])
> > };
> >
> > implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
> > it installs the name of th
Fisher Mark <[EMAIL PROTECTED]> writes:
>>Leaping to conculusions based on no tests at all is even worse...
>>
>>Will anyone bite the bullet and write the "Internals Decisions should
>>be based on actual tests on multiple platforms" RFC ?
>
>BTW, I have access to Rational Software's Quantify (and
Dan Sugalski wrote:
> >
> >I'm thinking that a n-dim array could just be a list of lists (of lists of
> >lists of...) with the n-dim notation just being syntactic sugar (and perhaps
> >helping with optimisation too).
>
> If you want efficiency, n-dimensional arrays really need to be a concrete
>
Nathan Torkington <[EMAIL PROTECTED]> writes:
>Dan Sugalski writes:
>> If the vtable stuff goes into the core perl engine (and it probably will,
>> barring performance issues), then what could happen in the
>
>I have a lot of questions. Please point me to the appropriate place
>if they are answer
At 10:28 AM 8/28/00 +1000, Jeremy Howard wrote:
>
>
>David L. Nicol wrote:
> > If arrays as we know them implement by using a key space restricted to
> > integers, I think a reasonable way to get matrices would be to open
> > up their key space to lists of integers.
> >
>I've been thinking along e
It's been strongly indicated that removing sockets (as well as any
other Perl functions that are little but wrappers around libc calls)
will not meaningfully reduce the size of Perl nor increase its
speed. Various VM issues have been discussed, including risks of
deadly embrace and egregious perf
>Leaping to conculusions based on no tests at all is even worse...
>
>Will anyone bite the bullet and write the "Internals Decisions should
>be based on actual tests on multiple platforms" RFC ?
BTW, I have access to Rational Software's Quantify (and PureCoverage and
Purify) on WinNT and HP-UX 10
I think the importance of splitting the core functionality into shared
objects is more general than that. There was some discussion a short time
ago about making a pared-down version for embedding, which would seem to
require some sort of functionality reduction. There is also the desire of
minimi
23 matches
Mail list logo
