[Rd] R_MakeExternalPtr

[TB]

Hi,

I'm using R_MakeExternalPtr() to store handles to (COM) objects in a SEXP.

The code basically is

sexp = R_MakeExternalPtr(handle,R_NilValue,R_NilValue);
R_RegisterCFinalizerEx(...);

After creating the sexp, LENGTH(sexp) returns some quite large integer
value. It seems like an "unitialized" value.

Can I safely assume, that an SEXP of type EXTPTRSXP can only contain a
single pointer value and never represent a vector (an array) of pointers? Or
should I maybe explicitly add something like

SETLENGTH(sexp,1);

Best wishes from sunny Austria,

Thomas Baier

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_MakeExternalPtr

[Prof Brian Ripley]

This is one of those undocumented things (AFAIK): LENGTH applies only to
'vectors'.  So don't use t and definitely don't set it for others.  The 
macro expands to

#define LENGTH(x)   (((VECSEXP) (x))->vecsxp.length)

What is a vector here?  Something which gets actually allocated by 
allocVector() AFAICS, that is an atomic or generic vector or an 
expression.  OTOH, an EXTPTRSXP is stored in a cons cell.

There is also a function length(), which is safer.

On Mon, 24 Oct 2005, TB wrote:

> Hi,
>
> I'm using R_MakeExternalPtr() to store handles to (COM) objects in a SEXP.
>
> The code basically is
>
>   sexp = R_MakeExternalPtr(handle,R_NilValue,R_NilValue);
>   R_RegisterCFinalizerEx(...);
>
> After creating the sexp, LENGTH(sexp) returns some quite large integer
> value. It seems like an "unitialized" value.
>
> Can I safely assume, that an SEXP of type EXTPTRSXP can only contain a
> single pointer value

It stores a pointer plus other things including a tag.

> and never represent a vector (an array) of pointers? Or
> should I maybe explicitly add something like
>
>   SETLENGTH(sexp,1);
>
> Best wishes from sunny Austria,
>
> Thomas Baier
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_MakeExternalPtr

[TB]

Brian,

Prof Brian Ripley  wrote:
> This is one of those undocumented things (AFAIK): LENGTH applies only
> to 'vectors'.  So don't use t and definitely don't set it for others.
> The macro expands to
> 
> #define LENGTH(x)   (((VECSEXP) (x))->vecsxp.length)
> 
> What is a vector here?  Something which gets actually allocated by
> allocVector() AFAICS, that is an atomic or generic vector or an
> expression.  OTOH, an EXTPTRSXP is stored in a cons cell.
> 
> There is also a function length(), which is safer.

Thanks for your message. Things are much clearer now to me.

Can I safely assume that INTSXP, REALSXP, LGLSXP, STRSXP, CPLXSXP and VECSXP
are
vectors (while EXTPTRSXP is not).

Thomas

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_MakeExternalPtr

[Prof Brian Ripley]

On Mon, 24 Oct 2005, TB wrote:

> Brian,
>
> Prof Brian Ripley  wrote:
>> This is one of those undocumented things (AFAIK): LENGTH applies only
>> to 'vectors'.  So don't use t and definitely don't set it for others.
>> The macro expands to
>>
>> #define LENGTH(x)   (((VECSEXP) (x))->vecsxp.length)
>>
>> What is a vector here?  Something which gets actually allocated by
>> allocVector() AFAICS, that is an atomic or generic vector or an
>> expression.  OTOH, an EXTPTRSXP is stored in a cons cell.
>>
>> There is also a function length(), which is safer.
>
> Thanks for your message. Things are much clearer now to me.
>
> Can I safely assume that INTSXP, REALSXP, LGLSXP, STRSXP, CPLXSXP and VECSXP
> are
> vectors (while EXTPTRSXP is not).

Yes. RAWSXP and EXPRSXP are also vectors (and so in a sense is CHARSXP).

Brian

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] read.fwf doesn't work with header = TRUE (PR#8226)

[Emmanuel . Paradis]

Prof Brian Ripley wrote:
> On Fri, 21 Oct 2005, Emmanuel Paradis wrote:
> 
>> Prof Brian Ripley wrote:
>>
>>> On Thu, 20 Oct 2005 [EMAIL PROTECTED] wrote:
>>>
 Full_Name: Emmanuel Paradis
 Version: 2.1.1
 OS: Linux
 Submission from: (NULL) (193.49.41.105)


 read.fwf(..., header = TRUE) does not work properly since:

 1/ the original header is printed on the console and not in FILE;
 2/ the different 'parts' of the header should be separated with tabs
   to work with the call to read.table.

 Here is a suggested fix for src/library/utils/R/read.fwf.R:

 38c38,40
 < cat(FILE, headerline, "\n")
 ---

> headerline <- unlist(strsplit(headerline, " {1,}"))
> headerline <- paste(headerline, collapse = "\t")
> cat(file = FILE, headerline, "\n")
>>>
>>>
>>>
>>> Thanks, but I don't think that is right.  It assumes the header line 
>>> is space-delimited (or at least that spaces get converted to tabs).  
>>> We have not specified the format of the header line, and it cannot 
>>> usefully be fixed format.  So I think we need to specify it is 
>>> delimited by 'sep'
>>> (not tab).
>>
>>
>> I see, but suppose we read selectively some columns in a file, eg with 
>> widths=c(1, -4, 2), how can we know how many variables have been 
>> skipped and then select the appropriate names in the header line?
> 
> 
> You do not: as the help file says
> 
>  Negative-width fields are used to indicate columns to be skipped,
>  eg '-5' to skip 5 columns.  These fields are not seen by
>  'read.table' and so should not be included in a 'col.names' or
>  'colClasses' argument.

OK, but it is strange to me to not have all variables named in a header 
line.

>> Here is another proposed fix, but this assumes the header line is in 
>> fixed-width format (as specified by 'widths'):
> 
> 
> What happens if there are multi-line records?  Your `fix' crashes.

It crashes anyway because it should be [!drop] and not [drop] ;)

>> 38c38,41
>> < cat(FILE, headerline, "\n")
>> ---
>>
>>> head.last <- cumsum(widths)
>>> head.first <- head.last - widths + 1
>>> headerline <- substring(headerline, head.first, head.last)[drop]
>>> cat(file = FILE, headerline, "\n", sep = sep)
>>
>>
>> ?read.fwf says clearly that sep is used internally.
> 
> 
> Not so: please check the current version.

Here is what I have in R 2.2.0:

  sep: character; the separator used internally; should be a
   character that does not occur in the file.

So, should the fix be simply:

38c38
< cat(FILE, headerline, "\n")
---
 > cat(file = FILE, headerline, "\n")

?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

[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.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

[Peter Dalgaard]

[EMAIL PROTECTED] writes:

> 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.

But what is the wish? 

You mean get it upgraded to xml2 and glade2? Patches would likely be
accepted... 

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

[Hin-Tak Leung]

Peter Dalgaard wrote:
> [EMAIL PROTECTED] writes:
> 
> 
>>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.
> 
> 
> But what is the wish? 
> 
> You mean get it upgraded to xml2 and glade2? Patches would likely be
> accepted... 
> 

:-). 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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8248)

[mschwartz]

On Mon, 2005-10-24 at 17:14 +0100, Hin-Tak Leung wrote:
> Peter Dalgaard wrote:
> > [EMAIL PROTECTED] writes:
> > 
> > 
> >>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.
> > 
> > 
> > But what is the wish? 
> > 
> > You mean get it upgraded to xml2 and glade2? Patches would likely be
> > accepted... 
> > 
> 
> :-). 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


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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

[Marc Schwartz (via MN)]

On Mon, 2005-10-24 at 17:14 +0100, Hin-Tak Leung wrote:
> Peter Dalgaard wrote:
> > [EMAIL PROTECTED] writes:
> > 
> > 
> >>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.
> > 
> > 
> > But what is the wish? 
> > 
> > You mean get it upgraded to xml2 and glade2? Patches would likely be
> > accepted... 
> > 
> 
> :-). 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


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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

[duncan]

-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:
> Peter Dalgaard wrote:
> 
>>[EMAIL PROTECTED] writes:
>>
>>
>>
>>>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.
>>
>>
>>But what is the wish? 
>>
>>You mean get it upgraded to xml2 and glade2? Patches would likely be
>>accepted... 
>>
> 
> 
> :-). 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
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

- --
Duncan Temple Lang[EMAIL PROTECTED]
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-

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

[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:
> Peter Dalgaard wrote:
> 
>>[EMAIL PROTECTED] writes:
>>
>>
>>
>>>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.
>>
>>
>>But what is the wish? 
>>
>>You mean get it upgraded to xml2 and glade2? Patches would likely be
>>accepted... 
>>
> 
> 
> :-). 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
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

- --
Duncan Temple Lang[EMAIL PROTECTED]
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-

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] R interpreter in Java/R plugin or RCP for Eclipse

[Ha, Vu \(MN65\)]

I've been enjoying R a lot and want to say thanks to all R developers for a
fantastic stat environment. 

I also am a fan of the Eclipse computing environment, which I've been using
for Java/C(++)/Python. I was researching for an Eclipse plugin for R and
found StatET (http://www.walware.de/goto/statet). That's when I thought
about writing another Eclipse plugin with tighter integration with R.
Essentially I want to write an R parser/interpreter in Java based on which I
can write an Eclipse plugin with advanced source code editor/interactive
debugger/object browser (say, with roughly the same functionalities as
JDT's). The interpreter would delegate all actual evaluations to C/Fortran
codes via the Java Native Interface, and would natively support new
libraries written in Java.

The potential benefits are:

- Leveraging state-of-the-art Eclipse features, such as frameworks to
develop advanced source editor and debugger.

- Largely complete environment for (future) R users with familiarity with
Eclipse but not with command-line environments (Emacs/Unix Shells). With a
LaTex plugin (http://sourceforge.net/projects/etex/), a grad student can
accomplish lots of tasks within Eclipse. 

- R library developers can for example use CDT (http://www.eclipse.org/cdt/)
for C/C++ or photran http://www.eclipse.org/photran/ within Eclipse.

- Encourage Java development for R.

- Make it easy to call R from Java programs and Java from R scripts.

I have been reading the R language definition document and studying R's C
source code. The first step is to isolate the source files responsible for
parsing R sources to internal data structures. I would appreciate any
comments/suggestions regarding this direction. Directness is a plus ("No,
that's a dumb idea" is fine, as long as a good explanation is provided). 

My hope is that as the Eclipse environment (especially  the Rich Client
Platform RCP and the Standard Widget Toolkit SWT) evolves, we can piggy-back
on it and develop a free R environment that can compete with S-Plus in the
GUI-oriented circles. 

Thanks in advance,
Vu Ha, PhD.
Information and Decision Technology
Honeywell Aerospace
3660 Technology Dr. 
Minneapolis, MN 55418
612-951-7114
http://cs.uwm.edu/~vu
 
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8247)

[Hin-Tak Leung]

Marc Schwartz (via MN) wrote:
> On Mon, 2005-10-24 at 17:14 +0100, Hin-Tak Leung wrote:
> 
>>Peter Dalgaard wrote:

>>>You mean get it upgraded to xml2 and glade2? Patches would likely be
>>>accepted... 

> 
> 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.

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] download problem: Windows binaries - patched/devel versions

[P Ehlers]

Lately, I get a "page cannot be found" error (IE 6.0, Windows XP)
when I try to download the following:

http://cran.us.r-project.org/R-2.2.0pat-win32.exe
http://cran.us.r-project.org/R-2.3.0dev-win32.exe

(Same for all other mirrors (about 6) that I've tried.
Could someone please check if these files are accessible to them?
I'm guessing there's something haywire in my setup.

Note that I can ftp the files without problem.

-- 
Peter Ehlers
Department of Mathematics and Statistics
University of Calgary, 2500 University Dr. NW   ph: 403-220-3936

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] download problem: Windows binaries - patched/devel versions

[Prof Brian Ripley]

The addresses are wrong.  We know there are some incorrect links due to 
mirroring errors, but

http://cran.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe

etc are there.

On Mon, 24 Oct 2005, P Ehlers wrote:

> Lately, I get a "page cannot be found" error (IE 6.0, Windows XP)
> when I try to download the following:
>
> http://cran.us.r-project.org/R-2.2.0pat-win32.exe
> http://cran.us.r-project.org/R-2.3.0dev-win32.exe
>
> (Same for all other mirrors (about 6) that I've tried.
> Could someone please check if these files are accessible to them?
> I'm guessing there's something haywire in my setup.
>
> Note that I can ftp the files without problem.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Problem with Rchtml.dll in R-2.3.0dev-win32.exe?

[P Ehlers]

Not really a problem, but I can't figure this out:
(OS: Windows XP SP2)

I have both R-patched ("R version 2.2.0, 2005-10-21")
and R-devel ("R version 2.3.0, 2005-10-21") installed.
For both, I set options(chmhelp = TRUE).
R-patched has no problems, but in R-devel, attempts to access
help result in a Windows error message:

"The procedure entry point [EMAIL PROTECTED] could not be located
in the dynamic link library hhctrl.ocx."

with an R error message:

Error in dyn.load(x, as.logical(local), as.logical(now)) :
  unable to load shared library
'C:/StatisticsPrograms/R/Rdevel/bin/Rchtml.dll':
  LoadLibrary failure:  The specified procedure could not be found.

Replacing Rchtml.dll in \bin with that from R-patched fixes the
problem.

A hex file compare claims the two versions of Rchtml.dll are
identical, except for the creation dates.

Any ideas?


Peter

-- 
Peter Ehlers
University of Calgary

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Rgnome depends on obsolete components libglade/libxml (PR#8249)

[mschwartz]

On Mon, 2005-10-24 at 19:15 +0100, Hin-Tak Leung wrote:
> Marc Schwartz (via MN) wrote:
> > On Mon, 2005-10-24 at 17:14 +0100, Hin-Tak Leung wrote:
> > 
> >>Peter Dalgaard wrote:
> 
> >>>You mean get it upgraded to xml2 and glade2? Patches would likely be
> >>>accepted... 
> 
> > 
> > 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.
> 
> 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).

Respectfully, I would disagree with your characterization of my reply. 

I simply pointed out (as it states in the manual) that there should be
no expectation of further development from R Core and as a result no
expectation of an _officially_ maintained, much less reviewed, TODO list
for the package.

It plainly indicates that it has been left as an example for others,
with no implication that one should be dissuaded from using it as such.
It was done (as others have characterized in prior threads) as a "proof
of concept", not as a fully functioning GUI.

Your reporting a RFE to the R Bug Tracking System would imply an
expectation that the request be officially tracked by R Core in some
fashion (even if just to close out the report) and/or perhaps be acted
upon at some future date by _somebody other than yourself_.

Peter's words were direct in that patches would _likely_ be accepted,
but at the same time are not being actively solicited. A substantive
difference, given that a patch made available for an official R package,
would still take some effort on the part of R Core to implement and
test.

It seems to me that yet another option here would be for you to offer to
take over as the package maintainer and bring it up to date to Gtk2, if
you are so inclined. The package has been made available under the GPL,
thus there is nothing precluding you from doing so and even creating a
new CRAN package based upon it.

The same approach is available for the orphaned packages on CRAN, so
this is nothing new.

This brings us full circle to the whole GUI discussion taking place and
so I'll leave it for that thread.

> 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?

I think that the question is more, what TODO list, where and maintained
by whom?

In this case, with a package that is no longer being actively maintained
by R Core, it may very well be appropriate to have a separate TODO list
or even Wiki someplace to address issues where participation by useRs is
being actively solicited. The R-sig-* mailing lists would certainly be
one place for such focused activities.

> 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?

Not bad at all. It is more a question of what is the appropriate
mechanism to facilitate such activity, in a fashion that does not have
an impact on R Core, unless it is truly required.

Best regards,

Marc

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] X11 redraw events dropped? (PR#8250)

[keith]

Full_Name: Keith Frost
Version: 2.1.0
OS: Debian Sarge
Submission from: (NULL) (66.162.141.10)


This has actually been a problem for some time in R under Linux. (I noticed 
it under previous builds for Redhat 9 as well.)  The graphics device windows
produced by the x11() function do not always get redrawn when they should, 
sometimes leaving the device blank when there should be a graph on it.  
I do not know for sure that this is an R-specific problem (I suppose the 
window manager could be failing to pass along the correct redraw information), 
but I thought I'd try to find out if other people are experiencing it, and 
if it can be tracked down and fixed.

To reproduce:

Bring up a number of plots with the x11() function, and graph things on them.  
Move 
other windows to cover, and then reveal, the various plot windows, until -- one
or more
of your graphs disappears.  Move the graphs over each other to get the graphs to
come
back.   Etc.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problems with example(Grid) in grid package

[Paul Murrell]

Hi


hadley wickham wrote:
 > I've also noticed the behaviour of grid.rect() has changed in 2.2.0.
 > Before the fill defaulted to transparent, but now it defaults to
 > white.


The initial value of the 'gp' settings for the ROOT grid viewport has 
changed in 2.2.0 (see grid/doc/changes.txt).  Before it defaulted to 
transparent, but now it defaults to whatever the 'bg' is for the current 
device (on some, e.g., png() this is "white", though I'm not sure why 
right now) so on some devices something like grid.rect() behaves 
differently.

If before you had something like ...

   
   # Now I think I'll draw a nice border around the outside
   grid.rect()

... you should either do ...

   # I'll draw a rectangle first in case there is a non-transparent
   # fill in effect;  NOTE that if I was writing perfect grid code
   # I would always be aware that I might be being drawn in a viewport
   # that was defined by someone else who might have, for example,
   # defined a non-transparent fill, so it's not entirely
   # grid's fault that things suddenly aren't working as I planned
   grid.rect()
   

... or ...

   
   # Now I think I'll draw a nice border around the outside
   # AND I really want JUST the border;  I have absolutely no
   # intention of filling this rectangle, no matter what the
   # current fill setting happens to be
   grid.rect(gp=gpar(fill="transparent"))

Paul


 > On 10/21/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote:
 >
 >>The following:
 >>
 >>library(grid)
 >>grid.newpage()
 >>example(Grid)
 >>
 >>has the yaxis label partly cut off and the x axis label does not 
appear at all.
 >>Also ?grid.multipanel in that example brings up documentation for
 >>grid-internal but this would not seem to be internal if its part of 
an example.
 >>
 >>I am using:
 >>
 >>
 >>>R.version.string  # Windows XP
 >>
 >>[1] "R version 2.2.0, 2005-09-20"
 >>
 >>__
 >>R-devel@r-project.org mailing list
 >>https://stat.ethz.ch/mailman/listinfo/r-devel
 >>
 >
 >
 > __
 > R-devel@r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problems with example(Grid) in grid package

[Paul Murrell]

Hi


Gabor Grothendieck wrote:
> The following:
> 
> library(grid)
> grid.newpage()
> example(Grid)
> 
> has the yaxis label partly cut off and the x axis label does not appear at 
> all.
> Also ?grid.multipanel in that example brings up documentation for
> grid-internal but this would not seem to be internal if its part of an 
> example.


grid.multipanel() is just a demo hack function, not intended for people 
to use for anything serious, just meant to provide an example of what 
can be done.  It had some merit when grid was just a prototype package 
for people to play with.  Now that grid is more mature I should probably 
just kill grid.multipanel().

Paul
-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
[EMAIL PROTECTED]
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problems with example(Grid) in grid package

[Prof Brian Ripley]

On Tue, 25 Oct 2005, Paul Murrell wrote:

> hadley wickham wrote:
> > I've also noticed the behaviour of grid.rect() has changed in 2.2.0.
> > Before the fill defaulted to transparent, but now it defaults to
> > white.
>
>
> The initial value of the 'gp' settings for the ROOT grid viewport has
> changed in 2.2.0 (see grid/doc/changes.txt).  Before it defaulted to
> transparent, but now it defaults to whatever the 'bg' is for the current
> device (on some, e.g., png() this is "white", though I'm not sure why
> right now)

Because many (maybe even most) png viewers do not handle transparency 
correctly.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] X11 redraw events dropped? (PR#8250)

[Prof Brian Ripley]

Please, your R is well out of date and you are asked NOT to submit bug 
reports on obselete versions.  Nor, BTW, on things you are not sure are R 
bugs.

The window manager hinting was changed in 2.2.0, and some people who used 
to experience this sort of thing say it is solved.


On Mon, 24 Oct 2005 [EMAIL PROTECTED] wrote:

> Full_Name: Keith Frost
> Version: 2.1.0
> OS: Debian Sarge
> Submission from: (NULL) (66.162.141.10)
>
>
> This has actually been a problem for some time in R under Linux. (I noticed
> it under previous builds for Redhat 9 as well.)  The graphics device windows
> produced by the x11() function do not always get redrawn when they should,
> sometimes leaving the device blank when there should be a graph on it.
> I do not know for sure that this is an R-specific problem (I suppose the
> window manager could be failing to pass along the correct redraw information),
> but I thought I'd try to find out if other people are experiencing it, and
> if it can be tracked down and fixed.
>
> To reproduce:
>
> Bring up a number of plots with the x11() function, and graph things on them.
> Move
> other windows to cover, and then reveal, the various plot windows, until -- 
> one
> or more
> of your graphs disappears.  Move the graphs over each other to get the graphs 
> to
> come
> back.   Etc.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] download problem: Windows binaries - patched/devel versions

[P Ehlers]

Thanks for the quick response.

-Peter

Prof Brian Ripley wrote:
> The addresses are wrong.  We know there are some incorrect links due to 
> mirroring errors, but
> 
> http://cran.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe
> 
> etc are there.
> 
> On Mon, 24 Oct 2005, P Ehlers wrote:
> 
>> Lately, I get a "page cannot be found" error (IE 6.0, Windows XP)
>> when I try to download the following:
>>
>> http://cran.us.r-project.org/R-2.2.0pat-win32.exe
>> http://cran.us.r-project.org/R-2.3.0dev-win32.exe
>>
>> (Same for all other mirrors (about 6) that I've tried.
>> Could someone please check if these files are accessible to them?
>> I'm guessing there's something haywire in my setup.
>>
>> Note that I can ftp the files without problem.
> 
> 

-- 
Peter Ehlers
University of Calgary

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] download problem: Windows binaries - patched/devel versions

[Duncan Murdoch]

P Ehlers wrote:
> Lately, I get a "page cannot be found" error (IE 6.0, Windows XP)
> when I try to download the following:
> 
> http://cran.us.r-project.org/R-2.2.0pat-win32.exe
> http://cran.us.r-project.org/R-2.3.0dev-win32.exe
> 
> (Same for all other mirrors (about 6) that I've tried.
> Could someone please check if these files are accessible to them?
> I'm guessing there's something haywire in my setup.
> 
> Note that I can ftp the files without problem.

The files are where they have always been (in 
/bin/windows/base), but the mirroring software has started 
playing around with the URLs, adding in lots of ".."'s to the path.  If 
you manually edit the path you'll find them.  We're working on fixing 
the mirroring.

To be explicit:  get them from

http://cran.us.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe
http://cran.us.r-project.org/bin/windows/base/R-2.3.0dev-win32.exe

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problems with example(Grid) in grid package

[Gabor Grothendieck]

On 10/24/05, Paul Murrell <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> Gabor Grothendieck wrote:
> > The following:
> >
> > library(grid)
> > grid.newpage()
> > example(Grid)
> >
> > has the yaxis label partly cut off and the x axis label does not appear at 
> > all.
> > Also ?grid.multipanel in that example brings up documentation for
> > grid-internal but this would not seem to be internal if its part of an 
> > example.
>
>
> grid.multipanel() is just a demo hack function, not intended for people
> to use for anything serious, just meant to provide an example of what
> can be done.  It had some merit when grid was just a prototype package
> for people to play with.  Now that grid is more mature I should probably
> just kill grid.multipanel().

If you kill it I still think it would be a nice to provide a similar
example.  I am sorry that I missed knowing about it when initially
trying to learn how to do layouts since it might have saved me some
time.  Maybe it can be incorporated into the example section of one
of the help files or into a demo or even a vignette on grid.multipanel.

Also note that grid.multipanel is used not only in Grid but also in:
  http://www.stat.auckland.ac.nz/~paul/grid/doc/rotated.pdf

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] strptime problem for 2004-10-03 02:00:00

[Michael Sumner]

Hello, I at first thought this was a system or locale issue, but since 
it occurs on
both Windows and Linux and only for 2004 (AFAIK) I report it.

I have a problem with as.POSIXct for the hour between
"2004-10-03 02:00:00 GMT" and "2004-10-03 02:59:59 GMT".  

In short, the 2 AM (GMT) hour in 2004 (but not in other years) is 
interpreted as 1 AM by strptime:
(I use ISOdatetime as a convenience).

## Windows XP

ISOdatetime(2004, 10, 3, 2, 0, 0,  tz = "GMT")
##[1] "2004-10-03 01:00:00 GMT"
ISOdatetime(2004, 10, 3, 1, 0, 0,  tz = "GMT")
##[1] "2004-10-03 01:00:00 GMT"

 ISOdatetime(2005, 10, 3, 2, 0, 0,  tz = "GMT")
##[1] "2005-10-03 02:00:00 GMT"
 ISOdatetime(2005, 10, 3, 1, 0, 0,  tz = "GMT")
## [1] "2005-10-03 01:00:00 GMT"


I've not explored it for other years, but it is not a problem for the 
same time in previous and next years.
I only found it as I have a continuous sequence of date-times that cover 
that time period, the problem
is not created by traversing that time with seq.POSIXt.

I usually use Windows XP, below I also give results on Linux  (release 
"2.4.21-37.ELsmp").  On that
machine the times are incorrect in the other direction (in 2004, 2 AM is 
interpreted as 3 AM).

My (Windows) system is set to automatically adjust for daylight summer 
time, and if I uncheck this and restart R
the problem is "fixed".  I don't know how I would do that on Linux, but 
it's a server anyway so I couldn't.  

## R 2.2.0
## Windows XP, SP2
## System time is set to (GMT+10:00) Hobart  -  Tasmanian Summer Time (1 
hour forward of GMT+10)
Sys.getlocale()
## [1] 
"LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252"

 Try for 2004

(t1 <- ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT"))
##[1] "2004-10-03 01:00:00 GMT"
(t2 <- ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT"))
##[1] "2004-10-03 01:00:00 GMT"

## no difference - why?  
 t2 - t1
## Time difference of 0 secs

## Try for 2005

(t1 <- ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT"))
##[1] "2005-10-03 01:00:00 GMT"

(t2 <- ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") )
##[1] "2005-10-03 02:00:00 GMT"

## 1 hour difference - as expected  
t2 - t1
## Time difference of 1 hours



 LINUX


## R 2.2.0
## Linux (release "2.4.21-37.ELsmp"
## System time is set to (EST) - summer time (I don't know how to find 
more about this)
Sys.getlocale()
## [1] 
"LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=en_AU.UTF-8;LC_MESSAGES=en_AU.UTF-8;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C"


 Try for 2004

(t1 <- ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT"))
## [1] "2004-10-03 01:00:00 GMT"

 (t2 <- ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT"))
##[1] "2004-10-03 03:00:00 GMT"

## difference of 2 hours - why?
 t2 - t1
## Time difference of 2 hours


 ## Try for 2005

 (t1 <- ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT"))
##[1] "2005-10-03 01:00:00 GMT"

(t2 <- ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") )
##[1] "2005-10-03 02:00:00 GMT"


## one hour difference as expected
 t2 - t1
## Time difference of 1 hours

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel