[SciPy-user] OpenOpt svn broken on Windows

[Matthieu Brucher]

>> Algecan2 is supposed to have a clear interface, isn't it ? So you only
>> have one wrapper per major version. This is done in other packages as
>> well. And it is clearer that this is for algecan 2.x and not for
>> algecan 1.x.
>>
> I meant not 2.0.1 vs 2.0.3 but 2.x vs 3.x vs ... as well

algecan 3 will break your current model. I think that the fft wrappers
for scipy are also named fftw2 and fftw3, so why not using it as well
?

>> It wasn't the case some time ago. But you still can do what I mean.
>> I see that you can't register a new solver in OO on the fly and use
>> your wrappers. Why didn't you make __solverPaths__ directly a
>> dictionary that you populate then ? This way, you always have one
>> __solverPaths__ that is not different accross modules, as it could be
>> expected to be.
>>
> Because the solution you propose turn out to be a headache, especially
> for me - and that's the main reason why I have removed your dictionary
> __solverPaths__.
> Each time I created solvers like "ralgELS", "ralg2" etc (with some
> modifications to compare results with origin ralg) I have got a error
> during execution and have to go to runProbSolver.py file to fix the
> issue (as well as for connecting a new solver). Also, I was not fond of
> those dozens of additional lines of code in rPS.py

I didn't say that you shouldn't have done this, you obviously can, you
have done it and it works. What I'm saying is that there were several
purposes for this registry :
- not polluting sys.path
- allow a clean way of adding a solver

For the moment, I think you have two places where you can do the second part :
- ooMisc.py
- runProbSolver.py
Each time, it uses __solverPaths__. The funny thing is that
__solverPaths__ in ooMisc is in fact never used or modified. If it
were a dictionary, it would be of some use.
If you modify ooMic.__solverPaths__ after loading OO, you can't add a
new solver, as it equals None. And you cannot add it before, as you
have to load OO to get access to it. So I think it is
runProbSolver.__solverPaths__ that should be used, but then,
ooMic.__solverPaths__ really is just junk code that is of no use. Or
have I missed something ?

>> Of course ;) but you should try to reuse your code at the beginning as well ;)
>>
> I don't know what code do you mean here, I had already moved some code
> from ALGENCAN_oo.py to algencan_oo.py.

It is one of the basis of agile development. Never copy code. What is
cool with Python is that you can import the pieces you want. For
instance, you can factor these code lines in a new package that you
will import in each solver. This is especially important when you find
a bug in one wrapper and you forget to apply it in the second wrapper.
And it will work great with algecan3 if you can also reuse the same
parts, as you will have a much shorter file to modify (and thus less
headhache ;))

Also, only 1 version of algencan
> can be used with OO because both versions produce pywrapper.so file, and
> only 1 can be used from PYTHONPATH. Of course, I can create a workaround
> but I have lots of other things to do, especially to complite my GSoC
> assigned tasks.

I didn't know that there was only one filename. Is it something you
build or is it something algecan provides ?

Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher