[MOBY-l] Trouble-ticketing for MOBY; unwanted side effect ofMOBY::Client::Service->execute

[mark wilkinson]

Hi Frank,

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...

Cheers!

M

-----Original Message-----
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
 MOBY::Client::Service->execute

Hi,
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.

Thanks,

-Frank


PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555       Fax: 
617-432-3557       http://llama.med.harvard.edu/~fgibbons 

_______________________________________________
moby-l mailing list
moby-l at biomoby.org
http://biomoby.org/mailman/listinfo/moby-l

--
Mark Wilkinson
...on the road!