Hi everyone,
A few (minor?) remarks about Tomas suggestions:
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 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?
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?
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).
[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
?
Just asking this because keeping JRI, in an early implementation, forces
us to keep, AFAIK, all R related environment variables in the startup
script...
Well, thanks for reading that far too long piece of text.
Regards
Gauthier
On 12/09/2014 05:53 AM, Tomas Pluskal wrote:
Hi Gauthier,
I briefly tested your new release and it works fine for me, without
any effort spent on configuration.
I think now would be a good time to replace the JRI interface with
RServe in the trunk.
My suggestion would be to create a new module (implementing
MZmineModule) that would provide the R-related services to other modules.
This module can also start RServe during MZmine startup.
The R_HOME settings could be moved to the mzmine Preferences dialog
(instead of the startMZmine script), with auto-detection by default.
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.
Please update your sources before committing any changes to the trunk,
as there has been lots of changes lately.
Cheers,
Tomas
PS: I have not had the time to really test Renjin, but I think you are
right that having the full power of R is an advantage for future
development, so RServe might be better option in that sense
On Dec 9, 2014, at 11:53, Gauthier Boaglio <gauthier.boag...@gmail.com
<mailto:gauthier.boag...@gmail.com>> wrote:
Hi all,
As promised, I released a first quite advanced (burn proof enough, just
hopping for now) for an 'Rserve wrapper'. Keeping it handy and with good
performances under Windows gave me quite a hard time, but I hope this
first attempt is a minimum satisfying. You'll tell me...
Rserve impl. change log:
-----------------------
[Still limited to the 'BaselineCorrectionModule' area - Backward
compatibility with 'JRI' preserved]
* 'R_HOME' detection: If not found automatically, R_HOME must be set
(from startMZmine script).
* Dedicated exception handling (R, Rserve or required package not
found, mostly via the 'RSessionWrapperException').
* Fixed some windows specifics (multi-instance open(), close(),
cancel(), bruteCancel()...).
* Cleaned console logging and GUI errors feedback.
* Cleanup everything related to 'Rserve' on MZmine exit.
* Cleaned up source code and comments.
* Removed completely RCaller stuffs.
* Still can choose preferred R engine among JRIengine and Rserve.
Release download location:
-------------------------
https://sourceforge.net/p/mzmine/code/HEAD/tree/branches/gboaglio-experimental/target/MZmine-2.11-EEE-release-20141209.zip
Thanks by advance for your feedback.
Cheers
Gauthier
--
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
