Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> We currently have constant Key and Sub PMCs both created from the
>> packfile at load time. They live in the constant_table pointing to a
>> constant PMC pool. But we need more.
>>
>> We have allover the core code like thi
> can people please test, if the program below compiles cleanly now:
It doesn't. MSVC++ aint' happy when * is at back of a name.
> static const char PCONCAT(name,_cstring) * = cstring;
this
static const char *PCONCAT(name,_cstring) = cstring;
would be okay.
Juergen Boemmels wrote:
>
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >
> > > #define PARROT_DECLARE_STATIC_STRING(name, cstring) \
> >
> > [ big snip ]
> >
> > While Juergen's original or your proposal are fine, they don't work
> > (or not
Leopold Toetsch wrote:
>
> We currently have constant Key and Sub PMCs both created from the
> packfile at load time. They live in the constant_table pointing to a
> constant PMC pool. But we need more.
>
> We have allover the core code like this:
>
>string_from_cstring(interpreter, "pIt",
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> The issues WRT the union initializer are gone now (can people please
> test, if the program below compiles cleanly now) - but:
>
>
> - make_COW_* sets flag on the source string [1]
> - if that is solved (with a special RO flag, or whatever) we have:
The issues WRT the union initializer are gone now (can people please
test, if the program below compiles cleanly now) - but:
- make_COW_* sets flag on the source string [1]
- if that is solved (with a special RO flag, or whatever) we have:
- string_make sets a default type and encoding if these a
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> > #define PARROT_DECLARE_STATIC_STRING(name, cstring) \
>
> [ big snip ]
>
> While Juergen's original or your proposal are fine, they don't work
> (or not as proposed). First there are compiler issues
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> #define PARROT_DECLARE_STATIC_STRING(name, cstring) \
[ big snip ]
While Juergen's original or your proposal are fine, they don't work
(or not as proposed). First there are compiler issues:
$ gcc -Iinclude -Lblib/lib -lparrot -ldl -Wall -g bg.c &&
Juergen Boemmels wrote:
> Leopold Toetsch wrotes:
>
> > We currently have constant Key and Sub PMCs both created from the
> > packfile at load time. They live in the constant_table pointing to a
> > constant PMC pool. But we need more.
> >
> > We have allover the core code like this:
> >
> >st
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ snip ]
> * const_string_from_cstring - return cached constant string or create one
> * const_key_new_cstring - return cached PMC or create a constant PMC
Some more thoughts WRT this issue:
- PerlHash isn't suitable for storing/lookup these STRINGs/Key
Luke Palmer wrote:
Ok, so supposing this split happens, what would it look like? As in,
would there now be two vtables, one for variables and one for values?
Would it just be a logical split?
AFAIK we would have still one vtable divided into sub-structures. At
least the get/set_ methods would b
Leopold Toetsch writes:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > Could we split the vtable further, so var/value by read/write, which would
> > allow constant objects to swap their write vtable to a throw implementation.
> > Did I misread what you were suggesting either in this message or la
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 21, 2003 at 03:31:42PM +0200, Leopold Toetsch wrote:
>> When a PMC is shared it is either ro or rw - in all threads. I don't see
>> a problem here.
> I don't see a problem but I do see a possible optimisation.
> I can't remember if you were
On Thu, Aug 21, 2003 at 03:31:42PM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > I'm not sure if a simple read/write split also helps PMCs shared across
> > threads. Maybe sharing between threads is a whole new can of worms that we
> > should leave untouched for now
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 20, 2003 at 02:05:19PM +0200, Leopold Toetsch wrote:
>> This leads to changes in parsing the vtable.tbl - which we need anyway
>> to do the proposed var/value split of vtables.
>>
>> e.g.
>> [FETCH]
>> get_integer
>> ...
>> [STORE]
>> set_int
On Wed, Aug 20, 2003 at 02:05:19PM +0200, Leopold Toetsch wrote:
> This leads to changes in parsing the vtable.tbl - which we need anyway
> to do the proposed var/value split of vtables.
>
> e.g.
> [FETCH]
> get_integer
> ...
> [STORE]
> set_integer
> ...
> [PUSH]
> push_integer
> ...
> and so o
[
The listserver does not like my attachments
ezmlm-send: fatal: Sorry, after removing unacceptable MIME parts from your message I
was left with nothing (#5.7.0)
ezmlm-gate: fatal: fatal error from child
Here is the resend with code inline
]
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Leopold Toetsch:
# The property 'constant', 'ro' or whatever can only be some kind of
# communication: the HLL is telling the PMC to be read only. We could
now
# have in each set-like vtable:
#
#if (we_have_props && !is_bool(prop("ro")) // pseudo code
# set_the_value ...
#else
#
Brent Dax wrote:
Leopold Toetsch:
# The property 'constant', 'ro' or whatever can only be some kind of
# communication: the HLL is telling the PMC to be read only. We could
now
# have in each set-like vtable:
#
#if (we_have_props && !is_bool(prop("ro")) // pseudo code
# set_the_value ..
Brent Dax wrote:
Leopold Toetsch:
# Further we would need for some classes a Const$Class variant, where
the
# set-like vtables throw an exception. These classes should be
# autogenerated from *.pmc for all classes that have a "const_too" or
such
# in their classes $flags.
Isn't The Plan(tm) to use
Leopold Toetsch:
# Further we would need for some classes a Const$Class variant, where
the
# set-like vtables throw an exception. These classes should be
# autogenerated from *.pmc for all classes that have a "const_too" or
such
# in their classes $flags.
Isn't The Plan(tm) to use properties for t
We currently have constant Key and Sub PMCs both created from the
packfile at load time. They live in the constant_table pointing to a
constant PMC pool. But we need more.
We have allover the core code like this:
string_from_cstring(interpreter, "pIt", 0)
key = key_new_cstring(interpreter,
22 matches
Mail list logo
