~l3on/ubuntu/precise/rkward/rebuild1

/** cancelling the command that is (or seems to be) currently running is tricky: In order to do so, we need to signal an interrupt to the RThread. We need this pointer to find out, when the command has actually been interrupted, and we can resume processing. */

100

/** canceling the command that is (or seems to be) currently running is tricky: In order to do so, we need to signal an interrupt to the RThread. We need this pointer to find out, when the command has actually been interrupted, and we can resume processing. */

101

RCommand *running_command_canceled;

102

100

103

/** See \ref RThread::doSubstack (). Does the actual job. */

102

105

// void processRGetValueRequest (RGetValueRequest);

103

106

/** See \ref RThread::doStandardCallback (). Does the actual job. */

104

107

void processRCallbackRequest (RCallbackArgs *args);

105

friend class RKwardApp;

108

friend class RKWardMainWindow;

106

109

friend class RCommand;

107

/** pointer to the RKwatch. TODO: (re-)move this pointer */

108

RKwatch *watch;

109

110

/** Used (once!) to start the RThread. Need to make this separate to avoid race conditions */

110

111

void startThread ();

111

112

protected:

137

138

\endcode

138

139

140

You will note, that actually there are two RInterface::issueCommand functions, this one is obviously the one taking a QString and several further

140

parameters as argument. It is actually quite similar to the other RInterface::issueCommand function which takes an RCommand as a paramter. This convenience class basically just creates an RCommand with the same parameters as the constructor of RCommand (RCommand::RCommand), and then submits this RCommand. We'll discuss what an RCommand really is further down below. For now a good enough explanations is, that it's simply a container for a command.

141

parameters as argument. It is actually quite similar to the other RInterface::issueCommand function which takes an RCommand as a parameter. This convenience class basically just creates an RCommand with the same parameters as the constructor of RCommand (RCommand::RCommand), and then submits this RCommand. We'll discuss what an RCommand really is further down below. For now a good enough explanations is, that it's simply a container for a command.

141

142

143

The first parameter here is fairly obvious, the command-string the R backend should evaluate.

143

144

147

148

149

\section UsingTheInterfaceToRHandlingReturns A slightly more realistic example: Handling the result of an RCommand

149

150

Most of the time you don't just want to run a command, but you also want to know the result. Now, this is a tad bit more difficult than one might expect at first glance. The reason for this is that the R backend runs in a separate thread. Hence, whenever you submit a command, it generally does not get executed right away - or at least you just don't know, when exactly it gets executed, and when the result is available. This is neccessary, so (expensive) commands running in the backend do not block operations in the GUI/frontend.

151

Most of the time you don't just want to run a command, but you also want to know the result. Now, this is a tad bit more difficult than one might expect at first glance. The reason for this is that the R backend runs in a separate thread. Hence, whenever you submit a command, it generally does not get executed right away - or at least you just don't know, when exactly it gets executed, and when the result is available. This is necessary, so (expensive) commands running in the backend do not block operations in the GUI/frontend.

151

152

153

Ok, so how do you get informed, when your command was completed? Using RCommandReceiver. What you will want to do is inherit the class you

153

154

want to handle the results of RCommands from RCommandReceiver. When finished, the RCommand will be submitted to the (pure virtual) RCommandReceiver::rCommandDone function, which of course you'll have to implement in a meaningful way in your derived class.

332

333

This one tells the backend, that the command does not really need to be executed, and does not contain anything. You'll rarely need this flag, but sometimes it is useful to submit an empty command simply to find out when it is finished.

333

334

335

- RCommand::DirectToOutput

335

This is typically used in plugins: When you specify this modifier, the plain text result of this command (i.e. whatever R prints out when evaluating the command) will be added to the HTML output file. Remember to call RKwardApp::newOutput in order to refresh the output-window once the command has finished.

336

This is typically used in plugins: When you specify this modifier, the plain text result of this command (i.e. whatever R prints out when evaluating the command) will be added to the HTML output file. Remember to call RKWardMainWindow::newOutput in order to refresh the output-window once the command has finished.

336

337

338

- RCommand::GetIntVector, RCommand::GetStringVector, RCommand::GetRealVector

338

339

These are special modifiers helpful when transferring data from R to RKWard (used primarily in the editor classes and in conjunction with RCommand::Sync): They tell the backend to try to fetch the result as an array of int, char*, or double, respectively. For instance, if you know object "myobject" is an integer vector, you may get the data using

Older »