Hi Tomas,Yep, I'll do that as soon as I can. But I have to warn you that there is a good probability that I cannot do this before a week or two. The reason for that being that, in France / CNRS, when you reach 3 years under contract, no matter how skilled you are, you get kicked off. Sure it sucks, but as a result, I might have other priorities (things to have finished with my colleagues before getting unemployed), by the end of this month. So I'll try to do my best, but there is a good chance that I cannot proceed with trunk before the 21th.
Cheers Gauthier On 12/11/2014 03:27 AM, Tomas Pluskal wrote:
Hi Gauthier, Let's move it to the trunk :) TomasOn Dec 11, 2014, at 0:02, Gauthier Boaglio <gauthier.boag...@gmail.com <mailto:gauthier.boag...@gmail.com>> wrote:Hi Tomas,That's fine for me, and you're right about simplicity. Moreover, the current wrapper is already working that way, meaning no additional work (for that part) ;)Note: I made some fixes related to the issue you submitted earlier. https://sourceforge.net/p/mzmine/code/HEAD/tree/branches/gboaglio-experimental/target/MZmine-2.11-EEE-release-20141210.zip Cheers Gauthier On 12/10/2014 02:18 PM, Tomas Pluskal wrote:Hi Gauthier,I would prefer to keep things simple and always instantiate Rserve when the task is started. I understand that will cause some delay, but honestly I think the delay of a few seconds does not matter so much. The task processing itself probably takes much longer time, so the initial delay will not make much difference.Cheers, TomasOn Wed, Dec 10, 2014 at 8:04 PM, Gauthier Boaglio <gauthier.boag...@gmail.com <mailto:gauthier.boag...@gmail.com>> wrote:Hi Tomas, Thanks for the feedback. The screen below, I think, results from attempting to kill a WAITING task. In windows case, the instance is net yet started (contrarily to its RSessionWrapper related object) when canceling, so killing it won't work (we even don't have its PID yet). Presumably easy to fix. One last thing I was wondering about: Have you noticed a 'too long' starting lag, while running many task at once under Windows? If this is the case, don't you think, one could - in Windows case only - warmup a certain amount of asleep instances that could be reused (never closed again) when R requests are thrown? That would speed up significantly processing the request. The drawback would be having N Rserve instances/processes (even if they are sleeping) remaining open all along the life time of the MZmine instance itself. So the question is: Is this acceptable to have those (lets say nbCores or nbCores/2) child processes alive on the machine, all along? Or shall we preferably deal with the possibly 'quite long' instantiation time, each time we ask for a new R depending Task (since the current implementation closes the Rserve instance related to a given Task, once the Task is done)? Implementation would become: * One 'RSessionWrapper' object per task, and dying with the Task. * Several (pooling system) 'Rsession' objects / Rserve asleep process - from 'Rsession' library, kept alive and registered for later call (that is: re-linkable with a new 'RSessionWrapper'). Note: Personally, I'm not a big fan of spawning many system processes that way (threads are OK, but processes...), but may be this is a common acceptable practice (I don't know much about that). Hope I made myself clear enough. Thanks for your lights and advices. Cheers Gauthier On 12/10/2014 02:40 AM, Tomas Pluskal wrote:Hi Gauthier,First, I'd like to have feedback about the behavior of this new Rserve wrapper under Windows, since it is the part that bugged me mostly. As mentioned in a previous message, on this system, forking processes is not a native behavior, so 'emulating' such a feature under Windows is a bit tricky, and, as a consequence, throwing a task requiring Rserve (AKA Rserve) in combo (so several tasks, on several files) needs some sort of synchronization and can be slow and (may be) not so thread safe (normally I made it safe, but still need more feedback, just to make sure). Same thing when canceling several tasks at once. So thanks very much for testing it (the baseline module actually), having the above in mind.I noticed some error messages when canceling tasks: <Mail Attachment.png> (note it says pid '-1', and also Failed loading package 'ptw', although this package is installed and working fine.I agree providing the R services to other modules via a specialized module is the right way to do. I would suggest, even more, to create an MZmine*R*Module, the modules requiring the R services would inherit from. This way would provide an easy way to distinguish those modules among the others (which would certainly ease the development at some point). What do you think about this approach?Sure, why not.Testing 'R_HOME' detection at startup is good idea too. I would suggest, in case MZmine couldn't find R_HOME right away by itself, to make it open the preference window on the fly and ask the user to give a correct setting for it, or preferably, may be, warn him that R_HOME ain't OK and give him a chance to fix it (YES/NO warning dialog which would open the preferences setup dialog if YES was pressed). Would you be fine with the latter approach?That is fine, but this dialog should be shown only when the user attempts to run a method that requires R (not at MZmine startup).As said in the very beginning of this text, Windows does not really start Rserve just once and then fork the main instance when an R request has to be evaluated. It starts a new fresh Rserve (master instance) every time (well, once per Task, actually). That is to say, starting Rserve at MZmine startup/warmup is the elegant and efficient way of doing under *nix, but it will slow down the whole application startup, especially under Windows. Does it sounds acceptable to you? (I don't have a predefined personal opinion about that particular point. But this can be a drawback for those who do not have a war machine as a computer).OK then, it is not necessary to start Rserve on MZmine startup, we can start it separately for each task.[Tomas]: I am not sure about my understanding of your latest suggestion: "Eventually, we can change the existing modules that use R to take advantage of this new module, and finally we can remove the JRI interface". Did you mean to do things step by step like: 1/ implement the said new module and startup checking 2/ make the targeted modules use it (keeping JRI as a fallback feature) 3/ later remove JRI Or, did you mean: 1/ implement the said new module and startup checking 2/ make the targeted modules use it and remove JRI in the meantime ?I meant the second option. I would like to have only one R backend in MZmine. Cheers, Tomas =============================================== Tomas Pluskal G0 Cell Unit, Okinawa Institute of Science and Technology Graduate University 1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan WWW: https://groups.oist.jp/g0 TEL: +81-98-966-8684 <tel:%2B81-98-966-8684> Fax: +81-98-966-2890 <tel:%2B81-98-966-2890> ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Mzmine-devel mailing list Mzmine-devel@lists.sourceforge.net <mailto:Mzmine-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/mzmine-devel-- Gauthier BOAGLIOCEFE - UMR 5175 1919 route de Mende F-34293 Montpellier cedex 5 Tel:+33/0 4 67 61 32 15 <tel:%2B33%2F0%204%2067%2061%2032%2015> Fax:+33/0 4 67 61 33 36 <tel:%2B33%2F0%204%2067%2061%2033%2036> email:gauthier.boag...@cefe.cnrs.fr <mailto:gauthier.boag...@cefe.cnrs.fr> www:http://www.cefe.cnrs.fr/en/evolutionary-ecology-and-epidemiology/gauthier-boaglio http://www.evolepid.org/people.php?name=boaglio ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Mzmine-devel mailing list Mzmine-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mzmine-devel-- Gauthier BOAGLIO CEFE - UMR 5175 1919 route de Mende F-34293 Montpellier cedex 5 Tel: +33/0 4 67 61 32 15 Fax: +33/0 4 67 61 33 36 email:gauthier.boag...@cefe.cnrs.fr www:http://www.cefe.cnrs.fr/en/evolutionary-ecology-and-epidemiology/gauthier-boaglio http://www.evolepid.org/people.php?name=boaglio ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________ Mzmine-devel mailing list Mzmine-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mzmine-devel=============================================== Tomas PluskalG0 Cell Unit, Okinawa Institute of Science and Technology Graduate University1919-1 Tancha, Onna-son, Okinawa 904-0495, Japan WWW: https://groups.oist.jp/g0 TEL: +81-98-966-8684 Fax: +81-98-966-2890 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Mzmine-devel mailing list Mzmine-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mzmine-devel
-- Gauthier BOAGLIO CEFE - UMR 5175 1919 route de Mende F-34293 Montpellier cedex 5 Tel: +33/0 4 67 61 32 15 Fax: +33/0 4 67 61 33 36 email: gauthier.boag...@cefe.cnrs.fr www: http://www.cefe.cnrs.fr/en/evolutionary-ecology-and-epidemiology/gauthier-boaglio http://www.evolepid.org/people.php?name=boaglio
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________ Mzmine-devel mailing list Mzmine-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mzmine-devel
