Re: t/src/manifest.t failed
On Wednesday 18 May 2005 07:52, Leopold Toetsch wrote:
Dino Morelli wrote:
I'm seeing the following test failure at r8113
t/src/manifestNOK 6# Failed test (t/src/manifest.t at line 79)
I'd say we just drop this test. Whenever you do reasoanble work in the
working tree, you got test files, editor swap file and whatnot.
The original version of t/src/manifest.t which i have written back in 2002
just tests that version control (CVS at that time) and MANIFEST are in sync.
There were no checks for extra file, because this would lead exact to the
above effects.
Still it is one of the most often failing tests, because people tend to
forget to update MANIFEST when adding files to CVS.
Garret Goebel wrote a commitinfo file which warned a commiter if he/she
forgot to update the MANIFEST.
I have an updated version of t/src/manifest.t I was about to commit but is
now conflicting with this latest version.
This new manifest.t introduces no new features (checking of MANIFEST.SKIP)
but just changes from CVS to SVN. While at it, I removed the reliance on
the interal files like CVS/Entries. In SVN this is no longer necessary
because working Perl-Bindings exist. A new version for the precommit-script
is still to be investigated.
I can commit this version, but first I want to reach consensus if this is
the right way to go.
bye
boe
#! perl -w
# Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
# $Id: manifest.t 7803 2005-04-11 13:37:27Z leo $
=head1 NAME
t/src/manifest.t - MANIFEST File
=head1 SYNOPSIS
% perl -Ilib t/src/manifest.t
=head1 DESCRIPTION
Checks that the distribution and the MANIFEST file agree.
=cut
use Test::More tests = 4;
use strict;
no warnings qw(once);
use ExtUtils::Manifest;
use Cwd;
ok (-e $ExtUtils::Manifest::MANIFEST, 'MANIFEST exists');
$ExtUtils::Manifest::Quiet = 1;
my @missing = ExtUtils::Manifest::manicheck ();
unless (ok ([EMAIL PROTECTED], 'manicheck ()')) {
print # Missing files:\n;
print # $_\n foreach @missing;
}
sub svn_check;
SKIP: {
if (-e '.svn') {
eval {
require SVN::Client;
require SVN::Wc;
};
if ($@) {
skip ('SVN Perlbindings not installed', 2);
}
svn_check;
}
# XXX: somebody can add SVK tests here
else {
skip ('Not under version control', 2);
}
}
sub svn_check {
my (@mani_miss, @svn_miss);
my $cwd = cwd ();
my %manifest = ();
{
my $manifest = ExtUtils::Manifest::maniread ();
while (my ($key, $value) = each %$manifest) {
$key = $cwd/$key;
$manifest{$key} = $value;
}
}
my $ctx = new SVN::Client;
$ctx-status ($cwd, 'WORKING', \check_func, 1, 1, 0, 1);
sub check_func () {
my ($path, $status) = @_;
my $textstatus = $status-text_status();
if ($textstatus == $SVN::Wc::Status::normal) {
push @mani_miss, $path
unless -d $path or exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::modified) {
push @mani_miss, $path [modified]
unless -d $path or exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::conflicted) {
push @mani_miss, $path [conflicted]
unless -d $path or exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::added) {
push @mani_miss, $path [added]
unless -d $path or exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::replaced) {
push @mani_miss, $path [re-added]
unless -d $path or exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::missing) {
# This is a bit strange the file is still in SVN
# but missing in the WC
push @mani_miss, $path [missing]
unless -d $path or exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::unversioned) {
push @svn_miss, $path
if exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::ignored) {
push @svn_miss, $path [ignored]
if exists $manifest{$path};
}
elsif ($textstatus == $SVN::Wc::Status::deleted) {
push @svn_miss, $path [deleted]
if exists $manifest{$path};
}
else {
# Unknown $textstatus, output some debuginfo
print # [$textstatus] $path\n;
}
}
local $ = \n\t;
ok ([EMAIL PROTECTED], 'all files in MANIFEST are in SVN')
or diag (Missing files in SVN:[EMAIL PROTECTED]);
ok ([EMAIL PROTECTED], 'all files in SVN are in MANIFEST')
or diag (Missing files in MANIFEST:[EMAIL PROTECTED]);
}
Re: t/src/manifest.t failed
On Wednesday 18 May 2005 20:14, Bernhard Schmalhofer wrote: [...] That's the same as checking that all files in SVN are also in MANIFEST. So a list diff between 'MANIFEST' and 'svn list -R' should be in t/src/manifest.t. Currently this is not checked in 't/src/manifest.t', but I think it is in Jürgens version. It was checked in the old CVS version. [...] Should I do a merge? Using the SVN Perl bindings make the code much nicer. I will do it, but I need some time. I have a day-time job. bye boe
Remove .cvsignore?
Hello, In the current SVN repository are 76 .cvsignore files. In SVN they aren't used any more. SVN uses the property 'svn:ignore' on a directory instead. During the cvs = svn transition the svn:ignore properties were set but in the recent weeks they started to diverge. Currently (r8078) 22 .cvsignore differ from svn:ignore (see attached cvsignore.diff) I think we should remove .cvsignore files entirly. Comments boe --- - 2005-05-12 20:03:42.864772000 +0200 +++ ./build_tools/.cvsignore 2005-05-11 20:01:02.0 +0200 @@ -0,0 +1 @@ +build_dynclasses.pl --- - 2005-05-12 20:03:42.971765000 +0200 +++ ./runtime/parrot/dynext/.cvsignore 2005-05-11 20:01:02.0 +0200 @@ -2,4 +2,3 @@ libnci.* *.bundle *.so - --- - 2005-05-12 20:03:42.995894000 +0200 +++ ./src/.cvsignore 2005-05-11 20:01:02.0 +0200 @@ -1,9 +1,13 @@ core_pmcs.c exec_cpu.c fingerprint.c +install_config.c jit_cpu.c nci.c +null_config.c +parrot_config.c platform.c platform_asm.s parrot_config.h +revision.c *.str --- - 2005-05-12 20:03:43.008638000 +0200 +++ ./docs/ops/.cvsignore 2005-04-11 23:51:16.0 +0200 @@ -1 +1,2 @@ *.pod + --- - 2005-05-12 20:03:43.084624000 +0200 +++ ./imcc/t/syn/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1,2 +1,3 @@ -*.imc +*.pir *.pbc +const_8.pasm --- - 2005-05-12 20:03:43.095574000 +0200 +++ ./imcc/t/imcpasm/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1 +1 @@ -*.imc +*.pir --- - 2005-05-12 20:03:43.106366000 +0200 +++ ./imcc/t/reg/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1,2 +1,2 @@ -*.imc +*.pir *.pbc --- - 2005-05-12 20:03:43.19647 +0200 +++ ./compilers/pge/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1,4 +1,3 @@ Makefile +PGE.pbc *.dylib -*.so - --- - 2005-05-12 20:03:43.210725000 +0200 +++ ./t/pmc/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1,4 +1,4 @@ -*.imc +*.pir *.pasm *.pbc *.out --- - 2005-05-12 20:03:43.234537000 +0200 +++ ./t/dynclass/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1,2 +1,2 @@ -*.imc +*.pir *.pbc --- - 2005-05-12 20:03:43.24462 +0200 +++ ./t/library/.cvsignore 2005-05-11 20:01:03.0 +0200 @@ -1,4 +1,4 @@ -*.imc +*.pir *.pasm *.pbc *.out --- - 2005-05-12 20:03:43.268047000 +0200 +++ ./t/op/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -1,4 +1,4 @@ *.pasm *.pbc *.out -*.imc +*.pir --- - 2005-05-12 20:03:43.369517000 +0200 +++ ./languages/m4/t/regex/.cvsignore 2005-05-10 06:39:27.0 +0200 @@ -1 +1 @@ -*.imc +*.pir --- - 2005-05-12 20:03:43.464287000 +0200 +++ ./languages/tcl/classes/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -0,0 +1,2 @@ +*.dump +*.c --- - 2005-05-12 20:03:43.658518000 +0200 +++ ./languages/urm/t/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -1 +1,3 @@ -testpars.pasm +*.pasm +*.out +*.urm --- - 2005-05-12 20:03:43.677463000 +0200 +++ ./languages/scheme/t/arith/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -0,0 +1,3 @@ +*.out +*.pasm +*.scheme --- - 2005-05-12 20:03:43.692089000 +0200 +++ ./languages/scheme/t/io/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -0,0 +1,3 @@ +*.out +*.pasm +*.scheme --- - 2005-05-12 20:03:43.702861000 +0200 +++ ./languages/scheme/t/logic/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -0,0 +1,3 @@ +*.out +*.pasm +*.scheme --- - 2005-05-12 20:03:43.778116000 +0200 +++ ./languages/cola/.cvsignore 2005-04-11 23:51:46.0 +0200 @@ -5,4 +5,4 @@ a.pasm colacc imcc -Makefile +Makefile \ No newline at end of file --- - 2005-05-12 20:03:43.802516000 +0200 +++ ./languages/lisp/.cvsignore 2005-05-11 20:01:04.0 +0200 @@ -0,0 +1,2 @@ +Makefile +lisp.pbc --- - 2005-05-12 20:03:43.808547000 +0200 +++ ./dynclasses/.cvsignore 2005-05-11 20:01:05.0 +0200 @@ -1,9 +1,7 @@ Makefile -build.pl *.dump *.c *.h *.dylib *.bundle *.so - --- - 2005-05-12 20:03:43.86027 +0200 +++ ./.cvsignore 2005-05-11 20:01:05.0 +0200 @@ -1,8 +1,10 @@ +CFLAGS +Makefile all_cstring.str blib config_lib.pasm libparrot.def -Makefile +miniparrot myconfig *.patch *.tmp @@ -10,6 +12,7 @@ parrot.pdb test test.c +test.err test.o test.cco test.ilk @@ -18,7 +21,6 @@ test.pdb vc60.pdb vc70.pdb -CFLAGS disassemble pbc_info pdb
Re: Bug in Boolean.pmc
On Friday 06 May 2005 18:17, John Lenz wrote: Hi, the following test fails because boolean.pmc actually registers the global True as a false boolean, and no boolean for False. It is fixed with the patch below. John find_global P0, True find_global P1, False if P0, L1 print Error, True is not true L1: unless P1, L2 print Error, False is not false L2: end I just committed a slightly modified version of this BugReprodutionRecipe as test in t/pmc/boolean.t juergen
Re: [perl #34959] config/auto/gmp/gmp.in returns 1 instead of 0
On Thursday 14 April 2005 08:36, Leopold Toetsch wrote:
Lambeck [EMAIL PROTECTED] wrote:
Hi all,
Configure.pl failed to find the GNU Math Lib (GMP) on my system
eventhough it is installed properly (version 4.1.4) .
I compiled config/auto/gmp/gmp.in by hand and it returned:
4950 1 but expected was:
4950 0
Everything seems to be right, except that mpz_fits_slong_p(k) returned
1 instead of 0. Could not find anything usefull to explain what it
means. I am on amd64 running Linux.
^
Yeah. The test is bogus for 64-bit systems. The tested number fits
within a 64-bit long. Could you please patch gmp.in and gmp.pl to use
some bigger numbers 64 bit.
I changed the test to calculate a mersenne prime number. I have tested it
on amd 64 and it finds amd64.
Ok to commit?
boe
Index: config/auto/gmp/gmp.in
===
--- config/auto/gmp/gmp.in (revision 7853)
+++ config/auto/gmp/gmp.in (working copy)
@@ -7,21 +7,17 @@
int main(int argc, char *argv[])
{
-mpz_t i, j, k;
+mpz_t prime;
char *s; int y;
-mpz_init(i);
-mpz_set_si(i, 99);
-mpz_init(j);
-mpz_set_si(j, 100);
-mpz_init(k);
-mpz_mul(k, i, j);
-mpz_set_si(i, 2);
-mpz_div(k, k, i);
+/* Calculate the 13th Mersenne prime 2^521 - 1 */
+mpz_init(prime);
+mpz_ui_pow_ui(prime, 2, 521);
+mpz_sub_ui(prime, prime, 1);
-y = mpz_fits_slong_p(k);
+y = mpz_fits_slong_p(prime);
-s = mpz_get_str(NULL, 10, k);
+s = mpz_get_str(NULL, 10, prime);
printf(%s %d\n, s, y);
free(s);
return 0;
Index: config/auto/gmp.pl
===
--- config/auto/gmp.pl (revision 7853)
+++ config/auto/gmp.pl (working copy)
@@ -55,7 +55,7 @@
my $has_gmp = 0;
if (! $@) {
my $test = cc_run();
- if ($test eq 4950 0\n) {
+ if ($test eq 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151 0\n) {
$has_gmp = 1;
print (yes) if $verbose;
$Configure::Step::result = 'yes';
Re: [perl #27969] [BUG] ParrotIO crash
Leopold Toetsch [EMAIL PROTECTED] writes: Causes a crash, instead of raising an exception. as probably any other IO opcode. Proper error handling for IO is much work and a lot of fun. Patches welcome. These were things I wanted to do quite a while ago, but then I got a new job, moved too a new town, had no connection to the internet. At the moment I work through a huge backlog of mails and try to get familar with the recent changes of the code. So don't hold your breath. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
How to raise an exception inside a PMC?
Hi, I'm just wondering how I should raise an exception inside a vtable function. I found the function real_exception, but I don't know what to put into the *dest argument. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
Leopold Toetsch [EMAIL PROTECTED] writes:
While playing with calling threaded subs, I came along a thing which I
think might be suboptimal:
pdd03 states that the method PMC should go into P2. This doesn't
really play with Perl5 - Perl6 interoperbility IMHO. Perl5 methods
are plain subs, where the first param is the object. I dunno, if Ponie
will ever use ParrotClass/ParrotObject, but I'm sure, that calling
Perl6 methods should work (and vv). So me thinks that the method PMC
should be the first PMC argument living in P5.
When I was experimenting with native methods in ParrotIO.pmc i had
also the problem that there was no way to put the P2 register to the
argument list. I don't know if this changed since then, but I had
put the object to P5.
sub meth {
my ($self, $arg1) = @_;
#P5P6
...
This makes a method-call and a sub-call more symetric. Both a method
object and a sub object are called via
invokecc P0
and returned with
invoke P1
the difference between them is currently that a method will use one more
register for the data transfer: P2
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: pdd03 and method calls
Dan Sugalski [EMAIL PROTECTED] writes: PDD 03 states that the *object* goes in P2. This works out just fine with perl 5 style method calls, where the argument list doesn't distinguish the object other than by position. What happens is that when a perl 5 sub is called, @_ is a combination of P2 if it's non-NULL, and the remaining PMC registers. It's slightly more work for the perl 5 code generator to handle the check, but other than that it shouldn't be a problem. It is missing from PDD03 that P2 must be set to NULL in case of a normal subroutine call. Otherwise P2 can contain everything and the called function has no way to decide if the data is valid. An other possibility would be to let invoke set P2 to null, but I don't like the idea of having more sideeffects in invoke. This also makes it impossible to write callmeth as: find_method P0, P2, S0 invoke P0 bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [24576] Some new targets in makefiles/root.in
If nobody objects to this I will apply this patch in 3 days (I think this is a reasonable time) Ok, time is up, committed boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfC] Testing for null
Hi, I'm curently playing around with open calls returning a PMCNULL instead of a half valid IO-Object. But the main problem with that is that there is currently no way for the byte-code to detect such a case. The if and unless ops call the get_boolean vtable method which throws an internal exception. As we can create a PMCNULL with the null_p op there should at least be a way to test for a PMCNULL. Two possible solutions come to my mind * A PMCNULL has false semantics. This may be done by letting get_boolean return FALSE, or by adding a test to if_p_ic op: if(!PMC_IS_NULL($1) $1-vtable-get_boolean($1)) * Have a special op for this if_null and unless_null which exlusively test for NULL. Comments boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] Testing for null
Melvin Smith [EMAIL PROTECTED] writes: [...] My intention for PMCNULL was to catch invalid interpreter state, or invalid bytecode; cases which used to give us core dumps. Explicitly returning PMCNULL and allowing tests on PMCNULL may or may not fit into this, depending on your point of view. I'm not even certain what my view of it is. Allowing ANY valid test on PMCNULL seems to muddy the water by allowing it to actually be used. There is currently a way of creating such an object: null P0 But you can't do anything with this object. If there are valid reasons to create such an object, there should be a way to test for it. The question is: should we allow a NULL register test and would this replace Undef as the de facto way to return nothing. Probably the answer is yes but I'd like to hear Dan's take on it. There is currently no general Undef, only a PerlUndef, which warns if used and morphs to a PerlInt when incremented. It might be best to create a undef.pmc. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: cvs commit: parrot/config/gen/makefiles root.in
Leopold Toetsch [EMAIL PROTECTED] writes:
Andy Dougherty [EMAIL PROTECTED] wrote:
Sorry, I guess I should have been more explicit. What folks apparently do
is have the sources on an NFS server mounted read-only. They then build a
symlink tree onto a local read-write filesystem and run the build there.
Thus they can create all the new files they want, but they can't touch or
change the source files.
That works except for the imc{parser,lexer} generated files. But we
could remove touching these files. When Configure.pl --maintainer was
run, you probably have the tools to create these files.
Some different idea:
Rename imc{parser,lexer}.[ch] files in CVS to
imc{parser,lexer}_c.generated. In non--maintainer mode these files are
simply copied, wheras in --maintainer mode the files are regenerated
from the sources imcc.[ly]. I think gcc uses something similar.
I don't think we even need to preserve the history
imc{parser,lexer}.[ch]; they are generated files anyway.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24576] Some new targets in makefiles/root.in
Bernhard Schmalhofer (via RT) [EMAIL PROTECTED] writes: languages.in: - add $(MAKE_C) befunge clean in target 'clean' root.in: - add target 'help': This should give a basic overview of what can be done with the Makefile - add target 'languages-clean': I needed that for testing - add target 'docs-clean': This seems to be consistent - add a '@' in 'flags-dummy': Compiling with should be printed only once - add target 'patch': generate a patch, when there are diffs to CVS, seems to be useful to me All these items are good. I also did some reformating of lists in 'root.in'. This is of course a matter of taste. I don't like tabs in lists. As tabs have a defined meaning in targets, I find it confusing to see them in macro assignments. This change touches many lines. This will invalidate many outstanding patches, which often need to change root.in. Anyway I think you are right, tabs don't belong in list definitions, and I also like the convention using a single line per item; this makes future diffs simpler. If nobody objects to this I will apply this patch in 3 days (I think this is a reasonable time) bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: cvs commit: parrot/config/gen/makefiles root.in
Leopold Toetsch [EMAIL PROTECTED] writes:
JüRgen BöMmels [EMAIL PROTECTED] wrote:
+TOUCH = $(PERL) -e ${PQ}open(A,qq{$$_}) or die foreach @ARGV${PQ}
Well done. *But* this f*cking command does still not update time stamps.
Is this a Perl5 failure? Anyway, we need a (golfy) touch equivalent for
these poor systems not providing one.
Appending nothing is not a modification (on Linux). Try this:
cat /dev/null imcc.flag
mtime does not change.
How about this? Its from perldoc -f utime:
TOUCH = $(PERL) -e ${PQ}$now = time; utime $now, $now, @ARGV;${PQ}
I don't know if it works reliable on Windows.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[CVS ci] --verbose flag to Configure.pl
Debugging configuration problems is a major problem. See e.g. the thread: configure on windows Therefor I just added a switch --verbose to Configure.pl. It does two things. First it outputs all changes to configuration data so you can trace the effects of the individual tests. Second it shows the commandline of all externally run (test)programs and also its output. This is done in the same way as in Parrot::Test.pm so it should work on windows too. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [PATCH] pio_win32_open fix
Vladimir Lipsky [EMAIL PROTECTED] writes: Hey unix folks, does test 10 in t/src/io.t succed on your OS? Yes, I just tested it again. patch applied. boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: PIO_eof
Melvin Smith [EMAIL PROTECTED] writes:
At 11:45 AM 11/24/2003 +0300, Vladimir Lipsky wrote:
Hi everyone!
In t/src/io.c, specifically test 9 and 10, I wonder if the PIO_eof check up
works anywhere; because I didn't manage to find any place where the
PIO_F_EOF flag is set up when the PIO_*_open function fails neither
in io_stdio.c, io_unix.c nor io_win32.c
In PIO_open the ParrotIO object never gets created if there is
an error condition.
But PIO_open returns a valid IO-PMC which just has a NULL in its data
segment. Maybe it should return PMCNULL if the open fails.
BTW: None of the PIO_* functions check if the incoming PMC is really a IO-PMC.
Maybe its a good idea to add glib-like return_if_fail like assertion
in the beginning of the functions. This reduces the speed but makes
debugging easier. Toughts?
PIO_eof() returns true if the PMC has a null IO object or if
the PIO_F_EOF flag is set.
Is the io == NULL testing prohibited in Parrot embedding system?
0x4c56
Currently it isn't prohibitied. That is the only way to detect an error
from PIO_open* at this time.
No, even that is wrong. PIO_open returns a PMC with NULL data.
So the test would be PMC_data(io) == NULL, but I think the better idea
is to return PMCNULL.
If someone convinces me that it is better to return a ParrotIO object
with error flags set rather than skip creating it, I might consider it.
No, I think we need to rethink the wrapping technology (which I
introduced). Something like:
struct parrot_io_t {
PObj pobj;
UINTVAL flags;
PIOHANDLE fd;
...
};
But this needs to allocate garbage-collected memory of
sizeof(struct parrot_io_t) instead of sizeof(PMC). I don't know if
something like that is already possible. Furthermore there are issues
with morph: You simply just can't morph another object to an IO
without reallocation.
It is probably more likely that we simply need documentation.
Sure, documentation is missing.
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Some random remarks
Matt Fowles [EMAIL PROTECTED] writes: All~ We could try to keep the opcode count down by simply having a seed opcode and an opcode to produce n random bytes... Anyone who wants more specific ranges could do the modulus and addition themselves. The modulus/addition trick is very common but actually a bad idea. See Press et al., Numerical Recipies in C, 2nd ed. or Linux rand(3): If you want to generate a random integer between 1 and 10, you should always do it by using high-order bits, as in j=1+(int) (10.0*rand()/(RAND_MAX+1.0)); and never by anything resembling j=1+(rand() % 10); (which uses lower-order bits). The best way to avoid this add/mod trick is to provide a convenient way to get random numbers in ranges. I like the basic idea of having different random number generators. But having only the integer valued level seems a little bit problematic to me. Its not easy extendable if you have some special needs on the random number generator. So I propose something completely new: Use a PMC. You don't need any special ops, only a special PMC. creating a random number generator. new P0, .RandomNumberGenerator getting a integervalued random number set I0, P0 getting a floatvalued random number set N0, P0 Special versions of the random number generator like other ranges can be created by initialisation arguments. Thoughs boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: configure on windows
Pete Lomax [EMAIL PROTECTED] writes: On 18 Nov 2003 18:37:57 +0100, Juergen Boemmels [EMAIL PROTECTED] wrote: I assume he runs it with perl Configure.pl --ask Yes snip The problem is that --ask option of has not the knowledge to change the options according to the compiler. I don't know a simple fix for this. A workaround solution to this is: Don't use --ask. Put the Compiler directly to the commandline perl Configure --cc=gcc# for MinGW perl Configure --cc=bcc32 # for Borland C++-Builder Maybe you need to add --jitcapable=0 or --cgoto=0 as well. That certainly moves things in the right direction. Determining if your C compiler is actually gcc... I had to laugh when that appeared! ;-) Some more errors, I still get lots of these three: gcc.exe: unrecognized option `-nologo' gcc.exe: unrecognized option `-nodefaultlib' gcc.exe: unrecognized option `-release' Are there any people out there building parrot on MinGW? config/init/hints/mswin32.pl is far from complete. Could you try out the attached patch. The options are just educated guesses, so you might have to play a little with them. Don't forget to rerun Configure to let your changes take effekt. test.c:2:21: pthread.h: No such file or directory (ENOENT) gcc.exe: test.o: No such file or directory (ENOENT) gcc.exe: no input files Bad command or file name test.c:2:23: arpa/inet.h: No such file or directory (ENOENT) test.c:2:21: sysexit.h: No such file or directory (ENOENT) test.c:2:24: sys/socket.h: No such file or directory (ENOENT) gcc is searching some system header files which are not found. Aren't these probed config/auto/headers.pl? BTW isn't the file call sysexits.h? test.o(.text+0x1b):test.c: undefined reference to `_memalign' collect2: ld returned 1 exit status test.o(.text+0x23):test.c: undefined reference to `_posix_memalign' collect2: ld returned 1 exit status test.c:12: error: parse error before set_handler test.c:12: error: parse error before __sighandler_t test.c: In function `set_handler': test.c:13: error: `__sighandler_t' undeclared (first use in this function) test.c:13: error: (Each undeclared identifier is reported only once test.c:13: error: for each function it appears in.) test.c:13: error: parse error before numeric constant It does finish, but this is what make does: D:\Parrot\Parrotmake echo Compiling with: Compiling with: Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. Use of uninitialized value in pattern match (m//) at tools\dev\cc_flags.pl line 54, F line 15. What does the file CFLAGS say? -nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -g -Dan_Sugalski -Larry -Wall -Ws D:\Parrot\perl\bin\perl.exe build_tools\ops2pm.pl ops/core.ops ops/bit.ops ops/c mp.ops ops/debug.ops ops/dotgnu.ops ops/io.ops ops/math.ops ops/object.ops ops/p mc.ops ops/rx.ops ops/set.ops ops/stack.ops ops/string.ops ops/sys.ops ops/var.o ps build_tools\ops2pm.pl: Could not find ops file 'ops/object.op'! make.exe: *** [lib\Parrot\OpLib\core.pm] Error 2 What make are you using? Could it be that it has problems with long commandlines? bye bö
Re: configure on windows
? $_
? languages/befunge/befunge.pbc
? t/src/headers.t
Index: config/init/hints/mswin32.pl
===
RCS file: /cvs/public/parrot/config/init/hints/mswin32.pl,v
retrieving revision 1.16
diff -u -r1.16 mswin32.pl
--- config/init/hints/mswin32.pl 15 Oct 2003 12:06:24 - 1.16
+++ config/init/hints/mswin32.pl 19 Nov 2003 14:30:26 -
@@ -95,6 +95,19 @@
Configure::Data-set(
link = 'gcc',
libs = $libs,
+ccflags= '-DWIN32 -DNO_STRICT -DNDEBUG -D_CONSOLE',
+cc_o_out = '-o ',
+cc_exe_out = '-o ',
+cc_debug = '-g',
+
+ld = ${cc},
+ldflags= '',
+ld_out = '-o ',
+cc_ldflags = '',
+ld_debug = '-g',
+ld_shared = '-mdll',
+libs = '-lmsvcrt'
+
slash = '\\',
ar= 'ar',
);
Re: configure on windows
they should be, though someone else may know. There is already a system for fixing these issue: hints/mswin32.pl. unfortunatly it is called to early to be useful for the ask option. Pete: I'm guessing you want to compile parrot for yourself. But if you just want a working Win32 parrot, then you can get a reasonably up to date binary build from http://www.jwcs.net/developers/perl/pow/ - latest one is 3 days old. Jonathan Hope this helps boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[CVS ci] Extra argument to PIO_open and PIO_fdopen
Hello, I just checked in a change to PIO_open and PIO_fdopen as discussed in the thread [RfC] (fd)open files on other layers than the default layer. I took the route Melvin suggested and added the layer argument directly to the PIO_(fd)open functions. The prototypes are now: PMC *PIO_open(theINTERP, ParrotIOLayer *, const char *, const char *); PMC *PIO_fdopen(theINTERP, ParrotIOLayer *, PIOHANDLE, const char *); If you put in NULL as second argument, you can get the old behaviour opening the file on the default layer. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Is this useful?
Leopold Toetsch [EMAIL PROTECTED] writes: BTW, inside parrot: $ find . -name '*.c' | xargs grep hash_get and you'll see another hash implementation. The disadvantage of this finds is that you get many generated files like core_ops_cg.c or classes/perlhash.c. To solve this problem, I have written some little helper script: manigrep.pl It just takes the MANIFEST and walks all files in it searching for a match. It can match fixed strings or /regular expressions/ and in contrast to the normal grep it also adds the line numbers. Do you think this tool should enter tools/dev ? bö manigrep.pl Description: Perl program
Re: HASH changes
Leopold Toetsch [EMAIL PROTECTED] writes:
[...]
void * hash_get(Interp * interpreter, HASH *hash, void *key);
HASHBUCKET * hash_get_bucket(Interp * interpreter, HASH *hash, void *key);
That's ok for me. For all of the normal Hash usage, we don't have NULL
values, so there is no ambuigity for the return value.
Attached patch implements this. Furthermore it implement hash_exists.
It does not break more tests than previously.
Is this ok to commit?
bö
Index: classes/perlhash.pmc
===
RCS file: /cvs/public/parrot/classes/perlhash.pmc,v
retrieving revision 1.57
diff -u -r1.57 perlhash.pmc
--- classes/perlhash.pmc 4 Nov 2003 18:33:04 - 1.57
+++ classes/perlhash.pmc 7 Nov 2003 15:09:43 -
@@ -1,4 +1,4 @@
- /* perlhash.pmc
+/* perlhash.pmc
* Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
* CVS Info
* $Id: perlhash.pmc,v 1.57 2003/11/04 18:33:04 leo Exp $
@@ -55,7 +55,8 @@
PMC* valpmc;
PMC* nextkey;
STRING* keystr = make_hash_key(INTERP, key);
- HASHBUCKET* b = hash_get(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
+ HASHBUCKET* b = hash_get_bucket(INTERP, (HASH*) PMC_ptr1v(SELF),
+keystr);
if (b == NULL) {
return enum_hash_undef;
}
@@ -79,7 +80,8 @@
INTVAL get_integer_keyed (PMC* key) {
PMC* valpmc;
STRING* keystr = make_hash_key(INTERP, key);
- HASHBUCKET *b = hash_get(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
+ HASHBUCKET *b = hash_get_bucket(INTERP, (HASH*) PMC_ptr1v(SELF),
+keystr);
PMC* nextkey;
if (b == NULL) {
/* XXX Warning: use of uninitialized value */
@@ -96,7 +98,8 @@
FLOATVAL get_number_keyed (PMC* key) {
PMC* valpmc;
STRING* keystr = make_hash_key(INTERP, key);
- HASHBUCKET *b = hash_get(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
+ HASHBUCKET *b = hash_get_bucket(INTERP, (HASH*) PMC_ptr1v(SELF),
+keystr);
PMC* nextkey;
if (b == NULL) {
/* XXX Warning: Use of uninitialized value */
@@ -112,7 +115,8 @@
BIGNUM* get_bignum_keyed (PMC* key) {
PMC* valpmc;
STRING* keystr = make_hash_key(INTERP, key);
- HASHBUCKET *b = hash_get(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
+ HASHBUCKET *b = hash_get_bucket(INTERP, (HASH*) PMC_ptr1v(SELF),
+keystr);
PMC* nextkey;
if (b == NULL) {
/* XXX Warning: Use of uninitialized value */
@@ -142,7 +146,7 @@
default:
keystr = make_hash_key(INTERP, key);
}
- b = hash_get(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
+ b = hash_get_bucket(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
if (b == NULL) {
/* XXX Warning: use of uninitialized value */
return VTABLE_get_string(INTERP, undef);
@@ -164,7 +168,8 @@
PMC* get_pmc_keyed (PMC* key) {
STRING* keystr = make_hash_key(INTERP, key);
- HASHBUCKET *b = hash_get(INTERP, (HASH*) PMC_ptr1v(SELF), keystr);
+ HASHBUCKET *b = hash_get_bucket(INTERP, (HASH*) PMC_ptr1v(SELF),
+keystr);
PMC* nextkey;
if (b == NULL) {
PMC *new_undef = pmc_new(INTERP, enum_class_PerlUndef);
@@ -223,7 +228,7 @@
HASHBUCKET *b;
sx = key_string(INTERP, key);
key = key_next(INTERP, key);
- b = hash_get(INTERP, h, sx);
+ b = hash_get_bucket(INTERP, h, sx);
if (b == NULL)
return 0; /* no such key */
if (key == NULL)
@@ -237,7 +242,7 @@
HASHBUCKET *b;
sx = key_string(INTERP, key);
key = key_next(INTERP, key);
- b = hash_get(INTERP, h, sx);
+ b = hash_get_bucket(INTERP, h, sx);
if (b == NULL)
return 0; /* no such key */
if (key == NULL)
@@ -252,7 +257,7 @@
HASHBUCKET *b;
sx = key_string(INTERP, key);
key = key_next(INTERP, key);
- b = hash_get(INTERP, h, sx);
+ b = hash_get_bucket(INTERP, h, sx);
if (b == NULL)
return; /* no such key */
else if (key == NULL)
Index: include/parrot/hash.h
===
RCS file: /cvs/public/parrot/include/parrot/hash.h,v
retrieving revision 1.17
diff -u -r1.17 hash.h
--- include/parrot/hash.h 4 Nov 2003 18:33:08 - 1.17
+++ include/parrot/hash.h 7 Nov 2003 15:09:44 -
@@ -72,7 +72,9 @@
INTVAL hash_size(Interp * interpreter, HASH *hash);
void hash_set_size(Interp * interpreter, HASH *hash, UINTVAL size);
void hash_destroy(Interp * interpreter, HASH *hash);
-HASHBUCKET *hash_get(Interp * interpreter, HASH *hash, void *key);
+HASHBUCKET *hash_get_bucket(Interp * interpreter, HASH *hash, void *key);
+void *hash_get(Interp * interpreter, HASH *hash, void *key);
+INTVAL hash_exists(Interp * interpreter, HASH *hash, void *key);
void hash_put(Interp * interpreter, HASH *hash, void *key, void *value);
void hash_delete(Interp * interpreter, HASH *hash, void *key);
void mark_hash(Interp * interpreter, HASH *hash);
Index: src/hash.c
===
RCS file:
HASH changes
Hi, the latest changes of HASH in src/hash.c makes t/src/hash.t fail badly. It did not even compile because of the prototype change in hash_new. Ok that was easy to fix and I have already a fix in my tree, which at least compiles cleanly. But I still have one problem: hash_put and hash_get are not symmetric. hash_put puts a void *value, but hash_get returns a HASHBUCKET. This looks wrong to me. I have no problem with value being a void* but hash_get should then return also a void *. If its really needed to get a bucket it should be done with a function hash_get_bucket. (But this really feels like exposing an implementation detail). Comments boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: HASH changes
Leopold Toetsch [EMAIL PROTECTED] writes: Juergen Boemmels [EMAIL PROTECTED] wrote: Hi, the latest changes of HASH in src/hash.c makes t/src/hash.t fail badly. Oops, sorry (but at least it isn't the only broken test currently :) I committed a partial fix. Now the tests are at least compiling. But I still have one problem: hash_put and hash_get are not symmetric. hash_put puts a void *value, but hash_get returns a HASHBUCKET. This looks wrong to me. When returning the value directly, we couldn't have NULL value's - or better NULL values and no entry at all would have the same return result. Yes this is a problem. I did a little research how other libraries solve this problem. Oh man, there are many of them. Far the most libraries return the value directly [1], some of them use a function to check if the key exists and set the value part as a side effect [2] and a third group uses an approach were creation is a side effect of lookup (sometimes controlled with a flag) and always return an key/value pair [3]. Glib for example use approaches [1] and [2]. Our current approach looks like a mixture of all these 3 cases. From the principle of least surprise, I suggest to let hash_get return a value pointer directly and have the ambiguity of NULL value and no entry, and have a hash_get_bucket which returns a pointer to the bucket. void * hash_get(Interp * interpreter, HASH *hash, void *key); HASHBUCKET * hash_get_bucket(Interp * interpreter, HASH *hash, void *key); Some other note. Didn't we decided some time ago to use only ALLCAPS types in cases were they are abbreviations. So the name would better be Hash and HashBucket. Additionally the returned bucket has the key inside, which could be useful. In cases where two keys compare equal but are not equal bitwise this is indeed nice. bye boe [1] http://oss.software.ibm.com/cvs/icu/icu/source/common/uhash.h?rev=1.24 http://developer.gnome.org/doc/API/2.0/glib/glib-Hash-Tables.html http://apr.apache.org/docs/apr/group__apr__hash.html http://www.w3.org/Library/src/HTHash.html http://mission.base.com/peter/source/pbl/doc/ http://judy.sourceforge.net/JudySL_3x.htm http://www.ipd.bth.se/ska/sim_home/libghthash_mk2_doc/ght__hash__table_8h.html http://dodgysoftware.net/ht/ http://chilli.degnet.de/~e_decker/hashtable/ [2] http://developer.gnome.org/doc/API/2.0/glib/glib-Hash-Tables.html http://www-2.cs.cmu.edu/~bwolen/fmcad98/packages/tiger/tgrlib/utilhash.html http://www.ohse.de/uwe/strhash/libstrhash.html http://www.stalphonsos.com/~attila/libgram/docs/hash_8h.html [3] http://www.gnu.org/manual/bfd-2.9.1/html_node/bfd_43.html http://www.gnu.org/software/libc/manual/html_node/Hash-Search-Function.html http://www.tcl.tk/man/tcl8.2.3/TclLib/Hash.htm -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] (fd)open files on other layers than the default layer.
Melvin Smith [EMAIL PROTECTED] writes: Hey Juergen, Here are a couple comments, At 03:18 PM 11/4/2003 +0100, Juergen Boemmels wrote: currently there is no (simple) way to open a file on an other layer than the default layer. But this is necessary if we want to take advantage from the layered approach. So i added two new functions: pio_open_with_layer and pio_fdopen_with_layer which create IO-Objects on different layers. I'm not keen on the names, but I didn't find better ones. An alternative is to add an optional layer parameter to PIO_open and company. If it is null you can use the default. Ok, but this means that all uses of PIO_open needs to be changed too. But greping through the source, they are not that many. But there are some issues: * During layer initialisation the layers want to register the handles for stdin, stdout and stderr. I went around this by conditionally only compiling the handle init if stdio is the base IO systems. Is this a good solution? It is probably time to have the layer specific init (PIO_unit_init, etc.) pass back an array of standard handles rather than explicilty setting them into the interpreter as it does now? This will allow us to ignore them at the top level if need be. You are right, currently it isn't really easy to mix terminal layers because of this. Yeah, might work. It can be an garbage collected array, there is already a PIO_data_mark. * I needed many casts from PIOHANDLE to FILE * and vice versa. I'm not sure if this one fits all approach of PIOHANDLE is the right way. Maybe its better to make PIOHANDLE a union. But what to do then with the fdopen and getfd ops. It is not guaranteed that a union can be casted to an INTVAL and back. I think it works with casts, unless there are cases where our INTVAL cannot hold a pointer. There are currently 2 cases: PIOHANDLE is a low level OS handle (UNIX or Win32) and we to create a ParrotIO around it. PIOHANDLE is a stdio FILE * and we need to create a ParrotIO around it. I'm really ok if the io_stdio.c is a mega hack since STDIO is only there for convenience and bootstrap where there is no other IO alternative. Is it always guaranteed that an pointer fits in an INTVAL? In either case, it is the bytecode op that is the unsure part, and whether we have to use the INTVAL type or we have to change it to a STRING buffer. Or a PMC. Either an PerlInt or an UnmanagedStruct. * Modifying the same file through different layers might lead to very unpredictable results. But thats already a problem with unix-handles/stdio-handles. What do you mean by modifying here? Two layers (write-)buffering independently. If one writes but not flushes, then the other on writes. But that problem is not new: fwrite(a, 1, 1, stdout); write(1, b, 1); fwrite(c, 1, 1, stdout); * PIO_isatty and PIO_getblksize are macros which are coded at compile-time to some layer, and not as read, write etc go through a LayerAPI. Those need to be changed as well. They break the whole layer plan, as you point out. Actually isatty() can be called inside PIO_fdopen and the result stored into the PIO header as a bit flag. Then PIO_isatty() can simply be a flag check against the PIO. Finally, the rest of the compile time macros definitely need to go away since they make it impossible to use 2 terminal layers at the same time. Will do that. boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] (fd)open files on other layers than the default layer.
Melvin Smith [EMAIL PROTECTED] writes: PIOHANDLE is a low level OS handle (UNIX or Win32) and we to create a ParrotIO around it. PIOHANDLE is a stdio FILE * and we need to create a ParrotIO around it. One more comment. I don't even see the possibility of calling fdopen from the bytecode level with a FILE *. From the bytecode level, either we know some OS constants that are typically streams (UNIX 0,1,2) or the call probably won't come from the bytecode. For the STDIO case, there is currently no way to even call fdopen() from bytecode with a valid parameter, it only works for the low level OS handles. The standard handles are already special cased in the ParrotIO, so they should not be a reason for fdopen. The main goal why I wanted to keep fdopen is in cases were parrot is embedded and the bytecode gets called with an external FILE * pointer. This might be for example yyin. But is it needed that this must be an opcode or can it be a method of some layer-object. It may not make sense to expose it, but I don't see how we can do without exposing it for UNIX and low level Win32 without exposing it for STDIO. 1 possible solution is: remove PIO_stdio_fdopen altogether and move the code to PIO_stdio_unit() which actually needs it. Or just set the FDOpen slot in ParrotIOLayerAPI to NULL. The function PIO_stdio_fdopen is static and should not leak out of io_stdio.c bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfC] (fd)open files on other layers than the default layer.
Hello,
currently there is no (simple) way to open a file on an other layer
than the default layer. But this is necessary if we want to take
advantage from the layered approach.
So i added two new functions: pio_open_with_layer and
pio_fdopen_with_layer which create IO-Objects on different layers. I'm
not keen on the names, but I didn't find better ones.
So to test this I need another layer on which I can open files: stdio
should be available on all systems. So far so good, now I can open
files on with stdio and fdopen existing handles.
But there are some issues:
* During layer initialisation the layers want to register the handles
for stdin, stdout and stderr. I went around this by conditionally
only compiling the handle init if stdio is the base IO systems.
Is this a good solution?
* I needed many casts from PIOHANDLE to FILE * and vice versa. I'm not
sure if this one fits all approach of PIOHANDLE is the right way.
Maybe its better to make PIOHANDLE a union. But what to do then
with the fdopen and getfd ops. It is not guaranteed that a union
can be casted to an INTVAL and back.
* Modifying the same file through different layers might lead to very
unpredictable results. But thats already a problem with
unix-handles/stdio-handles.
* PIO_isatty and PIO_getblksize are macros which are coded at
compile-time to some layer, and not as read, write etc go through a
LayerAPI.
Comments
bö
? icu/source/test
? languages/befunge/befunge.pbc
? t/src/headers.t
Index: include/parrot/io.h
===
RCS file: /cvs/public/parrot/include/parrot/io.h,v
retrieving revision 1.49
diff -u -r1.49 io.h
--- include/parrot/io.h 25 Oct 2003 05:40:08 - 1.49
+++ include/parrot/io.h 4 Nov 2003 14:15:32 -
@@ -261,7 +261,11 @@
extern INTVAL PIO_parse_open_flags(const char *flagstr);
extern PMC *PIO_open(theINTERP, const char *, const char *);
+extern PMC *PIO_open_with_layer(theINTERP, ParrotIOLayer *,
+const char *, const char *);
extern PMC *PIO_fdopen(theINTERP, PIOHANDLE, const char *);
+extern PMC *PIO_fdopen_with_layer(theINTERP, ParrotIOLayer *, PIOHANDLE,
+ const char *);
extern INTVAL PIO_close(theINTERP, PMC *);
extern void PIO_flush(theINTERP, PMC *);
extern INTVAL PIO_read(theINTERP, PMC *, void *, size_t);
Index: io/io.c
===
RCS file: /cvs/public/parrot/io/io.c,v
retrieving revision 1.70
diff -u -r1.70 io.c
--- io/io.c 30 Oct 2003 08:49:14 - 1.70
+++ io/io.c 4 Nov 2003 14:15:32 -
@@ -574,6 +574,25 @@
return new_io_pmc(interpreter, io);
}
+PMC *
+PIO_open_with_layer(theINTERP, ParrotIOLayer *layer,
+const char *spath, const char *sflags)
+{
+ParrotIO *io;
+INTVAL flags = PIO_parse_open_flags(sflags);
+
+io = PIO_open_down(interpreter, layer, spath, flags);
+/* io could be null here but we still have to
+ * to create a PMC for the caller, no PMCNULL here
+ * as that would cause an exception upon access.
+ */
+if (io) {
+io-stack = layer;
+}
+
+return new_io_pmc(interpreter, io);
+}
+
/*
* Create an IO object on an existing, open file descriptor.
@@ -595,6 +614,26 @@
*/
if (io) {
io-stack = l;
+}
+
+return new_io_pmc(interpreter, io);
+}
+
+
+PMC *
+PIO_fdopen_with_layer(theINTERP, ParrotIOLayer *layer, PIOHANDLE fd,
+ const char *sflags)
+{
+ParrotIO *io;
+INTVAL flags = PIO_parse_open_flags(sflags);
+
+io = PIO_fdopen_down(interpreter, layer, fd, flags);
+/* io could be null here but we still have to
+ * to create a PMC for the caller, no PMCNULL here
+ * as that would cause an exception upon access.
+ */
+if (io) {
+io-stack = layer;
}
return new_io_pmc(interpreter, io);
Index: io/io_stdio.c
===
RCS file: /cvs/public/parrot/io/io_stdio.c,v
retrieving revision 1.33
diff -u -r1.33 io_stdio.c
--- io/io_stdio.c 11 Oct 2003 13:15:30 - 1.33
+++ io/io_stdio.c 4 Nov 2003 14:15:32 -
@@ -19,7 +19,8 @@
#include parrot/parrot.h
#include io_private.h
-#ifdef PIO_OS_STDIO
+extern INTVAL PIO_stdio_isatty(PIOHANDLE fd);
+extern INTVAL PIO_stdio_getblksize(PIOHANDLE fd);
/* Defined at bottom */
extern ParrotIOLayerAPI pio_stdio_layer_api;
@@ -93,6 +94,8 @@
static INTVAL
PIO_stdio_init(theINTERP, ParrotIOLayer *layer)
{
+#ifdef PIO_OS_STDIO
+/* Only set standard handles if stdio is the OS IO */
PIO_STDIN(interpreter)
= new_io_pmc(interpreter,
PIO_stdio_fdopen(interpreter, layer, stdin, PIO_F_READ));
@@ -104,7 +107,7 @@
PIO_STDERR(interpreter)
= new_io_pmc(interpreter,
PIO_stdio_fdopen(interpreter, layer, stderr, PIO_F_WRITE));
-
+#endif /* PIO_OS_STDIO */
Re: [perl #24257] [PATCH] Integration of ICU to the build system
Jürgen Bömmels (via RT) [EMAIL PROTECTED] writes: The attached patch makes it an optional part of the normal build system. By using the switch --buildicu the ./configure of icu/source is run and the makefile is extended with rules for building and cleaning icu. This option is not enabled by default. Solving Warnocks dilemma by appling the patch. boe
Re: docs
Simon Glover [EMAIL PROTECTED] writes: On Mon, 3 Nov 2003, Dan Sugalski wrote: On Mon, 3 Nov 2003, Nick Kostirya wrote: Catalog docs\ops is empty in 0.0.13 version. Is it bug? I think that's leftover cruft. Well, we used to generate a .pod file for each .ops file, at build time, which lived in here. However, we don't appear to be doing this anymore (although I'm not sure when this changed). It's some left over error from The Great Move. The ops files were searched at the root of parrot not in the new ops directory. I'm just testing a fix, if it works I will commit it. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Tinderboxens
Nick Kostirya [EMAIL PROTECTED] writes: - Irresolute (FreeBSD) Configure is failing: Determining some sizes...Linker failed (see test.ldo) at lib/Parrot/Configure/Step.pm line 181. Question: what says test.ldo Linker failed have a place only for FreeBSD 4.x, over pthreads. I will do patch for config/init/hints/freebsd.pl. But is trifle, it is important what testing sys/socket.h for FreeBSD failed. See RT ticket #24329. Irresolute seems to work now. What have you done? I see include/parrot/parrot.h modified in your cvs checkout. Commenting to #24329: There is currently now way to test for headers on only one platform, but sys/types.h is general enough to get tested. In fact the test is already done in perl and we use these by default. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] Header Dependencies
Dan Sugalski [EMAIL PROTECTED] writes: On Mon, 27 Oct 2003, Juergen Boemmels wrote: Hi, Currently there 64 header files in include/parrot. From these 64 header files 36 can be included directly, i.e. #include parrot/embed.h will compile, but #include parrot/chartype.h will fail with errors. In the case of chartype this can be easily fixed [1]. Other headers are a little bit harder. Would it be a good idea to fix the other headers the same way? Well... I suppose, though I don't see much point. The headers are the way they are in part because the interdependencies between the pieces made it easiest to do it the way that we are. FreeBSD has problems exactly because of this problem: It needs some headers before others. What we need at least is respect our own conventions. I.e. no INTVALs out of PARROT_IN_CORE. The simplest solution would be: protect all of the headers with PARROT_IN_CORE. Most (though certainly not all) of the core source files will just include parrot.h, so I'm not sure how much work it's worth. I don't know if the reason for including parrot.h is only that using only the minimal set is really hard to get right. (More importantly, I think it'll decay pretty quickly) The attached test would ensure that it won't decay, if this test fails this is a regression. But I see your point. Keeping MANIFEST up to date is also a real problem, even though there is a test. But put it the other way. If we always want to include parrot.h why are there so many header-files and not only one big parrot.h bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24333] [PATCH] pthreads configure on FreeBSD
Lars Balker Rasmussen (via RT) [EMAIL PROTECTED] writes:
The pthreads library seems to be missing on the FreeBSD 4.8 and 5.0
machines I have access to. I don't know what, if any, FreeBSD'en
should happen to have that library...
There are two ways to link in the pthreads-stuff on FreeBSD - I have
taken the method from the ports systems makefile to decide between them.
I have another patch from Nick Kostirya [EMAIL PROTECTED] which
accidently dropped off-list. He tries to solve the same issue (and
uses a similar approach). But he changed ccflags. Can someone of the
FreeBSD guys enlighten me which of these two patches is the better
one? I can apply only one.
bye
bö
Index: config/init/hints/freebsd.pl
===
RCS file: /cvs/public/parrot/config/init/hints/freebsd.pl,v
retrieving revision 1.1
diff -u -r1.1 freebsd.pl
--- config/init/hints/freebsd.pl 10 Oct 2003 07:43:05 - 1.1
+++ config/init/hints/freebsd.pl 28 Oct 2003 14:19:41 -
@@ -1,7 +1,31 @@
+# 500016 is the first osreldate in which one could
+# just link against libc_r without disposing of libc
+# at the same time. 500016 ... up to whatever it was
+# on the 31st of August 2003 can still be used with -pthread,
+# but it is not necessary.
+my $osreldate = `/sbin/sysctl -n kern.osreldate`;
+
my $libs = Configure::Data-get('libs');
-if ( $libs !~ /-lpthreads/ ) {
-$libs .= ' -lpthreads';
+
+if ($osreldate = 500016) {
+ # use KSE (libpthread)
+ # See http://www.freebsd.org/kse/
+ if ( $libs !~ /-lpthreads/ ) {
+ $libs .= ' -lpthreads';
+ }
+} else {
+ # use libc_r
+ $libs =~ s/-lpthreads//;
+
+ my $ccflags = Configure::Data-get('ccflags');
+ if ( $ccflags !~ /-pthread/ ) {
+ $ccflags .= ' -pthread';
+ }
+ Configure::Data-set(
+ ccflags = $ccflags,
+ )
}
+
Configure::Data-set(
libs = $libs,
);
[CVS ci]: C Test changes
I just committed a change to Parrot::Test.pm If a c_output_* test fails to generate an executable the test fails instead of being silently ignored. Hopefully the printf(Done\n) trick is not necessary any more. Furthermore, if the C-Compiler fails to build an object-file the output of the C-Compiler is passed to the user instead of the rather useless linker error Failed to build 'test_1': cc: test_1.o: No such file or directory bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfC] Header Dependencies
Hi,
Currently there 64 header files in include/parrot. From these 64
header files 36 can be included directly, i.e.
#include parrot/embed.h
will compile, but
#include parrot/chartype.h
will fail with errors. In the case of chartype this can be easily
fixed [1].
Other headers are a little bit harder.
Would it be a good idea to fix the other headers the same way? This is
not a really hard task. A next step could be not simply include
parrot/parrot.h, but only the headers, that are really needed. This
is currently a real pain because some header files have hidden
asumptions to be included only after other header files.
A simple src test can enforce this policy [2].
Comments?
bö
Index: chartype.h
===
RCS file: /cvs/public/parrot/include/parrot/chartype.h,v
retrieving revision 1.19
diff -u -r1.19 chartype.h
--- chartype.h 23 Sep 2003 10:19:17 - 1.19
+++ chartype.h 27 Oct 2003 16:56:17 -
@@ -13,6 +13,8 @@
#if !defined(PARROT_CHARTYPE_H_GUARD)
#define PARROT_CHARTYPE_H_GUARD
+#include parrot/config.h
+
struct parrot_chartype_t;
typedef Parrot_UInt (*Parrot_CharType_Transcoder)
(const struct parrot_chartype_t *from,
@@ -32,8 +34,8 @@
* Character code to digit value translation map
*/
struct chartype_digit_map_t {
-UINTVAL first_code;
-UINTVAL last_code;
+Parrot_UInt first_code;
+Parrot_UInt last_code;
int first_value;
};
@@ -54,7 +56,7 @@
struct parrot_chartype_t {
-INTVAL index;
+Parrot_Int index;
const char *name;
const char *default_encoding;
Parrot_Int (*is_digit)
# perl -w
@headers = map { s!^include/!!; $_ } glob include/parrot/*.h;
require Parrot::Test;
import Parrot::Test tests = scalar @headers;
for $header ( @headers ) {
c_output_is(CODE, '', $header);
#include $header
int
main()
{
return 0;
}
CODE
}
Tinderboxens
Hi, I just took the time and looked through the failing tinderboxens: - sprite and ariete: They have an old dynoplibs/Makefile lying around, which leads to a failing MANIFEST check. Solution: just remove dynoplibs/Makefile. - adrastea Conflict in MANIFEST, which lets Configure.pl fail, and the Makefiles are not regenerated. Solution: Remove conflicts in MANIFEST - Irresolute (FreeBSD) Configure is failing: Determining some sizes...Linker failed (see test.ldo) at lib/Parrot/Configure/Step.pm line 181. Question: what says test.ldo - Irresolute (Windows) Fails in compiling jit_cpu.c: with d:\cvsprojects\parrot\src\jit_cpu.c(95) : error C2065: 'RTYPE_COM' :undeclared identifier hidden a huge bunch of warnings. Does JIT work on windows? Maybe it works if configured with --jitcapable=0 BTW: It does make but nmake test and make seems to fail right away. - actinium This is a harder error: # Failed to build 't/src/extend_1.o': ./include/parrot/extend.h, line 76.23: 1506-120 (S) Function cannot return a const qualified type. # ./include/parrot/extend.h, line 78.23: 1506-120 (S) Function cannot return a const qualified type. # Failed test (t/src/extend.t at line 7) The offending code section is: const Parrot_CharType Parrot_find_chartype(Parrot_INTERP, char*); Parrot_Language Parrot_find_language(Parrot_INTERP, char*); const Parrot_Encoding Parrot_find_encoding(Parrot_INTERP, char*); It seems like AIX does not like functions returning a const variable even though its a void *. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Object freezing
Leopold Toetsch [EMAIL PROTECTED] writes: 1) Freezing at the destruction level may *not* use any additional memory for object traversal This is a really hard problem. In some early experiments with destruction ordering (one of the problems wich need iteration) I didn't get around with allocating new memory, or recursing on the stack. It may be that we can get arround with a second pointer, but I'm not sure. What is Freezing at the destruction level? Is this anyhow related to destruction ordering? Note that I do *not* want to have multiple object traversal systems in parrot! We have one for DOD, and proposals have ranged upwards from there. No. That is *not* happening--the chance for error is significant, the side-effects of the error annoying and tough to track down for complex cases (akin to the trouble with tracking down GC issues), and just not necessary. (Perhaps desirable for speed/space reasons, but desirable isn't necessary) I did some benchmarking (to test our hash implementation, but thats a different story). One thing I found out: We are completely dominated by gc. I'm not sure if it was trace_systemareas or the mark method, but don't put any load on mark. mark should be as fast as possible. The other uses of traverse for freeze, dump, destruction-ordering etc. are all more or less called on user request, so the user needs to know its cost. One other thing that makes mark different. If we ever want to use a copying collector (Which is not reachable currently because of the conservative stack-walking) The mark routine needs to know about the moving of objects. All other traverse routine never get this problem. DOD's mark() routine has different requirements then a general traverse() for freeze(), chill(), clone(), and destruction ordering. Using just mark() will have these side effects that you want to avoid. My words. mark() is not traverse() also they do similar things. A general traverse() can be depth first of breadth first, mark() isn't required do have any specific ordering as long as it sets live bits everywhere. mark() is called permanently in a running interpreter, that does non trivial things. There are shortcuts for scalars, DOD is highly optimized not to destroy cache coherency. Using mark() also implies to back out my small PMC patches. All the advantages of smaller scalars are gone then. This ist just on more thing of mark() speed. While freeze() and friends have to pull in each PMC into the cache, just setting the live bit on a PMC hasn't. Further: Lukes proposal for speeding up timely destruction puts objects either in front or at the end of the next_for_GC chain. This IMHO implies that mark() is unusable as your general and solely iterator. ... This is something that's hidden under a number of layers of API, so regardless of the outcome it doesn't affect the assembly, PMC, or runtime API. So when its hidden, I really don't understand, why you are insisting on an (IMHO) suboptimal design. We have at the moment 15 (in words fifteen) vtable slots for dividing/remainder, 5 for multiplikation, 24 for bitwise ops. So bloating the vtable is by design, but it is the end of world if we special case the most often called function and have 2 (in words two) walking functions. Sorry, I think there are other places in the vtable which need some cleanup. The thread-safety is an issue, While all schemes aren't thread-safe from user level (e.g. manually sorting an array containing shared PMCs, while it gets frozen), your scheme isn't thread-safe at low-level, as the next_for_GC pointer inside the PMC is used as a duplicate marker. But if a user changes shared resources its a user problem. We only guarantee atomic updates per PMC (s. P6E p 86f by Dan). The thread safty is less a problem for marking. It only needs to make sure that other threads don't munge the data they are walking. Write barriers or mutexes might help here. But how to freeze an object of an other thread? This needs to freeze the whole thread. Dan Comments addressing all these issues are highly welcome, leo I think we should address this issue like experimentalists: Create the general traverse function. (No don't call it mark). Implement freeze, dump, destruction ordering using this function. When this all is running, port the mark function to use this new functionality. Benchmark, and watch the speedup of the brandnew design (or just find out that the slowdown is not bad enough to satisfy two walking functions). When the benchmarking is done lets descide if we need only one walk-function, and only than remove the mark function. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] and [PATCH]: Libraries
Last week i send this: I spent the last day getting parrot running under Borland. The attached patch is whats need to get linking and running make test on both Windows/Borland and Linux/gcc. I'm not sure if its ready for inclusion in the tree, but I want some feedback on the approach. No feedback is not very much. Sure I just can commit this thing right away, but this patch changes one fundamental thing: There is no more one single (static) libparrot. So Comments please. boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Object freezing
Dan Sugalski [EMAIL PROTECTED] writes:
[...]
The chill and warm runtime methods take a PMC or a frozen representation
of a PMC (respectively) and provide a human readable version of that PMC.
I dunno, why chill() is superior to dump() or pretty_print(), but the
name doesn't really matter.
The important thing is that it's not a vtable method. It's a function that
belongs in the freeze/thaw API as it's just an alternate encoding or
decoding. (Arguably it ought not be a separate API entry at all and just
another encoding scheme, but that requires transcoding serialization
forms, and I'd rather not get into that)
This is really just a naming problem. Dan wants to call the
vtable-function freeze and have different encodings for all kinds of
dumping/pretty_printing/marking. Leo calls the function traverse and
controlls it by callbacks.
My personal opinion on this naming problem is: traverse describes more
generaly what the function does. Marking live objects by freezing them
in an encoding that does return nothing just sounds plain wrong.
Freeze should be just a user of the general traverse function. (And
this does mean it is also no vtable function)
STRING *freeze(PMC *pmc, whatever *encoding)
{
return (STRING *)pmc-vtable-traverse(pmc, freeze_callbacks, encoding);
}
or even the freeze_encodings are callback_sets: freeze_xml,
freeze_yaml, freeze_binary, whatever.
1) Freezing at the destruction level may *not* use any additional memory
for object traversal
What is Freezing at the destruction level? Is this anyhow related to
destruction ordering?
No. There are some valid cases where an object, after having been declared
dead by the DOD, wants to serialize itself. Persistent object stores
apparently do this, and it makes a certain amount of sense--when the
object goes out of scope the current state is flushed to disk.
This is a question of what is allowed at destruction time. You don't
want to allow memory allocation, but allow freezing. That gets hard,
because you need at least allocate the STRING where you want to put
your frozen stream.
It puts a number of unpleasant constraints on the core freeze routines.
User code can violate them and take the consequences, but we can't.
We can call (hopefully) arbitary user code in destruction routines. So
this argument does not count
Note that I do *not* want to have multiple object traversal systems in
parrot! We have one for DOD, and proposals have ranged upwards from there.
No. That is *not* happening--the chance for error is significant, the
side-effects of the error annoying and tough to track down for complex
cases (akin to the trouble with tracking down GC issues), and just not
necessary. (Perhaps desirable for speed/space reasons, but desirable
isn't necessary)
Freeze is just another traversal method. Just calling it freeze
instead of traverse does not change this fact. You can limit the power
of encodings, but this does not change the fact that you need to walk
all children
DOD's mark() routine has different requirements then a general
traverse() for freeze(), chill(), clone(), and destruction ordering.
Using just mark() will have these side effects that you want to avoid.
The only thing that mark does that the general traversal doesn't, in the
abstract, is flip the object's live flag. Everything else is an
optimization of code which we can, if we need, discard.
mark() may be implemented in form of a general traverse. Let the
profiler decide if a special purpose mark() or a general traverse is
better.
A general traverse() can be depth first of breadth first, mark() isn't
required do have any specific ordering as long as it sets live bits
everywhere.
I'm pretty sure that with a singly linked list we can get a generally
properly-ordered flattened tree without having to do an insane number of
passes across the dead object store. I may be incorrect in this, but I
don't think so, and for our purposes the live bit can be safely ignored if
we end up setting it, though potentially with another pass over the dead
store, which may end up prohibitively expensive. We'll see.
I'm pretty sure that a singly linked list is not enough. I had done
some experiments with this. One pass my be enough, but you need to
keep track of the tree-traversal and of the partial ordered
list. These to things don't play well together. Maybe this can be cut
down to two lists, or one list and one bit per pmc.
mark() is called permanently in a running interpreter, that does non
trivial things. There are shortcuts for scalars, DOD is highly optimized
not to destroy cache coherency. Using mark() also implies to back out
my small PMC patches. All the advantages of smaller scalars are gone
then.
All of this stuff for freezing is going to end up killing the small PMC
patch anyway, unfortunately, since we're going to have to be able to
traverse PMCs in the destruction phase, which means we have to have the
Re: [perl #24261] [PATCH] for t\harness under win32
Nick Kostirya (via RT) [EMAIL PROTECTED] writes: cmd.exe of WinNT do not convert t\src\*.t into list files. D:\CvsProjects\parrotnmake test D:\Programs\Perl\bin\perl.exe t\harness t\src\*.t t\src\*t\src\*.t does not exist FAILED--1 test script could be run, alas--no output ever seen NMAKE : fatal error U1077: 'D:\Programs\Perl\bin\perl.exe' : return code '0x2' Stop. Applied (except white-space) identical patch which i had already in my tree. boe
Re: [perl #24240] HP-UX Support
Adam Thomason (via RT) [EMAIL PROTECTED] writes: 4) 'cc: io.ops, line 466: warning 950: Shift amount should be in the range of zero through 31 bits' It's moaning about 32-bit shifts in the 64-bit tell op in io.ops. I don't know what the desired failure behavior is for that op in a 32 bit environment, but I'm happy ignoring it for now. This is an op allowing 64-bit seeks with 32-bit INTVALS. But if PIOOFF_T is also 32-bit this op will fail. Is there a portable way of detecting such cases? #if sizeof(PIOOFF_T) == 4 will not work. bye boe
Re: Fixed opcode numbering infrastructure in
Robert Spier [EMAIL PROTECTED] writes: The goals are to assign permanent numbers to the opcodes. What the numbers are is generally irrelevant, but they must be constant across all systems for the lifetime of parrot. At first glance, gut reaction, that seems really hard(tm) and really limiting(tm)... since there's going to be a combination of dynamic oplibs that are going to have to be dynamically numbered anyway. (right?) So why not treat the core oplib as dynamic? (With the exception of the handful that need to be fixed, like end.) Why not this way: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. This ops never change during the lifetime of parrot. All other libs are inited (not necessary loaded) at byte-code loadtime. The bytecode has a list of needed oplibs with the acompaning base offset. The ops of that oplib are added to core starting at base offset. This scheme is extendable: Oplibs can append new ops to the end. If a bytecode doesn't know anything about this new ops it will overwrite this ops with ops from another oplib. But thats not a problem because the bytecode does not need this new ops. Problems might be two independ bytecodes using different versions of the oplibs. Then you have either to renumber the bytecode or use two independent opcode-tables. We can for sure define a base-lib which has all whats now in core, which is loaded by default starting at 256. A typical bytecode which just uses the base-lib has no extra load cost, because the lib is already there. Comments boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Fixed opcode numbering infrastructure in
Leopold Toetsch [EMAIL PROTECTED] writes:
Juergen Boemmels [EMAIL PROTECTED] wrote:
Have a small number of _real_ core.ops which have fixed assigned
numbers below say 256.
The problem with this approach is the JIT/EXEC subsystem. Dynamically
loaded oplibs and JIT don't play together. To make this work, it would
need probably a total rewrite of JIT code.
I'm really no expert in the JIT system. But from my last step-thru
session in the debugger I remeber that build_asm calls out to a
function based on the opcode. Ah, here:
(op_func[cur_opcode_byte].fn) (jit_info, interpreter);
At build_asm time the oplib must already be loaded. The oplib must
then have funcions for JIT-emitting the code, otherwise it should just
emit calls to the slow core functions.
This means that the author of an oplib must also include a
JIT-emitting table (for all supported platforms). This raises the
level for writing oplibs, but the worst case is that the new oplib
under jit is as slow as the function-core (All ops call
functions). Ideally the JIT-emitting functions could be mechanically
created out of the *.ops files.
The switched core has some overhead too, you can't expand a switch
statement like the other table based opcode dispatches.
Thats definitly a problem.
But this can be solved by first finding out to which oplib a code
belongs (This can be done really fast by using bisection or something
similar). Then call the right switch function and stay in this
function as long as you are in this oplib.
Pseudocode:
while (next_op) {
if (op base || op base+num_ops) return
switch (op-base) {
...
}
}
As oplib-switches are slow it might be a good idea to include the core
ops to the switch function, so the core is always dispatched fast.
Comments
boe
leo
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Fixed opcode numbering infrastructure in
Dan Sugalski [EMAIL PROTECTED] writes: On Fri, 17 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Put them *back*, please, unless you're going to fix core.pm. Done. op2pm.pl now has the renumbering. Its simpler and cleaner. Now, that 1237 opcodes are fixed numbered, shall we remove the finger-printing? Currently we just don't read PBCs, when the finger-print (generated from core.pm) doesn't match. We should keep the fingerprinting, since we can still have an issue where new bytecode can't run on old interpreters, but it's probably time to take another look at how we set the fingerprint. The fingerprint is an ugly hack: It builds an MD5-hash over the signatures and stores the first 10 bytes in the reserved slots of the parrot header. The reason why it was introduced was that the bytecode_numbers were floating, and each change led to hard to debug errors. When these opcodes are fixed now then the fingerprint should go out. If we want to keep the fingerprint it should be generated from the ops.num file, and it should be moved out of the header. The only reason I put it there was that by this time we used the nonextendable Version 0 bytecodeformat and had two independ ways of creating assembly (which is now dead). bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfC] and [PATCH]: Libraries
Hi,
I spent the last day getting parrot running under Borland. The
attached patch is whats need to get linking and running make test on
both Windows/Borland and Linux/gcc. I'm not sure if its ready for
inclusion in the tree, but I want some feedback on the approach.
The main problem is that Borland can't build a single static library
(at least I did not find out) with two files of the same name. But
there are some name clashes: intlist.o and classes/intlist.o or
stacks.o and languages/imcc/stacks.o. I solved this by seperating
libparrot in three partial libs: classes/classes.a containing all
object-files of classes/ ; languages/imcc/imcc.a containing all
object-files of imcc and blib/lib/libparrot.a for all the rest. (This
names need cleanup; shouldn't they all go to blib/lib?). classes/ is
still build by its own Makefile, this should be integrated in the
root-Makefile, but thats another story.
Next problem is library interdependence. classes.a depends on
libparrot.a and libparrot.a depends on classes.a. This complicates
linking a bit. The gnu linker does not revisit previous files so the
link line has to contain something like
libparrot.a classes.a libparrot.a
A new configure variable parrot_libs takes care of this
Last Windows does no expansion of *.t. Adding glob expansion of ARGV
to t/harness lets make test work again on windows. (I think this part
of the patch can be applied right away because the Irresulte tinderbox
has the same problem)
Comments
bö
? icu/source/test
Index: config/gen/makefiles/classes.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/classes.in,v
retrieving revision 1.10
diff -u -r1.10 classes.in
--- config/gen/makefiles/classes.in 12 Sep 2003 21:30:42 - 1.10
+++ config/gen/makefiles/classes.in 14 Oct 2003 17:53:36 -
@@ -1,4 +1,5 @@
O = ${o}
+A = ${a}
RM_F = ${rm_f}
INC=../include/parrot
@@ -19,11 +20,18 @@
PERL = ${perl}
MAKE_F=${make}
PMC2C=$(PERL) pmc2c.pl
+AR_CR = ${ar} ${ar_flags}
+RANLIB = ${ranlib}
.c$(O):
$(CC) $(CFLAGS) ${cc_o_out}$@ -c $
-all : $(O_FILES)
+all : classes$(A)
+
+classes$(A) : $(O_FILES)
+ $(RM_F) $@
+ $(AR_CR) ${ar_out}$@ ${ar_extra} $(O_FILES)
+ $(RANLIB) $@
${pmc_build}
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.146
diff -u -r1.146 root.in
--- config/gen/makefiles/root.in 14 Oct 2003 11:08:21 - 1.146
+++ config/gen/makefiles/root.in 14 Oct 2003 17:53:36 -
@@ -168,9 +168,8 @@
nci$(O) cpu_dep$(O) ${asmfun_o} tsq$(O) longopt$(O) events$(O) \
dynext$(O) utils$(O) vtables$(O) mmd$(O) extend$(O)
-O_FILES = $(INTERP_O_FILES) $(IO_O_FILES) $(CLASS_O_FILES) \
- $(ENCODING_O_FILES) $(CHARTYPE_O_FILES) \
- $(IMCC_O_FILES)
+O_FILES = $(INTERP_O_FILES) $(IO_O_FILES) \
+ $(ENCODING_O_FILES) $(CHARTYPE_O_FILES)
OPS_FILES = ${ops} $(GEN_OPSFILES)
@@ -205,7 +204,10 @@
TEST_PROG = ${test_prog}${exe}
TEST_PROG_SO = ${test_prog}_so${exe}
+PARROT_LIBS = ${parrot_libs}
LIBPARROT = ${blib_lib_libparrot_a}
+LIBCLASSES = classes/classes$(A)
+LIBIMCC = $(IMCC_DIR)/imcc$(A)
# utils
DIS=disassemble${exe}
PDUMP = pdump${exe}
@@ -255,8 +257,8 @@
mops : examples/assembly/mops${exe} examples/mops/mops${exe}
-$(TEST_PROG) : $(PARROT_MAIN)$(O) $(GEN_HEADERS) $(LIBPARROT) lib/Parrot/OpLib/core.pm
- $(LINK) ${ld_out}$(TEST_PROG) $(LINKFLAGS) $(PARROT_MAIN)$(O) $(LIBPARROT) $(C_LIBS)
+$(TEST_PROG) : $(PARROT_MAIN)$(O) $(GEN_HEADERS) $(LIBPARROT) $(LIBIMCC) $(LIBCLASSES) lib/Parrot/OpLib/core.pm
+ $(LINK) ${ld_out}$(TEST_PROG) $(LINKFLAGS) $(PARROT_MAIN)$(O) $(PARROT_LIBS) $(C_LIBS)
lib_deps_object : $(O_FILES)
$(PERL) tools/dev/lib_deps.pl object $(O_FILES)
@@ -338,8 +340,8 @@
pdb$(O) : $(GENERAL_H_FILES)
-$(PDB) : pdb$(O) $(LIBPARROT)
- $(LINK) ${ld_out}$(PDB) pdb$(O) $(LINKFLAGS) $(LIBPARROT) $(C_LIBS)
+$(PDB) : pdb$(O) $(LIBPARROT) $(LIBCLASSES)
+ $(LINK) ${ld_out}$(PDB) pdb$(O) $(LINKFLAGS) $(PARROT_LIBS) $(C_LIBS)
#
# Parrot Disassembler
@@ -347,20 +349,20 @@
disassemble$(O) : $(GENERAL_H_FILES)
-$(DIS) : disassemble$(O) $(LIBPARROT)
- $(LINK) ${ld_out}$(DIS) disassemble$(O) $(LINKFLAGS) $(LIBPARROT) $(C_LIBS)
+$(DIS) : disassemble$(O) $(LIBPARROT) $(LIBCLASSES)
+ $(LINK) ${ld_out}$(DIS) disassemble$(O) $(LINKFLAGS) $(PARROT_LIBS) $(C_LIBS)
#
# Parrot Dump
#
-$(PDUMP) : pdump$(O) packdump$(O) $(LIBPARROT)
- $(LINK) ${ld_out}$(PDUMP) pdump$(O) packdump$(O) $(LINKFLAGS) $(LIBPARROT) $(C_LIBS)
+$(PDUMP) : pdump$(O) packdump$(O) $(LIBPARROT) $(LIBCLASSES)
+ $(LINK) ${ld_out}$(PDUMP) pdump$(O) packdump$(O) $(LINKFLAGS) $(PARROT_LIBS) $(C_LIBS)
# pbc_info
-$(PINFO) : pbc_info$(O) $(LIBPARROT)
- $(LINK) ${ld_out}$(PINFO) pbc_info$(O) $(LINKFLAGS) $(LIBPARROT) $(C_LIBS)
+$(PINFO) : pbc_info$(O) $(LIBPARROT) $(LIBCLASSES)
+ $(LINK) ${ld_out}$(PINFO) pbc_info$(O) $(LINKFLAGS) $(PARROT_LIBS)
Re: FreeBSD (4.8) can't build imcc
Nick Kostirya [EMAIL PROTECTED] writes:
- Original Message -
From: Juergen Boemmels [EMAIL PROTECTED]
To: Nick Kostirya [EMAIL PROTECTED]
Cc: Nicholas Clark [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, October 13, 2003 6:29 PM
Subject: Re: FreeBSD (4.8) can't build imcc
Nick Kostirya [EMAIL PROTECTED] writes:
I propose replace
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS)
${cc_o_out}$@ -c $
by
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -I$(@D)
${cc_o_out}$@ -c $
and remove
$(IMCC_DIR)/%${o} : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS)
${cc_o_out}$@ -c $
I tested it and it seems to work on Linux/i386 too.
But before appling it I want to here something from the windows folks
Oh! Wher I sent message with this proposal
I forget inform about I tested it on
MS nmake, BSD make, gmake.
(nmake Version 6.00.8168.0)
I also tested Borlands make and it works also.
Thanks applied.
boe
Re: cvs commit: parrot/io io.c io_buf.c
Melvin Smith [EMAIL PROTECTED] writes: Did you consider using the method interface in ParrotIO? That ought to be even extensible with user code. Yes, I'm trying to get back up to speed on everything. The method interface is a new feature that I need to look at. I've written a first cut on the method interface in parrotio.pmc. The system is fairly simple: At class_init time the methods are registred in a hash and the find_method function looks up this hash and returns a invoke-able PMC (a NCI). See t/pmc/io.t for example. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: An evil task for the interested
Jeff Clites [EMAIL PROTECTED] writes: On Oct 9, 2003, at 8:43 AM, Dan Sugalski wrote: We've got ordered destruction on the big list 'o things to do, and it looks like we need to get that done sooner rather than later. ... Not a huge task, we just need to order PMCs before destroying them, to make sure we don't call the destructor for a PMC before we destroy the things that depend on it. A quick run through the PMC pools to build up a dependency chain if there's more than one PMC that needs destruction should do it. I have a partial implementation of this now. (Need to clean it up before submitting it.) There are a couple of thorny points that may need some discussion, but I'll start with the sharpest thorn: For PMCs with a custom mark method, the idea is that it's opaque exactly what other object they have references to, right? (That is, the PMC knows how to mark them alive, but doesn't reveal what they are, right?) Right. There are ways to find out which PMCs are actually marked but that is digging in the deep internals of the DOD-System. After a call to vtable-mark the list interpreter-mark_ptr/pmc-next_for contains the objects which are marked. With some hacks that create a new list before the next call to vtable-mark it might be possible to get a list of children. But I don't suggest to go this way. I'm asking because my approach is to collect the list of PMCs which need their destroys called, and trace through this set (like a DOD run) to see which ones are referred to by others on the list (and more importantly, which ones are not), destroy() those that are unreferenced and take them off the list (or do this to an arbitrary one if none are unreferenced), and repeat until done. You might need to iterate quite often with this approach. The worst case scenario is destroying a linked list. You iterate the list, find out which is the head, destroy it and search the list again for the new head. But you can, while generating the list of PMCs which need destruction enforce that this list is ordered. If you know nothing about the object already append it to the front of the list, if you know that it must destroyed after an object which is already on list enter it after the list. If the tree is walked depth first you get a list which is in the right order for destruction. The destruction is then just iterating a list and calling the functions. But I did not figure out a way to do the depth-first tree-walking without massive recursion. This works out fine, but I don't think I can use the PObj_live_FLAG for this marking or it will mess up the subsequent work in free_unused_pobjects(), but there isn't a way to ask a mark() method to set another flag. This leaves me stuck with regard to PMCs with custom mark methods (but it's working for the other PMC flavors of referring). So, I wanted to see if I'm missing something obvious, or if we need for mark() to take a parameter to indicate the flag to set. We need a general tree-walk vtable. This is needed for dump, freeze and more things. Leo suggested something like that in the thread [RfC] vtable-dump. One way to implement this is a generalization of the mark-function. I don't like the idea of generalizing the mark function: mark is called very often and should be as fast as possible. I think we should have one mark function which is very tight coupled to the gc-system and one general iterator function. (For a second I was about to decide that I could re-use PObj_live_FLAG, since by definition it will be unset for objects we are going to destroy(), thinking that I just need to be sure to clear the flag again before getting to the rest of free_unused_pobjects(), but since there's no unmark() method I'm again stuck, since my tracing could inadvertently appear to bring things back to life. Though I suppose a subsequent DOD run would get them) Resurrection of objects is opening a can of worms. Do we really want to go into this. It might be a nice feature, but it is worse the trouble. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: x86 JIT and GCC 3.3 don't play well together
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Strange, with gcc 3.3.1 I could not reproduce this error. Only one test fails: t/op/number.NOK 38# Failed test (t/op/number.t at line 1038) # got: '12.50 # -1.996899 # ' # expected: '12.50 # 0.00 # ' # Looks like you failed 1 tests of 38. Fix committed. And that was before this fix was commited. From the gcc3.3.1 docs it seems that -mno-accumulate-outgoing-args is default. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: x86 JIT and GCC 3.3 don't play well together
Dan Sugalski [EMAIL PROTECTED] writes: On Mon, 13 Oct 2003, Juergen Boemmels wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Strange, with gcc 3.3.1 I could not reproduce this error. 3.3.2 dies like this. (And the fix is apparently very specific, as arete, which looks to be running 3.3.2, dies wiht a complaint about no-accumulate-outgoing-args not existing. Looking a bit more closely to the gcc-docs: This option is specific to i386 and x86-64. As ariete is an ia64 it does not recognize this option. I think we're entering a maze of twisty little compiler version quirks, all of them annoying. :( It also depends on the target. An i386 needs diffrent flags than a ia64. :-( On the positive side adding -mno-accumulate-outgoing-args did not hurt on gcc-3.3.1/i386; it still fails only t/op/numbers_38.pasm. I will try to find out whats wrong with this. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: FreeBSD (4.8) can't build imcc
Nick Kostirya [EMAIL PROTECTED] writes:
I propose replace
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
by
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -I$(@D)
${cc_o_out}$@ -c $
and remove
$(IMCC_DIR)/%${o} : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS)
${cc_o_out}$@ -c $
I tested it and it seems to work on Linux/i386 too.
But before appling it I want to here something from the windows folks
bye
boe
Context diff:
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.145
diff -u -r1.145 root.in
--- config/gen/makefiles/root.in13 Oct 2003 13:36:08 - 1.145
+++ config/gen/makefiles/root.in13 Oct 2003 15:26:15 -
@@ -240,7 +240,7 @@
MAKE_C = ${make_c}
.c$(O) :
- @$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
+ @$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -I$(@D) ${cc_o_out}$@
-c $
all : flags_dummy $(TEST_PROG) docs
@@ -608,8 +608,6 @@
$(IMCC_O_FILES) : $(IMCC_H_FILES) $(ALL_H_FILES)
-$(IMCC_DIR)/%${o} : $(IMCC_DIR)/%.c
- $(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS)
${cc_o_out}$@ -c $
docs, test and maintainer targets
Re: x86 JIT and GCC 3.3 don't play well together
Leopold Toetsch [EMAIL PROTECTED] writes:
Dan Sugalski [EMAIL PROTECTED] wrote:
I think we're entering a maze of twisty little compiler version quirks,
all of them annoying. :(
The problem is JIT_CGP. This does nasty things with call frames, as well
as gcc does. Only core_ops_cgp.c has to be compiled with
mno-accumulate-... Or we disable JIT_CGP for failing gcc versions.
That explains something. The compilation of cgoto is so anoyingly slow
on my machine that I nearly always configure with --cgoto=0.
Another idea would be only add -mnoaccumulate-... if the target
supports it and needs it.
Something like this:
Index: config/auto/gcc.pl
===
RCS file: /cvs/public/parrot/config/auto/gcc.pl,v
retrieving revision 1.12
diff -u -r1.12 gcc.pl
--- config/auto/gcc.pl 13 Oct 2003 14:19:28 - 1.12
+++ config/auto/gcc.pl 13 Oct 2003 17:35:22 -
@@ -18,8 +18,9 @@
%gnuc=eval cc_run() or die Can't run the test program: $!;
cc_clean();
- my($gccversion, $warns, $ccwarn);
+ my($gccversion, $warns, $ccwarn, $ccflags);
$ccwarn=Configure::Data-get('ccwarn');
+ $ccflags=Configure::Data-get('ccflags');
unless (exists $gnuc{__GNUC__}) {
return;
@@ -74,7 +75,7 @@
2.7 = ,
2.8 = -Wsign-compare,
2.95 = ,
- 3.0 = -Wformat-nonliteral -Wformat-security -Wpacked
-Wdisabled-optimization -mno-accumulate-outgoing-args -Wno-shadow,
+ 3.0 = -Wformat-nonliteral -Wformat-security -Wpacked
-Wdisabled-optimization -Wno-shadow,
# -Wsequence-point is part of -Wall
# -Wfloat-equal may not be what we want
# We shouldn't be using __packed__, but I doubt -Wpacked will harm us
@@ -96,6 +97,11 @@
}
$warns = join ' ', @warns;
}
+# target dependend options
+my $target = Configure::Data-get('cpuarch');
+if ($target eq 'i386' $gccversion = 3.0) {
+ $ccflags .= ' -mno-accumulate-outgoing-args';
+}
}
if (defined $miniparrot $gccversion) {
@@ -112,6 +118,7 @@
Configure::Data-set(
ccwarn= $warns $ccwarn,
+ccflags = $ccflags,
gccversion = $gccversion
);
}
Index: lib/Parrot/Configure/RunSteps.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Configure/RunSteps.pm,v
retrieving revision 1.26
diff -u -r1.26 RunSteps.pm
--- lib/Parrot/Configure/RunSteps.pm30 Sep 2003 12:52:47 - 1.26
+++ lib/Parrot/Configure/RunSteps.pm13 Oct 2003 17:35:23 -
@@ -23,9 +23,9 @@
auto/byteorder.pl
auto/pack.pl
auto/format.pl
+ auto/jit.pl
auto/gcc.pl
auto/isreg.pl
- auto/jit.pl
auto/funcptr.pl
auto/cgoto.pl
auto/gc.pl
Re: x86 JIT and GCC 3.3 don't play well together
Juergen Boemmels [EMAIL PROTECTED] writes:
t/op/number.NOK 38# Failed test (t/op/number.t at line 1038)
# got: '12.50
# -1.996899
# '
# expected: '12.50
# 0.00
# '
# Looks like you failed 1 tests of 38.
I think I found out why this test is failing (randomly):
The null_n op emits in emits the address to a auto variable in
Parrot_null_n_jit. But this frame is destroyed after the emission of
the code. When the code is run it uses a reference to a no longer
existing frame which may contain random data. The value zero has to
outlive the invokation of Parrot_null_n_jit so making zero static
will solve the problem.
Can someone with more jit-experience verify that I'm correct?
bye
boe
Index: jit/i386/core.jit
===
RCS file: /cvs/public/parrot/jit/i386/core.jit,v
retrieving revision 1.48
diff -u -U7 -r1.48 core.jit
--- jit/i386/core.jit 3 Oct 2003 15:43:49 - 1.48
+++ jit/i386/core.jit 13 Oct 2003 19:11:55 -
@@ -129,15 +129,15 @@
}
Parrot_null_s {
Parrot_null_x s/_N/_i/ s/INT_R/STRING_R/ s/val/NULL/
}
Parrot_null_n {
-FLOATVAL zero = 0;
+static FLOATVAL zero = 0;
if (MAP[1]) {
jit_emit_mov_ri_n(NATIVECODE, MAP[1], zero);
}
else {
jit_emit_mov_mi_ni(NATIVECODE, NUM_REG[1], zero);
}
}
Re: [RfC] return value of PIO_seek
Melvin Smith [EMAIL PROTECTED] writes: [...] That sounds proper as that is the traditional semantic for seek/lseek on most systems. I'm not sure why I wrote it otherwise, probably just in haste. That semantic I had in mind. I just checked in the change to use the new/traditional semantics. Furthermore i fixed some seek-errors in io_buf. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Destruction bug in make test.
Leopold Toetsch [EMAIL PROTECTED] writes: Juergen Boemmels [EMAIL PROTECTED] wrote: It turned out, that it was even simpler. The explicit sweeping is already in the code, but is only triggered if there are objects which need _early_ destruction, not if objects just need destruction. Removing this test made it work. Why can't you call PIO_finish(DO_FLUSH) before the sweep? Because the object in question is not in PIO_data. Its just a plain PMC with a destroy-function. And this destroy-function was not run until now. Some other bug was hiding that fact. I don't understand these workarounds. Also you mark the IOdata live, only that they are destroyed 3 lines later then. Thats something completely different and I addmit it is a hack. When I introduced this, I had problems with closing the three _standard_ handles to early. Maybe I don't need this hack any more because the handles are now only flushed (not tested). But I left it in because its a matter of correctness. One destroy-function which prints and the problem is there again. The correct solution to this problem is destruction ordering: The standard handles should be destroyed after the interpreter (which isn't a PMC yet). If there are no objects that need timely destruction, the sweep is wasted time. Fix is commited. Not IMHO. PIO_finish still does not release the standard handles and valgrind complains about invalid reads in PIO_flush_down. I think this is one (or two) other problems. When I think about it, I just flush the buffers, but do not free them. Will look at the code now. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Destruction bug in make test.
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: No. If any object has a destructor it should be called as the last interpreter is shut down. We're not guaranteeing dead-on immediate destruction, or if the timely flag isn't set timely destruction, but we *are* guaranteeing eventual destruction. Oha. That explains the reasoning. That adds a third category to destruction IMHO: 1) timely destruction on scope exits 2) eventual destruction on exit of interpreters or any time between the death of the object and the and of universe^H^H^Hinterpreter. But no guarantee when. 3) memory destruction for leak tests and such or for intermediate interpreters. For 1) we have opcode support Cneeds_destroy. 2) seems to be the case where IO objects jump in - and HLL destructors. We don't need to free memory, but we do need to call destructors. So we'd better separate 2) and 3) This would simplify destruction ordering and speedup interpreter shutdown. The code is already there. The final sweep runs the destructors. The problem was that 1) and 2) were to strongly coupled. All destructors were only run if one object exists which needed timely destruction. Maybe we should generate another PMC which uses destruction functions, just for testing these things. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[CVS ci] Remove of PutS and GetS from PIOLayerAPI
Hi, I just removed the PutS and GetS functions PIOLayerAPI. This API-functions used plain C-Strings and had no advantage over the Read and Write API-calls. They just introduced a second code-path. The only function actually using this API was PIO_puts, which was easily changed to use the Write API. I also temporarily disabled t/pmc/io_21 (seek/tell), because of some bugs in the seek/tell implementation in io_buf, which I want to address next. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfC] return value of PIO_seek
Hi,
I'm currently working on some bugs in the PIO_seek code, and i find
the current return-code of Seek impractical: it just returns 0 on
success and -1 on error. I found myself writing code like
PIO_seek_down(...);
pos = PIO_tell_down(...);
but in the layer implementations typically is this code:
return pos == -1 ? -1 : 0;
So i think it would be better to let PIO_seek return the current
offset. So I purpose a change of the prototype of PIO_seek to
PIOOFF_T PIO_seek(theINTERP, PMC *io, PIOFF_T offset, INTVAL whence);
The error checking can still be done by
if (PIO_seek(...) 0) {
/* an error occured */
}
Comments?
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Destruction bug in make test.
Hi, I just discovered a really subtele bug: Normaly the test are not run with --destroy-at-end. This has not many consequences yet because the only PMCs with active destruction are IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it won't flush its buffers without --destroy-at-end. The print op also did not use this buffer so this bug didn't even show up. There are several ways to solve this: - run the test always with --destroy-at-end - make --destroy-at-end the default and have an option --no-destroy-at-end - add a explicit flush to the test just before the end. I think we should take the second route: destroy-function should be run by default at the end of program. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Destruction bug in make test.
Dan Sugalski [EMAIL PROTECTED] writes: [...] Option 2 is the right one. (Well, OK, having parrot do an explicit sweep destroy's the right option, but until then...) Go ahead and add a patch to whatever you need to make this happen. It turned out, that it was even simpler. The explicit sweeping is already in the code, but is only triggered if there are objects which need _early_ destruction, not if objects just need destruction. Removing this test made it work. Fix is commited. cu boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
test_main.c can die
Hi, test_main.c is not used any more. The only references are from make.pl (which also does not seem to work), a comment in imcc/main.c that it is mostly stolen from there, and docs/embed.pod giving test_main.c as an example. Shouldn't test_main.c be removed completely? Maybe as part of the big imcc-move. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Destruction bug in make test.
Dan Sugalski [EMAIL PROTECTED] writes: I disagree :) We already have a 2 stage IO destroy. The first shall flush its files. This get called even if destroy-at-end isn't set. The two stage IO destroy is a problem that we don't have destruction ordering yet. Closing the standard handles to early leads to failed tests. The second phase (clean allocated memory) isn't called for the last interpreter, if this option isn't given. So either this test has to set the needs_destroy on the IO object or IO has a bug. No, needs_destroy marks the object that it needs _early_ destruction, not that it needs destruction at all. The problem that the destruction code is not run run at all. If there are objects that did needs_destroy then a lazy sweep is done, which should flush the IO object or release resources or whateve rsuch an object might need. No. If any object has a destructor it should be called as the last interpreter is shut down. We're not guaranteeing dead-on immediate destruction, or if the timely flag isn't set timely destruction, but we *are* guaranteeing eventual destruction. We don't need to free memory, but we do need to call destructors. Exactly. My first idea --destroy-at-end only removed the symptom. The real problem was that the final sweep, which should have run the destructor code, was only triggered if there was still an object left which needs early destruction. I changed this to run the final sweep unconditionally and the problem disappeared. I did not touch any of the --destroy-at-end semantics. I thought one moment about introducing a variable interpreter-has_destroy analog to interpreter-has_early_DOD_PMCs but rejected it. This would slow down the DOD because it has to take care of this variable also. I think its better to force one sweep at the end than slowing down every DOD. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfT] Configure/Makefile changes towards Borland C++ Builder
Jonathan Worthington [EMAIL PROTECTED] writes: - Original Message - From: Juergen Boemmels [EMAIL PROTECTED] To: Brent Dax [EMAIL PROTECTED] Cc: 'Steve Fink' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 23, 2003 6:38 PM Subject: Re: [RfT] Configure/Makefile changes towards Borland C++ Builder I tried the first way: substitute before interpolation. This means all uservariables need to substitute slashes. Fortunatly there are not so many. ... Anyway please test the revisited patch Works for me. :-) All languages apart from cola now build successfully on Win32 using nmake. Thanks, If nobody objects I will commit this change tomorrow. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24038] [PATCH] PIO_parse_open_flags is too lenient
Michael Scott (via RT) [EMAIL PROTECTED] writes: PIO_parse_open_flags thinks that is the same as . This could lead to errors such as using instead of . I solved the problem with a different patch. Your solution was not easily extendeble with the planned but not implemented ? and ! modifieres. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: PIO tests
Michael Scott [EMAIL PROTECTED] writes: Here are some tests for the io.h API that should go in t/src/io.t. Ah yes. I know I submitted one too. I thought it got committed a long time ago but maybe it wasn't. I will try to merge it with your tests and commit a change. In one test you include ../io/io_private.h. I'm not sure if it's a good idea to test implementation details. On one side its better to test as many as you can, on the other side mainly the public API should be tested, the implementation should just work. Maybe some of the expected results are debatable. Should PIO_parse_open_flags think that is the same as ? No it shouldn't. Should PIO_fdopen open ok on stdout with invalid flags like ;-) or ? I think all invalid flags should be invalid. Also, successive calls to PIO_seek with SEEK_CUR seem to be broken. I will look at this. Mike bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: CVS checkout hints for the bandwidth-limited
Jeff Clites [EMAIL PROTECTED] writes: Actually, I'm pretty sure that cvs will delete local copies of file removed from the repository with just cvs update. The -dP just affects directories--the -d says to pull down and update new directories, and the -P tells it to prune (remove) empty directories (this is necessary because cvs doesn't really version directories, and you end up not really having a way to fully remove them from the repository). exactly. My canonical invocation is: cvs -q -z6 update -dP (I use -z6 rather than -z9 because I remember reading somewhere that the higher compressions numbers don't save much space, but use a lot more CPU, and level 6 is the default for gzip.) I use a .cvsrc file: $ cat .cvsrc cvs -z3 -q diff -uN update -dP This way i just type cvs up and the data is compressed (I use -z3 because some sites don't want higher compression rates because of high CPU usage on the server) and the directories are handled right. Furthermore I always get unified diffs. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: PIO tests
Michael Scott [EMAIL PROTECTED] writes: On Tuesday, Sep 30, 2003, at 15:44 Europe/Berlin, Juergen Boemmels wrote: Michael Scott [EMAIL PROTECTED] writes: Here are some tests for the io.h API that should go in t/src/io.t. Ah yes. I know I submitted one too. I thought it got committed a long time ago but maybe it wasn't. I will try to merge it with your tests and commit a change. In one test you include ../io/io_private.h. I'm not sure if it's a good idea to test implementation details. On one side its better to test as many as you can, on the other side mainly the public API should be tested, the implementation should just work. I'm just including io_private.h to get the correct flags to test the return values of PIO_parse_open_flags() which is in the public API. Maybe PIO_parse_open_flags should also get moved to io_private.h. The private/public split of the io subsystem is far from complete. In fact io is the first subsystem that even tries to do so. I agree there are limits to what should be tested, but what embarked me on the tests in src/io.t was the failure of test 6 in pmc/io.t. I tried to fix it, but because there were no src/io.t tests I couldn't be sure whether the problem lay in the io.ops code or the io/* code. Needless to say, once I'd written src/io.t, I got sidetracked into the need for string C code tests, and never got back to pmc/io.t. It seems to me that there are at various levels of public in Parrot, and each one should be tested. Furthermore, the more tightly the testing is done at the lowest level, the more confident we can be about the higher level test results. Ok you convinced me, we need to test private implementation details. But this tests should be cleanly flagged as such. PIO_parse_open_flags() is, I think, a good case in point. It makes sense to throw a bunch of invalid values at it in src/io.t, and then assume that it works in pmc/io.t. BTW those src/io.t tests should be rewritten to use the scheme Leo uses in the 3rd test in src/basic.t. I proposed a patch to simplify this in [PATCH] C code test header which if you could get into CVS I'd be grateful as my string tests will rely on it. The whole c_output_is() tests are more or less a hack. Ideally there would be C-markos like OK(val, name), DIAG(text), IS(this, that, name), etc. and be able to check individual c-statements without recompiling and running a new file each time. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24063] [PATCH] Add C test info to tests.pod
Michael Scott (via RT) [EMAIL PROTECTED] writes: I've added some info about C source code tests to parrot/docs/tests.pod. Thanks applied boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfT] Configure/Makefile changes towards Borland C++ Builder
Brent Dax [EMAIL PROTECTED] writes:
Steve Fink:
# Following things were done:
# - s,/,\${slash},g
#
# Ugh. How difficult would it be to have Configure do this rewriting
# automatically? (Or rewrite to whatever it is you need, instead)? This
# just clutters up the makefiles a little too much, IMO.
Well...
It's theoretically possible. However, it'll cause problems if we use
tools that require use of slashes on arguments (xcopy /e, for example,
which we might use to install modules at some point--and my
understanding is that VMS tools all use slashes exclusively).
Either we substitute before we interpolate things into the Makefile,
which'll miss any interpolated slashes (like the ones in the variable
that defines which PMC classes are compiled in), or we do so after,
which will hit all interpolated slashes (including command-line
switches). We can't have it both ways.
I tried the first way: substitute before interpolation. This means all
uservariables need to substitute slashes. Fortunatly there are not so
many.
But VMS brings up another point--can we afford to use a simple
substitution at all? After all, they use a completely different syntax
for paths, right?
How does VMS-make handle the directory case?
What seems far more promising to me is something in the cc wrapper we're
using. Similar wrappers for ld, ar, and the other build tools might be
in order. Nothing would please me more than a Makefile like:
.c$(O):
$(PERL) tools/build/calltool.pl cc $@ $
parrot$(EXE):
$(PERL) tools/build/calltool.pl ld parrot$(EXE)
$(O_FILES)
That could appear exactly the same in makefiles/root.in as in /Makefile.
All systems would use 'calltool.pl cc' to invoke the C compiler--it
wouldn't be 'calltool.pl cl' on Windows, or 'calltool.pl gcc' on
gcc-using systems. And 'calltool.pl' could convert paths on VMS or
Windows.
But this means that calltool.pl must be generated by Configure. The
diffrent Makerules are just hidden in calltool.pl.
*That* would make me a happy Configure hacker. :^)
--Brent Dax [EMAIL PROTECTED]
Perl and Parrot hacker
Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it.
Anyway please test the revisited patch
bye
bö
? bcc5.diff
? r.diff
Index: config/auto/sizes.pl
===
RCS file: /cvs/public/parrot/config/auto/sizes.pl,v
retrieving revision 1.7
diff -u -r1.7 sizes.pl
--- config/auto/sizes.pl 27 Apr 2003 07:36:44 - 1.7
+++ config/auto/sizes.pl 23 Sep 2003 17:20:42 -
@@ -118,7 +118,7 @@
};
# clear int8_t on error
-if($@) {
+if($@ || !exists $results{hugeintval}) {
Configure::Data-set('int8_t' = undef);
next;
}
Index: config/gen/makefiles.pl
===
RCS file: /cvs/public/parrot/config/gen/makefiles.pl,v
retrieving revision 1.17
diff -u -r1.17 makefiles.pl
--- config/gen/makefiles.pl 23 Jul 2003 14:38:23 - 1.17
+++ config/gen/makefiles.pl 23 Sep 2003 17:20:42 -
@@ -10,27 +10,27 @@
sub runstep {
genfile('config/gen/makefiles/root.in', 'Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/classes.in', 'classes/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/languages.in', 'languages/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/jako.in', 'languages/jako/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/miniperl.in', 'languages/miniperl/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/scheme.in','languages/scheme/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/perl6.in', 'languages/perl6/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/imcc.in', 'languages/imcc/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/bf.in','languages/bf/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/befunge.in', 'languages/befunge/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
genfile('config/gen/makefiles/ook.in', 'languages/ook/Makefile',
- commentType = '#');
+ commentType = '#', replace_slashes = 1);
# set up docs/Makefile, partly based on the .ops in the root dir
Index:
Re: nmake languages fails (Win32)
Jonathan Worthington [EMAIL PROTECTED] writes:
- Original Message -
From: Leopold Toetsch [EMAIL PROTECTED]
To: Jonathan Worthington [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, September 19, 2003 5:50 PM
Subject: Re: nmake languages fails (Win32)
Jonathan Worthington [EMAIL PROTECTED] wrote:
Hi,
nmake languages is failing because /'s rather than \'s are used in
paths.
Makefiles, e.g. like the befunge one, contain this:-
PARROT = ../../parrot
Did you try Juergen Boemmels proposal RFT / patch?
I actually went through all the makefiles and put ${slash} in place of all
the /'s in paths. Would Juergen's proposal be better? I noticed there was
already a ${slash}defined in the config.
This was one part of my patch. But Steve tought it would decrease
readability to much. ATM I'm experimenting with a makefile.pl based
hack.
With my changes it appears to work fine apart from the cola makefile uses
chomd, which doesn't work under Win32. So, I added chmod to the config
data, and under Win32 it uses rem instead of chmod - essentially commenting
it out. It's a bit of a hack, but it should work - it's attached in a
separate diff in case it's not liked. :-)
IMCC is build twice for this reason.
I say should work because cola has a makefile generated by the developer,
not by parrot's configure system. Thus even with my addition of the chmod
variable it doesn't work out. What's the best option from here?
- Make cola's makefile be generated with configure?
- Exclude cola from being made under Win32 for this release?
If you let me know which one I can have a go at it.
Make the makefile generated by Configure. But this couples the
languages very close to the core system. Maybe Makefile.in should be
resurrected in the languages/ directory.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] Semantics of fdopen.
Nicholas Clark [EMAIL PROTECTED] writes: On Fri, Sep 05, 2003 at 05:24:48PM +0200, Juergen Boemmels wrote: * Add an layer-argument to PIO_open and PIO_fdopen, which walk the layerstack and search for the Open-implementation. The current implentation of PIO_open with the default layer should be renamed to PIO_open_default. What is the layer stack? That term doesn't seem to be defined anywhere. The documentation of ParrotIO is uhm... suboptimal. ParrotIO uses handles IO request via layers. Each request is handled either directly by the layer or the request is passed down to the next layer. The layer stack is something that is associated with an io-handle. (OK, I can make a guess based on what perl 5.8 is doing) I can see why one would have a layer stack on an open file handle, but doesn't open crate file handles? Or is the action of open something that happens after file handle construction (hence there can be a stack by open time)? Open and fdopen create an IO-handle. But currently this IO-handle has always the current default layer (stack) associated with it, which is an interpreter-variable. There should be a possiblity of opening a file on a different layer. Nicholas Clark bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: string_to_cstring()
Gregor N. Purdy [EMAIL PROTECTED] writes:
Nicholas --
I'd be happy with that...
[...]
Instead could we just ditch the C-style put? (and make the layer table
one pointer smaller)
Thats something I wanted to do, See [RfC] Cleanup of ParrotIOLayerAPI
I just wanted to let the release pass by.
Anyone who wants to put a \0 terminated string can do the strlen
themselves. (Or we could provide a helpful macro)
I don't want to remove the PIO_puts function; It will just be
changed to
INTVAL
PIO_puts(theINTERP, PMC *pmc, const char *s)
{
return PIO_write(interpreter, pmc, s, strlen(s));
}
Maybe a rename is also needed. Have we decided for a suffix for
functions taking a c-string yet?
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfT] Configure/Makefile changes towards Borland C++ Builder
Steve Fink [EMAIL PROTECTED] writes:
On Sep-18, Juergen Boemmels wrote:
Following things were done:
- s,/,\${slash},g
Ugh. How difficult would it be to have Configure do this rewriting
automatically? (Or rewrite to whatever it is you need, instead)? This
just clutters up the makefiles a little too much, IMO.
Yes.
In principle it is adding above line to config/gen/makefile.pl
I went the above way because parts of the Makefile already used this
style.
- remove of in the makefiles:
I introduced $(MAKE_C) which calls a perlscript which recursively
calls $(MAKE) to get rid of
cd doc make cd ..
This seems like a clear improvement.
The few cases where is not used for descending into
subdirectories it is replaced with ${make_and} which expands to
on everything but bcc32
What does bcc32 use? Is an infix operator likely to also work with
other platforms that don't like ?
bcc32 uses a simple \n\t which works quite well for the cases were
it is still used, but i would like it more to get rid of entirly.
- TLIB needs the options after the outputfile so I introduced
${ar_extra}
This seems good. Is there a better name? ${ar_final}? Could they just
always be in this order?
They need to be between the archive and the members.
TLIB archive /au [members]
whereas ar needs the action flags before the archive
ar cr archive [member]
- The ${link} variable is set to bcc32
Obviously good.
The final problem for getting make test running on BCC is the
name-clash key.c and classes/key.c (and some others like this). There
are two possible way to solve this problem:
- rename either key.c or classes/key.c
- build a seperate classes.lib
How difficult would the latter be? I have no strong opinion either way
for this one.
I already have a hacky version of the later running, I just need to
integrate them with Configure. The downside of this approach is that
we always need to link with -lclasses additionally to -lparrot.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfT] Configure/Makefile changes towards Borland C++ Builder
Hi,
I did some experiments to get parrot compile on Borland C++
Builder. I got it working until the linking of libparrot.lib (and with
some ugly tricks even got a running make test). The attached patch are
the Changes to Configure and Makefiles which are needed to get there.
Before I want to commit this changes I need some people on diffrent
architectures to test this patch and report problems.
Following things were done:
- s,/,\${slash},g
- remove of in the makefiles:
I introduced $(MAKE_C) which calls a perlscript which recursively
calls $(MAKE) to get rid of
cd doc make cd ..
The few cases where is not used for descending into
subdirectories it is replaced with ${make_and} which expands to
on everything but bcc32
- TLIB needs the options after the outputfile so I introduced
${ar_extra}
- The ${link} variable is set to bcc32
The final problem for getting make test running on BCC is the
name-clash key.c and classes/key.c (and some others like this). There
are two possible way to solve this problem:
- rename either key.c or classes/key.c
- build a seperate classes.lib
The patch works on Win32/BCC32 (until linking stage) with
perl Configure --jitcapable=0 --cgoto=0 --cc=bcc32
and on Linux/i386
bye
bö
Index: config/auto/sizes.pl
===
RCS file: /cvs/public/parrot/config/auto/sizes.pl,v
retrieving revision 1.7
diff -u -r1.7 sizes.pl
--- config/auto/sizes.pl 27 Apr 2003 07:36:44 - 1.7
+++ config/auto/sizes.pl 18 Sep 2003 00:31:18 -
@@ -118,7 +118,7 @@
};
# clear int8_t on error
-if($@) {
+if($@ || !exists $results{hugeintval}) {
Configure::Data-set('int8_t' = undef);
next;
}
Index: config/gen/makefiles/imcc.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/imcc.in,v
retrieving revision 1.29
diff -u -r1.29 imcc.in
--- config/gen/makefiles/imcc.in 12 Sep 2003 21:30:42 - 1.29
+++ config/gen/makefiles/imcc.in 18 Sep 2003 00:31:18 -
@@ -44,7 +44,7 @@
# do it for you.
#
${make_set_make}
-
+MAKE_C = ${make_c}
all : flags_dummy imcc${exe}
@@ -52,8 +52,8 @@
echo Compiling with:
@$(PERL) ../../tools/dev/cc_flags.pl ./CFLAGS echo $(CFLAGS) xx$(O) -c xx.c
-../../$(PARROTLIB):
- cd ..${slash}.. $(MAKE) $(PARROTLIB) cd languages${slash}imcc
+..${slash}..${slash}$(PARROTLIB):
+ $(MAKE_C) ..${slash}.. $(PARROTLIB)
# The .flag files are needed because we are keeping some derived files in CVS,
# which does not keep accurate timestamps on the files, relative to each other.
Index: config/gen/makefiles/languages.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/languages.in,v
retrieving revision 1.3
diff -u -r1.3 languages.in
--- config/gen/makefiles/languages.in 15 Sep 2003 07:23:07 - 1.3
+++ config/gen/makefiles/languages.in 18 Sep 2003 00:31:18 -
@@ -1,15 +1,17 @@
-MAKE = ${make}
+PERL = ${perl}
+${make_set_make}
+MAKE_C = ${make_c}
all : imcc jako scheme befunge bf cola ook perl6
-test : imcc.test regex.test befunge.test bf.test ook.test perl6.test
+test : imcc.test scheme.test regex.test befunge.test bf.test ook.test perl6.test
# Could someone please comment on the reason for all these *.dummy
# targets?
imcc: imcc.dummy
imcc.dummy:
- cd imcc $(MAKE) cd ..
+ $(MAKE_C) imcc
imcc.test:
cd imcc $(MAKE) test cd ..
@@ -17,62 +19,65 @@
jako: jako.dummy imcc.dummy
jako.dummy:
- cd jako $(MAKE) cd ..
+ $(MAKE_C) jako
scheme: scheme.dummy
scheme.dummy:
- cd scheme $(MAKE) cd ..
+ $(MAKE_C) scheme
+
+scheme.test:
+ $(MAKE_C) scheme test
regex: regex.dummy
regex.dummy:
- cd regex $(MAKE) cd ..
+ $(MAKE_C) regex
regex.test :
- cd regex $(MAKE) test cd ..
+ $(MAKE_C) regex test
befunge : befunge.dummy
befunge.dummy:
- cd befunge $(MAKE) cd ..
+ $(MAKE_C) befunge
befunge.test:
- cd befunge $(MAKE) test cd ..
+ $(MAKE_C) befunge test
bf : bf.dummy
bf.dummy:
- cd bf $(MAKE) cd ..
+ $(MAKE_C) bf
bf.test:
- cd bf $(MAKE) test cd ..
+ $(MAKE_C) bf test
cola : cola.dummy
cola.dummy:
- cd cola $(MAKE) cd ..
+ $(MAKE_C) cola
ook : ook.dummy
ook.dummy:
- cd ook $(MAKE) cd ..
+ $(MAKE_C) ook
ook.test:
- cd ook $(MAKE) test cd ..
+ $(MAKE_C) ook test
perl6 : perl6.dummy
perl6.dummy:
- cd perl6 $(MAKE) cd ..
+ $(MAKE_C) perl6
perl6.test:
- cd perl6 $(MAKE) test cd ..
+ $(MAKE_C) perl6 test
clean:
- cd imcc $(MAKE) clean cd ..
- cd jako $(MAKE) clean cd ..
- cd scheme $(MAKE) clean cd ..
+ $(MAKE_C) imcc clean
+ $(MAKE_C) jako clean
+ $(MAKE_C) scheme clean
update:
cvs -q update -dP
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.120
diff -u -r1.120 root.in
---
Re: TREE IS FEATURE FROZEN (2003-Sep-14)
Vladimir Lipskiy [EMAIL PROTECTED] writes: Seems like Juergen did apply only one of two patches which I proposed on 06.09.2003 See Re: Win32 Build Issues (was Re: Linking pdump and dissassemble) 06.09.2003 4:40 Ooops. These were two independend patches with the same name. Thanks applied. So we have only 2 test failing on Windows. Those failings are concerned with the erroneous implementation of fdopen and Juergen will fix that in a while. See Sent: Friday, September 05, 2003 6:24 PM Subject: [RfC] Semantics of fdopen. I'm working on that, but had several days without a computer at all. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[CVS ci] Change of fdopen sematics (Part 1)
Hello, Nobody yet commented to my proposed change of fdopen semantics http://groups.google.de/groups?selm=m2ptifuukf.fsf%40helium.physik.uni-kl.de so I checked in the part. This change mainly changes the semantics of getfd The returned value is no longer the index in the interpreter-piodata-table but the real OS handle. fdopen takes an OS-filehandle; this means fdopen P0, 0, is only valid under UNIX. (It never worked on other systems anyway). The only way to portable open stdin is now getstdin P0. Furthermore fdopend handles are not closed automatically when they are destroyed, but only flushed. But they can be closed explicitly. The tests are updated to follow the new semantics. Now the tests t/pmc/io_3.pasm and t/pmc/io_4.pasm pass on stdio and hopefully also WIN32. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [CVS ci] Change of fdopen sematics (Part 1)
vcv [EMAIL PROTECTED] writes:
Granted I haven't gotten my hands dirty with the guts of parrot yet, but it
looks good to me, and makes sense.
Thanks for the fix though, it works great now :)
However, it did introduce a warning (on Win32):
io.ops(59) : warning C4022: 'PIO_fdopen' : pointer mismatch for actual
parameter
2
Ah, this line was ifdefed out on windows until now. Try following
patch. It adds a cast for the INTVAL parrameter. This is only a
temporary hack because this abuses an INTVAL to carry a pointer, which
is not guaranteed to work. Moving fdopen away from INTVAL to PMCs will
solve this but this is a drastic change in feature-freeze.
bye
boe
Index: io.ops
===
RCS file: /cvs/public/parrot/io.ops,v
retrieving revision 1.34
diff -u -r1.34 io.ops
--- io.ops 17 Sep 2003 17:34:01 - 1.34
+++ io.ops 17 Sep 2003 18:26:21 -
@@ -56,7 +56,7 @@
const char * mode;
mode = string_to_cstring(interpreter, $3);
- $1 = PIO_fdopen(interpreter, $2, mode);
+ $1 = PIO_fdopen(interpreter, (PIOHANDLE)$2, mode);
if (!$1) {
$1 = pmc_new(interpreter, enum_class_PerlUndef);
}
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #23822] [PATCH] Avoid undef warnings for ccwarn
Andy Dougherty (via RT) [EMAIL PROTECTED] writes: The following patch eliminates the following (correct!) warnings during the Configure process: Thanks, applied boe
Re: TREE IS FEATURE FROZEN (2003-Sep-14)
Leopold Toetsch [EMAIL PROTECTED] writes: ... t/pmc/n.t is failing for me right now, but that's probably because I have an ancient libnci.so that happens to be lying around. Is everyone else just skipping this test? I'm always running nci.t. How do you do that? On a clean checkout of parrot i get : t/pmc/nci...i386 JIT CPU .so SO extension t/pmc/nci...ok, 10/10 skipped: needs jit/i386 and libnci.so $ make libnci.so make: *** No rule to make target `libnci.so'. Stop. $ touch libnci.so $ perl -Ilib t/pmc/nci.t 1..10 i386 JIT CPU .so SO extension Quit All tinderboxens say the same: 10/10 skipped: needs jit/i386 and libnci.so confused boemmels -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: One more test failure on Windows
Brent Dax [EMAIL PROTECTED] writes: ... t/op/stringNOK 117# Failed test (t/op/string.t at line 1981) # got: 'ASCII is the same as UTF8 # ÇÇ' # expected: 'ASCII is the same as UTF8 # ASCII is the same as UTF8 # ' # Looks like you failed 1 tests of 117. t/op/stringdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 117 Failed 1/117 tests, 99.15% okay ... Failed Test Stat Wstat Total Fail Failed List of Failed t/op/string.t1 256 1171 0.85% 117 21 subtests skipped. Failed 1/57 test scripts, 98.25% okay. 1/897 subtests failed, 99.89% okay. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff' This is with a fresh checkout. I don't know where to start on this one--any thoughts? Maybe this has something to do with the warning i just discovered when I configured with --ccwarn=-Werror under Linux chartypes/usascii.c cc1: warnings being treated as errors chartypes/usascii.c:35: warning: initialization from incompatible pointer type make: *** [chartypes/usascii.o] Error 1 The offending line is usascii_transcode_from_unicode, /* from_unicode() */ I'm still investigating this bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Moving imcc ...
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski wrote: On Mon, 8 Sep 2003, Leopold Toetsch wrote: Imcc is still lacking full integration inside Parrot. To accomplish this, we would need these steps: - rebuild and commit directory structure $Parrot_Root/imcc - move files from languages/imcc to ../imcc [1] - adapt Makefiles - include imcc source files except main.c into libparrot Almost. IMCC's getting integrated with Parrot. All the core sources should be in one spot, so either move the current top-level C code to core/ and put the IMCC stuff in there as well (in core/ directly, not core/imcc/) or move all the IMCC files to the top level directory (with the header files in include/parrot) Could be done too (with some file renaming i.e. jit.c) but imcc has its own test structure and its own TestCompiler.pm. OTOH pd07 has something about subsystem - they should be separate. As imcc is the assembler/compiler subsystem I'd rather have it in a separate directory. I think the same way. Imcc is a seperate subsystem. Clobbering the root of the source directory is not good, and moving everything to core/ neither. In the long term more code from the root directory should move to subsystems like packfile, mem etc. Furthermore the *.h should not get blindly copied to include/parrot, some of the imcc header-files are private to the imcc subsystem (like imcparser.h). These files should stay in the subsystem directory. PDD07 calls them *_private.h. ... The makefile needs to be integrated into the top-level makefile. (Again, in the top-level. I don't want a separate makefile for IMCC) Nor do I. io is also a subsystem, but the build is controlled by the root-makefile. There's not much reason to have IMCC split out, so I'd rather not. pdd07, file name clashes, t/* bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Win32 Build Issues (was Re: Linking pdump and dissassemble)
Vladimir Lipskiy [EMAIL PROTECTED] writes:
static INTVAL
PIO_win32_getblksize(PIOHANDLE fd)
{
those indentifiers had internal linkage. Bi-bi. Fixed.
Thanks applied.
boe
[RfC] Semantics of fdopen.
Hi,
The current implementation of fdopen op in PIO is buggy. The tests
fail currently on every system except unix. This is because the test
are based on the assumption of 1 being stdout on every system.
Furhtermore the standard handles get autoclosed at exit. This has in
the past lead to problems on Windows.
As we decided long ago to drop support for integer filehandles I
propose the following [1]:
* fdopen should make no assumtions about the nature of the handle,
there are no special values.
* getfd should return the OS-filehandle and not an offset in an
internal array. This makes fdopen and getfd inverse operations:
getfd (fdopen (x)) == x
* The std{in,out,err} can only obtained by getstd{in,out,err}
* fdopen is for communication with external resources. Therefor a
fdopened file should not be closed on destruction. (Unless the user
explicitly requested so)
* a filehandle (PIOHANDLE) is not always an integer, it might also be
a pointer. As its not guaranteed that an INTVAL can hold a pointer,
there needs to be a PMC version of the fdopen op
fdopen (out PMC, in PMC) which takes an UnmangedStruct or PerlInt.
A related point is that currently only one layer can be active. But on
Unix there can be interger FDs and stdio FILE* handles, somewhere in
time there might be also a STRING * layer which operates on memory.
Therefor the external visible open/fdopen functions need to have a
layer argument to create a non-default IO-object. Surely you can
always call PIO_stdio_fdopen(interpreter, pio_stdio_layer, handle)
directly, but it does not feel right.
* Add an layer-argument to PIO_open and PIO_fdopen, which walk the
layerstack and search for the Open-implementation. The current
implentation of PIO_open with the default layer should be
renamed to PIO_open_default.
Comments?
boe
[1] based on discussion with Vladimir Lipskiy
http://groups.google.com/groups?selm=006901c36204%24c181db10%24229d943e%4087w5ovc8gmxcahy
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: PIO Questions.
Benjamin Goldberg [EMAIL PROTECTED] writes:
I'm looking for, but not finding, information regarding the character
type and encoding on parrot io objects.
As an example of why... I found this in io.ops :
op write(in PMC) {
PMC *p = $1;
STRING *s = (VTABLE_get_string(interpreter, p));
if (s) {
PIO_write(interpreter, PIO_STDOUT(interpreter),
s-strstart, s-bufused);
}
goto NEXT();
}
Surely, blinding writing the bytes that are in a string, without
checking that the string's encoding and type match that of the stream,
is wrong.
The PIO-system does not know anything about encodings yet, but they
need to. We might push a encoding transforming layer on top of the
current layerstack.
I would expect something like:
op write(in PMC) {
PMC *p = $1;
STRING *s = VTABLE_get_string(interpreter, p);
if( s ) {
PMC *o = PIO_STDOUT(interpreter);
string_transcode(interpreter, s,
PIO_encoding(interpreter, o),
PIO_chartype(interpreter, o), s);
PIO_write(interpreter, o, s-strstart, s-bufused);
}
goto NEXT();
}
My current plan is to have it more like:
op write(in PMC) {
STRING *s = VTABLE_get_string(interpreter, $1);
if (s) {
PIO_puts(interpreter, PIO_STDOUT(interpreter), s);
}
goto NEXT();
}
with a revised PIO_puts API (using a parrotstring instead of a
c-string).
Except that I can't seem to find any PIO_encoding and PIO_chartype
functions.
Maybe we need to implement them. They surely must get integrated in
the ParrotIOLayerAPI to support transcoding layers.
#
Actually... I think that the op print(in PMC) and write(in PMC) are
designed wrong. Instead of asking for a string, and printing that
string, they should call a print_self and/or write_self vtable method on
the PMC, passing in the PIO object.
Putting an object to a stream is one of the most basic operations for
a PMC. But I don't think its a good idea to introduce many more vtable
functions. (Vtables are already really fat, mostly because every
PMC needs to know how to multiply a ParrotIO with the keyed version of
a Continuation). print, write, dump and all call one function. The way
of printing/writing/dumping the data should be controlled via flags
which can be stored in the stream.
In turn, the default
implementations of those methods should print or write the results of
DYNSELF.get_string() to that PIO object.
This way, a PMC whose string representation is very large doesn't need
to serialize itself to a string before it can be printed -- it can print
itself directly to the PIO object, thus avoiding allocating memory for
that big string, and probably lots of copying.
To avoid loss of synchronization between the get_string form of a pmc
and the print_self/write_self form of a pmc, one should be able to
define a string's get_string as creating a new stringstream PIO object,
printing itself to that stream, and returning the corresponding string.
However, there doesn't (yet) seem to be a stringstream layer. When do
we expect to have one?
There will be one. When? When I find time to do it or you (or anybody
else) submitts a patch.
Implementations of read/write and seek/tell are fairly
trivial. Problem is fdopen/getfd; the PIOHANDLE needs to be
interpreted as a string-pointer. We have semantic problems of fdopen
on other platforms than Unix (stdio, win32). This normaly leads to
failing t/pmc/io 3-4.
#
PIO_putps converts to a cstring, then calls PIO_puts.
PIO_puts is subject to change. The printing of cstrings can be
trivially done by calls to PIO_write. This will be ripped out of the
ParrotIOLayerAPI and a new puts wich passes parrotstrings down the
layers is introduced.
Since PIO_puts doesn't take a length, obviously it must be determining
the length of the string based on the presence of a nul character in
it. Thus, we cannot use PIO_puts to print binary data. This means that
PIO_write must be used. Since there's no op write(in STR), the only way
to do it from parrot is to create a PerlString, store our Sreg into it,
then call write. Blech.
#
Shouldn't everything in io_unix.c (except for pio_unix_layer) be
static? This isn't just about namespace pollution -- it slows down
linking and dynamic loading. I think.
Hmm, the same applies to the other io_foo.c files.
Yes it should. There should not be any inter-layer calls except via
the layerstack. Making them static would enforce this. If nobody
objects I will commit this change.
#
Why does PIO_unix_seek clear errno before calling lseek?
Don't know. Its in the code since Melvin added the seek in Jan 2002.
I will remove it.
#
Why does PIO_unix_tell have a temp variable pos?
This value gets returned.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern
[CVS ci] Factoring out the io layer iteration to helper functions.
Hello, Now I use my brand new commit access: Non-Terminal IO-Layers often call down to the lower-lying layers. Until now this was done in a while-loop reimplemented in every upper layer (At the moment there is only one io_buf but there will be more). This commit introduces new io_system private helper-functions which do the iteration of the layer-stack. PIO_xxx_down() walks the layersstack starting at the passed in layer, and calls the first implementation of the API it finds. All manual versions of the iteration are replaced by this helper functions. This commit is internal to the PIO subsystem, it should have no effect on the rest of parrot. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfT] Request for Test: build system changes
Andy Dougherty [EMAIL PROTECTED] writes:
On Sat, 30 Aug 2003, Juergen Boemmels wrote:
the make shipped with Borland C++ builder doesn't like the makefiles
in the current way. I had to tweak the buildfiles a little in order to
get it Configure and compile. (It still does not link but thats
another story). I removed the appearences of in the Makefiles with
${make_and} which is defined to '' on all platforms but bcc, and
simplified the cd dir make cd .. case by using a
perl-replacement for the -C commandlineoption of make on windows
platforms.
make -C is non-portable even among Unix systems. I think it's a
GNU-specific extension. It's not in Solaris make nor in BSD make,
as far as I can tell.
In short, if you have a portable perl-replacement for it, perhaps you
should just use your replacement everywhere.
Ok will look into this. I need to fix the quoting to work under Unix
and Windows. Should the name of the replacement-script still be
$(MAKE_C) or should I use some other name.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
[RfT] Request for Test: build system changes
Hi,
the make shipped with Borland C++ builder doesn't like the makefiles
in the current way. I had to tweak the buildfiles a little in order to
get it Configure and compile. (It still does not link but thats
another story). I removed the appearences of in the Makefiles with
${make_and} which is defined to '' on all platforms but bcc, and
simplified the cd dir make cd .. case by using a
perl-replacement for the -C commandlineoption of make on windows
platforms.
Can people on diffrent architectures please test the
attached patch?
Its already tested on linux/i386.
bye
bö
? ~bcc32.diff
Index: config/auto/sizes.pl
===
RCS file: /cvs/public/parrot/config/auto/sizes.pl,v
retrieving revision 1.7
diff -u -r1.7 sizes.pl
--- config/auto/sizes.pl 27 Apr 2003 07:36:44 - 1.7
+++ config/auto/sizes.pl 30 Aug 2003 15:36:48 -
@@ -118,7 +118,7 @@
};
# clear int8_t on error
-if($@) {
+if($@ || !exists $results{hugeintval}) {
Configure::Data-set('int8_t' = undef);
next;
}
Index: config/gen/makefiles/imcc.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/imcc.in,v
retrieving revision 1.28
diff -u -r1.28 imcc.in
--- config/gen/makefiles/imcc.in 16 Aug 2003 17:44:19 - 1.28
+++ config/gen/makefiles/imcc.in 30 Aug 2003 15:36:48 -
@@ -52,8 +52,8 @@
echo Compiling with:
@$(PERL) ../../tools/dev/cc_flags.pl ./CFLAGS echo $(CFLAGS) xx$(O) -c xx.c
-../../$(PARROTLIB):
- cd ..${slash}.. $(MAKE) $(PARROTLIB) cd languages${slash}imcc
+..${slash}..${slash}$(PARROTLIB):
+ $(MAKE_C) ../.. $(PARROTLIB)
# The .flag files are needed because we are keeping some derived files in CVS,
# which does not keep accurate timestamps on the files, relative to each other.
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.114
diff -u -r1.114 root.in
--- config/gen/makefiles/root.in 28 Aug 2003 11:03:02 - 1.114
+++ config/gen/makefiles/root.in 30 Aug 2003 15:36:48 -
@@ -182,6 +182,7 @@
# do it for you.
#
${make_set_make}
+MAKE_C = ${make_c}
.c$(O) :
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
@@ -319,23 +320,23 @@
#
###
-examples/assembly/mops.pbc : examples/assembly/mops.pasm
- cd examples cd assembly $(MAKE) mops.pbc PERL=$(PERL) cd .. cd ..
+examples${slash}assembly${slash}mops.pbc : examples${slash}assembly${slash}mops.pasm
+ $(MAKE_C) examples/assembly mops.pbc
-examples/assembly/mops.c : examples/assembly/mops.pbc pbc2c.pl
- $(PERL) pbc2c.pl examples/assembly/mops.pbc examples/assembly/mops.c
+examples${slash}assembly${slash}mops.c : examples${slash}assembly${slash}mops.pbc pbc2c.pl
+ $(PERL) pbc2c.pl examples${slash}assembly${slash}mops.pbc examples${slash}assembly${slash}mops.c
-examples/assembly/mops${exe} : examples/assembly/mops$(O) $(LIBPARROT)
- $(LINK) $(LINKFLAGS) ${ld_out}examples/assembly/mops${exe} examples/assembly/mops$(O) $(LIBPARROT) $(C_LIBS)
+examples${slash}assembly${slash}mops${exe} : examples${slash}assembly${slash}mops$(O) $(LIBPARROT)
+ $(LINK) $(LINKFLAGS) ${ld_out}examples${slash}assembly${slash}mops${exe} examples${slash}assembly${slash}mops$(O) $(LIBPARROT) $(C_LIBS)
-examples/assembly/life.pbc : examples/assembly/life.pasm
- cd examples cd assembly $(MAKE) life.pbc PERL=$(PERL) cd .. cd ..
+examples${slash}assembly${slash}life.pbc : examples${slash}assembly${slash}life.pasm
+ $(MAKE_C) examples/assembly life.pbc
-examples/assembly/life.c : examples/assembly/life.pbc pbc2c.pl
- $(PERL) pbc2c.pl examples/assembly/life.pbc examples/assembly/life.c
+examples${slash}assembly${slash}life.c : examples${slash}assembly${slash}life.pbc pbc2c.pl
+ $(PERL) pbc2c.pl examples${slash}assembly${slash}life.pbc examples${slash}assembly${slash}life.c
-examples/assembly/life${exe} : examples/assembly/life$(O) $(LIBPARROT)
- $(LINK) $(LINKFLAGS) ${ld_out}examples/assembly/life${exe} examples/assembly/life$(O) $(LIBPARROT) $(C_LIBS)
+examples${slash}assembly${slash}life${exe} : examples${slash}assembly${slash}life$(O) $(LIBPARROT)
+ $(LINK) $(LINKFLAGS) ${ld_out}examples${slash}assembly${slash}life${exe} examples${slash}assembly${slash}life$(O) $(LIBPARROT) $(C_LIBS)
###
#
@@ -343,11 +344,11 @@
#
###
-examples/mops/mops$(O) : examples/mops/mops.c
+examples${slash}mops${slash}mops$(O) : examples${slash}mops${slash}mops.c
-examples/mops/mops${exe} : examples/mops/mops$(O)
- $(LINK) $(LINKFLAGS) ${ld_out}examples/mops/mops${exe} \
- examples/mops/mops$(O) $(LIBPARROT) $(C_LIBS)
Re: MSVC++ complaints
Vladimir Lipskiy [EMAIL PROTECTED] writes:
d:\build\parrot\include\parrot\interpreter.h(40) : error C2040:
'Parrot_Interp' : 'struct Parrot_Interp *' differs in levels of indirection
from 'struct Parrot_Interp'
My compiler doesn't like the following:
typedef struct Parrot_Interp *Parrot_Interp;
This is valid ANSI C. structs and types live in seperate
namespaces. Problem is if the compiler thinks for whatever reason it
is compiling C++. Then sturct, class and typedef are all in one
namespace. Headerfiles may be protected with
#ifdef __cplusplus
extern C {
#endif
or the equivalent __BEGIN_DECLS.
io.h uses the convention to prepend every struct with a _ like
typedef struct _ParrotIO ParrotIO;
(This convention wasn't introduced by me)
If we decide to use this as general convention we should document this
in PDD07.
The current PDD07 says that structs should start with a lower case
letter and typedefs should start with an upper case letter. This seems
not to be followed consequently as a little grepping through the tree
shows:
2037 lines use struct Upperletter (762 lines in header files)
454 lines use struct lowerletter (29 lines in header files)
98 lines use struct _underscore (16 lines in header files)
I further don't know if its is a good idea to hide the pointer
character of a type in the typedef, like in
typedef struct Parrot_Interp *Parrot_Interp;
or if we just introduce an alias for the struct like in
typedef struct pobj_t { ... } pobj_t;
Anyway it should be consistent through the code. (And documented in
PDD07). These are some really big patches colliding with much other
outstanding patches.
[...]
INTVAL Parrot_get_datatype_enum(Interp * interpreter, STRING *typename);
typename is a keyword in C++. This declaration
INTVAL Parrot_get_datatype_enum(struct Parrot_Interp *, STRING *);
from PDD07:
: Variable names should be included for all function parameters in the
: function declarations. These names should match the parameters in the
: function definition.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] vtable-dump
Leopold Toetsch [EMAIL PROTECTED] writes: Tracing through Parrot programs shows the type and value of variables. This doesn't work very well for PMCs, trace_pmc_dump() tries to extract some info from the PMC, but much better would it be, if the PMC itself can return a string representation of itself. ACK, wanted something like this forever. STRING* dump(INTERP, SELF, STRING *, INTVAL flags); what is the STRING * parameter good for. I assume lineheaders. append and return a printable representation of SELF, with flags being: 0x1 ... name (whoami) 0x2 ... id (enum) 0x4 ... value(s) (non aggregates) 0x8 ... address ... e.g. newlines, tabs in output for aggregates 0x100...n ... dump of aggregate items at nesting (n-0x100) Use the lower bits for nesting depth. This way you can use n = flags 0xff to obtain the nesting depth, and still define the flags which can be passed to the passed to dump of the childs: dump (..., (flags ~0xff) | n-1); Comments welcome leo allways boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] vtable-dump
Leopold Toetsch [EMAIL PROTECTED] writes: Juergen Boemmels [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: STRING* dump(INTERP, SELF, STRING *, INTVAL flags); what is the STRING * parameter good for. I assume lineheaders. The place, where to append SELF.dump. Appending doesn't consume a new header for each piece. Ah, ok. How do you want to solve indentation in multiline dumps? With an additional indent parameter? Use the lower bits for nesting depth. This way you can use n = flags 0xff to obtain the nesting depth, and still define the flags which can be passed to the passed to dump of the childs: dump (..., (flags ~0xff) | n-1); That would restrict the nesting depth. 2 more shifts don't harm, dump()ing will be slow enough. Ok, then use a mask of 0x. Or even 0xff (I don't want to see a dump of depth 4 million on my screen). I wanted to keep the opportunity to pass the other flags like multiline or name only down to the childs. BTW what about self-referential structures (same problem as with clone): $ cat rclone.pasm new P0, .PerlArray new P1, .PerlInt push P0, P1 push P0, P0 clone P2, P0 end $ ulimit -m 5000 # don't forget, if you havn't any $ parrot rclone.pasm Segmentation fault (core dumped) I'm thinking of dump to be: - if (flag) return - set a flag on SELF - dump children - reset flag But this doesn't help against very deeply nested structures. An alternative would be to have a general iterator with a todo-list like the current DOD mark_ptr. We could use a generalization of the mark-scheme by passing a function argument for DOD too with some? impact on DOD performance. A general nesting iterator would be a good idea. It might be useful in quite a few places: DOD, destruction ordering, dumping, serialisation, cloning. But DOD is the most timing-critical: It's called often and has to visit all active objects, whereas the others only visit the affected objects (the ones which gets destructed, dumped, serialized, cloned). When we want to use this for serialization too, we need some means to refer to an already visited PMC, passing an optional hash would do it IMHO. When using callbacks they often have a void* params. The interpretation of this *params is job of the callback. boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Warnocks Dilemma (was Maybe [PATCH] move some stuff out of io.h to io_privat.h)
Hello, last week I send in a patch which creates io/io_private.h, but nobody replied to it. The classical Warnock's Dilemma. I have the strange feeling that its because nobody read my mail, because sometimes the p6i mailinglist does not like mail with attachments. But otherwise it made its way to http://nntp.x.perl.org/group/perl.perl6.internals/17670 so somebody should have read it. Anyway, I can resend it, resend it with the patch inline or put it in the bug-tracker. What should I do? bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Embedding Parrot in Perl
Benjamin Goldberg [EMAIL PROTECTED] writes: Luke Palmer wrote: I started working on some XS code for embedding a Parrot interpreter in Perl. I ran into a few problems: 1) I don't know XS :-) (good way to learn, though) 2) What do I put as stacktop in Parrot_init()? I can't just use a local variable in the calling function, because it will return and there might be something lower than that later... If our DoD is no longer walking the C stack, then stacktop should no longer be needed. Until the code is changed, just pass NULL. AFAIK, the stack is still walked. (I don't like this but thats a diffrent story). So Parrot_init() should be called with a real stacktop. A typical codefragment to do this is: struct Parrot_Interp *interpreter; interpreter = Parrot_new(); Parrot_init(interpreter, interpreter); 3) I'd like to have the PIR compiler available to this embedded interpreter. What would be the best way to do that? IMCC implements the (static) functions imcc_compile_pir and imcc_compile_pasm in parser_util.c. You can take a look at them. But be careful imcc uses some global data in the parser and the lexer, so this is not reentrant. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] constant PMCs and classes
Leopold Toetsch [EMAIL PROTECTED] writes:
The issues WRT the union initializer are gone now (can people please
test, if the program below compiles cleanly now) - but:
- make_COW_* sets flag on the source string [1]
- if that is solved (with a special RO flag, or whatever) we have:
- string_make sets a default type and encoding if these arguments were
NULL. These constant strings have NULL for encoding/type so during
string_append as the encodings differ transcode is called - next
SIGSEGV with NULL encoding pointer.
It is in principle possible to use a default_encoding in the static
initialiser, but then a relocation is needed because the static string
and default_encoding are not in the same object-file. This would lead
to a longer load-time.
On the other hand accessing the encoding through macros
#define ENCODING_skip_forward(enc, p, n) ((enc) ? \
(enc)-skip_forward(p, n) : \
default_enc-skip_forward(p, n))
has a runtime cost; the test will fool the branch prediction.
So using these .rodata-constant STRINGs needs a lot of work.
- COW code (there are problems with COWed stacks anyway)
- transcoding stuff (should be changed to use {strstart, byteidx} and
do something about default vs NULL type/encoding.
Next idea:
create a new function
STRING *string_from_static_cstring(const char *cstr);
which does not copy the string to newly allocated memory. But maybe
then the problems with COW are still there.
[...]
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] constant PMCs and classes
Leopold Toetsch [EMAIL PROTECTED] writes: Benjamin Goldberg [EMAIL PROTECTED] wrote: #define PARROT_DECLARE_STATIC_STRING(name, cstring) \ [ big snip ] While Juergen's original or your proposal are fine, they don't work (or not as proposed). First there are compiler issues: $ gcc -Iinclude -Lblib/lib -lparrot -ldl -Wall -g bg.c ./a.out #v+ bg.c: In function `main': bg.c:35: warning: braces around scalar initializer bg.c:35: warning: (near initialization for `_Parrot_static_mystr_STRING.obj.u.int_val') bg.c:35: warning: initialization makes integer from pointer without a cast bg.c:35: warning: excess elements in scalar initializer bg.c:35: warning: (near initialization for `_Parrot_static_mystr_STRING.obj.u.int_val') #v- The first warning is about the Union initialisation. A initialiser of a union always initializes the first element, which is a INTVAL, but I wanted to initialize the last item (which is not possible in pure ANSI, but it turned out gcc got it right anyway). A simple change of order in the Union would make this warning go away. The declaration looks ok at first sight, my gcc 2.95.2 might be wrong, but anyway, a bigger problem is here: PIO_printf(interpreter, %S\n, mystr); Program received signal SIGSEGV, Segmentation fault. 0x400f8725 in make_COW_reference (interpreter=0x8049828, s=0x80486e0) at string.c:95 95 PObj_constant_CLEAR(s); (gdb) bac #0 0x400f8725 in make_COW_reference (interpreter=0x8049828, s=0x80486e0) at string.c:95 #1 0x400f91b6 in string_copy (interpreter=0x8049828, s=0x80486e0) at string.c:497 Ah it seems that make_COW_reference wants to change a constant string. As my code puts the static strings in .rodata (this was one of the targets of my experiments) it is not possible in any way to change this item. I even think PObj_constant_CLEAR(s) is evil. One reason for setting a PObj_constant_FLAG is to declare that an object will not change. Unsetting this flag means breaking this contract. snippet from objdump: .rodata0011 _Parrot_static_mystr_cstring.15 .rodata0024 _Parrot_static_mystr_STRING.16 If we get a general compiler independend solution for declaring static STRINGs we still have nothing for static keys. The main problem of all this code is the union initialiser. Static keys could also created with an initialisier, but i think this needs an other union-val to be initialized. There are gcc extension to init arbitary members, but ANSI-C allows only the initializiation of the first member. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Weak References?
Benjamin Goldberg [EMAIL PROTECTED] writes: But suppose that at the end of DoD, the object we're weakly referring to gets marked as alive? Now, we would need to look through that object's list of destroy-functions, and remove all of the weakref-callbacks. At the end of DoD nobody gets marked alive anymore. The calling of destroy-functions is done at sweep-time. There might be a problem when you destroy referent and referee at the same DoD run. Then the weakref-callback can be called on a dead but not destroyed object. It is a matter of destruction ordering to destroy the referee first, which destroyes the weakref. But if the weakref-callbacks are stored in a seperate data structure, created during DoD, then there's no problem; this data structure will get re-created for each DoD pass, and thus always start empty. This is unnecessary complicated. And it slows down the DoD run by creating a datastructure. Also, by keeping them seperate, we can walk all the callback functions before destructing the dead objects. This is a problem of destruction ordering. You try to solve it by introducing a seperate step, which works in this special case. But destruction ordering is a much harder problem. (But you're right -- it is too complicated to do a lookup table. A simple linked list should do fine.) But one other thing, what happens if the object holding the weakref dies before the refrenced object? Then the callback-function will be called for a dead object. Each callback-function belongs to a pmc. The DoD should be able to know this, and act on it. So if the pmc which registered the callback is dead, (or if the object weakly referred has since then come alive), then the callback isn't called. So pobject_weakref() needs to return a handle for the weakref and there needs to be a function weakref_destroy(weakref_handle *handle). Other issue is who owns the data_structure of the weakref? The referent, the referee, or will this be garbage-collected (which makes the weakref_handle a PObj* and weakref_destroy its custom destroy function. The garbage collector owns everything except for callback_info, which belongs to the pmc which registered the weakref-callback. This is one possiblity. Therefor the destroy-function of the registering PMC must be extended with freeing the callback_info. As we already extend the destroy function of the PMC referenced by the weakref this needs no new mechanics. After DOD finishes, the lookup table is walked; for each entry whose Pobj* hasn't been marked as alive, the callbacks are called. The effect of this of course is that a WeakRef has no cost except during Dead Object Detection. It only has a cost at object destroy-time. (If the weakrefs are garbagecollected they have an effect on DOD in the way that there are more objects to trace) *blink* More objects? Oh, you're assuming that pobject_weakref is returning a Pobj* handle. Returning a PObj* handle is the other possibility. The registering PMC holds a hard reference to the callback_info, and the callback_info deregisters itself when it gets destroyed. The advantage of this approach is there is no need to malloc/free the memory for callback_info, it just uses the standard gc-allocator. Keeping the callback data in a seperate list which only exists for the duration of the dod prevents this. Or rather, you do have to clean up the linked list, of course, but there's no extra bookkeeping. *blink too* You don't want to use a weakref you want a weak_MARK. The callbacks are getting registered during each mark, and get used or destroyed. But this registring and destructing has a cost too. This cost is only payed by the weakmark-using objects, but they need to be paid on every DoD run. this is only useful if a hashlookup is fast compared with string_make. Well, it might be. Hashing can be quite fast, ya know. Only the profiler can tell you which one is faster. Here's a better idea, one you'll have more difficulty arguing with -- imagine a debugger, written in parrot. We are going to have one, right? Hmm, p6tkdb :) It needs to keep references to objects it's interested in, but if they're strong references, then we would have trouble debugging objects with custom destroys (or worse, objects needing timely destruction), since the debugger's references to them would prevent them from being cleaned up. Changing to weakrefs removes this kind of horrible heisenbug. Something totaly diffrent. DoD runs happen normaly in out of memory situations. Doing things like running a debugger callback befor a sweep finishes might ask for trouble. If the debugger is writen in parrot, then the callback-function which deregisters the object is surely also written in parrot. Recursive runloops with unfinished sweeps, combined with early destruction in the inner runloop. This will be really fun. bye boe -- Juergen Boemmels
Re: Weak References?
Luke Palmer [EMAIL PROTECTED] writes: I may be missing the problem that you are talking about, but it seems to me that since we have PMCs which mark themselves instead of being automatically marked, a WeakRef PMC would be trivial... I don't think it needs to be any more fundamental than a PMC. Marking itself does not help here. The mark-function of a PMC is called after it is already marked. Self-marking does nothing in the best case, in the worst case it blocks the DoD in an endless loop. Anyway a weakref needs to extend the destroy-function of the refered object (on a per object basis). This is whats not possible in current parrot. Parrot_exit/Parrot_on_exit does something similar but not for the destruction of an object but for the end of the program. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [CVS ci] PackFile-15: print warning location
Benjamin Goldberg [EMAIL PROTECTED] writes:
Normal processors also don't have setline and setfile operations. They
use an extra segment in the *.o file, which is only used by the
debugger. This could also be done in parrot.
In other words, setline and setfile ops in source don't translate to
actual ops in the bytecode, but instead translate to additions/changes
to the debugging segment?
In principle yes. But as they are no opcodes any more they should not
look like ones. They should be written .setline or #setline
#line 17 sourcefile.p6
I don't like this syntax -- it sounds too easy for someone to write a
comment like:
#When this was in the original foobar language, it was on
#line 17
And have it interpreted as a directive, when the author meant for it to
be just a comment.
from the point of the bytecode this is just a comment. No different
bytecode is generated with or without this line. Only for the
debugsegment gets other information.
There's no reason not to have the directives look like ops (setline,
setfile).
No they should not look like ops. They are no ops.
They might look like macros .setfile, macros can evaluate to nothing.
Oh, and you could have get{line,file} directives, which end up
translated as being simple set ops, using the info generated by the
set{line,file} directives.
Same here. Use .getline macros which are expanded to a set
operation. Or better use a .currentline macro which expands to the
current line. Much like the __LINE__ macro in C.
bye
boe
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Weak References?
Benjamin Goldberg [EMAIL PROTECTED] writes: I would like for Parrot to have some way of creating Weak References; I think that this is probably a vital feature. The way I envision this is as follows. The following typedef and new function would be added: typedef void (*pobject_died_cb)(INTERP, PMC* who_asked, Pobj* weakref, void *callback_info); void pobject_weakref(INTERP, pobject_died_cb callback, Pobj* weakref, void *callback_info); This might be sometimes useful. Keeping a container of active objects like filehandles or windows for example. In this case it can't mark the reference because this would make the object active forever. Inside of a PMC*'s mark method, it registers callbacks (using the above function) so that it will be informed about what to do if the object to which it weakly refers to is found to not be alive at the end of the DOD sweep. This does not need to go into the mark function. The weakref_callback code can be called inside the destroy function. Im not sure if it should be called befor or after the custom destroy-function is run. And is the order of the weakref_callbacks defined. The pobject_weakref function first checks if the 'weakref' argument has been marked as alive -- if so, nothing happens. Then, it adds the Pobj* to a lookup table, pointing from the Pobj*, to a list of registered callbacks for that Pobj*. This is far to complicated. Each object has a list of destroy-functions, one of them is the costom-destroy function the others are the weakref-callbacks. But one other thing, what happens if the object holding the weakref dies before the refrenced object? Then the callback-function will be called for a dead object. So pobject_weakref() needs to return a handle for the weakref and there needs to be a function weakref_destroy(weakref_handle *handle). Other issue is who owns the data_structure of the weakref? The referent, the referee, or will this be garbage-collected (which makes the weakref_handle a PObj* and weakref_destroy its custom destroy function. After DOD finishes, the lookup table is walked; for each entry whose Pobj* hasn't been marked as alive, the callbacks are called. The effect of this of course is that a WeakRef has no cost except during Dead Object Detection. It only has a cost at object destroy-time. (If the weakrefs are garbagecollected they have an effect on DOD in the way that there are more objects to trace) The first, perhaps most important use, would be to implement a string-interning table. You'd have a global (per-interpreter) pmc which contains a hashtable of cstrings to perlstrings; if the cstring is present, the corresponding perlstring is returned; otherwise a new perlstring would be created and added to the table, then returned. If any of the perlstrings go out of scope, then their hash entries should disappear from the table. Obivously, if the table contained normal references to the strings, then they won't ever go out of scope. And if the table simply doesn't mark them as alive, it wouldn't know when they're dead. But with weakrefs, this is easy. this is only useful if a hashlookup is fast compared with string_make. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
