At 05:55 PM 8/1/00 -0400, John Tobey wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Non-inline functions have their place in reducing code size
and easing debugging. I just want an i_foo for every foo that callers
will have the option of using.
Before we make any promises to do
"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
On Wed, 2 Aug 2000, Kevin Scott wrote:
While C might be fine and dandy for getting o.k. native code w/o too
much implementation effort, I think that it might be worth the effort
to implement a JIT compiler for the perl interpreter's intermediate
language.
Given the number of OSes and chip
this is certainly doable (heck, you can do it now with tied
variables), I'm not at all comfortable with a magic untainting variables. I
think it's a rather bad idea.
Dan
--"it's like this"-------
Da
!
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 02:48 PM 8/4/00 -0400, John Tobey wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Yup, and I realized one of my big problems to GCs that move memory
(references that are pointers and such) really isn't, if we keep the
two-level variable structure that we have now. The 'main' SV structure
like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 01:03 PM 8/5/00 -0400, John Tobey wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
and it will require
jumping through a lot of hoops because of perl's profligate use of dynamic
polymorphing. If it's needed, well, we'll do it, but I'd rather put the
effort elsewhere to start
.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
nlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Dan
------"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
--if someone's
leaking interpreters then, well, they've got bigger problems than the odd
foreign object. :)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL
At 03:29 AM 8/4/00 -0400, Ken Fox wrote:
Dan Sugalski wrote:
Your extended way's cool too--RFC it and we can do that as well.
I've been wanting to. It would be nice (at least for me) for you to
start suggesting more RFC "assignments" like this. Community is not
the same as &qu
At 07:54 AM 8/6/00 -0400, John Tobey wrote:
On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski wrote:
John Tobey wrote:
Picture this. A Lisp (or Java, ...) structure holds a Perl
interpreter. A Perl variable holds a reference to the Lisp structure.
Structure and interpreter
y change" parts.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Okay, Okay, I was sloppy! :) I was using the p5 term, assuming it'd give
more context for folks to work with. I agree it should be different and
more appropriately named for p6.
Dan
------"it
like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
to
be designed in.
I'm working on it.
:) I promised Kirrily that I'd race you in the RFC count...
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL
example, did a "$foo[2] = 'bar'" I don't
see any reason not to make $foo[2] have a value of 0. (With a warning
emitted by -w, of course)
Dan
------"it's like this"-
question, given that's almost a year off.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bear
to the
non-op functions, it means they don't have to worry about writing code to
do localtime however we do it, they can just call our function.
Dan
--"it's like this"-------
Da
At 12:35 PM 8/4/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS The language semantics of tie strongly impact the internals. tie() is
DS basically a declaration that the rules are completely different (and
DS unknown at compile time) for the tie
needs has to be designed in.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
s to data with known behaviours.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
t be unreasonable.
This would necessitate the expansion of select to check for pending
events/coroutine writes/data, but that's likely to happen anyway, so...
Dan
--"it's like this"---
Dan Sugalski
creation/attachment methods for
conceptually distinct things.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bear
be perfectly
happy to do so, though, if the resulting code is frozen to disk so I didn't
pay it the next time.
Dan
--"it's like this"---
Dan Sugalski
ent-based perl runtime, the select loop would be hidden
from the programmer. All I/O calls would be non-blocking and context
switching.
I meant select the perl construct, not select the low-level construct.
Dan
------
At 12:51 PM 8/2/00 +0100, Graham Barr wrote:
On Tue, Aug 01, 2000 at 11:56:48AM -0400, Dan Sugalski wrote:
What I was thinking of was something along the lines of a lexically scoped
pragma--"use taint"/"no taint". (We could do this by sticking in an opcode
to set/unset
)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 09:38 AM 8/7/00 +0200, H.Merijn Brand wrote:
On Sat, 05 Aug 2000 12:54:52 -0400, Dan Sugalski [EMAIL PROTECTED] wrote:
At 06:04 PM 8/5/00 +0200, H.Merijn Brand wrote:
In the roadmap, there's lot of actions and shamelines as spoken of in the
camel herders association meeting. What
At 05:42 PM 8/7/00 +0100, Graham Barr wrote:
On Mon, Aug 07, 2000 at 12:03:36PM -0400, Dan Sugalski wrote:
I've been thinking we could have a "state change" op that would
selectively
and lexically alter the appropriate state variable (warnings, stricture,
shell, taint checking
we may need
some sort of "refered to by" field to track variables that have had
references to them taken, so we know when the last referent goes out of scope)
Dan
--"it's like this"----
On Mon, 7 Aug 2000, Uri Guttman wrote:
can someone write up a short description (or rfc is you prefer) on
vtables. i gather that they are a per value (for some definition of
value) dispatch table which handles the ways a value can be
accessed. everyone is using that term and i haven't seen
ibly handy, that. :)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
programmer. Is that it, in
a nutshell, or am I missing something?
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have t
like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
On Tue, 8 Aug 2000, Bart Lateur wrote:
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
On Tue, 8 Aug 2000, Nick Ing-Simmons wrote:
Perl6 Rfc Librarian [EMAIL PROTECTED] writes:
This document is not precisely concerned with the details of the
implementation
of the interfaces it specifies, beyond a general attempt to restric
itself to the possible.
But this list is _only_
On Tue, 8 Aug 2000, Ken Fox wrote:
Chaim Frenkel wrote:
Have every Package generate a vtbl for each subroutine in the package.
Then when something is blessed into the package ...
I wasn't discussing the core. Rather a possible optimization of
method lookup.
At any time only for
be backwards. ;-)
True, quite true. I should throw together a reasonable test program (with,
say, LWP and Net::FTP) in perl 5 and see what the symbol tables look like.
Dan
--"it's like this"-----
At 05:41 PM 8/9/00 +0200, Bart Lateur wrote:
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 l
At 07:07 PM 8/9/00 -0400, Karl Glazebrook wrote:
Dan Sugalski wrote:
At 11:27 PM 8/9/00 +1000, Jeremy Howard 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. :)
Why
On Thu, 10 Aug 2000, Jeremy Howard wrote:
At 07:07 PM 8/9/00 -0400, Karl Glazebrook wrote:
Dan Sugalski wrote:
At 11:27 PM 8/9/00 +1000, Jeremy Howard wrote:
5- Compact array storage: RFC still coming
I hope this RFC will be "Arrays should be sparse when pos
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
if it was saving the byte stream to disk...)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bear
gging more compartmentalized.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
ne backend for a whole bunch of
language front-ends. If they can front-end fortran, C++, and cobol, we
ought to be able to do it with perl...)
Dan
--"it's like this"-------
Dan Sugalski
At 12:14 PM 8/12/00 -0400, Bryan C. Warnock wrote:
On Fri, 11 Aug 2000, David L. Nicol wrote:
Dan Sugalski wrote:
Strong typing and sparse arrays are orthogonal--no reason we
shouldn't use
them if someone does:
$foo[time]
or something of the sort. (People like huge
At 10:47 PM 8/12/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
Er, you still have to think about whether something could be tied and
tainted at the same time.
DS Yeah, that's an issue. We need to hammer out how much is the
responsibility
DS of
o. Whether
it's too specialized to be worth it's a separate issue, of course.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
t
"most CS educated folks" ought to know (a category a number of us don't
necessarily fall into), it's handy to know where to look to brush up on the
details of the thing in question.
Dan
--"it's like th
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote:
Dan Sugalski writes:
I don't mind if someone overrides the vtable functions for a variable of a
built-in type--a standard declaration of:
my $foo;
is really shorthand for:
my generic_scalar $foo;
more or less
On Mon, 14 Aug 2000, Larry Wall wrote:
Nick Ing-Simmons writes:
: It's not clear to me whether the intrinsic types should have a different
: solution to this than the extrinsic types.
:
: _This_ thread is about using vtables for intrinsic types. If we cannot
: make them work there then
On Mon, 14 Aug 2000, Larry Wall wrote:
Dan Sugalski writes:
: The big problem here is the large number of operators that need to
: be supported in every vtable. On the other hand, it means we whittle
: ourselves down to only one operator opcode. ;-)
I don't care if the program is half
On Mon, 14 Aug 2000, Larry Wall wrote:
Dan Sugalski writes:
: On Mon, 14 Aug 2000, Larry Wall wrote:
:
: Dan Sugalski writes:
: : The big problem here is the large number of operators that need to
: : be supported in every vtable. On the other hand, it means we whittle
: : ourselves
On 14 Aug 2000, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS How much of the current base of target ports are you willing to give up in
DS the first cut for fast? The TIL suggestion, amongst others, has the
DS potential to speed things up rather a lot,
functions to be capable of being
written in perl. Even if we don't want to write the floating point division
routines ourselves, I'd like to be able to)
Dan
--"it's like this"----
function for variable @b, and pass it a
pointer to @c, and let it Do The Right Thing.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED]
collection, but it's not really
gone anywhere, besides to the bookstore. The current reference-count GC
scheme will probably go, though.
Dan
--"it's like this"-------
Dan Sugalski ev
At 04:43 PM 8/16/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS * There was some discussion about garbage collection, but it's not really
DS gone anywhere, besides to the bookstore. The current reference-count GC
DS scheme will probably go, though.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
date preceded the
oldest star catalogue in use at SAO, which also avoided having to use
negative time in any of the satellite tracking calculations.
Dan
--"it's like this"-------
Da
-1858 00:00:00.00, for some astronomical
reason IIRC.
It's the Smithsonian Base Date, FWIW. On VMS, though, perl presents all
time in Unix epoch seconds.
Dan
--"it's like this"-------
Da
At 12:23 AM 8/23/00 +, David L. Nicol wrote:
Dan Sugalski wrote:
Any variable that has a 'per-thread' component should be self-contained.
We don't know how many instances of iteration happening in the
program there will be, or how many there can be. If each instance
of hash iteration
hings
that munch the bytecode.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 11:30 AM 8/23/00 -0700, Larry Wall wrote:
Dan Sugalski writes:
: I have had the "Well, Duh!" flash, though, and now do realize that having
: multiple iterators over a hash or array simultaneously could be rather
handy.
You can also have the opposite "Well, Duh!" flash a
At 11:26 AM 8/23/00 -0700, Larry Wall wrote:
Dan Sugalski writes:
: The core will already know.
Especially if we add return types.
Sure. Can't hurt to add code to optimize 'old-style' perl 5 code either,
though.
: Whether this justifies exposing the information's for someone else to
: judge
At 01:49 PM 8/23/00 -0700, Larry Wall wrote:
Dan Sugalski writes:
: At 11:30 AM 8/23/00 -0700, Larry Wall wrote:
: Dan Sugalski writes:
: : I have had the "Well, Duh!" flash, though, and now do realize that having
: : multiple iterators over a hash or array simultaneously could be rath
re or less.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
One of the current plans is for the parser to have access to a list of
functions that trigger autoloading modules.
Isn't dynamic loading really slow?
Not particularly, at least not as far as I know. There's some extra
of the functions
under discussion. (They're generally trivial wrappers around library calls,
with very little code involved)
Dan
--"it's like this"-------
Dan Sugalski ev
At 06:27 AM 8/25/00 -0700, Benjamin Stuhl wrote:
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
One of the current plans is for the parser to have
access to a list of
functions that trigger autoloading modules.
Isn't dynamic loading really slow
...
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy
still continue to work unaltered, then I suppose
not--assuming no seriously grave performance issues.
That's one of the working goals...
Dan
--"it's like this"-------
Dan Sugalski
that
details what I'm thinking about for this...
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bear
on into a
shareable image so we don't even need to parse a text file--it's already
predigested and available)
Dan
--"it's like this"---
Dan Sugalski
.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
that be $baz = 3, since the middle list would be taken in scalar
context?
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED]
into
perl 6. Whether (or how) that happens depends mainly on the speed penalty
the overriding costs.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL
On Sun, 27 Aug 2000, Nathan Torkington wrote:
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
attributes.
You folks are all going to make my head explode before this is all over,
aren't you? (Not that it's a *bad* thing, mind... :)
Dan
--"it's like this"-------
Dan Sugalski
like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
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 arrays
of the way now, rather than after spending a month or more of
wasted time.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED]
be nice to statically link in code that would otherwise be
dynamically loaded
I've got part of an RFC done--I'll finish it and send it off.
Dan
--"it's like this"-------
Da
.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
lved calls into the
routines in the newly loaded library get resolved.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have
On 29 Aug 2000, Russ Allbery wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
2) Having a mechanism to automagically load in chunks of executable code
only when needed would be nice
It's not clear to me how useful this really is from an internals speed
standpoint on modern systems. It's
On 29 Aug 2000, Russ Allbery wrote:
I'm not sure I'm completely following what you're arguing for here, but be
careful not to go too far down the road of duplicating what the dynamic
loader already knows how to do. There be dragons; that stuff is seriously
baroque. You really don't want to
because we hand
someone a gun doesn't mean we need to load it and point it somewhere as well)
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote:
Dan Sugalski wrote:
2) Having a mechanism to automagically load in chunks of executable code
only when needed would be nice
I would take this one a bit further:
2a) It should be possible, at compile-time, to detect what chunks
At 07:37 PM 8/29/00 -0700, Russ Allbery wrote:
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 way
for
biggish things), I wonder how much perl 5's performance could be boosted
with some relatively minor changes to GC list handling.
Dan
--"it's like this"-------
Dan Sugalski
"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
At 01:26 PM 8/30/00 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
Oh, and then they will be unloaded if we need the space for something
else. I understand now, thanks.
Well, probably not, though that could be reasonable for a particular
platform. It's only relevant
On Wed, 30 Aug 2000, Andy Dougherty wrote:
On Tue, 29 Aug 2000, Russ Allbery wrote:
Not a big deal, and that's certainly doable. But it's possible to do more
than that if you really want to. The glibc folks have decided to comment
to nearly full binary compatibility for essentially
At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
Okay, here's a list of functions I think should go into variable vtables.
Functions marked with a * will take an optional type offset so we can
handle asking for various permutations of the basic type
t or float.
Dan
--"it's like this"-------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
1 - 100 of 3756 matches
Mail list logo
