On Tue, Nov 20, 2001 at 03:56:15PM +, Dave Mitchell wrote:
> My bluff has been called!
> Okay, here's a stab at it. I'm keen that we use enums to define constants,
> rather than using #define.
Nice work. Thanks, applied.
--
teco < /dev/audio
- Ignatios Souvatzis
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2001 at 03:29:00PM +, Dave Mitchell wrote:
> > I'd prefer the "you have 8 private bits, the rest is Parrot's" approach
> > rather than the "Parrot has 8 bits and the rest is yours for now, we'll
> > let you know when we want to grab som
[EMAIL PROTECTED] wrote:
> > There is. You can't necessarily convert on the fly - perl5 allows
> > dual-typed SVs where the string and number aren't necessarily
> > interchangable versions of each other.
>
> Ahem, I was asking about int and num, not num and string :-)
Oops - so you were. Soz!
At 03:29 PM 11/19/2001 +, Dave Mitchell wrote:
>Hmmm - of course, once Parrot is out there in the wild with the equivalent
>of XS vtables, we won't have the luxury of recompiling.
Then we'll need to abstract that out somehow so we can do it if we need to...
On Mon, Nov 19, 2001 at 03:29:00PM +, Dave Mitchell wrote:
> I'd prefer the "you have 8 private bits, the rest is Parrot's" approach
> rather than the "Parrot has 8 bits and the rest is yours for now, we'll
> let you know when we want to grab some more back off you" approach. I think
> that wa
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2001 at 10:58:55AM +, Dave Mitchell wrote:
> > Presumably we should have a small, *fixed* number of private bits in
> > the flags word available for use by vtable implementors (ie to stop
> > people getting carried away with the notion
On Mon, Nov 19, 2001 at 10:58:55AM +, Dave Mitchell wrote:
> Presumably we should have a small, *fixed* number of private bits in
> the flags word available for use by vtable implementors (ie to stop
> people getting carried away with the notion that they can steal any
> bits which do not othe
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >I'm saying that classes can have user-defined flags, to save a
> >dereference. Or at least, I'm saying that until Dan wanders over
> >here and persuades me it's a bad idea. :)
>
> Dan thinks its a very good idea. :) Almost anything that potentially saves
ason Gloudon <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 17, 2001 at 02:22:44PM +, [EMAIL PROTECTED] wrote:
> > Alan Burlison <[EMAIL PROTECTED]> wrote:
> > > Dave Mitchell wrote:
> > > > * Is there ever any need to for a PMC type which holds both an int and
> > > > a
> > > > num? In the Perl 5 c
At 01:24 PM 11/16/2001 +, Dave Mitchell wrote:
>* I think that the cache of a PMC ought to be more flexible, eg replace
>
> DPOINTER *data;
> union {
> INTVAL int_val;
> FLOATVAL num_val;
> DPOINTER *struct_val;
> } cache;
>
>with something like
>
> union {
> INTVAL int
At 08:10 PM 11/15/2001 +, Simon Cozens wrote:
>On Thu, Nov 15, 2001 at 02:58:58PM -0500, Michael L Maraist wrote:
> > Why are you storing flags for PerlScalarData inside the pmc-flags?
>
>I'm saying that classes can have user-defined flags, to save a
>dereference. Or at least, I'm saying that
On Sat, Nov 17, 2001 at 02:22:44PM +, [EMAIL PROTECTED] wrote:
> Alan Burlison <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > * Is there ever any need to for a PMC type which holds both an int and
> > > a
> > > num? In the Perl 5 case we were constrained by code that expected to
> >
Alan Burlison <[EMAIL PROTECTED]> wrote:
> Dave Mitchell wrote:
> > * Is there ever any need to for a PMC type which holds both an int and
> > a
> > num? In the Perl 5 case we were constrained by code that expected to
> > always
> > find an int (or a num) in a fixed slot in the SV; with PMCs, all
Dave Mitchell wrote:
> * Is there ever any need to for a PMC type which holds both an int and a
> num? In the Perl 5 case we were constrained by code that expected to always
> find an int (or a num) in a fixed slot in the SV; with PMCs, all access
> to these slots is via methods, so an int-num or
On Fri, Nov 16, 2001 at 09:59:23AM -0800, Larry Wall wrote:
> I think that as soon as the concept of a cache starts producing bit flags
> and unions and cascaded if/then/elses, it's probably a bad concept.
It doesn't; once I've finished the reworking, then a PMC that has a
PerlInteger vtable will
Dan Sugalski writes:
: At 06:52 PM 11/15/2001 +, Simon Cozens wrote:
: >I've hit upon quite a major problem with implementing
: >Perl scalar PMCs. The problem is that the code is just
: >too damned ugly for words.
: >
: >Remember that PMCs have a data area which is a void
: >pointer; I'm conne
A few comments.
* Is there ever any need to for a PMC type which holds both an int and a
num? In the Perl 5 case we were constrained by code that expected to always
find an int (or a num) in a fixed slot in the SV; with PMCs, all access
to these slots is via methods, so an int-num or num-int conv
>
>As a last sort of alternative. I had invisioned PMC's has having separate
>vtables for each of the many different types of operations. Meaning, that
a
>scalar-int would be separate from a scalar-string-num, etc. Since it seems
>that we're not currently doing this, it would require 8 times as
On Thu, Nov 15, 2001 at 05:02:52PM -0500, Uri Guttman wrote:
> that is starting to look okay now.
Yes, it's starting to look quite like what I've had in CVS for
the past couple of hours. :)
--
luckily, my toes have no trailing newline characters
> "BD" == Brent Dax <[EMAIL PROTECTED]> writes:
BD> static INTVAL
BD> Parrot_scalar_get_integer(struct Parrot_Interp* interpreter, PMC* pmc) {
BD> PSD* sd=(PSD*)pmc->data;
BD> if(FLAG_pmc_iok_TEST(pmc)) {
BD> return sd->intdata;
BD> }
BD> FLAG_pmc_iok_SET(pmc
Brent Dax:
# Simon Cozens:
# # I've hit upon quite a major problem with implementing
# # Perl scalar PMCs. The problem is that the code is just
# # too damned ugly for words.
# #
# # Remember that PMCs have a data area which is a void
# # pointer; I'm connecting that to a structure which has
# # i
Simon Cozens:
# I've hit upon quite a major problem with implementing
# Perl scalar PMCs. The problem is that the code is just
# too damned ugly for words.
#
# Remember that PMCs have a data area which is a void
# pointer; I'm connecting that to a structure which has
# integer, number and string s
In message <[EMAIL PROTECTED]>
Michael L Maraist <[EMAIL PROTECTED]> wrote:
> inlined c-functions.. Hmm, gcc has some support for this, but what about
> other archectures.. For function-inlining to work with GCC, you have to
> define the function in the header.. That's definately not po
On Thu, Nov 15, 2001 at 02:58:58PM -0500, Michael L Maraist wrote:
> Combining these two, I have a couple comments.
Take a peek at the code that's in CVS now and see if it's OK with
your aesthetic sentiments. :)
> Why are you storing flags for PerlScalarData inside the pmc-flags?
I'm saying th
On Thursday 15 November 2001 02:11 pm, James Mastros wrote:
> I don't see doing it with a macro as too bad, so long as the macro is
> decently localized. (If you don't like macros because of their
> preprocessor nature, use a function; it should inline just fine.) And it
> seems like it would be
Combining these two, I have a couple comments.
On Thursday 15 November 2001 02:07 pm, Simon Cozens wrote:
> if (pmc->flags & PS_INTEGER_OK) {
> return ((struct PerlScalarData *)(pmc->data))->intdata;
Why are you storing flags for PerlScalarData inside the pmc-flags? If the
nested type i
On Thu, Nov 15, 2001 at 07:34:52PM +, Simon Cozens wrote:
> Thanks to Andy Doughtery for the obvious and beautiful solution:
s/ter/ert/
--
It's much better to have people flaming in the flesh. -Al Aho
On Thu, Nov 15, 2001 at 06:52:11PM +, Simon Cozens wrote:
> I've hit upon quite a major problem with implementing
> Perl scalar PMCs. The problem is that the code is just
> too damned ugly for words.
Thanks to Andy Doughtery for the obvious and beautiful solution:
USE SOME FREAKING TEMPORARY
At 07:07 PM 11/15/2001 +, Simon Cozens wrote:
>On Thu, Nov 15, 2001 at 02:01:53PM -0500, Dan Sugalski wrote:
> > *) Use the cache entry in the PMC header. It'll mean for ints and floats
> > you won't need to bother with a separate structure or dereference
>
>I can't. :(
>
>/* It's more efficie
On Thu, 15 Nov 2001, Simon Cozens wrote:
> Remember that PMCs have a data area which is a void
> pointer; I'm connecting that to a structure which has
> integer, number and string slots. Those of you familiar
> with Perl SVs will know exactly where I'm coming from.
Umm, I'm not sure /how much/ bet
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> So, for instance, the method to get an integer value
SC> ends up looking like this:
SC> static INTVAL Parrot_scalar_get_integer (struct Parrot_Interp *interpreter, PMC*
pmc) {
SC> if (pmc->flags & PS_INTEGER_OK) {
SC>
On Thu, Nov 15, 2001 at 02:01:53PM -0500, Dan Sugalski wrote:
> *) Use the cache entry in the PMC header. It'll mean for ints and floats
> you won't need to bother with a separate structure or dereference
I can't. :(
/* It's more efficient to use our own caching than the PMC's cache
Why? Bec
At 06:52 PM 11/15/2001 +, Simon Cozens wrote:
>I've hit upon quite a major problem with implementing
>Perl scalar PMCs. The problem is that the code is just
>too damned ugly for words.
>
>Remember that PMCs have a data area which is a void
>pointer; I'm connecting that to a structure which has
33 matches
Mail list logo
