Re: Untested modules update: The Magic Number is 27
On Thu, Dec 27, 2001 at 02:58:56PM -0500, Michael G Schwern wrote:
Dynaloader has a good sized documented interface which isn't
necessarily exercised by the core modules. Test that.
Remember to test DynaLoader with miniperl, though, otherwise you are
cheating. And not fair testing dynaloading unless $Config{usedl},
either.
Its also nice to know something a little more organized than
something exploded when I tried to build Perl. And when hacking on
DynaLoader, its easier to run a fast test suite than to rebuild Perl
every time you want to check if you broke something leaving the
ultimate rebuild check to the end.
I assure you that if Dynaloader is busted you are not going to
rebuild Perl any further than miniperl.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: Untested modules update: The Magic Number is 27
Nicholas Clark [EMAIL PROTECTED] writes: On Thu, Dec 27, 2001 at 09:11:26AM -0800, Benjamin Stuhl wrote: --- Michael G Schwern [EMAIL PROTECTED] wrote: [... and the shears went snip, snip, ker-snip ...] #B::Bytecode[module broken, can't test] #B::C [ditto] #B::CC [ditto ditto] What is up with B::C ? #B::Concise [[EMAIL PROTECTED]] #B::Disassembler[Wolfgang Laun] #B::Lint[[EMAIL PROTECTED]] #B::Stackobj[[EMAIL PROTECTED]] #B::Xref[[EMAIL PROTECTED]] Byteloader Byteloader is untestable without a working B::Bytecode (we have no way of generating input files for it. Anyway, Byteloader/B::Bytecode are actually speed _losses_, so IMHO they should probably simply be killed - they're just wasted space in the distribution. (IIRC, I was the last person to seriously hack on them.) And if they get removed from the core, they obviously don't need tests ;-). I think I agree on all of this. (think in that I've read it twice and can't see any obvious reason why I'm going to be able think of any counter arguments between now and perl6) Dynaloader What sort of test does Dynaloader need? If dynaloading doesn't work, no dynamic extensions (Socket, Fcntl, IO, POSIX, ...) will work, and the errors they'll spew are pretty obviously loading problems. XSLoader::load 'POSIX', $VERSION; XSLoader::load 'Fcntl', $VERSION; XSLoader::load 'Socket', $VERSION; XSLoader::load 'IO', $VERSION; although that's a biased picture as it appears that many other core extensions are using its interface directly, rather than via the featherweight XSLoader. (including Encode.pm, I18N.pm, threads.pm threads/shared.pm) Does it make sense to switch Encode et. al. to XSLoader? (Did anyone take action to move Cwd.pm to place where XSLoader expects it?) From its pod: DynaLoader Interface Summary @dl_library_path @dl_resolve_using @dl_require_symbols $dl_debug @dl_librefs @dl_modules Implemented in: bootstrap($modulename) Perl @filepaths = dl_findfile(@names) Perl $flags = $modulename-dl_load_flags Perl $symref = dl_find_symbol_anywhere($symbol) Perl $libref = dl_load_file($filename, $flags) C $status = dl_unload_file($libref) C $symref = dl_find_symbol($libref, $symbol) C @symbols = dl_undef_symbols()C dl_install_xsub($name, $symref [, $filename])C $message = dl_error C so I guess that as much as that as possible, preferable all needs testing (in an ideal world. As I found with Benchmark.t, trying to test everything gets quite big. And it had less things than Dynaloader.) Nicholas Clark -- Nick Ing-Simmons http://www.ni-s.u-net.com/
Re: Untested modules update: The Magic Number is 27
On Thu, Dec 27, 2001 at 09:11:26AM -0800, Benjamin Stuhl wrote: --- Michael G Schwern [EMAIL PROTECTED] wrote: [... and the shears went snip, snip, ker-snip ...] #B::Bytecode[module broken, can't test] #B::C [ditto] #B::CC [ditto ditto] #B::Concise [[EMAIL PROTECTED]] #B::Disassembler[Wolfgang Laun] #B::Lint[[EMAIL PROTECTED]] #B::Stackobj[[EMAIL PROTECTED]] #B::Xref[[EMAIL PROTECTED]] Byteloader Byteloader is untestable without a working B::Bytecode (we have no way of generating input files for it. Anyway, Byteloader/B::Bytecode are actually speed _losses_, so IMHO they should probably simply be killed - they're just wasted space in the distribution. (IIRC, I was the last person to seriously hack on them.) And if they get removed from the core, they obviously don't need tests ;-). I think I agree on all of this. (think in that I've read it twice and can't see any obvious reason why I'm going to be able think of any counter arguments between now and perl6) Dynaloader What sort of test does Dynaloader need? If dynaloading doesn't work, no dynamic extensions (Socket, Fcntl, IO, POSIX, ...) will work, and the errors they'll spew are pretty obviously loading problems. XSLoader::load 'POSIX', $VERSION; XSLoader::load 'Fcntl', $VERSION; XSLoader::load 'Socket', $VERSION; XSLoader::load 'IO', $VERSION; although that's a biased picture as it appears that many other core extensions are using its interface directly, rather than via the featherweight XSLoader. (including Encode.pm, I18N.pm, threads.pm threads/shared.pm) From its pod: DynaLoader Interface Summary @dl_library_path @dl_resolve_using @dl_require_symbols $dl_debug @dl_librefs @dl_modules Implemented in: bootstrap($modulename) Perl @filepaths = dl_findfile(@names) Perl $flags = $modulename-dl_load_flags Perl $symref = dl_find_symbol_anywhere($symbol) Perl $libref = dl_load_file($filename, $flags) C $status = dl_unload_file($libref) C $symref = dl_find_symbol($libref, $symbol) C @symbols = dl_undef_symbols()C dl_install_xsub($name, $symref [, $filename])C $message = dl_error C so I guess that as much as that as possible, preferable all needs testing (in an ideal world. As I found with Benchmark.t, trying to test everything gets quite big. And it had less things than Dynaloader.) Nicholas Clark
