I am currently stuck because I get the error parrot: src/string.c:269: string_init: Assertion `p' failed. on the second string_init of a parrot run using the last vanilla cvs
It may be a problem with mandrake cooker. Jérôme Quelin uses a older mandrake cooker and it works there. Comparing our config, it seems that the main difference is he got: set P0["buildicu"], "1" and I have: set P0["buildicu"], "0" in config_lib.pasm I have yet to check further. So I may imprecise in my answers because I can't currently run tests. Also, I should have put a disclaimer, many pmc methods are still missing. This is an early submission to get feedback. On Sun, Oct 24, 2004 at 12:58:48PM +0200, Leopold Toetsch wrote: > Stephane Payrard <[EMAIL PROTECTED]> wrote: > > Siva is a type that acts as a hash, array , string scalar, int > > scalar. It is intended as the type for nodes of attributed trees > > These attributed trees may probably be of various kinds such as > > parse trees and XML trees. The intensive use of context should > > minimize explicit structure walking. > > > Hashes and arrays are allocated only when needed. I meant for a given pmc, the hash, array, or string that it may contain is allocated only when necessary. > > > I have a problem with siva.t. The pasm code is the same as > > siva.pasm though. > > What problem? Apparently, there is a problem in the reading of siva.so. I did not yet check how Parrot::Test run that makes the parrot run differently than running directly parrot dynclasses/siva.pasm siva.t must be updated anyway to reflect that I made siva a dynamically loaded pmc. > > > +/* rhs and lhs versions needed to avoid the msg "warning: use of cast expressions > > as lvalues is deprecated" > > Have a look at LVALUE_CAST() > > > +#define siva_hash(a) ((siva*) PMC_pmc_val(a))->hash > > > +#define siva_str(a) ((siva*) PMC_pmc_val(a))->s > > What happens, if I create a hash and extract a string? Should work. They live in different fields of the siva struct. At this point my tests in siva.pasm were just that: toverify that the different structures are correctly allocated and that they don't overlap. -- stef > > > leo >