> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> It's basically a method of indirection. You have a table of
DS> functions--whate each entry in the table does is fixed, but how it
DS> does it depends on which table you use.
DS> foo = (some_pointer->vtable[GET_INT])(some_point
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>> Hmm, will vtbl get rid of all the magic hacks?
NI> The "mg.c" 'magic hacks' are in essence applying vtable semantics (they
NI> are even called vtables in the sources) to a subset of "values".
NI> So yes vtables mean evrything is "mag
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interfaces for linking C objects into perlsubs
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 61
=head1 ABSTRACT
C
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
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 a concrete
definition here.
thanx,
uri
--
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> I was thinking of that--the int portion has the number of keys/entries for
>DS> both hashes and arrays, the char * holds the pointer to the sparse array
>DS> vector or something. Sounds like
In article <01f301cb$90f2ded0$c1252ccb@SAMANTHA>, "Jeremy Howard"
<[EMAIL PROTECTED]> writes:
> Tom Hughes wrote:
>
> > Surely value == NULL is true iff value really is a null?
>
> No. NULL isn't equal to anything! In SQL, you can only say 'value IS NULL'.
You are of course completely corre
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 06:37 AM 8/7/00 -0400, Chaim Frenkel wrote:
>> Are there any (p5p) pragmas that have a runtime effect?
DS> strict, for one. Warnings for another.
Please explain how these are runtime? I see them as compile time.
>> Would requiring/l
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> the user needs a mechanism to handle multi-object locking, or a clean
>> method to order his lock aquisition.
DS> A language issue. Being able to require multiple locks upon
DS> entering a sub, along with timeouts and retries and such, wo
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 08:13 AM 8/7/00 +0100, Hildo Biersma wrote:
>> I want the expressions '1 + 3.14' and '3.14 + 1' to work the same, and
>> they do. Using the current perl overloading mechanism, '1 +
>> Math::BigInt' and 'Math::BigInt + 1' also mean the
If one does 'use tristate' I would hope they know what they are doing
or asking for.
And in fact, I would want the warning turned off. One of the pains
in doing sybperl, is I have to liberally sprinkle $^W=0 or
do a lot of defined() ? :, to avoid the warnings.
> "GB" == Graham Barr <[EMAIL
At 09:25 AM 8/6/00 -0400, Ken Fox wrote:
>John Tobey wrote:
> > But if we anticipate possibly implementing mark-and-sweep
>
>We're definitely going to have some sort of traversing collector. It
>might only augment the ref count collector.
I'd rather not have multiple GC schemes going at once. (Th
When writing RFCs that talk about the inclusion of "interesting" new
features--things like coroutines, matrix math, bizarre regex theory (yes, I
know that's redundant), curried (or garlic'd, or peppered) subs, for
example--it would be helpful if there was a good reference in the
references sec
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, wha
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, whatever) on the fly. Each op would check the
> current
On Mon, Aug 07, 2000 at 06:05:30AM -0400, Chaim Frenkel wrote:
> What are the issues doing it through the vtbl of 'self'? Though if
> the op does it, there would be a different op under the tristate pragma.
Not true. Right now you get a warning for use of uninit when undef
is used. How about unde
On Mon, Aug 07, 2000 at 11:42:39AM -0400, Dan Sugalski wrote:
> At 10:19 AM 8/7/00 +0100, Graham Barr wrote:
> >On Sat, Aug 05, 2000 at 11:55:33PM -0400, Chaim Frenkel wrote:
> > > I was thinking of RFC'ing tri-state logic. Would it be worthwhile to
> > > make it seperate or to extend your RFC?
>
At 08:13 AM 8/7/00 +0100, Hildo Biersma wrote:
>I want the expressions '1 + 3.14' and '3.14 + 1' to work the same, and
>they do. Using the current perl overloading mechanism, '1 +
>Math::BigInt' and 'Math::BigInt + 1' also mean the same (though the hack
>used for this, parameter reversing, is a b
At 06:15 AM 8/7/00 -0400, Chaim Frenkel wrote:
> > "JT" == John Tobey <[EMAIL PROTECTED]> writes:
>
>JT> SVs are never downgraded, so no one's source and destination are
>JT> another's respective destination and source. Maybe the above sequence
>JT> isn't exactly right, but if we adhere to st
At 06:22 AM 8/7/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> I was thinking of that--the int portion has the number of keys/entries
>for
>DS> both hashes and arrays, the char * holds the pointer to the sparse array
>DS> vector or something. Sounds
At 06:29 AM 8/7/00 -0400, Chaim Frenkel wrote:
>What is the problem? WOuldn't every object that ends up on the
>evaluation stack, have to have it's gc-dont-touch-me flag set?
Every object that perl tracks would be safe from GC destruction (though
possibly not movement), and if we don't track it
At 06:37 AM 8/7/00 -0400, Chaim Frenkel wrote:
>Are there any (p5p) pragmas that have a runtime effect?
strict, for one. Warnings for another.
>Would requiring/limiting pragmas to have a strictly compile time effect
>have a win for internals (performance, development, whatever)?
Probably, but p
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. Wh
At 10:19 AM 8/7/00 +0100, Graham Barr wrote:
>On Sat, Aug 05, 2000 at 11:55:33PM -0400, Chaim Frenkel wrote:
> > I was thinking of RFC'ing tri-state logic. Would it be worthwhile to
> > make it seperate or to extend your RFC?
>
>I had mantioned this before, I forget who to. I think it should be
>p
At 12:04 AM 8/7/00 +0200, Bart Lateur wrote:
>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
Are there any (p5p) pragmas that have a runtime effect?
Would requiring/limiting pragmas to have a strictly compile time effect
have a win for internals (performance, development, whatever)?
Would there be any breakage?
For example, warnings. Rather than checking the flag in each op. A wrapper
Ken Fox wrote:
>
> Tom Hughes wrote:
> > In message <[EMAIL PROTECTED]>
> > Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> >
> > > I'd like to be able to mimic what the rules for nulls are in databases.
> >
> > > NULL == NULL : false
> >
> > Always true surely?
>
> NULL to a database
What is the problem? WOuldn't every object that ends up on the
evaluation stack, have to have it's gc-dont-touch-me flag set?
> "JT" == John Tobey <[EMAIL PROTECTED]> writes:
JT> =head1 TITLE
JT> Binary stack layout to support accurate garbage collection and
JT> continuations
JT> =head1
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I was thinking of that--the int portion has the number of keys/entries for
DS> both hashes and arrays, the char * holds the pointer to the sparse array
DS> vector or something. Sounds like a good candidate for Implementation
DS> Define
> "JT" == John Tobey <[EMAIL PROTECTED]> writes:
JT> SVs are never downgraded, so no one's source and destination are
JT> another's respective destination and source. Maybe the above sequence
JT> isn't exactly right, but if we adhere to strict rules for lock
JT> sequencing, there won't be a
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Tom Hughes wrote:
>> In message <[EMAIL PROTECTED]>
>> Chaim Frenkel <[EMAIL PROTECTED]> wrote:
>>
>> > I'd like to be able to mimic what the rules for nulls are in databases.
>>
>> > NULL == NULL : false
>>
>> Always true surely?
KF
On Sat, Aug 05, 2000 at 11:55:33PM -0400, Chaim Frenkel wrote:
> I was thinking of RFC'ing tri-state logic. Would it be worthwhile to
> make it seperate or to extend your RFC?
I had mantioned this before, I forget who to. I think it should be
possible, but probably via a pragma;
use tristate;
Chaim Frenkel wrote:
> The string/number duality should be handled by the vtbl. So a string that
> is never accessed as a number, doesn't waste the space. And numbers that
> are rarely accessed as a string save some room. And as needed the vtbl can
> be promoted to a duality version that maintain
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 was also talked about there, was an
> >early release
34 matches
Mail list logo
