Skip to content

Rgnome depends on obsolete components libglade/libxml (PR#8247)

6 messages · Hin-Tak Leung, Peter Dalgaard, Marc Schwartz (via MN) +1 more

Original
Hin-Tak Leung
# 
Full_Name: Hin-Tak Leung
Version: R 2.2.0
OS: x86 linux
Submission from: (NULL) (131.111.126.242)


Rgnome depends libglade 0.x and libxml 1.x .

They are no longer shipped with Redhat EL4.
(I know they are still in fedora core 4).

Just a wish-list.
Peter Dalgaard
# 
hin-tak.leung at cimr.cam.ac.uk writes:
But what is the wish? 

You mean get it upgraded to xml2 and glade2? Patches would likely be
accepted...
Hin-Tak Leung
#
Peter Dalgaard wrote:
:-). libglade went from 0.17 to 1.99 then 2.x, but the current Rgnome 
code depends on some of <0.17-specific stuff.

Already tried against libglade 2 - not trivial. It probably also 
requires changing to gtk2 also...

Just like to have it in the distant TODO list, and not forgotten...

Hin-Tak Leung
Marc Schwartz (via MN)
#
On Mon, 2005-10-24 at 17:14 +0100, Hin-Tak Leung wrote:
According to the R Admin manual (2.2.0) on page 34:

"This interface is experimental and incomplete. The console offers a
basic command line editing and history mechanism, along with tool and
button bars that give a point-and-click console to some R commands. Many
of the features of the console are currently stubs, and the console is
**no longer under development**: it has been kept available as an
example of adding a front-end to R."


This language (my emphasis added) would suggest that a TODO list does
not (or should not) exist...so Peter's suggestion would seem spot on.

HTH,

Marc Schwartz
Duncan Temple Lang
# 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


It is probably more sensible to rewrite this using the bindings
to Gtk+-2 and keep it purely in R so that we can more
readily customize the GUI.  There is a simple prototype in
the RGtk package and if anyone was interested, they can
do this with the soon to be released RGtk2 package.
Hin-Tak Leung wrote:
- --
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDXQ7w9p/Jzwa2QP4RAr7CAJsErP04DaUfdksk7TmzZIMBVqSNMgCeKh1b
QbwAU9AVolMTfd4nyK01zgo=
=qaNk
-----END PGP SIGNATURE-----
Hin-Tak Leung
#
Marc Schwartz (via MN) wrote:
<snipped>
<snipped>
Peter's suggestion is spot on ("patches would likely be accepted"), 
yours suggestion, on the other hand...

You do understand that, as an *example*, studying it and/or trying
to learn to modify it is useful for future R improvements in
similiar areas, and you have just managed to discourage a few 
individuals from studying a complete if out-dated example.
(yes, I have spent a few hours modifying the code for glade2).

A TODO list doesn't mean that it has to be done by the R foundation
- if you can identify small bug do-able areas that needs improvement,
some individual might come along just for the fun/fame, and in the
end, the R foundation gains an outsider who is knowledgeable about
embedding R. e.g. some college professor might assign that as a
final year computer programming project, or some student might pick
it as one. Is it such a bad thing to have a list of "inadequacies
but nowhere important enough to get fixed any time soon" issues?

The possible gain - somebody decides to take it up, and move forward,
and in so doing, learns some R internals - is it such a bad thing?

Hin-Tak Leung