[perl #16926] [PATCH] unused static decl. in headers.h
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16926]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16926 >
Hi,
these static functions are
- never used
- produce ugly warnings with -Wall, which implies
- use -Wno-unsed
- which may hide over orphaned code
Same applies for buffer_lives() in dod.h.
Could this function go somewhere else, or be a #define?
leo
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36304/29342/5fefec/headers.h.diff
--- headers.h Fri Aug 23 11:37:01 2002
+++ /home/lt/src/parrot-leo/include/parrot/headers.hMon Sep 2 10:05:20 2002
@@ -19,20 +19,6 @@
#define BUFFER_ALIGNMENT 16
#define STRING_ALIGNMENT 4
-
-static void *
-get_from_free_pool(struct Parrot_Interp *interpreter,
- struct Small_Object_Pool *pool)
-{
-return (*pool->get_free_object)(interpreter, pool);
-}
-static void
-add_to_free_pool(struct Parrot_Interp *interpreter,
- struct Small_Object_Pool *pool, void* to_free)
-{
-(*pool->add_free_object)(interpreter, pool, to_free);
-}
-
/** Header Management Functions **/
/* pmc header small-object methods */
Iterator.pmc (was: set_p_p)
Mattia Barbon wrote:
>> set P1, P0 # tells P1 that he's going to iterate P0
>
> This looks like a kludge. IMHO the correct way of getting an iterator
> is having the aggregate return it (say, using find_method/invoke);
that's a correct assumption, and when find_method/invoke will be
implemented, there will be something like that. but this doesn't
change much in the Iterator implementation. it will be just another
way (probably the preferred one) to get an Iterator.
either way, the PASM language is not intended for humans(*), doesn't
strive for inner elegance and perfect orthogonality, so kludges are
legal as long as they gain us speed :-)
(*) read: it is not intended to be something you will have fun(**)
programming in, there's Perl for this.
(**) but then, there are people actually having fun programming in
Befunge, so this statement could not apply at all :-)
> and the iterator does not need to be of class Iterator, it just needs
> to behave like one. Otherwise your Iterator needs to know all the
> types it has to iterate over, which is bad.
that's not the case. the Iterator *need* to be of class Iterator, as
I'm going to demonstrate. as I implemented it, it actually doesn't need
to know all the types it has to iterate over, as I'm going to show.
on the other hand, the current Iterator PMC does not actually
*implement* an iterator, but in some sense it behaves like one. it's
the aggregate itself that needs to implement the methods to iterate
its own data structure, so what you say is partly correct.
the design of Iterator.pmc has the following objectives:
1. provide an abstract (read: aggregate-independant) interface to
iterate an aggregate
2. provide an object that is external to the aggregate, so that
one aggregate can have multiple iterators
point 1. is accomplished through vtable entries. the aggregate
should implement the following functions for Iterator to work:
INTVAL iterator_sizeof()
void iterator_reset()
void iterator_set(void *data)
void iterator_get(void *data)
PMC* iterator_get_current()
void iterator_next();
once an Iterator is "assigned" to an aggregate PMC, it calls its
iterator_sizeof() method.
INTVAL iterator_sizeof()
this should return the amount of memory required to store and mantain
iterator state information. for example, iterating an Array only
requires an INTVAL (the current index in the array), so sizeof(INTVAL)
will be returned. iterating an Hash requires two values (the bucket
chain index and a pointer to the current HashBucket, but these are
details), so PerlHash's iterator_sizeof() will return
sizeof(HashIndex) + sizeof(HASHBUCKET*). the Iterator PMC allocates
the proper amount of memory so that it can mantain its own state
information (see point 2.).
void iterator_set(void *data)
this sets the aggregate's iterator state to the given "data", eg. the
amount of memory allocated with iterator_sizeof().
void iterator_get(void *data)
this gets the aggregate's iterator state so that the Iterator PMC can
update its own "data".
PMC* iterator_get_current()
void iterator_reset()
void iterator_next()
these are the methods that actually does the iteration.
as you can see, all the iteration stuff is done by the aggregate
PMC class itself. the Iterator PMC provides opcode mapping for
its action (eg. inc for next, etc.), as well as storage for its
own state. this way, an aggregate (which really does the iteration)
does not need to mantain such information for multiple iterators.
it only needs to receive the relevant information from the Iterator
who's currently acting on the aggregate.
the iterator updates its own memory from the aggregate on each
operation, as the following pseudocode shows (hope it's clear :-):
reset {
AGGREGATE->iterator_reset()
ITERATOR->data = AGGREGATE->iterator_get()
}
next {
AGGREGATE->iterator_set(ITERATOR->data)
AGGREGATE->iterator_next()
ITERATOR->data = AGGREGATE->iterator_get()
}
get_current {
AGGREGATE->iterator_set(ITERATOR->data)
return AGGREGATE->iterator_get_current
}
this accomplishes point 2. and shows why Iterator needs to be a class
of its own.
the implementation could surely be improved, and it certainly need
to(*), but I hope the design does make some sense :-)
(*) just to make an example, this approach is absolutely not
thread-safe.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Goal call for 0.0.9
Here's a call for potential goals for the 0.0.9 release of parrot. My list: *) Exceptions *) initial PMC freeze/thaw API *) Sub indicators in bytecode *) On-the-fly bytecode section generation Anyone got any others? We can get the list together and then prioritize from there. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #16931] [PATCH] minor updates
# New Ticket Created by Josef Höök
# Please include the string: [perl #16931]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16931 >
Some minor updates on multiarray
/josef
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36326/29355/79861a/multiarray_20020901.patch
--- multiarray.pmc.orig Sun Sep 1 20:32:13 2002
+++ multiarray.pmc Sun Sep 1 21:08:55 2002
@@ -10,7 +10,7 @@
* (y-1)X0+x
*
* Where X0 is the length of X-base (fig 1.1). We use this equation in
- * calc_offset to get offset from the buffer we store our data in.
+ * calc_offset_multi to get offset from the buffer we store our data in.
* Lets say we want to store (2,2) in a buffer. We then take values and do:
* (2-1)3 + 2 = 5.
*
@@ -36,12 +36,12 @@
* Current code has complexity:
*
*O(1) writing.
- *O(1) reading.
+ *O(?) reading.
* History:
- *Initial revision by Josef HËËk
+ *Initial revision by Josef Hook <[EMAIL PROTECTED]>
* Notes:
- *Future plan is to make calc_offset_multi polymorphic
- *and to make it handle multidimensions: done
+ *Future plan is to handle multidimensions: done
+ *Move code into vtable functions:
* References:
*/
@@ -130,6 +130,7 @@
prod_of_dims *= key_integer(interpreter, dim_key);
dim_key = key_next(interpreter, dim_key);
inner_loop_i--;
+
}
offset += key_integer(interpreter, my_key) * prod_of_dims;
@@ -141,6 +142,7 @@
/* only 1 dim */
offset = key_integer(interpreter, k);
}
+
return offset;
}
@@ -217,20 +219,20 @@
oldkey = key;
size = 1;
-
while (key_next(interpreter, key) != NULL) {
-
- size *= key_integer(interpreter, key);
- key = key_next(interpreter, key);
-
+
+size *= key_integer(interpreter, key);
+key = key_next(interpreter, key);
+
}
+
marray->size = size;
marray->free_cell = size;
Parrot_reallocate(interpreter, marray->cell_buffer, marray->size * sizeof(CELL));
memset(marray->cell_buffer->bufstart, 0, marray->size * sizeof(CELL));
marray->dimension = oldkey;
-
+
}
@@ -245,6 +247,10 @@
INTVAL offs = 0;
INTVAL ret_val = 0;
+INTVAL dead_val = 0;
+INTVAL my_val = 0;
+INTVAL iterate_count = 0;
+
offs = calc_offset_multi(interpreter, mg_marray, key);
base = (CELL *)mg_marray->cell_buffer->bufstart;
@@ -261,7 +267,48 @@
if(virtual_addr == buffer_ptr_virt) {
ret_val = buffer_ptr->data.int_val;
} else {
- /* PANIC */
+ /* OK here's the deal. We should never come to this point BUT if we have
+* something must have happened to our cell buffer. Code below is
+* a cut-paste from my matrix code though structures differs
+ * it should work anyway. TODO: verify its validity
+ */
+
+ dead_val = buffer_ptr->virtual_addr; // save our begin value
+ while(buffer_ptr->virtual_addr != offs && (buffer_ptr != NULL)) {
+
+ /* my_val = (offs - (buffer_ptr->sparse_offset)); */
+ my_val = (offs);
+/* outside rand we dont have any value to collect */
+ if(my_val < 0) {
+ ret_val = 0;
+ break;
+ }
+/* outside rand we dont have any value to collect */
+ if(my_val > buffer_ptr->virtual_addr) {
+ ret_val = 0;
+ break;
+ }
+/* possible deadlock should never occur */
+ if(iterate_count > 10) {
+ printf("AAYIE: possible deadlock in
+get_matrix_keyed(), recovering\n");
+ ret_val = 0;
+ break;
+ }
+/* do some walking among our cells */
+ buffer_ptr = &base[my_val];
+ /*
+ * if true we have walked our way around
+ * which means no value to collect
+ */
+ if(buffer_ptr->virtual_addr == dead_val) {
+ ret_val = 0;
+ break;
+ }
+ ret_val = buffer_ptr->data.int_val;
+ iterate_count += 1;
+ }
+
[perl #16932] ScanMail Message: To Sender, action taken by attachment blocking.
# New Ticket Created by System Attendant # Please include the string: [perl #16932] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16932 > ScanMail for Microsoft Exchange has blocked a file attachment(s). Place = [EMAIL PROTECTED] Sender = Josef "Hvvk Subject = [perl #16931] [PATCH] minor updates Delivery Time = September 02, 2002 (Monday) 10:09:59 Action on file attachment(s): Quarantine 'multiarray_20020901.patch' to C:\Program Files\Trend\Smex\blocked_attachments at Marc Belgrave Message from recipient's administrator: As part of Algorithmics Security Policy on e-mail, this attachment has been blocked from entering our mail system. The attachment name can be found in this message. For Algorithmics Employees who require more information on how to send and receive e-mail with attachments, please refer to the following: http://algoweb/it/docs/documentation/virus-faq.html . For people external to Algorithmics, please contact the intended recipient for further informaton.
[perl #16933] [PATCH] new pmc function
# New Ticket Created by Josef Höök
# Please include the string: [perl #16933]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16933 >
Added a new pmc function that is used for passing inital sizes to pmcs.
There was an old function called pmc_new_sized but it seemed that it was
outdated so i replaced it.
/Josef
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36329/29359/d1db20/pmc.20020830.patch
--- pmc.c.orig Fri Aug 30 22:11:08 2002
+++ pmc.c Fri Aug 30 22:10:47 2002
@@ -8,6 +8,7 @@
* See include/parrot/vtable.h.
* History:
* Initial version by Simon on 2001.10.20
+ * Added pmc_new_pmc function. Josef 2002-08-30
* Notes:
* References:
* <[EMAIL PROTECTED]>
@@ -87,15 +88,16 @@
return pmc;
}
-/*=for api pmc pmc_new_sized
+/*=for api pmc pmc_new_pmc
- As C, but passes C to the PMC's C method.
+ As C, but passes a C to the PMC's C method,
+ used when passing sizes to pmc.
=cut
*/
PMC *
-pmc_new_sized(struct Parrot_Interp *interpreter, INTVAL base_type, INTVAL size)
+pmc_new_pmc(struct Parrot_Interp *interpreter, INTVAL base_type, PMC *p)
{
PMC *pmc = new_pmc_header(interpreter);
@@ -115,8 +117,7 @@
return NULL;
}
-/* XXX - pmc->vtable->init(interpreter, pmc, size); */
-pmc->vtable->init(interpreter, pmc);
+pmc->vtable->init_pmc(interpreter, pmc, p);
return pmc;
}
--- include/parrot/pmc.h.orig Fri Aug 30 22:12:31 2002
+++ include/parrot/pmc.hFri Aug 30 22:08:50 2002
@@ -118,10 +118,8 @@
/* Prototypes */
PMC *pmc_new(struct Parrot_Interp *interpreter, INTVAL base_type);
PMC *pmc_new_noinit(struct Parrot_Interp *interpreter, INTVAL base_type);
-PMC *pmc_new_sized(struct Parrot_Interp *interpreter, INTVAL base_type,
-INTVAL size);
-PMC *pmc_new_sized_pmc(struct Parrot_Interp *interpreter, INTVAL base_type,
- PMC *p);
+PMC *pmc_new_pmc(struct Parrot_Interp *interpreter, INTVAL base_type, PMC *p);
+
#endif
[perl #16934] [PATCH] new opses
# New Ticket Created by Josef Höök
# Please include the string: [perl #16934]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16934 >
Added 2 new opses into core.ops that handles this code:
new P0, .MultiArray[2;2;2]
and
new P0, .Multiarray[2]
I also changed new (out PMC, in INT, in INT). It now creates a perlint and
calls pmc_new_pmc (in pmc.c)
/Josef
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36331/29362/dc823d/core_ops.20020830.patch
--- core.ops.orig Fri Aug 30 21:57:23 2002
+++ core.opsFri Aug 30 21:56:55 2002
@@ -3806,6 +3806,10 @@
=item B(out PMC, in INT, in INT)
+=item B(out PMC, in INT, in INTKEY)
+
+=item B(out PMC, in INT, in KEY)
+
Create a new PMC of class $2; look in F for the base
vtable types. The assembler allows you to specify PMCs by type
name as well as by integer - you should do this for compatibility,
@@ -3818,6 +3822,10 @@
new P0, .PerlStruct, 64
+or
+
+ new P0, MultiArray[2;2;2]
+
=cut
op new(out PMC, in INT) {
@@ -3835,10 +3843,39 @@
op new(out PMC, in INT, in INT) {
PMC* newpmc;
+ PMC* new_int_pmc;
+ if ($2 <0 || $2 >= enum_class_max) {
+abort(); /* Deserve to lose */
+ }
+ /* use a perlint pmc as a wrapper to pass the size to $1 pmc */
+ new_int_pmc = pmc_new(interpreter, enum_class_PerlInt);
+ new_int_pmc->vtable->set_integer_native(interpreter, new_int_pmc, $3);
+ newpmc = pmc_new_pmc(interpreter, $2, new_int_pmc);
+ $1 = newpmc;
+ goto NEXT();
+}
+
+op new(out PMC, in INT, in INTKEY) {
+ PMC* newpmc;
+ PMC* new_key_pmc;
+ INTVAL key = $3;
+ if ($2 <0 || $2 >= enum_class_max) {
+abort(); /* Deserve to lose */
+ }
+ /* use a key pmc as a wrapper to pass the size to $1 pmc */
+ new_key_pmc = pmc_new(interpreter, enum_class_Key);
+ new_key_pmc->vtable->set_integer_native(interpreter, new_key_pmc, key);
+ newpmc = pmc_new_pmc(interpreter, $2, new_key_pmc);
+ $1 = newpmc;
+ goto NEXT();
+}
+
+op new(out PMC, in INT, in KEY) {
+ PMC* newpmc;
if ($2 <0 || $2 >= enum_class_max) {
abort(); /* Deserve to lose */
}
- newpmc = pmc_new_sized(interpreter, $2, $3);
+ newpmc = pmc_new_pmc(interpreter, $2, $3);
$1 = newpmc;
goto NEXT();
}
[BUG] strange key behaviour
I've discovered a "feature" when using the new key implementation.
It seems that key_next function dosent walk down the chain of keyes like
the old key->next pointer did.
I've managed to reproduce this behaviour many times.
Consider this pasm code:
new P0, .MultiArray[2;3;2;1;1;1]
set P0[0;0;0], 1
set P0[0;0;1], 2
set P0[0;1;0], 3
set I0, P0[0;0;0]
print I0
print "\n"
set I0, P0[0;0;1]
print I0
print "\n"
set I0, P0[0;1;0]
print I0
print "\n"
end
produces this output:
init_marray key size is 3
key_next is 814bb60
init_marray key size is 2
key_next is 814bb44
init_marray key size is 1
key_next is 814bb28
init_marray key size is 1
key_next is 814bb0c
1
5
3
As you can see above the while loop in multiarray below only iterates
4 times when it should iterate 6 times ( .MultiArray[2;3;2;1;1;1] ).
The same happens when i define a 3 dim array .MultiArray[2;2;2]
it only iterate 1 time. This means that key_next(interpreter,key)
always loose 2 keyes.
multiarray.pmc:
while (key_next(interpreter, key) != NULL) {
printf("init_marray key size is %d\n", key_integer(interpreter, key));
printf("key_next is %x\n", key_next(interpreter, key));
size *= key_integer(interpreter, key);
key = key_next(interpreter, key);
}
Tom is this a know problem?
/Josef
Re: [BUG] strange key behaviour
In message <[EMAIL PROTECTED]>
Josef Hook <[EMAIL PROTECTED]> wrote:
> As you can see above the while loop in multiarray below only iterates
> 4 times when it should iterate 6 times ( .MultiArray[2;3;2;1;1;1] ).
> The same happens when i define a 3 dim array .MultiArray[2;2;2]
> it only iterate 1 time. This means that key_next(interpreter,key)
> always loose 2 keyes.
>
> multiarray.pmc:
>
> while (key_next(interpreter, key) != NULL) {
> printf("init_marray key size is %d\n", key_integer(interpreter, key));
> printf("key_next is %x\n", key_next(interpreter, key));
> size *= key_integer(interpreter, key);
> key = key_next(interpreter, key);
>
> }
This loop stops as soon as key_next() becomes NULL which means that
you never process the last key component. I would guess that you want
to make the first line into this:
while (key != NULL) {
That explains why you are not seeing the last component. You are also
missing the first one for some reason. The most likely cause would be
that you have already used key_next to discard the first component
before you reached this loop but I can't tell for sure from that code
fragment.
Tom
--
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu
Re: [BUG] strange key behaviour
On 2 Sep 2002, Tom Hughes wrote:
> This loop stops as soon as key_next() becomes NULL which means that
> you never process the last key component. I would guess that you want
> to make the first line into this:
>
> while (key != NULL) {
what can i say. OOPS :-)
/j
Re: [BUG] strange key behaviour
In message <[EMAIL PROTECTED]> Tom Hughes <[EMAIL PROTECTED]> wrote: > That explains why you are not seeing the last component. You are also > missing the first one for some reason. The most likely cause would be > that you have already used key_next to discard the first component > before you reached this loop but I can't tell for sure from that code > fragment. I've just seen the patch you sent, and I can now explain the other problem - you are passing initializer->data to the function which effectively discards the first element as the data member of a Key PMC is the pointer to the next component. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu
Re: [BUG] strange key behaviour
On 2 Sep 2002, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > Tom Hughes <[EMAIL PROTECTED]> wrote: > > > That explains why you are not seeing the last component. You are also > > missing the first one for some reason. The most likely cause would be > > that you have already used key_next to discard the first component > > before you reached this loop but I can't tell for sure from that code > > fragment. > > I've just seen the patch you sent, and I can now explain the > other problem - you are passing initializer->data to the function > which effectively discards the first element as the data member > of a Key PMC is the pointer to the next component. Aaa.. Thanks! i would never have found the bug myself. /josef > > Tom > > -- > Tom Hughes ([EMAIL PROTECTED]) > http://www.compton.nu >
Re: Goal call for 0.0.9
On Mon, 2 Sep 2002, Dan Sugalski wrote: > Here's a call for potential goals for the 0.0.9 release of parrot. My list: > > *) Exceptions > *) initial PMC freeze/thaw API > *) Sub indicators in bytecode > *) On-the-fly bytecode section generation *) methods (in PASM and C) *) implementation of some methods for the Perl classes *) stashes /s
approximate string matching in regexes
Edit distance is a measure of the number of edits required to turn one string into another, basically the size of a character-by-character "diff". For example, the edit distance between "aches" and "access" is one change and one insert: aches acCes accesS Depending on how you define the costs of edit operations, this could either cost 2 (one for the change and one for the insert) or 3 (the change counts as a delete followed by an insert). Edit distance can be used for approximate string matching, by saying that one string "equals" another if the edit distance between the two strings is less than some threshhold. Approximate matching cannot be done with regular expressions short of making an alternation consisting of all possible alternatives withing a given distance. Using an edit distance algorithm, it can be done in O(nm) time and space, where n and m are the lengths of the two strings to be compared. When matching a pattern against a substring of a text this becomes O(n^2), where n is the pattern length. Since it solves a common class of pattern-matching problems not addressed by regexes or grammars, I think this would make a valuable addition to the Parrot regex engine. I propose something along the following lines: rx_amatch Sx, Ix, Sy, Nx Do an approximate match of Sy against Sx at Ix with maximum edit distance floor(Nx * length(Sy)). Push a mark, then the end positions of the approximate matches, onto the regex stack, with the closest match on top. Using this op, matching "/[:approx(0.3) aches] s/" against a substring of "access" at position 0 would be turned into Parrot bytecode like so: set S0, "access" set S1, "aches" set I0, 0 rx_amatch S0, I0, S1, 0.3 next_amatch: rx_popindex I0, fail rx_literal S0, I0, "s", next_amatch branch succ fail: print "no " succ: print "match\n" I attached an implementation of this op. Comments welcome. /s amatch.tgz Description: Binary data
[perl #16935] [PATCH] more regex stack manipulation
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #16935]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16935 >
This adds the following two regex ops:
rx_stackdepth Ix -- Store the size of the regex stack in Ix
rx_stackchop Ix -- shorten the regex stack to have Ix entries
I found these useful in implementing explicit backtracking control, and
much better than the alternative, a bytecode loop popping entries and
counting marks.
Steve, others: do you find these useful?
/s
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/36335/29365/24afcb/stacks.patch
Index: rx.ops
===
RCS file: /cvs/public/parrot/rx.ops,v
retrieving revision 1.30
diff -p -u -w -r1.30 rx.ops
--- rx.ops 25 Aug 2002 00:20:22 - 1.30
+++ rx.ops 2 Sep 2002 15:51:14 -
@@ -209,6 +209,17 @@ op rx_clearstack () {
intstack_free(interpreter, interpreter->ctx.intstack);
goto NEXT();
}
+
+op rx_stackdepth (out int) {
+ $1 = intstack_depth(interpreter, interpreter->ctx.intstack);
+ goto NEXT();
+}
+
+op rx_stackchop (in int) {
+ intstack_chop(interpreter, interpreter->ctx.intstack, $1);
+ goto NEXT();
+}
+
=item C(in pmc)
Index: rxstacks.c
===
RCS file: /cvs/public/parrot/rxstacks.c,v
retrieving revision 1.8
diff -p -u -w -r1.8 rxstacks.c
--- rxstacks.c 22 Aug 2002 20:08:24 - 1.8
+++ rxstacks.c 2 Sep 2002 15:51:14 -
@@ -101,6 +101,27 @@ intstack_pop(struct Parrot_Interp *inter
return entry->value;
}
+void intstack_chop (struct Parrot_Interp *interpreter, IntStack stack,
+INTVAL n)
+{
+INTVAL depth = intstack_depth(interpreter, stack);
+IntStack_Chunk chunk = stack->prev;
+IntStack_Entry entry;
+
+if (depth < n) {
+internal_exception(ERROR_STACK_EMPTY, "popn: stack underflow\n");
+}
+while (depth - chunk->used > n) {
+depth -= chunk->used;
+if (chunk->next != stack) {
+chunk->next = stack;
+}
+
+chunk = chunk->prev;
+stack->prev = chunk;
+}
+chunk->used -= depth - n;
+}
void intstack_free (struct Parrot_Interp *interpreter, IntStack stack)
{
Index: include/parrot/rxstacks.h
===
RCS file: /cvs/public/parrot/include/parrot/rxstacks.h,v
retrieving revision 1.4
diff -p -u -w -r1.4 rxstacks.h
--- include/parrot/rxstacks.h 22 Aug 2002 20:08:59 - 1.4
+++ include/parrot/rxstacks.h 2 Sep 2002 15:51:14 -
@@ -37,6 +37,8 @@ INTVAL intstack_depth(struct Parrot_Inte
void intstack_push(struct Parrot_Interp *, IntStack, INTVAL);
INTVAL intstack_pop(struct Parrot_Interp *, IntStack);
+void intstack_chop(struct Parrot_Interp *interpreter, IntStack stack,
+ INTVAL n);
void intstack_free(struct Parrot_Interp *, IntStack);
Re: Conditional makefile generation (Was Re: [perl #16856] [PATCH]variouschanges to imcc)
On Fri, 30 Aug 2002, Steve Fink wrote: > On Fri, Aug 30, 2002 at 03:49:07PM -0400, Andy Dougherty wrote: > > Thus what I'd really like to do here is generate two different makefile > > fragments, depending on whether or not the user is using bison or (yacc or > > byacc). With the current substitution-driven makefile.in system, it's not > > obvious to me how best to do that. Anyone have any suggestions? > > Well, you could extend the current system with something like the > attached patch. Ahh. This is quite clever. I'm going to file this away for possible future use. For cases (such as this) where we're trying to emulate a simple well-known interface (e.g. bison -o) with a clunkier multi-line version (e.g. yacc, with it's y.tab.? files) it makes a lot of sense. For more complex cases (e.g. perl5's building a shared libperl on OS/2 or cygwin) I'm less certain. In those cases, it might still be more convenient to conditionally include different fragments in a makefile. It was with an eye to such future issues that I posted my original question. The imcc issue just gave me a convenient concrete context. Of course, once parrot is self-bootstrapping, we merely need to ensure that its build command understands conditionals somewhat like GNU make's. For imcc, I think I'm going to suggest sidestepping the issue and just shipping the pre-generated files (longer message and associated patch in progress). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Goal call for 0.0.9
On Mon, Sep 02, 2002 at 08:25:30AM -0700, Sean O'Rourke wrote: > On Mon, 2 Sep 2002, Dan Sugalski wrote: > > > Here's a call for potential goals for the 0.0.9 release of parrot. My list: > > > > *) Exceptions > > *) initial PMC freeze/thaw API > > *) Sub indicators in bytecode > > *) On-the-fly bytecode section generation > > *) methods (in PASM and C) > *) implementation of some methods for the Perl classes > *) stashes *) Resolve the prompt finalization problem (good luck...) *) PMC name, implementation cleanup *) Filename, line number tracking The second one requires more comment. Right now, we have a set of language-independent PMCs (Array, Continuation, Coroutine, Key, Pointer, etc.) and a set of Perl PMCs (PerlArray, PerlString, etc.). But the exact methods implemented on each one are a little tangled, and many of the Parrot PMCs refer to and create Perl PMCs on the fly. For example, when you increment an nonexistent Array slot, it automatically creates a PerlInt to hold the number. Similarly, PerlUndef gets spontaneously created all over the place. Some of these problems can probably be fixed by renaming PMCs (eg PerlUndef -> Undef); others by making a generic base PMC and having the Perl PMC inherit from it; and still others need to be rethought. On a related note, we should probably have a test case that tries every possible vtable entry for every PMC and makes sure that the result makes sense (mostly meaning that things throw 'operation not supported' type errors when appropriate.)
Re: [perl #16935] [PATCH] more regex stack manipulation
At 3:59 PM + 9/2/02, "Sean O'Rourke" (via RT) wrote: >rx_stackdepth Ix -- Store the size of the regex stack in Ix Make that intstackdepth, since it's a general-purpose stack. >rx_stackchop Ix -- shorten the regex stack to have Ix entries Yeek--that's from the wrong end. We need to chop entries off the top, as we have no idea how many entries were already there. I think I'm really, *really* close to tossing the last pretense of being a stack-based system and move all the way to routine-based frames instead, which'd definitely make some things easier. Anyway, it should be intstackchop, and chop X entries off the top of the stack. Or, if you'd rather, intstackpop ix, and add in "pop X" versions for the other stacks too. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] in makefile, move libparrot.a from "test" to "all"
On Sun, Sep 01, 2002 at 02:32:26AM -0400, Mike Lambert wrote: > Mr. Nobody wrote: > > > Date: Fri, 30 Aug 2002 18:13:27 -0700 (PDT) > > From: Mr. Nobody <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: [PATCH] in makefile, move libparrot.a from "test" to "all" > > > > libparrot.a is not really related to testing, it should belong in "all". This > > patch does so, and as a side effect, t/src/basic will now work with "make testj". > > I thought so as well, at first. And currently, that might be an > okay thing to do. > > However, it might help if I explain the purpose of the t/src/* tests. The > originate from ticket 468: > http://bugs6.perl.org/rt2/Ticket/Display.html?id=468 > > I believe the eventual intent is to set up the t/src/* tests to test: > a) functions in parrot which aren't testable via opcodes, and thus can't > be tested with our pasm files. > b) the embedding system, to ensure that a static interface doesn't change > behavior on us, etc. > > Currently however, neither a nor b are implemented, and so the t/src/* > test have no direct dependancy upon libparrot.a/lib and libparrot.so/dll, > and so can probably be removed. If it helps make 0.0.8 build on more > platforms, it might be a "good thing" to do. As long as it's not long-term. I have a patch I will be sending in soon that includes a large test case in t/src, and it requires libparrot.a. But t/src/basic.t test 2 calls internal_exception(); shouldn't that require libparrot.a already? Either way, I think more t/src/ tests can only be a good thing, since they'll help narrow regression failures down to either the underlying ADT or the calling code. And if the failure is in the core code, it's easier to debug when you don't have peer at the problem through the outer layers of parrot. So I vote for leaving the directory, and fixing the library building instead. (Which means I agree with Mike, since 0.0.8 has gone out now!) It ought to be commented in the makefile *why* the tests require libparrot.
Re: [perl #16857] [PATCH] minor refactoring in dod.c
On Sun, Sep 01, 2002 at 02:30:35AM -0400, Mike Lambert wrote: > > Small cleanups, but also a piece of my attempted fixes to the > > BUFFER_external_FLAG. (The CVS version currently doesn't work anyway, > > so don't worry about only getting parts of my fixes in; nothing > > depends on it.) > > I'm curious about your dod/external "fix". If I understood the purpose of > BUFFER_external_FLAG correctly, it indicates that the memory pointed to by > this header is external to our local memory pool, and thus should not be > collected, etc. > > However, if I understand your patch correctly, it makes all external > buffers immune to being collected. I agree with the resources.c patch to > fix external, but I'm not sure about this one. I ran into a bug with argv getting collected when things were started up with pdb.c, and kept beating on things until the problem went away. (Though I'm not sure debug.c even uses that flag anymore...) Upon rereading the dod.c patch, I agree with your criticism. I'll leave it up to you how to fix up external stuff (whether to integrate it with selfpoolptr or whatever.) But in addition to what you and Peter have already considered, I wonder if making a separate string API entry would make sense: instead of passing any special flag to string_make(), create a separate entry string_wrap() or something.
Re: [perl #16935] [PATCH] more regex stack manipulation
On Mon, 2 Sep 2002, Dan Sugalski wrote: > At 3:59 PM + 9/2/02, "Sean O'Rourke" (via RT) wrote: > >rx_stackdepth Ix -- Store the size of the regex stack in Ix > > Make that intstackdepth, since it's a general-purpose stack. If so, we'll probably also want to change rx_clearstack and rx_initstack. I thought the "rx_" was the naming convention for things that dealt with the interpreter intstack. > >rx_stackchop Ix -- shorten the regex stack to have Ix entries > > Yeek--that's from the wrong end. We need to chop entries off the top, > as we have no idea how many entries were already there. Either way. I thought it was more natural to be able to "save" and "restore" absolute stack depths, so you don't have to track how much stuff gets pushed onto the stack between when you record the depth and when you pop back to it. I think it ends up being two more ops if you say "chop X entries" -- "getdepth; subtract; chop" vs. "setdepth". > I think I'm really, *really* close to tossing the last pretense of > being a stack-based system and move all the way to routine-based > frames instead, which'd definitely make some things easier. I don't think frames help us here. This is basically a poor man's exceptions. It's useful for regexes, where you are only accumulating state on the intstack, so using full exceptions or (heaven forbid) continuations is overkill. I don't know if it's a useful approach outside of a limited regex-backtracking context. > Anyway, it should be intstackchop, and chop X entries off the top of > the stack. Or, if you'd rather, intstackpop ix, and add in "pop X" > versions for the other stacks too. I think these could be useful as well. /s
Re: Iterator.pmc (was: set_p_p)
On Mon, Sep 02, 2002 at 01:33:45PM +0200, Aldo Calpini wrote: > INTVAL iterator_sizeof() > void iterator_reset() > void iterator_set(void *data) > void iterator_get(void *data) > PMC* iterator_get_current() > void iterator_next(); What is the advantage of having the aggregate ever hold onto the iteration state? What do you think of the following interface: INTVAL iterator_sizeof() void iterator_reset(void *data) PMC* iterator_get_current(void *data) void iterator_next(void *data); intiterator_has_next(void *data); In other words, state allocation happens the same way you have it now, but the aggregate never holds onto any state between calls; it is always passed in the state object when it needs to do anything. This would remove any thread-related headaches, and just seems safer in general (less potential for bugs resulting from calling the API functions in the wrong order.) But perhaps I'm missing some advantage in having the aggregate hold onto the state? Also, with garbage collection it seems safe to have the aggregate return its own state object rather than having the Iterator do the allocation. The Iterator wouldn't even need to know how big the object was. When the owning Iterator got collected, it would just pass the pointer to mem_sys_free(). (In other words, the memory allocation system already maintains metadata like the size of allocations; why duplicate it?)
[perl #16937] [PATCH] Configure still using wrong shared library flags.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #16937]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16937 >
This is a resubmit. Configure currently hard-wires ld_shared to a
GNU-binutils-specific value of '-shared'. This is wrong. The correct
value should be available from perl5's $Config{lddlflags}.
I have been told that some perl5 ports (cygwin?) have wrong values for
$Config{lddlflags}. If so, those ports should be fixed over on
perl5-porters. In the meantime, platform-specific hints can be used to
override the wrong value. For most users, however, using the correct
value from perl5's Config is probably the correct thing to do.
diff -r -u parrot-orig/config/init/data.pl parrot-andy/config/init/data.pl
--- parrot-orig/config/init/data.pl Thu Aug 29 16:56:29 2002
+++ parrot-andy/config/init/data.pl Mon Sep 2 12:41:02 2002
@@ -39,7 +39,7 @@
ld_out=> '-o ', # ld output file
ld_debug => '', # include debug info in executable
-ld_shared => '-shared',
+ld_shared => $Config{lddlflags},
ld_shared_flags=> '', # What is this, exactly? For GNU ld, it was
# '-Wl,-soname,libparrot$(SO)'
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
[perl #16938] [PATCH] Fix imcc shared library versions.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #16938]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16938 >
imcc doesn't work anymore now that the version number has changed from 7
to 8. This patch replaces the hardwired 0.0.7 by the appropriate defines
determined by Configure.pl.
diff -r -u parrot-orig/languages/imcc/anyop.c parrot-andy/languages/imcc/anyop.c
--- parrot-orig/languages/imcc/anyop.c Tue Aug 27 02:48:44 2002
+++ parrot-andy/languages/imcc/anyop.c Mon Sep 2 14:51:51 2002
@@ -195,7 +195,9 @@
while ((c = getopt(argc, argv, "l:a:")) != -1) {
switch (c) {
case 'l':
- op_load_lib(optarg, 0, 0, 7);
+ op_load_lib(optarg, PARROT_MAJOR_VERSION,
+ PARROT_MINOR_VERSION,
+ PARROT_PATCH_VERSION);
break;
case 'a':
diff -r -u parrot-orig/languages/imcc/imcc.y parrot-andy/languages/imcc/imcc.y
--- parrot-orig/languages/imcc/imcc.y Thu Aug 29 16:56:30 2002
+++ parrot-andy/languages/imcc/imcc.y Mon Sep 2 14:53:28 2002
@@ -733,7 +733,9 @@
if (IMCC_DEBUG)
fprintf(stderr, "loading libs...");
op_load_file("../../blib/lib/libparrot.so");
-op_load_lib("core", 0, 0, 7);
+op_load_lib("core", PARROT_MAJOR_VERSION,
+ PARROT_MINOR_VERSION,
+ PARROT_PATCH_VERSION);
if (IMCC_DEBUG)
fprintf(stderr, "done\n");
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
core.ops ARGDIR
Hi all, I would like to discuss the intended meaning of ARGDIR_IN/OUT in core.ops (core_ops.c). s. also #16838 and #16895 imcc uses the IN/OUT information for determining the life status of a symbol, which is the base for register allocation, so it's crucial. The meaning in imcc is like: IN ... register is read, (or exists) OUT ... register is written to, i.e. starts a new life cycle when we have a op sequence: 1 set I0, 5 # I0 is alive 2 set I1, I0 # here too, gets read 3 set $I55, $I56 # no use of I0 here N-1 ... # but some temps need a register N set I0, 6 # I0 starts a new life here then - I0 is alive at [1,2] and at [N,..] because it's not read again after 2 and in N, it start's a new life cylce. So the register allocator may use the register I0 between 3 and N-1 for allocation of other temporary variables, which need a register. So similar example with PMCs 1 new P0, .PerlUndef # start life of P0 2 set P0, 5 # call P0's vtable->set_integer_native(5)... 3 ... # no set P0, Py here N-1 ... # no new P0, xx here N set P0, 6 # call same's PO set_integer_native(6) so P0 is alive in the whole instruction sequence [1,N], and may not be used in between. This should be - from my (imcc) POV - reflected by these IN/OUT settings: op set(in PMC, in INT) op set(in PMC, in STR) op set(in PMC, in NUM) op set(out PMC, in PMC) # ok, $1 points to $2 now # P[i] = x op set(in PMC, in intkey, in x) # P[KEY] = x op set(in PMC, in KEY, in x) # p[KEY] = P[KEY] op set(in PMC, in KEY, in PMC, in KEY) Actually current imcc overrides core.ops with these opterations and changes them to "in", and does fail, when core.ops is regarded for these operations and "out" is used. The only other usage of this ARGDIR info is in JIT, where I really, don't know, how (if even for PMCs) it's used there. Comments welcome, TIA leo
Re: [perl #16935] [PATCH] more regex stack manipulation
I think those are necessary operations -- if you're going to use the
intstack in the first place. And personally, I don't intend to. I
think it's much easier to deal with a separate data structure than
something tied into the interpreter struct. A free-floating intstack,
if you will. But this has some of the same problems, which I'll talk
about later.
I will soon be submitting a patch for an IntArray PMC (which should
probably be called IntList or IntArrayList). It's a wrapper around a
reworking of intstack.c. intarray.c operates almost exactly like
intstack.c, only it's more suitable for calling via a PMC. Also, it
seemed like it was so close to the oft-mentioned integer-only array
(declared in perl6 with something like 'my int @array'), that I
finished off the other common operations (shift, unshift) so that it
can be used for that, too.
Given this intarray, I intend languages/regex to target it instead of
the user stack or the integer stack. (This partly came about because
in trying to deal with dynamically-modifiable rules, I realized it
would be far easier to have two integer stacks instead of one.) So
instead of having to revert the stack back to some initial depth, I'll
just discard the whole thing. Also, it should be easier to implement
restartable regexes to implement things like perl6's :each flag
(everyone else's /g flag) without going whole-hog and using
continuations or coroutines.
On Mon, Sep 02, 2002 at 11:46:41AM -0700, Sean O'Rourke wrote:
> On Mon, 2 Sep 2002, Dan Sugalski wrote:
>
> > I think I'm really, *really* close to tossing the last pretense of
> > being a stack-based system and move all the way to routine-based
> > frames instead, which'd definitely make some things easier.
>
> I don't think frames help us here. This is basically a poor man's
> exceptions. It's useful for regexes, where you are only accumulating
> state on the intstack, so using full exceptions or (heaven forbid)
> continuations is overkill. I don't know if it's a useful approach outside
> of a limited regex-backtracking context.
What about nested scopes? Isn't there any variable-sized stuff that
needs to be popped off en masse on a scope exit? Pads or stash
override chunks or whatever? C certainly has this for local variables,
but I've lost track of what perl6 is supposed to use.
But as for exceptions vs continuations vs whatever, I know very well
where Sean is coming from. In a match where we expect to backtrack a
few thousand times, I'd really rather not create a few thousand
Exception or Continuation objects. So doing something lightweight with
the integer stack or intarrays seems much more workable.
On the other hand, hypotheticals in combination with restartable
regexes are still going to be a headache. I don't know how messy that
gets -- if we allow arbitrary BACK{} blocks, then it seems like we'll
need to be doing the same thing for the regex instack(s) as we already
have to do with the other stacks to support continuations. Maybe. I
haven't really thought it through.
Re: Goal call for 0.0.9
On Mon, Sep 02, 2002 at 11:15:17AM -0700, Steve Fink wrote: > On Mon, Sep 02, 2002 at 08:25:30AM -0700, Sean O'Rourke wrote: > > On Mon, 2 Sep 2002, Dan Sugalski wrote: > > > > > Here's a call for potential goals for the 0.0.9 release of parrot. My list: > > > > > > *) Exceptions > > > *) initial PMC freeze/thaw API > > > *) Sub indicators in bytecode > > > *) On-the-fly bytecode section generation > > > > *) methods (in PASM and C) > > *) implementation of some methods for the Perl classes > > *) stashes > > *) Resolve the prompt finalization problem (good luck...) > *) PMC name, implementation cleanup > *) Filename, line number tracking *) Careful elimination of all compiler warnings, particularly on non x86 platforms, and for builds with non-default INTVAL size This is going to need some care to work out why some warnings happen, and find ways to re-order/re-pack/re-size structures to avoid both these gcc warnings: In file included from ../include/parrot/register.h:16, from ../include/parrot/interpreter.h:42, from ../include/parrot/parrot.h:160, from perlhash.c:24: .../include/parrot/string.h:59: warning: padding struct size to alignment boundary In file included from ../include/parrot/interpreter.h:51, from ../include/parrot/parrot.h:160, from perlhash.c:24: .../include/parrot/debug.h:53: warning: padding struct to align `value' over all platforms. (which will be fun) and I think *) Rationalisation of how we make bytecode I think that the assembler is slower than it could be. I feel that the "correct" solution is a perl front end talking to a C bytecode generation library. I feel the library ought to be common, so that it would be possible for imcc (or anything else) to use the bytecode generation library direct, rather than having to emit PASM only for it to be re-interpreted. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
[perl #16941] [PATCH] Use pre-generated files for imcc.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #16941]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16941 >
The following patch changes the build system to use pre-generated files
for languages/imcc. A special target 'make regen_all' has to be invoked
to run bison and flex. This removes the requirement that the build system
has bison and flex installed.
As examples of the sorts of problems this avoids, and to record somewhere
what I had to do in case someone else wants to pursue it further, here
are the main problems I had in using Sun's yacc and lex:
0. Configure.pl needs to determine whether or not you have bison, byacc,
or yacc, and flex or lex. There's currently no built-in method to do
that, though searching through File::Spec::path isn't too bad.
1. yacc puts its output into non-portable files, y.tab.[ch] on Unix
systems. This would require Configure/Makefile hackery to handle
portably. Similarly, lex uses yy.lex.c.
2. Sun's yacc doesn't put the appropriate token #defines early enough in
the generated file, so imcparser.c has to #include "imcparser.h". This
causes an error however due to a redeclaration of a union. Further cpp
hijinks are required to get around that.
3. The lex-generated gives errors for the flex-specific %option lines.
These all have to be deleted before even running lex. More Makefile
hackery.
4. The lex-generated parser didn't work because the input lines are too
long. It's possible to get around this by manually adding #define
DYYMLMAX 8192 to the top of imclexer.c, but this is more annoying Makefile
hackery.
5. The lex-generated parser would need additional work because Sun's lex
doesn't appear to have anything similar to flex's YY_CURRENT_BUFFER
used in yywrap(). I suspect it'd have to be re-written specifically for
lex.
All in all, I judged it better to simply supply the generated files with
parrot. That's what this patch enables.
I don't really know how to work cvs well. I think the first hunk is
needed so that the appropriate files get exported. The remaining hunks
do the actual work.
I'd appreciate folks trying this out and verifying that it works.
--- parrot-orig/languages/imcc/.cvsignore Tue Aug 27 04:07:45 2002
+++ parrot-andy/languages/imcc/.cvsignore Mon Sep 2 15:44:45 2002
@@ -1,6 +1,3 @@
imcc
-imclexer.c
-imcparser.c
-imcparser.h
imcparser.output
Makefile
diff -r -u parrot-orig/MANIFEST parrot-andy/MANIFEST
--- parrot-orig/MANIFESTThu Aug 29 16:56:27 2002
+++ parrot-andy/MANIFESTMon Sep 2 12:32:08 2002
@@ -321,6 +321,9 @@
languages/imcc/imc.h
languages/imcc/imcc.l
languages/imcc/imcc.y
+languages/imcc/imcparser.c
+languages/imcc/imcparser.h
+languages/imcc/imclexer.c
languages/imcc/instructions.c
languages/imcc/instructions.h
languages/imcc/sets.c
diff -r -u parrot-orig/config/gen/makefiles/imcc.in
parrot-andy/config/gen/makefiles/imcc.in
--- parrot-orig/config/gen/makefiles/imcc.inTue Aug 27 01:02:28 2002
+++ parrot-andy/config/gen/makefiles/imcc.inMon Sep 2 15:35:13 2002
@@ -23,8 +23,6 @@
CC = ${cc}
PERL = ${perl}
MAKE_F=${make}
-YACC = bison -v -y
-LEX = flex
LD = ${ld}
LD_SHARED = ${ld_shared}
@@ -33,11 +31,17 @@
all : imcc
cd ../.. && $(MAKE) shared && $(RM_F) parrot${exe} && $(MAKE)
-imcparser.c imcparser.h : imcc.y
- $(YACC) -d -o imcparser.c imcc.y
+.PHONY:run_bison run_flex
-imclexer.c : imcc.l $(HEADERS)
- $(LEX) imcc.l
+# We now supply imcparser.[ch] and imclexer.c, so only run the
+# following commands if imcc.l or imcc.y is changed.
+regen_all: run_bison run_flex
+
+run_bison:
+ bison -v -d -o imcparser.c imcc.y
+
+run_flex:
+ flex imcc.l
.c$(O):
$(CC) $(CFLAGS) ${cc_exe_out}$@ -c $<
@@ -50,8 +54,6 @@
realclean: clean
$(RM_F) a.pasm
- $(RM_F) imcparser.*
- $(RM_F) imclexer.*
imcc: $(O_FILES)
$(LD) $(LD_OUT)imcc $(LDFLAGS) $(O_FILES) $(C_LIBS)
diff -r -u parrot-orig/languages/imcc/imcc.l parrot-andy/languages/imcc/imcc.l
--- parrot-orig/languages/imcc/imcc.l Tue Aug 27 10:09:00 2002
+++ parrot-andy/languages/imcc/imcc.l Mon Sep 2 15:32:27 2002
@@ -22,6 +22,7 @@
%}
%option outfile="imclexer.c"
+%option nounput
LETTER [a-zA-Z_]
DIGIT [0-9]
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Goal call for 0.0.9
On Mon, 2 Sep 2002, Nicholas Clark wrote: > *) Careful elimination of all compiler warnings, particularly on non x86 >platforms, and for builds with non-default INTVAL size I agree here. There are still *lots* of warnings. I've slowly whittled away at them, but there are lots to go. Fixing some of them might also help re-claim the Tru64 systems, which are currently failing with unaligned access errors in the tinderbox. Similarly, it may be a good time to revisit our "core" platforms and see if they all work. A lot of the library stuff, especially the shared library stuff, is rather dlopen-specific. I suspect the perl6 stuff probably doesn't work now with AIX, HP/UX, OS/2, Unicos, or VMS, to name just a few. I'd be very happy to be proven wrong. It may be that 0.0.9 isn't the time for such portability issues (which are *hard*). That's ok, too, but I thought I'd raise the issue. Andy Dougherty [EMAIL PROTECTED]
Re: [perl #16938] [PATCH] Fix imcc shared library versions.
Andy Dougherty (via RT) wrote:
> + op_load_lib("core", PARROT_MAJOR_VERSION,
> + PARROT_MINOR_VERSION,
> + PARROT_PATCH_VERSION);
Thanks for this one.
I did integrate it in my tree.
A _big_ imcc patch is in my queue and will be sent to the list in the
next days.
leo
Re: [perl #16935] [PATCH] more regex stack manipulation
Sean O'Rourke wrote: > On Mon, 2 Sep 2002, Dan Sugalski wrote: >... I think it ends up being two more ops if you say "chop X > entries" -- "getdepth; subtract; chop" vs. "setdepth". Think the perlish way: chop -X could do it. Leave X or keep it. BTW what is the difference between the rx_stack and the "high-speed int stack" in core.ops? leo
Re: core.ops ARGDIR
On Mon, Sep 02, 2002 at 09:49:25PM +0200, Leopold Toetsch wrote: > > This should be - from my (imcc) POV - reflected by these IN/OUT settings: > > op set(in PMC, in INT) > op set(in PMC, in STR) > op set(in PMC, in NUM) > op set(out PMC, in PMC) # ok, $1 points to $2 now Thinking about it, that actually seems correct. This alternative seems wrong: op set(inout PMC, in INT) op set(inout PMC, in STR) op set(inout PMC, in NUM) op set(out PMC, in PMC) # ok, $1 points to $2 now because I'm assuming that the input PMC register for the first three is unchanged. Or can there be situations where an assignment to a PMC changes the value of the register itself? Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
