Dan Sugalski wrote:
> Grab one via a utility function. getPMC() or something of the sort.
>
> newPMC() ? ;-)
I think we shouldn't rule out the possibility of having multiple
newPMC() style functions for grabbing PMCs used for different activities
(eg lexicals vs tmps vs guaranteed-to-have-refcoun
At 02:50 AM 2/19/2001 +, Simon Cozens wrote:
>On Sun, Feb 18, 2001 at 09:34:46PM -0500, Dan Sugalski wrote:
> > At 01:13 AM 2/19/2001 +, Alan Burlison wrote:
> > >Dan Sugalski wrote:
> > >
> > > > Grab one via a utility function. getPMC() or something of the sort.
> > >
> > >newPMC() ? ;-)
On Sun, Feb 18, 2001 at 09:34:46PM -0500, Dan Sugalski wrote:
> At 01:13 AM 2/19/2001 +, Alan Burlison wrote:
> >Dan Sugalski wrote:
> >
> > > Grab one via a utility function. getPMC() or something of the sort.
> >
> >newPMC() ? ;-)
>
> Works for me.
Slight that-sucks alert: So, if I have to
At 01:13 AM 2/19/2001 +, Alan Burlison wrote:
>Dan Sugalski wrote:
>
> > Grab one via a utility function. getPMC() or something of the sort.
>
>newPMC() ? ;-)
Works for me. Though for some reason it brings up visions of the Village
People, and that's generally a Bad Thing... :)
Dan Sugalski wrote:
> Grab one via a utility function. getPMC() or something of the sort.
newPMC() ? ;-)
Alan Burlison
At 12:45 AM 2/19/2001 +, Alan Burlison wrote:
>Dan Sugalski wrote:
>
> > >If PMC is a pointer to a structure, "new" will need to allocate memory
> for a
> > >new structure, and hence the value of mypmc will have to change.
> >
> > Nope. PMC structures will be parcelled out from arenas and not
Dan Sugalski wrote:
> >If PMC is a pointer to a structure, "new" will need to allocate memory for a
> >new structure, and hence the value of mypmc will have to change.
>
> Nope. PMC structures will be parcelled out from arenas and not malloc'd,
> and they won't be freed and re-malloced much. If
On Sat, Feb 17, 2001 at 02:34:08PM -0500, Dan Sugalski wrote:
> Well, the idea was that the passed in PMC is either reusable, can be
> trashed, or is an aggregate of some point and we may autoviv the element
> corresponding to the key.
Right, OK, but how do we create them in the first place?
>
At 04:55 PM 2/17/2001 +, Simon Cozens wrote:
>On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> > =item new
> >
> >void new(PMC[, key]);
> >
> > Creates a new variable of the appropriate type out of the passed PMC,
> > destroying the current contents if there ar
On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> =item new
>
>void new(PMC[, key]);
>
> Creates a new variable of the appropriate type out of the passed PMC,
> destroying the current contents if there are any. This is a class
> function.
Can I suggest this becom
On Wed, Feb 14, 2001 at 06:37:18PM +, David Mitchell wrote:
> Hmm, there doesnt seem to be anything related to handling constants in PDD 2.
I anticipate constants will be PMCs with a small vtable of "get methods",
possibly with several different types of value (string, numberic, float, etc.)
After a week's delay where I've just been too busy,
I thought I'd resurrect the corpse of a thread I was involved in.
First off,
on Wed, 07 Feb 2001 14:37:33, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:05 PM 2/7/2001 +, David Mitchell wrote:
> >Dan, before I followup your reply to m
At 11:16 AM 2/12/2001 +, Tim Bunce wrote:
>On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
> >
> > >On the other side, for a string that is matched against regexps, it
> doesn't
> > >matter much if it has variable character length, since regexps
> normally read
> > >all the str
On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
>
> >On the other side, for a string that is matched against regexps, it doesn't
> >matter much if it has variable character length, since regexps normally read
> >all the string anyway, and indexing characters isn't much of a concern.
At 08:47 AM 2/10/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > >The string API should be sufficiently smart to be able to convert data
>from
> > >one encoding to another as it's more convenient.
> >
> > No, the vtable functions for the variables should know how to convert from
> > and to per
Dan Sugalski wrote:
> >The string API should be sufficiently smart to be able to convert data
from
> >one encoding to another as it's more convenient.
>
> No, the vtable functions for the variables should know how to convert from
> and to perl's preferred string representations, and can do whateve
At 09:56 AM 2/9/2001 -0200, Branden wrote:
>Jarkko Hietaniemi wrote:
> > > Umm, one way or another I suspect UTF-8 will be in there.
> >
> > I suspect so too but very grudgingly. As Dan said dealing with
> > variable length data is a major pain. UTF-8 is certainly a much
> > better designed VLD
Jarkko Hietaniemi wrote:
> > Umm, one way or another I suspect UTF-8 will be in there.
>
> I suspect so too but very grudgingly. As Dan said dealing with
> variable length data is a major pain. UTF-8 is certainly a much
> better designed VLD than most but it's still a pain.
>
I guess that's why
On Thu, Feb 08, 2001 at 09:55:17PM -0600, Jarkko Hietaniemi wrote:
> > Umm, one way or another I suspect UTF-8 will be in there.
>
> I suspect so too but very grudgingly.
If we abstract the string handling nicely, it can be added on later or even
separately. (Credo: We don't have to write all of
> > I didn't put UTF-8 in on purpose, because I'd just as soon not deal with it
> > internally. Variable length character data's a pain in the butt, and if we
> > can avoid having the internals deal with it except as a source that gets
> > converted to UTF-32, that's fine with me.
>
> I agree
Dan Sugalski wrote:
>
> At 11:57 AM 2/8/2001 +0100, Edwin Steiner wrote:
> >Dan Sugalski wrote:
> > > At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > > > >Please see my previous post on the subject. As I pointed there,
> > > > implementing
> > > > > >|| and && like that breaks short-circu
At 11:57 AM 2/8/2001 +0100, Edwin Steiner wrote:
>Dan Sugalski wrote:
> > At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > > >Please see my previous post on the subject. As I pointed there,
> > > implementing
> > > > >|| and && like that breaks short-circuits.
> > > >
> > > > No, it doesn't
At 12:12 PM 2/8/2001 +, Nicholas Clark wrote:
>On Wed, Feb 07, 2001 at 01:24:27PM -0500, Dan Sugalski wrote:
> > At 06:12 PM 2/7/2001 +, Nicholas Clark wrote:
>
> > >But I don't like the thought of going in and out of a lot of generic
> > >routines for
> > >
> > >$a = 3;
> > >$a += 2;
> >
On Wed, Feb 07, 2001 at 01:24:27PM -0500, Dan Sugalski wrote:
> At 06:12 PM 2/7/2001 +, Nicholas Clark wrote:
> >But I don't like the thought of going in and out of a lot of generic
> >routines for
> >
> >$a = 3;
> >$a += 2;
> >
> >when the integer scalar ought to know what the inside of anot
Dan Sugalski wrote:
> At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > >Please see my previous post on the subject. As I pointed there,
> > implementing
> > > >|| and && like that breaks short-circuits.
> > >
> > > No, it doesn't. Just because you pass in two PMCs doesn't mean that they
>
At 06:08 PM 2/7/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > Splitting the vtable into two pieces, with one piece not tied to a PMC,
> > makes some things impossible. Consider this:
> >
> >@foo = @bar * @baz;
> >
> > where all three arrays are really matrix types.
>
>By the PDD's notion
Dan Sugalski wrote:
> Splitting the vtable into two pieces, with one piece not tied to a PMC,
> makes some things impossible. Consider this:
>
>@foo = @bar * @baz;
>
> where all three arrays are really matrix types.
By the PDD's notion of `key', what would be the `key' of a matrix type ?
(I
At 07:05 PM 2/7/2001 +, David Mitchell wrote:
>Dan, before I followup your reply to my list of nits about the PDD,
>can I clarify one thing: destruction.
>
>I am assuming that many PMCs will require destruction, eg calling
>destroy() on a string PMC will cause the memory used by the string
>da
Dan, before I followup your reply to my list of nits about the PDD,
can I clarify one thing: destruction.
I am assuming that many PMCs will require destruction, eg calling
destroy() on a string PMC will cause the memory used by the string
data to be freed or whatever. Only very simple PMCs (such
> >I'm not either. They feel like they should be operators.
> >But I don't like the thought of going in and out of a lot of generic
> >routines for
> >
> >$a = 3;
> >$a += 2;
> >
> >when the integer scalar ought to know what the inside of another integer
> >scalar looks like, and that 2 + 3 doesn'
At 04:15 PM 2/7/2001 -0200, Branden wrote:
>David Mitchell wrote:
> >
> > Well, many of the vtable methods are operator-ish rather than value-ish,
> > presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> > have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> >
At 06:12 PM 2/7/2001 +, Nicholas Clark wrote:
>On Wed, Feb 07, 2001 at 05:54:14PM +, David Mitchell wrote:
> > Well, many of the vtable methods are operator-ish rather than value-ish,
> > presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> > have add(), concatenate() e
David Mitchell wrote:
>
> Well, many of the vtable methods are operator-ish rather than value-ish,
> presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> whether you are in favour of, or oppose, += etc being
On Wed, Feb 07, 2001 at 05:54:14PM +, David Mitchell wrote:
> Well, many of the vtable methods are operator-ish rather than value-ish,
> presumably on the grounds of efficiency. A pure 'value' vtable wouldnt
> have add(), concatenate() etc. Whihc leads me back to: I'm not sure
> whether you ar
Dan Sugalski wrote:
> At 03:09 PM 2/7/2001 +, David Mitchell wrote:
> >A mere detail, but would it not be more efficient to just pass them
> >as extra args, ie add(PMC1, PMC2, PMC3, key1, key2, key3),
> >rather than having to potentially create and populate a tmp struct
> >just to call the fun
> > > ++ and -- are already slightly messy in perl5
> > >
> > > pp_preinc, pp_postinc, pp_predec and pp_postdec live in with all the ops.
> > > They know how to increment and decrement integers that don't overflow,
> > > and call routines in sv.c to increment and decrement anything else.
> > >
>
At 03:09 PM 2/7/2001 +, David Mitchell wrote:
>Some comments about the vtable PDD...
>
>First a general comment. I think we really need to make it clear for
>each method, which arg respresents the object that is having its method
>called (ie which is $self/this so to speak). One way to make th
From: Tim Bunce [mailto:[EMAIL PROTECTED]]
>
> On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> >
> > At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> > >
> > > On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> > > >
> > > > =head2 Core datatypes
> > > >
> > > > For eas
On Wed, Feb 07, 2001 at 05:19:16PM +, David Mitchell wrote:
> Nicholas Clark <[EMAIL PROTECTED]> mused:
> > On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
> > > BTW, should the vtable include all the mutator operators too, ie
> > > ++, += and so on, on the grounds that an impl
Nicholas Clark <[EMAIL PROTECTED]> mused:
> On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
> > BTW, should the vtable include all the mutator operators too, ie
> > ++, += and so on, on the grounds that an implementation may be able
> > do this more efficiently internally?
>
> ++
Nicholas Clark wrote:
> ++ and -- are already slightly messy in perl5
>
> pp_preinc, pp_postinc, pp_predec and pp_postdec live in with all the ops.
> They know how to increment and decrement integers that don't overflow,
> and call routines in sv.c to increment and decrement anything else.
>
> Act
On Wed, Feb 07, 2001 at 04:03:49PM +, David Mitchell wrote:
> BTW, should the vtable include all the mutator operators too, ie
> ++, += and so on, on the grounds that an implementation may be able
> do this more efficiently internally?
++ and -- are already slightly messy in perl5
pp_preinc,
BTW, should the vtable include all the mutator operators too, ie
++, += and so on, on the grounds that an implementation may be able
do this more efficiently internally?
At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > >Please see my previous post on the subject. As I pointed there,
> implementing
> > >|| and && like that breaks short-circuits.
> >
> > No, it doesn't. Just because you pass in two PMCs doesn't mean that they
> > both need to be evaluated. Tho
> >Please see my previous post on the subject. As I pointed there, implementing
> >|| and && like that breaks short-circuits.
>
> No, it doesn't. Just because you pass in two PMCs doesn't mean that they
> both need to be evaluated. Though the PDD does need to be clearer about how
> that happens
Some comments about the vtable PDD...
First a general comment. I think we really need to make it clear for
each method, which arg respresents the object that is having its method
called (ie which is $self/this so to speak). One way to make this clear
would be to insist that the first arg is alway
On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> >[First off: I've not really been paying attention so forgive me if I'm
> >being dumb here. And many thanks for helping to drive this forwards.]
> >
> >On Mon, Feb 05, 2001 at 05:14:44PM
Branden wrote:
> Where can I find how Perl5's stack works (specially about parameter passing
> and returning from subs)?
Oh boy. What a masochist.
;-)
Alan Burlison
On Tue, Feb 06, 2001 at 05:21:03PM -0200, Branden wrote:
> Where can I find how Perl5's stack works (specially about parameter passing
> and returning from subs)?
4 steps:
1) Read the things I just mentioned.
2) Compile Perl with -DDEBUGGING, and run a very simple program with perl -Dts
3) Excha
Simon Cozens wrote:
> On Tue, Feb 06, 2001 at 05:01:38PM -0200, Branden wrote:
> > How is a list currently (Perl5) implemented?
>
> It's a bunch of SVs sitting on the stack, followed by a mark.
>
Where can I find how Perl5's stack works (specially about parameter passing
and returning from subs)?
On Tue, Feb 06, 2001 at 05:01:38PM -0200, Branden wrote:
> How is a list currently (Perl5) implemented?
It's a bunch of SVs sitting on the stack, followed by a mark.
> Which operations does it support?
None.
--
Rule the Empire through force.
-- Shogun Tokugawa
At 05:01 PM 2/6/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> > >Arrays and hashes should probably be at least mentioned here.
> >
> > And lists, yes. Or they need their own PDD with details.
> >
>
>What's the difference between array and list?
Dan Sugalski wrote:
> At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> >Arrays and hashes should probably be at least mentioned here.
>
> And lists, yes. Or they need their own PDD with details.
>
What's the difference between array and list? How is a list currently
(Perl5) implemented? Which opera
At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
>[First off: I've not really been paying attention so forgive me if I'm
>being dumb here. And many thanks for helping to drive this forwards.]
>
>On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> >
> > =head2 Core datatypes
> >
> > For ea
At 11:32 AM 2/6/2001 -0200, Branden wrote:
>Simon Cozens wrote:
> > > > =item logical_or
> > > > =item logical_and
> > > > =item logical_not
> > >
> > > Er, why not just use get_bool?
> >
> > Overloading.
> >
>
>Please see my previous post on the subject. As I pointed there, implementing
>|| and &
Simon Cozens wrote:
> > > =item logical_or
> > > =item logical_and
> > > =item logical_not
> >
> > Er, why not just use get_bool?
>
> Overloading.
>
Please see my previous post on the subject. As I pointed there, implementing
|| and && like that breaks short-circuits.
- Branden
On Tue, Feb 06, 2001 at 11:26:57AM +, Tim Bunce wrote:
> > =item UTF-32 string
> > =item Native string
> > =item Foreign string
>
> I'm a little surprised not to see UTF-8 there, but since I'm also
> confused about what Native string and Foreign string are I'll skip it.
"Native string encodi
Tim Bunce wrote:
> > =item move_to
> >
> >BOOL move_to(void *, PMC);
> >
> > Tells the PMC to move its contents to a block of memory starting at
> > the passed address. Used by the garbage collector to compact memory,
> > this call can return a false value if the move can't be done for some
>
[First off: I've not really been paying attention so forgive me if I'm
being dumb here. And many thanks for helping to drive this forwards.]
On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
>
> =head2 Core datatypes
>
> For ease of use, we define the following semi-abstract data t
Dan Sugalski wrote:
> Okay, here's the VTABLE PDD. Comments, please. (As if there's any worry
> about not having any :)
Hi, Dan.
I have a _very_ different view of yours on the vtable area. I read your PDD,
but I really couldn't figure out how the operations would be carried. For
instance, on
Okay, here's the VTABLE PDD. Comments, please. (As if there's any worry
about not having any :)
-Snip here--
=head1 TITLE
Common vtable format for all variables
=head1 VERSION
=head2 CURRENT
Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
Class: Internals
PDD Numbe
61 matches
Mail list logo
