-
Notifications
You must be signed in to change notification settings - Fork 1
/
TODO.txt
82 lines (47 loc) · 5 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
----------------------------
TODO for version 0.5.xx
* drag-and-drop files from the Finder
* copy contents from the tables in the GUI
* allow to remove xgrid jobs
* Add an icon for "Retrieving" status for the jobs
* Add a "clean" button for metajob: remove all memory of previous submissions, same for individual commands in the "Info" panel
* add shouldLimitPendingJobs in GEZMetaJob, so that one can keep submitting jobs until all commands are submitted, and quit the client
* Poll on a regular basis to check GEZJob in a GEZMetaJob, in the rare cases where we don't get notified of Finished/Invalid jobs
----------------------------
OTHER BUGS/FEATURES
* apparently bug with the -dirs and -files argument:
* see the autodock project with the 'ligands' folder from Rob, metajob3, 2007-06-26
* -dirs with nested folders
* 2 files in the same nested folder, e.g. 'ligands/01/01.-EGFR1xx.dlg' and 'ligands/01/01.pdbqt
* file 1 is referenced in the argument list
* file 2 is referenced using the '-dirs' flag
* file1 and file2 end up in a different folder on the agent: file1 in the root, file2 in a subdir
* they should be in the same place: root working dir
* have a 'default' metaJob, editable when no MetaJob is displayed. To do it, I could have the default metaJob in the store, and subclass NSArrayController and add one of NSPlaceholder methods. Well, I tried, it is not that easy... I may have to go to the user defaults. OK --> create a dictionary in the user defaults. If it does not exist, do not use it (!). A selected job can be used to 'Set Default Settings' in the menu or with a button
* when creating a new meta job, could check that it does not use an output folder shared with another metajob. In fact, it could work fine (if the same thread).
* clicking "Load Demo" deletes all the stuff that another job is potentially using
* run the job submission and retrieval in a different thread if too much spinning wheel...
----------------------------
BUG 2007-10-25
When I say I cancel the job I mean I use the "-" button at the top of the Metajobs window.
When I kill the process, I kill the commands submitted to the grid. For example if I submit a job containing a "find | grep" command I have to kill the "find" command manually, if I don't do it GridStuffer will crash every time I try to open it.
I don't have any crash logs, there are no GridStuffer.crash. I don't know why, I haven't erase any.
Most of the time when I used 0.4.5 it worked ok. These problems show up if I start canceling unfinished jobs.
luis
On Oct 23, 2007, at 4:46 PM, Charles Parnot wrote:
Thanks very much for the feedback, and I am glad that GridStuffer can help you in your job. And I hope it can continue to do so after I fix it!!
I have a quick question about the description of the bug you make: when you said "kill the process", are you talking about GridStuffer? When you say "GridStuffer will keep crashing", do you in fact mean GridStuffer is locked up? It just seems the 2 actions are contradictorfy: you would not have to kill GridStuffer if it crashed, so I am not sure I understood fully the description.
In addition, when you say "cancel a job", you mean cancel an Xgrid job (e.g. from Xgrid Admin), or you mean cancel a GridStuffer metajob?
Finally, if you have time, I would be interested in the crash logs (in /Library/Logs/CrashReporter/GridStuffer.crash) so I can maybe get a sense of where things went wrong.
I did fix some memory/CoreData leaks in 0.4.5, but it might have revealed some other underlying bugs. The only recommandation I would make with using 0.4.4 is to delete the GridStuffer database once in a while (the xml file in /Library/Application Support/GridStuffer/GridEZ), e.g. when you are done with a metajob, because this file will grow bigger and bigger and it will eventually slow down GridStuffer (of course, once a metajob is finished, all your results are safe in the output folder that you set for the metajob; the xml file only keeps track of the progress and settings for the metajob). With Leopard, Apple improved CoreData efficiency, and I found that some of these issues might be exposed even more. I have a pretty good idea of what they are, and they mostly stem from initial misconceptions I had about CoreData, but your feedback could really help too. So I hope I can fix it and release 0.4.6 eventually...
best regards,
charles
On Oct 23, 2007, at 11:55 AM, Luis M Martinez wrote:
Hi, I have been using your GridStuffer for a research project in computer forensics. This tool has help me a lot simplifying the submission and retrieving of jobs. I just wanted to let you know I have been experiencing problems with version 0.4.5. Sometimes if I cancel a job while processing the job keeps running in memory, GridStuffer will keep crashing until I kill the process stuck in memory manually. I went back to version 0.4.4 and I haven't experienced the problem with this version.
Thanks.
--
Xgrid-at-Stanford
Help science move fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford
Charles Parnot
charles.parnot@gmail.com