How to help ?
Hi all, I'd really like to try helping developing Perl6 and Parrot, I subscribed to the mailing-list, read some docs, got and compiled parrot via svn (in a vmware-played ubuntu ;-) ). But it is not obvious to see where to begin, and where I can be useful. My main objective is to have a fast, reliable and with good threading support interpreter. I have written a lot of perl code (APIs, scripts, CGIs, applications, Inline::C), I can program and optimize in C, and I have a good understanding of algorithmics. Any help greatly appreciated Karl P.S I suppose that I'm not the only one willing to help facing this difficulty. Maybe a tutorial or a FAQ could attract more contributors ?
list_set_length
I apologize for my probably naive question... Trying to decipher t/pmc/array.t, I began wondering what happens if you set a negative length to an array. It lead me to array.pmc::set_integer_native, which just forwards its size argument to list.c::list_set_length without any check. list_set_length() seems to accept negative sizes. The implemented behaviour seems to decrease the size of the array by the absolute value of the arg, iff it is >= 0. For instance, if an array of size 5 is set to -10, it will have no effect. So my question is : - Is it expected (in List API, in PMC Array) ? - Where can I find the specification/documentation describing this kind of behaviour ? Thanks Karl
Re: How to help ?
On 2/21/06, Allison Randal <[EMAIL PROTECTED]> wrote: > > On Feb 20, 2006, at 9:56, Bernhard Schmalhofer wrote: > > > >> P.S > >> I suppose that I'm not the only one willing to help facing this > >> difficulty. > >> Maybe a tutorial or a FAQ could attract more contributors ? > >> > > Yes. > > In fact, this may be the best place you can start, even if it's only > in the form of "here's a list of things I wish I knew starting out". > It's difficult to see the code from that perspective after working on > it for a few years (I know, I've tried), so your view can be a big help. I was expecting this kind of answer (Just Do It) ;-) Where/How could I add this kind of FAQ ? And always feel free to ask questions. Thanks Karl
docs
Hello, I've played a little with 'make html', and the docs produced seem to me much more useful than the docs available on the parrotcode.org website. What I particularly appreciate is the hyperlinks to other pod documents and the ability to browse the source code, the examples, the tests and so on. Concerning the hyperlinks, I noticed that for now, in order for the links F< foo.pod> to work, I had to give the relative path from the root of the parrot checkout, even if the file referencing the other is in the same directory. Let me clarify a bit: in docs/parrot.pod, using "make html", the link produced by "F" does not work while "F" does work. So at last my questions are: - is this the canonical/correct way of referencing files ? In that case should I correct all pod files ? - Is it planned that the html documentation produced by "make html" will replace the current website documentation ? - Are there some documentation that I missed about how to write parrot documentation (POD syntax, guidelines etc...) ? Thanks Karl
Re: [perl #38627] [TODO] fill Parrot_register_move() with code
On 2/25/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > Leopold Toetsch (via RT) wrote: > > > fill the function body of Parrot_register_move() (src/utils.c 633 ff). > > Parrot is now using this function [1] for recursive tailcalls. There are > 2 new tests in t/compilers/imcc/imcpasm/optc.t. > > Implementations can therefore be tested easily now. > > [1] just a broken one to one move > > Takers still welcome, > leo > Probably a naive question : in which branch is Parrot using this function ? Because I got the main one (svn co https://svn.perl.org/parrot/trunk parrot) and this function does not seem to be called when running the t/compilers/imcc/imcpasm/opt.t (using perl t/harness t/compilers/imcc/imcpasm/opt.t) : I put some printf/fprintf(stderr) debugs and can see nothing. Moreover what I don't understand is that if the current implementation is broken, why are the tests successful ? > Thanks Karl
[TODO] fill Parrot_register_move() with code : new implementation
Hello,Because I will soon somewhat criticize Vishal's work, I would start by thanking him for his implementation that enabled me for the first time to experiment with parrot development.I have some new tests to contribute that reveal some bugs in Parrot_register_move(). Moreover the current implementation produces suboptimal code, is quadratic in space and and cubic in execution time in the worst case.So I propose a new implementation that solve the bugs, and that is linear in space and time, and hopefully produce an optimal list of moves. It is to be found in the second patch.I'll try to explain my method in order to help you try to detect any flaw or things I have missed.DEFINITIONS AND VOCABULARY We have two lists of registers, the src_regs[] and dest_regs[], that form a graph: src_regs[i] ==> dest_regs[i]A same register may appear several times in the src regs, but only at most one time in the dest ones, because it makes no sense to assign two values to a same register. If we have : i ==> j, I call i the predecessor of j, and j is one successor of i.I call a cycle (shoud be a circuit though) a path whose last element is the same as the first one, e.g : i ==> j==>k ==> i I call a cycle without exist, a cycle such as every member of the cycle has exactly one successor, i.e it is not possible to leave the cycle.An example of a graph with a cycle WITH an exit : 1 == > 2 ==> 1 ( 1==>2, 2==>1, 1==>3) ||3I call a well a register that has no successor ( 3 in the previous example )PROPERTIES OF THE REGISTERS GRAPHS There can be several disconnected subgraphs ( e.g 1 ==> 2 and 3 ==> 4), in the following I will say graph for a connected component.- there is at most ONE cycle in a graph (remember, in the same component)- a graph has either at least a well, or it is a single cycle without exit OPTIMALITY-To handle a cycle with exit, you do not need a temp register. Look at he previous example, the optimal list of moves operation is : move( 1 -> 3)move( 2->1) move( 3->2) and not move(1->3)move(1->temp)move(2->1)move(temp->2)So the rule is : the only time you need a temp register is in a cycle without exit, and in this case you need exactly one. The optimal number of moves is then the number of registers + the number of cycles without exits. ALGORITHMA graph has either a well, and in that case we do not need a temp register, or it's a cycle without exit. So we first locate the wells, and for each one we climb back the graph, emitting the moves, and using the notion of backup both for marking visited nodes, and to store the new register that now hold the value. For instance, after a move(i -> j), j is now the backup of i.We stop when we process a node already marked.This process will mark all the sub graphs except for the cycles without exits. We then take the list of (destination) nodes that have not been marked, and process them specifically.DATA STRUCTURES-The trick is to use the existing data structures src_regs[] and dest_regs[] to explore the graph.And because each node has only one predecessor, we can locate it in constant time. We need three data structures, one to hold the mapping between the parrot destination register numbers and their index in the dest_regs[] array,an other to count the nb of successors in order to locate the wells, and the last to both mark the nodes and store their backup register. COMPLEXITYIt should be easy to figure out that the complexity is linear in n_regs (or max_reg).OPTIMIZATION--For now, I've only hard-coded the cases n=0 and n=1. I know that premature optimization is EVIL, but one thing that could save some often slow system calls would be to keep the allocated data structures, reallocating them when needed instead of allocating them each time we enter the function. Those arrays could be stored in the Interpreter for instance.OPEN PROBLEMS-It is stated in the documentation that the mov_alt function should be tried before using a temp register Suppose that you have a cycle 1 ==> 2 ==> 3 ==> 4If move_alt( 1 -> 2 ) fails, should we try move_alt( 2 -> 3) and move_alt( 3-> 4) too ? It would slow down a little, but if successful could reduce the nb of moves by one. Currently it is not implemented.So I hope that this work could prove useful, I would be very glad if I could help the development of parrot.Regards,Karl Forner Index: t/compilers/imcc/imcpasm/optc.t === --- t/compilers/imcc/imcpasm/optc.t (revision 14604) +++ t/compilers/imcc/imcpasm/optc.t (working copy) @@ -4,7 +4,7 @@ use strict; use lib qw( . lib ../lib ../../lib ); -use Parrot::Test tests => 36; +use Parrot::Test test
HOWTO give options to parrot in tests
Hi, I'm currently trying to implement [#40064: [TODO] shootout example testing]. Because the PIR shootout scripts are run with specific options, I must be able to run the script with these options that I can get by parsing the she-bang line. But by looking in other tests and in the Parrot::Test, it seems that the canonical way of running a PIR script is through the example_output_is() function. BUT this function does not take any arguments for Parrot. By looking again in the code I figured out that maybe I could use the TEST_PROG_ARGS env var (if the script name does not match "opt"). But it is undocumented and not very robust, so What Should I do ? Thanks, Karl Forner
Re: HOWTO give options to parrot in tests
On 9/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: Am Freitag, 15. September 2006 01:42 schrieb Karl Forner: > But by looking in other tests and in the Parrot::Test, it seems that the > canonical way > of running a PIR script is through the example_output_is() function. > BUT this function does not take any arguments for Parrot. I'd subclass Parrot::Test and create a function shootout_output_is(), which takes an extra commandline argument. Hmmm but if I subclass Parrot::Test, I won't be able to reuse any code. So if by instance the multiplatform way of getting the path to the parrot interpreter changes, I will have to synchronyze the code in the subclass too. Isn't it evil ? By the way, I have implemented the test using the TEST_PROG_ARGS environment variable. It is not very elegant but at least it seems to work for now.
Re: [TODO] fill Parrot_register_move() with code : new implementation
On 9/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 14. September 2006 02:54 schrieb Karl Forner:
> Hello,
>
> So I propose a new implementation that solve the bugs, and that is
linear
> in space and time, and hopefully produce
> an optimal list of moves. It is to be found in the second patch.
Great. Applied as r14621.
> We have two lists of registers, the src_regs[] and dest_regs[], that
form a
> graph: src_regs[i] ==> dest_regs[i]
Please note:
- There are 2 use cases for register_move
a) optimized recursive tail calls
b) simple function call argument passing compiled to native code in JIT
core
For a) {src,dest}_regs aren't register numbers, but just an index in the
move
list. While a function could have x 1000s of registers, a function call is
limited to 255 arguments. This is currently the limit due to the usage of
unsigned char (and there's no designer decision on that yet).
Anyway, a function call:
foo(P2000, P3000, I5)
would create
src_regs := (0, 1, 2)
So in that case ( a or b ?), the src_regs are always (0,1,2,..,n) ?
If so I'm sure that we can use this property to optimize the code.
For b) it's either the same or (likely) HW register numbers (whatever is
appropriate - it's not implemented yet) (see jit_set_args_pc())
> A same register may appear several times in the src regs, but only at
most
> one time
> in the dest ones, because it makes no sense to assign two values to a
same
> register.
While it doesn't make sense, we can't prevent users from coding such a
function call.
The problem is that I have no clue of JIT, registers and so on. But could
you give an example of code that would
lead to that case ?
And worse: due to PMC registers any argument passing (with
conversions) could have a side effect due to operator overloading or such.
This means that we just have to avoid these optimizations which are using
register_move() in that case.
> To handle a cycle with exit, you do not need a temp register.
Excellent.
> For instance, after a move(i -> j), j is now the backup of i.
This and the implementation assumes that now i and j have the same value.
Again due to the nastiness of P registers and due to possible argument
conversion, this isn't true in the general case. Again, while it doesn't
make
much sense, to create such recursive tailcalls with argument conversion
to/from PMC registers, users might still code that.
Again, we have to check if any argument conversions could take place and
then
turn off the optimization in case.
ok, so where would the check take place ?
I can imagine an extra argument indicating whether or not doing this extra
optimization, or two different functions/implementations,
or more infomration about the registers allowing the function to decide by
itself to do or not the optimization on a register-couple basis
OPEN PROBLEMS
> -
> It is stated in the documentation that the mov_alt function should be
tried
> before using a temp register
The idea of mov_alt is coming from the JIT code. src HW registers have a
backup value in either a parrot registers or some call stack. The mov_alt
code would produce an instruction like:
mov 8[%ebp], %edx
> Suppose that you have a cycle 1 ==> 2 ==> 3 ==> 4
> If move_alt( 1 -> 2 ) fails, should we try move_alt( 2 -> 3) and
move_alt(
> 3-> 4) too ?
It's not implemented yet, but I'd say, if mov_alt fails, a temp should be
used
always, and mov_alt shouldn't be tried again.
Ok, that's what the implementation does on a per cycle basis, meaning one
move_alt try by (disconnected) cycle.
It is likely true the other way
too: if mov_alt succeeds for one register, it would always succeed for
other
registers too.
ok, but I can't see how we could use this property.
So is there anything more I could do on this subject ?
Karl
[HOWTO] call a method on a PMC in PIR
I suppose that again it is a trivial question, but I did not manage to find the answer by myself in the documentation. So I want for example to call diretly the "elements" method on a FixedBooleanArray I tried pmc.elements() pmc."elements"() pmc._elements() pmc.__elements() But it did not work... In fact, what I really want to do, for debugging purposes, is to add a custom method in the FixedBooleanArray.pmc (e.g get_allocated_size() ) and be able to call it from PIR test code. Thanks Karl Forner
Re: [HOWTO] call a method on a PMC in PIR
METHOD INTVAL get_allocated_size() {
return PMC_int_val2(SELF); /* or whatever */
}
great, exactly what I needed
thanks
karl
Re: [svn:parrot-pdd] r14784 - trunk/docs/pdds/clip
Hi all, It crossed my mind that we could do this, but I rejected it since it's not really helpful. The #! line is generally only applicable to UNIX-y systems. Even on those systems that do support it, the path to Parrot won't always be the same either. Just a little trick that can help. If the parrot interpreter in in your path, you can workaround the need to specify the aboslute path by using the env command. For instance: #! /usr/bin/env parrot I used that trick to enable the use of perl scripts in a multi-platform but shared filesystem environment. My 2 cents... Karl Forner
Questions about FixedBooleanArray and ResizeBooleanArray
Hi, I coud not find detailed specifications for these PMCs, so I was wondering what should happen when they are (re)sized. For example: a = new FixedBooleanArray a = 3 So a has been (re)sized in order to be able to hold 3 elements, but what should be the value of these elements ? Do they have a default value ? Should they be marked as "undefined" ? 'cause for now it seems that these PMCs do not implement the "defined" interface. Should they ? A last question: By looking in the source code, I noticed that the implementation of get_integer_keyed_int() in ResizeBooleanArray allows negative indexes while not in FixedBooleanArray. Is it expected ? Are there any specs or guidelines for that sort of stuff ? Thanks, Karl Forner
[#39063 and #40066] boolean arrays
Hello, I need some advices. I've worked on fixedbooleanarray and resizablebooleanarray. From #40066 it is said that both need to be rewritten. So I've cleaned up fixedbooleanarray that should be a lot cleaner, somewhat faster and more understandable, and I've added some tests. But of course because resizablebooleanarray extends it, it breaks its current implementation. In parallel, I've checked the #39063 bug that states that ResizableBooleanArray uses 64 bytes per bit of information. I've found the reason why (just a silly #define bug), but nonetheless the implementation is deficient. For example pmc1 = new ResizableBooleanArray pmc1 = 1 pmc1 = 2 pmc1 = 3 makes the following allocation calls: # mem_sys_allocate_zeroed(64) ==> (pmc=1, preallocation of 64 bytes, ok) # mem_sys_realloc(64) ==> (pmc=2)we have 63 bytes left, and we realloc ?? # mem_sys_realloc(64) ==> (pmc=3) same problem So in my opinion too this pmc should be rewritten. I'm ready to do it, based on my fixedbooleanarray implementation, but before doing it I need some answers : Whare the requirements/constraints of a ResizableBooleanArray ? e.g are unshift to be less frequent that shift ? What's a typical usage test case ? Should I keep the actual implementation concept : allocating by chunks of 64 bytes ? Waiting for your input... Karl Forner
Re: [#39063 and #40066] boolean arrays
Yes, I've always why ResizableBooleanArray extends FixedBooleanArray and why FixedBooleanArray is not simply a special case of ResizableBooleanArray. Because a FixedBooleanArray is simpler, so that it may use less memory and be implemented more efficiently I suppose. Is there a real difference between boolean arrays, big integers and binary data? Are the above really different from a STRING ? If not they could become the same thing, or at least share a common implementation. I don't know for the fixed one, because it's so simple that you do not need a backend. But I suppose that String and the Resizable could use a common vector implementation. Of course it would be nice to have all the bitwise and arithmetic methods available. Can the C-code of the Perl5 Module Bit::Vector reused for that? I suppose it could. It comes with the same Licences as Perl (Artistic, GPL and LGPL) so I guess there's no problem at this level. I believe that Bigints already use an external library if available : libGMP. Is there a particular reason not to include it in the parrot distribution. Any Licensing or portability issues ? The only problem I see is that if we don't add other methods to ResizableBooleanArray, it would be overkill just using the BitVector library to store an array, and maybe difficult to debug. See the list of functions it provides : Version()Word_Bits() Long_Bits() new()new_Hex()new_Bin() new_Dec()new_Enum() Shadow() Clone() Concat() Concat_List() Size() Resize() Copy() Empty() Fill() Flip() Primes() Reverse()Interval_Empty() Interval_Fill() Interval_Flip() Interval_Reverse() Interval_Scan_inc() Interval_Scan_dec() Interval_Copy() Interval_Substitute()is_empty() is_full() equal() Lexicompare()Compare() to_Hex() from_Hex() to_Bin() from_Bin() to_Dec() from_Dec() to_Enum()from_Enum() Bit_Off() Bit_On() bit_flip() bit_test() Bit_Copy() LSB()MSB() lsb()msb()rotate_left() rotate_right() shift_left() shift_right() Move_Left() Move_Right() Insert() Delete() increment() decrement() inc()dec()add() subtract() Negate() Absolute() Sign() Multiply() Divide() GCD()Power() Block_Store() Block_Read() Word_Size() Word_Store() Word_Read() Word_List_Store()Word_List_Read() Word_Insert()Word_Delete()Chunk_Store() Chunk_Read() Chunk_List_Store() Chunk_List_Read() Index_List_Remove() Index_List_Store() Index_List_Read() Union() Intersection() Difference() ExclusiveOr()Complement() subset() Norm() Min()Max() Multiplication() Product()Closure() Transpose()
Re: [#39063 and #40066] boolean arrays
On 10/5/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: Am Donnerstag, 5. Oktober 2006 01:49 schrieb Karl Forner: > > Whare the requirements/constraints of a ResizableBooleanArray ? e.g are > unshift to be less frequent that shift ? shift and unshift are both more unlikely than push/pop I presume. OTOH if a user wants a bit queue, you have to deal with both ends ;) > Should I keep the actual implementation concept : allocating by chunks of > 64 bytes ? 64 bytes is any arbitray number but probably fine. It ought to be some power of 2 though and smaller than 16 bytes doesn't make sense. The basic problem with Resizable*Array is: we'd need 3 fields for book-keeping: first_elem 0 unless shift/unshift was done last_elem_p1elements = last_elem_p1 - first_elem allocated amount of allocated memory The latter is of course just an optimization, but we can't afford resizing on each size change. Current PMC layout only allows for 2 integer fields: PMC_int_val and PMC_int_val2. Ok. So first maybe the best way is to use an external lib (GMP or Bit::Vector, cf previous mail in thread)... Otherwise, I have imagined two approaches : 1) in the hypothesis that shift/unshifts are more unlikely, it can be done in a way that uses only the 2 integer fields, one for the nb of elements, the other for the allocated memory. If a shift or unshift is needed, then alloc and copy. 2) in all resize ops are to be symmetrical, we can allocate a third int field : PMC_data could point to a struct holding a buffer and its size. ResizableBooleanArray tried to implement this strategy: 1) 'allocated' is always the minimal n*64 bytes (aka n*CHNUK_SIZE) 2) if there's more room than CHUNK_SIZE on either side of the array, reallocation and moving of bits happens to fullfill again constraint 1. 3) and of course, if more bits are needed, reallocation must be done. yes that's what I had figured out. Karl
What are the final words on GMP, BigNums and *BooleanArrays ?????????????
Hi, It's not that easy to contribute to parrot development. I got into that by picking a TODO task about *BooleanArrays, that seemed appropriate for a Parrot newbie that knows a bit about algorithmics and Data structures. Answering one of my mail, Bernhard raised the question of using a common implementation for strings, boolean arrays. And that maybe this implementation could be borrowed from the Perl5 Bit::Vector library. It reminded me of something I read on this list, about the GMP library. So I checked the GMP website, ok looks great. I've also noted that there are some GMP-based implementations and GMP stuff in Parrot, and a GMP test. But a priori not a word in the specifications and the design documents. So I tried to track all the GMP related threads, and that's not that easy, for instance there does not seem to be a "search" feature on the nntp archive. I tried using some news readers then found my happiness with Google Groups (always Google). But there's also some materials in the blogs for example. So what did I found, among other stuff ? in Joshua Gatcomb mail, 2004-07-31 The "make ICU optional" was supposed to read "make ICU like GMP" - autodetect it if present, but do not force it upon the user. in the Perl 6 Summary for the week ending 2004-07-18: GMP Licensing Armin Obersteiner reported his investigations into the licensing requirements of the GMP maths library. It appears that the FSF's 'GPL Compliance Engineer' reckons we won't need to include the GMP's source code with binary distributions. We just have to make it available from the same source as the distribution. Which is handy. A thread "GMP's license looks Parrot-compatible" starting on 2004-06-30 SO MY POINT IS: 1) it seems that a decision has been made, but that it not written anywhere, and at least not on the parrot site. This decision is, in my understanding, to use an internal fall-back poor man's implementation. 2) Nor could I find the rationale for that decision. I've read some IMHO good arguments for including or for linking, but not a definitive summary, because from the last stuff I read, it seems that the Licensing issues are not blocking 3) I spent more time trying to figure out the right thing to do than in my opinion coding something useful. WHAT I'D LIKE: * Some place, in the docs/ part of the parrot website, where that kind of decision is recorded, along with pointers to relevant information. A kind of proceedings, or critical review, I'm not sure about the word in English. * The particular details for the GMP decision. AND YET OTHER QUESTIONS * What is the intended usage, or in other words, the usefulness of the *BooleanArrays ? I'm somewhat puzzled, because there is no API for using these boolean arrays (a la Bit::Vector for example) * If it's just a kind of storage, I can go on and implement it with a custom, simple and small implementation, but I've still 2 solutions for Resizables : - either grow smartly only on the right (push, pop), an alloc/copy when changes are needed on the left (that saves on INTVAL attribute) - allocate a third INTVAL attribute on the heap, and grows smartly in both directions Thank you very much for your attention Karl Forner
[QUESTION] PMC Pre-allocation
Hi, Is there a way to specify a minimum allocation size for PMCs like strings or arrays ? Something like in perl : %h = 1000 ? It could boost execution times when you have a good idea of the space you need. For example, I'd like to do: #ensure that the array has enough allocated storage for 100 elements without need for allocationg memory new P0, .Array, 100 and then push 1,000,000 elements. N.B: it is not the same as new P0, .Array P0 = 100 Thx Karl
PMCs exact allocated size
Hi, It could be useful to have a way to know the exact memory footprint of any PMC. For instance, suppose that each PMC must override/implement a method get_allocated_size(), it could be used to optimize programs that takes too much memory, or to debug/optimize PMC implementation. That method could run in non constant time, e.g for a linked list. What do you think ? Karl
[PATCH] today's build failed because of a missing 'use'
Hi, Just checked out parrot and the build failed like this:cc -o miniparrot -L/usr/local/lib -Wl,-E compilers/imcc/main.o \ -Wl,-rpath=/home/kforner/dev/parrot/test/parrot/blib/lib -L/home/kforner/dev/parrot/test/parrot/blib/lib -lparrot -ldl -lm -lpthread -lcrypt -lrt src/null_config.o
compilers/imcc/main.o: In function `imcc_version':compilers/imcc/main.c:124: undefined reference to `Parrot_revision':compilers/imcc/main.c:128: undefined reference to `Parrot_config_revision'collect2: ld returned 1 exit status
make: *** [miniparrot] Error 1After a little investigation, it appears that the revision_c.pl failed during the build process (see below) but its output is hidden in the make output becausethe make process DOES NOT STOP, and a void
revision.c file is produced.The problem for the revision_c.pl is just a missing 'use File::Spec', see the attached patch.src/extend_vtable.c/usr/bin/perl -Ilib tools/build/revision_c.pl > src/revision.c
Can't locate object method "devnull" via package "File::Spec" at lib/Parrot/Revision.pm line 35.Compilation failed in require at tools/build/revision_c.pl line 25.BEGIN failed--compilation aborted at tools/build/revision_c.pl line 25.
make: *** [src/revision.c] Error 255Compiling with:xx.ccc -I./include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wwrite-strings -Waggregate-return -Winline -Wno-unused -Wsign-compare -falign-functions=16 -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -mno-accumulate-outgoing-args -Wno-shadow -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -fPIC -I. -o
xx.o -c xx.csrc/revision.csrc/packfile/pf_items.csrc/stm/backend.csrc/stm/waitlist.csrc/resources.csrc/charset/ascii.cSo the make process failed with an error 255, but it seems to continue with the compilation, or maybe it is another make process ???
Karl
Index: lib/Parrot/Revision.pm
===
--- lib/Parrot/Revision.pm (revision 14971)
+++ lib/Parrot/Revision.pm (working copy)
@@ -22,8 +22,8 @@
use strict;
use warnings;
+use File::Spec;
-
our $svn_entries = undef;
sub __get_revision {
Re: [QUESTION] PMC Pre-allocation
On 10/18/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: IMHO the only way to get rid of this historical confusion is: - disable the set opcode for arrays by throwing an exception in the vtable - use elements for getting .elems only - implement 2 new opcodes elements P0, I0# fill with default value, set element count to I0 presize P0, I0# allocate storage, elem count is unchanged - implement an introspection method to get various info like allocated size or storage needed I totally agree. Karl
[HOWTO] add a C file to get archived in libparrot.a
Hi, I've added one C src file, say src/foo.c, and include/parrot/foo.h, and a test in t/src/foo.t. I've changed the MANIFEST file accordingly, but I can not manage to have my foo.o file to be added in libparrot.a (after a make clean;perl Configure.pl ;make) What did I miss ? Thanks, Karl
Re: [HOWTO] add a C file to get archived in libparrot.a
On 10/23/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote: Karl Forner wrote: > I've added one C src file, say src/foo.c, and include/parrot/foo.h, and a > test in t/src/foo.t. > I've changed the MANIFEST file accordingly, but I can not manage to > have my > foo.o file to be added in libparrot.a (after a make clean;perl > Configure.pl > ;make) > > What did I miss ? Not sure if you've solved this yet, but just a guess: did you try a "make realclean"? Yes, but that does not change anything. My file does not appear in the Makefile (except for foo.h). I have absolutely no clue of the process used to generate the list of C files to be linked into the parrot interpreter.
Re: [HOWTO] add a C file to get archived in libparrot.a
On 10/25/06, Adam Thomason <[EMAIL PROTECTED]> wrote: Adding the file to the INTERP_O_FILES section in config/gen/makefiles/root.in and re-running Configure should do the trick. --AT Thanks a lot, it works ! Karl
