Jeff wrote:
Partial perl6 compiler
What should be the prerequisits for languages/perl6?
README and languages/perl6/README imply that it should work with perl
5.005, but it obviously doesn't.
(I tried to patch P6C and got it to compile, but the generated
Perl6grammar doesn't work).
With
Nicholas Clark wrote:
In October 2000 I believed that 5.005 maintenance *is* important for the
acceptance of perl6, and I still do now:
Some minutes ago I sent a first patch to Sean, to make it work on 5.005_03.
One reason of failure is shown by the following snippet:
$ cat t1
Sean O'Rourke wrote:
The compiler should work with 5.005_03 now (you may need to get a newer
version of Class::Struct -- I'm waiting to hear back on this).
Patches are on the way.
It works(tm) here, modulo imcc quirks, meaning same test results as with
5.6.1.
/s
leo
Hi all,
thanks to Sean, finally a perl6 driver arrived in CVS.
To further improve/clean up/enhance it, I would need the help of various
people, working on different parts of the parrot project.
Though I could try to write some patches, to address below mentioned
items, I think, people
Hi all,
1) perl6 driver program arrived in CVS/languages/perl6
CAVEATS: it generates a lot of intermediate files:
($filename.{warn,imc,pbc,pasm[,c,o,tree,])
an may therefore clobber e.g. mops.c if you run
languages/perl6 perl6 -C
Dan Sugalski wrote:
At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote:
2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend:
(»make mops« in parrot root)
Just out of curiosity, I presume the (rather abysmal) perl 6 numbers
include time to generate the assembly
Dan Sugalski wrote:
At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote:
2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend:
Just out of curiosity, I presume the (rather abysmal) perl 6 numbers
After the bugfix in perlarray.pmc I can bring you new numbers, which
Daniel Grunblatt wrote:
On Sun, 28 Jul 2002, Leopold Toetsch wrote:
[ Mops ]
plain c 366
You didn't use -O3 while compiling mops.c, did you?
No. Just Makefile's options as defined.
But interesting idea. It makes the inner loop look like this:
..L492
Sean O'Rourke wrote:
-- languages/perl6 should work equally well with 5.005_03 and 5.6.1.
s/should/does/
EOT ;-)
/s
leo
John Porter wrote:
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
This _writes_ to a[1] by generating the entry:
P0, 100
P1 = new .PerlArray
P1 = 0
P0[1] = P1
I0 =
Sean O'Rourke wrote:
On Sun, 4 Aug 2002, Mike Lambert wrote:
Unfortunately, this causes different semantics for whether you are storing
primitives or pointers (primitives copy, whereas pointers are shallow). Of
course, one could argue that the previous one didn't work at all. :)
Thoughts?
Brent Dax wrote:
[EMAIL PROTECTED]:
# Modified:config/gen/makefiles perl6.in
# +perl6-config: ../../Makefile pconfig.pl
# + $(myperl) pconfig.pl ../../Makefile perl6-config
Bad programmer, no cookie--those slashes aren't portable to Windows.
Actually it is my code ;-)
Nicholas Clark wrote:
... I'd find it a lost easier to redo the
trivial cut and past by copying what you did with your patch in front of me,
Please don't forget the $str_re in _annotate_contents, it's still/again
broken for 5.005.
Nicholas Clark
TIA,
leo
Hi,
when testing native types with perl6 I encountered the following problem:
..p6:
my $b is Boolean = 2;
..imc:
.local Boolean _SV_b1
$P4 = new PerlUndef
$P4 = 2
_SV_b1 = $P4
..pasm:
new P14, .PerlUndef
set P14, 2
set P10, P14
..pbc
new_p_ic P14,2
Hi,
assembler.pl has it's private (propably handmade) list of PMC types.
lib/Parrot/PMC.pm is exactly this list, generated by pmc_pm.pl.
Is there any reason why
- PMC.pm is generated with \Lowercased names
- and assemble.pl can't use it?
leo
Peter Gibbs wrote:
[ set_p_p ]
... The future 'assign Px, Py' will call a vtable function
(set_pmc);
So, trying to set a Boolean to 2, would be a case for the proposed
assign function, ok, yes.
... however, in the quoted example, the pure register level
behaviour is all that is
Sorry for replying myself,
my $b is Boolean = 2;
Here obviously a syntax disorder slept in, but the conclusion would be
the same.
leo
Chris Dutton wrote:
Maybe I'm just doing something wrong...
Then when I try to run perl6, via perl perl6 to avoid INC issues, I get:
Code must live with a function
Trying to compile hw.p6.
What does hw.p6 look like? Anyways:
sub main() {
# your code goes here
my $a = 1;
Leopold Toetsch (via RT) wrote:
attached patch uses now a similar startup code for native compiled
programs like test_main.c.
Rediffed and additional patch to compile natively .pasm containing keyed
access (pack_key was not export in lib/Parrot/Types.pm).
please apply,
leo
Hi,
Attached shell script (for systems with a shell) runs all parrot tests
natively compiled either static or shared.
It uses the perl6 driver for this, which has (since I ran out of disc
space first ;-) an explicit option to delete the ~2MB static executables
after successful tests.
(perl6
Jason Gloudon (via RT) wrote:
find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing
old values of bucket pointers across calls to string_compare, which can invoke
compaction, causing the bucket to move.
Dunno, how expensive getBucket is, but wouldn't it be faster,
Mike Lambert wrote:
Anyways, cd to languages/BASIC, run basic.pl, type LOAD wumpus, and
watch it die on Not a string!.
Tracing this beast down, needs attached patch, to cut displayed arg strings.
BTW trace.c nether frees this escaped string.
The last instruction executed is:
PC=1457;
Melvin Smith wrote:
Sean, I'm replying publicly because I'd like to hear other opinions than
mine, yours, Angel's and Leopold's.
I'll answer here to Melvin's mail, but I'll try to make a summary of all
point's taken in this thread + some more.
I still prefer infix notation to prefix
'John Porter' wrote:
Brent Dax wrote:
No; but statements like imcc MUST provide access to ALL of parrot's
(still very dynamic) feature set and discussions of imcc syntax
naturally lead to questions of imcc's role in the parrot project.
E.g. will the perl6 compiler target imcc?
The perl6
Sean O'Rourke wrote:
On Wed, 21 Aug 2002, Leopold Toetsch wrote:
Well, Sean's not quite sure about that. I agree with Melvin that using
PASM syntax for IMCC could make it harder to target other platforms.
I don't know Melvin's plan for other targets - but - as parrot is very
special - I
Melvin Smith wrote:
At 11:15 PM 8/21/2002 +0200, Leopold Toetsch wrote:
So please, first, let's consider the status quo, not the future.
Agree.
_SV_s1 = clone $P1
I've considered changing '=' to mean clone, and add ':=' to imply set.
What do you think?
No changes
Markus Laire wrote:
I tested than on Cygwin and imcc does compile, but I have some
problems:
If I compile imcc with 'make imcc', most perl6 tests will fail with
error readline() on closed filehandle P6C::TestCompiler::PASM at
P6C/TestCompiler.pm line 55.
This looks like imcc doesn't
Markus Laire wrote:
I just checked all failed tests. Worst problem seems to be that tests
returns int/str instead of PerlInt/PerlString
t/parser/apoc1.t 1 256 11 100.00% 1
parser test's are currently broken due to changes in the Parser and
should be disabled in
Markus Laire wrote:
On 25 Aug 2002 at 23:01, Sean O'Rourke wrote:
I got new cvs and applied same 2 patches (dlopen-patch imcc-patch)
only t/rx/basic.{3,4} fails, both with same error:
Please rebuild the grammar (there is currently no Makefile autmagic for
this):
$ perl6 --force -v
Markus Laire wrote:
On 27 Aug 2002 at 1:49, Mike Lambert wrote:
With following commands ALL perl6 tests pass. NO skipped or failed
tests, not even those 8_5 and 8_6.
These failures are somwhere hidden in the test scripts.
With
Configure.pl cd languages\perl6 make make test
make
Andy Dougherty wrote:
I note that currently imcc uses Bison and Flex. Is there any compelling
reason for this? I've sort of got it working with Sun's yacc and flex. Do
folks think it would be worthwhile for me to polish things up a bit and
post patches so it builds fine with either?
Send
Hi,
examples/life-ar.p6 uses a rather lengthy initialisation
my world = (
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
...
}; # 512 values
then tries to figure out, how many generations to run:
my $gen = ARGS[0] || 512;
at this point, ARGS[0] aka P0[1] aka argv[1] is
Andy Dougherty wrote:
... make the barrier to running languages/perl6 as low as possible,
My concerns too.
(Some history)
- I sent all the patches to get P6C running with 5.005_03
- I'm currently 95% maintaining/pushing the per6 driver (perl6)
- last ~50 Kb imcc patches originated from my
Mike Lambert wrote:
Is there any fundamental reason why we *cannot* just enter a generated
imcparser.c and imcparser.h into CVS and save users the step of building
them on these platforms?
Ack, so we should just delete the lines:
imclexer.c
imcparser.c
imcparser.h
from .cvsignor
Mike
Mike Lambert wrote:
... Attached patch gets IMCC building on MSVC without
cygwin (lex/bison/yacc/etc).
Good.
t/rx/basic.t 2 512 52 40.00% 3-4
t/rx/call.t1 256 21 50.00% 2
Any idea on how to go about fixing the rx ones? They're failing on
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:
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
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
Angel Faus wrote:
Hi Leo,
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
Dan Sugalski (via RT) wrote:
We need to nail down what the directions mean.
This is, what I'm trying to do since quite a time.
... The IMCC and JIT folks
are the ones that care here.
Here is the IMCC folks speaking ;-)
... I've been working on the assumption that
an out means that
Nicholas Clark wrote:
1: the value in the register did/didn't change
2: the value of the thing referenced by the register did/didn't change
(possibly 2a and 2b being that the internals of the object didn't/might've
changed)
Actually, thinking now of an optimizer, we should know these
Steve Fink (via RT) wrote:
# New Ticket Created by Steve Fink
# Please include the string: [perl #17039]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17039
Why intarrary.pmc:
+=item Bpush(in PMC, in PMC)
Dan Sugalski wrote:
At 8:04 AM + 9/5/02, Leopold Toetsch (via RT) wrote:
Argh, someone reverted the patch in CVS, when changing some print
functions.
Please, this is core.ops
core.ops has currently:
- obvious errors e.g.
-inline op mul (out PMC, out PMC, out PMC) {
- wrong
The op_code() function in op_lib_t does look up an op_info_table entry
by the op's full_name. To accomplish this, the current implementation
builds via ops2c.pl basically a static hash table, which get's appended
to core_ops.c and core_ops_prederef.c.
My proposal is: build a hash table at
While I'm already at oplib, interpreter and predereferenced code, I've
another one:
Currently we have 3 incarnations of one core.ops:
- core_ops.c
- core_ops_cg.c
- core_ops_prederef.c
While the 1st and the the 3rd have an op_info_table (and and op lib
descriptor, core_ops_cg.c doesn't has
Nicholas Clark wrote:
On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote:
I like this idea. (but I've no idea of the subtle implications)
There are only PDB_eval, pxs.c and imcc as users currently, I can't
really see subtle implications whatsoever.
Where you thinking
Leon Brocard (via RT) wrote:
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17159]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17159
There is a problem building imcc under Mac OS
Kevin Falcone wrote:
LT == Leopold Toetsch [EMAIL PROTECTED] writes:
LT Leon Brocard (via RT) wrote:
# New Ticket Created by Leon Brocard # Please include the string:
[perl #17159]
LT Either remove -fno-common or do something like this:
Apple's perl5.6.0 has the following in ccflags
Leon Brocard wrote:
Leopold Toetsch sent the following bits through the ether:
And finally, in imc.c there is another »int n_spilled;«, please delete
this line.
Sorry,
leo
Leon Brocard wrote:
Leopold Toetsch sent the following bits through the ether:
Could you try my second proposal?
Sure. The patch I tried is attached, which fixes up a lot of the
warnings. However, I now get:
ld: multiple definitions of symbol _n_spilled
imcparser.o definition
Leon Brocard wrote:
Leopold Toetsch sent the following bits through the ether:
Cool, I've done the past two patches and it compiles but then fails to
compile parrot shared:
We are getting close ;-)
cc: unrecognized option `-shared'
And here probably helps the patch, that was sent
Here is a patch, that is selfcontained in packfile.c,
s/packfile/packout/
of course, sorry
leo
Let's first compare with a PerlArray:
(following snippet is from an imcc test file, in PASM syntax)
new P1, .PerlArray
new P0, .PerlArray
set P1[0], P0
set P0[1], 2
set I0, P1[0;1]
print I0= 2
i.e. P1[0;.. returns an array PMC, which, indexed by key_next, gives
the
Dan Sugalski wrote:
At 9:51 AM +0200 9/13/02, Leopold Toetsch wrote:
and is a perl6 %h{a}[0][1] a PASM P2[a;0;1]?
Yes.
Fine, thought so too, thanks for your quick answer.
I have already a patch for it, I'll make an entry in t/pmc/perlhash.t too.
_But_:
What about all these bogus
Dan Sugalski wrote:
First I want to thank you, for all the checkins.
(Please don't forget #17143, which makes predereferencing working)
Do we have any idea why GC's getting in the way here? I presume we have
GC bug, so we ought to track it down if we can.
I can only bring some hints:
-
Sean O'Rourke wrote:
On Mon, 16 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke wrote:
...it should inherit from some basic_scalar.pmc, that
implements this for scalars. default.pmc is no more this default scalar
type, it's a invalid.pmc.
Aggregates and Sub's and so on, don't need
Sean O'Rourke wrote:
On Tue, 17 Sep 2002, Leopold Toetsch wrote:
Yes of course. What once was in default.pmc will be scalar.pmc,
where all scalar like classes can inherit from.
And from which perlarray.pmc, perlhash.pmc, and (probably) a whole host of
other types that need scalar-like
Above docs state, that a gernal parrot op looks like this
op dest[dkey], src1[skey1], src2[skey2]
e.g.
add P0[P1], P2, P3[P4]
where P1 and P4 are keys and P0 and P3 are aggregates and P2 is a scalar.
Several questions arise from these pdd's:
1) Are above pdd's valid, WRT this 3 key opcodes?
Dan Sugalski wrote:
At 9:03 AM +0200 9/16/02, Leopold Toetsch wrote:
In PASM they look the same. But as Dan stated, and as tried to show in
my answer to Graham, the lookup succeeds only if the nested PMCs are
all of the correct type. This works now because an array doesn't
support
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
All 64 combinations would be a horror.
Indeed.
But I really vote for a predereferencing like solution.
I didn't really understand that part of your previous message, but I
don't see what
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
while (pc) {
argp1 = ...pmc_reg.registers[cur_opcode[1]];
if (*pc KEY1_MASK) {
key1 = ...pmc_reg.registers[cur_opcode[2]]; /* for p_k */
argp1 = get_keyed_entry(argp1
Should these be implemented:
- machine dependent, like now: (INTVAL)SELF-cache.num_val | ...
- SELF.get_integer() | ...
- or just throw an exception
leo
I did send a ~200KB patch do Dan (I supposed it to be to big for the list).
It implements the proposed class hierarchy:
default ... implementing almost nothing, throwing exceptions
| |
| scalar ... most of previous default
| |
| perlint, perlnum, ...
Sub
Continuation
It's
Piers Cawley wrote:
Happy birthday to me!
Congratulations.
... by my turning 35 on the 15th
44 on 16th - yes Sept.
and thanks for the kudos,
leo
2. Proposal for _keyed opcodes
--
The thread with subject pdd06_pasm, pdd08_keys: _keyed ops clearly
showes the shortcomings of the current _keyed opcodes and the
implementation of these.[1]
My first proposal WRT a solution (modifying the run loop) did not earn
much
As PBC files might be built from different core.ops aka core_ops.c, it
is necessary to add a fingerprint to PBC files, to validate, that the
interpreter uses the very same ops, when running the PBC.
- during make a fingerprint of core_ops.c is generated:
$ perl -pe's/\s//g' core_ops.c |
Sean O'Rourke wrote:
On Sat, 21 Sep 2002, Leopold Toetsch wrote:
As PBC files might be built from different core.ops aka core_ops.c, it
is necessary to add a fingerprint to PBC files, to validate, that the
interpreter uses the very same ops, when running the PBC.
- during make
I did cp t/pmc/intlist.t t/pmc/intlista.t and
s/\.IntList/\.PerlArray/g in the latter.
After implementing the missing pop-methods[1] in array.pmc I ran both:
$ time parrot t/pmc/intlist_2.pbc
I need a shower.
real0m0.097s
user0m0.090s
sys 0m0.000s
$ time parrot
Mike Lambert (via RT) wrote:
Now, trace_system_stack walks a ~1300 entries deeper stack in CGoto
run mode, because of the jump table in cg_core. Don't ask me about this
difference to 900 ops, gdb says so.
Ahh, good observation. (I'm more of a non-cgoto person myself ;).
My favorit is
Dan Sugalski wrote:
*) Spec the vtable changes
Starting from my proposal ...
Subject: [RFC] 2. Proposal for _keyed opcodes
I have some more implementation details, WRT _keyed.
- An aggregate should provide these vtable methods:
* entry_type ... get info about the aggregates storage
Sean O'Rourke (via RT) wrote:
What happens if you presize the PerlArray to its final size
Then it is of course faster, but this is not a real world proposal IMHO,
you don't know in advance the usage pattern, so you can't do this. Of
course, the memory management of array/PerlArray could be
I don't know, if this is a possible way to go, nor how portable the
malloc code really is - anyway I did hack together parrot with malloc.c
from http://gee.cs.oswego.edu/dl/html/malloc.html.
s also http://www.cs.utexas.edu/users/oops/papers.html.
The whole resource.c is replaced by calls to
Already in #17537
leo
Sean O'Rourke wrote:
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke (via RT) wrote:
The real-world version would increase the array's allocation by some fixed
multiple, e.g. double its size, which would still improve things from O(n)
to O(log n) reallocations. I suspect
Simon Cozens (via RT) wrote:
# New Ticket Created by Simon Cozens
# Please include the string: [perl #17560]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17560
It's used by stat.h on Darwin, at least.
Ah,
Andy Dougherty wrote:
On Mon, 23 Sep 2002, Leopold Toetsch wrote:
./imcc examples/sample.imc
This doesn't even compile on my computer.
Please try:
$ cd ../perl6
$ per6 --test [-r]
HTH
leo
Mike Lambert wrote:
The whole resource.c is replaced by calls to calloc/realloc (res.c),
add_free_buffer does free().
I think that's the problem right there. What exactly are you changing
to use this new calloc/malloc implementation? One approach is to modify
memory.c to use the new
Sean O'Rourke wrote:
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke wrote:
Exactly this is, what my recent patch actually did: list-chunk_list
holds pointers to chunks, an index lookup is one div more expensive
then in array.
It's not in #17549. Is it in an earlier patch
Steve Fink (via RT) wrote:
- In imcc.y:main(), the stacktop was being set to an uninitialized
value, making stackwalking sometimes *really* slow, sometimes crash,
and sometimes work perfectly fine.
Yes, already fixed
- My bison does not accept actions that do not end in a semicolon,
As already announced, I used the memory allocator from
http://gee.cs.oswego.edu/dl/html/malloc.html and tossed the collect system.
Description of changes:
- DOD is the same incl, stack_walk and so on
- resources.c is gone, no copying of memory, no string tails ...
- dead objects are free'd, the
or who applies what when and why or not? This questions arises
sometimes, so I'll ask.
Here is a list of current open patches in decreasing priority:
#17578 imcc including all fixes sent to the list except todays fix
by Andy.
- actually the 3rd fix summary IIRC I sent in (s. there for
Tom Hughes wrote:
#17578
Applied.
First of all, thank you for comitting these. I hate 3-way rediff's ;-)
#17193 necessary for imcc to write out PBC
Applied. Like you I don't like it much but there aren't any other
obviously better ways.
Yes, seems so.
I missed that when it went
Steve Fink wrote:
On Wed, Sep 25, 2002 at 11:44:11PM +0200, Leopold Toetsch wrote:
or who applies what when and why or not? This questions arises
sometimes, so I'll ask.
If people don't have the time to look at it, it's ok. But then, it would
be fine, if I could checkin at least
Tom Hughes wrote:
In message lists.perl6.internals/[EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
#17353/17323 test for Parrot_sprintf
Applied.
Thank you.
... The outstanding question here is anyop.h
and anyop.c in languages/imcc as they are not built, and seem
Tom Hughes wrote:
In message lists.perl6.internals/[EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
#17549, 17569 intlist bugfix, speedup, test
Applied.
Thanks again for all the checkins.
One slight query I had was the meaning of the extra parameter added
H.Merijn Brand wrote:
a5:/pro/3gl/CPAN/parrot 116 cat .timestamp
1033023609
Thu Sep 26 07:00:09 2002 UTC
(time of this cvs update)
a5:/pro/3gl/CPAN/parrot 117
parrot all OK
perl t/harness
t/builtins/array.Can't bless non-reference value at ../../assemble.pl line 163.
#
Peter Sinnott wrote:
So we have ...
$ perl6 --test
Looks bad as above
$ perl6 --test -r
All tests successful, 2 subtests skipped.
imcc seems not to produce valid PASM files for your environment in
most of the cases. Running them directly is ok.
Hhm - could you track this
Dan Sugalski wrote:
At 5:40 PM +0100 9/26/02, Peter Sinnott wrote:
I'm running linux on intel with perl 5.6.1.
Please run:
$ perl6 --force-grammar --test
$ perl6 --test -r
both ought to succeed on your platform.
And I'm seeing it on OS X with 5.6.0. Okay, we're doing something screwy
I have some questions and suggestions regarding PMCs, Buffers and memory
management/internal data structures.
First and foremost, is there any compelling reason, to have totally
different structures for PMCs and Buffers?
- Both have a -data aka -bufstart
- Both have -flags, that have vastly the
H.Merijn Brand (via RT) wrote:
Attached patch fixed the make --test problem, reported by Tanton et al.
no dashes I may hope?
Argh, yes of course, lack of coffee early in the morning ...
# make test
should be the same as
# perl6 --test
If I followed the discussion correct
They
Steve Fink wrote:
To expand on that: the currently commented-out dependency on
Configure.pl in the makefile is wrong. It says the $(STICKY_FILES)
depend only on the Configure.pl script itself, which is woefully
incomplete:
There are a lot more dependencies, that are uncovered:
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
I applied this to my checkout (with _intlist_new renamed to
allocate_chunk because names starting with _ are reserved).
Ah, didn't know that - ok changed too.
Unfortunately it doesn't test
Mike Lambert wrote:
First and foremost, is there any compelling reason, to have totally
different structures for PMCs and Buffers?
- Both have a -data aka -bufstart
- Both have -flags, that have vastly the same meaning.
As jason said in another message, Dan has changed his mind from
As already posted I incorparated the allocator from
http://gee.cs.oswego.edu/dl/html/malloc.html
in parrot.
Some remarks:
- it's totally stable now, runs all tests (parrot and perl6)
- memory consumption is like CVS or much less ...
- ... if resources.c is unpatched (#17702)
- runs almost[1]
Dan Sugalski wrote:
At 2:01 PM +0200 10/2/02, Leopold Toetsch wrote:
As already posted I incorparated the allocator from
http://gee.cs.oswego.edu/dl/html/malloc.html
in parrot.
Some remarks:
- it's totally stable now, runs all tests (parrot and perl6)
- memory consumption is like CVS
Peter Gibbs wrote:
I have been looking at other areas for improvements.
Arrays seem to be one such area, ...
Yep
This is using a singly linked list of variable sized chunks,
without a separate index array. Each chunk is created
with a minimum size (4 entries at present), then doubled
Nicholas Clark wrote:
digression
Which in C terms scares me, as *how* can the allocator know for sure?
Sure it can stack walk, and probe all the CPU registers for pointers to buffers,
but there are defined C behaviours you can do (such as storing only a pointer
somewhere into your buffer
Peter Gibbs wrote:
Simon Cozens wrote:
Put another loop in, which sets I1 to every array element in turn,
(maybe make this an inner loop which runs each time you extend) and
re-benchmark.
25000: CVS = 47 seconds, grey = 1 second
Please compare to intlist.
leo
I did post 3 major proposals for the next big changes in parrot
internals - but I'm lacking somehow final answers on these.
There seems to be a general consens to do these changes though.
So here is a summary of the next changes to parrot:
1) restructure class dependencies
(s. #17352,
After my posting Status of my patches a lot of patches went in -
thanks again to Tom. But now unapplied patches accumulate again e.g.
imcc, perl6 examples ...
So please ...
leo
1 - 100 of 4900 matches
Mail list logo
