Path fixes

[Torsten Anders]

Dear all,

> However, I'd like you to hold off on these until I can review.

No problem, I really appreciate it.

>  Also, I don't know if it's practical, but these are not small 
> changes, and it is easier to
> review small, well documented changes. The ideal way to do this is by 
> using a
> branch where each commit makes a small well-documented change.  I 
> realize svn is
> not well suited to small short-lived branches, which is why ideally 
> I'd really
> prefer to use bzr (at least for this purpose).  Of course, I am not 
> asking you
> to redo these proposed changes just to suit my preferences, but it 
> might be nice
> to consider my suggestion in the future.
>
> Still, if you could also provide the documentation that might go in 
> the future
> commit message, that would be helpful ;-)

Sorry for not following any standard procedure, I didn't know how this 
is usually expected to happen.     I am not at all experienced in this 
kind of thing, so please bear with me. Do you suggest I do a svn branch 
the next time? How did this happen before?

The little temporary package provided (Path.tgz) was intended to serve 
as a simple branch. Of course, there is no edit history. Nevertheless, 
I added some temporary explanation for the most  important changes.

I would certainly have preferred small changes only. I suggest you 
first run the test cases I provided with the original Path definition 
to get an idea why I had to change so much ;-) I wonder whether anybody 
tried, e.g., basename or dirname before, and I got lots of error 
messages when I used MacOS.

I also added some documentation remarks in the code which will in the 
end be added to the Path documentation *.sgml files (and then removed 
in the code). For example, there are several lines like

% [add to documentation] here goes my additional explanation

I thought it is more practical to have that in the code directly before 
things get accepted.

> Sure, and it is very important that when you fix bugs or change 
> behaviour you add test cases.  See mozart/share/test/.

I added tests in Path.tgz. These have to be run and interpreted 
manually however (currently at least). What is the standard format for 
Mozart test cases? Is there perhaps some documentation about that.


> ideally, someone should contribute a unit testing framework that we 
> could reuse :-) ahem...

Juergen Stueber actually did that for Mozart in 2004. I think he 
announced that on the mailing list. I still have his sources on my 
machine. It may not be fit for every purpose, but it would be a start..

Thank you very much!

Best,
Torsten

PS: I am currently not subscribed on the hackers mailing list and hope 
this gets through anyway..

--
Torsten Anders
Sonic Arts Research Centre • Queen's University Belfast
Frankstr. 49 • D-50996 Köln
Tel: +49-221-3980750
http://strasheela.sourceforge.net
http://www.torsten-anders.de