[Rd] weird bug with parallel, RSQlite and tcltk

Gabor Grothendieck ggrothendieck at gmail.com
Thu Jan 3 14:36:44 CET 2013

On Thu, Jan 3, 2013 at 7:45 AM, peter dalgaard <pdalgd at gmail.com> wrote:
> On Jan 3, 2013, at 12:20 , Gabor Grothendieck wrote:
>> On Thu, Jan 3, 2013 at 5:59 AM, peter dalgaard <pdalgd at gmail.com> wrote:
>>> On Jan 3, 2013, at 10:32 , Karl Forner wrote:
>>>> Hello,
>>>> The point is that I do not use tcltk, it gets loaded probably as a
>>>> dependency of a dependency of a package.
>>>> When I unload it all work perfectly fine. I just found it because one
>>>> of my computer did not have tk8.5 installed, and did not exhibit the
>>>> mentioned bug. So I really think something should be done about this.
>>>> Maybe the "gui loop" should not be run a the the loading of the tcltk
>>>> package, but
>>>> at the first function ran, or something like this.
>>> Doesn't sound doable. It would be tricky to do and wouldn't help in the cases where people actually want to use the GUI - plus, it would leave a time bomb if you directly or indirectly fire up a Tk window (say, the CRAN menu from install.packages()).
>> Would it be possible to separate the tk and tcl portions of tcltk into
>> two packages so that the tcltk package would be dependent on a new tcl
>> package ?  From the viewpoint of a user of tcltk there would be no
>> change but it would allow packages that only use tcl to declare a
>> dependency only on that.
> Not sure that actually solves much. We do this already if the DISPLAY is unset for X11, so the logic should not be too hard to extend, but the event loop belongs to Tcl, Tk events are just a special type of events.

OK. I had assumed the event loop was to process the GUI events only
and therefore would be in tk.

Another possibility might be just to have a standard option that users
or other packages could set to indicate that they don't have or don't
want to use tcltk so packages that do use tcltk could examine that
option and act accordingly (e.g. use alternate code or issue a
meaningful error).  I already use options(gsubfn.engine = "R") for
that purpose but that only works for my packages and if something were
standardized in tcltk then it could be more broadly applicable and
more visible.  As far as tcltk this is basically just a matter of
documentation to set the standard but for the parallel package, say,
the option could be automatically set in the workers.

Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

More information about the R-devel mailing list