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:
[cid:00A6E7F9-CCB8-4C2A-9E6E-55469924C65C@oist.jp]
(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 MZmineRModule,
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
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
