Hi,
I just released a new version of a module this week-end [1], and it was
(wrongly) packaged this morning. Actually, I noticed two problems with
this packaging, which are making the process a pain : I think they are
worth to share.
* The module contains C source code. But the packaging was (wrongly)
done as if it was a macro-based module. This is a human error which can
happen because the developper has no way to give the information to the
packager.
What we may need is a button "My module contains a C source" on the
atoms web interface. This way, the packager knows what exactly must be
done with the sources of the module (i.e. compile the code on several
machines).
* Many tests fail (as indicated in the distfun_0.8_test.txt logfile).
The typical log looks like :
[...]
001/160 - [SCI/contrib/distfun/0.8] betacdf..................failed:
premature end of the test script
002/160 - [SCI/contrib/distfun/0.8] betainv..................passed
[...]
I have the same behavior on my machine. Notice that if you run the tests
twice, you will not get the same failed/passed status. What happens is
that, sometimes (looks like random), some module (say apifun, for
example) is not loaded. But the betacdf uses apifun, and this makes the
test fail. This happens if the module is loaded either manuall after an
exec statement in the .scilab script, or automatically, after an
atomsInstall statement.
I think that there might be an issue with the way the modules are loaded
at startup. Perhaps some function does not wait until all the packages
are started up. I have never been able to see this precisely. But this
makes the testing process really horrible when it involves dependent
modules.
Regards,
Michaël
PS
[1] http://atoms.scilab.org/toolboxes/distfun/0.8
_______________________________________________
dev mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/dev
