[MOBY-l] Trouble-ticketing for MOBY; unwanted side effect ofMOBY::Client::Service->execute
markw at illuminae.com
Thu Aug 11 12:37:03 EDT 2005
Two quick responses (I'm on the blackberry and it isn't very efficient :-) )
1). The execute method will shortly be significantly changed in light of the upcoming API changes (esp. Insistence on named parameters allows me to use a more sensible "hash" structure in place of the list structure). I don't know if it is worth spending time fixing it.
2). I didn't realize that my code modified the input list. You're right, this is bad. I could post a fix for the such that the input listref is cloned to avoid this (if that is the root of the problem), or you are of course always welcome to fix it yourself and commit.
3). We do have a ticketing system, but nobody ever uses it :-). Click the "bugs" link on the left side of the homepage... I haven't tested it for a while, but it worked last time I tried...
From: Frank Gibbons <fgibbons at hms.harvard.edu>
Date: Wed, 10 Aug 2005 11:37:14
To:moby-l at biomoby.org
Subject: [MOBY-l] Trouble-ticketing for MOBY; unwanted side effect of
Two related items:
I think MOBY::Client::Service->execute has an unwanted side-effect in that
the XMLinputlist argument appears to be modified upon returning from this
function. The code does some editing on it. I don't think that would have
been a problem had XMLinputlist been passed in as a scalar, but it's passed
as an ARRAY ref, and so modifications to it are propagated back to the
calling code. This is a problem if, like me, you want to iterate over
services calling each one with the same XMLinputlist. (At least, I think
that's what's happening - correct me.)
How do we fix something like this? Are there regression tests to make sure
nothing gets broken when this issue is tackled? Who fixes it? (I'll
volunteer) The issue of how to fix this raises the other item: while MOBY
is under CVS control, there's no ticketing system (that I'm aware of). As a
long-time lurker on this list, I know that most issues just get posted to
the list, and then fixed. I think there are a lot advantages to having a
centralized, non-email-based record of what needs to be fixed in the
future, but also of what was fixed in the past. I'm wondering partly why
MOBY isn't on SourceForge (which has a ticketing system for bugs and
feature requests, so that potential users can not only see what issues have
been fixed, but also what features are likely to appear in the future) - if
this has been discussed in the past and resolved, I'd appreciate a pointer.
PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555 Fax:
moby-l mailing list
moby-l at biomoby.org
...on the road!
More information about the moby-l