General development notes (was: [Saga-devel] saga SVN commit 3373: /trunk/adaptors/aws/aws_job/)

['Andre Merzky']

Hartmut, 

Quoting [Hartmut Kaiser] (Jan 24 2009):
> 
> Andre,
> 
> > User: amerzky
> > Date: 2009/01/24 09:05 AM
> > 
> > Modified:
> >  /trunk/adaptors/aws/aws_job/
> >   aws_job_service.cpp, aws_job_service.hpp
> > 
> > Log:
> >  Not to self: do not use boost::process on unix!
> >  It is broken!  I should have remembered why I reimplemented the
> >  local job adaptor in the first place....
> >  Anyway, we use the local job adaptor now, and voila, it works
> >  :-)
> 
> What's broken?


It is still about the code example I sent you earlier - I
spent almost a day trying to understand what boost::process
is reporting as exit code - it is wrong, and is probably
caused by the same waitpid mess I tried to fix a year ago in
the local adaptor.

> Wouldn't it be better to _fix_ things rather than even to
> consider _rewriting_ them?

I know you don't want to hear it, but I CAN'T FIX
BOOST::PROCESS.  I am not good enough.  It would eat weeks
of my time, would probably not be portable (and thus
rejected by the boost people), and would likely be broken in
some other way.  It is too complex for me. 

So, I write short examples deonstrating the problem, like
the one I mailed you about in
examples/misc/boost_process.cpp, so that other people can
try to fix it.  If not - well, thats life.  Don't know whom
else to report to - the last time the original author wrote
anything about boost::process was in 2006...


> And please don't tell me again you're not able to debug Boost.Process. This
> might have been true as long as you were working on Linux. But now, on the
> Mac, you have XCode which has a decent debugger integration (ok, it's just
> gdb, but it's working quite well).
> 
> Rewriting usually just adds to the mess, by introducing new bugs, a
> maintenance headache, code bloat, etc. 
> Nothing good to say about rewrites, as long as those don't fully _replace_
> the existing code base, increasing the _full_ feature set of the old
> implementation (functionality, portability, maintainability, you name it).

And I did not rewrite code, but simply reused what we had,
in the local adaptor.  I am not even duplicating code, but
just calling the fork-js.  Works.

Andre.


> OTOH, the more code you rewrite, the less code responsibility is left for
> me, so I should be happy... :-/
> 
> And a last note: Boost.Process works well for Joao in his Condor adaptor. Go
> figure.

Works in many cases for me, in simple cases.  But fails in
others.  See other mail, and example.


> Please don't get me wrong. I understand you have deadlines. Usually
> deadlines result in times of quick and dirty hacks, which is fine. What we
> should avoid, though, is to leave those quick hacks in place forever.
> Unfortunately the experience shows those quick hacks either have been fixed
> my me or they are still there. But I'm not willing to clean up other
> people's mess anymore, I have had my share of this, no thanks.

Well, no need to clean up - I did not touch boost process
:-P  In fact, I did not touch much, just cleaned up my code
at the end.  It simply took me a coupld of days trying to
_use_ and _understand_ boost::process.  I won't touch it
again anytime soon, sorry...


> Regards Hartmut


-- 
Nothing is ever easy.