[rkward-devel] KDE 4 status update

Prasenjit Kapat kapatp at gmail.com
Mon Oct 29 17:49:17 UTC 2007


Hi,

On 10/28/07, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> Hi,
>
> On Sunday 28 October 2007, Prasenjit Kapat wrote:
> > I am not sure if you got to this issue, neither the File browser nor
> > the workspace browser opens up properly the first time... I have to
> > drag it out. Need debug/valgrind  info?
>
> no, I didn't get to this issue, yet. It's not so much related to file browser
> or workspace browser, but (technically) a window management issue. I have a
> good idea what's causing this, so no debug info needed. Will take care of
> this sooner or later.

Not, a problem. BTW, feel free to modify or reposition by comments in
TODO_KDE4 to wherever you feel suitable. I am note sure, if I have put
them in the correct categories/classes.

>
> > I had a crazy idea here.. Is it possible to access a variable (as
> > read-only) when it is part of a running code? (smell debugger?)
>
> This is not easy to do. The problem is that R itself is not designed to allow
> multiple concurrent threads, and hence only one command can run at a time.
> Therefore we can't really do anything while a command is running.
>
> Now R has some facilities for debugging (see ?debug, ?browser). These
work by

Thanks, they look interesting... There is also a ?debugger, I did not
quite  understand the man page :(

> GUI), and the R devels are highly conservative about changes in the core R
> code. All in all, therefore, it's a considerable effort, and will not work in
> the near term.

Yes, I bet it is a difficult task....

> > In this regard, a non KDE4 issue:
> > I was trying the following code: i=1; while (i>0) {}
> > If it executed by-passing the console and I try print(i) in the
> > console, then the R engine / threading system somehow stops, doesn't
> > freeze, doesn't crash! If I try to cancel through the "Pending jobs"
> > window, some "sync" situation arises. The same can be achieved when
> > the code is executed through the console and I use the workspace
> > browser to "View" i.
>
> Not sure what you mean by non KDE4 issue?

Well, I thought it is not a KDE4 porting issue, rather a general
issue, as you have rightly mentioned.

> In the KDE3 version of rkward, the
> command sometimes gets shown at a wrong place in the Pending Jobs window, but
> can be cancelled alright. In the KDE4 version, the command showed up
> correctly in the Pending Jobs window, but most of the time it was not
> actually possible to cancel it (I think I've fixed this, now).

The "Pending Jobs" window looks like this:
- Command Stack
   |-- i=1; while (i>0) {}                     Running      U
   |-- print(i)                                                           U

At this point if I Cancel the "i=1;..." line then both commands get
cancelled and R engine is idle again, But if I cancel the second
command, "print(i)" then though both the cmds seem to be cancelled,
the R engine is still busy...

Is it possible to make the RConsole window inactive when there is a
cmd running. Inactive from the point of view of taking (input) further
characters at the cmd line, but still should be able to browse,
select, copy etc... Anyway, this is a low-priority feature/bug, you
might not want to concentrate on this ATM.

>
> Of course the larger issue is how to deal with interrupting locked-up commands
> that were not entered in the R console. The problem is that the "Pending
> Jobs" window is not easily discoverable, but it's the only way to cancel
> those commands, ATM. One idea was to detect commands that run longer than a
> configurable threshold (say 30 seconds by default), and then ask whether
> those should be stopped. I guess we'll need something like this, sooner or
> later.

I am not quite sure of this. I myself write codes that run more than
10 mins quite often. But then, the threshold can be configurable. We
will have to think over it a bit - if a user says "NO" (i.e. do not
stop), then will he be asked again after every k secs the same
question? Or should the question be just one time, for every command
that runs beyond the threshhold of k secs?

Regards
PK




More information about the Rkward-devel mailing list