Progress over the weekend

Progress notes:

ConfigurationOfSciSmalltalk updated to version 1.01 (and github README
tracking it).
     This includes some bug-fixes Werner Kassens submitted (with tests)
for the GeneticOptimizer from DHB Numerical.
     Whenever I update this, I bring it in to a clean image and run the
tests. I expect to get the same results as in the development image.
This gives me the freedom to switch images or machines on the fly, and
verifies that when I say it's available it's really going to work. Right
now I'm working between Pharo-2.0 and Pharo-1.4. I don't think there are
too many issues with backwards compatibility, though I noticed loading
into Pharo-1.2 that the allowable syntax for boolean and: messages were
relaxed since then. I may test as far back as Pharo-1.3.

More tests included.
     Well, I could spend a few weeks bringing tests up to spec. Right
now there are over 400 methods, the large majority of them in the DHB
package, with no coverage. And some of the tests I've written exercise
the methods, but don't really show much intent. I think 100% coverage
for new methods is a reasonable expectation. Writing more than useful
for the Dhb-Numerical classes would bog me down too much to be worthwhile.

Development notes:

Right now, code is committed to github as it is committed to ss3. This
takes perhaps a few extra minutes to push, but it means that the two
sites are effectively synchronized. I don't plan to make more than 1-2
commits per day once I get started (and perhaps get lost). What isn't
being kept near real-time is the Metacello configuration. I plan to
update the version there when something meaningful changes, but likely
not for my temporarily broken forays. The bleedingEdge, for anyone
installing from ss3, is the package Math-All, which depends on
everything else. Loading packages one at a time is possible, but finicky
due to cross dependencies (esp. the double-dispatch between
DhbPolynomial or DhbVector and Complex/Quaternion). Test Cases assume
that everything is loaded.


Hopefully, the layout of the github repository should become more
stable. I'm experiencing some issues from time to time
     + sometimes Monticello doesn't show any packages in the filetree
repository.
     + classes and extensions end up in multiple package directories,
This is rather a large nuisance, since it makes the diffs look
unreasonably large, if for example DhbNumericalTests is included in two
places. This is especially common with extensions.
     + required packages totally not working in FileTree, due to a
`glitch` in creation of subdirectories, (Can't commit a package with
required packages to a filetree repository)
     + loading Packages with dependencies from filetree does not trigger
the load of the required packages, though they are present.
     + version information exists, but version history doesn't seem to
be visible in Monticello.

I understand Dale Henrichs has his own goals in building and sharing
FileTree/Smallsource. I will let him know what I'm seeing. It may be
outside his normal workflow and not important, or just not yet noticed
and easy to fix.


Dan Uber

> classes and extensions end up in multiple package directories
if i remember correctly monticello sees '-' as a word separator, hence
he finds math-dhb-numerical in math-dhb-numerical-tests. renaming the
last one to eg mat-dhb-numericalTests should probably solve that
problem.
werner

Werner,

that seems to be correct. I renamed Random-Tests and DHB-Numerical-Tests to lose the last hyphen, and the resulting package layout was more what I expected. This whole time I wondered why people hadn't been using a fully hyphenated or fully CamelCased naming system. Now I see the light!

Thanks for the helpful hint.

Dan Uber


On Tuesday, May 22, 2012 6:42:43 AM UTC-5, werner kassens wrote:

> classes and extensions end up in multiple package directories
if i remember correctly monticello sees '-' as a word separator, hence
he finds math-dhb-numerical in math-dhb-numerical-tests. renaming the
last one to eg mat-dhb-numericalTests should probably solve that
problem.
werner

On Mon, May 21, 2012 at 11:25 AM, Daniel Uber <[hidden email]> wrote:
We have already 200 tests, with one faling test, this is a good start ;-)
What tools do you use for test coverage ?

Thank you for the great work report. This is really interesting to follow.
Regards,
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/

On 05/22/2012 11:08 PM, Serge Stinckwich wrote:
> We have already 200 tests, with one faling test, this is a good start
> ;-) What tools do you use for test coverage ? Thank you for the great
> work report. This is really interesting to follow. Regards,
Serge,

Right now I'm just using TestRunner's coverage tool to ensure methods
are called, and some common sense about execution paths to make sure I'm
catching all the right branch conditions. I haven't been very good about
making tests with erroneous input to ensure errors are raised.
TestRunner has its quirks, especially on extensions, which appear to be
listed twice sometimes, so even if a test is written for them, the are
listed as not called (but are listed twice if they actually aren't called.)

I tried to load Hapa'o, but it seems like installing Moose is
non-trivial, and the moose image (one-click) is a little old. I was able
to load SciSmalltalk into the image after fiddling with the source a
bit, I think I had used some parenthesized booleans as arguments to
and:, where older versions of Boolean>>and: were more strict about
enforcing block only arguments. I think in this case, the analysis tool
used the existing (1.2-1.3 era) compiler and language environment very
deeply, so changes to BlockClosure recently are a huge headache to the
Moose tools. Loading Hapa'o into a newer image is buggy at best, and
sometimes unusable. It looked like a great tool, so I wanted to give it
a try.

For the ODE package, I'm trying in a few cases to write the tests first
the way I expect the objects to behave, and let the debugger prompt me
for the rest. It's an interesting experience.

Before I merge it in, I'd be happier to get a little more done today.
Before this evening (US Central, about 2100 UTC), I will definitely
merge it in and push to master, so you should be able to see it tomorrow
morning in Vietnam. It shouldn't break anything, so there's no harm in
including it. Partially I was more interested in seeing how the branch
mechanism works on git than on isolating the source. Also, I'm
completely undecided on the proper selector names for the methods, and
the entire class hierarchy is possibly going to change in the ODE package.

Dan Uber