Re: Library loading and initialization sequence
Dan Sugalski [EMAIL PROTECTED] wrote: Next, the sequence of loading. Right now there's a load_pmc op Gone. and loadlib ops. I'd like to unify that Done. When we load a library, the bytecode should probe for and, if it exists, call Parrot_lib_load_%s, where %s is the library name. If it doesn't exist, it assumes a native library, this is what the sequence loadlib / dlfunc is expecting, --done ... , the interpreter, and returns a PMC representing the library that we can query later. ... until here. What kind of PMC is e.g a PMC-library intended to return? As it seems, that the Parrot_lib_init_%s code is called again on interpreter forking, the PMC has to hold the library handle. Now, when Parrot_lib_load_%s should construct the PMC, it can't place the handle into the PMC. Of course, the dynext.c:Parrot_load_lib() could stuff the handle into the PMC, if the returned PMC is appropriate for that. I have an optional (currently unused, NULL) 3rd argument to Parrot_load_lib, which could be an initializer, if needed, so that loadlib P1, the_lib, P2 would be possible too. Dan leo
RE: MANIFEST verification
Robert Spier wrote:
I need a script that meets the following specs:
Input (via command line)
1) file representing MANIFEST
2)file representing MANIFEST.SKIP
3)file representing list of all files found
Output (via stdout)
error message if manifest check fails
Restrictions:
The script cannot access any other files/filesystems/directory
listings besides the data in the files provided on the command
line.
I think the easiest to implement this is by subclassing
ExtUtils::Manifest, and overriding manifiles() and maybe one or two
other subroutines.
I assume you can probably yank the Mac and VMS stuff... but left it in
anyway.
Garrett
#!/usr/bin/perl
use ExtUtils::Manifest;
die expected 3 args unless 3 == @ARGV;
-f or die file not found: $_ for @ARGV;
my $found = {};
my $Is_MacOS = $^O eq 'MacOS';
my $Is_VMS = $^O eq 'VMS';
require VMS::Filespec if $Is_VMS;
$ExtUtils::Manifest::MANIFEST = shift;
my $read = ExtUtils::Manifest::maniread() || {};
$ExtUtils::Manifest::DEFAULT_MSKIP = shift;
my $skip = ExtUtils::Manifest::_maniskip();
open IN, shift;
/^(.*)$/ and $found-{$1}++ while (IN);
close IN;
# _check_manifest
foreach my $file (sort keys %$found){
next if $skip-($file);
unless ( exists $read-{$file} ) {
my $canon = $Is_MacOS
? \t.ExtUtils::Manifest::_unmacify($file)
: '';
warn Not in $ExtUtils::Manifest::MANIFEST: $file$canon\n;
}
}
# _check_files
foreach my $file (sort keys %$read) {
warn No such file: $file\n unless exists $found-{$file}
}
1;
__END__
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
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
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. 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. 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. 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: 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: PIO tests
Since PIO_parse_open_flags just assists the IO code in fulfilling an API, but is not part of the published API, I would suggest that it be moved into the private, but before tests are written for it, there should be a spec written. When I wrote the code, there was not even a design for what sort of API we would implement. I chose supporting a stringified flags because I liked it, but there was never much discussion about whether this was the right way or not. It is a very Perlish way of doing it, but languages that have constant values would then have to translate back to the string version to run on top of Parrot. That, or there will need to be a second form of open() written to take numerical constants. In short, I think it should be discussed as to whether it is even the right way. It seemed right at the time, but now I'm having second thoughts. -Melvin Juergen Boemmels [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/30/2003 01:20 PM To: Michael Scott [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: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: PIO tests
On Tuesday, Sep 30, 2003, at 19:20 Europe/Berlin, Juergen Boemmels wrote: 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. Being more or less of a hack myself, I'm happy to persist with the existing scheme, in the absence of any imminent ideal. The main hassle with c_output_is() is, when developing the test, the C code dies and the Perl harness doesn't notice. That's why I stick a done at the end of every test. 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
On Tuesday, Sep 30, 2003, at 19:31 Europe/Berlin, Melvin Smith wrote: Since PIO_parse_open_flags just assists the IO code in fulfilling an API, but is not part of the published API, I would suggest that it be moved into the private, but before tests are written for it, there should be a spec written. Given how much code is already written, it's probably most efficient to write the spec as tests. When I wrote the code, there was not even a design for what sort of API we would implement. I chose supporting a stringified flags because I liked it, but there was never much discussion about whether this was the right way or not. It is a very Perlish way of doing it, but languages that have constant values would then have to translate back to the string version to run on top of Parrot. That, or there will need to be a second form of open() written to take numerical constants. When I was writing the PIO_parse_open_flags() test it did seem to me rather Perlish to have string flags in the first place. But I'm a new cockroach in town, so I kept my mouth shut, not wanting to get stomped on. If the PIO_F_* flags used by open() were moved up to io.h then they could be exported as .constants by config/gen/parrot_include.pl and used explicitly. Various composite flags could be added for convenience. PIO_F_WRITE_TRUNC () PIO_F_WRITE_APPEND () PIO_F_READ_WRITE(+, +) Also, add an INT flag version of open. inline op open(out PMC, in STR, in INT) In short, I think it should be discussed as to whether it is even the right way. It seemed right at the time, but now I'm having second thoughts. -Melvin
Re: PIO tests
On Tuesday, September 30, 2003, at 01:24 PM, Michael Scott wrote: When I was writing the PIO_parse_open_flags() test it did seem to me rather Perlish to have string flags in the first place. But I'm a new cockroach in town, so I kept my mouth shut, not wanting to get stomped on. If the PIO_F_* flags used by open() were moved up to io.h then they could be exported as .constants by config/gen/parrot_include.pl and used explicitly. Various composite flags could be added for convenience. PIO_F_WRITE_TRUNC () PIO_F_WRITE_APPEND () PIO_F_READ_WRITE(+, +) Also, add an INT flag version of open. inline op open(out PMC, in STR, in INT) It does seem to make more sense to have the open op take an INT mode, à la the Unix open(2), and leave the translation from a flags string to an INT to the language level. This of course leaves the PIO layer less language-specific, which is good, and it also gets rid of ambiguities such as whether + is a valid alternative to +, or whether is valid, or what do do with a mode string such as ;)-, since a bit in an INT is either set or not, making an INT flag-set unambiguous and (probably) never invalid. Here is the list of modes from the open(2) man page on my system; I'm not sure if this is a subset or a superset of what PIO should support: O_RDONLYopen for reading only O_WRONLYopen for writing only O_RDWR open for reading and writing O_NONBLOCK do not block on open or for data to become available O_APPENDappend on each write O_CREAT create file if it does not exist O_TRUNC truncate size to 0 O_EXCL error if create and file exists O_SHLOCKatomically obtain a shared lock O_EXLOCKatomically obtain an exclusive lock JEff
Re: MANIFEST verification
Thank you Garrett! That's perfect. Starting now, if anyone does something to make the MANIFEST unhappy, it will print out a message at the bottom of the commit log. You'll see things like this: manicheck: Not in MANIFEST: somefile1 manicheck: File not found: somefile2 Enjoy! -R (CVS Timelord) Robert Spier wrote: I need a script that meets the following specs: I assume you can probably yank the Mac and VMS stuff... but left it in anyway.
